Год назад, когда в коллектив бросились знакомым для всех вопросом, а как вы считаете трудозатраты, мы честно говоря оторопели. Случилось это по простой причине. Было неудобно декомпозировать деятельность на глазах у руководства, а фантазии придумать другую модель тогда еще не было. Как мы выходили из положения.
Как по мне, оценивать задачу тогда было страшно. Это был конфликт между «хочу» и «а как по факту выйдет». Конфликт был по простой причине. Головой понимали все, что задача от сих до сих протянется долго, а отвечать за нее нам. И, самое главное, заинтересованные лица требовали уменьшать срок, а договоренности были только односторонними. Другими словами обязанностей прибавляли, а полномочий — нет. Результат такого конфликта какой? Правильно — не готово в срок, да еще и виноваты. А если разбираться, то необходимыми для исполнения задачи ресурсами (той же аллокацией экспертов) управляют не в твоих интересах.
Как мне удалось побороть этот страх? Разобрался с методологией относительной оценки, что вылилось в изучение книги М. Кона и BABoK. А параллельно всю дорогу пытались с коллегами представить свою работу в виде измеренного сервиса. В итоге, когда подступились к достаточно частной модели оценки задачи, состоящей из порядка 30 входных параметров, стало мне понятно, что так не пойдет. Очень сложно.
Упростить получилось через косвенные показатели «тяжести» проекта. Они вам понравятся, их всего три: простой, тяжелый и средний. Скажите мне, как вы различаете простой и сложный проект? Вам подают документ, вы его изучаете, там своя предметная область, набор информационных систем и интеграций. Вот именно на этом и начал строить модель оценки.
В итоге у меня получилась простая модель, состоящая из нескольких шагов и итераций. Для каждого проекта тропинка оценки будет своя, но приблизительно это можно представить следующим образом:
Для начала знакомимся с входной документацией. У нас основным документом является Бизнес требования. И когда общее количество страниц этого документа достигает более 20, то обычно проект тяжелый. А если аналитик умудрился понятно и полно описать требования в документе до 10 страниц — простой проект. Сама по себе информация сомнительная, но смысл первичной оценки — набрать палитру, спектр, набор рисков по всему пути. Что можно сказать о сложном проекте? Обычно подготовка требований для сложных проектов длится более 3 месяцев. Зная этот факт, вписываю в палитру рисков: Отпуска сотрудников-экспертов, перерывы на праздники, увольнения, болезни и тп. Все это увеличивает аллокацию работ в графике.
На следующем шаге оцениваю количество бизнес-процессов, систем, реализующих эти БП, и общее количество необходимых интеграций между системами. И дальше просто складываю все эти величины, предварительно умножив каждую на свой коэффициент влияния. По пути, получая информацию конкретных системах в панорамной архитектуре, вписываю в палитру рисков специфичные особенности систем, наиболее вероятно влияющие на срок.
Например, участие в архитектуре системы с внешней разработкой, это риск. Участие в решении слишком перегруженного управления, это риск. Появление новых процессов, систем, отсутствие четкой позиции по регуляторным рискам или новизна предметной области, все это риски, которые раздувают оценку.
И напоследок, в процессе разговора с заинтересованными лицами напоминаю им, что относительная оценка это о договоренностях, а не обязательствах. Поэтому счастье испытают только те, кто начнет договариваться. О чем стоит договориться? Вы обязаны договориться о степени загруженности по этой задаче. Полная, наполовину, треть, не важно. Главное дать понять, что надо выбрать график и степень загрузки. Затем показываете расчет календарного срока и ту самую палитру рисков. Дальше все сделают за вас. Опытный планировщик возьмет на вооружение эту информацию и пойдет бороться с источниками рисков.
Но на этом оценка не заканчивается. Остановимся на интересном моменте, обсуждении договоренностей. Как добиться сотрудничества или не добиться, расскажу в другой раз. А вы напишите в комментариях где я не прав. Всем чао!
0 комментариев