?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Порядок задач, или квадрат риск-приоритет revisited

Posted on 2009.01.29 at 17:49
Tags: , ,

Одна из самых простых и ценных техник при выборе порядка задач в плане (или состава итераций при  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: вообще, у правила Кантора есть серьезное преимущество перед моим. А именно - Кантор не вынуждает вас проводить оценку трудозатрат. Поэтому, его правило можно применять на более раннем этапе проекта, чем мое. И я сам до сих пор часто пользуюсь Канторовским правилом на раннем этапе, применяя свое для уточнения плана. Более того, если трудозатраты для реализации фич примерно одинаковы, а при большом их числе вполне можно так считать, то правило Кантора гораздо проще и практичнее моего. Вот так. Хотя, если оценивать трудозатраты не точно, а по шкале, скажем, "меньше недели", "меньше месяца", "меньше квартала", то можно обойти эту сложность. Но, тогда опять же становится не понятно, как оценивать риски.


Comments:


shalayev
shalayev at 2009-01-29 16:57 (UTC) (Link)
Хорошая статья.
Один момент достаточно расплывчат - определение той самой ценности отдельно взятой фичи..
Gaperton
gaperton at 2009-01-30 13:02 (UTC) (Link)
Есть несколько вариантов. Примеры:
А) Имеет смысл, если мы делаем продукт
Определяем целевую аудиторию продукта, кто будем им пользоваться, какую проблему или потребность удовлетворяет продукт. Выписываем его свойства-фичи, и вводим три приоритета для них:
1. Без данного свойства продукт никому не нужен, так как заявленную потребность не удовлетворяет. Обычно - базовое свойство, которым постоянно пользуется подавляющая часть целевой аудитории. Эти фичи - основная суть продукта. Если мы не успеваем сделать данные фичи - мы переносим срок сдачи проекта.
2. Без данного свойства целевая аудитория продукта станет заметно меньше, и его потребительские свойства заметным образом ухудшатся. То есть, заявленную потребность он удовлетворит, но не в полном объеме. Обычно, это важные свойства, которые нужны существенному количеству (50% +-) целевой аудитории, и которыми аудитория регулярно пользуется. Потерять такую фичу будет больно и обидно, но не смертельно. Мы не переносим срок проекта из-за того, что не успели сделать данные фичи, они двигаются на следующую итерацию. Однако, мы стараемся успеть сделать их как можно больше.
3. Отсутствие данного свойства не повлияет существенным образом на продажи. Обычно, это либо косметика и вопросы usability, либо дефекты, для которых есть workaround, либо фичи ценные и полезные, но нужные небольшому проценту аудитории или большому, но пользуются ими редко. Эти фичи включаются в план при условии, что затраты на их реализацию невелики, и именно эти фичи обычно идут в жертву в первую очередь (разве что они не очень-преочень дешевы в реализации).

Я описал качественный подход. Его можно превратить в количественный, рассчитав прогноз объема рынка в штуках и деньгах для каждой фичи или группы фич. Но это уже совершенно другая задача, и компетенция скорее стратегического маркетинга, чем управления проектами.
android##paranoid
baz_a at 2013-09-24 20:03 (UTC) (Link)
В тему квадрата Кантора.
Не могу удержаться не привести цитату из А.П. Чехова.

“На этом туннеле превосходно сказалась склонность русского человека тратить последние средства на всякого рода выкрутасы, когда не удовлетворены самые насущные потребности.”

Чехов. Остров Сахалин.
Previous Entry  Next Entry