Comments 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 бакета этой новой задачей. Это упростило контроль состава спринта.
Sign up to leave a comment.
Продуктовая трансформация в Delivery Club Tech