?

Log in

No account? Create an account
Andrei Ivanov
Про estimation 
1st-Jun-2009 03:05 pm
JetBrains
Закончил читать Software Estimation от Стива МакКоннела. Надо сказать, что книги Стива наряду с Томом ДеМарко и Джерри Вайнбергом оказали ключевое влияние на мое формирование как менеджера. Rapid Development вообще была первой книгой по менеджементу, которую я прочитал от корки до корки, что учитывая мой тогдашний английский и 650 страниц текста было мальньким подвигом.
Software Estimation состоит из 23 частей, большинство из которых посвящено различным техникам. Прочитать её стоит, однако, хотя-бы ради первой и последней части.

Первая часть определяет estimation, его отличие от target и commitment и его вероятностный характер. В начале проекта невозможно точно *оценить* сколько займёт проект. Любые оценки позволяют оценить диапазон и примерную вероятность завершения работы к той или иной дате из этого диапазона. Точность оценки увеличивается по мере развития проекта. То, чего обычно добиваются менеджеры от подчинённых - это не оценка - это коммитмент на выполнение той или иной цели. Целью может быть "выпуск следующей версии к JavaOne со всеми фичами", например. Руководствуясь имеющимися в его распоряжении оценками подчинённый может взять на себя коммитмент, учитывающий вероятностный характер оценки. Например, "со всеми фичами к JavaOne мы сможем выпустить продукт с 10% вероятностью.

Последняя часть затрагивает политический аспект estimation и рекомендации по ведению переговоров. В частности, критикуется отношение к обсуждению estimation, как к переговорам. Приведу цитату:
"Переговоры происходят между сторонами, имеющими конкурирующие интересы. Цель переговоров - поделить пирог между ними. В конкурентных переговорах каждая сторона стремиться получить как можно больший кусок пирога и что-бы не получила одна сторона - другая сторона теряет. При дружественных переговорах стороны совместно ищут способ сделать пирог больше, но в конце концов он все-равно оказывается поделён.
При переговорах по поводу сроков выпуска софта нет пирога, который надо поделить. При обсуждении сроков с маркетингом, сейлзами и экзекьютивами вопрос не стоит о том, кто выиграет и кто проиграет - либо выиграют все, либо проиграют все. Поэтому обсуждение estimation-ов - это не переговоры, это совместный поиск решения проблемы."
В вышеприведённом примере, проблема, которую следует решить, выглядит так "выпустить к JavaOne с вероятностью больше 90% продукт, содержащий как можно больше возможностей", решением проблемы будет список фич, относительно которых это возможно.

Все это теоретически прекрасно. Но вот сам же Стив пишет: "Многие технари считают, что дискуссии с менеджментом по поводу оценок и целей (направленные на их уменьшение) могут повредить карьере", поскольку "экзекьютевы агрессивны по натуре, они и экзекьютевами стали поэтому". Он дальше пишет, что его опыт показывает обратное - способность и умение вести не комфортные дискуссии, демонстрируя при этом, что вы в первую очередь защищаете интересы организации, способствуют карьере. Есть, однако, два "но".
Во-первых, да, способствуют, если ваш менеджер не идиот. И если вокруг нет желающих выглянуть у вас из-за спины с более агрессивным коммитментом. Я знаю очень немного менеджеров, которые имея перед собой более и менее агрессивный коммитмент выбрали бы второй.
Во-вторых, возможно умение вести конструктивную дискуссию способствует карьере. Но агрессивные коммитменты - особенно если потом повезёт и результат попадёт в 10 процентов - способствуют ей гораздо больше. Поэтому желающие выглянуть очень часто есть - особенно в большой организации. Причём, совершенно не обязательно они подлецы и лгуны. Возможно они молоды, полны энтузиазма и пусты в смысле опыта. И действительно уверены, что вот этот вот продукт со всеми фичами можно сделать к JavaOne. Надо только немного поработать по ночам. И по выходным. И вот ещё двух человек добавить. И все будет Ok. Сам таким был по молодости, чего уж там. И не могу сказать, что моей карьере это повредило - нет, помогло.
Так что не все просто, в смысле стратегии поведения. Но во всяком случае понимать, что именно происходит, что делаете вы и люди вокруг вас - необходимо.

Для формирования этого понимания книжка очень хорошая. Рекомендую.
Comments 
1st-Jun-2009 12:38 pm (UTC)
При переговорах по поводу сроков выпуска софта нет пирога, который надо поделить.
[..]
Поэтому обсуждение estimation-ов - это не переговоры, это совместный поиск решения проблемы


А какие могут быть решения, не связанные с отрезанием пирога у кого-нибудь?

Программисты работают больше - забираем кусок у программистов

Добавляем больше ресурсов - забираем кусок у других проектов

Удаляем фичи, растягиваем сроки - забираем кусок у sales/marketing

1st-Jun-2009 12:44 pm (UTC)
Автор исходит из предположения, что пирог появляется в момент релиза. Таким образом, если по той или иной причине продукт не вышел, то никто не получает ничего. В том же, чтобы найти компромисс между сроками/функциональностью заинтересованны все.

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

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

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

Идея в том, что оценка (в отличии от коммитментов) - это вообще не тема для переговоров. Сейлзы-маркетинг-экзекьютивы должны принимать ее как факт. Дискуссия возможно о скопе (меньше фич), о рисках (мы понимаем, что с 90% вероятностью мы не получим ничего, но идем на этот риск), но не о результатах оценки.

Edited at 2009-06-01 12:47 pm (UTC)
2nd-Jun-2009 04:19 am (UTC)
Из человека, который обещает estimate Х и стопроцентно укладывается в сроки, и человека, который обещает Х-N и укладывается в сроки с вероятностью меньше 80%, я всегда выберу первого. А так же и за гарантированный премиум в качестве можно много сроков отдать.
2nd-Jun-2009 01:00 pm (UTC)
Я тоже, как правило. Но исключения бывают.
17th-Jul-2009 02:37 pm (UTC)
Журнальчик прикольный у вас, можно было бы уже и на собственный домен перебираться
This page was loaded Oct 19th 2017, 7:00 am GMT.