Создание системы управления проектами на Yandex Tolstoy Camp. Часть 2
По статистике, около 50% IT-проектов выходят за бюджет, время или не полностью оправдывают ожидания заказчиков. Среди прочих причин — недостатки в процессе управления, размытие границ проекта (в частности, из-за недостатка контроля этих границ) и отсутствие учета рисков проекта. Эти проблемы мы поднимали в нашей прошлой статье.
Если хотите узнать, как мы в e-Legion боремся с этими проблемами и делаем проекты успешными, добро пожаловать под кат.
Цена проектаПримечание: опытным управленцам этот раздел может показаться капитанством. Если у вас появляется такое ощущение, просто перейдите к следующему разделу =)Начнем с понимания того, из чего складывается цена проекта, которую студия выставляет заказчику. Описанное ниже верно для всех компаний, занимающихся разработкой на заказ.
Стоимость работ — оценка требуемых на проекте работ в часах, умноженная на стоимость часа. Обычно отдельно считается стоимость аналитики и дизайна, разработки и тестирования. В среднем проекте составляет 60–70%. Маржа — собственно, заработок нашей компании. В среднем по рынку маржа планируется на уровне 20–40% (без учета рисков), но зачастую по результатам проекта оказывается меньше из-за недооценки рисков. Часто часть маржи резервируется под риски. Если мы знаем, что в среднем в проектах мы ошибаемся с оценками на 10%, логично заранее учесть эту ошибку и немного повысить цену для клиента, чтобы не терять свою прибыль. В среднем риски по проекту закладываются на уровне 10–20% (в дополнение к 20–40% маржи). Понятно, что цена имеет ограничение сверху — цена конкурентов, сколько вообще готов потратить заказчик. Как можно влиять на цену? Стоимость работ напрямую зависит от их объема (то, что попросил сделать заказчик — объективно неуменьшаемый параметр) и ценой часа (которая зависит от многих факторов, описание которых выходит за рамки данной статьи и которые, по сути, тоже не могут быть изменены в рамках одного проекта, а только в рамках всей организации). Маржа — в принципе, для перспективного заказчика первый проект может быть с нулевой или даже отрицательной маржой (т.е. убыточным для компании). Но вообще любая компания хочет зарабатывать деньги и маржой делиться не хочет. Риски можно разделить на две части: фиксированную, которая зависит от организации, клиента, проекта, разработчиков, которые будут работать над проектом, возможных болезней сотрудников и т.д., и на «риски незнания», которые отражают то, что на момент оценки обычно велика неопределенность — нет точных требований, непонятны детали реализации и т.д. Из описанного выше, уменьшение неопределенности выглядит самым легким фактором для изменения. Давайте займемся им.Оценка проекта Как уменьшить неопределенность? Выяснить требования заказчика, понять, из каких компонентов будет состоять система и какие функции она будет выполнять. Чем больше мы подумаем над проектом заранее, тем меньше вероятность того, что в ходе проекта появятся новые задачи, которые придется выполнять за свой счет.В ходе оценки не стоит забывать, что сама оценка тоже не бесплатна. В среднем оценка пришедшего от заказчика проекта занимает от 2-х часов до 1 недели и требует привлечения разработчиков, аналитиков и тестировщиков. Таким образом, оценка одного проекта для компании стоит примерно от 10 до 100 человеко-часов! С учетом того, что не каждый оцененный проект продается, затраты компании достигают немаленьких величин.
Наше решение
Мы решили попробовать использовать Mind map (диаграммы связей) для составления структуры проекта и их оценки: 
Центральный элемент Mind map«а — название проекта. Его дочерние элементы — компоненты будущей системы (для мобильного приложения — экраны; можно использовать пользовательские сценарии или другие понятные заказчику компоненты). Далее для каждого экрана записываются его основные функции. Общие компоненты (например, диалоговые окна) рано или поздно выносятся в отдельный родительский элемент первого уровня. Не тратя больше времени и не применяя каких-то секретных навыков, команда оценщиков получает куда более детализированную карту будущего приложения. Уровень детализации получается такой, что самые последние элементы Mind map«а редко имеют оценку более 4–8 часов.
Если точную оценку по какому-либо элементу дать не получается, мы можем добавить некоторый элемент, отражающий риск:
Заказчику дается детализация оценки на уровне самых первых дочерних элементов. Эти элементы отражают некоторые бизнес-компоненты (use case, экран приложения) и поэтому понятны заказчикам.
Что самое интересное, в ходе проекта выяснилось, что эта карта еще и куда более точная — количество неожиданных задач сильно снизилось (точные цифры — в конце статьи).
Ход проекта Допустим, проект продан и пора его реализовывать. В этот момент многие делают ошибку и теряют связь между элементами приложения, которые были определены в ходе оценки и проданы заказчику, и задачами, которые заводятся в таск-трекере. А многие такой ошибки не делают =) и, все равно, тратят много времени на контроль того, что объем работы в таск-трекере соответствует в конце проекта проданной смете. Многие таск-трекеры либо вообще не позволяют организовывать многоуровневые иерархии, либо позволяют сделать это неинтуитивно. Какие проблемы при этом возникали у нас? Из-за потери связи очень сложно понять, что какая-нибудь дополнительная задача, появившаяся в ходе проекта, приводит к превышению «проданной» оценки и мы начинаем реализовывать ее за свой счет. Из-за отсутствия хорошего представления иерархии задач в трекере сложно понять статус готовности той или иной функции (в нашем случае — экрана мобильного приложения). Когда возникает такая необходимость, PM должен вручную просмотреть весь список задач в трекере и понять, есть ли какие-то незаконченные задачи, относящиеся к интересующему нас экрану. Решение И здесь на помощь пришел Mind map. Тот же самый Mind map, который получился при оценке, используется и в разработке — задачи самого нижнего уровня заводятся в трекер и отдаются на выполнение. Зная структуру, PM (и другие участники проекта) легко могут определить, какие задачи находятся под узлом, соответствующим тому или иному экрану. Сам узел содержит информацию о начальной оценке, поэтому PM сразу замечает ее превышение (при появлении новой задачи) и может принять меры.Статус отмечается на «низкоуровневых» задачах — тех, с которыми работают разработчики в трекере — и «транслируется» на более высокие уровни диаграммы. Это позволяет менеджерам проектов и CTO легко видеть статус всего проекта:
серый — к задаче еще не приступали, зеленый — задача готова, желтый — задача в работе, красный — есть какие-то проблемы.
При необходимости, можно быстро понять, чем вызвана та или иная проблема:
Можно применить фильтр по задачам, требующим внимания менеджера:
Дополнительный бонус, которого мы уж никак не ожидали — существенное сокращение затрат на тестирование. Оно объясняется тем, что разработчики видели статус того или иного экрана и старались закончить задачи, связанные с ним, прежде, чем начинать работу над новым экраном (мы передаем приложение на тестирование поэкранно, либо по бизнес-фичам клиента). И если раньше случалось так, что разработчики отправляли на тестирование экраны, по которым оставались незавершенные задачи, то сейчас в тестирование стали поступать целиком завершенные экраны.
Сложная экономика простых чисел Обещанные результаты.В проектах, которые использовали новый подход, были отмечены следующие улучшения:
20% сокращение затрат на тестирование. 50% сокращение превышения изначальных оценок (из-за более точной оценки и контоля превышения оценок). Менеджеры проектов стали тратить на 5–10% (субъективная оценка) меньше времени на контроль команды и за счет этого смогли больше общаться с заказчиком. Как это может сказаться на маржинальности проекта? Давайте предположим, что цена проекта составляет 100 условных единиц. В соответствии со структурой цены, поясненной выше, маржа и риски в таком проекте составляет примерно 30; затраты на разработку — 60; на тестирование — 10. Допустим, выстрелившие риски «съедали» 20 единиц, т.е. реальная маржа составляла всего 10. При снижении рисков на 50% (10 у.е.), а затрат на тестирование — на 20% (2 у.е.), маржа могла бы повыситься с 10 до 22 — т.е. более, чем на 100%! Что дальше? Проверив новый подход на нескольких проектах, мы решили принести свет в массы поделиться своим опытом и автоматизировать наши инструменты и процессы. Для этого несколько добровольцев отправились на Tolstoy Startup Camp и в настоящее время занимаются разработкой системы управления проектами SNAP, которая реализует описанные процессы.Автоматизация пока видится в следующих местах:
Интеграция Mind map с трекером задач — сейчас довольно много времени тратится на поддержание Mind map«а в актуальном состоянии Автоматизация контроля начальных оценок — сейчас менеджеры контролируют это вручную, в будущем при приближении к начальной оценке будут загораться желтые и красные лампочки =) Шаблоны проектов Возможно — база знаний о рисках проекта для ведения статистики и более точного учета рисков А для руководства компании — верхнеуровневое «карта» всего портфеля проектов с своим бюджетом и плюшками вроде планирования ресурсов между проектами. Команда SNAP будет рада ответить на вопросы по поводу примененной методики, и может помочь вам научиться пользоваться Mind map«ами для оценки и ведения ваших проектов.А как вы оцениваете ваши проекты?
