?

Log in

No account? Create an account
Andrei Ivanov
Checking assumptions 
26th-Jun-2009 11:06 am
JetBrains
Один из признаков хорошего менеджера проектов - умение минимизировать число сюрпризов. Один из основных источников сюрпризов - неявные допущения, сделанные при планировании. Assumptions. Допущения делаются всегда и сами по себе они не ведут к сюрпризам. Проблемы с допущениями возникают от того, что они неявные.
Возьмём, например, простое утверждение. "У нас есть команда из 4 разработчиков и мы оценили объем разработки в 12 человеко-месяцев. Мы обещаем заказчику, что продукт будет готов через 3 месяца".

Вот только некоторые, из неявных допущений, сделанных в этом утверждении:
1) Все 4 разработчика будут работать все 3 месяца. Никто не уйдёт в отпуск. Никто не заболеет. Никого не отвлекут на поддержку старых разработок. Не будет проводиться митингов, отвлекающих разработчиков, или эти митинги включены в оценку.
2) У наших 4 разработчиков одинаковая производительность, работа в команде никак на неё не влияет. Объем разработки мы оценивали в человеко-месяцах соответствующих этой производительности.
3) Наши разработчики пишут программное обеспечение сразу готовое к использованию. Его не надо тестировать, и не надо править в нем ошибки.
4) Наши заказчики не будут менять постановку задачи по ходу разработки.

Теперь, если любое из этих допущений окажется неверным, например один из разработчиков на неделю заболеет, то нас ожидает сюрприз в виде проекта, который не закончен к ожидаемому сроку.

Правильное обращение с допущениями состоит из 3 частей. (1) Допущения необходимо делать явными (2) Нужно отслеживать, остаются ли наши допущения верными (3) Если какое-либо допущение оказывается неверным, необходимо соответствующим образом корректировать план.

Checking assumptions - занятие полезное не только в управлении разработкой программных продуктов. Чтобы мы не делали, всегда существует набор допущений, из которых мы исходим. И всегда полезно помнить об этих допущениях и правильно реагировать, если они оказываются неверными.
Comments 
26th-Jun-2009 07:30 am (UTC) - Совсем нет
Теория хаоса со всей уверенностью заявляет нам, что минимизировать количество сюрпризов в сколько нибудь существенном отношении в контексте практики реального менеджмента невозможно. Вот здесь как раз рефакторинг социального управления неустраним...
26th-Jun-2009 08:52 am (UTC) - Re: Совсем нет
Теория хаоса и рефакторинг социального управления - это как-то чересчур сложно для меня.

Одни менеджеры выпускают продукты в срок, или, в случае форс-мажора, к нему готовы. Другие за неделю до релиза, сообщают о "непредвиденных обстоятельствах". Мне гораздо больше нравятся первые -)

Edited at 2009-06-26 09:01 am (UTC)
26th-Jun-2009 09:12 am (UTC) - Re: Совсем нет
Ну, это очевидно..мне тоже первые нравятся...:-)
26th-Jun-2009 07:36 am (UTC)
минимизация рисков и снижение воздействий отклонений везде наиболее полезная штука, в радиотехнике к примеру при проектировании тоже ведь основное было - снижение влияния разбросов параметров радиодеталей на результат, так как кто помнит еще советские резисторы и конденсаторы, то помнит что на них писалось и +- 20% :)
26th-Jun-2009 09:11 am (UTC)
Практика показывает, что учесть допущения на рациональном уровне (как и оценить все риски) сложно, а для средних и небольших проектов слишком затратно. Хороший менеджер поэтому не столько работает с допущениями, выписывая и отслеживая их, сколько умеет избегать грубых допущений, меняющих оценку затрат на порядок, и работать с буферным временем. Знает, а может чувствует, какой запас времени нужен. Для стандартной задачи один, для исследовательской -- другой; для монолитной задачи, где ничего нелья урезать, запас времени должен быть больше, чем в проекте, где возможен поэтапный запуск с неполной функциональностью.

Искусство выполнения задачи в срок проявляется в том, чтобы сделать все этапы проекта равномерными. Если на текущем этапе расходуем буфер, значит, уже сейчас надо урезать функционал, а не надеяться, что времени на всё хватит; если на последнем этапе согласовываем с заказчиком, значит, надо и на первом держать его в курсе; и т.д. Как только поймано это ощущение ритма, равномерности, детальный контроль допущений уже не даст качественного скачка.
26th-Jun-2009 09:30 am (UTC)
Проблема с оценкой *всех* рисков и допущений возникает только после того, как их *в принципе* начали выявлять и оценивать. Что для многих виденных мною проектов уже было бы большим шагом вперед.

Но вообще, согласен, выписывание в столбик всех допущений и рисков с их точной оценкой может быть избыточным для малых и средних проектов. И про ритм и равномерность тоже согласен. (Сначала написал, что науки про выписывание и оценивание всех рисков нет. Потом посмотрел на вот эту и вот эту книжки, устыдился и поправил.)

Edited at 2009-06-26 09:55 am (UTC)
26th-Jun-2009 09:18 am (UTC)
Лёгким офтопом: насчёт пункта 3. Всегда удивляло, почему изготовление первого кое-как с божьей помощью не падающего прототипа называется "концом разработки". По-моему, настоящий конец разработки совпадает с концом тестирования, а не с началом.

Но понятно, что пример из поста можно порефакторить и включить тестирование туда, где ему и место - в первоначальную оценку объёма работ.
26th-Jun-2009 10:56 am (UTC)
Понятно почему. Надо же отрапортовать stop development. Не все, как один наш общий знакомый, понимают, что в принципе, остановится можно в любой момент -)
26th-Jun-2009 11:20 am (UTC)
Да само понятие "stop development" - лживое. Всегда плевался, услышав. Есть, по-моему, два существенных майлстоуна: "первый прототип отдан в тестирование" - и здесь нужно понимать, что абсолютно всё ещё может быть переписано заново. И второй: "продукт/фича готов(а), багфикс окончен". "Stop development" - это химера вообще.

Впрочем, это должно быть очевидным.
26th-Jun-2009 09:57 am (UTC)
А еще у нас говорят: assumption is the mother of all fuck-ups. :)
26th-Jun-2009 10:11 am (UTC)
всё правильно и полезно, но неуловимо напоминает один блог про рефакторинг ;-)
26th-Jun-2009 10:41 am (UTC)
Что не удивительно. Любые попытки кому-то давать советы похожи -)
Я прежде чем на что-то подобное решиться, обычно задаю себе два вопроса: насколько сказанное может быть для кого-то новым и полезным. И насколько я компетентен в данном вопросе, чтобы высказываться. В "блоге про рефакторинг" посты про рефакторинг иногда, мне кажется, не проходят первого теста. А посты с советами СЕО - второго.
26th-Jun-2009 10:50 am (UTC)
да я просто слегка подколол ;-)
по мотивам вашего недавнего поста про яшин блог.

а если по теме - все эти допущения, наверное, ещё и имеют сильно разные веса в зависимости от типа проекта, типа заказчика итп.
26th-Jun-2009 10:53 am (UTC)
Да я понял -)
26th-Jun-2009 10:13 am (UTC)
предположение №3 заведомо ложное
26th-Jun-2009 10:26 am (UTC)
Угу. Тем не менее, встречается. Как раз в силу неявности. То есть, если спросить человека, который делает изначальное утверждение про 3 месяца, правда ли он думает, что все будет написано без ошибок, и не потребует тестирования, он скорее всего спохватится.
29th-Jun-2009 09:06 am (UTC)
кто-то сравнивал проджект менеджмент с управление автомобилем. как-бы четко не устанавливать руль в точке отправки, точно попасть в точку назначения невозможно без постоянного подруливания. вот об этом постоянном "подруливании" менеджеры часто забывают.

любые требования приблизительны. оценки, соответственно, тоже. но при правильном управлении в течении процесса разработки шансы прийти вовремя туда, куда нужно, достаточно высоки.
29th-Jun-2009 09:25 pm (UTC)
Planning Extreme Programming (XP Series) (Paperback)
by Kent Beck, Martin Fowler
http://www.amazon.com/Planning-Extreme-Programming-Kent-Beck/dp/0201710919

первая глава
30th-Jun-2009 04:13 am (UTC)
да, да, да... давно это было, подзабыл :(

к сожалению, знаком с менеджерами, для которых сия мысль - далеко не аксиома
4th-Jul-2009 10:54 am (UTC)
Как управлять рисками --- понятно, но вот с предположениями сложнее. Предположения не всегда можно однозначно обратить в риски, поскольку вероятность многих событий (например, смена ключевого лица заказчика или отваливание разом всей команды) оценить практически невозможно. С больничными или отвлечениями на саппорт, если компании больше 1 года, можно справиться на основании накопленной статистики.
4th-Jul-2009 04:00 pm (UTC)
Оценка рисков и предположений и включение на основе этих оценок какого-то запаса в план - это уже высший класс.

Для большинства проектов, которые мне приходилось наблюдать, простое осознание существования рисков и допущений и готовность реагировать в случае реализации рисков или ошибок в допущениях стало бы большим шагом вперед.

Основная пробелма с допущениями/предположениями - они очень часто не осознанны.
6th-Jul-2009 07:43 am (UTC)
ИМХО, неосознание рисков --- это полная профнепригодность менеджера. Если менеджер не в курсе про управление ожиданиями, рисками и бюджетом, то он может выполнить проект лишь случайно :-)
18th-Jul-2009 09:25 am (UTC)
Не понимаю как такое может быть - именно на вашем блоге через раз антивирусник ругается, на остальных блогах жж нормально :(
This page was loaded Sep 20th 2017, 5:58 am GMT.