Я не недоволен )) Это же просто обмен мнениями
Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.
Есть в этом мире два скрама – правильный, и неправильный. Правильный описан в книге Джеффа Сазерленда. Неправильный – в т.н. scrum guide, причем в авторах числится все тот же Джефф Сазерленд.
Правильный скрам говорит: можно и нужно ускорить работу в 4 раза. Неправильный ничего такого не говорит, просто дает некие правила.
Правильный скрам честно дает отсылки к японским методам управления качеством, называя их одной из основ философии скрама. В том числе, рекомендует использовать правила приличного самурая – взять скрам за основу, и сотворить свою собственную методику. Неправильный скрам говорит – делай, как у нас тут написано. А если делаешь по-другому, то это не скрам.
Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.
Выводы?
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.
P.S. А оценивать задачи разработчики всегда будут посредственно. Оценил и ошибся, и сделал в два раза дольше — хреновый разработчик. Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят. Помните же — задача занимает все отведенное на нее время ))
В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
Простите, но вы явно не видите здесь проблем.
Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )
Какой % всех ваших проектов завершился раньше времени?
С опытом хороший менеджер начинает это понимать и вносит коррективы: например, услышав оценку в 10 часов, он умножает её на 2 и получает результат, впоследствии оказывающийся более верным.
Только дурак поедет оценивать и покупать авто с ценой в два раза выше рыночной, либо мошенник :) (на kolesa.kz, кстати, в каждом объявлении есть индикатор средней рыночной цены на такую марку/модель/год).
А если банк скажет, что реальная стоимость авто сильно меньше рыночной — тогда пересчитают покупателю условия кредита и всё. Дальше стороны либо соглашаются, либо нет.
Чаще всего пересчёт — это увеличение первоначального взноса.
Из личного опыта — там более длинная конечная процедура )
— если тебе одобрили кредит (смысл ехать смотреть авто, если тебе не одобрили?) — звонит менеджер из банка и приглашает на ближайшее аффилированное СТО в твоем городе на определенное время, удобное продавцу и покупателю.
— на СТО проводится осмотр и оценка авто, составляется дефектовочный акт и в течение нескольких минут оценивается авто (продавец может оценить авто дороже в 2 раза, чем оно действительно стоит, такие ушлые ребята отсекаются).
— дальше покупатель едет в банк (или прям на аффилированном СТО) и вносит первоначальный взнос от 10% и продавец с покупателем едут переоформлять автомобиль.
Не все марки и модели кредитуются (как правило, банк смотрит на ликвидность). Какой-нибудь кабриолет вряд ли доступен в кредит, либо доступен, но по адским условиям.
Не обязательно. Проверка гипотезы не подразумевает большого тестирования, тем более регресса (хотя все зависит от специфики теста).
Я так думаю, что речь идет о примерно такой схеме — одновременно проверяются, например, 10 гипотез (каждая по сути делается как MVP), и в разработке 1-2 фичи, которые проверены тестами.
В любом случае я согласен с тем, что тестирование всегда будет узким местом. У нас в компании я стремлюсь к соотношению 1 к 1, но пока даже 2 тестировщика на 3 разработчика не всегда получается…
но и думать о том, что это решение действительно решит задачу человека
— пока это не на тесте, мы об этом не узнаем никак… Т.е. это только гипотеза изначально, и 9 из 10 гипотез проваливаются, но ценность десятой покрывает все временные и ресурсные затраты.
Если вообще глобально говорить о проблеме (которая есть практически у всех менеджеров — в том числе и у меня), то это неверная трактовка сроков, их оценок и вообще целей менеджмента. 99.999% менеджеров (проектные или продуктовые, неважно) ставят себе задачу такую — успеть в оцениваемый срок и в озвученный бюджет. Классика PMBOK.
И тут я отошлю себя к nmivan:
Из наших наблюдений — все разработчики пишут код быстро (если вы работаете не с ленивыми ребятами, неважно, сеньоры это или джуниоры). Но в процессе доставки функционала до пользователя этот этап занимает всего 10-15% времени. Остальные 85-90% — это тестирование, сборки билдов, изменение статусов, переключение разработчиков на параллельные задачи, коммуникации и еще куча других, крайне веселых вещей. Вот куда надо смотреть и изменять+улучшать (ИМХО). Ну а чтобы понять после изменений, хуже или лучше стало, эти процессы нужно измерять уже сейчас.
Выводы?
Даже если ваши разработчики начнут писать код в два раза быстрее, проект закончится раньше только на несколько процентов раньше.
P.S. А оценивать задачи разработчики всегда будут посредственно. Оценил и ошибся, и сделал в два раза дольше — хреновый разработчик. Оценил и ошибся, но сделал в два раза быстрее — разработчик растянет задачу на весь озвученный срок, иначе в следующий раз ему не поверят. Помните же — задача занимает все отведенное на нее время ))
В общем, на самом деле нет проблем с так называемыми «дедлайнами». Мы фокусируемся не на том. Именно поэтому я ушел из проектного менеджмента в продуктовый — в проектном (проекты в классическом виде — заказчик, бюджет, сроки) практически нет ни времени, ни возможности залезть в процессы, которые занимают те самые 90% времени.
Как минимум это оценка сроков — у вас оценивает срок один человек, независимо от его квалификации? Если да, то это тут водопадом льется еще один список последующих проблем. Ваш коэффициент не спасёт )
Какой % всех ваших проектов завершился раньше времени?
А если банк скажет, что реальная стоимость авто сильно меньше рыночной — тогда пересчитают покупателю условия кредита и всё. Дальше стороны либо соглашаются, либо нет.
Чаще всего пересчёт — это увеличение первоначального взноса.
— если тебе одобрили кредит (смысл ехать смотреть авто, если тебе не одобрили?) — звонит менеджер из банка и приглашает на ближайшее аффилированное СТО в твоем городе на определенное время, удобное продавцу и покупателю.
— на СТО проводится осмотр и оценка авто, составляется дефектовочный акт и в течение нескольких минут оценивается авто (продавец может оценить авто дороже в 2 раза, чем оно действительно стоит, такие ушлые ребята отсекаются).
— дальше покупатель едет в банк (или прям на аффилированном СТО) и вносит первоначальный взнос от 10% и продавец с покупателем едут переоформлять автомобиль.
Я так думаю, что речь идет о примерно такой схеме — одновременно проверяются, например, 10 гипотез (каждая по сути делается как MVP), и в разработке 1-2 фичи, которые проверены тестами.
В любом случае я согласен с тем, что тестирование всегда будет узким местом. У нас в компании я стремлюсь к соотношению 1 к 1, но пока даже 2 тестировщика на 3 разработчика не всегда получается…