Comments 8
Спасибо за статью.
Честно, даже не подозревал, что у подобного метода планирования есть название. Меня к подобному методу привёл мой бизнес-партнёр, в одном проекте который начался 2-года назад (спасибо ему за это огромное). У него на любом совещании как внутреннем так и с заказчиком всегда 3 вопроса (как на предложения по инновациям, так и на требования о новом функционале):
1. Какова цель?
2. Какой профит от этого бизнесу?
3. Вы уверены, что это нужно делать прямо сейчас?
В итоге довольно легко, растрясти разновестные шарики-задачи в коробке, и на поверхности оказываются самые срочные и необходимые, и к тому-же с наибольшим импактом эффективности.
Честно, даже не подозревал, что у подобного метода планирования есть название. Меня к подобному методу привёл мой бизнес-партнёр, в одном проекте который начался 2-года назад (спасибо ему за это огромное). У него на любом совещании как внутреннем так и с заказчиком всегда 3 вопроса (как на предложения по инновациям, так и на требования о новом функционале):
1. Какова цель?
2. Какой профит от этого бизнесу?
3. Вы уверены, что это нужно делать прямо сейчас?
В итоге довольно легко, растрясти разновестные шарики-задачи в коробке, и на поверхности оказываются самые срочные и необходимые, и к тому-же с наибольшим импактом эффективности.
Да, соглашусь с вами, подходов понять, для чего всё затевается, много — начиная с классического вопроса и заканчивая техникой 5 why. Если начать хотя бы ими задаваться при планировании — уже должен быть значительный рост «полезности» планов :)
Конкретно эта статья мне понравилась тем, что кроме понимания базовых предпосылок и определения целей проектов она рассказывает ещё и об управлении идеями по достижению этих целей. И тогда фокус очень хорошо смещается с «надо придумать, что делать, чтобы разработчики не простаивали» к «надо выбрать, что делать, чтобы бизнес зарабатывал больше / рос быстрее / вышел из кризиса / etc.»
Конкретно эта статья мне понравилась тем, что кроме понимания базовых предпосылок и определения целей проектов она рассказывает ещё и об управлении идеями по достижению этих целей. И тогда фокус очень хорошо смещается с «надо придумать, что делать, чтобы разработчики не простаивали» к «надо выбрать, что делать, чтобы бизнес зарабатывал больше / рос быстрее / вышел из кризиса / etc.»
Классический вопрос
Чаще всего роадмапы все таки нужны, они уже настолько въелись в сознание большинства, что просто сложно будет объяснить что можно без них, хотя это и возможно =) И вина здесь не в «гибкости» схем, а в гибкости у большинства людей, вернее в ее отсутствии =(
Да, как способ коммуникации с «менее гибкими» коллегами, роадмапы однозначно нужны — просто потому что более консервативным сотрудникам / отделам / компаниям сложно отказаться от стратегического мышления вида «план-задача».
Конкретно GIST хорошо ложится на OKR (что упомянуто как раз с примерами), а OKR сам по себе подразумевает бОльшую гибкость, переход от мышления вида «план-задача» в сторону «цель-задача», при этом ещё и задачу исполнитель сам себе ставит.
Начинать переход можно хотя бы с формулирования стратегии на год в виде целей, а не задач, пусть даже на первых порах задачи тоже будут спускаться сверху директивно. Это может быть больно, будет становиться заметно, насколько «верх» способен грамотно поставить директивную задачу, которая будет достигать заданной цели, что вызовет вопросы к компетентности. Возможно, в компании начнутся более глобальные изменения, которые повлекут изменение подходов…
В общем, переход от одной парадигмы к другой непрост, но, имхо, стоит того :)
Другое дело, что не все компании понимают необходимость таких переходов, но каждый сотрудник всегда оставляет за собой право голоса ногами, благо рынок (по крайней мере, технологический) позволняет
Конкретно GIST хорошо ложится на OKR (что упомянуто как раз с примерами), а OKR сам по себе подразумевает бОльшую гибкость, переход от мышления вида «план-задача» в сторону «цель-задача», при этом ещё и задачу исполнитель сам себе ставит.
Начинать переход можно хотя бы с формулирования стратегии на год в виде целей, а не задач, пусть даже на первых порах задачи тоже будут спускаться сверху директивно. Это может быть больно, будет становиться заметно, насколько «верх» способен грамотно поставить директивную задачу, которая будет достигать заданной цели, что вызовет вопросы к компетентности. Возможно, в компании начнутся более глобальные изменения, которые повлекут изменение подходов…
В общем, переход от одной парадигмы к другой непрост, но, имхо, стоит того :)
Другое дело, что не все компании понимают необходимость таких переходов, но каждый сотрудник всегда оставляет за собой право голоса ногами, благо рынок (по крайней мере, технологический) позволняет
Благодаря тому, что каждый шаг-проект такой маленький, мы избегаем всех негативных побочных эффектов, присущих долгим проектам, и потому у нас появляется возможность тестировать гораздо больше идей параллельно, при этом уменьшая инвестиции и учась быстрее. Ничего не требуется питчить или разводить политику
Получается, что шаг-проекты предполагают в какой-то момент пересечение. То есть один уже в бете и в тестах, а второй на этапе мвп. Как здесь не потерять фокусировку?
Мы разбиваем крупные проекты на маленькие пошаговые проекты, шаг-проекты
С другой стороны, пересечение проектов это плюс. Например, если крупный проект — приложение, а шаг проекты — фичи, то на этапе каст дева можно сразу несколько фичей проверить. Но есть здесь можно представить задачу уже в несколько потоков.
Не знаю, насколько продуктивно на проблемных / решенческих интервью прорабатывать сразу несколько разных фичей — человек-то нежелезный, банально устанет :)
Что касается пересечения фичей:
В большинстве компаний всё равно так или иначе работа ведётся над несколькими задачами одновременно (даже канбан-метод это позволяет), полностью вся команда одну идею не пилит просто потому, что специализацию никто не отменял.
Проблемы фокусирования вроде не должно быть — программисты пишут код по шаг-проекту для идеи №1, исследователи и продакт работают над сбором фидбека по шаг-проекту идеи №2 и т.д.
Есть ощущение, что во многих компаниях одновременно в работе и так большое количество проектов (что распыляет, конечно), поэтому если это будут более «обстуканные об рынок» проекты, то глобально ничего не поменяется.
Про«каноничный скрам» ничего не могу сказать, если мне не изменяет память, скрамгайд не регламентирует распределение задач внутри DevTeam и распределение задач внутри проектов (или шаг-проектов в случае GIST), поэтому противоречия вроде бы нет.
Как решить проблему набора в спринт Инкрементов (задач) из разных проектов (шаг-проектов) — команда сама решит на планировании и возникшие по ходу сложности разберёт на ретро.
Как-то так мне видится :)
Что касается пересечения фичей:
В большинстве компаний всё равно так или иначе работа ведётся над несколькими задачами одновременно (даже канбан-метод это позволяет), полностью вся команда одну идею не пилит просто потому, что специализацию никто не отменял.
Проблемы фокусирования вроде не должно быть — программисты пишут код по шаг-проекту для идеи №1, исследователи и продакт работают над сбором фидбека по шаг-проекту идеи №2 и т.д.
Есть ощущение, что во многих компаниях одновременно в работе и так большое количество проектов (что распыляет, конечно), поэтому если это будут более «обстуканные об рынок» проекты, то глобально ничего не поменяется.
Про«каноничный скрам» ничего не могу сказать, если мне не изменяет память, скрамгайд не регламентирует распределение задач внутри DevTeam и распределение задач внутри проектов (или шаг-проектов в случае GIST), поэтому противоречия вроде бы нет.
Как решить проблему набора в спринт Инкрементов (задач) из разных проектов (шаг-проектов) — команда сама решит на планировании и возникшие по ходу сложности разберёт на ретро.
Как-то так мне видится :)
Предлагаемый подход не противоречит здравому смыслу и главное во всех подходах: не делать ради методики а постоянно замерять эффективность инструмента и не зацикливаться. Спасибо историю про свой опыт и результат!
А можете на пальцах различия дать? Пока для меня это разные названия…
Используются банки идей вместо продуктового бэклога.
А можете на пальцах различия дать? Пока для меня это разные названия…
Хочу обратить ваше внимание, что это не авторская статья, а перевод :)
Банк Идей глобально — просто список идей (например, в Excel), а бэклог зачастую размещают в таск-трекерах / диаграммах Ганта / специализированном инструментарии для роадмапов. Я думаю, автор имел ввиду именно эту разницу — идеи ещё не обязательно будут взяты в работу в том виде, в каком записаны и предполагают лёгкую запись, расширение и т.п.
Банк Идей глобально — просто список идей (например, в Excel), а бэклог зачастую размещают в таск-трекерах / диаграммах Ганта / специализированном инструментарии для роадмапов. Я думаю, автор имел ввиду именно эту разницу — идеи ещё не обязательно будут взяты в работу в том виде, в каком записаны и предполагают лёгкую запись, расширение и т.п.
Sign up to leave a comment.
Почему вам стоит перестать использовать продуктовые роадмапы и попробовать GIST