Щелчок тумблера, и теперь мы не программисты, но разработчики продукта :)
Шутка. Нет волшебного переключателя, которым можно было бы щёлкнуть, чтобы все сразу заработали по-новому. Кто-то уже несколько лет делал работу на всех слоях, а кто-то не начнёт и в новой должности.
Фактически уже несколько лет мы двигались в Scrum и LESS. Теперь и на формальном уровне. Никаких больше узко специализированных должностей. Нет больше фронтендеров, мобильников, бэкендеров, дбд, тестировщиков. Есть разработчики продукта с Т-shape или Ш-shape экспертизой. Не всем это подходит, но вариантов нет. Больше не получится тыкать пальцем "это вон у бэкендеров апи кривое". Придётся всей командой проектировать контракт апи.
Придётся брать на себя больше ответственности.
Никого не увольняют, но подозреваю что не всем подойдёт новая реальность, и кто-то уйдет искать привычное болото в менее прогрессивные конторы.
Шутка. Нет волшебного переключателя, которым можно было бы щёлкнуть, чтобы все сразу заработали по-новому. Кто-то уже несколько лет делал работу на всех слоях, а кто-то не начнёт и в новой должности.
Фактически уже несколько лет мы двигались в Scrum и LESS. Теперь и на формальном уровне. Никаких больше узко специализированных должностей. Нет больше фронтендеров, мобильников, бэкендеров, дбд, тестировщиков. Есть разработчики продукта с Т-shape или Ш-shape экспертизой. Не всем это подходит, но вариантов нет. Больше не получится тыкать пальцем "это вон у бэкендеров апи кривое". Придётся всей командой проектировать контракт апи.
Придётся брать на себя больше ответственности.
Никого не увольняют, но подозреваю что не всем подойдёт новая реальность, и кто-то уйдет искать привычное болото в менее прогрессивные конторы.
❤2👍2
Продуктовый. Разработчик.
Прежде всего, надо пояснить за название канала.
Какие такие продукты разрабатывает этот парень? Обойдемся без пошлых шуток про арбузы. Всё, о чем буду писать, - про IT.
IT с точки зрения программиста, который не ограничивает свою зону ответственности кодированием. И имеет от этого некоторые явные и не очень профиты.
Возможность выйти за пределы кодирования должна быть обеспечена рабочей средой. Продуктовая разработка - как раз такая среда. Я еще успею рассказать, в чем отличие продукта от проекта с точки зрения того Васи, который непосредственно копает яму.
Этот канал - про взгляд изнутри на образ мышления, роли, процессы, события и артефакты продуктовой разработки.
Прежде всего, надо пояснить за название канала.
Какие такие продукты разрабатывает этот парень? Обойдемся без пошлых шуток про арбузы. Всё, о чем буду писать, - про IT.
IT с точки зрения программиста, который не ограничивает свою зону ответственности кодированием. И имеет от этого некоторые явные и не очень профиты.
Возможность выйти за пределы кодирования должна быть обеспечена рабочей средой. Продуктовая разработка - как раз такая среда. Я еще успею рассказать, в чем отличие продукта от проекта с точки зрения того Васи, который непосредственно копает яму.
Этот канал - про взгляд изнутри на образ мышления, роли, процессы, события и артефакты продуктовой разработки.
❤2👍1
Product Developer pinned «Продуктовый. Разработчик. Прежде всего, надо пояснить за название канала. Какие такие продукты разрабатывает этот парень? Обойдемся без пошлых шуток про арбузы. Всё, о чем буду писать, - про IT. IT с точки зрения программиста, который не ограничивает свою…»
Продукт vs Проект
Попробую объяснить, что такое продукт, через сравнение с проектом.
Проект имеет границы, заданные на этапе запуска. Функции, которые нужно реализовать. Время, за которое нужно успеть. Ресурсы, которые выделили на разработку.
Проект может быть грандиозным: долгим, дорогим, эпическим. Но к моменту окончания проекта он может потерять свою ценность. Мир вокруг убежал вперед за то время, пока проект пилили. Функции, которые появились в рамках проекта, могут быть уже не востребованными.
Как показал прошлый год, востребованность функций может меняться очень резко. Тот, кто не может адаптироваться, обречен.
Продукт решает проблемы пользователя, текущие и будущие. Продукт не ограничен по времени и функциям.
Продукт - это живой организм, которому нужно адаптироваться, чтобы выжить. Конкуренция продуктов напоминает эволюционный отбор: преуспевает наиболее приспособленный.
Так что отличает инженера в проекте от продуктового разработчика? Я убежден, что главное отличие - образ мышления, направленный на преуспевание продукта. На этом образе мышления выстраиваются процессы, позволяющие делать нужные функции своевременно, получать обратную связь от вселенной и меняться с учетом этой обратной связи.
Попробую объяснить, что такое продукт, через сравнение с проектом.
Проект имеет границы, заданные на этапе запуска. Функции, которые нужно реализовать. Время, за которое нужно успеть. Ресурсы, которые выделили на разработку.
Проект может быть грандиозным: долгим, дорогим, эпическим. Но к моменту окончания проекта он может потерять свою ценность. Мир вокруг убежал вперед за то время, пока проект пилили. Функции, которые появились в рамках проекта, могут быть уже не востребованными.
Как показал прошлый год, востребованность функций может меняться очень резко. Тот, кто не может адаптироваться, обречен.
Продукт решает проблемы пользователя, текущие и будущие. Продукт не ограничен по времени и функциям.
Продукт - это живой организм, которому нужно адаптироваться, чтобы выжить. Конкуренция продуктов напоминает эволюционный отбор: преуспевает наиболее приспособленный.
Так что отличает инженера в проекте от продуктового разработчика? Я убежден, что главное отличие - образ мышления, направленный на преуспевание продукта. На этом образе мышления выстраиваются процессы, позволяющие делать нужные функции своевременно, получать обратную связь от вселенной и меняться с учетом этой обратной связи.
❤1👍1
Scrum - это ответ! А какой был ваш вопрос?🙃
Очень часто слышу от людей из разных контор, что вот мол у них Scrum.
А потом от них же слышу “этот _ваш_ скрам не работает”. Потом оказывается, что они просто отсчитывают итерации по две недели. А еще у них четко разделены функции: вот спринт бэкендеров, вот спринт фронтендеров, вот спринт разработчиков баз данных. И планирование спринтов у них раздельное. И каждая функциональная команда является “внешней” для другой функциональной команды. И когда фронтендерам нужно какое-то API, они заводят задачу бэкендерам. Вот такой “этот ваш скрам” точно не работает.
А у нас работает. Но не совсем скрам. Мы руководствуемся теорией ограничений и понимаем что тру-скрам трудно достижим. Это обусловлено в первую очередь нашими ограничениями: большой продукт, большая популяция айтишников, большая база легаси кода и легаси процессов, смежные IT подразделения, работающие с процессами локальных очередей. Мы работаем по фреймворку, который скромно называем Scrum-based LeSS-like.
Основных идей три:
📌- уменьшать количество бэклогов
📌- собрать все нужные компетенции в одной команде
📌- уменьшать внешние зависимости
Очень часто слышу от людей из разных контор, что вот мол у них Scrum.
А потом от них же слышу “этот _ваш_ скрам не работает”. Потом оказывается, что они просто отсчитывают итерации по две недели. А еще у них четко разделены функции: вот спринт бэкендеров, вот спринт фронтендеров, вот спринт разработчиков баз данных. И планирование спринтов у них раздельное. И каждая функциональная команда является “внешней” для другой функциональной команды. И когда фронтендерам нужно какое-то API, они заводят задачу бэкендерам. Вот такой “этот ваш скрам” точно не работает.
А у нас работает. Но не совсем скрам. Мы руководствуемся теорией ограничений и понимаем что тру-скрам трудно достижим. Это обусловлено в первую очередь нашими ограничениями: большой продукт, большая популяция айтишников, большая база легаси кода и легаси процессов, смежные IT подразделения, работающие с процессами локальных очередей. Мы работаем по фреймворку, который скромно называем Scrum-based LeSS-like.
Основных идей три:
📌- уменьшать количество бэклогов
📌- собрать все нужные компетенции в одной команде
📌- уменьшать внешние зависимости
Роли
В этом нашем Scrum-Based LeSS-Like мы выделяем 5 ролей, хотя скрам подразумевает всего 3.
Chief Product Owner - Имеет верхнеуровневое видение вектора развития продукта в целом. Взаимодействует с продуктовыми командами, передает это видение.
Area Product Owner - отвечает за определенную зону продукта. Приоритезирует задачи в бэклоге зоны, чтобы максимизировать ценность своей зоны продукта; Плотно работает с командами в своей зоне;
Product developer - создает качественный регулярный инкремент в продукт. Обычно работают со своим APO;
Product IT Manager - помогает разработчикам продукта поддерживать вектор развития инженерных практик и процессов разработки. И индивидуального развития самих разработчиков;
Scrum master - поддерживает и развивает процессы нашего фреймворка. В нашей команде нет выделенного человека на этой роли, но я считаю что справляемся неплохо и своими силами.
В этом нашем Scrum-Based LeSS-Like мы выделяем 5 ролей, хотя скрам подразумевает всего 3.
Chief Product Owner - Имеет верхнеуровневое видение вектора развития продукта в целом. Взаимодействует с продуктовыми командами, передает это видение.
Area Product Owner - отвечает за определенную зону продукта. Приоритезирует задачи в бэклоге зоны, чтобы максимизировать ценность своей зоны продукта; Плотно работает с командами в своей зоне;
Product developer - создает качественный регулярный инкремент в продукт. Обычно работают со своим APO;
Product IT Manager - помогает разработчикам продукта поддерживать вектор развития инженерных практик и процессов разработки. И индивидуального развития самих разработчиков;
Scrum master - поддерживает и развивает процессы нашего фреймворка. В нашей команде нет выделенного человека на этой роли, но я считаю что справляемся неплохо и своими силами.
Запись в трудовой
Нас, айтишников, в продукте примерно сто-двести человек. То, что написано в трудовой, кажется формальностью.
Но на подсознательном уровне узко-специализированная должность, например, “инженер по тестированию”, может быть стоп-фактором, чтобы начать погружаться в вёрстку. Поэтому сейчас запущен процесс переоформления должностей, чтобы в трудовой так и было написано: “продуктовый разработчик”.
Нас, айтишников, в продукте примерно сто-двести человек. То, что написано в трудовой, кажется формальностью.
Но на подсознательном уровне узко-специализированная должность, например, “инженер по тестированию”, может быть стоп-фактором, чтобы начать погружаться в вёрстку. Поэтому сейчас запущен процесс переоформления должностей, чтобы в трудовой так и было написано: “продуктовый разработчик”.
Ок. Теперь ты продуктовый разработчик. Что дальше?
В серии из 4 постов расскажу о цикле разработки с точки зрения изнутри.
Часть 1 - проработка бэклога.
Работа над задачей начинается гораздо раньше, чем у программиста. До взятия задачи в спринт, команда проясняет все вопросы.
📌- Выпытывает у владельца продукта критерии приемки;
📌- Проводит предоценку: сколько примерно задача принесет денег, и сколько будет стоить в разработке;
📌- Прорабатывает все архитектурные аспекты;
📌- Согласовывает будущие изменения со всеми внешними заинтересованными сторонами;
📌- Понимает, как будет проводить постоценку;
📌- Решает, какой нужен мониторинг работоспособности фичи после спринта;
📌- Составляет верхнеуровневый план спринта.
Это не исчерпывающий список, я покажу наш Definition of Ready for sprint (DoR) позже.
В серии из 4 постов расскажу о цикле разработки с точки зрения изнутри.
Часть 1 - проработка бэклога.
Работа над задачей начинается гораздо раньше, чем у программиста. До взятия задачи в спринт, команда проясняет все вопросы.
📌- Выпытывает у владельца продукта критерии приемки;
📌- Проводит предоценку: сколько примерно задача принесет денег, и сколько будет стоить в разработке;
📌- Прорабатывает все архитектурные аспекты;
📌- Согласовывает будущие изменения со всеми внешними заинтересованными сторонами;
📌- Понимает, как будет проводить постоценку;
📌- Решает, какой нужен мониторинг работоспособности фичи после спринта;
📌- Составляет верхнеуровневый план спринта.
Это не исчерпывающий список, я покажу наш Definition of Ready for sprint (DoR) позже.
Часть 2 - планирование спринта
Спринт начинается с планирования. Чем лучше команда подготовит задачу к спринту, тем быстрее и проще пройдет планирование. Чем четче планирование, тем больше вероятность что мы не отклонимся от плана в спринте. Если идти по плану в спринте, то с большой вероятностью на выходе получится то, чего мы ожидали.
На планировании мы декомпозируем предварительный план на задачи размером не больше дня. Участники берут на себя задачи и распределяют их по дням. При этом желательно оставить время на проработку бэклога и на улучшение процессов и инженерных практик.
После планирования команда расходится работать. Работа может быть как парной, так и индивидуальной. Но каждый понимает вклад его индивидуальной работы в общую цель спринта.
Общая цель - на мой взгляд основное отличие команды от рабочей группы. Конец планирования ознаменует для нас очередную возможность сделать что-то полезное. Мы не фанатики, но в конце планирования в шутку поздравляем друг друга с началом нового спринта🚀
Спринт начинается с планирования. Чем лучше команда подготовит задачу к спринту, тем быстрее и проще пройдет планирование. Чем четче планирование, тем больше вероятность что мы не отклонимся от плана в спринте. Если идти по плану в спринте, то с большой вероятностью на выходе получится то, чего мы ожидали.
На планировании мы декомпозируем предварительный план на задачи размером не больше дня. Участники берут на себя задачи и распределяют их по дням. При этом желательно оставить время на проработку бэклога и на улучшение процессов и инженерных практик.
После планирования команда расходится работать. Работа может быть как парной, так и индивидуальной. Но каждый понимает вклад его индивидуальной работы в общую цель спринта.
Общая цель - на мой взгляд основное отличие команды от рабочей группы. Конец планирования ознаменует для нас очередную возможность сделать что-то полезное. Мы не фанатики, но в конце планирования в шутку поздравляем друг друга с началом нового спринта🚀