. Прежде чем оценивать вероятность успеха или неудачи следует провести декомпозицию ситуации. Нам следует выписать каждый потенциально возможный риск, и оценить его отдельно. Подобный анализ по времени может занять на 30% больше времени, но в итоге дать на 90% более точный результат.
. В начале любого обсуждения нам следует обозначать повестку дня (agenda). Повестка должна быть отсортирована по важности вопросов (важнейшие – первыми). Помимо этого, нам следует назначить ведущего повестки (модератора), который будет следить за тем, чтобы обсуждение не уходило в мелкие детали и не «съедало» время всей команды.
. Иногда атмосферы «открытости и доверия» бывает недостаточно чтобы узнать мнение каждого участника. Нам следует создать механизм, благодаря которому каждый участник планирования сможет свободно (может, даже, анонимно) высказать свою точку зрения. Самый большой «риск» для нас – это случайно узнать какую-то деталь, которая была всеми упущена.
. Любые обсуждаемые сроки должны быть оценены всеми участниками команды. Возможность обсуждать сроки, озвученные коллегами, позволяет нам сохранять атмосферу открытости, что делает диалог более продуктивным.
. Нам следует ограничить влияние наших эмоций, а также офисной атмосферы на обсуждаемые сроки.
, . В большинстве случаев мы не ожидаем каких-то существенных изменений в завтрашнем дне. Вероятность изменений коньюнктуры рынка или «мира» наших партнеров по проекту нами обычно игнорируется. Если мы не хотим впоследствии объяснять причину нашего провала «маловероятными», «внешними» событиями, тогда нам следут заранее учесть подобные вероятности ().
. Бывают ситуации, когда наш выбор в пользу «безопасного», «однозначного» решения приводит к недополученной выгоде. Например, мы не решились делать релиз в один день с конкурентами из-за вероятности низкого спроса. При этом, мы не подумали, что ситуация может быть прямо противоположной, и интерес у аудитории к нам в этот день может быть гораздо выше чем в любой другой. Понимая нашу склонность к выбору решений с гарантированным исходом, нам следует учиться абстрагироваться от наших эмоций и более трезво оценивать ситуацию.
. В планировании следует опираться только на данные системы и проверенные факты. К мнению любых персон, у которых много власти и авторитета следует подходить предельно осторожно.
. В зависимости от специфики нашего продукта и нашей аудитории, нам может понадобиться учесть фактор предрассудков. Это касается календарных дат запуска (напр. Пятница 13), ассоциаций с негативными событиями (день скорби в стране), и т.д.
. Нам следует записать все договоренности к которым мы с командой пришли, включая те, которые, как нам может показаться, слишком очевидны. Показывая нашу картину мира во всех возможных деталях мы снижаем вероятность, что что-то «предельно очевидное» было пропущено нами, либо нашими коллегами.
, . Если наш коллега игнорирует какие-либо аргументы из указанных выше, считая что «это к нему не применимо», тогда первым делом нам следует пересмотреть все решения в которых он участвовал.
#63.В последнем релизе мы допустили грубую ошибку. Что делать?
#5.Почему пользователи жалуются на обновления продукта?
#8.Почему пользователи остро реагириуют на изменения в продукте?
#22.Почему пользователям не понравилось последнее обновление продукта?
#37.Какие риски несут большие изменения в идеологии или функциональности продукта?
#61.Что делать, если команда тратит слишком много времени на неважные мелочи?