Про estimation
Закончил читать Software Estimation от Стива МакКоннела. Надо сказать, что книги Стива наряду с Томом ДеМарко и Джерри Вайнбергом оказали ключевое влияние на мое формирование как менеджера. Rapid Development вообще была первой книгой по менеджементу, которую я прочитал от корки до корки, что учитывая мой тогдашний английский и 650 страниц текста было мальньким подвигом.
Software Estimation состоит из 23 частей, большинство из которых посвящено различным техникам. Прочитать её стоит, однако, хотя-бы ради первой и последней части.
Первая часть определяет estimation, его отличие от target и commitment и его вероятностный характер. В начале проекта невозможно точно *оценить* сколько займёт проект. Любые оценки позволяют оценить диапазон и примерную вероятность завершения работы к той или иной дате из этого диапазона. Точность оценки увеличивается по мере развития проекта. То, чего обычно добиваются менеджеры от подчинённых - это не оценка - это коммитмент на выполнение той или иной цели. Целью может быть "выпуск следующей версии к JavaOne со всеми фичами", например. Руководствуясь имеющимися в его распоряжении оценками подчинённый может взять на себя коммитмент, учитывающий вероятностный характер оценки. Например, "со всеми фичами к JavaOne мы сможем выпустить продукт с 10% вероятностью.
Последняя часть затрагивает политический аспект estimation и рекомендации по ведению переговоров. В частности, критикуется отношение к обсуждению estimation, как к переговорам. Приведу цитату:
"Переговоры происходят между сторонами, имеющими конкурирующие интересы. Цель переговоров - поделить пирог между ними. В конкурентных переговорах каждая сторона стремиться получить как можно больший кусок пирога и что-бы не получила одна сторона - другая сторона теряет. При дружественных переговорах стороны совместно ищут способ сделать пирог больше, но в конце концов он все-равно оказывается поделён.
При переговорах по поводу сроков выпуска софта нет пирога, который надо поделить. При обсуждении сроков с маркетингом, сейлзами и экзекьютивами вопрос не стоит о том, кто выиграет и кто проиграет - либо выиграют все, либо проиграют все. Поэтому обсуждение estimation-ов - это не переговоры, это совместный поиск решения проблемы."
В вышеприведённом примере, проблема, которую следует решить, выглядит так "выпустить к JavaOne с вероятностью больше 90% продукт, содержащий как можно больше возможностей", решением проблемы будет список фич, относительно которых это возможно.
Все это теоретически прекрасно. Но вот сам же Стив пишет: "Многие технари считают, что дискуссии с менеджментом по поводу оценок и целей (направленные на их уменьшение) могут повредить карьере", поскольку "экзекьютевы агрессивны по натуре, они и экзекьютевами стали поэтому". Он дальше пишет, что его опыт показывает обратное - способность и умение вести не комфортные дискуссии, демонстрируя при этом, что вы в первую очередь защищаете интересы организации, способствуют карьере. Есть, однако, два "но".
Во-первых, да, способствуют, если ваш менеджер не идиот. И если вокруг нет желающих выглянуть у вас из-за спины с более агрессивным коммитментом. Я знаю очень немного менеджеров, которые имея перед собой более и менее агрессивный коммитмент выбрали бы второй.
Во-вторых, возможно умение вести конструктивную дискуссию способствует карьере. Но агрессивные коммитменты - особенно если потом повезёт и результат попадёт в 10 процентов - способствуют ей гораздо больше. Поэтому желающие выглянуть очень часто есть - особенно в большой организации. Причём, совершенно не обязательно они подлецы и лгуны. Возможно они молоды, полны энтузиазма и пусты в смысле опыта. И действительно уверены, что вот этот вот продукт со всеми фичами можно сделать к JavaOne. Надо только немного поработать по ночам. И по выходным. И вот ещё двух человек добавить. И все будет Ok. Сам таким был по молодости, чего уж там. И не могу сказать, что моей карьере это повредило - нет, помогло.
Так что не все просто, в смысле стратегии поведения. Но во всяком случае понимать, что именно происходит, что делаете вы и люди вокруг вас - необходимо.
Для формирования этого понимания книжка очень хорошая. Рекомендую.
Software Estimation состоит из 23 частей, большинство из которых посвящено различным техникам. Прочитать её стоит, однако, хотя-бы ради первой и последней части.
Первая часть определяет estimation, его отличие от target и commitment и его вероятностный характер. В начале проекта невозможно точно *оценить* сколько займёт проект. Любые оценки позволяют оценить диапазон и примерную вероятность завершения работы к той или иной дате из этого диапазона. Точность оценки увеличивается по мере развития проекта. То, чего обычно добиваются менеджеры от подчинённых - это не оценка - это коммитмент на выполнение той или иной цели. Целью может быть "выпуск следующей версии к JavaOne со всеми фичами", например. Руководствуясь имеющимися в его распоряжении оценками подчинённый может взять на себя коммитмент, учитывающий вероятностный характер оценки. Например, "со всеми фичами к JavaOne мы сможем выпустить продукт с 10% вероятностью.
Последняя часть затрагивает политический аспект estimation и рекомендации по ведению переговоров. В частности, критикуется отношение к обсуждению estimation, как к переговорам. Приведу цитату:
"Переговоры происходят между сторонами, имеющими конкурирующие интересы. Цель переговоров - поделить пирог между ними. В конкурентных переговорах каждая сторона стремиться получить как можно больший кусок пирога и что-бы не получила одна сторона - другая сторона теряет. При дружественных переговорах стороны совместно ищут способ сделать пирог больше, но в конце концов он все-равно оказывается поделён.
При переговорах по поводу сроков выпуска софта нет пирога, который надо поделить. При обсуждении сроков с маркетингом, сейлзами и экзекьютивами вопрос не стоит о том, кто выиграет и кто проиграет - либо выиграют все, либо проиграют все. Поэтому обсуждение estimation-ов - это не переговоры, это совместный поиск решения проблемы."
В вышеприведённом примере, проблема, которую следует решить, выглядит так "выпустить к JavaOne с вероятностью больше 90% продукт, содержащий как можно больше возможностей", решением проблемы будет список фич, относительно которых это возможно.
Все это теоретически прекрасно. Но вот сам же Стив пишет: "Многие технари считают, что дискуссии с менеджментом по поводу оценок и целей (направленные на их уменьшение) могут повредить карьере", поскольку "экзекьютевы агрессивны по натуре, они и экзекьютевами стали поэтому". Он дальше пишет, что его опыт показывает обратное - способность и умение вести не комфортные дискуссии, демонстрируя при этом, что вы в первую очередь защищаете интересы организации, способствуют карьере. Есть, однако, два "но".
Во-первых, да, способствуют, если ваш менеджер не идиот. И если вокруг нет желающих выглянуть у вас из-за спины с более агрессивным коммитментом. Я знаю очень немного менеджеров, которые имея перед собой более и менее агрессивный коммитмент выбрали бы второй.
Во-вторых, возможно умение вести конструктивную дискуссию способствует карьере. Но агрессивные коммитменты - особенно если потом повезёт и результат попадёт в 10 процентов - способствуют ей гораздо больше. Поэтому желающие выглянуть очень часто есть - особенно в большой организации. Причём, совершенно не обязательно они подлецы и лгуны. Возможно они молоды, полны энтузиазма и пусты в смысле опыта. И действительно уверены, что вот этот вот продукт со всеми фичами можно сделать к JavaOne. Надо только немного поработать по ночам. И по выходным. И вот ещё двух человек добавить. И все будет Ok. Сам таким был по молодости, чего уж там. И не могу сказать, что моей карьере это повредило - нет, помогло.
Так что не все просто, в смысле стратегии поведения. Но во всяком случае понимать, что именно происходит, что делаете вы и люди вокруг вас - необходимо.
Для формирования этого понимания книжка очень хорошая. Рекомендую.