Объясняем бизнесу, почему у нас такие «фиговые» оценки

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

    Почему ты не можешь дать точную оценку трудоемкости разработки?
    Почему ты не можешь завершить все работы в два раза быстрее?

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

    Оценка это всегда вероятностная величина
    Потому что оценка всегда делается в условиях неопределенности. Поэтому одно число это ни разу не оценка. Оценка это всегда, как минимум, два числа. От … и до…

    Дальше ваш выбор, по какой цене разработку продавать.

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

    Хотите гарантированную прибыль – продавайте по пессимистичной оценке.

    И еще оценки от Х/2 до 2Х на стадии обработки RFP – это очень хорошие оценки. Потому как, неопределенность.

    Что такое неопределенность
    Попробую объяснить на примере. Представте себя на месте разработчика, которому надо дать оценки. Оценки приходится давать всегда. Вопрос только в мере их неопределенности — ширине доверительного интервала.

    Тест. Хороший ли ты оценщик?
    Приведите оценки от… и до… для следующих величин:

    Количество городов в СНГ, которые, имеют метро.
    Температура плавления этилового спирта (°С).
    Длина реки Днепр (км).
    Максимальная продолжительность жизни Галапагосской черепахи (лет).
    Касса первого викенда в СНГ фильма «Сталинград» (млн. руб).

    image

    Правильные ответы
    Количество городов в СНГ, которые, имеют метро: 16.
    Температура плавления этилового спирта (°С): -114,15.
    Длина реки Днепр (км): 2200 км.
    Максимальная продолжительность жизни Галапагосской черепахи (лет): 177.
    Касса первого викенда в СНГ фильма «Сталинград» (млн. руб): 565.

    А теперь посчитайте, сколько раз вам удалось накрыть реальное значение и сколько — уложиться в диапазон от Х/2 до 2Х.

    Откуда берется неопределенность в разработке ПО
    Еще один пример. Оцените трудоемкость разработки простенькой функции для ввода контактного телефонного номера нового клиента.

    Скажу сразу ответ 20 мин – неправильный. Правильный ответ должен содержать две оценки.

    Правильный ответ
    От 2 чел*час до 200 чел.*час. Потому что, никто на стадии заключения контракта не может ответить на простые вопросы:

    Может ли вводиться несколько номеров?
    Должна ли быть проверка номеров на действительность?
    Простая или сложная проверка?
    Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную?
    Должна ли проверка работать для иностранных номеров?
    Можно ли воспользоваться готовым решением?
    Каково должно быть качество реализации? Вероятность ошибки после поставки?
    Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).


    Последний вопрос особенно интересен. Потому что, когда мы делаем оценку трудоемкости, мы не знаем, кто из бойцов войдет в команду проекта. Вася, Петя или новый разработчик, который выйдет через две недели. А человеческий фактор – это самая значимая неопределенность в разработке ПО. Сошлюсь на отраслевой опыт — Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood Cliffs, NJ:Prentice-Hall, 2000.

    Вот диаграмма влияния человеческого фактора, рассчитанная согласно этой методике.

    image

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

    И последнее. О сроках
    Вот еще законы того же Бари Боэма, которые он вывел еще в середине 80-х.

    Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)^1/3.

    Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.

    Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за ¾ расчетного оптимального графика вне зависимости от количества занятых в нем!

    Как-то так.

    Успехов.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 45
    • +2
      Поясните пожалуйста форму для временной оценки
      • +1
        Это просто империческая формула, выведенная по статистке завершенных проетов. Если за ней и стоит како-то объективный закон, то мы его не знаем. Но наше незнание нас от него не освобождает
    • 0
      Неопределённость можно выражать и преподносить через оценку рисков. Эта часть темы не раскрыта совсем.
      • +1
        У автора топика совсем недавно была статья про риски. Похоже на то, что он скрыл её в черновики (потому что я свой коммент не могу найти даже в «моём»).

        Насчет этого топика можно сказать, что не любая неопределенность — риск. Риск — это событие, а неопределенность — это неточность наших знаний о настоящем и будущем, результат того, что мы что-то недопонимаем/не знаем. Т.е. конус неопределенности оценок сроков завершения — это еще не риск, но уже неопределенность, и ее изучали отдельно. Риском будет «не успеть» к конкретной дате.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +5
          Ничего удивительного. Люди ведь не изменились с «далекого» 1975 года :)
          Даю две подсказки:
          1. Многие ли люди читают книги, если нужно найти ответ на вопрос/проблему?
          2. Редко ли те, кто прочитал толковую книгу, говорят: «ну это только в книгах все так хорошо»?
          • НЛО прилетело и опубликовало эту надпись здесь
            • +20
              А если бы сроки всегда можно было оценить, то Windows Vista вышла бы в 2005м, а не в 2007м и содержала бы в себе объектно-ориентированную файловую систему, про которую рассказывали красочные буклеты в 1993м.

              Разработка ПО больше всего похожа на ремонт, который, как известно, невозможно закончить но можно только прекратить. То же самое и тут: выживают не фирмы, способные как-то прогнозировать сроки (таковых в природе нету), а фирмы способные убедить заказчика принять то, что в оговоренные сроки удалось сделать как «ну-почти-то-что-вы-в-общем-то-и-хотели».
              • НЛО прилетело и опубликовало эту надпись здесь
              • +2
                Книжка, да, хороша. Но я не очень верю в то, что в вузах на ИТ специальностях у нас вот-так скоро начнут учить выстраивать процессы. Планирование — это ведь процесс. Вот в автошколах сначала учат правилам, а потом вождению. А программистов сначала учат быстро-быстро кодить, а потом… а ничего потом. Потом они попадают с реальные условия, совершенно не умея (чаще всего) по уму применять свои знания.

                Я думаю, что опытные девелоперы лучше планируют, помому что принимают во внимание больше аспектов, связанных с задачей. Именно в мелочах часто кроется «неучтенное» время. Может быть главная польза от планирования — это сам факт поиска неочевидных штучек-дрючек в задаче.
                • +1
                  Сроки = себестоимость.

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

                  Их было бы меньше, но они остались бы — просто выставлять счета по факту, оплачивая разработку из собственных или заемных средств. Или договариваясь с заказчиками на «почасовой рэйт» как, по сути, при внутренней разработке.
                  • 0
                    ИМХО, на оборот. Если бы оценивать было просто, то фирм-разработчиков ПО было больше.
                    • +1
                      Это никак не противоречит моим словам:
                      — оценивать просто — фирм много
                      — оценивать сложно (как сейчас) — фирм нормально
                      — оценивать невозможно — фирм мало
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Какую работу заказчика?

                        Я заказываю у вас разработку продукта, вы сроки оценить не можете, мы договариваемся, что как сделаете, то я вам готовый продукт оплачу. Вы разрабатываете, оплачивая издержки из собственных или заемных средств.
                • 0
                  очевидно вы не имели заказчиков со всяких телекомов газ и прочих промов
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Если в двух словах: для fixed bid проектов с большой долей неизвестности почти гарантировано будет даваться близкая к верхней оценке величина. Даже для dedicated team в вопросах строков хотят comitment что заявленные сроки будут исполнены.
                      Как окологосударственные и не только компании ищут себе подрядчиков? Создают тендер. А дальше риски оказываются в цене.
                      Добавим очень частую ситуацию, когда детали вы утверждаете с профессионалом представителем заказчика, но он не является decision maker, а decision maker человек далёкий и специалист с совсем другими навыками или вообще без оных.
                • +2
                  Перед каждым участником разработки встаёт этот вопрос, и не раз. Каждый раз, переходя на новую ступень или на новую должность, смотришь на проблему по-новому. Я, например, основные причины неадекватности оценок (и возможные способы повышения их адекватности) сформулировал для себя так: greesha.livejournal.com/11358.html
                  • 0
                    А я не такой плохой оценщик, только с городами, в которых есть метро сильно ошибся
                    • 0
                      Я наоборот, попал только с городами, в которых есть метро :D
                      И еще с двумя пунктами уложился в интервал 0.5X...2X
                    • 0
                      Точка зрения из экосистемы аутсорс/интеграции:

                      На эту тему есть несколько точек зрения:
                      1. Разработчик, которому необходимо обезопасить себя и менеджера от факапа по срокам
                      2. Менеджер, которому необходимо обезопасить себя и команду от факапа и продать максимально дорого в реальных условиях
                      3. Руководитель менеджера, которому нужно выполнить план по обороту любой ценой
                      4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.
                      В ваккуме все это порождает порочный круг «эффективного менеджмента», «урезания костов» и прочих вещей, ведущих к плохому коду и недовольству всех участников этого шоу.

                      2 случая из практики:
                      1. крупная система, договор по сдельной оплате, каждая задача проходит 3х ступенчатую проверку трудоемкости и согласование техкомитетом (с представителями бизнеса). Архитектору приносят ТЗ на изменение куска ядра, по которому нет документации. Он, не будь дурак, вычленяет все отдельные блоки ТЗ (60 штук) и на каждый дает 3 дня. По итогу задача утверждается на ТК с трудоемкостью около 70 дней и делается за 120. Все недовольны, штрафы субподрядчику, задачу просохатили на календарный месяц по срокам сдачи.

                      2. Другая крупная система, договор по абонентской плате. Разработчикам дана строгая установка в оценках быть пессемистичными, согласование трудоемкости с заказчиком идет на предмет адекватности (не может отчет из 2 форм дорабатываться 60 дней, верно? :)), с бизнесом согласовываются сроки деплоя задачи на бой (сроки даются после планирования), исключение — задачи, связанные с законодательством. Процент попадания в сроки — ~95%, все довольны.

                      Считаю, опасно рассматривать эту проблему только с точки зрения разработчика.
                      • 0
                        4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.

                        Заказчику, как правило, ещё нужно как можно быстрее. И, часто, гарантированные сроки, чтобы он мог планировать свой бизнес.
                      • 0
                        Очень помогает оценка по «женскому» времени: берем первоначальную оценку времени и умножаем на число пи.
                        • 0
                          она же максимальная у опытных ПМ-ов, вроде так? :)
                          • 0
                            Иногда и эта оценка может оказаться очень оптимистичной
                            • 0
                              Угу. Та функция ввода контактного телефона — от 2 до 6,5 часов получается, а под спойлером — от 2 до 200.
                              • 0
                                А для получения пессимистичной нужно ее еще умножить на e
                            • +2
                              Боюсь, что бизнесу на этот пост, мягко говоря, плевать. По крайней мере — большинству средних предпринимателей, не понимающих, насколько на самом деле важна «прослойка между стулом и монитором», работающих не на эффективность в целом, а на результат прямо сейчас.
                              • –2
                                В какой-то книжке читал про формулу оценки времени, необходимой для разработки — возмите время, сказанной программистом, умножьте на 2 и переведите в следующую единиицу времени.
                                • 0
                                  В справочнике Стеля таких формул с избытком.
                                  • 0
                                    Видимо Вы являетесь ПМ'ом?
                                    • 0
                                      ПМ по умолчанию — корень всех бед?
                                      • 0
                                        Нет, я админ, вернее — технический консультант, так написано в трудовом договоре.
                                        И ко мне часто ПМы приходят с вопросом — сколько может занять времени та или иная задача. И я обычно даю всегда два ответа — если все пойдет хорошо, то это одно время (оптимистичный прогноз), а если на каком-то этапе возникнут проблемы, то необходимо увеличивать этот прогноз на время решения проблем, естественно, не всегда можно точно сказать, сколько именно времени необходимо на решение проблем на каждом этапе. При этом я стараюсь донести до ПМ все возможные проблемы на каждом этапе, как их можно будет порешать и сколько ориентировочно это может занять времени — обозначить риски, так сказать.
                                        Не хочу так же сказать, что я пользуюсь тем правилом, которое озвучил, скорее наоборот — обычно мои прогнозы по оценке затрат времени на мою работу имеют погрешность не более 15-20%.
                                        А та формула, которую я привел, это, на мой взгляд, разное видение задачи с точки зрения программиста и ПМ. Программист смотрит на задачу — реализовать такую-то фичу, — думает про себя, — ну эт несложно, вот тут добавим и все — дел на час. И озвучивает час. А ПМ нужна эта фича уже в готовом продукте, соответственно, помимо программиста, написавшего эту фичу, необходимо прогнать ее через отдел тестирования, проверить, нет ли багов, исправить их, если вдруг они появились и только после этого только получить продукт с такой фичей. И тогда действительно, час вполне может превратиться в 2 дня.
                                      • 0
                                        Это из тех книжек где пишут про необходимость создания конкурентной атмосферы в коллективе, порядок расстановки кактусов перед монитором под обложкой «12,5 шагов к эффективному менеджменту»?

                                        Хороший ПМ зачастую выходит из исполнителей (QA/Dev/Analytics), неплохо разбирается в подотчетной системе и в состоянии адекватно оценить оценку разработчика
                                      • –1
                                        Как то странно вы сделали, мягко говоря… «Приведите оценки от… и до… для следующих величин:» — для физических величин и фактов, которые нагуглить совсем не трудно. В реальности же требуется «угадывать» не величины, а временные интервалы, причем на основании аналитики и опыта. Какой опыт может помочь в определении длины реки? Ну на бред же прхоже. Попытка смешать в кучу не смешиваемое.
                                        • 0
                                          … требуется «угадывать» не величины, а временные интервалы...

                                          Не понял. Временные интервалы чего?

                                          По сути. Кейз приводился на семинаре (естественно без всяких гуглов) для того, чтобы люди ощутили, что такое неопределенность. В каких-то вопросах она меньше. Например, человек Химик. В каких-то больше, например, не учил в школе географию и не знает где течет Днепр.

                                          Как-то так.
                                          • –2
                                            Задача как поставлена: на глазок прикинуть параметры, которые нет реальной необходимости прикидывать — их можно относительно легко узнать. Зачем прикидывать то, что можно узнать? Там нет неопределённости, там есть вещи, которые люди не знают, но могут легко узнать, не тратя много времени. Пример высосан из пальца.

                                            В реальном проекте часть вещей нельзя узнать, пока ты их не сделаешь, например, производительность разработчика, который пришел к вам фирму два дня назад. Вот это — неопределённость.
                                            • 0
                                              При таких вопросах может возникнуть ложное ощущение «меня спрашивают то, что я не знаю, но могу легко узнать» => «срок разработки тоже легко узнать».
                                          • +1
                                            По собственному опыту могу сказать, что в плане оценок сроков выполнения задач действует правило 90/10.
                                            90% задач очень хорошо поддаются оценке. Как правило, это типовые задачи.
                                            10% дают очень большое непопадание в первоначальных оценках.
                                            Это я привожу цифры в отношении тех задач, выполнение которых зависит только от меня.
                                            В интеграционных задачах, в задачах, где нужно использовать open-source либы, не проверенные временем правило 90/10 уже не действует.
                                            • 0
                                              Прикольно — сроки виртуальные, а оплата фиксированная. Если человек — профессионал своего направления, делает на заказ работу, в которой он имеет большой опыт, разве не может он дать реальную оценку готовности продукта? Я понимаю, когда надо делать что-то совершенно новое, когда нет опыта решения конкретных задач и понимания подводных камней. Но большинство программистов, что мне довелось видеть как правило специализируется на конкретных видах заказов и типовых проектах.
                                              • +2
                                                Насчёт типовых заказов — оценить приблизительно, что почём, конечно, можно.
                                                А если речь идёт о большом проектах, а задачи могут меняться в зависимости от сложности конкретного заказа и, да-да, сложности конкретного клиента?
                                                Даже документированные требования к проекту — это по факту филькина грамота, устаревающая, как только доходит до дела (насколько я имею об этом представление, переданное от признанных авторов типа Стива Макконелла). На практике, скорее всего, всё жёстко. Только если сама команда — не слаженно и работающий монолитный механизм: тогда, конечно, будет легче и оценивать сроки, и задачу выполнять.

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