Простые практики прогнозирования временных затрат

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


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


    Сформулировать описания функциональности


    Основа хорошего планирования, хорошо сформулированное описание функциональности, которое необходимо реализовать. Лучший на мой взгляд способ — это достаточно давно придуманный формат пользовательских историй или шаблонов поведения (use cases):


    Как пользователь, я хочу оплатить заказ пластиковой картой


    Чем хороша такая формулировка? Ясностью. Хороший управляющий сознательно ограничивает объем информации доступный участникам для обсуждения. Чем меньше информации, тем меньше вероятность совершения ошибки.


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


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


    Определить списки задач


    Что дальше? Дальше необходимо каждое из описаний функциональности разбить на задачи. Делать это необходимо вместе с разработчиком, который предположительно будет выбранную функциональность реализовывать. Что включать в список задач? Если разработчик видит задачу впервые и ранее не касался ее, то буквально все действия, которые предположительно могут потребоваться, включая исследовательские и коллаборационные:


    1. Изучить документацию по интеграции с платежным шлюзом, касающуюся части платежей пластиковыми картами
    2. Согласовать со специалистами платежного шлюза выбранный способ подключения и осуществления платежей
    3. Согласовать с руководителем проекта выбранный способ подключения и осуществления платежей
    4. Реализовать хранение и извлечение данных, необходимых для взаимодействия с платежным шлюзом (идентификаторы клиента, ключи безопасности)
    5. Реализовать получение и подготовку данных о заказе, который будет оплачен
    6. Разработать (подключить предоставленную платежным шлюзом) форму для ввода данных пластиковой карты пользователем
    7. Реализовать передачу данных о заказе и его стоимости в форму оплаты
    8. Реализовать получение, обработку и сохранение данных об успешном выполнении платежа
    9. Реализовать обработку ошибок, произошедших в ходе выполнения оплаты
    10. Реализовать отображение пользователю квитанции о выполнении оплаты
    11. Реализовать отображение пользователю сообщения об ошибках, произошедших в ходе выполнения оплаты

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


    По мере выполнения пунктов в списке задач, попросите разработчика указывать фактически затраченное на задачу время, таким образом у вас появится возможность оценить качество вашего планирования.


    Инструменты


    Я не сторонник дорогих или не очень понятных инструментов планирования, с покером, диаграммами сгорания и story point-ами. Я считаю в управлении следует полагаться на здравый смысл и принцип сохранения простоты.


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


    Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч


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


    Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч — 15ч


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

    Поделиться публикацией

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

      +4
      в реальности обычно так:
      Как пользователь, я хочу оплатить заказ пластиковой картой — 30ч — 150ч — готово на 90% — осталось еще 90%
        +3
        — Ну что, теперь готово?
        — Да, можно отправлять заказчику, *неразборчиво*.
        — Что?
        — Да, говорю, тесты писать времени не было, будем надеяться у заказчика заработает.
        — На тесты сколько времени ещё надо?
        — Да там немного, порефакторить ещё только сначала, а ту часть, которую Вася делал, вообще с нуля переписать надо, там всё плохо, невовремя он уволился, некому разбираться теперь. Дима, который вместо него пришел, говорит надо новый фреймворк использовать, он гораздо удобнее и быстрее можно всё сделать, повезло нам, его в прошлом месяце выпустили, говорят очень хороший, на голову выше аналогов.
          +2

          Если это так, то возможно тот, кто управляет проектом, не делает свою работу или делает ее очень плохо?

          0
          2. Согласовать

          Я не занимаюсь пластиковой картой, но по моим наблюдениям любой пункт со словом «Согласовать» непредсказуем. М.б. очень быстро, а может очень долго.
            0

            Так и есть. Любые пункты, подразумевающие коммуникации с третьими сторонами непредсказуемы по времени. Особенно если третья сторона за океаном, в другом часовом поясе и говорит на другом языке. Планы никогда не выдерживают встречи с реальностью, я написал это.


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


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

            +1

            Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.


            Как пользователь, я хочу оплатить заказ пластиковой картой

            Откуда 30 часов?


            А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?

              0
              Как-то слабовато. Предложенные критерии разбиения на user story работают только для типичных crud и ecommerce. Попробуйте применить это для CAD, игр, научного или системного софта.

              А почему нет?


              • Как AI, я хочу спрогнозировать направление следующего движения игрока
              • Как система, я хочу прочитать список команд устройства X
              • Как система моделирования освещенности, я хочу вычислить компенсацию отражения от плоской поверхности из материала Y
                0
                >А почему нет?
                Я бы сказал, что оно применимо, но при одном дополнительном условии, которое автор не сформулировал достаточно четко.

                Описанный способ хорошо работает, если разбиение происходит на задачи, объем каждой из которых достаточно мал, скажем часы. В этом случае оценки получаются близкими к реальности. Если вы это можете сделать для игр или CAD — это даст реалистичную оценку. Если нет — точность оценки будет низкая.

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

                  Я не смогу сделать это для игр или CAD, ибо это не моя предметная область. Однако я полагаю, что если руководитель проекта, управляющий разработкой игр или CAD, совместно с разработчиками, программирующими в этой же сфере будет постоянно, осмысленно и осознанно практиковать описанные мной в публикации действия, то точность оценки будет постепенно нарастать.

                    0
                    Примерно это в общем и подразумевалось.
                    0
                    Я бы сказал, что оно применимо, но при одном дополнительном условии, которое автор не сформулировал достаточно четко.

                    Описанный способ хорошо работает, если разбиение происходит на задачи, объем каждой из которых достаточно мал, скажем часы.

                    У меня была мысль, в дополнение к утверждению:


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

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

                  0
                  Откуда 30 часов?

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


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

                    0
                    А если требование «Как пользователь, я хочу оплатить заказ криптовалютой SuperPuper» SuperPuper версии 0.0.1 вышла вчера, документации нет, но разработчики утверждают что «SuperPupper is the most advanced and stable crypto currency ever. You can integrate SuperPupper with your website in under 5 minutes!» Сколько поставим часов на реализацию, 5 минут?

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

                      0
                      Конечно 5 минут это утрированный пример :) Я веду к тому, что предложенным методом можно оценивать только задачи, которые знакомы оценивающим. В то же время, оценки наиболее ценны для областей, которые не знакомы. Для знакомых областей команда часто без всяких формализмов знает сколько времени надо не выполнение, просто из опыта. Мне кажется это и есть самая большая проблема всех методов оценки, они лучше всего работают в знакомых областях, но наиболее востребованы в не знакомых.
                    +1
                    Составление списка — дело хорошее, конечно, но вот у меня сложилось так — составлю список дел, прикину время на вот это всё. Пессиместично. Еще более пессиместично. Потом умножаю на три. И тогда получается довольно точно. Оценку я всегда пытаюсь делать честно, зачем себя обманывать? но без умножения на три — не работает.
                      0
                      «Список» — в Вашем случае это просто набор задач или каким-либо образом структурированный объект?
                        0
                        Теоретически принцип довольно прост — нужно дробить пока каждая подзадача по срокам не станет около 2х недель или меньше. На практике обычно проблема в том, что как скурпулезно не проектируй, всегда найдутся непредвиденности, на которые никто не заложил время. Вот умножение на 3 — это мой импирический коэффициент. У вас, возможно, он другой.
                        Хотя, опять же — о каких задачах мы говорим? Я — о, например, рефакторинге очень старого кода, спагетти, больше 10К строк С, написанным в 90х, с нулевым беспокойством о времени жизни указателей, с нулевым беспокойством о переиспользовании переменных, с отключенными варнингами и прочими прелестями. При этом код не покрыт тестами более чем на 80% и трудится 24/7 в production.
                        Я честно оценил в 3 мес. Разложил по косточкам план и оценил. Не лукавя. 10К строк. Эка невидаль. Запросил 9 мес и по факту едва уложился в 8. Т.е. с опережением, но минимальным.
                          0
                          Я не про распределение времени по списку спрашивал, а про составление самого списка, есть ли в нем структура. последовательность, правила какие… Мне кажется, что если есть правила, то они применимы к составлению списков по сродным задачам. А рефакторинг «спагетти» на мой взгляд очень похож на планирование (и реализацию) похода с супругой в большой сетевой магазин, когда цель по времени точно недостижима, но хоть цель по предметам удержать близко.
                            0
                            а про составление самого списка, есть ли в нем структура. последовательность, правила какие

                            Структура обычно 2-3 уровня.
                            Правила — от development cycle зависит. В случае scrum/agile правила одни, в других случаях — другие. Т.е. это бизнес практики компании. Если у вас их нет, то можете попробовать взять — в книжках подробно описаны. Сэкономите время на изобретение велосипеда.
                            В приведенном примере это не 100% рефакторинг. Там нужно было вычленить 4 этапа работы кода, и 2 из них, нечетные, перенести на клиента, обеспечив его библиотекой, с прежним внешним API, а меж собой эти куски должны взаимодействовать за минимальное количество вызовов RPC. Т.к. это внутренний сервис компании, то там довольно много клиентов сервиса, которые не перейдут на новую клиентскую библиотеку одномоментно. Им нужен старый API. А код мы хотим выдрать из сервиса уже сейчас, чтобы улучшить масштабируемость. Окей, значит мы делаем брокеров, которые транслируют API. Ну вот сидишь, изучаешь, рисуешь и планируешь неделю или две. Ставишь сроки. Умножаешь на 3. И утверждаешь в планы.
                            0

                            Как разработчик, я хочу рефакторить 10 тысяч строк кода — это слишком масштабная история. И если к примеру с этим кодом никто не знаком из разработчиков, то прежде, чем взяться за планирование, надо потратить время на исследование этого кода. Потому что — как планировать неизвестность?


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

                              0
                              И исследование поддается планированию. «План исследования» как документ, определяющий и регулирующий процедуры и бюджет процесса.
                                0

                                Да. Именно это я и имел в виду, когда написал что прежде, чем взяться за планирование рефакторинга 10К кода, надо потратить время на исследование этого кода.

                                  0
                                  Конечно, если всё детально изучить, потратить достаточное время, то, вероятно, можно составить довольно точный план, и назначить правильные сроки. Но это скучно, не очень интересно, и, главное, никто и не даст сидеть и долго что-то там изучать. Особенно, если у вас scrum/agile. На всё у вас 1 этап скрама максимум.
                                  Поэтому привлекаем интуицию. Это еще называется educated gut feeling :)
                                  И если известно насколько она ошибается и в какую сторону, то можно скорректировать цифры в противоположенную сторону.
                        0
                        User story хороши, когда речь идёт о реализации новой функциональности, которую видит этот самый юзер. А теперь представим, что оплата картой у вас уже реализована и работает, но вышла новая версия протокола МПС/шлюза/whatever, и вам надо добавить в сообщение шлюзу дополнительное поле (ну, например, раньше шлюзу отправлялись фамилия и имя плательщика, а теперь ещё отчество надо). Как будет выглядеть user story? «As a payment switch, I want to see field DE39 filled with payer's second name»? :)
                        А задач по сопровождению существующей функциональности, по-моему, гораздо больше, чем на реализацию новой…
                          0

                          Возможно, точно так же, как в случае, когда функциональность ещё не реализована? Ну, может быть, добавится ещё один пункт: изучение текущей реализации. Просто теперь будут другие оценки времени на выполнение требований.


                          Если SRS ещё нет — её нужно разработать, если есть — адаптировать. Затем на основе SRS разработать/адаптировать HLD. (По сути, написать/адаптировать документацию и ПМИ. Нужен ли далее DLD или в качестве него будет выступать непосредственно патч изменений — это уже зависит от размера компонента.)

                          0
                          Как основной цикл прошивки я хочу вывести эти биты через DMA — вполне себе user story или нет?
                            0

                            На мой взгляд вполне.

                            0
                            Лично мой опыт: StoryPoints хорошо подходят для прогнозирования (по происшествию 2-3 спринтов) потому что частично учитывают риски. Боле мелкие стори — более точные прогнозы

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

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