Комментарии 14
Работает у вас всё так же хорошо, как и шестерёнки на КДПВ, которые блокируют друг друга?
только недавно отсмотрел видео о работе в этой прекрасной компании, вроде уже прошли протесты курьеров… поэтому читал статью скептически. пользуюсь приложением уже много лет. Если честно — даже самому интересно что там успела разработать новая команда за это время. Надеюсь одна из следующих публикаций повествует о том что было достигнуто за последние 2-3 года разработки
А я правильно понял что вы к спотифай-модели пришли, да?
Привет!
У нас действительно много атрибутов, которые есть в Spotify-модели. И Inner Source они используют, чтобы не блокироваться релизными циклами соседней команды, и матричная структура, и процесс верификации гипотез — мы адаптируем GIST, а у них это называется Bets, но суть та же.
Но сказать, что прям брали их опыт для копирования, не возьмусь :)
У нас действительно много атрибутов, которые есть в Spotify-модели. И Inner Source они используют, чтобы не блокироваться релизными циклами соседней команды, и матричная структура, и процесс верификации гипотез — мы адаптируем GIST, а у них это называется Bets, но суть та же.
Но сказать, что прям брали их опыт для копирования, не возьмусь :)
А тогда как относитесь к их же статье о том, почему спотифай-модель не работает?
Spotify — это культура в первую очередь, а не модель организации. А культуру невозможно скопировать из организации в организацию.
Мы в свою очередь берем практики и адаптируем под нашу культуру. Практики взяты из разных методологий и предыдущего опыта. В итоге получился единый процесс. Но процесс адаптации всегда уникальный. Думаю, что если и наш случай скопировать полностью в другой компании, то тоже ничего не получится и можно писать статью «Почему продуктовая трансформация не работает» :)
Мы в свою очередь берем практики и адаптируем под нашу культуру. Практики взяты из разных методологий и предыдущего опыта. В итоге получился единый процесс. Но процесс адаптации всегда уникальный. Думаю, что если и наш случай скопировать полностью в другой компании, то тоже ничего не получится и можно писать статью «Почему продуктовая трансформация не работает» :)
Ну вот в их культуре, к которой был адаптирован этот процесс — он не полетел. Почему думаете что у вас полетит в лонгтёрме?
Потому что компании Delivery Club 10 лет и мы являемся лидерами на своём рынке. Кажется, это достаточно лонгтёрм.
За 10 лет было много трансформаций, а в конце 2018-го была одна из них. Модель — это не стратегия, а ответ текущим реалиям (про это как раз я писал в первой статье из этого цикла).
Если угодно, то и опыт Spotify это подтверждает. Они использовали разные модели в разные моменты жизни компании: в зависимости от числа сотрудников, от задач, от особенностей рынка.
За 10 лет было много трансформаций, а в конце 2018-го была одна из них. Модель — это не стратегия, а ответ текущим реалиям (про это как раз я писал в первой статье из этого цикла).
Если угодно, то и опыт Spotify это подтверждает. Они использовали разные модели в разные моменты жизни компании: в зависимости от числа сотрудников, от задач, от особенностей рынка.
У вас описана классика scrum. Напомню, что согласно отцам-основателям методологии (тот же Сазерленд), достижение цели scrum- постоянное повышение производительности- осуществляется улучшением коммуникации внутри команды. Это избавляет от «серых зон», вносящих неопределенность в разработку и, в итоге, в неопределенность со сроками. Но вы указали, что у вас команды 3-7 человек. Это очень компактные команды, в них априори не существует проблем с коммуникацией. Пара-тройка разрабов всегда могут сами за кофе на кухне обсудить вопросы и выбрать техническое решение. Это самый тесный, самый эффективный способ коммуникации. Scrum им для этого не нужен. Почитайте Сазерленда- scrum начинается от 50 человек в команде. Когда коммуникации ослабляются и одна часть команды не знает, что делает другая. Все эти митинги, демо, ретро нацелены именно на то, чтобы команда не разваливалась на отдельные слабосвязанные группы.
На мой взгляд, в вашем случае эффективней будет отказаться от ретро, демо, планирования спринтов. Попробуйте в рамках одной команды провести такой эксперимент в течение полугода: ежедневные летучки и через 2 недели выкладывание в релиз того, что успели. Думаю, вы увидите, что производительность команды возрастёт. Agile-методологии на то и гибкие, что допускают любые отклонения от классической реализации.
На мой взгляд, в вашем случае эффективней будет отказаться от ретро, демо, планирования спринтов. Попробуйте в рамках одной команды провести такой эксперимент в течение полугода: ежедневные летучки и через 2 недели выкладывание в релиз того, что успели. Думаю, вы увидите, что производительность команды возрастёт. Agile-методологии на то и гибкие, что допускают любые отклонения от классической реализации.
Здравствуйте!
Спасибо за комментарий.
Я думаю важным моментом является практика Inner Source, которую мы используем с начала 2019-го года. Да, когда команда изолирована, то коммуникация внутри очень просто происходит, особенно, если внутри команды 3-4 человек.
Но помимо этого есть соседние команды. Коммуникация с ними важна, если команда взяла в Inner Source фичу, сервисы которой находятся во владении другой команды. Далее, есть product-менеджер, который озвучивает требования. Над ним есть ещё stakeholder'ы. Помимо этого есть ещё и другие департаменты: чтобы сделать фичу в логистике, команда плотно общается с операционкой (кол центр, операторы, диспетчеры, etc.), без них фича в вакууме просто не запустится, есть много оффлайн процессов.
Таким образом, область коммуникации выходит далеко за рамки технической команды из 3-7 человек.
Другой момент: планирование спринта, которое происходит за неделю до его начала. Он не просто так был введен, команда производит техническую аналитику. То есть чаще всего это момент, когда техническая команда впервые знакомится с этой фичей.
В этих условиях очень важно иметь предсказуемый измеряемый процесс. В первой статье этого цикла я писал про особенности FoodTech и насколько критично держать низкий Time to market.
Спасибо за комментарий.
Я думаю важным моментом является практика Inner Source, которую мы используем с начала 2019-го года. Да, когда команда изолирована, то коммуникация внутри очень просто происходит, особенно, если внутри команды 3-4 человек.
Но помимо этого есть соседние команды. Коммуникация с ними важна, если команда взяла в Inner Source фичу, сервисы которой находятся во владении другой команды. Далее, есть product-менеджер, который озвучивает требования. Над ним есть ещё stakeholder'ы. Помимо этого есть ещё и другие департаменты: чтобы сделать фичу в логистике, команда плотно общается с операционкой (кол центр, операторы, диспетчеры, etc.), без них фича в вакууме просто не запустится, есть много оффлайн процессов.
Таким образом, область коммуникации выходит далеко за рамки технической команды из 3-7 человек.
Другой момент: планирование спринта, которое происходит за неделю до его начала. Он не просто так был введен, команда производит техническую аналитику. То есть чаще всего это момент, когда техническая команда впервые знакомится с этой фичей.
В этих условиях очень важно иметь предсказуемый измеряемый процесс. В первой статье этого цикла я писал про особенности FoodTech и насколько критично держать низкий Time to market.
Support 20%.
Спасибо за статью! А какая именно деятельность подразумевается под «Support»?
Приветствую!
В Support попадают asap'ы или критичные баги, которые не могут ждать следующего спринта. Как правило они поступают из нашей поддержки, поэтому и Support.
Когда только переходили на этот формат, этот бакет оставался пустым, задачи туда не планировались. Но это усложняло контроль над общим capacity спринта. Не всегда ставились label'ы и не было ясно что изменило спринт, иногда туда попадало слишком много задач, иногда мало :)
В итоге сейчас делаем так: в Product бакет попадают задачи из Ideas (гипотезы в GIST) — стратегические проекты; в Support бакет попадает так называемая «гигиена продукта» — мелкие задачи и минорные фиксы. Если прилетает asap или тикет из поддержки, то заменяем запланированную задачу из Support бакета этой новой задачей. Это упростило контроль состава спринта.
В Support попадают asap'ы или критичные баги, которые не могут ждать следующего спринта. Как правило они поступают из нашей поддержки, поэтому и Support.
Когда только переходили на этот формат, этот бакет оставался пустым, задачи туда не планировались. Но это усложняло контроль над общим capacity спринта. Не всегда ставились label'ы и не было ясно что изменило спринт, иногда туда попадало слишком много задач, иногда мало :)
В итоге сейчас делаем так: в Product бакет попадают задачи из Ideas (гипотезы в GIST) — стратегические проекты; в Support бакет попадает так называемая «гигиена продукта» — мелкие задачи и минорные фиксы. Если прилетает asap или тикет из поддержки, то заменяем запланированную задачу из Support бакета этой новой задачей. Это упростило контроль состава спринта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Продуктовая трансформация в Delivery Club Tech