Бизнес студии: про этапы, деньги, калькулятор и канбан


    Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!

    Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

    Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.


    Свою рентабельность, в смысле. Когда я обнаружил это с помощью простой excel-таблицы, и посчитал, во что обходится добавление еще одного этапа — я присвистнул.

    Итак, у нас есть абсолютно типовые этапы:



    • Пресейл [0.10];
    • Продажа [0.50];
    • Аналитика [0.8];
    • Дизайн [0.9];
    • Верстка [0.9];
    • Кодинг [0.9];
    • Поддержка [0.8];

    Цифры в скобках — это вероятность того, что проект у вас перейдет из одной фазы в другую с успехом и прибылью. Вымышленные, но довольно близкие к реалиям. Например, если у вас заказали только дизайн — то циферка в скобках уменьшается. Вы можете сами посчитать это для своей компании. Делайте это хотя бы раз в год. Просто проанализируйте все продажи и проекты. Будет где-то 0.8-0.95, наверное. Теперь перемножьте эти цифры, и вы получите вероятность того, что проект с текущей фазы дойдет до конца производственной цепочки, а вы хорошо заработаете.

    * У нас была довольно бурная полемика по поводу того, корректно ли использовать слово «рентабельность», ведь мы же получаем деньги за каждый этап. То есть рентабельность этапов не снижается. Однако проект, отвалившийся на середине цепочки, означает, что разработчики на последних этапах внезапно могут оказаться недогруженными и проедят прибыль с предыдущих этапов, вместо того, чтобы ее генерировать. Кроме того, именно на заключительных этапах проект обретает ту форму, в которой его хочется положить в портфолио, поставить на нем копирайт и гордиться им. А это — привлечение новых проектов и +100 к боевому духу. Так что пусть будет «рентабельность».


    Это упражнение сразу отбивает желание добавлять новые этапы в рабочий процесс.


    Просто откройте калькулятор, введите туда 0.9, нажмите [X] и тыкайте кнопку [=] столько раз, сколько у вас этапов.



    Каждый из этих этапов можно разбить на более мелкие стадии или делать много итераций по коду и дизайну. Так обычно и происходит на крупных проектах. В основном, именно такими мы и занимаемся. Это важно, потому что на крупном проекте — продажа, ухаживание за клиентом, обретение взаимного доверия и уважения — одна из очень затратных операций. Причем очень долгая и непредсказуемая. А теперь самое интересное:

    Дорогая и непредсказуемая операция есть в начале и в конце каждого этапа рабочего процесса.


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

    Иногда даже наоборот: хорошо сделанный прототип четко даст понять клиенту, что проект делать не надо.


    Получается, что чем больше этапов и итераций проходит проект в agile-процессе, тем больше демонстраций, а каждая демонстрация — это риск того, что клиент тормознет проект. Или устроит ТЯГОМОТИНУ!

    Тут нет никакого противоречия с маркетингом. У маркетоидов вообще для этого придуман инструмент: воронка продаж. Как-то вечером мне стало скучно, и я решил посчитать, сколько обращений мне нужно иметь «на входе», чтобы обеспечить:

    • Оптимальную загруженность команд на проектах.
    • Желаемый уровень дохода моей компании.

    Я исходил из того, что у меня 8 команд, и мне нужны примерно 4-6 проектов на стадии РЕЛИЗА за месяц.



    Итогом стала примерно такая табличка:



    В столбце «вероятность перехода дальше» — вероятность, с которой проект перейдет из текущей фазы в последующую. В строках — этапы, через которые проходит проект.

    Например, минимально у нас должен быть 137 проектов на фазе лида за месяц. С вероятностью 0,1 каждый из них переходит в фазу сделки (т.е. остается 14 проектов). И так далее — из всех входящих только 4 проекта будут доведены до фазы релиза.

    Мне удобно использовать канбан-доску для хранения всего списка проектов. Минимальное и максимальное количество проектов я использую как индикаторы для каждой из колонок (доска подсветит их нужным цветом, если что-то пошло не так, и если на какой-то фазе слишком мало или слишком много проектов). Кроме того, я могу прикинуть, сколько всего карточек (суммарный work in porgress) допустимо у меня на канбан-доске. В нашем случае это 39 и 59 проектов. Еще удобно считать, сколько денег у меня «застряло» на каждой фазе.



    Наверное, если бы я был не такой ленивый, я бы постоянно мониторил, насколько перегружены или недогружены мои менеджеры проектов. Я бы даже сделал такую табличку:



    Но обычно это и так понятно по их внешнему виду, зачем такие заморочки? ;)

    Все просто. Теперь я рискую и иногда делаю бесплатную работу осознанно!


    Почему? Я знаю, что разбиение проекта на более мелкие этапы:

    • Снижает риски «не уложиться в оценку» (хорошо).
    • Повышает риск «невыпуска» проекта в полном объеме от изначально задуманного (плохо) и добавляет тяяягомоооотины (очень-очень плохо).

    Кроме того, я знаю (и прогнозирую) вероятную загрузку менеджеров и их команд на пару месяцев вперед.

    И иногда мне выгоднее, чтобы менеджер и команда взяли на себя больше рисков по неопределенности. НЕ разбивали проект на дополнительные этапы. Или даже проделать какой-то из этапов как будто бы за свой счёт. Например, аналитику. Лишь бы быстрее и без потерь пропихнуть проект на следующий этап. Который уже окупит все. Ибо бесплатно работать — грех ;)

    Так что отслеживайте количество проектов в работе, рискуйте и иногда играйте с вашим калькулятором. Всем аджайл, пацаны!
    • +25
    • 18k
    • 9
    Share post

    Comments 9

      +2
      Тут, наверное, играет роль размер проекта. Такой подход отлично подойдет для огромных проектов, и будет лишним для небольших и средних.
        +4
        Когда стало понятно что будет 0.43, может лучше сразу сходить в казино всей компанией?
        :)
          +2
          Статья заслуживает внимания, но подсчет вероятности связанных событий, как вероятности независимых, выглядит более чем странно, поэтому конечные цифры не вызывают доверия.
            +1
            Те же самые мысли, математика очень-очень хромает, слишком много допущений. Да итак понятно, что заказчику в стиле «рога и копыта», или быстрому стартапу, нужно быстро, полу-на-коленке, сделать сайт/приложение, а потом, когда (если?) они отобьют финансирование — делать все по правилам.
            +1
            Вообще, смысл риск-менеджмента — предотвратить и уменьшить вероятность или тяжесть последствий риска, и проактивно ;) его мониторить. Сказать «У нас на проекте есть риск, что мы недооценили три фичи, поэтому, если что, я об этом говорил и не виноват» и на этом успокоиться — это не совсем про управление рисками. Это я типа на троллинг повёлся.

            А если серьёзно, рассчёты «воронки проектов» — вещь предельно полезная для планирования.

            Но в цифрах есть один нюанс:
            Если разбить один большой этап на десять маленьких, вероятность успеха каждого будет выше, чем у исходного… (Ой, кажется я только что изобрёл agile). Какова вероятность сфэйлить 20-недельную «итерацию»? А 10 двухнедельных? А этапов будет аж на 9 больше.

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

              Еще интересно, что имеется в виду под «крупным проектом»? Сколько это в человеко-месяцах?

              Из статьи сложилось впечатление, что выполняются примерно одни и те же задачи (с функциональной точки зрения) или сильно похожие. Так как их уже было сделано какое-то количество, и набор рисков всегда примерно одинаковый, и все о них знают, то кажется, что риск-менеджмент не нужен.… хотя, руководители проектов какие-то риски наверно все равно отслеживают (есть же такие, вероятность которых не зависит от количества итераций и/или их длительности). :)
                0
                Не совсем вероятность успеха каждого, но с направлением мысли согласен. Есть книга, Мишин, «Проектный бизнес», где он описывает этот механизм — много мелких и одинаковых по времени задачек в сумме дают меньшую ошибку по срокам (или бюджету, или отклонению от требований), чем одна большая.
                0
                Снижает риски «не уложиться в оценку» (хорошо).
                Повышает риск «невыпуска» проекта в полном объеме от изначально задуманного (плохо) и добавляет тяяягомоооотины (очень-очень плохо).

                А почему бы не сделать ряд этапов внутренними. То есть для клиента этапа три, а для исполнителя — девять. Апельсины три рубля кучка в кучке три штучки. Вы берете деньги за этапы по три стадии в каждом.

                С другой стороны кстати посмотрите на «риск невыпуска проекта в полном объеме». Откуда вы знаете, может быть выстрелит другой, более рентабельный проект, это раз, с другой стороны, аккаунты и аналитики в таких случаях должны работать над тем, чтобы проект пошел по новой.
                  0
                  Я, честно говоря, не совсем понял — в чем тут «value»?
                  У меня никогда не было таких этапов в контрактах — Дизайн, Верстка, Кодинг. Как то мои клиенты предпочитают функциональные этапы, типа «создание каталога товаров», «процесс оформления покупки» и т.д. И тут ничего не сократишь, потому что этапы приводят к решению бизнес-задачи заказчика, за что они и платят. А вот я, да, плачу за дизайн, верстку, код, в рамках каждого отдельного этапа.
                  Я стараюсь соблюдать баланс. Если в контракте все сдается одним этапом — есть риск что в конце все равно не понравится результат, хоть мы все итерации пройдем гладко. Просто у заказчика к концу срока работ могут деньги кончится, или гендир поменяется. Это тоже риски :-) Если этапов будет слишком много — нас могут замордовать на соблюдении всех бюрократических процедур по многу раз, получаться слишком большие накладные расходы. Так и живу.

                  PS: О да, внутри этапа agile работает суперски

                  Only users with full accounts can post comments. Log in, please.