Создание системы управления проектами на 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 проект работает в убыток (ну или просто снижает маржинальность проекта)

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

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

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

      0
      Звучит очень интересно! Ждём следующую статью и, конечно, саму систему, о которой написано на сайте, уже хочется потестить.
        0
        Опрос заполнил, заявку на сайте оставил.

        Эти проблемы есть и я их решаю интуитивно. Интуитивная цена на основании сроков, которые как-то считаются в голове. Благо, угадываю. Но понимаю, что такой подход крайне не профессионален и на высоком уровне это не пройдет.

        Надеюсь, у вашей команды всё получится! Инструмент реально нужен и полезен, потому что может снять реальную головную боль в прямом смысле. Надоело питаться таблетками.
          +2
          Как-то это не правильно, брать с early adopters по 50$ в месяц за альфа версию продукта, непонятно как и зачем работающего.
            +1
            Сейчас вроде все, кроме бестолкового basecamp'a или корыстного salesforce'a (Atlassian в расчет не берем, там предельно ясно за что платить) перешли на модель «сам пользуйся сколько влезет, заплатишь когда правда начнешь применять в работе, пригласив хоть одного коллегу», альтруистическая Asana пошла дальше, заменив среднее значение 2 (пользователя) на 15.
              0
              Спасибо за комментарий. Мы пока только экспериментируем с ценником, скорее всего, в первой версии продукта будет бесплатная версия.

              Насчет Asana — я думаю, что альтруизм здесь ни при чем. Есть мнение, что при большом количестве активных клиентов (а у Асаны, по слухам, их больше 100 тысяч) можно ввести практически любую бизнес-модель — и она будет приносить прибыль. Оказание бесплатных услуг можно расценивать как инвестиции в рост клиентской базы. Но для такого подхода нужные серьезные инвестиции, которые были у Асаны (в компанию суммарно вложили более 35 миллионов долларов), и которых не будет у нас. Поэтому мы вынуждены выбирать другой подход и сразу оказывать платные услуги.
              0
              Давно пора было уже сделать что-то подобное. Насколько я понял идею, то проект можно «покрутить», как модель, изначально, прежде чем авторизовывать. Если это так, то хорошо. Далее, встроено управление ЖЦ проекта, и функционал планирования поженили на трекере — это тоже очень здорово.

              В случае вопроса, как мониторить бюджет, есть ответ — освоенный объем. Но с одной только стороны простая метода, с другой стороны — сложная (прогнозные показатели по ней достаточно сложно интерпретируются).

              Ну то есть успехов вам, держите в курсе. И, если как выше пишут, 50$ в месяц за альфу, то сам я следить не буду :)
                0
                $50 в месяц можно платить, если видно за что. За непонятную Альфу — нет.

                Совет от того, кто это все уже проходил: не пытайтесь делать комбайн, лучше сосредоточьтесь на том, что вы делаете лучше конкурентов, на том, чего у них нет. Делайте небольшой продукт. Если эти ваши уникальные фичи не продадутся за небольшие деньги сами по себе, без остальных наворотов и обвесов — значит и ваш комбайн скорее всего тоже не «взлетит», т.к. никакой ощутимой добавленной стоимости он не несет (с точки зрения клиента, конечно же).
                  0
                  Спасибо, постараемся сфокусироваться для начала только на нашей киллер фиче.
                  0
                  Ну давайте начнём с того, что вы не продаёте заказчику услуги по разработке требований, в результате делаете требования абы как быстрее и получаете те самые риски, оценки 4X и т.д.

                  Вы бы хоть объяснили, какую проблему решаете.

                  Если не понимаете, то приходите учиться к нам на product.vision

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

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