Об оценках сроков в разработке ПО

Автор оригинала: Denis Stebunov
  • Перевод
В течение всей истории разработки ПО мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

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

Оценки тормозят работу команды


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

Вопреки интуиции, называние сроков «с запасом» вовсе не обязательно помогает в них укладываться. Этот эффект известен как Первый закон Паркинсона, здесь психология играет против нас. Представьте, что вы предполагаете, что задача займет пару дней. Однако, с учетом всего неизвестного и с учетом прошлого печального опыта, вы называете срок «неделя». Допустим, ваш менеджер говорит «окей», и вы принимаетесь за работу. Первое ощущение, которое у вас есть — времени достаточно! Вы только что договорились на срок с хорошим запасом. Поэтому первая половина недели проходит или в расслабленном режиме, или, что чаще, вы переключаете свои приоритеты на другие задачи, на которые раньше все никак не находилось время. По мере того как назначенный срок приближается, вы принимаетесь за работу основательно, и вот тут начинают всплывать как раз те самые неожиданности, на которые вы, собственно, и закладывали запас. Вы упорно трудитесь, возможно, засиживаетесь на работе допоздна и в итоге с трудом укладываетесь (или не укладываетесь) в срок, который вы сами себе назвали «с запасом». В следующий раз та же самая история повторяется снова.

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

Продуктивность в зависимости от подхода к оценкам

Источник: Том ДеМарко и Тимоти Листер, Человеческий фактор

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

Пальцем в небо


Сложность и неопределенность — постоянные спутники разработки ПО. Почти все, что мы делаем как разработчики, это что-то новое. Даже если мы делали что-то похожее в прошлом, теперь мы делаем это в новых условиях. Это может быть новый проект, или новые требования, или наши знания, полученные за время прошедшее с прошлого опыта. Если же задача является типовой и регулярно повторяющейся, то ее наверняка уже кто-то автоматизировал и предложил в виде готового продукта, библиотеки, или фреймворка. Таким образом, в подавляющем большинстве случаев разработчикам приходится давать оценки на задачи с высокой степенью неопределенности.

Figuring out what to do - Getting it done

Источник — Show Progress | Shape Up by BaseCamp

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

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

Оценки создают опасные искажения


Плохая точность — это не единственная проблема оценок. Помимо этого, они искажают представления о том, как вообще происходит разработка ПО. Как сказал Фред Брукс, «вынашивание ребенка занимает 9 месяцев, вне зависимости от того, скольким женщинам это поручено». Однако, когда люди слышат, что «проект займет 9 человеко-месяцев», они могут подумать, что это по сути 3 месяца работы для команды из 3-х произвольных разработчиков.

Мифический человеко-месяц

Источник: Фредерик Брукс, Мифический человеко-месяц

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

Первоначальная разработка — это меньшая из затрат


image

Люди постоянно спрашивают оценки на первоначальную разработку, но мало кто интересуется оценками на последующую поддержку решения. И это большая проблема, поддержка — это очень серьезно. Поддержка может занимать до 60-80% всех затрат на проект. Кроме того, каждая новая фича, которую вы добавляете в продукт, добавляет сложности и замедляет последующую разработку.

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

Как управлять проектом без оценок


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

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

Во-вторых, если у вас есть определенный дедлайн или ожидания от бизнеса, в которые надо уложиться, сообщите их вашей команде, вместо того чтобы запрашивать их оценки. Есть замечательный подход Fix Time and Budget, Flex Scope. Каждую задачу можно решить множеством разных способов. Тщательно приоритезируйте требования и работайте над ними начиная от самых важных к менее важным, и будьте готовы запустить проект в любой момент времени. В таких условиях работать с дедлайнами гораздо проще. Даже если вам не удастся полностью закончить проект к сроку, вы успеете выполнить наиболее важные требования и будете готовы к запуску — и зачастую это именно то, что нужно.

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

Управление ожиданиями


Это, пожалуй, самое сложное. Как менеджер или тимлид вы будете регулярно иметь дело с людьми, желающими знать, сколько времени займет тот или иной проект. Если вы спросите, зачем людям нужна эта информация, они обычно скажут, что или для планирования, или же просто хотят знать, чего вообще ожидать. Мы поговорили о планировании выше, теперь давайте поговорим об ожиданиях. Ожидания — это естественно; человеку свойственно волноваться по поводу неопределенности в чем-то, что ему небезразлично. Иногда оценки спрашивает ваш руководитель, и вы не можете просто так ответить ему «я не знаю». Что вы можете сделать:

  1. Если задача уже взята в разработку или находится в очереди на разработку, спросите, какие есть планы, связанные с этой задачей. Постарайтесь помочь в достижении этих планов. Иногда разговоры о планах дают полезную вводную информацию для команды разработки. Возможно, будет достаточно предоставить упрощенный вариант на первое время. А иногда вы можете помочь найти какой-то обходной путь, который может использоваться, пока основное решение разрабатывается;
  2. Если задача еще не взята в разработку, уточните про ее приоритет. Поговорите о том, какая работа уже запланирована для команды, и подумайте вместе, как новая задача вписывается в эти планы. В некоторых случаях вы можете обнаружить, что нет никаких шансов взяться за эту задачу в обозримом будущем, а раз так — то и разговор об оценках не имеет смысла;
  3. Фокусируйтесь на продуктивности команды и прозрачности ее работы. Если ваша команда релизит в прод каждый день и все могут это видеть и видеть вашу очередь на разработку — люди будут менее склонны к запросам оценок;
  4. Как менеджер или тимлид держите руку на пульсе и будьте постоянно в курсе, что уже сделано, что еще осталось и какие есть препятствия. Если вы хорошо представляете себе картину происходящего, при необходимости вы сможете дать свои собственные оценки руководству, если посчитаете нужным. Помните, хорошие менеджеры защищают команду от всякого дерьма, плохие менеджеры просто пропускают дерьмо прямым потоком в команду. Прямая передача разработчикам всех запросов на оценки не является хорошей практикой.

Заключение


Оценки могут казаться естественными и даже необходимыми, но очень часто они просто вводят людей в заблуждение и тормозят разработку. Для людей естественно упрощать сложные для понимания вещи, но оценки часто упрощают понимание процесса разработки ПО сверх всякой меры. Scrum способен возвести это чрезмерное упрощение в культ, со своим Planning Poker (tm), измерением Velocity и графиками Burndown charts.

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

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

Подробнее
Реклама

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

    +16

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


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


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

      0

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

        0
        когда руководитель давит на разработчиков или берет на слабо, в стиле «а вот ХХХ сделает это в 2 раза быстрее»

        Я обычно говорю: «отлично! отдайте это ХХХ!»
          0
          +1. Тоже так делаю. Потом часто выясняется, что XXX нехило так охреневает от своих возможностей и вообще никаких оценок не давал.
      +5
      Вот только как заказчику сказать «сделаю за сколько получится» и при этом выиграть заказ?
        +4
        Сложно, да. Заказная разработка с фиксированными бюджетами — это отдельная боль. Впрочем, даже и в заказной разработке есть примеры, когда люди успешно применяют «Fix Time and Budget, Flex Scope», например Бюро Горбунова.

        Иногда удается применить комбинированный подход, например, начать работать с фиксированными бюджетами, а потом, по мере роста доверия заказчика к вам, перейти на работу по фактически затраченному времени. У меня есть знакомые, у которых так получалось.
          0
          Тут сразу сказали «выиграть заказ».
          Т.е. речь идет об уровне КП. В статье хорошо всё описано когда заказ ваш, но нет понимания об оценках до получения заказа.
          Ну и нельзя дать разработчику 2-3 дня, если клиент эти дни не оплатил.
            0
            Интересно описано, спасибо.
          +2
          Подгонка закрытия задач под рамки итераций — это одна из проблем скарама. Для её решения есть Scrumban. Оценки получаются гораздо точнее если над ними подумать денёк. Никто не сможет дать правильную оценку без кода, требований и за 15 минут.
            +3
            Вот именно что никто не сможет, а менеджеры требуют, иначе спринт не запускается. Причем там времени на оценить от 10 секунд до 1 минуты во время планирования пока распределяются задачи. И такие компании через одну, а то и чаще.

            Даже подумав денёк, всё равно невозможно предусмотреть все нюансы, которые могут всплыть при разработке.
              0

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

            +11

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


            Сначала менеджер говорит дай хоть что-то, а потом почему не сделал как сказал

              +6
              Наконец-то кто-то сформулировал всё то с чем я сталкивался в компаниях скрам-наше-всё. Всё что заставляло людей уходить из компаний. Прекрасно описано то, к чему приводит зацикливание на оценках всего и вся, рост техдолга, дискомфорт команды, давление, которое в итоге заставляет человека просто уйти. Почему так мало людей, которые понимают это и используют нормальный здравомысленный подход к управлению проектами?

              Забыли ещё в статье упомянуть так называемых бизнес-аналитиков, которые мониторят «эффективность» каждого сотрудника на основе этих вот оценок в часах, и увольняют тех, кто не укладывается в спринт.
                0

                Есть вероятностные оценки. Самое простое это определить срок как (пессимистичная оценка + оптимистичная оценка + обычная оценка*4) / 6. Плюс скрам говорит, чтш при понимании, чтш не укладываешься в эстимейт, надш сразу доносить эту инфу наверх, чтобы у покупателей всегда была актуальная информация.

                  0

                  97.578% оценок вероятностные :)


                  А где скрам такое говорит? Где в скраме вообще работа с эстмейтами прописана?

                  –2

                  Спасибо за статью. Я разработчик, но сейчас прохожу менеджерский курс на курсере, где в том числе обсуждаетсят планирование бюджета и сроков проекта.
                  Все, что описано в статье — далеко не новость для менеджеров (с образованием конечно, а не самоучек). Более того, есть решения всех этих проблем, проверенные временем. Когда брать оценки, кого к этому привлекать, делать ли какие-то допущения по оценкам или нет и на каком этапе их делать, что вообще означает невыполнение оценки, кто несёт ответственность если несёт, есть ли какой-то резервный бюджет на случай если оценки профакапились, и если есть — то на каком уровне, и кто может его вскрывать — все эти вопросы весьма четко обсуждаются в менеджерских курсах по PMBOK.
                  Разработчикам надо просто чуть поменьше думать не о своих проблемах. Имхо это вообще проф деформация программистов, когда они начинают думать обо всем на свете, залезая не в области своей компетенции.
                  Все сказанное, конечно, относится только к командной работе, где есть project manager с образованием.

                    +2
                    Это не профдеформация, а некомпетентность руководства, которое требует от программистов что-либо помимо непосредственно программирования. В реальности в огромном количестве компаний программисты вынуждены заниматься и менеджментом, и общаться с клиентами/заказчиком и много чего ещё, о чем на курсах могут не рассказывать. Только поработав в нескольких разных организациях видишь сразу разницу где нормально всё, а где нет. При некомпетентном руководстве зачастую не поможет даже менеджер с образованием) Всему виной желание руководства на всём экономить.
                      +4

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

                        +2

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

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

                        В теории, нет разницы между теорией и практикой
                        На практике — она есть

                        Или вы думаете, что во всех компаниях одни дураки сидят, а тут вы в белом с дипломом придёте?
                          +4
                          Почему во всех? Лично у меня в тех компаниях, где я работал, кроме самой первой все было отлично с менеджментом. Так что я не понимаю, откуда вы обобщение взяли.
                          Во-вторых, я подозреваю, что во многих компаниях IT-менеджеры — это программисты, которые не очень хорошо программируют, но хорошо «болтают языком». Поэтому они стали подниматься по этой лесенке. При этом по какой-то причине они не получают нормального менеджерского образования, и от этого, возможно, начинают изобретать велосипеды, которые иногда никуда не едут. А потом от этого появляются статьи, подобные этой, где программисты начинают советовать свои велосипеды.
                          Надо для начала читать теорию (не вам, менеджерам). Вот и я вся моя мысль.
                            0

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

                              0

                              Плюс вам от меня! Могу только на словах пока…
                              Я также считаю и вижу что в разработке ПО именно повальный непрофессионализм и рождает все эти айтишные "алхимии", "астрологии" и "метафизики". Причины для меня очевидны — дикое желание сэкономить сверху и дикое желание "кушать" снизу, а поверх всего отсутствие требовательного рынка. Подавляющее количество ПО не является жизненно-критичным, кое-как да справляется с поставленными задачами. А как следствие рынок вполне устраивает положение дел.

                          +2
                          "… Тщательно приоритезируйте требования, и работайте над ними начиная от самых важных к менее важным, и будьте готовы запустить проект в любой момент времени. В таких условиях работать с дедлайнами гораздо проще....(с)" — Потому что дедлайн каждый день? Это типо без стресса?? Правда?
                          А в целом с посылом я согласен, сейчас очень очень много it компаний наслушались разных методологий, на самом деле не поняв их. Закидывание задачами по середине спринта, Scrum без ретроспектив, планировать лишь на спринт вперед (подчеркните то с чем вы сталкивались). И стараются не управлять проектами, а просто их контролировать, чтобы разрабы не расслаблялись, а то окаяные наверное ютуб смотрят. А в итоге управляют пусть разработчики и нервничают тоже, и достанется если что тоже им.
                            +2
                            Потому что дедлайн каждый день?

                            здесь речь идет о Continuous Delivery и регулярной выкладке готовых результатов в прод небольшими порциями. Это вовсе не то же самое, что «дедлайн каждый день»
                              +1
                              Одна мааааленькая проблема, когда у этих маленьких выкладок нет привязки к конкретным фичам, всё действие становится очень сомнительным. Ну и фраза «в любой момент» все таки означает что у вас готово должно в любой момент всё таки
                              0
                              Не надо обесценивать слово «дедлайн». Если после невыполнения дедлайна вы не умерли (dead), то это просто «лайн».
                                +3
                                ну формально от «постоянной» готовности и спешки, в тебе что-то все равно умирает, а потом умираешь весь
                                  0
                                  ну тут можно привести аналогию со срочностью задач
                                  Если у вас в трекере все задачи «срочные», то по факту нет срочных задач
                                +11

                                Как рассказывал Вадим Макишвили из Яндекса:
                                "В молодости мне поручили один проект, и я прикинул, за сколько дней смогу его выполнить. Когда я показал свои прикидки начальнику, он зачеркнул мои выкладки и написал новый срок — мое время, умноженное на Пи пополам плюс 2 недели. Я спросил, почему. Он ответил:


                                • Послушай, в жизни не бывает прямых путей. К любой цели ты начинаешь двигаться в обход, по дуге окружности. Поэтому и надо умножить на Пи пополам.
                                • Ого, понятно. Ну, а две недели-то почему?
                                • Так если даже за Пи пополам ты не успеешь закончить, то уж за две недели-то хоть что-то на коленке накидать сможешь! :)"
                                  0
                                  (мое время*Пи/2+2 недели) спасибо вам за формулу попробую ее на практике.
                                    +1
                                    Именно так, причем в военное время значение Пи может достигать 10.
                                      0
                                      Добавив 2 недели к положенному по графику сроку на непредвиденные задержки, добавьте еще 2 недели на непредвиденность самих непредвиденных задержек.

                                      Следствие №2 к "Закону прикладной неразберихи" (из "Законов Мерфи")

                                      +4
                                      Оценки это плохо.
                                      Оценки это хорошо.
                                      Оба утверждения правильные. Вопрос контекста и кто делает.

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

                                      Заставь дурака богу молиться — он себе лоб расшибет.

                                      Тоже самое с оценками в разработке.

                                      Оценки бывают полезны, в ситуации когда клиенту, инвестору или руководству нужно понять инвестировать в задачу/проект или нет. Например если задача стоит пол года и 1 млн долларов то да, а если 12 месяцев и 4 млн долларов то нет.

                                      Ну или чтобы понять что мы можем успеть к 1 января, а что нет? Что отбросить? А на чем фокусировать силы команды?

                                      Другой момент когда «эффективные менеджеры» начинают оценивать сроки по задачам. Типа вот у нас 100 задач и каждой задаче надо поставить срок. А потом прививать «комплекс вины» разработчикам и заставлять их через манипуляции работать в выходные.

                                      Ну или есть 1000 других вариантов разбить себе лоб и ушатать команду. Делая оценки сроков без смысла и понимания.
                                        0
                                        Ну при 100 активных линейных задачах на человека можно брать ТМО (теория массового обслуживания) и не париться в управлении. Сроки и загрузки считать по эрлангу и добавлять известные риски комнады.
                                        О сроках(датах) в такой постановке не может быть и речи.
                                        Ну и при таком потоке нейронку можно натренировать оценивать задачи :)
                                        +1

                                        Много спорных моментов. Особенно про управление командой и приоритезации.


                                        Есть супер книга про оценки, там всё разжевано и в сухом остатке, покрывает, вероятно, всё что написано в статье и описывает много больше – https://www.amazon.com/Predicting-Unpredictable-Pragmatic-Approaches-Estimating-ebook/dp/B00ZL05FYA.


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

                                          0
                                          и о вылете за рамки оценки лучше сообщать где нибудь на половине пути, а не в конце
                                          0

                                          Надо для начала определить, что сроки нужны — менеджерам и заказчику продукта. Программистам же — они до лампочки в большинстве своём.
                                          А вообще я до сих пор недоумеваю — ведь с точки зрения Agile методологий вообще странно предполагать наличие сроков и дедлайнов. Ведь один из основополагающих принципов Agile методологий — каждую итерацию поставлять рабочий продукт. Дедлайны — это же реликт с водопадной модели. У меня всегда складывалось впечатление, что "манагеры" — недочитали эту часть Agile и взяли кусок старой парадигмы — в новую методологию. Потому что "ай-ай-ай, но мы же должны знать когда?! Нам же продавать!" Очень часто хочется ответить "манагерам": "каждые две недели есть готовый продукт — продавайте на здоровье"

                                            +1

                                            Им нужно знать, что будет входить в этот готовый продукт, чтобы знать, что продавать.

                                              0

                                              Ну на момент получения продукта они точно знают — что туда уже вошло.

                                                +1

                                                Подготовка рекламы фичи, например, должна проходить до релиза фичи

                                                  +1

                                                  не могли бы раскрыть мысль? Почему нельзя после релиза рекламу делать?

                                                    0

                                                    И как это будет выглядеть? Месяц пилить фичу, потом месяц делать рекламу, в которой будет говориться: "А теперь торжественно объявляем, что месяц назад мы выпустили новую версию, в которой вы можете X"?

                                                      +2

                                                      Да. Можно опустить, что мы сделали ее месяц назад — кому это иетересно в рекламе? Я далек от маркетологии, поэтому решил уточнить, почему так не делают. Да и что там в рекламе делать месяц? Ролик? Материалы? Почему нельзя подготовить это, а пустить онлайн, когда с фичей закончат?

                                                        +1
                                                        Да и что там в рекламе делать месяц? Ролик? Материалы?

                                                        Да, если это сложная рекламная кампания, то может и дольше быть.


                                                        Почему нельзя подготовить это, а пустить онлайн, когда с фичей закончат?

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


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

                                                          0

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


                                                          У меня вообще есть устоявшееся мнение, что в провале сроков — виноваты манагеры. ВСЕГДА. Почему? Потому что обычно, когда манагеры обсуждают контракты и сроки сдачи продукта — мнение программистов зачастую просто не спрашивается. Манагеры же типа "белая кость", в костюмах и "делают деньги компании"- разве там есть место бородатому хмырю в безрукавке, который начинает задавать неудобные вопросы и рассуждать на тему архитектуры? К программисту в лучшем случае прийдут ПОСЛЕ переговоров и то, будут намекать, что "а не прихренел ли ты со своими 1.5 года, потому что мы через 3 месяца уже релиз обещали и деньги уже получили?"

                                                            +1
                                                            У меня вообще есть устоявшееся мнение, что в провале сроков — виноваты манагеры. ВСЕГДА. Почему? Потому что обычно, когда манагеры обсуждают контракты и сроки сдачи продукта — мнение программистов зачастую просто не спрашивается.

                                                            К счастью, хоть и "обычно", но не всегда. В компании, где я сейчас работаю, жесткий дедлайн "сверху" приходит, только если иначе никак – например, требование законодательства "к такому-то сроку должно работать вот так". В остальных случаях сроки называет команда, и в обсуждении участвуют все. И тут уже девелопер должен, имхо, разделять ответственность, если все сроки завалили.

                                                              0

                                                              Смешно слышать про "разделение ответственности" в случае если девелопер обвиняется в неумении определить сроки априори, а зачастую — эти сроки ему в принципе навязываются менеджером.
                                                              Т.е. предлагается разделять ЧУЖУЮ ответственность, на которую разработчик влияет чуть менее чем никак.

                                                                0
                                                                на которую разработчик влияет чуть менее чем никак.

                                                                Я же написал, "в остальных случаях сроки называет команда, и в обсуждении участвуют все." Что значит не влияет? Я не за всех говорю, а только за компанию, в которой работаю, и тут именно девелопер больше всех влияет на заявленный срок (опять же, исключая ситуации с "по закону надо сделать до числа X" – но что делать в таких случаях, тема для отдельного обсуждения, таких ситуаций не так уж и много). Не умеет – пусть учится, палкой его все-таки никто не бьет за просроченную задачу. А senior developer должен уметь давать адекватную оценку.

                                                      +1
                                                      Может потому что это тоже ненулевые работы, а денег у компании может и не хватить, если это делать последовательно.
                                                        0

                                                        Можно делать, но менее эффективно. Проще говоря, деньги, вложенные в разработку, будут заморожены

                                                  –1
                                                  А вообще я до сих пор недоумеваю — ведь с точки зрения Agile методологий вообще странно предполагать наличие сроков и дедлайнов. Ведь один из основополагающих принципов Agile методологий — каждую итерацию поставлять рабочий продукт.
                                                  В первом предложении вы отрицаете сроки и дедлайны в Agile, а вторым утверждаете, что дедлайн известен ещё до появления требований — конец очередного спринта.

                                                  Agile это про деятельность с жёстким сроком, жёстким бюджетом, но с гибким объёмом работ. То есть срок и работоспособность к этому сроку гарантируются, но объём выполненных работ к этому сроку — нет.

                                                  Нам же продавать!
                                                  Да, это так. Причём продажа часто происходит до начала спринта: клиентам, совету директоров или акционерам. И у менеджера есть инструмент решения данной объективной потребности бизнеса — выставление задачам по проданному функционалу высокого приоритета помещением таких задач в начало бэклога продукта. Ответственность за разруливание возникающих при этом конфликтов между продавцами на Владельце продукта.
                                                    +1

                                                    Ключевое слово – итерация.


                                                    Итерации в Agile не обязательны. Можно работать по Канбану без итераций, в потоке задач, и поставлять рабочий продукт без итераций – набрали задач от фичи из беклога и вперед за работу. Причем в отличии от Скрама, в Канбане можно заводить задачи по ходу работы.


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


                                                    Поэтому всё что вы сказали верно по-своему.


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


                                                    Есть и Канбан, где ни итераций (как вариант), ни сроков.


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

                                                      0

                                                      Формально говоря, в скраме вроде оценка производительности команды формальная не обязательна. Главное — достигать поставленных в итерации(спринте) целей, пока ПО и вообще заинтересованных лиц процесс устраивает. "Игры" в метрики и оценки начинаются часто когда цели хронически не достигаются, или у кого-то влиятельного появляется ощущение, что цели слишком лёгкие, что заметную часть спринта команда бездействует.

                                                        0

                                                        Как без оценки производительности можно спланировать спринт (Скрам), если менять задачи нельзя?


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


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

                                                          0

                                                          Просто "по ощущениям" сможем сделать такой-то набор задач за, например, две недели или не сможем.

                                                    +5
                                                    Полностью согласен.

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

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

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

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

                                                    А так получается, что программист честно отрабатывает свои 40 часов в неделю (а иногда еще и больше), и при этом чувствует себя виноватым. WTF?
                                                      0
                                                      Самый главный обман, в который попадает офисный разработчик, когда от него требуют четких сроков, и четкого соблюдения сроков — это то, что зарплату он получает за часы работы, а требуют от него уже фактического выполнения задач. Оплата за выполненные задачи — это вообще-то из другой области


                                                      Интересная мысль… Не задумывался о ней.

                                                      Если провести какие-то параллели с прошлым, глубоким прошлым человечества, то почасовую/посменную оплату труда получали люди, чей труд был линеен и легко измерим — шахтеры, ткачи, ну и так далее. Условному художнику или строителю моста вроде как платили гонорар за всю работу.
                                                        0
                                                        а это зависит от задач. Если вы в своей жизни сделали 50 одинаковых фич в разных проектах, то знаете сколько времени это занимает. Если вы делаете фичу первый раз в жизни, то тут только декомпозиция.
                                                        Т.е. задачи делятся на 2 типа
                                                        1 производственные
                                                        2 исследовательские
                                                        Производственные легко считаются, так как описаны кем либо где либо и т.д. (чужой код не учитываю)
                                                        исследовательские «мне надо 3 дня, чтобы дать оценку между вилкой 100-1000 часов»
                                                        А эффективность разработчика не оценивается в затраченных им часах на работе. Если он полезен бизнесу, то получает больше денег. Вот в этот момент начинается движение на встречу работника и работодателя, подключаются софт скиллы, хард скиллы и деньги со стороны работодателя.

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

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

                                                            0
                                                            «Если бы мне платили доллар каждый раз когда я слышу эту фразу» :)
                                                            Это и называется «риски».
                                                            Они бывают скрытыми и явными (в очень упрощенном виде). Если у вас оценка зависит от проекта или его тех устройства, то это явный риск и его можно учесть. Если проект ваш, то архитектура известна (либо у вас будут вопросы к тех персоналу), если проект чужой, то основные архитектуры описаны и это можно учесть, но «фактор» говнокода всегда присутствует.
                                                            Поэтому при оценке будет x часов архитектура 1, y часов архитектура 2, риски такие то, и это приемлемо.
                                                      0
                                                      Практически всегда есть «подводные камни», возникающие при реализации задачи. Поэтому свою временную оценку лучше умножать минимум на 30%
                                                        +3
                                                        Тот же Фредерик Брукс предлагал умножать сроки на 3 при переходе от прототипа к production-решению, и ещё раз на 3 — при переходе от решения для частного случая к общесистемному решению. Этот эффект кумулятивен.
                                                          +1
                                                          Чем чаще вы спрашиваете вашу команду об оценках, тем сильнее вы замедляете ее работу.


                                                          Собственно так и есть, время же уходит на сам анализ.

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

                                                          Ускорить можно другими способами — введением автоматизации, наймом дополнительных людей, покупкой дополнительных ресурсов (вычислительных и не только). Опытный менеджер может попробовать поменять методологию разработки. Но к сожалению, редко когда бывает правильно.
                                                            0
                                                            А ведь это хорошо, когда задача сначала анализируется и только потом делается теми же людьми. Нет?
                                                              0
                                                              Конечно хорошо.
                                                              Именно поэтому грамотный менеджер не набирает команду разработчиков с которыми сразу в agile и пилить богатому клиенту что-то быстренько, а срабатывается с командой, чтобы примерно представлять их производительность, и обсуждает дедлайны с заказчиком, пользуясь оценкой специалистов.

                                                              Agile это вообще не про то, чтобы работать без дедлайнов. Agile это как variable bitrate — общий дедлайн должен быть, а внутри срока какая-то задача выполняется дольше, какая-то меньше, какая-то разбивается на несколько сроков, но это все об управлении людьми, чтобы уменьшить простои.

                                                            0
                                                            Люди постоянно спрашивают оценки на первоначальную разработку, но мало кто интересуется оценками на последующую поддержку решения. И это большая проблема, поддержка — это очень серьезно. Поддержка может занимать до 60-80% всех затрат на проект.

                                                            Еще задолго до появления PMBOK, SCRUM и ХР, в книгах В.В.Липаева приводилась такая разбивка — первоначальная разработка занимает — 25%, а последующая отладка (тогда это так называлось) еще 75%.

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

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

                                                                Вроде около год назад на хабре был пост, где также, как и здесь, обсуждалась тема оценки сроков задач. Так вот, из одного из комментариев мне заполнилась следующая мысль: "Когда меня спрашивают срок, я всегда сначала рассчитываю ожидаемый срок X с маленьким запасом, а по итогу называю срок X * 2,5", я проверял на себе это много раз и ни разу не ошибся. Многие наверно решат, что это не со всеми работает и я с ними соглашусь, это работает почти всегда только с людьми, которые идут брать новые задачи, как только заканчиваются предыдущие. Для такого человека назвать срок 2.5X не страшно, т.к если он уложится в срок X, то просто пойдет и попросит другую задачу, тем самым опережая сроки еще и покажется себя очень расторопным.

                                                                  +1

                                                                  В статье должно было быть хоть что-то об оценке с помощью story points, если коротко то это одна из agile практик, когда оценивается время + сложность + то насколько понятны требования. Главное тут порядок величин, обычно оценка даётся в степени цифры 2 (1/2/4/8/16/32). Первые несколько спринтов оценки просто записываются, а потом становится примерно понятно сколько story points команда делает в среднем за один спринт и уже можно планировать объем работы.
                                                                  Такой подход позволяет избежать многие проблемы, которые указаны в статье и на моем опыте оценки получаются точнее.

                                                                    0

                                                                    Обычно даётся в числах Фибоначчи: 1,2,3,5,8,13,21...

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

                                                                      Из личного опыта добавлю, что нередко в задачи для оценки попадает какая-нибудь полная хрень, которая делается за 5-15 минут, но ей дают 1 сторипоинт, раз уж притащили.
                                                                        0

                                                                        Обычно команда сама выбирает минимальную оценку, как и максимальную.

                                                                      +1
                                                                      Хорошо пишете, все именно так и все эти проблемы, они везде. Чтобы я не делал, как бы не убеждал, на каких бы позициях не работал, самый эффективный путь — дать вышестоящему менеджменту въехать в пень с размаху. К сожалению терапию приходится повторять. Я прекрасно понимаю сколько ресурсов на ветер, но по другому видимо знания даже высокооплачиваемых специалистов не передаются.
                                                                        0
                                                                        Им же сверху виднее… говорили они
                                                                        0
                                                                        Благодарю за развернутую и полезную статью!
                                                                          0
                                                                          Спасибо за статью. Полезно!

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

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