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

А как вы оцениваете ваши проекты?

Автор:

Источник