Comments 11

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

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

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

На моей практике была только одна ситуация, когда у разработчика всегда были нереальные дедлайны: когда мы пилили продукт, разработчик не проектировал и называл сроки задач интуитивно, а когда сроки проходили, говорил: «нууууу… там сложности, ктож знал». При этом когда я спрашивала, а почему сложности не выяснились на берегу, мне говорили «Ну ты же про сроки спрашивала и НАДО БЫЛО БЫСТРЕЕ, а на оценку надо еще времени». Это был косяк обоих, и мой (как менеджера), и разработчика.
Мой — в том, что я не донесла до разработчика приоритеты и не объяснила, что точность важнее скорости. Разработчика — в том, что он брал задачи без декомпозиции и проектирования и не сказал «Э, погодите, это вне здравого смысла. Я так не работаю.»
Это хорошо, что вам еще не приходилось оказываться в ситуации, когда «сейлы так продали» или «выиграли тендер» и книжные методы начинают работать очень со скрипом
В ситуации «выиграли тендер» действительно не оказывались, потому что сознательно их избегаем (и вы тоже можете начать).

В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
Господи, какая жесть )) Особенно это:
С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Если не вырывать фразу из контекста, то было написано:
Переоценивать свои силы склонны некоторые джуниоры и мидлы. С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.

Что из этой фразы кажется жестью?

Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
Простите, но вы явно не видите здесь проблем.
Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )

Какой % всех ваших проектов завершился раньше времени?

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


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

Я не недоволен )) Это же просто обмен мнениями
Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.

И тут я отошлю себя к nmivan:
Есть в этом мире два скрама – правильный, и неправильный. Правильный описан в книге Джеффа Сазерленда. Неправильный – в т.н. scrum guide, причем в авторах числится все тот же Джефф Сазерленд.

Правильный скрам говорит: можно и нужно ускорить работу в 4 раза. Неправильный ничего такого не говорит, просто дает некие правила.

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


Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.

Выводы?
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.

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

В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
Мы с вами начали обсуждать фразу про поставновку сроков выполнения задачи — смещать фокус из такого контекста на дистрибуцию до пользователя некорректно, т.к. точные оценки — это одно, а то, что тестирование у вас (видимо) в оценку разработки входит, это другое. Мы следим за утилизацией времени разработчиков (сколько тратится непосредственно на код), и у нас на код тратится ~60% времени (кодревью я сюда же включаю, это тоже работа над кодом). Разработчик — достаточно дорогой ресурс, странно, что вы признаетесь, что на 90% используете его не вцелевую, и вам это ок.

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

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

Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.

Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
О, здравствуйте! Прям диалог двоих )
В целом я вас понял, внешне все выглядит как задумано. А можно подробности, если это конечно не секрет?
Например, как вы измеряете time-to-market задачи (название условно, главное чтобы понятно было) — от ее создания до того, как она появится в виде функционала у пользователей? И как это меряется для одного функционала, но на разных платформах (iOS,Android, сайты, может еще что-то) и при этом учитываются проводимые A/B-тесты?

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

А вы делаете продукты внутри компании? Которые вам деньги приносят?
Only those users with full accounts are able to leave comments. Log in, please.