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

В перерывах между разработкой мобильных решений для крупных заказчиков, в голову постоянно приходят идеи новых сервисов. Чтобы не откладывать их реализацию в долгий ящик, мы решили дать самим себе под зад и прошли отбор в Yandex Tolstoy Startup Camp 2014.

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

Если вы слышали о подходе Lean Startup, вы должны знать и о Customer Development — подходе, который заставляет стартаперов не сидеть и молча пилить гениальный продукт полгода, а выходить к своим потенциальным клиентам сразу, искать их реальные проблемы и решать их. Так вот, поскольку пользователи Хабра — наша потенциальная целевая аудитория, мы будем проверять наши гипотезы о проблемах на вас =). Мы будем регулярно делать посты о том, как развиваемся, какие гипотезы подтвердились, а какие были опровержены, как изменилось видение нашего продукта в ходе кастдева и сколько денег мы сэкономили по сравнению с обычным подходом (пиши код, б❚❚❚❚❚!), ну и рассказывать про Lean Startup и Customer Development.

Итак, если вы менеджер проектов или CTO, хотите принять участие в интервью и высказать свое мнение о том, как должна выглядеть система управления проектами вашей мечты, или просто хотите увидеть, как работает customer development в стартапе изнутри — добро пожаловать под кат.

Многие, услышав словосочетание «новая система управления проектами», наверное, подумают — чем же она отличается от существующих инструментов вроде JIRA, Redmine, Asana, Мегаплана и многих других. С нашей точки зрения, все эти системы хороши, но вряд ли могут называться “системами управления проектами”, поскольку они покрывают лишь немногие процессы из тех, что происходят в проекте (примеры таких процессов — оценка задач, разработка иерархической структуры работ, контроль и управление стоимостью проекта; есть и другие. Таск-трекеры, как следует из их названия, покрывают управление задачами частично несколько других процессов — отчетность, контроль качества).

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

Проблемы...

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

1. сбор требований с заказчика, первоначальная оценка и продажа;
2. после подписания контракта — фаза анализа и разработки дизайна. К завершению этой фазы заказчик получает более-менее точный work breakdown с указанием компонентов разрабатывамой программы, поддерживаемых use case’ов, с проставленной напротив каждого элемента ценой. Формат этого документа обычно файл Word или Excel:
   

   Компонент/функциональность	Дизайн	Разработка	Тестирование
   Логин	50	150	75
   Стартовая страница	100	500	200

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

3. После окончательных согласований начинается, собственно, работа над проектом. Менеджер проекта заводит задачи в таск-трекер (например, JIRA); начинается первый спринт, если команда работает по scrum; идут счастливые трудовые будни.

… и опасности

С нашей точки зрения, подобные проекты подстерегают следующие опасности:

• На этапе оценки не производится оценка рисков. Точнее, каждый участник процесса оценки умножает цифру, которая сначала пришла в голову, на 2 (а опытный оценщик — на 4 =)), но что это за риски и нужно ли их увеличить/уменьшить для данного проекта — обычно не знает никто.
• Такой подход затрудняет переговоры с заказчиком, поскольку сейлзу сложно понять, на сколько он может снизить начальную цену до того, как проект перестанет быть прибыльным. В результате компания предлагает цену выше, чем конкуренты, и теряет потенциального клиента.
• Артефакты, созданные в результате оценки, редко попадают в таск-трекер в том же виде, в котором они были представлены заказчику. Это затрудняет подсчет actuals по каждой разрабатываемой фиче (экрану, use case’у) отдельно и не дает понять, можем ли мы позволить себе потратить на нее больше времени или уже нет.
• PM’у приходится регулярно и вручную синхронизировать информацию в баг-трекере, плане проекта, отчетах, которые он посылает руководству компании и заказчикам. При этом нередко случается, что пункты в Excel, по которым он отчитывается перед заказчиком, не имеют ничего общего со списком задач в трекере (см. пункт выше), и подготовка каждого такого отчета требует немало усилий для понимания, какой же процент готовности той или иной части функционала.
• У PM’а нет понимания того, сколько действительно рисков было заложено при оценке и после достижения какой цифры fact проект работает в убыток (ну или просто снижает маржинальность проекта)

Сталкиваетесь ли вы с подобными проблемами? Как вы их решаете? Будем рады вашему фидбеку по данной теме в комментариях к посту. Также, просим потратить несколько минут и заполнить опрос ^[1].

Особенно благодарны мы будем тем, кто согласится потратить 30-40 минут своего времени на скайп-интервью. Для этого нужно просто зарегистрироваться на сайте www.snapyourproject.com ^[2] и поставить галочку «свяжитесь со мной» — и мы придем за вами =). Если вы живете и работаете в Москве, мы будем рады встретиться с вами лично, чтобы узнать ваше мнение.

Автор: krokhmalyuk

Источник ^[3]