Создание системы управления проектами на Yandex Tolstoy Camp. Часть 2

    По статистике, около 50% IT-проектов выходят за бюджет, время или не полностью оправдывают ожидания заказчиков. Среди прочих причин — недостатки в процессе управления, размытие границ проекта (в частности, из-за недостатка контроля этих границ) и отсутствие учета рисков проекта. Эти проблемы мы поднимали в нашей прошлой статье.

    image

    Если хотите узнать, как мы в e-Legion боремся с этими проблемами и делаем проекты успешными, добро пожаловать под кат.


    Цена проекта


    Примечание: опытным управленцам этот раздел может показаться капитанством. Если у вас появляется такое ощущение, просто перейдите к следующему разделу =)

    Начнем с понимания того, из чего складывается цена проекта, которую студия выставляет заказчику. Описанное ниже верно для всех компаний, занимающихся разработкой на заказ.
    • Стоимость работ — оценка требуемых на проекте работ в часах, умноженная на стоимость часа. Обычно отдельно считается стоимость аналитики и дизайна, разработки и тестирования. В среднем проекте составляет 60-70%.
    • Маржа — собственно, заработок нашей компании. В среднем по рынку маржа планируется на уровне 20-40% (без учета рисков), но зачастую по результатам проекта оказывается меньше из-за недооценки рисков.
    • Часто часть маржи резервируется под риски. Если мы знаем, что в среднем в проектах мы ошибаемся с оценками на 10%, логично заранее учесть эту ошибку и немного повысить цену для клиента, чтобы не терять свою прибыль. В среднем риски по проекту закладываются на уровне 10-20% (в дополнение к 20-40% маржи).

    Понятно, что цена имеет ограничение сверху — цена конкурентов, сколько вообще готов потратить заказчик. Как можно влиять на цену?

    • Стоимость работ напрямую зависит от их объема (то, что попросил сделать заказчик — объективно неуменьшаемый параметр) и ценой часа (которая зависит от многих факторов, описание которых выходит за рамки данной статьи и которые, по сути, тоже не могут быть изменены в рамках одного проекта, а только в рамках всей организации).
    • Маржа — в принципе, для перспективного заказчика первый проект может быть с нулевой или даже отрицательной маржой (т.е. убыточным для компании). Но вообще любая компания хочет зарабатывать деньги и маржой делиться не хочет.
    • Риски можно разделить на две части: фиксированную (зависит от организации, клиента, проекта, разработчиков, которые будут работать над проектом, возможных болезней сотрудников и т.д.) и на «риски незнания» (которые отражают то, что на момент оценки обычно велика неопределенность — нет точных требований, непонятны детали реализации и т.д.).

    Из описанного выше видно, что уменьшение неопределенности выглядит самым легким фактором для изменения. Давайте займемся им.

    Оценка проекта


    Как уменьшить неопределенность? Выяснить требования заказчика, понять, из каких компонентов будет состоять система и какие функции она будет выполнять. Чем больше мы думаем над проектом заранее, тем меньше вероятность того, что в ходе проекта появятся новые задачи, которые придется выполнять за свой счет.

    В ходе оценки не стоит забывать, что сама оценка тоже не бесплатна. В среднем оценка пришедшего от заказчика проекта занимает от 2-х часов до 1 недели и требует привлечения разработчиков, аналитиков и тестировщиков. Таким образом, оценка одного проекта для компании стоит примерно от 10 до 100 человеко-часов! С учетом того, что не каждый оцененный проект продается, затраты компании достигают немаленьких величин.

    Наше решение


    Мы решили попробовать использовать Mind map (диаграммы связей) для составления структуры проекта и их оценки:

    image

    Центральный элемент Mind map’а — название проекта. Его дочерние элементы — компоненты будущей системы (для мобильного приложения — экраны; можно использовать пользовательские сценарии или другие понятные заказчику компоненты). Далее для каждого экрана записываются его основные функции. Общие компоненты (например, диалоговые окна) рано или поздно выносятся в отдельный родительский элемент первого уровня. Не тратя больше времени и не применяя каких-то секретных навыков, команда оценщиков получает куда более детализированную карту будущего приложения. Уровень детализации получается такой, что самые последние элементы Mind map’а редко имеют оценку более 4-8 часов.

    Если точную оценку по какому-либо элементу дать не получается, мы можем добавить некоторый элемент, отражающий риск:

    image

    Заказчику дается детализация оценки на уровне самых первых дочерних элементов. Эти элементы отражают некоторые бизнес-компоненты (use case, экран приложения) и поэтому понятны заказчикам.

    Что самое интересное, в ходе проекта выяснилось, что эта карта еще и куда более точная — количество неожиданных задач сильно снизилось (точные цифры — в конце статьи).

    Ход проекта


    Допустим, проект продан и пора его реализовывать. В этот момент многие делают ошибку и теряют связь между элементами приложения, которые были определены в ходе оценки и проданы заказчику, и задачами, которые заводятся в таск-трекере. А многие такой ошибки не делают =) и, все равно, тратят много времени на контроль того, что объем работы в таск-трекере соответствует в конце проекта проданной смете. Многие таск-трекеры либо вообще не позволяют организовывать многоуровневые иерархии, либо позволяют сделать это неинтуитивно. Какие проблемы при этом возникали у нас?
    • Из-за потери связи очень сложно понять, что какая-нибудь дополнительная задача, появившаяся в ходе проекта, приводит к превышению «проданной» оценки и мы начинаем реализовывать ее за свой счет.
    • Из-за отсутствия хорошего представления иерархии задач в трекере сложно понять статус готовности той или иной функции (в нашем случае — экрана мобильного приложения). Когда возникает такая необходимость, PM должен вручную просмотреть весь список задач в трекере и понять, есть ли какие-то незаконченные задачи, относящиеся к интересующему нас экрану.

    Решение


    И здесь на помощь пришел Mind map. Тот же самый Mind map, который получился при оценке, используется и в разработке — задачи самого нижнего уровня заводятся в трекер и отдаются на выполнение. Зная структуру, PM (и другие участники проекта) легко могут определить, какие задачи находятся под узлом, соответствующим тому или иному экрану. Сам узел содержит информацию о начальной оценке, поэтому PM сразу замечает ее превышение (при появлении новой задачи) и может принять меры.

    Статус отмечается на «низкоуровневых» задачах — тех, с которыми работают разработчики в трекере — и «транслируется» на более высокие уровни диаграммы. Это позволяет менеджерам проектов и CTO легко видеть статус всего проекта:

    image
    серый — к задаче еще не приступали, зеленый — задача готова, желтый — задача в работе, красный — есть какие-то проблемы.

    При необходимости, можно быстро понять, чем вызвана та или иная проблема:

    image

    Можно применить фильтр по задачам, требующим внимания менеджера:

    image

    Дополнительный бонус, которого мы уж никак не ожидали — существенное сокращение затрат на тестирование. Оно объясняется тем, что разработчики видели статус того или иного экрана и старались закончить задачи, связанные с ним, прежде, чем начинать работу над новым экраном (мы передаем приложение на тестирование поэкранно, либо по бизнес-фичам клиента). И если раньше случалось так, что разработчики отправляли на тестирование экраны, по которым оставались незавершенные задачи, то сейчас в тестирование стали поступать целиком завершенные экраны.

    Сложная экономика простых чисел


    Обещанные результаты.

    В проектах, которые использовали новый подход, были отмечены следующие улучшения:
    • 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’ами для оценки и ведения ваших проектов.

    А как вы оцениваете ваши проекты?
    e-Legion
    Делаем приложения, которыми пользуются миллионы

    Комментарии 27

      +1
      Ах вон как, майндмапы. Я думал что-то помощнее.

      Всегда использую майндмапы для управления проектами. Только вот пишу не по компонентам — а по делам.
      Прикрутите сроки и переход мапы в таймлайн (гантт) — и будет вообще чудесная вещь.
        +2
        Майндмапы — это только начало. Нам видится, что довольно много менеджеров используют их для визуализации статуса проекта, а плагинов для популярных трекеров, которые позволяют использовать майндмапы, нет. В целом же круг проблем, которые мы собираемся решить, немного шире.

        Не могли бы вы привести пример разбивки проекта по делам?
          +1
          Например

          Проект
          — Дела с клиентом
          — — Встречи
          — — Документы
          — Периодические активности
          — — Отчетность
          — — Контроль задач
          — Вопросы на контроле
          — — Тут конкретика о каких-нибудь поставках ПО/железа
          — — Риски
          — Текущая неделя
          — — Исполнитель 1
          — — — Задачи
          — Решения
          — — Собственно история решений/изменений по проекту

          Ну и всё в таком духе. Видно с первого взгляда, если помечать флажками, где затыки и к чему они ведут.
            0
            спасибо!
              0
              Мне кажется очень большой уровень абстракции у вас и вы эту схему за счет этого применяете почти под любой проект. Не понятна перекрестная зависимость, например вопросы на контроле и задачи, если таковые возникают.
              С одной стороны есть ощутимый плюс: при множестве одновременно ведомых проектов вы в рамках разных проектов работаете по одному плану, но как я уже написал мне не понятно как вы выстраиваете зависимости между подобными делами.
                0
                В принципе, многие mind map инструменты позволяют задавать произвольные связи между элементами, не только связь «родитель-потомок». Структура, которую привел в пример S_A, больше ориентирована на задачи; возможно, для нее как раз больше подошла бы диаграмма Ганта — если важно планировать задачи по времени и знать критический путь.
                Мы отталкиваемся больше от разбиения всего scope на функциональные компоненты, которые интересны и понятны как заказчику, так и участникам проекта.
                Не стоит забывать, что и тот, и другой вариант — просто вопрос группировки одних и тех же сущностей (задач). Над набором задач можно построить сколько угодно таких группировок — кому-то удобнее смотреть в разрезе задач и групп задач, кому-то — в разрезе функций приложения.
                  0
                  Это не карта продукта как такового, а карта именно управленческих дел. Зависимости можно указывать стрелками, задачи при желании можно перенести мышкой в вопросы на контроле. Не проблема. Это такой общий набросок я привел, в каждом проекте мапа уникальна.
            0
            Интересная вещь, буду следить за развитием.

            PS: На сайте не работает подписка, исправьте, пожалуйста.
              0
              Спасибо. А можно скриншот или описание того, что не работает. Мы пробуем — все ок.
                0
                Эммм… я сейчас из-за этой же ошибки 7 раз зарегистрировался. Сообщение «Спасибо за регистрацию» сразу не появляется. Как итог у меня в ящике 7 одинаковых писем «SNAP registration» и я думаю в случае запуска проекта я получу в этот ящик 7 одинаковых приглашений. =) Сделайте проверку на подписку пользователя.
                  0
                  спасибо, исправим
                    0
                    я так и не получил приглашения в проект, а он, как я понял уже успел свернуться )
              +1
              В конечном счете, у вас просто декомпиляция задач в виде Миндмапа. Признаться, я не понимаю, как у вас проекты не разваливаются. Даже в Ганте есть порядок работ, что позволяет увидеть риски. У вас же все задачи как бы одноуровневые. Уже этого достаточно, чтобы не называть все это «системой».
                0
                Я, признаться, тоже не понимаю что вы имеете ввиду под «у вас все задачи одноуровневые»?
                  0
                  По вашим схемам все задачи могут быть выполнены в любой последовательности и не зависят одна от другой. Например, UI магазина сделать сейчас, а UI офиса через месяц, а потом сделать API или еще что-то. При этом, где нибудь есть одна ключевая задача без которой весь проект будет считаться нерабочим и которая может существенно влиять на весь проект, но мы этого из ваших схем никогда не узнаем.
                    0
                    Как я понял, цель не в том что бы отслеживать линейность процесса, а в том что бы отслеживать общую завершенность проекта. Фактически это полезная инфографика для PM, более удобная нежели диаграмма Ганта, только из-за того что оно представлено иначе. Другой вопрос, что декомпозицию проекта для такого представления нужно провести правильно, иначе можно сделать только хуже.
                      0
                      Да, спасибо, я хотел написать примерно то же самое.
                      Декомпозиция в нашем случае завязана на отдельные функции приложения, интересные заказчику. Как описывалось в статье, задачи первого (и иногда второго) уровня — это те строчки, которые клиент видит в смете. Если декомпозиция сделана плохо даже на этом уровне, проект обещает быть веселым =)
                      +1
                      Теперь понял, спасибо.
                      1. Многие не планируют, а точнее планируют по итерациям или на дэйли скрам митингах задачи и таким образом вполне реализуют свои проекты. т.е. по моему скромному ИМХО — это сравнение теплого и мягкого: планировать критический путь проекта в каком-либо инструменте и причины по которым проекты могут разваливаться.
                      2. Вы в каком то смысле очень правы, если мы возьмем задачи из таск-трекера и просто декомпилируем их в виде MindMap, то получим скорее всего плоский список :). Наш подход как раз предлагает начинать «заводить» задачи в проект используя графическое представление, и как показывает уже практика, задачи имеют от 2-х до 5 уровней.
                      3. Вы утверждаете что используя Ганта, вы решаете задачу, чтобы проект не развалился. И, соответственно, мы не отрицаем, что структурируя проект в Ганте, в обычном виде в таск-трекере или в виде MindMap нужно думать и структурировать проект так, чтобы каждая «корневая ветка» могла считаться законченным функционалом.
                      4. И есть немаловажное отличие между Гантом и структурой проекта в MindMap. Планируя проект в Ганте, вы можете функционал одного экрана, например «Экран личного кабинета пользователя», «физически» разбить… отдельно на APi, на UI, на разработку и т.д. т.к. эти задачи действительно паралелятся и делаются разными командами. Вы действительно, можете спланировать работу так, что сделаете проект за минимальный календарный срок. Но при этом, если у вас отдельный Гант (или группа в рамках одного Ганта) для серверных разработчиков, для дизайнеров и для фронтенда, то, очень сложно понять готов ли функционал. Структура в виде MindMap, предлагает описать бизнес фичу и видеть, на сколько она готова. Т.е. одно другому не мешает, можно представлять проект в виде MindMap и видеть «законченность» фич, при этом имея даты старта и окончания задач, планировать их паралельное выполнение.
                        0
                        Я понимаю, что основная ваша фишка — это увидеть законченность отдельных функций в проекте, причем, как можно нагляднее. Но это задачи инфографики. Предположим, что вы хотите еще дать упрощенный доступ к аналитической информации по проекту. Но тогда сам выбор формата Миндмапа для меня странный.
                        Например, я легко могу представить, что все ваши ветки красные, потому что какие то проблемы с UI (некая сквозная задача, которая затрагивает все функции — «перекрасить все кнопки в красный цвет, а дизайнер забухал»). Но сам формат Миндмапа сложен, чтобы наглядно оценить насколько эти проблемы критичны для всего проекта.
                          0
                          А как вы решаете проблему «перекрасить все кнопки в красный цвет, а дизайнер забухал» в целом или при помощи того же Ганта? :)
                            0
                            Вопрос в том: Будет ли ваша «система» как-то решать такие задачи? :) Как я понимаю — никогда не будет.

                            Гант я лично использую только для оценки проекта (сроков и бюджета). Управление проектом уже вне его делается. И для целей оценки прекрасно используется JCVGantt + MindManager. Вы же берете Mindmanager и выдумываете что-то несусветное (уж простите меня за такую оценку), при этом убеждая себя, что в этом есть какой то смысл. Ну ладно, мне лень переходить на новую версию MIndManager, но вы могли бы посмотреть оригинальную реализацию использования миндмапов для ведения бизнеса http://www.mindjet.com/mindmanager/features/business-project-tools/.

                            На мой скромный взгляд, вы просто изобретаете новую форму колеса. В принципе, если вам за это деньги платят, то вы вообще в шоколаде. Работы бесконечно много, но в идее нет ничего нового и интересного.
                              0
                              Насчет новизны вы, пожалуй, правы. Другое дело, что в целом сложно назвать какие-то радикально новые вещи в управлении проектами. «Мифический человеко-месяц» был написан в 1975, с тех пор мало что изменилось — те же проблемы, примерно те же способы их решения. Scrum'у, который в последние несколько лет набирает популярность, порядка 25 лет.

                              Мы точно знаем, что есть люди, которые тоже используют майндмепы для ведения проектов и согласны с нами в том, что это удобно. Но таких людей пока мало, поэтому мы и делимся опытом в надежде, что больше оценит удобство и простоту такого подхода.

                              Mindjet мы используем, собственно, все скриншоты в статье — из него. Проблема в том, что он никак не интегрируется с таск-трекерами вроде Redmine или JIRA, а перевозить всех разработчиков в Mindjet Project Director мы не готовы.
                                0
                                Еще немного потревожу вас. Коль вы взялись за проект, то, наверное, лучше, как мне кажется, сделать понятный проект меньшего размера, чем огромный, но с невнятной аудиторией и функционалом.

                                Вы пытаетесь охватить «оценку, планирование, контроль, риски». Мне кажется, что если вы сконцентрируетесь только на оценке, то ваш результат окажется более значительным. Вы сами пишете, что для вас было важно «составление структуры» и «оценка». Если этот этап сделан грамотно, то вероятность, что дальше все будет хорошо, сразу сильно повышается. Т.е. сама по себе этот этап имеет ценность. Причем, я не знаю какой либо системы или сервиса, который бы помогал это сделать.

                                У больших компаний есть свои базы знаний, которыми они используют для таких работ (декомпиляция, оценка, риски), но они строго охраняются – все это область коммерческой тайны. Маленьким же компаниям создать полномасштабную базу не по силам, у них просто нет достаточного объема работ и примеров для этого. Т.е. потенциальная аудитория есть и она шире, чем просто любители Миндмапов. Заметьте, мы сократили функционал, но добавили аудиторию не пожертвовав ценностью продукта. Таким продуктом могли бы воспользоваться и продукт менеджеры больших студий для быстрой первичной оценки и студии, которые работают с каким-нибудь Битриксов и возможно люди не связанные с программированием – декомпозировать и оценивать можно все, но лучше это разносить по разным площадкам. (Хотя хрен его знает, у вас будут эксперты на кэмпе у них спросите, что они думают).

                                В итоге для сервиса нужно будет сделать: декомпиляция проекта, коллективная база знаний для типовых проектов/задач, работа в виде онлайн сервиса. Визуализировать, раз вам это нравится, можно в виде Миндмапов. Ну, еще понадобиться какой-нибудь вариант экспорта – в TXT, WORD, JPEG, PDF для начала подойдет.

                                По прошествию времени вашей сильнейшей стороной станет база знаний. А ее скопировать гораздо труднее, если вообще возможно, чем техническое решение, которое не защищено патентом.

                                Вариантов монитизации будет больше, чем сейчас, география, если захотите, шире, потенциал развития огромный. Ну, мне так кажется. Если вам или экспертам Яндекса покажется иначе – ну извините. Была бы у меня под руками команда разработки, сам бы занялся таким проектом.
                                  0
                                  Большое спасибо за хороший совет. Мы лишь озвучили наши мысли и планы, но вы правы что то, что вы написали будет как MVP. И да, экспорт уже предусмотрен нами.
                              0
                              Проблема решается примерно одинаково что с помощью диаграммы Ганта, что с помощью MindMap. Вы добавляете зависимость между задачей «дизайн кнопки» и задачами, которые зависят от нее. Отслеживать что там, что там будет не очень — в Ганте (говорю Гант, имею в виду MS Project) обычно не ведут задачи такого низкого уровня; в обоих инструментах будет мешать куча стрелочек.

                              Если говорить конкретно про ваш кейс, возможно, просто нужен некоторый список задач, которые блокируют другие задачи, отсортированный по количеству/суммарной оценке блокированных задач. Это просто немного другой инструмент.
                    0
                    Хм, Вы тоже перешли на шаблоны с ТемФорест? )
                      0
                      для первой версии сайта — самое то :) неплохой дизайн за 12 баксов.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое