Monthly Archives: November 2011

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

Слушал выступление Юрия Прядко на тему “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” – это печально.
При изменении старого решения нужно понять, почему оно было принято и объяснить, почему производятся изменения.
Если дали завышенные оценки, то ни в коем случае не соглашаться с заказчиком о заниженных, потому что покажете свою некомпетентность, а оценщику дать по шапке.
Лучшее всего заслужить доверие – это сделать успешный проект. До этого можно на небольших кейсах заслуживать доверия, демонстрируя заказчику свою компетентность. И опять же управлять ожиданиями, эмоциями в том числе.
От себя добавлю. Раньше мне казалось, что в ИТ все оценивается только по продукту, как он сделан. Но несколько лет назад, закралось подозрение, что что-то тут не так. И чем дальше, тем больше начал понимать, что эмоции, впечатления на человека и т. д. играют очень большую роль, а техническая часть как-то неожиданно несколько намного менее значительна. А в какой-то момент доходит, что все вообще наоборот – как прозрение :)… Неожиданно для меня Юрий это подтвердил – все к этому приходят. Объяснить это сложно. Единственное что скажу, что если бы мне раньше кто-то сказал то, к чему я пришел, я бы подумал, что человек с луны свалился….