Порядок задач, или квадрат риск-приоритет revisited
Одна из самых простых и ценных техник при выборе порядка задач в плане (или состава итераций при time-boxing планировании) является квадрат риск-приоритет.
Я с этой штукой ознакомился в 2000 году в книге Мюррея Кантора OO Project Management with UML. Все предельно просто. Приоритета всего два - 1 (обязательно надо делать, без этого продукт не имеет смысла, не успели - двигаем срок), и 2 (желательно сделать, но если не успели к сроку, то и черт с ним). Далее, Кантор советует указать для каждой задачи риск - опять же, по простой градации, "высокий", "средний", и "низкий". Под риском задачи понимается наша уверенность в точности сроков ее выполнения.
Затем, порядок задач выбирается так:
2. Низкий риск, высокий приоритет - делаем во вторую очередь. Делаем просто потому, что это надо обязательно делать. Все, сделали это - уже хорошо. 1. Высокий риск, высокий приоритет - делаем в первую очередь. Над такими задачами надо обычно много думать, возможно - прототипировать, проектировать или исследовать. Потому, что надо максимум граблей словить в начале проекта, чтобы все коррекции сроков пришлись на начало. 3. Низкий риск, низкий приоритет - делаем в третью очередь, стараемся сделать наверняка и побольше. 4. Высокий риск - низкий приоритет - план обычно составляется так, что это мы делать не успеваем :).
Как видите, это великолепный способ побить работу на этапы-итерации. Однако, здесь есть две проблемы, которые мешают применить данный метод в лоб.
1. У людей вызывает затруднение не только выставить приоритет задачам, но и вообще разбить работу на задачи. Потому, что задача есть определенная активность, и она сама по себе определенного статического приоритета не имеет.
2. После определенной практики, становится понятно, что надо принимать во внимание не только риск и приоритет, но и общие затраты на задачу.
3. Бинарный приоритет - это однако маловато. Хочется больше градаций приоритета, а как их добавить в данное правило - непонятно.
Тем не менее, данное правило сослужило мне отличную службу, и сейчас у меня достаточно опыта, чтобы сделать его еще лучше. Мы исправим эти косяки, и сделаем его еще проще в применении.
Новый квадрат risk-value-cost
Первый косяк разрешается элементарно. У активностей нет статичного приоритета - он в самом деле может меняться по ходу проекта. Однако, у фичей проиритет, во-первых есть, во-вторых - он определяется более просто и понятно, и в третьих - он более статичен, и по ходу проекта меняется редко.
То есть, в квадрате должы стоять фичи, а не задачи (агилистам этот пункт должен быть совершенно очевиден). Что такое фича? Это функциональность, видимая пользователю, которая может быть протестирована. То есть, это такая штука, относительно которой вы можете дать инструкции тестерам, как это проверять.
Относительно фичи довольно просто сказать, насколько она полезна пользователю. При желании, можно даже экономический эффект посчитать от каждой фичи, основываясь на прогнозе ее целевой аудитории. Собственно, составлять план от единиц тестирования - это как раз тот подход, который я всегда рекомендовал.
Так что забываем о задачах-активностях, и ставим в квадрат фичи - то, что может быть протестировано, и имеет ценность для пользователя.
Теперь насчет затрат. Есть другой метод определения порядка работ, который применяется при определении порядка работ при поддержке ПО и исправлении дефектов. Он называется value/cost. Идея очень проста - сделать все невозможно, поэтому надо стараться делать то, что приносит максимум value, имея минимальные затраты (cost) на реализацию. Штоб КПД наших усилий был выше.
А вот теперь - к делу. Мы "склеим" оба метода в один, очень простой, применив один элемент техники оценки трудозатрат, впервые появившийся в PERT Estimation. Речь идет о том, что давать одну оценку срока/трудозатрат нерационально, да и вообще - попросту обман. Правильнее оценивать ожидаемый коридор завершения задачи - "раньше точно не справлюсь", и "за такое время точно успею".
Идея PERT Estimation состоит в том, что прогноз срока завершения задачи - есть случайная величина, у которой есть матожидание и дисперсия. Матожидание имеет смысл "среднего" времени завершения задачи, в то время как дисперсия отражает риск задачи.
Уникальность PERT Estimation состоит в том, что это единственный метод, позволяющий перевести эфемерное понятие "риска" в вариацию срока. А также в том, что этим свойством PERT почти никто не пользуется :). Вот, сейчас оно нам пригодится. Только формулы PERT мы не возьмем - мы просто будем оценивать для каждой фичи вариацию трудозатрат - то есть дадим пару оценок минимум (L)-максимум (H), и все.
А вот теперь - внимание. Новый квадрат "risk-value-cost".
2.Все остальные фичи, с максимальным customer value, помеченные как необходимый минимум. То есть, среди группы обязательных фич, порядок выполнения по убыванию H-L. Здесь мы следуем квадрату риск приоритет. 1. Все фичи, с максимальным customer value, помеченные как необходимый минимум, имеющие максимальное значение риска (H-L). 3. А вот теперь все прочие фичи, не помеченные как необходимые, делаются в порядке убывания value/H. Таким образом, мы одновременно учитываем как риск, так и cost - обе величины заложены в оценку H. 4. Это, так же как и в случае квадрата риск-приоритет - кандидаты на исключение из плана. Зачем делать ненужные никому фичи, которые к тому же могут занять много времени?
Обратите внимание на один момент - теперь вы не ограничены бинарной шкалой приоритета-value. Вы можете иметь несколько градаций value в группе необязательных фич, и в этом случе порядок их реализации будет по убыванию value/H.
С этим правилом у вас перестанет разрывать мозг при выборе порядка реализации фич, планировании итераций, разбиения проектов на этапы, в том числе и в случае поддержки ПО - когда вы планируете релизы с исправлениями дефектов и добавлением новых фич.
Оставайтесь с нами :). Мы превращаем менеджмент из исскуства в технологию, снимая с него ореол мистики, и предпочитая краткие методички бессмысленным толстым талмудам. Пользуйтесь на здоровье :) Удачного планирования.
ps: вообще, у правила Кантора есть серьезное преимущество перед моим. А именно - Кантор не вынуждает вас проводить оценку трудозатрат. Поэтому, его правило можно применять на более раннем этапе проекта, чем мое. И я сам до сих пор часто пользуюсь Канторовским правилом на раннем этапе, применяя свое для уточнения плана. Более того, если трудозатраты для реализации фич примерно одинаковы, а при большом их числе вполне можно так считать, то правило Кантора гораздо проще и практичнее моего. Вот так. Хотя, если оценивать трудозатраты не точно, а по шкале, скажем, "меньше недели", "меньше месяца", "меньше квартала", то можно обойти эту сложность. Но, тогда опять же становится не понятно, как оценивать риски.