Почему инженеры не могут оценить время разработки

Автор оригинала: Hesham Meneisi
  • Перевод

Статистический подход к объяснению ошибочных дедлайнов в инженерных проектах



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

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

Общая информация


Давайте сначала взглянем на проблему, её последствия и потенциальные первопричины с высоты птичьего полёта.

Проблема


Программные проекты редко укладываются в дедлайн.

Последствия


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

Известные причины


  • Неправильная оценка времени (основная тема этой статьи).
  • Нечётко сформулированные на старте проекта требования с их последующим изменением.
  • Украшательства: слишком много внимания уделяется деталям, не относящимся к сути проекта.
  • Недостаточно времени уделено этапу исследований и проектирования архитектуры. Или наоборот — уделено слишком много времени.
  • Недооценка потенциальных проблем интеграции со сторонними системами.
  • Стремление «сделать всё правильно с первого раза»
  • Параллельная работа над слишком большим количеством проектов или отвлечение (слишком частое прерывание потока).
  • Несбалансированное соотношение качества и производительности.

Чрезмерный оптимизм, эффект Даннинга-Крюгера, чистая неопределённость или просто математика?



Пятая стадия: ПРИНЯТИЕ.

Сразу можно отбросить чрезмерный оптимизм — логично, что ни один разработчик, когда-либо испытывавший проблемы с дедлайнами, не будет оптимистичен при их выборе. Если же руководство проекта не имеет инженерного опыта и не понимает, что делает, то это тема для совершенно другой статьи.

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

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

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

Это просто математика!



Однажды я выполнял задачу, которая должна была занять 10 минут, но в конечном итоге потребовала 2 часа. Я начал размышлять о том, почему решил, что она должна занять 10 минут, и как это число выросло до 2 часов. Мой мыслительный процесс был довольно интересным:

  • Я считал, что это займёт 10 минут, потому что в голове на 100% знал код, который нужно написать.
  • Написание кода и в самом деле потребовало примерно 7–10 минут. А потом потребовалось 2 часа из-за совершенно неизвестного мне бага во фреймворке.

В управлении проектами подобное любят называть «форс-мажором» — внешними неконтролируемыми причинами задержки.

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

Здесь нам нужно провести границу между одиночной задачей, нерепрезентативной для всего процесса, и наоборот.

Как мы оцениваем время в «нормальных» условиях



Нормальное распределение (гауссиана)

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

Если в этом месяце вы ходили в ближайший магазин почти 20 раз и каждый раз путь занимал 5 минут, за исключением случая, когда сломался лифт и вам пришлось прождать 10 минут, а ещё того случая, когда вы решили подождать две минуты, пока закончится дождь. Сколько по вашим оценкам понадобится времени, чтобы добраться до магазина прямо сейчас? 5 минут?

Я имею в виду, что не имеет смысла говорить «15 минут», потому что это редкий случай, или «7 минут», если только на улице нет дождя. И с большой вероятностью вы окажетесь правы. Если в 18 из 20 случаев путь занимал 5 минут, то определённо существует высокая вероятность, что он займёт 5 минут (медиана) и на этот раз. Вероятность примерно равна 90% (если, разумеется, не вдаваться в более сложные вычисления).

Но график искажён!


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

Все читающие статью нерды-математики (и дата-саентисты/статистики) уже должны были узнать в крошечном графике из предыдущего мема скошенное вправо нормальное распределение. Увеличим его и объясним, что оно означает:


Для этой отдельной задачи медиана (median) по-прежнему имеет более высокую вероятность, чем среднее (mean)! Если вы попытаетесь угадать значение моды (mode), имеющей наивысшую вероятность, то при увеличении объёма задачи ошибётесь ещё сильнее

Видите, что здесь может пойти не так? Наша «естественная» догадка основана на медиане, максимизирующей вероятность правильной догадки, однако реальное число при выполнении «события» достаточное количество раз всегда будет стремиться к среднему. Другими словами: чем больше похожих задач вы выполняете, тем сильнее накапливается эта погрешность!


Уравнение задержки на основании этой гипотезы

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

Как же воспользоваться этим знанием?


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

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

  1. Проще сказать, займёт ли задача X больше/меньше/столько же времени по сравнению с задачей Y, чем точно определить, сколько займёт их выполнение. Так получается, потому что если скошенность кривых приблизительно одинакова (что справедливо для похожих задач), то сравнение медиан даёт примерно такие же результаты, как и сравнение средних.
  2. Я не запоминаю и не записываю каждую отдельную задачу, чтобы проводить вычисления и получать среднее (и не могу найти никаких данных для таких опытов). Поэтому я обычно оцениваю неизбежную погрешность (среднее-медиана) как процент от времени на задачу, который увеличивается/уменьшается в зависимости от того, насколько я освоился со средой разработки. (Нравится ли мне этот язык/фреймворк (40%) Есть ли у меня хорошие инструменты отладки? (30%) Хороша ли поддержка IDE? (25%) … и т.д.).
  3. Я начал разделять спринты на задачи равного размера чтобы обеспечить некую однородность процесса оценки времени. Это позволяет мне воспользоваться пунктом 1. Бывает легко определить, что две задачи примерно равны по времени. Кроме того, это делает задачи ещё более похожими на то, к чему применима гипотеза, и всё становится более предсказуемым.
  4. Применив эти принципы, при наличии ресурсов можно организовать «тестовый прогон». Например, если за X1 дней Y1 разработчиков выполнило Z1 однородных задач, то мы можем вычислить X2 (дней), зная Y2 (количество имеющихся разработчиков) и Z2 (общее количество оставшихся задач).




На правах рекламы


Эпичные серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и NVMe хранилища для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN.

VDSina.ru
Серверы в Москве и Амстердаме

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

    +37
    Просто оцени правильно время заранее
    — Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
    — Представь что тебе надо разгрузить машину, сколько времени это займет?
    — Пару часов
    — Это камаз
    — 8 часов
    — Камаз, груженый песком
    — 12 часов
    — У тебя нет лопаты и инструментов, только твои руки
    — 2 дня
    — На улице -40
    — 4 дня
    — Камаз вообще под водой
    — Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
      +18
      Как говорил Вадим Макишвили из Яндекса:
      «В молодости я спросил у начальника, как оценить время на выполнение работы? И начальник ответил мне:
      — Время, которое ты планируешь, умножить на Пи пополам, плюс 2 недели.
      — Почему Пи пополам? — удивился я.
      — Потому что в реальной жизни ты никогда не будешь двигаться к своей цели напрямую, а скорее — по дуге окружности.
      — А почему плюс две недели?
      — А потому, что когда ты в итоге просрёшь все сроки, то за две недели хоть что-то успеешь сделать.»
      makishvili, прошу прощения, если слегка художественно переврал ваши слова :)
        0
        Задача начальника прежде всего оценить полезный/вредный эффект от выполненной задачи. А это тоже не оценивается.
        +3
        Камаз, груженый песком, разгружается примерно полторы минуты.
        Если он под водой при -40°С — разгружать его вообще не нужно.
        :)
          +13

          Это если спросить сеньора который разбирается в фреймворке

            +7
            А джун пойдёт искать ледоруб… И может даже начать рубить лёд. Пока его не остановит сеньор.
              0
              Кстати очень интересный момент. Начальники любят таких, которые готовы по незнанию браться за любую задачу, которая взбредёт им в голову. Кого выбрать? — бодрого джуниора или занудного синьёра, которого с места не сдвинуть?
                +2

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

                  +1
                  А потом окажется, это был не тот камаз, переделывай. И грузить надо было только песчинки с 16 углами, остальные — вернуть на место. Или занести каждую песчинку и ее количество углов в эксель, чтобы кто-то мог построить красивые графики. В итоге, на одной из таких итераций даже у такого несгибаемого джуна где-то в мозгу что-то зашевелится и в следующий раз он попытается всё уточнить до того, как снова возьмется за ледоруб (наивно полагая, что в момент погрузки не прилетят новые требования). Осознание бесполезности работы в таких ситуациях убьёт любую оставшуюся мотивацию и приведёт к написанию на хабре статьи «как я выгорел в свои 21».
                  0
                  так-то да, только по тексту — трата времени на совершенно ненужную задачу в принципе, вместо решения реальных проблем/задач по проекту… ощущение, как будто задачу по разгрузке КАМАЗа с песком под водой в -40 ставил эффективный менеджер
              +2
              У него сломан механизм подъема
              Разгрузить надо равными частями в 10 разных местах
              У Камаза кончилась солярка

              Вечно вы что-нибудь придумываете!
                0
                Берётся детский совочек и ведёрко, и задача оценки времени, требующегося на разгрузку Камаза, становится значительно легче.
                  +1

                  Это под водой то и в -40? Ну как скажете товарищ. Только видится мне, что при исходных данных оценка займет по времени ровно столько же (если не больше) сколько и сама реализация. И что то мне подсказывает, что через пару месяцев менеджмент начнет подозревать что то не ладное.

                +2
                А потом оказывается, что он ниже точки промерзания (следовательно надо сначала прорубь), и там вообще не песок, а плиты, и Камаз бортовой
                  0
                  И в другом городе.
                0
                для того, чтобы корректно определить время, которое надо потратить на работу, надо знать сразу все условия
                  0
                  Так в материале как раз указано про то, что есть обстоятельства, которые сложно предугадать, с чем сталкивается и крупные компании
                  +1
                  Жизненно! :)))
                  0

                  Слышал вариант: "планируемый срок исполнения увеличить в двое и перевести в следующую единицу измерения ". Из одного дня получаются две недели.

                    +16

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

                      +5

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

                        0
                        Но строители хорошо справляются с этой задачей!
                          0

                          ну наймите строителей оценивать сроки )))


                          Мне ремонт обещали за 3, а делали 4 месяца.


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


                          первое что нагуглилось https://www.irn.ru/conf/103/

                            +1
                            Не смотря на то, что постройка дома предваряется получением проекта, в котором расписаны все детали с точностью до сантиметра и все процессы с точностью до дня, чего в программировании пойди найди, я многократно видел перенос срока сдачи дома на полгода, а некоторые дома и по несколько лет сдать не могут. Потому что строительство — это не только арматуру сварить и цемент размешать. Так и в разработке — реализация новой фичи не заключается в одном только написании кода.
                              0
                              Уже ответили, но добавлю, что мне застройщик деньгами компенсировал 2 месяца опоздания сдачи дома.
                                0
                                С оценкой времени постройки очередной типовой панельки?
                                Ну окей, я могу точно оценить, что я исправлю баг за тоже время, что я его исправлял. Если конечно будет та же самая кодовая база и тот же самый баг.
                                  0
                                  Но строители хорошо справляются с этой задачей!

                                  Когда строят одинаковые дома — да, справляются. Потому что всё уже известно.
                                  При попытке построить что-то уникальное — у строителей наблюдается постоянный выход за бюджеты сроков и денег, вплоть до умопомрачительных многократных масштабов от первоначальной стоимости/сроков.

                                +1
                                Я прикидываю время, за сколько бы я это сделал, потом умножаю на Пи — получается примерно похоже на правду))) Проблема в том, что помимо этой задачи еще много рутины…
                                  0

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

                                    0

                                    Мой прошлый шеф говорил: "У нас сильная команда разработчиков, поэтому время мы умножаем на 2. Была бы обычная команда — умножали бы на три"

                                      0

                                      А как рутина влияет на количество часов, которые нужно потратить непосредственно на задачу?

                                        0
                                        Количество часов – это трудозатраты. А трудозатраты != срок. На задачу надо в общей сложности 4 часа, но вы сперва эти 4 часа найдите в череде встреч, совещаний и «отложи всё, сделай это, потому что срочно прям вчера уже горит». В итоге 4 часа легко и непринуждённо превращаются в две недели.
                                          0

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

                                            0
                                            А это именно то, о чём я говорю. Вы говорите про трудозатраты в два, условно, дня. А менеджер слышит от вас, что вы сделаете это за два дня. Через два дня менеджер приходит — ничего не сделано. Как так?

                                            И тут выясняется, что вы сделали бы это за два дня, если бы все вокруг про вас на эти два дня забыли и забили — не звонили бы, вопросов бы не задавали, на совещания бы не звали, в почту и прочие слаки не писали бы.

                                            Именно об этом весь сыр-бор. Количество часов вы назовёте весьма точно, я не сомневаюсь. А вот срок — дату на календаре — когда задача будет реально готова? Можно не отвечать, у меня те же проблемы. Вроде и простенькая задачка — сесть и сделать (я не разработчик) за пару часов. Ан нет — этому ответь, того проконсультируй, тут совещание, там опять у кого-то горит на ровном месте. И в итоге простенькая задачка, не переставая быть простенькой, решается неделями.
                                              0
                                              Вы говорите про трудозатраты в два, условно, дня. А менеджер слышит от вас, что вы сделаете это за два дня. Через два дня менеджер приходит — ничего не сделано.

                                              В этом случае нужно решать проблему с коммуникацией. Говорите менеджеру, что на задачу нужно потратить 16 человекочасов, а не 2 дня. И объясните, что вы программируете не 8 часов в день. Какой-нибудь трекер учета времени легко поможет самому понять, на что вы его тратите и менеджеру потом объяснить. Попробуйте как-нибудь.


                                              А вот срок — дату на календаре — когда задача будет реально готова?

                                              Если у задачи есть приоритет и она должна быть готова к определенному сроку (в силу каких-либо обязательств), она будет к нему готова. При этом все менее приоритетные задачи откладываются. Если кто-то пытается всунуть менее приоритетную задачу в таймлайн, сразу же нужно говорить, что дата реализации изначальной фичи отодвигается. Вроде простой тайм менеджмент же.


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

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

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

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

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

                                      То есть грубо говоря, если в проекте не описывают только CRUDы, то разработка оценивает не «разгрузку грузовиков с песком», как в комментариях выше, а дает оценку проекту и реализации механизма, который мог бы разгружать разные грузовики в разных условиях при наступлении всяких событий, причем наборы этих «разных и всяких» меняются и их обычно надо при оценке прикинуть самостоятельно и задать наводящие вопросы.
                                        +1
                                        Обычно для оценки трудоемкости разработчик вытаскивает из своего «портфолио» хоть как-то похожий проект, и называет срок, отталкиваясь от этого. Типа, «Мы недавно подобное устройство, только для нефтехимии, за полгода сделали. Надеюсь, тут примерно столько же потребуется») Но иногда происходят знатные казусы.

                                        Например, когда от инженера требуется назвать срок разработки еще до того, как написано нормальное ТЗ, а вместо него подсовывают только «хотелки». Причем возражения, что «без подробного ТЗ, результат будет ХЗ», к сведению не принимаются. Прямо, как в армейском анекдоте «Поехали, потом заведешься».

                                        Сколько раз бывало, что проекту на переход от стадии Ознакомились с ТЗ к стадии Что-то вроде «задышало». потребовалось, например, два месяца.
                                        И сотрудники коммерческого отдела сделали вывод, что «Раз они самое сложное сделали за два месяца, то через неделю можно продавать.».

                                        И тут оказывается, что для перехода к следующей стадии развития проекта (Когда Все готово, проверено, мин нет) может внезапно потребоваться и полгода, и год, и больше. Потому что сейчас проект работает только в режиме «Руками не трогать!!!». А в ходе опытной эксплуатации выползают такие нюансы, которые почему-то никому на стороне заказчика не приходили в голову на этапе написания ТЗ. И хорошо, если заказчик понимает причины этого явления. («Да все нормально, не переживайте. Чтобы с первой попытки все прямо вот взяло и заработало — так не бывает. Мне уже очевидно, что вы на верном пути. Продолжайте работать»)

                                        Бывало и так, что многие тонкости казались заказчику настолько очевидными, что он просто поленился их подробнее расписать в ТЗ. А вопросы (типа, Как это должно выглядеть, чтобы оператору было удобнее? А вот такая ситуация возможна? А что в этом случае делать?), которые ему явно пытались задавать разработчики, оставались без ответа (Типа, «Заняты все были...»).

                                        Ну и про «блуждания пьяного человека» (то есть про многочисленные изменения в ТЗ, вносимые на разных сроках разработки), уже куча копий переломано.

                                        Хотя много раз было и так, что на реализацию какой-то мелкой фичи достаточно опытному инженеру внезапно потребовалось несуразно большое количество времени. Потому что в процессе работы открылась самая натуральная пучина, и фича оказалась не такой уж мелкой, какой казалась в начале…
                                          +1
                                          Неправильная оценка времени (основная тема этой статьи).

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


                                          время выполнения задачи = объем задачи / скорость выполнения


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


                                          Украшательства: слишком много внимания уделяется деталям, не относящимся к сути проекта.

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


                                          Недостаточно времени уделено этапу исследований и проектирования архитектуры. Или наоборот — уделено слишком много времени.

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


                                          Недооценка потенциальных проблем интеграции со сторонними системами.

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


                                          Я бы еще добавил:


                                          • Фетишизм и фричество (девопс, тдд и т.д.)

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

                                            0

                                            Типовые задачи тоже не имеют оценки… На одном из курсов препод спрашивал — за сколько времени вы покрасите стенку? Кто-то отвечал- за 2 часа. Хорошо, через 2 часа приду преверю. Хотя через 2 часа только кончалась лекция

                                            0

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

                                              +3

                                              Мне понравилось как Роберт Мартин сказал, примерная цитата: если Вам нужен функционал, который уже кем-то сделан, просто возьмите эту реализацию; если этот функционал раньше никто не реализовывал, то как можно его оценить?

                                                0

                                                Даже если кто-то реализовывал, то вряд-ли поделится информацией и тем более исходниками.

                                                  0

                                                  Из какого года пишете нам? Опенсорс еще пока не изобрели? :)

                                                    0
                                                    Ну тогда попросите исходники у какой-нибудь финансовой конторы.
                                                      0
                                                        0
                                                        Довольно редкое явление для коммерческих контор. Уход исходников — дыра в безопасности.
                                                          0
                                                          В процессингах так вообще единственное. Как говорил Антон (СТО RBKMoney), это способ показать рынку, что у них достойное решение среди вендоров.
                                                          А про безопасность, то как раз это работает с точностью наоборот, опенсорц более защищённый.
                                                            0
                                                            Защищенный, когда проект по опенсорсу разрабатывается с самого начала, и при этом у него есть достаточно много сторонних заинтересованных в его развитии разработчиков. А когда что-то, разрабатываемое в уютном ентерпрайзике, уплывает в свободный доступ, то тут возможны разные неприятные сюрпризы.
                                                              0
                                                              Непонятно, — каким образом открытый исходник доказывает, что решение достойное? Я не видел способа доказать, что программа работает корректно. Есть конечно статические анализаторы, но это не гарантия.
                                                              0

                                                              еще пример :)
                                                              даже не один

                                                                0
                                                                Т.е. единственный фиговый листок, прикрывающий этот насос по перекачке денег — это незнание из каких каловых масс он сделан?
                                                            0

                                                            Колесо вот тоже давно реализовано, только оно слегка разное у КАМАЗа и приоры.

                                                        0

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


                                                        Сложно расчитать точное время выполненмя, но можно пойти по-другому критерию.По сложности проета в целом и в частности.
                                                        Дя, для этого нужны примеры прошлых работ, но сравнить сложность с чем-то эталоным, приняв его сложность средней, намного проще чем прикинуть время.А потом просто умножить соответственный колфецент сложности(например лёгкая -0.5, средняя 1, сложная 3, можно заморочится и придумать сложную шкалу, формулу и т.п.) на коофецент форс-мажоров(например взять его 1.5, а потом коректировать на основе опыта), а после умножить на время выполнение эталоного проекта.


                                                        Проблема в том, что если ТЗ меняется во время проекта, то надо умножать получившиеся число сразу на 5-10, ибо адекватная оценка в этом случае, почти не возможна.

                                                          +5
                                                          Универсальная таблица оценки задач
                                                          изян — 1ч
                                                          изи — 2ч
                                                          просто — 4ч
                                                          вроде просто — 6ч
                                                          норм — 8ч
                                                          норм так — 12ч
                                                          хз — 16ч
                                                          хз как-то — 20ч
                                                          как-то сложно — 24ч
                                                          сложно — 30ч
                                                          очень сложно — 40ч
                                                          б*я — 48ч
                                                          п*здец — 60ч
                                                          п*здец какой-то — 80ч
                                                          вроде изян — 100ч
                                                            +3

                                                            В свое время присутствовал на докладе Woody Zuill, "Estimates or NoEstimates?" (на ютюбе есть запись). Идея в том, что оценка времени на реализацию — самоцель — на самом деле нужно не число, а некая уверенность что работа вообще будет сделана. В докладе много психологии в стиле "на кой хрен тебе вообще эта оценка?".


                                                            Наша команда взяла на вооружение и мы оцениваем не время на выполнение, а сложность задач — если задача достаточно маленькая чтобы быть реализованной за время спринта — мы ее берем в спринт. Если большая — разбиваем на задачи поменьше, пока не получим достаточно маленькие задачи. А дальше — методом проб и ошибок приближение по трудоемкости команды, приоритеты от продуктов и проч. И мы еще не научились закладывать время на "то что нам накинут сверху". Пока вроде более-менее работает.


                                                            Но исходя из многолетнего опыта, все эти оценки — херня, нету хоть сколько точного метода оценки, всегда будут ситуации когда сроки прогорят (прилетит "вот это капец срочно!" от начальства — и никакой скрам не спасет, ну или кто-то будет пилить тривиальную задачу весь спринт и все равно не уложится). Да и трудозатраты на все эти оценки часто могут быть потрачены с много большей пользой на собственно решение задач, а не на их оценку.

                                                              0
                                                              Очень часто так получается что на первый взгляд тривиальная задача в реальности оказыватется каким-то лютым, хтоническим пиз… ом. Да вот как раз сейчас такой занимаюсь, взял простенькую задачку, что-бы заняться хоть чем-то перед крупным проектом, думал за неделю неспешной работы легко все сделаю… Полез в код а там такое… вторую неделю уже копаюсь и света в конце тоннеля не видно. Одна задачка тянет за собой несколько, другие задачи из этих связанных цепляют на себе еще задачки, те тянут другие… Причем предвидеть это заранее было практически нереально, код проекта очень «своеобразный» — последствия многолетней работы команды любителей сделать все круто, в их понимании крутизны. Огромные разлапистые иерархии, велосипедная кодогенерация, несколько велосипедов-фреймворков, чудовищная система наименования пакетов и объектов. И в итоге простая задача вида — исправить поведение программы на паре формочек вылилась в какую-то неслабую такую задачу с переписыванием кучи классов.
                                                                0

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

                                                                +2

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

                                                                  +1
                                                                  Я так же пытался делать, но мне постоянно говорили, что либо оценки завышены, либо из-за высокой длительности делать не будем. А через 30 минут передумывали и давали задачу джуну за 1\30 моей оценки реализовать. Ну и естественно результат был предсказуем) Время потрачено, задача не сделана или не работает реализация.
                                                                  0
                                                                  Потому что не могут все факторы влияющие предсказать. А так оптимально для себя вывел закладывать на задачу в среднем на 30% больше, чем представляешь изначально
                                                                    –1

                                                                    Спасибо за статью! Вы переизобрели story points)

                                                                      +3
                                                                      Ну вот реально — а чем сторипоинты лучше? Такая-же оценка наудачу без каких-то гарантий достоверности оценки. Более-менее она близка к реальности при потоке типовых «мартышкиных» задач, в которых ну совсем уж ничего неожиданно сложного быть не может. Любая более сложная задача может подкинуть сюрпризы (и обычно подкидывает).
                                                                      0

                                                                      Статистика с тяжелыми хвостами. Матожидание невычимлимо.

                                                                        0
                                                                        Почему нельзя оценить время разработки проекта? Даже если остальные условия, не связанные с процессом разработки будут соблюдены идеально, то оценить можно только свои силы и знания, которые будут использованы в проекте, но редкий инженер выполняет проект с нуля сам и это иногда может оказывать существенное влияние на сроки.
                                                                          0
                                                                          Из опыта любой адекватный начальник знает какой объем работы примерно за какое время делается и какие ресурсы для этого надо. А дедлайн ставится в обычных условиях с запасом.
                                                                            0
                                                                            «Если же руководство проекта не имеет инженерного опыта и не понимает, что делает...» начальство чаще всего хочет как можно быстрее срубить бабла. Отсюда короткие сроки, пятая точка в огне и грусть в глазах айтишников.
                                                                            Тут даже киберпанк в пример привести можно
                                                                              0
                                                                              Простое правило, которое еще никогда не подводило — умножить на 2 и прибавить 100%.
                                                                                0
                                                                                простите, позанудствую:

                                                                                y = x * 2 + x
                                                                                y = x * (2 + 1)
                                                                                y = x * 3

                                                                                или это какая-то цитата, с которой я не знаком
                                                                                  0
                                                                                  Занудствование принимается, хотя то всего лишь игра слов. )) Но правило железобетонное (аксиома, если хотите), и ни один ПМ еще не смог его опровергнуть.
                                                                                    0
                                                                                    Меня учили в таких случаях использовать Пи/2 для знакомых задач, Пи или е для новых.
                                                                                  0
                                                                                  Мне в зеленом детстве начальник говорил так: умножить первую оценку на 2 и сделать инкремент единиц измерения. То есть, работа, оцениваемая в 1 час, будет выполнена за 2 дня. А требующая пары дней — за 4 недели.
                                                                                  Я не совсем программист, но это реально работает ;-)))
                                                                                  0
                                                                                  Написание кода и в самом деле потребовало примерно 7–10 минут. А потом потребовалось 2 часа из-за совершенно неизвестного мне бага во фреймворке.
                                                                                  То есть прогноз оказался верным, но в скопе задач появилась новая «разобраться с багом фреймворка».
                                                                                  Аналогичная ситуация в многочисленных кейсах «изменилось ТЗ» — появляются новые задачи, а не изменяется ранее оцененная.
                                                                                  Поэтому можно утверждать, что опытные программисты практически всегда верно оценивают трудоемкость задач, проблемы вовсе не в эстимейтах.
                                                                                  Варианты проблем, приписываемых программистам, якобы срывающим сроки:
                                                                                  — Часть времени съели задачи, подкинутые вне очереди. Включая те блокеры, которые возникли в процессе работы, будь то особенности фреймворка, подводная мина в легаси или разгребание ошибок оператора.
                                                                                  — Программиста вынудили оценивать задачу с недостаточно четким ТЗ, и когда программист сказал «от двух часов до двух месяцев без гарантии завершения», менеджмент не захотел услышать окончание фразы.
                                                                                  — Кто-то начал считать эстимейты достаточным поводом для назначения дедлайнов. Особенно это прикольно выглядит, когда есть зависимости — для продолжения работы необходимы телодвижения со стороны, и ждать этих телодвижений иногда приходится неделями.
                                                                                  — Часть времени съели совещания, больничные и прочие факторы, которые менеджмент не умеет учитывать, гибко изменяя график работ.
                                                                                    0

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


                                                                                    У меня было несколько проектов в которых у меня не спрашивали сколько времени потребуется, просто ставили перед фактом, через месяц первая версия должна быть отгружена заказчику. При этом у нас даже опыта в этих областях не было. Сейчас, я бы сказал, этого сделать нельзя, а кто попытается это сделать — авантюрист. Но тогда мы это делали. Был реально драйв. Были довольные заказчики. Было довольное начальство.


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


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

                                                                                      0

                                                                                      Метод определения сроков выполнения проекта по Бобуку-Бацеку
                                                                                      https://youtu.be/XUqiMEh2PMc

                                                                                        0

                                                                                        http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk Не устаревший блиц-доклад, обосновывающий «умножение на Pi», тремя разными моделями реализации проекта (пуассоновский поток, логнормальное распределение, броуновское движение)

                                                                                          +1
                                                                                          Я начал разделять спринты на задачи равного размера чтобы обеспечить некую однородность процесса оценки времени.

                                                                                          У вас есть пара конкретных примеров? В теории этот пункт звучит достаточно разумно и понятно, однако мне сложно представить как можно сравнивать затраты по времени на задачи разного содержания и приоритета.

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

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