Comments 11
Это конечно здорово, но, гораздо чаще у людей стоит вопрос: что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшить.
Что грамотные менеджеры делают в этой ситуации?
что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшит
Этот вопрос надо задавать по-другому: а откуда такой нереальный дедлайн вообще взялся? Ну и многое зависит от того, кто вы в команде.
Если вы менеджер, то это как раз ваша работа — договориться, чтобы дедлайн был реальным.
Если вы программист, то влияйте на дедлайн: просите больше времени на проектирование, разбирайте задачу по кусочкам и давайте более точную оценку выполнения, чтобы задница потом не горела.
На моей практике была только одна ситуация, когда у разработчика всегда были нереальные дедлайны: когда мы пилили продукт, разработчик не проектировал и называл сроки задач интуитивно, а когда сроки проходили, говорил: «нууууу… там сложности, ктож знал». При этом когда я спрашивала, а почему сложности не выяснились на берегу, мне говорили «Ну ты же про сроки спрашивала и НАДО БЫЛО БЫСТРЕЕ, а на оценку надо еще времени». Это был косяк обоих, и мой (как менеджера), и разработчика.
Мой — в том, что я не донесла до разработчика приоритеты и не объяснила, что точность важнее скорости. Разработчика — в том, что он брал задачи без декомпозиции и проектирования и не сказал «Э, погодите, это вне здравого смысла. Я так не работаю.»
Это хорошо, что вам еще не приходилось оказываться в ситуации, когда «сейлы так продали» или «выиграли тендер» и книжные методы начинают работать очень со скрипом
В ситуации «выиграли тендер» действительно не оказывались, потому что сознательно их избегаем (и вы тоже можете начать).
В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
В ситуации «сэйлзы так продали» и я, и мои коллеги оказываемся систематически: банально, продали решение, которое оказалось неподходящим (а подходящее стоит дороже). И я считаю, что эта ситуация на 100% зависит от менеджера — моя задача договориться с клиентом и при этом оставить его лояльным. Если у вас сейлз всегда продает в убыток, а менеджеры не могут договариваться, то… не оч у вас все.
Господи, какая жесть )) Особенно это:
С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Если не вырывать фразу из контекста, то было написано:
Что из этой фразы кажется жестью?
Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
Переоценивать свои силы склонны некоторые джуниоры и мидлы. С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Что из этой фразы кажется жестью?
Конечно, здесь речь не идет о буквальном умножении на 2 всех сроков: например, у нас в компании для защиты от риска, когда разработчик некорректно оценил, используется система коэффициентов (от 0,5 до 1, где единица — сеньор). Все сроки делим на этот коэфициент. Важно понимать, что такая схема используется для определения только кадендарного срока проекта: когда считаем бюджет, берем «голую» оценку разработчика. Таким образом, клиент платит за фактическое выполнение задачи, а не за то, что работу выполняет джун или мидл вместо сеньора.
Простите, но вы явно не видите здесь проблем.
Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )
Какой % всех ваших проектов завершился раньше времени?
Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )
Какой % всех ваших проектов завершился раньше времени?
В чем состоит проблема, как вам кажется? Пока действительно не улавливаю причину вашего недовольства, раз мы начали обмениваться мнениями, то давайте обсуждать не только то, в чем я (по вашему мнению) неправа но и то, как сделать оптимальнее. Мы гибкие в плане процессов ребята, и если почерпнем что-то полезное из комментов на Хабре, то нам будет не стремно это внедрять).
Что касается ответов на вопрос: да, на некоторых проектах оценивает только один человек — обязательно тот, кто будет выполнять задачу. Проекты раньше календарного срока почти не завершаются, но это не только из-за коэффициентов, кроме этого стараемся делить работу на маленькие итерации, так проще прогнозировать.
Я не недоволен )) Это же просто обмен мнениями
Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.
И тут я отошлю себя к nmivan:
Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.
Выводы?
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.
P.S. А оценивать задачи разработчики всегда будут посредственно. Оценил и ошибся, и сделал в два раза дольше — хреновый разработчик. Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят. Помните же — задача занимает все отведенное на нее время ))
В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.
И тут я отошлю себя к nmivan:
Есть в этом мире два скрама – правильный, и неправильный. Правильный описан в книге Джеффа Сазерленда. Неправильный – в т.н. scrum guide, причем в авторах числится все тот же Джефф Сазерленд.
Правильный скрам говорит: можно и нужно ускорить работу в 4 раза. Неправильный ничего такого не говорит, просто дает некие правила.
Правильный скрам честно дает отсылки к японским методам управления качеством, называя их одной из основ философии скрама. В том числе, рекомендует использовать правила приличного самурая – взять скрам за основу, и сотворить свою собственную методику. Неправильный скрам говорит – делай, как у нас тут написано. А если делаешь по-другому, то это не скрам.
Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.
Выводы?
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.
P.S. А оценивать задачи разработчики всегда будут посредственно. Оценил и ошибся, и сделал в два раза дольше — хреновый разработчик. Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят. Помните же — задача занимает все отведенное на нее время ))
В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
Мы с вами начали обсуждать фразу про поставновку сроков выполнения задачи — смещать фокус из такого контекста на дистрибуцию до пользователя некорректно, т.к. точные оценки — это одно, а то, что тестирование у вас (видимо) в оценку разработки входит, это другое. Мы следим за утилизацией времени разработчиков (сколько тратится непосредственно на код), и у нас на код тратится ~60% времени (кодревью я сюда же включаю, это тоже работа над кодом). Разработчик — достаточно дорогой ресурс, странно, что вы признаетесь, что на 90% используете его не вцелевую, и вам это ок.
На этом месте загордилась своими коллегами). У нас так не принято. Сделал задачу медленнее — на ретро будем обсуждать, что не учли и как проектировать лучше. Сделал задачу быстрее — берешь следующую, неизрасходованное время потратится на то, чтобы «закрыть» ту задачу, на которой выбились из оценки. Или фиксишь баги. Никто ничего не растягивает.
Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.
Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят.
На этом месте загордилась своими коллегами). У нас так не принято. Сделал задачу медленнее — на ретро будем обсуждать, что не учли и как проектировать лучше. Сделал задачу быстрее — берешь следующую, неизрасходованное время потратится на то, чтобы «закрыть» ту задачу, на которой выбились из оценки. Или фиксишь баги. Никто ничего не растягивает.
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше
Полностью согласна! Только мы обсуждаем не скорость кода, а точность сроков. На оценку разработчика (=планируемое время окончания задачи) подвязывается много процессов, и если разработчик не попадает в оценку, не важно, на 4 часа или 3е суток он опазадал — сроки все равно поедут, т.к. двигаются задачи у QA, других разработчиков и т.д., а у них может вообще под конкретную задачу одно окно было выделено, а потом — другой проект. Моя задача, как менеджера — не чтобы все было максимально быстро (хотя да), а чтобы несколько людей работали слажено и минимально тормозили друг-друга съездами по срокам.
Не согласна с вами, что в проектном менеджменте нет времени на процессы, и поэтому срочно стоит идти в продуктовый — вы же не внедряете под каждый проект процессы с 0, одни и те же процессы работают на всех проектах и могут оптимизироваться несколькими менеджерами, главное правильно настройте метрики. Фокусироваться надо не на каких-то странных «проектных / продуктовых» процессах, а на процессах в бизнесе.
О, здравствуйте! Прям диалог двоих )
В целом я вас понял, внешне все выглядит как задумано. А можно подробности, если это конечно не секрет?
Например, как вы измеряете time-to-market задачи (название условно, главное чтобы понятно было) — от ее создания до того, как она появится в виде функционала у пользователей? И как это меряется для одного функционала, но на разных платформах (iOS,Android, сайты, может еще что-то) и при этом учитываются проводимые A/B-тесты?
Про «утилизацию» времени разработчика — такой показатель попросту невозможен для продуктов с миллионами пользователей на разных платформах. Либо в вашем случае код пишется прямо на продакшне (это смерть бизнесу), либо они роботы, у которых нет личной жизни и времени сходить в туалет (а это тоже смерть бизнесу) ))
А вы делаете продукты внутри компании? Которые вам деньги приносят?
В целом я вас понял, внешне все выглядит как задумано. А можно подробности, если это конечно не секрет?
Например, как вы измеряете time-to-market задачи (название условно, главное чтобы понятно было) — от ее создания до того, как она появится в виде функционала у пользователей? И как это меряется для одного функционала, но на разных платформах (iOS,Android, сайты, может еще что-то) и при этом учитываются проводимые A/B-тесты?
Про «утилизацию» времени разработчика — такой показатель попросту невозможен для продуктов с миллионами пользователей на разных платформах. Либо в вашем случае код пишется прямо на продакшне (это смерть бизнесу), либо они роботы, у которых нет личной жизни и времени сходить в туалет (а это тоже смерть бизнесу) ))
А вы делаете продукты внутри компании? Которые вам деньги приносят?
Sign up to leave a comment.
Горящий дедлайн: как проджект-менеджеру не лишиться пальцев