Портал №1 по управлению цифровыми
и информационными технологиями

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

Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты поставки разрабатываемых продуктов. А что для разработчиков? Для них отдача совсем не очевидна. Да и в целом может показаться, что и пользы-то никакой нет, ведь оценки используются зачастую «против» разработчиков, поскольку интерпретируются и воспринимаются стейкхолдерами именно как обещания.

Вполне естественно, что разработчикам без особого удовольствия дают оценки, ведь они могут повлечь неприятности. Однако, оценки могут принести однозначную пользу командам разработки — фактически, со временем они могут повысить статус команд разработки среди всех заинтересованных сторон и дать больше возможностей и веса на встречах и обсуждениях, считает Майк Кон (Mike Kohn), рассуждая на эту тему в своей заметке. Как же этого добиться?

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

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

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

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

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

    • Технический долг: как не стать жертвой невидимого врага
      Зачастую о техническом долге говорят как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Что подготовить в компании, чтобы заработало управление ИТ-активами?
      Автор — Андрей Боганов, ITSM/ITAM эксперт, тренер курса «Управление ИТ-активами (ITAM)» Для организации управления ИТ-активами «навести порядок» только в ИТ …
    • Технический долг и беклог
      Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его …
    • маленькие релизыТри визуализации, которыми я объясняю Agile
      Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые …
    • Что дальше в DevOps: AIOps?
      Уже со времен появления гигантских хранилищ и анализа больших данных эксперты говорили о том, какими огромными становятся ИТ—инфраструктуры, и что скоро они станут настолько …
    • Как “продать” место в очереди
      Очередь — одна из раздражающих вещей и пережиток советской эпохи. Она повсюду: в магазине на кассу, у лифта в офисном здании, пробка на дороге – это ведь тоже очередь. …
    • Кто тут крайний?
      Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную …
    • Что такое практическая польза от обучения, и как её получить?
      Обычно для того, чтобы получить максимум пользы от обучения, рекомендуют выбирать правильного поставщика обучения. Изучить отзывы о компании и её курсах, ознакомиться с …
    • Руководство по машинному обучению для новичков
      Обучение — это часть процесса роста каждого живого существа.  Растения учатся фотосинтезу, животные учатся охоте, а люди учатся ездить на велосипеде. Это универсальный навык, …
    • Как обучать команду удаленно
      Обучение — это важный обряд посвящения, который проходит каждый новый сотрудник, чтобы узнать о своей новой роли и обязанностях, встретиться со своими товарищами по команде и …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT