No Flame No Game dan repost
Решила попробовать новый формат - запускаю рубрику #ментальныеловушкипродакта, короткие заметки "на подумать".
Ментальная ловушка №1: "если я блокирую команду, это провал".
Пример: разработчики готовы начинать работу над новой фичой, но продуктовая спецификация (one pager) еще в процессе. Продакт паникует, собирает что-то за час, отдает команде, чтобы не задерживать начало разработки. Простой в несколько дней воспринимается как провал.
В чем ловушка: мы пытаемся оптимизировать непрерывный execution; кажется, что постоянно бежать - лучше, чем остановиться и подумать. Задачи, связанные с работой над фичой в прогрессе, всегда приоритизируются выше, чем более оторванные от текучки дела (например, исследование проблемы, рынка или конкурентов).
Чем плохо:
- у продакта не находится времени глубоко подумать над проблемой и успехом; оценить риски и edge cases. Вероятно, что команда начнет разработку раньше, но застрянет на первом повороте, придется возвращаться назад и начинать сначала. Второй вариант - команда сделает решение для несуществующей проблемы. В любом случае, потраченное время будет больше потенциального "простоя" в начале;
- у продакта не находится времени подумать над стратегией. Команда застревает на уровне локальных оптимизаций и делает неконкурентноспособный продукт, несмотря на то, что работает круглыми сутками.
Вопросы "на подумать":
1) Чувствуешь ли ты себя некомфортно, если берешь время на размышление, а не решаешь "горящие" задачи?
2) Какой процент твоей работы сейчас – это решение срочных задач (reactive) vs средне-/долгосрочное мышление (proactive)?
3) Действительно ли команда заблокирована? Или это иллюзия срочности? (например, могут ли разработчики в это время заняться рефакторингом или документацией)
4) Как можно изменить процесс разработки, чтобы сделать выбор в п.1 более простым?
5) Как можно заложить "долгосрочное мышление" в оценку работы продакта?
@proproduct
Ментальная ловушка №1: "если я блокирую команду, это провал".
Пример: разработчики готовы начинать работу над новой фичой, но продуктовая спецификация (one pager) еще в процессе. Продакт паникует, собирает что-то за час, отдает команде, чтобы не задерживать начало разработки. Простой в несколько дней воспринимается как провал.
В чем ловушка: мы пытаемся оптимизировать непрерывный execution; кажется, что постоянно бежать - лучше, чем остановиться и подумать. Задачи, связанные с работой над фичой в прогрессе, всегда приоритизируются выше, чем более оторванные от текучки дела (например, исследование проблемы, рынка или конкурентов).
Чем плохо:
- у продакта не находится времени глубоко подумать над проблемой и успехом; оценить риски и edge cases. Вероятно, что команда начнет разработку раньше, но застрянет на первом повороте, придется возвращаться назад и начинать сначала. Второй вариант - команда сделает решение для несуществующей проблемы. В любом случае, потраченное время будет больше потенциального "простоя" в начале;
- у продакта не находится времени подумать над стратегией. Команда застревает на уровне локальных оптимизаций и делает неконкурентноспособный продукт, несмотря на то, что работает круглыми сутками.
Вопросы "на подумать":
1) Чувствуешь ли ты себя некомфортно, если берешь время на размышление, а не решаешь "горящие" задачи?
2) Какой процент твоей работы сейчас – это решение срочных задач (reactive) vs средне-/долгосрочное мышление (proactive)?
3) Действительно ли команда заблокирована? Или это иллюзия срочности? (например, могут ли разработчики в это время заняться рефакторингом или документацией)
4) Как можно изменить процесс разработки, чтобы сделать выбор в п.1 более простым?
5) Как можно заложить "долгосрочное мышление" в оценку работы продакта?
@proproduct