Стаття як раз про це.
Але проблема виявилася в тому, що кожна з команд вела власний беклог за своїм компонентом. Розробники брали з нього задачі, навіть якщо у конкретний момент часу ці тікети не були найважливішими та найпріоритетнішими для компанії та продукту загалом.
Ви неуважно читали статтю, я гадаю.
Value Steam Mapping може не лише дати усвідомлення того, що усі Ваші компоненти насправді формують один єдиний продукт з точки зору клієнта, але й виявити що один чи декілька ваших компонентів можуть служити як окремий продукт, але для іншої цільової аудиторії.
У Постера один продукт. З точки зору широкої дефініції продукту як того, что є enabler of the business model. Та насправді є різні клієнтськи портрети, B2B, B2B2C...
Але ми хотіли прийти до такого широкого розуміння — в нас один продукт. Один на всіх. Ламаємо стіни.
І для цього ми використовували системне мислення. З якого стає очевидно, що розщеплення продукту на куски і беклоги приводить до локальних оптимізацій: «моє — не моє», «наша хата з краю», «ми своє зробили»...
Читаємо тут: https://less.works/less/framework/product
2&3. За що відповідають у вашій моделі новопризначені продакт менеджери, враховуючи, що за єдиний наявний продакт беклог відповідає Product Owner = CEO?
Ніякий PO не працює наодинці. Тим більше в маштабному продукті. Продакт менеджери Постера працюють як команда поруч з PO.
Вони також допомагають командам дізнатися деталей елементів беклогу (який пріорітезує PO) та задизайніти гарні фічі.
А як ви бачите роботу PO наодинці? Це нереально.
Епіхарію, відповідаю на ваше питання.
1. На зображенні ’Як ми працбємо зараз’ вказано ’5 крос-КОМПОНЕНТНИХ інженерних команд’, звідси й питання. Зараз ви пишете про крос-функційні крос-компонентні кастомер-фейсинг команди. Навіщо для команд, що вже й так крос-функційні, наголошувати на їх крос-компонентності? Перше визначення є ширшим.
Команда може будет кросс-ф і при тому працювати тільки над одним модулем системи — аналізувати, розробляти, тестувати. То є функції команди. Але не кросс-компонентність.
Кросс-компонентні команди — це ортогональна дефініція. Ми маємо наувазі, що вони не тільки покривають всі функції, а й працюють кріз продукт.
В однокомандному Скрамі — де на весь продукт є одна команда, дійсно, ніхто не говорить про крос-компонентність. Але в маштабі — то є сама важка річ.
В матеріалах LeSS є така мапа: https://less.works/less/adoption/feature-team-adoption_map. Там по осі X: кросс-ф, а по осі Y: кросс-комп.
Гарне питання. Команди беруть роботу з єдиного продакт беклогу з глобальними пріорітетами, а не роблять те, що хотять.
Станіславе
Постер навчив усіх інженерів, менеджерів та С-level системному мисленню та LeSS. Після цього альтернативи не розглядалися.
Чому? Тому ще optimizing goal з LeSS співпав з тим, що було потрібно Постеру. А саме — адаптивність для пошуку цінності та ії постачання.
Навіщо шукати іншу жінку, коли ти закохався?
Романе
У Постері на всю компанію — ОДИН продукт. Це теж була зміна. Зміна в розумінні свого продукту.
Тому їм не потрібно робити value stream mapping.
Романе. Уся ця стаття про орг зміни. Вчитайтеся.
1. Постер пішов від підходу компонентних команд на feature cross-functional cross-component customet-facing команд. Це орг зміна.
2. Постер прибрав позицію team-level product owner. Це дуже важка і суттєва орг зміна. Ці люди знайшли нову роботу всередині Постера. Де-кто з них пішов у команду. Де-кто став продакт менеджером
3. Постер поставив 1 Product Owner. Це СЕО компанії. Це мега орга зміна.
4. Постер перейшов на 1 продакт беклог із цілями замість 10 беклогів з тасками. Це орг зміна.
5. Команди відкрили свої репозиторії одна для одної. Internal open source. Це суттєва орг зміна в інженерній культури.
6. Постер прибрар позицію team lead що була всередені команди. Замість цього ввели позицію Engineering Manager. Це
І багато чого ще.
Людей не можна «переформувати». Poster зробив умови, в яких спеціалізовані розробники можуть також розвиватись в шир.
Це не або те .. або те. LeSS цінує глибоких спеціалістів. І також прагне допомогти командам працювати над тим, що потрібно бізнесу та клієнтам. А це не завжди тільки те, в чому зараз є максимальна спеціалізація.
больше денег можно просить всегда, когда клиент доволен.
Олексий
к сожалению, адекватной альтернативы слова
коучингна русском нет. найдете — пишите.
к скраму и правда накопилось в индустрии много претензий. но давайте разбираться:
на моем опыте половина из них вызвана просто непониманием самих принципов (это лечится тренингами, отчасти), вторая половина тем, что компании, заявляющие о внедрении скрам, на самом деле не хотят меняться вовсе. и поэтому адаптируют каркас, не понимая, его сути. это опасно.
винить скрам в чем-то по сути бессмысленно и непродуктивно. по своей сути, скрам — это очень леговесный набор правил. целью которого является наладить ряд обратных связей для повышения прозрачности ситуации. это в своей сути все. ничего об оценках, велосити, менеджерах, отчетах, длинных неинтересных совещаниях по грумингу...
есть такая метафора, что скрам — дает зеркало. это так, если его правильно внедрить. без всего мусора, с которым он ассоциируется.
а то, что потом в этом зеркале видны кривые рожи (не примите лично!) — ну да, некомфортно, но ведь они там и раньше были. просто зеркало было замыленным.
так что вреда от скрама быть не может в принципе. как от зеркала. как от обратной связи. как от прозрачности. просто начнут происходить вещи, которые давно должны были случиться. и куча всяких проблем всплывет наружу, но они скорее всего и раньше были.
так, что скрам безопасен, если внедрен опытными людьми (отсюда и вся эта статья о скрам-мастерстве)
безопасен...НО! кроме случаев, когда вместо скрама подается что-то очень кривое с таким же названием. к сожалению, 80% команд и компаний украины если не больше делают скрам очень криво. и это ведет очень часто к наращиванию тех долга, эксплуатации команды, недовольству команд и проч.
вот это и нужно чинить. а не скрам.
по поводу вреда кривого скрама есть есть крутая статья апологета xp по этому поводу: ronjeffries.com/...
разница не очевидная, но есть.
на самом деле есть, как минимум, 4 стиля работы с группой (или человеком):
— фасилитация (применимо только для группы)
— коучинг
— менторинг (наставничество)
— обучение
отличие обучения от коучинга в том, что первое подразумевает, что у клиента нет знаний, и что их нужно дать. коучинг же подразумевает, что у клиента уже есть все необходимое, ему нужно просто поддержать и помочь вопросами открыть для себя ответы.
agile коучинг — это по сути смешение всех приведенных 4 стилей работы, отсюда часто возникает путаница.
ищите дальше. такие проекты-команды-компании есть.
“common sense is not that common” как известно.
вижу в этом мире скопилось много обиженных «скрамом» людей. очень жаль.. и как минимум половина «озлоблённых» (как видно из комментариев) работающий скрам в глаза-то и не видела.
жаль. реально. ибо классная команда, тесно работающая с заказчиком — это прекрасное зрелище.
сходите может в гости в компании, где всё в порядке? поговорите с людьми, у которых есть позитивный опыт?
слелайте что-то с собой толковое. правда.
скептицизм — это вообще хороший знак, знак потенциала для развития.
цинизм же — нет, тупик для мозга.
решать вам.
предоставлять клиенту качественный сервис по разработке ПО
а у вас что, делание успешных продуктов не входит в спектр услуг?
согласен полностью.
но статья о том, как решать проблему уже после сейлов. конечно же, root cause — глубже.
Вони НЕ працюють, як Area Product Owners — то є тема з LeSS Huge, де 8+ команд, і один PO вже не справляється.
В постері — LeSS. Один на всіх. Один ПО, один Беклог на всі команди.
Продакт менеджери працюють... продакт менеджерами, допомогаючи робити класний продукт. Але вони НЕ володіють беклогами. В деяких речах вони насправді — subject matter experts, деколи вони експерти в product discovery process.