?

Log in

No account? Create an account
Andrei Ivanov
Про estimation-2 
5th-Jun-2009 06:06 pm
JetBrains
В предыдущем посте я поделился радостью от прочитанной книжки и немного пересказал содержание. Надо, однако, сказать, что изложенный в этой книжке классический порядок "сбор требований->оценка требований->планирование->трекинг->корректировка требований, их оценки и плана по мере получения новой информации->релиз в запланированное время" я наблюдал за 20 лет своей карьеры считанное число раз. Как правило, хаоса было гораздо больше. При этом очень часто участники проекта уверены в том, что на самом деле они все делают правильно. Потому, что упомянутые этапы успешно имитируются:

1) Имитация сбора требований:
-- Клонируйте продукт X - это была любимая постановка задачи Дитрихом. Такая постановка задачи не исключает, теоретически, сбора требований, поскольку продукт X можно разобрать на требования. Но этим никто и никогда в такой постановке задачи не занимался - зачем тратить время - смотри и копируй. Понятно, что по таким "требованиям" ни последующая оценка, ни планирование при таких "требованиях" невозможны и заменяются соответствующими имитациями.
-- Выпустите релиз к июню, никаких новых фич но пофиксите все баги и реализуйте все запросы на улучшения в трекере! (никто не считал эти баги и запросы, сколько их и можно ли их пофиксить к июню)
-- Сделайте мне хороший сайт (реализуйте поддержку UML 2.0)!

2) Имитация оценки
-- Подмена оценки целью или коммитментом: "Нам нужен этот релиз к JavaOne, я думаю мы сможем все успеть", "Вася, ты за сколько ты берешься сделать этот релиз? Я уже пообещал его к JavaOne нашему VP!"
-- "Экспертная" оценка. У самого опытного разработчика спрашивают, сколько как ему кажется потребуется, чтобы сделать "хороший сайт" или "склонировать продукт X". Самый опытный разработчик говорит - год! Оценка готова.
-- "Оценка" руководителем того, что делать будут подчинённые. "Я уверен, что все это можно сделать до JavaOne! Вы плохие программисты, если у вас это не получится!"

3) Имитация планирования
-- Менеджер рисует красивый гант-чарт где каждый разработчик делает свою подсистему все время релиза. Вопросов разработчикам про оценки не задаётся.
-- "Планом" называется коммитмент. Мы сделаем эту подсистему в этом квартале!

4) Имитация трекинга и внесения поправок
-- Мы не смогли сделать этот продут в этом квартале, но мы ТОЧНО сделаем его в следующем
-- Первый этап занял полгода, хотя планировался на месяц -ничего, мы наверстаем потом
-- Первый этап занял полгода, хотя планировался на месяц - так уж и быть, сдвинем релиз на пять месяцев

Этот, очень ограниченный, набор примеров взят не из жизни стартапа организованного двумя студентами, нет, я видел все это в разных больших и известных конторах, в которых или с которыми доводилось работать. При этом, не сказать, что все это заканчивалось катастрофами. Продукт X клонировался - пусть в совершенно не предсказуемый момент, но рано или поздно и так, что всем нравилось. Релиз "к июню без новых фич но со всеми исправленными багами и запросами на улучшение" выходил в декабре, с новыми фичами и еще большим числом багов, но ко всеобщему удовольствию. Продукт, который "должен ТОЧНО быть готов в этом квартале" в конце-концов выходил после 5-6 таких кварталов. Коммитменты превращались в "правильные" оценки - за счёт большого числа рабочих уикендов и ночей. "Эксперты" иногда угадывали.

Тут, конечно, следует учитывать специфику моего опыта. Львинная его доля - даже во времена SwiftTeams-а пришлась на ресерч проекты и изготовление собственных продуктов. Где предсказуемость была гораздо менее важна, чем инновации и гибкость. Там, где работа была скорее работой на заказ, и где требовалась именно предсказуемость и "встреча с ожиданиями" (как перевести meet expectations?), все делалось по правилам гораздо чаще и отклонение от них заканчивалось хуже.
Comments 
5th-Jun-2009 03:56 pm (UTC)
Кстати, про estimation сроков завершения проекта. Не знаете, как вот эта проблема
http://maximkr.livejournal.com/17641.html
решается ? Должно же этому быть какое-то разумное объяснение :-)


6th-Jun-2009 09:00 am (UTC)
Интересными вещами вы занимаетесь -) Можно, наверное, посмотреть как к этому относятся существующие estimation инструменты - вот тут подборка ссылок.

Я, однако, не очень верю в полезность слишком большой точности оценок. Во-первых, точность больше аккуратности - бесполезна. Во-вторых, проект после начальной оценки управляется по мере поступления данных и оценка уточняется. В-третьих, проекты, в которых команда удосужилась разбить все на подзадачи, оценить подзадачи диапазоном, предъявить суммарную оценку начальству и быть услышанна уже в лучшем положении, чем 99% компаний.

А по поводу математики... Вот есть еще одна проблема - diseconomies of scale называется. Яша Сироткин на бытовом уровне описал ее недавно. Умные дяди придумали математику и для нее тоже - есть она у вас в инструменте? -)
6th-Jun-2009 07:41 pm (UTC)
Ага, спасибо, ссылки посмотрю.

У нас в инструменте планирования нет вообще - это в чистом виде issue tracking, не project management. Вот тут я писал, почему планировать на основе инфрормации из issue tracking-а нельзя (и неправильно):
http://www.trackstudio.ru/forum/bug-tracking-project-management-issue-tracking-issue-1685.html

А вот тут про методику estimation одного из конкурентов, которая вряд ли будет работать:
http://maximkr.livejournal.com/11192.html

Последний пост про вид распределения - это даже не про точность оценок, а про ненаучность планирования вообще (если там ошибок не найду) :-) Распределение не является нормальным, при увеличении количества задач в проекте дисперсия даты завершения растет вплоть до бесконечности.

С фондовым рынком та же история: существующая теория оптимизации портфелей предполагает, что изменения цен активов распределены по нормальному закону и оценивает риски на основе исторических данных. Но если бы распределение в самом деле было нормальным, то кризисы случались бы раз в миллиард лет или около того :-) Т.е. и в этой предметной области вероятность "выбросов" существенна и они труднопредсказуемы.

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

Решение - делать упор не на предсказание "когда мы закончим проект", а заранее допускать совсем невероятные ситуации и планировать действия и для таких случаев тоже. Даже если теоретически модели (основанные на нормальном распределении) говорят, что ТАК пролететь по срокам невозможно :-)
5th-Jun-2009 09:18 pm (UTC)
Понравились примеры из первой части. Причём, не частными чертами, а общей: нежеланием сесть с листочком бумажки, спокойно подумать и посчитать. Трясти надо! На следующих этапах уже политика начинается, там злобные силы нас вяло гнетут. Но вначале-то люди сами впрягаются.
6th-Jun-2009 05:53 am (UTC)
заметил что если проекты организованы плохо и через задницу, а руководят ими дебилы и отморозки, то это не от того что человеческая природа такая и не свезло в конкретной точке вселеной, но исключительно из-за того что этот проект включен в систему диктующую именно такой стиль и управленцы тоже в данном случае неслучайны
6th-Jun-2009 09:07 am (UTC)
По разному бывает -) Качественный дебил и отморозок в данной конкретной точке пространства-времени может побороть правильную систему. Еще бывают дебилы и отморозки, которые систему эксплуатируют, то есть творят беспредел не потому, что системе это нужно, а потому, что система это позволяет.

Edited at 2009-06-06 09:08 am (UTC)
6th-Jun-2009 09:15 am (UTC)
путь дебила и отморозка - долгий путь невыложенный цветами, как правило дебил и отморозок это не частный случай или отклонение но плод долгосрочной усиленной работы множества людей и целых коллективов :) .. имхо система врядли нейтральная вещь, она скорее на каком то уровне именно заинтересована в порождении дебила и отморозка в данной конкретной точке пространства и проекта и иногда думаю что в этом есть какая то метафизика и наверное обладая полной информацией можно отслеживать и начало и конец этого процесса, но так как мы редко обладаем полной информацией, то нам кажется что эта точка случайно возникает в нашем измерении, а на деле это линия с которой мы пересеклись из другого нам недоступного и неучитываемого соответственно :)
This page was loaded Nov 24th 2017, 2:50 pm GMT.