По статистике, около 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’ами для оценки и ведения ваших проектов.
А как вы оцениваете ваши проекты?
Автор: krokhmalyuk
