Предположения и управление ожиданиями

Слушал выступление Юрия Прядко на тему “Assumptions and expectations management”.
Все более и более понимаю важность этой темы. Все кажется очень просто до тех пор, пока не начинаешь сталкиваться с реальными кейсами на своем опыте.

Ниже краткий отчет и основные мысли, которые мне показались полезными.

Когда мы даже угадываем число, мы предполагаем, что загадывающий будет отвечать на вопросы, будет говорить правду. О том, целое ли число, спрашивают очень редко, хотя подразумевают неявно.
Всегда в условиях недостатка информации при принятии решения мы делаем какие-то предположения: явно или неявно.
Некоторые предположения базируются на фактах, некоторые на опыте.
Типы преположений:
*Культурные
* Биологические
* Интеллектуальные
* Индивидуальные (наши аксиомы, у каждого есть свои)
Часто избыток информации (особенно противоречивой) хуже чем недостаток.
 
Культурные ожидание:
* Запад – восток
* Север – юг
* Мужчины – женщины
* Россия – Украина
* Программисты – тестировщики
Биологические ожидание
* стоять – лежать
* будущее (вверх, вправо у дизайнеров) – прошлое
* активность – пассивность
* «Приподнятое настроение»
* «Как в воду опущенный»
Интеллектуальные:
Аргументы:
* Рациональные (рассуждения, доказательства) – наиболее распространен
* эмоциональные (сопереживание)
* Этические
Лучше использовать все три.
Недооценивая эмоциональные и этический аспекты, мы многое упускаем.
Индивидуальные:
Травматический опыт чаще всего:
* Все собаки злые
* Все стоматологи причиняют боль
* «Все мужики – козлы»
Кругом «все» – нужно остерегаться.
Ограничивающие:
Любое предположение или ожидание может ограничивать, если оно блокирует или мешает нам ясно мыслить в конкретной задаче.
Ожидания базируются на предположениях.
Что такое успех проекта? On time? on spec? on budget?.
No! Customer satisfaction!!
Customer satisfaction = удовлетворенные ожидания заказчика.
Как же их удовлетворять?
* Знать
* Устанавливать
* Поддерживать актуальными
* Управлять
Знать.
В начале проекта задать 2 вопроса:
* Чего мы хотим достичь?
* Какими критериями определяется успех?
Ответы на эти вопросы – всегда перед глазами.
Большая понятная цель для всех – ее все видят и ничего не может ее закрыть, все в фокусе.
Главное – четкий критерий достижения цели.
Когда заказчик уменьшительно говорит «маленький прототипчик быстренько» часто исполнители забывают спрашивать о больших целях.
Команда теряет фокус.
У всех разные цели – закончить проект, получить ЗП, не получить «по башке». В этой ситуации главное, чтобы все правильно понимали цели проекта.
Эти два вопроса нужно задавать всем, чтобы понимать цели друг друга.
В конечном счете нужно собирать команду так, чтобы цели были сходными.
Одним митингом невозможно изменить цели людей просто потому, что появились цели проекта.
Нужно подбирать и людей, и заказчика. Нужно до 70% пересечения целей, 50% – возможно еще работать слаженно, но уже не то.
Чтобы сопоставить цели компании с тем, что делают конкретные разработчики, менеджеру всегда нужно давать фидбек команде и показывать разработчикам их вклад для бизнеса.
А также показывать постановщикам целям, как команда помагает достичь бизнес целей.
Здоровье и счастье команды критично, особенно в IT 🙂
Как устанавливать эти цели, ответы на 2 вопроса?
* Ответьте на те же вопросы себе и вашим коллегам, заказчикам, подрядчикам
* Разрешите противоречия
* Зафиксируйте результаты письменно.
Люди должны понимать, какую пользу они приносят конечным пользователям.
Средняя слаженная команда сильнее неслаженной команды сильных игроков, поскольку знают ожидания друг друга.
После каждой итерации проведите ретроспективу – туда ли мы идем?
Цель в любом случае должна быть в фокусе.
Если ПжМ говорит что все идет 100% по плану – либо врет, либо не все знает 🙂
Управление ожиданиями
* Опишите правила игры
* Поступайте согласно этим правилам
* Требуйте от других того же
* Меняйте правила, если это необходимо.
(По сути неявные ожидения сделать явными и частью процесса)
От новичков много фидбеков об ожиданиях, когда они с ними знакомятся. Это связано с тем, что те, кто давно работает, следуют ожиданиям автоматически и незаметно для себя.
Что нужно документировать и писать в контрактах, чтобы не набивать шишки?
Основные правила:
* Ключевые ожидания – в контракт!
* Все ожидания – в письменном виде (email).
* Обо всех изменениях сообщать в течении 1 (одного) бизнес дня – лучше, чтобы бизнес-процессы были организованы так, чтобы это было известно всем и сразу.
По западным законам можно с email идти в суд. В Украине – нет, нужно передавать на физическом носителе (на диске).
Иногда нужно уточнять, что является официальным – например есть случаи, когда просто е-мейл – это не официально, а если в doc-файле переслано, то уже официально.
Нужно обсуждать с заказчиков также вплоть до coding conventions, особенно если некоторые части системы заказчик реализует своими силами, а некоторые части – исполнительно, т.е. мы. В идеале оповещение об изменении ожидание должны приходить сразу после изменения вики страниц.
Что писать в контракт?
* Зависимости от третьих сторон.
* Надежность оценок
* Контроль изменений
* Ресурсинг, рекрутинг, стаффинг
Зависимости от третьих сторон:
* Необходимые нам артефакты будут предоставлены вовремя (указывать время)
* Представители заказчика/третьей стороны будут доступны для уточнения вопросов (указать SLA по ответам!)
* Решение третьих сторон будут удовлетворять проектным нуждам – это нужно писать!
(Ух и драконовские видать контракты у Cogniance 🙂 )
Кейс: API заказчика было не приспособлено для взаимодействия с проектом, который планировался для реализации компанией. Но заказчик ничего не показывал до подписания контракта, мотивируя это требованиями безопасности.
Проект закрыт, но нужно было вписать в контракт общую формулировку, что наши предположения по требованиям будут удовлетворены. И после ознакомления информировать заказчика либо о закрытии проекта, либо об продолжении с измененными условиями
Контроль изменений, оговаривать:
* Оценки базируются на документах, доступных в момент совершения оценки.
* Все новые требования будут проводиться через процесс внесения изменения (неплохо описать процесс)
Надежность оценок
* Прописан конкретный процесс (например, 80%, 90%), на основании экспертного решения и исторических данных – здесь имеется ввиду fixed price. На практике покрывается 6 сигмами, вероятность около 95%.
* Надежность оценок по решениям третьих сторон должна быть ниже вашей собственной.
* Ниже определенного уровня надежности fixed price делать нельзя.
Если при fixed price идете быстрее графика, то лучше вложить избыток в качество – повышаете удовлетворение заказчика, а также избегаете подозрения заказчика о переоценке с целью срубить побольше бабла.
Ресурсинг
* План по ресурсам проекта – функция от времени (довольно сильно зависит как от ситуации в компании, так и от смены технологий)
* Устанавливайте «срок годности» для ваших оценок по людям – рынок меняется. (если мы обещали сформировать команду за месяц, то это обещание имеет срок годности, через месяц все может быть по другому)
Кейс. Гибель человека в Аламеде. Люсьен Кантон, статье “Assumptions Can Kill” – это печально.
При изменении старого решения нужно понять, почему оно было принято и объяснить, почему производятся изменения.
Если дали завышенные оценки, то ни в коем случае не соглашаться с заказчиком о заниженных, потому что покажете свою некомпетентность, а оценщику дать по шапке.
Лучшее всего заслужить доверие – это сделать успешный проект. До этого можно на небольших кейсах заслуживать доверия, демонстрируя заказчику свою компетентность. И опять же управлять ожиданиями, эмоциями в том числе.
От себя добавлю. Раньше мне казалось, что в ИТ все оценивается только по продукту, как он сделан. Но несколько лет назад, закралось подозрение, что что-то тут не так. И чем дальше, тем больше начал понимать, что эмоции, впечатления на человека и т. д. играют очень большую роль, а техническая часть как-то неожиданно несколько намного менее значительна. А в какой-то момент доходит, что все вообще наоборот – как прозрение :)… Неожиданно для меня Юрий это подтвердил – все к этому приходят. Объяснить это сложно. Единственное что скажу, что если бы мне раньше кто-то сказал то, к чему я пришел, я бы подумал, что человек с луны свалился….

Share

5 thoughts on “Предположения и управление ожиданиями

  1. anotherpm

    Да, ты не одинок.

    Эмоции всегда будут рулить, потому что мы люди. Давно об этом рассказываю на блоге.

    Reply
  2. sergtk

    людям чужие грабли не подходят, нужно именно своими по лбу получить 🙂

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *