|
В январе Алексей Кривицкий провел вебинар с командой Poster, чтобы поделиться кейсом перехода и работы в рамках Large-Scale Scrum (LeSS). Запись вебинара можно посмотреть на нашем Youtube канале
В дискуссии принимали участие:
Алексей Кривицкий специально собрал такую разношерстную, кросс-функциональную команду, чтобы с разных сторон рассказать о том, как Poster готовился к переходу на LeSS и как команда работала последние полгода.
Poster - это украинская продуктовая компания. Продуктом является программа по автоматизации от А до Я процессов для HoReCa (Hotels, Restaurants, Café) заведений, которые принимают и кормят своих гостей. Программа наводит порядок в бизнесе и помогает контролировать продажи, прибыль, склад и производство. Миссия Poster - упрощать ведение бизнеса.
Если в двух словах, то каждый раз, когда вы заходите в кофейню или ресторан, ваш заказ принимают, чек отправляется на кухню, чтобы блюдо могли готовить, а со склада списывается какое-то количество продукции. Эти продажи нужно каким-либо образом учитывать. В Макдональдсе, например, ваш заказ пробивают в кассовом терминале (POS-терминале). Poster делает то же самое, но в современном мире, на планшете, и делает это с очень классным пользовательским опытом.
У Poster достаточно сложный домен, поскольку с технической стороны помимо облачной платформы команда поддерживает большое количество hardware-устройств. Это накладывает свои особенности. Плюс, так, как Poster работает в ядре бизнеса, у команды много взаимодействий с законодательством. К примеру, на текущий момент, в Украине активно работают с Программным РРО (Регистратор Расчетных Операций). Так как, с 1 января 2022 года в Украине вступил в силу закон, согласно которому использование кассовых аппаратов стало обязательным для ФЛП 2 — 4 групп, которые проводят расчетные операции.
В dev-отделе Poster больше 50 человек. Это продуктовая команда и инженерная команда. Отдельно есть команда, которая занимается инфраструктурой, большой отдел технической поддержки и продаж. 70% команды находится в Днепре (Украина), и порядка 30% работает удаленно. Причем те, кто находится в Днепре, тоже в большинстве случаев работают удаленно.
Клиентами Poster является больше 20 тысяч заведений в мире. Команда Poster считает, что присутствует хотя бы в одной стране, если у них там есть хотя бы один платный клиент. Сейчас таких стран больше 100. Последние несколько лет Poster активно инвестирует в Латинскую Америку. У них там есть офис и команда, которая занимается поддержкой и продажами в этом регионе. В том числе, есть продукт на испанском.
Илья Ковальчук: Мы живем уже в пост-ковидный период, и наша история с LeSS очень хорошо соотносится как раз с началом этого периода. Тот сегмент бизнеса, в котором мы работаем, был подвержен истории с коронавирусом довольно сильно. Закрытые рестораны сразу же меняли бизнес-модель - переключались на доставку. И в тот момент, когда все наши клиенты перешли на доставку, им нужно было совсем другое. Не то, что делает наш текущий продукт. Мы из всего отдела в 50 человек смогли вытянуть по одному человеку с каждой команды, собрать такой отряд спецназа, который занимался решением проблем и новых потребностей наших клиентов. Мы не смогли в один момент развернуть всю компанию для того, чтобы дать нашим клиентам то, что им было нужно. И это заставило нас серьезно задуматься о том, а правильно ли мы все делаем.
Алексей Кривицкий: То есть, до того, как вы перешли на LeSS или о нем задумались, у вас уже было какое-то количество команд? К слову, сколько их было?
Илья Ковальчук: На тот момент у нас было 12 команд. У нас были большие команды по 8-10 человек, и были команды из одного-двух человек. Мы знали правило (первое правило Скрама) и мы старались держать меньше 10 человек в команде.
Алексей Кривицкий: Но при этом, особенностью было то, что каждая команда имела какой-то свой узкий фокус, свое направление, свои компоненты, или свою фичу? И ты утверждаешь, что это мешало вам, в итоге, вместе работать над чем-то общим?
Илья Ковальчук: Да, все верно. Это были команды, которым принадлежали конкретные части системы. Мы их называем компонентами. И сложность была в том, что, несмотря на то, что важно работать над чем-то одним, они продолжают работать над теми задачами, которые есть у них в бэклоге по своему компоненту, даже если это сейчас не самое важное и не самое приоритетное для компании.
Алексей Кривицкий: С точки зрения бизнеса, по каким причинам был выбран именно LeSS как фреймворк? Как выглядел переход, сам процесс перехода?
Илья Ковальчук: Для меня, как для руководителя, очень привлекательной частью LeSS, была история с возможностью фокусироваться на чем-то одном. Та часть, которая про один бэклог - это возможность сфокусировать весь отдел на чем-то главном. И я думаю, что это вот то, что, собственно, было ключевым selling point для менеджмента, и в целом для компании.
Алексей Кривицкий: После того как менеджмент компании посетил тренинг по LeSS и увидел, что это решит их проблемы, как дальше развивались события внутри компании? Какими были ваши первые мысли и опасения, после того, как вам было озвучено намерение перехода на LeSS? Что тогда начало в компании происходить?
Юлия Кастерова: Первое, что прозвучало в голове “Стоп, я QA, и что со мной будет дальше?”. Потом, когда появилось чуть больше контекста, то стало, в принципе, все понятно. Но появилось опасение того, что очень много новых доменов, новых функциональностей, с которыми ты никогда не сталкивался. Очень много было сложных участков системы, к которым было страшно прикасаться. То есть, когда QA были каждый в своей команды до перехода на LeSS, мы немножечко опасались брать задачи в тестирование с других команд, потому что думали “О Боже, это темный лес, ну его нафиг”. И были кейсы, когда мы даже откладывали фичи до того, как тестировщик из этой команды вернется из отпуска или из больничного. Также переживали в плане sharing информации.
Алексей Кривицкий: Где находились тестировщики до перехода на LeSS? В командах?
Юлия Кастерова: У нас каждая команда занималась определенной своей областью и в каждой команде был тестировщик, который был экспертом в этой теме. Например, когда я занималась ЕГАИС (Единая государственная автоматизированная информационная система в России), у нас была маленькая узконаправленная команда из двух, периодически трех человек. И мне было страшно нырять, например, в тему фискализации в Украине, с которой я никогда не сталкивалась. То есть, если отвечать на твой вопрос, то каждый тестировщик был в конкретной команде, у которой была своя тематика.
Алексей Кривицкий: Кирилл, вопрос к тебе: что происходило в клане product owner-ов, product manager-ов? Потому что LeSS утверждает следующие вещи: “Если вы до этого работали так, что у каждой команды был свой Product Owner и свой бэклог - забудьте об этом, теперь у вас один Product Owner на всех!”. И теперь нужно решить, кто этот один человек - это будет один из тех, кто был раньше или кто-то другой? Плюс вам нужно склеить все бэклоги в один. Я уверен, что такие изменения вызывали некоторые внутренние переживания. Поделись если можешь, пожалуйста, этим.
Кирилл Рекецкий: Первое, что пугает продактов - это то, что нужен только один Product Owner. Пришлось чуть ли не с каждым индивидуально говорить о том, что ничего страшного, потому что у каждого есть свои страхи и свои мотивации. Для кого-то страшно терять свою старую команду, потому что привязались к людям. Кто-то не уверен по поводу того, понравится ли ему работать со всем продуктом, а не исключительно со своим ребенком (=компонентом), которого он там растил на протяжении нескольких лет. B общем, ты находишь все эти страхи и опасения, и пытаешься просто придумать, как это все решить и как показать, что с этого будет дело. Например, один из самых таких ярких разговоров был с разработчиками моей тогда еще команды: “Мы с вами движемся очень быстро в рамках нашей области, в рамках нашего элемента бэклога, Но не всегда наш элемент бэклога супер приоритетный в размерах всей компании. Поэтому делать быстро, но не то что нужно - это не то, что поможет компании прийти к какому-то успеху”. И в принципе, этот аргумент был достаточным для того, чтобы мы засинхронизировались и поняли, куда двигаться в плане орг изменений.
Алексей Кривицкий: Звучит, как очень непростой внутренний конфликт. Какие-то команды по факту сейчас занимаются чем-то супер важным, а какие-то нет. И для продакта это выглядит, как глубинная работа со своим эго - отдать свою команду в общий пул команд во благо компании - и самому остаться без команды. Но при этом знать и надеяться , что твои навыки продакт менеджмента будут нужны и необходимы в будущем. Сколько сейчас к слову в Poster продакт менеджеров?
Кирилл Рекецкий: Шесть продактов и один верховный PO (Product Owner).
Алексей Кривицкий: По факту было так, что, чтобы никто не дрался, никому из бывших PO не дали корону того самого верховного LeSS PO. Ее взял на себя C-level человек, а все product owners имели возможность либо вернуться в команду и программировать, либо стать членом команды PO, как продакт менеджер, и помогать работать с бэклогом. Это не понижение, это валидная опция. Фактически, с одной стороны: у тебя есть твои текущие навыки и желания, с другой: новая схема работы. Твоя задача, как продакта принять этот факт и найти себе место в новой структуре, помочь приносить пользу теми навыками, которые у тебя есть или начать обзаводиться новыми. И что важно - никто не был уволен и никто не ушел. Потому что все нашли место в новой системе.
Кирилл Рекецкий: Основная задача продакта - это находить максимальную пользу для продукта. Будь то самая важная проблема, самая важная возможность или задача. Важно то, какой ты impact можешь дать.
Алексей Кривицкий: Саша, расскажи, что происходило в рядах инженеров. Какие были переживания?
Алекс Гоголь: Мы, разработчики, разделяли предвкушение и возможность сделать impact в какой-то самой важной вещи конкретно. Например, если говорить про меня, я был разработчиком в технической команде, мы занимались самыми хардкорными штуками. Команда была создана, когда был большой запрос на прокачку технической части продукта. Мы занимались самыми сложными вещами за которые никто другой не хотел особо браться. В таком составе мы просуществовали полтора года и к концу своего жизненного цикла очень хорошо закрывали технические задачи, но мы не всегда занимались тем, что по-настоящему важно для клиентов и бизнеса. Мы все ощущали, что есть какая-то более важная вещь, которую мы могли бы сейчас сделать. Впечатлившись LeSS, мы командой решили взять фичу из другого домена - по украинскому законодательству. Это было очень сложно, никто ни в чем не разбирался. Но мы очень хотели попробовать “немножечко помочить ногу в этом бассейне до того, как мы туда нырнем всей компанией”. Получилось сложно, получилось, наверное, не очень качественно, с точки зрения кода, но потом мы справились с этой штукой.
Алексей Кривицкий: То есть, еще до того, как вы перешли на LeSS, вы технической командой взяли на себя что-то, чем вы раньше не занимались, для того чтобы поработать с чем-то новым?
Алекс Гоголь: Да, ты абсолютно прав, мы взяли фичу по законодательству. А законодательство у нас в компании - одна из таких вещей, которая раньше считалась сложной. Мы попросили консультацию всех членов других команд и все равно получилось очень странно. Потому что у нас не было правильных инструментов и правильного понимания, что мы должны делать. Например, код на peer review уходил в другую команду и соответственно, это был огромный блокер в процессе. Потому что у тебя есть scope, и ты делишься этим scope с другой командой, а у нее есть свой scope. Вы как-то там пытаетесь что-то перемешать, они вам взамен отдают свои какие-то ветки, и получается хаос. Это вот то, как мы попробовали первый раз поработать с другим доменом, без применения правильных инструментов многокомандного взаимодействия.
Алексей Кривицкий: Да, LeSS даёт хорошие инструменты работы с этим.
Алекс Гоголь: Так и есть. Но если говорить о том, что было, то основная боязнь у многих, как и у меня, разработчиков была такая: “Как же мы сейчас отдадим свой код другим людям?”. Каждому казалось, что он занимается какой-то сложной вещью. То есть, мега спецификой, для которой нужны особенные знания, и если ты вот этот код кому-то отдашь, то человек обязательно в нем не разберется. В худшем случае не разберется и еще будет ругать тебя. Но, забегая немного наперед, это опасение не подтвердилось, и разобраться оказалось намного проще, чем мы думали.
Алексей Кривицкий: Давайте немного подытожим. Если до LeSS был однокомандный Скрам, то с LeSS перед вам стал “Скрам на всех” - более простая схема работы, казалось бы, но которая порождает много либо правдивых опасений, либо недоразумений. Одну из них мы обсудили. Это что Product Owner'ы больше не нужны, нужен один, давайте всех уволим или переквалифицируем в кого-то другого. Это неправда, они еще больше нужны, потому что теперь стратегия продукта одна, и нужно намного больше времени провести в дискуссиях о стратегии и о продукте для того, чтобы ее сформировать. Поэтому все те навыки, которые были раньше у PO, они все еще мега-мега нужны.
Вторая вещь, это, так сказать, инженерное опасение. Раньше у всех инженеров и команд был узкий фокус, узкое владение кодов, и любой человек скажет “ownership и focus - это же классно”. А теперь, вроде как в LeSS, у нас нет фокуса и нет владения. Но на самом деле, у нас есть и то и другой, только они теперь шире, на весь продукт! Чуть забегая наперед, мы не утверждаем, что после того, как компания перешла на LeSS, все команды смогут делать всё. Это заблуждение. Все еще есть специализация, все еще есть старые навыки, старые знания. Но что важно - теперь вы можете осмысленно принимать решение, какая команда над чем работает из общего бэклога, а делать это просто потому, что так сложилось.
Алексей Кривицкий: Для меня, как для LeSS коуча (или LeSS мастера? а есть ли такой термин?), выбор между каркасами LeSS и LeSS Huge - это довольно важный вопрос на старте LeSS трансформации. LeSS Huge, на самом деле - это такой себе недо-LeSS. Он звучит круче чем LeSS, но это худший LeSS из всех возможных вариантов. Почему? Потому что в нём может скрываться дисфункция. Поясню. На сайте LeSS есть правила внедрения LeSS. И правило такое, что любой LeSS-мега-Huge, начинается с одного работающего LeSS. То есть на старте, какая бы большая организация ни были, мы берём 1) максимально широкое понимание продукта, которое можем заменеджтить одним бэклогом; 2) максимальное количество команд, которое мы можем сформировать - и формируем одну продуктовую группу в LeSS.
У Poster было на старте порядка 50 человек в отделе разработки - это такое количество, которое как раз умещается в один LeSS. И у нас было достаточно времени для подготовки и обсуждения, как стартовать. То ли мы все накидываемся вместе в LeSS, либо мы делаем несколько областей: одну на главный продукт, одну на новый потенциальный бизнес, одну на growth. Так что, перед руководством компании и сотрудниками был ряд опций.
До того, как мы перешли на LeSS и запустили первый спринт, менеджмент компании во главе (или, скажем, с участием Ильи Ковальчука), принял решение, что мы сперва обучим всех инженеров и стейкхолдеров LeSS. И уже после этого вместе примем решение, как запускаемся, когда запускаемся, сколько областей формируем, сколько команд собираем. Это было, пожалуй, самое мудрое решение, которое я слышал от своих клиентов за последние года - обучить всех и потом решать. Потому что, если люди не понимают под какие изменения их приводят, люди не будут знать, что правильно и что неправильно.
И на моей памяти, после ряда обучающих воркшопов, которые у нас были летом 2021 года, в какой-то момент сформировался консенсус: "Давайте начнем все вместе внутри одного LeSS, ведь LeSS, он для того и есть, чтобы учиться работать вместе!”. И было принято решение стартовать вместе, чему я, как ваш коуч, был очень-очень рад.
Илья Ковальчук: История с LeSS и LeSS Huge - это одна из самых тяжелых историй, особенно, когда вы только-только задумываетесь об этом. Я могу рассказать в двух словах о том, какие у нас были опасения и то, как мы думали. Ранее у нас было 12 команд и множество разных мелких направлений - по сути по одному на команду.
Но после обильного количества дискуссий в течение подготовки перехода на LeSS, мы для себя определили три главных стратегических направления, над которыми мы хотим продолжать работать далее. И нам было тяжело думать о LeSS с одним бэклогом на все эти направления. Как будто на нужно было от чего-то отказываться, помещая его в общий бэклог. У нас было ощущение, что если мы сейчас не закрепим за этим направлением Area Product Owners, то мы перестанем заниматься ими, что что-то потеряется, станет. А нам очень хотелось уделять внимания всем трём из этих направлений.
Как же работать с одним бэклогом и с несколькими направлениями? Одна из идей была квотировать, но мы быстро от этого отказались ещё до старта. В конечном итоге, мы задали вопрос себе о том, что же мы продаём? А продаём мы один цельный продукт. И клиент покупает нас, если смотреть широко, по сути за ценность предоставления единого обширного use case, который помогает ему управлять своим бизнесом посредством нашего единого продукта. И это, наверное, послужило основным фактором в принятия решения - старта с одним общим бэклогом на всех. Для тех, кто, возможно, в будущем будет решать как переходить на LeSS, это и есть тот самый важный вопрос, на который, себе нужно ответить: "Что у вас является продуктом?".
Алексей Кривицкий: Как вы на этот вопрос себе ответили тогда?
Илья Ковальчук: Наш use case, который мы решаем, это учет продаж из склада. Это наша основная ценность, которую мы даём клиенту.
Алексей Кривицкий: Следующая часть нашей дискуссии - процесс перехода на LeSS, то, как выглядел сам процесс перехода.
Важно сказать на старте, что по сути, переход на LeSS - это некоторый революционный шаг. Это реструктуризация. Есть такой термин "LeSS Flip" - это пу сти про переворот компании с ног на голову или с головы на ноги - как вам угодно. У нас была внутренняя шутка в Poster, как не допустить back flip, чтобы все не скатилось обратно. И, собственно, важно заметить такую вещь, что мы уже тогда больше года работали в удаленно в условиях Covid и логично было бы проводить LeSS Flip удаленно...
Но в какой-то момент мы одумались и решили собрать всех вместе. Это было второе самое лучшее решение. Потому что после того, как мы пообщались вместе и два дня формировали команды, смотрели на бэклог, учились друг у друга, кто-то сказал: "Я не представляю, как мы могли бы вот это все сделать в Zoom. Мы бы просто бы сдохли".
Сейчас в сети есть много статей/отчетов о том, как компании переходят на LeSS и делают LeSS Flip в онлайне. Но нам это было неинтересно. Есть вещи, которые нельзя сделать симитировать в Zoom/Mirо, к примеру - отвести кого-то в сторонку или заговорить с кем-то случайно, наливая кофе, потом отойти, зацепить кого-то третьего, и вдруг, о чем-то важном поговорить.
Кирилл Рекецкий: Одной из самых сложных штук было расставание с прошлой командой. Это был трогательный и самый тяжелый момент. И второй, по сложности момент был потом, когда мы поняли, что новые рельсы есть, но они абсолютно не чёткие, ещё непонятные для нас. А уже нужно делать новый спринт и при этом еще делать штуку, экспертиза которой в компании чуть-ли всего не у 1-2 людей. Вот это был основной вызов на старте. Я помню первый спринт, который мы планировали в офлайне. Можно было вживую посмотреть, задавать кучу вопросов и это не то же самое, что в Zoom, когда ты подымаешь руку и ждёшь. А там - драка, споры, обсуждение, рисование на бумаге и все остальное. Это очень хорошо сработало тогда для нас - планировать первый спринт вживую ещё на Flip-е.
Алексей Кривицкий: Я хочу сделать небольшое отступление, рассказать о том, что мы сделали в эти два дня. Цель первого дня - увидеть людей в трехмерном измерении, не в Zoom, вспомнить кто есть кто. Были люди, которые пришли в компанию в удалённое время и первый раз видели своих коллег и сзади, и сбоку, и снизу и сверху! Это был неких тимбилдинг. Мы смотрели на цели компании, на общий бэклог. Потому что в LeSS мы не просто начинаем работать новыми командами над чем-угодно. У нас есть список наших вызовов, и мы учимся атаковать их вместе. Мы общались о том, что это за те большие блоки работы, которые стояли перед нами на первые полгода и что хорошо, довольно много было вокруг одной большой темы - изменения законодательства. Уверен, это не случайно так вышло. Это следствие наличия одной стратегии на цельный продукт. Следствие от работы по составлению и приоритизации единого бэклога.
Вторая вещь, которую мы делали на этом мероприятии, мы говорили о Definition of Done (DoD). Важно понимать, что до старта LeSS у нас был десяток команд. И у многих было разное понимание того, что же такое “готово”, когда они говорят, "у нас всё готово”. Я помню, это была довольно сложная дискуссия. Мы пришли к тому, что у нас есть старый definition of done, мы его назвали "DoD 1.0". И мы не хотели быть ниже его, но мы хотели сделать некоторый скачок вперёд, но с другой стороны не такой, чтобы надорваться. Поэтому мы пошли таким процессом - составили идеальный DoD. Там, всё команды пишут код и документацию, онбордят фичи клиентам, и вообще мега-красавчики. Это такой себе DoD на вырост. Он явно был нереален на том этапе развития организации, но тем не менее, важно было его проговорить - как цель развития. Мы его назвали "DoD 3.0". И дальше мы пытались всеми договориться о том, что будем посредине между 1.0 (нашего текущего состояния дел) или 3.0 (недостижимым стандартом). Эта версия по средине была тем, что команды фактически уже могли начинать учиться делать из DoD 3.0 первые спринты. Там были пункты было про документацию, про onboarding клиентов. То, что ранее делалось сугубо вне команд. Это вот всё была вторая большая часть этого нашего Flip Event. Чуть ниже мы ещё затронем тему DoD в разрезе первых LeSS-спринтов.
Третья часть - про новые команды. Команды могут самостоятельно сформироваться, перестроиться, если дать людям такую возможность. Мы знали по количеству людей, что у нас должно появиться порядка шести команд. Мы расставили постые стулья в форме шести кругов. Люди взяли листы А4, выписали на них свои навыки, знания: "я умею кодить такой-то бекэнд", "я умею тестить", "я знаю JavaScript" и т.д. После чего мы попросили всех менеджеров удалиться на 20 минут, и пошла самоорганизация по формированию команд. Через 20 минут мы позвали менеджеров. И запустили раунд фидбека. Например: в такой-то команде слишком много знания такой-то компоненты, и соответственно, нехватка в других командах. А в другой команде слишком много новичков. После раунда фидбека цикл самоорганизации повторяется без менеджеров ещё 20 минут...
Илья Ковальчук: Когда команды делились, менеджмент мог дать свой фидбек после какого-то определенного тура итерации. Конкретно, что кажется, что не подходит в этой команде. Был интересный момент с командой, в которой сейчас Саша. У меня были свои опасения по поводу формирования этой команды, и мы договорились с ребятами, что оставим команду как есть, если они готовы. Но при этом договорились, если в момент работы мы сразу увидим те вещи, которых мы боимся, команда получит этот фидбек и нужно будет предпринимать какие-то решения. Собственно, уже сколько времени прошло и я к ребятам ни разу не приходил!
Алексей Кривицкий: Прикольно! В общем, где-то за 2-3 раза мы смогли сформировать адекватные команды. Все были довольны. Это были неидеальный команды, таких не бывает. Но что важно - все согласились, что могут жить с такой структурой. К слову полгода спустя, вы сейчас живете этими командами, верно? Или были какие-то сильные перестановки?
Алекс Гоголь: Ничего не поменялось. Именно с команды в команду никого не переводили. То есть, к нам приходили новые люди, их добавляли в команды, но изменений в составах, с момента того, как мы сформировались в первый раз, не было никаких.
Алексей Кривицкий: Мы в Poster работаем удаленно. Благо, Poster не купил никакой новый "LeSS automation tool". Потому что проблема не в инструментах, проблема в людях. Используем Zoom и Notion, как такой Spreadsheet, который нам позволяет менеджерить один общий бэклог и это наш фактически knowledge base со всей документацией. Мы используем Miro, когда нам нужно визуально что-то вместе поделать. Это кусок нашей общей доски, слева доски с PBR и с планированием спринтов. Одно время мы проводили это все в Miro копируя карточки из Notion. С правой стороны, вы видите доски с ретроспективой, у каждой команды есть своя доска, и каждая команда проводит ретроспективы. Спринт ревью проводим в Zoom, туда приходят все: и сотрудники инженерного департамента, и саппорта, и кто угодно. Это открытая встреча в компании, где мы смотрим наш веб продукт, мы смотрим на его интеграцию. Кто-то может показать как печатаются чеки в реальном времени, и это наш спринт ревью. Но конечно же, не всё гладко-идеально. Мы учимся работать вместе и это и есть суть LeSS - учиться, получать данные, реагировать и тем самым улучшать нашу организацию работы. Это коллективный процесс. И никто заранее не знает, как лучше что-то делать. Это постоянные эксперименты. Иногда, конечно, же и провальные. Но это и есть - learning.
Юлия Кастерова: На старте у большинства разработчиков было ощущение того, что мы очень медленно движемся. На примере моей команды, у нас ушло полспринта на то, чтобы развернуть проект, потому что проект был сложный, знаний не было. Я, наверное, не говорила этого никогда, но тут хочу выразить благодарность менеджменту. Нас никогда не торопили и говорили: "Ребята все окей. Никто не ожидает какой-то супер продуктивности, каких-то бешеных скоростей работы, потому что все всё понимают, все люди, всем нужно научиться спервая". И это очень хорошо, получить такую поддержку и знать то, что тебя понимают. Потому что ощущение какой-то гонки всё-таки тянулось достаточно долго. Не только первый спринт, но и пару последующих спринтов.
Илья Ковальчук: Я хочу дополнить Юлю. Я помню свои мысли и воспоминания в один из первых спринтов. Я очень чётко словил себя на мысли, что “вот сейчас, большая часть компании работает над самой важной бизнес идеей, которая у нас есть. Да, медленно, но вместе над самым важным. Видно, что все очень вовлечены, все стараются”. И это впервые за историю Постера, чтобы такое большое количество людей работали вместе над самым важным.
Юлия Кастерова: Задача создания Definition of Done, на первый взгляд, казалась очень простой. На самом деле, количество дискуссий, количество времени, которое мы потратили, показало обратное. Я была в рядах сообщества по работе с DoD. Мы провели много встреч первые спринты, пытаясь его структурировать. С переходом на LeSS мы осознали, что нам нужно фокусироваться не только на технических каких-то отдельных задачах, а на фиче в целом. И тут пришло осознание того, что над фичей работают не только разработчики или не только тестировщик. На фиче завязано много других команд, много других сотрудников, поэтому нам пришлось изменить немного подход к тому, как мы описываем, коммуницируем и работаем с Definition of Done в спринтах.
Мы разделили DoD и работу с ним по сути на 4 блока:
Первое, это качество кода и тестирования. В первую очередь, code review и покрытие автотестами кода. Мы и до Flip, проводили review, мы писали тесты. Но мы решили сделать это чуть более обязательным и чуть более формальным. Приняли такое решение, что все новые фичи мы будем покрывать тестами и будем идти от более низкоуровневых тестов и дальше. Если мы по какой-либо причине можем покрывать низкоуровневыми тестами, то будем смотреть какие куски мы можем покрыть более высокоуровневые.
Второй блок - документация. Здесь стоит выделить два направления: первое, это внутренняя документация для dev-отдела, и второе - это внутренняя документация для сотрудников Poster, но сфокусирована больше на других отделах. Объясню почему так. Почему нам понадобилась документация более четкая внутри отдела? Опять же, все упирается в sharing знаний. Нам нужно было как-то где-то размещать те знания, домены, которые у нас есть, чтобы любой сотрудник, который сталкивался с какой-либо фичей, мог заглянуть в документацию и познакомиться с ней. Техническая документация для dev-отдела включает в себя в основном требования по продукту, и мы начали писать документацию по тем инструментам, которые мы используем. Банальный пример - это развернуть проект. Вот как я уже раньше говорила мы с нашей командой, столкнулись с тем, что мы пол спринта только занимались разворачиванием проекта. Все по причине того, что раньше с этой сферой работала только одна команда и больше ни у кого не было знаний. И задокументированных знаний этих не было. Поэтому, мы решили выделить это отдельным пунктом definition of done. И теперь после каждой фичи или как только сотрудник сталкивается с чем-то, он это описывает и это реально уже сейчас приносит свои плоды. Уже сейчас это намного проще. Второй вектор документации - это документация для сотрудников отдела поддержки и отдела продаж. Это больше формат статей, где мы можем уже более понятным языком описать как работает фича, как она должна работать. Мы можем приводить примеры, можем добавлять скрины. Есть статьи, где мы пролинковывали видео, получали очень хороший фидбек от сотрудников с других отделов. Это стало приносить больше пользы, чем это было раньше.
Следующий блок - это ревью фич. Мы пришли к тому, что круто проводить ревью, всеми сотрудниками, которые к нему могут быть причастны. Это и команда, это и UX-ревью, и продуктовое ревью. Мы создаем отдельный звонок, в котором собираем сотрудников, которые нам нужны. Условно, нам нужен дизайнер для ревью дизайнов, UX-райтер возможно, и всегда есть PM, который работал с этой задачей. Таким образом, в этом звонке мы двигаемся по всему flow, который разработали, по всей фиче. И мы таким способом выявляем те элементы, которые могли упустить. Это могут быть какие-то правки в дизайне, могут быть какие-то правки в тексте, или мы также можем выделять какие-то задачи, которые мы либо берем в доработку, либо мы понимаем, что фича сейчас не готова и нам нужно что-то доработать.
И последний пункт - напоминалки. Не очень красиво обозвала, но, на самом деле, очень полезная штука. Я туда объединила метрики, разбор какой-то тестовой группы, взаимодействия с командой онбординга. Все такие штуки, которые нам не обязательны, возможно они не пригодятся в конкретной задаче. Например, у нас есть фича, которую мы можем “вылить” на всех клиентов и нам не обязательно искать тестовую группу. Но это больше о том, чтобы напомнить, что вот чек-метод, возможно он тебе понадобится. То есть, необязательно его делать, но ты можешь о нем забыть, поэтому будет круто, если он есть в DoD.
Как проходит дальше работа? Обычно, после того, как мы уже считаем, что мы завершили работу над фичей или в процессе разработки, мы просто отмечаем карточки с задачей (чекбоксы), что все сделано и фича считается закрытой, готовой. Это не какая-то идеальная картинка, и это еще не конец. Всегда прилетают пожелания какие-то или замечания о том, что чего-то не хватает, или что-то не удобно. Поэтому, это бесконечный процесс развития.
Алексей Кривицкий: Добавлю, что ребята решили в какой-то момент, что фича называется “готовой”, только если как минимум один клиент начал ею пользоваться. То есть, они не только стали шире смотреть на продукт и глубже владеть общим кодом, но и взяли внутрь команд часть процессов, которыми раньше занимался вообще другой функциональный отдел в компании. Мне было очень приятно, как Скрам-мастеру, наблюдать за тем, как вы много на себя хотите взять ответственности и инициативы. Но с другой стороны, это было очень волнительно. Но что важно - учиться брать меньше фич, но доводить их до большей готовности. Это культурное изменение.
Алексей Кривицкий: Кирилл, как происходит работа с общим бэклогом? Мы озвучили, что у нас один главный product owner и множество product managers. Как вы договариваетесь о том, что попадает в бэклог?
Кирилл Рекецкий: У нас шесть product managers (далее "продакты"). Мы распределяем между собой инициативы и проблемы. Продакт собирает всю информацию от саппорта, от фаундера, данные от девелоперов, входящую информацию и преобразует это в некую высокоуровневую задачу либо проблему.
Примерно так выглядит картина. То есть, продакт ищет какие-то инсайты извне. Продакт прорабатывает задачу после релиза, на предмет ее деливеринга. То есть, клиенты подключились к этой новой фиче, они понимают эту фичу, какие фидбеки клиенты дают. Мы проводим так называемое коридорное интервью, когда мы общаемся с клиентом, чтобы понять понимает ли он фичу, какую проблему она решает, какие есть инсайты. Сейчас наш саппорт подключается и самостоятельно проводит эти интервью. Это все дает очень много информации для того, чтобы фича реализовывалась в несколько итераций:
Собственно, продакт после того, как обработал всю информацию, готовит дальше карточку для бэклога. После у него есть некий definition of ready. Карточка идет на приоритизацию продактам. Продакты определяют, что мы планируем, что можем взять в PBR и что после PBR в каком приоритете возьмем разрабатывать. Важный момент, что на этапе PBR, карточка может быть возвращена продакту. Если продакт слабо её проработал, либо в ней очень много спорных моментов. Продакт, в идеале, должен собирать в себе знания по поводу проблемы клиента и собственно заделиверить команде саму суть проблемы, не решение. А команды у нас уже настолько самостоятельны, что они в 80% случаях придумывает лучшее решение, чем кто-либо другой. То есть, команда самостоятельна в принятии решений и в поиске решения. Задача продакта сводится к тому, чтобы найти самую большую и сложную проблему, которая больше всего даст импакта бизнесу, либо же клиентам. И собственно принести и доказать, что это важно.
Алексей Кривицкий: Наверное стоит рассказать как проходит сам PBR. На картинке кусочек нашей Miro доски (PBR в декабре)
Как описал Кирилл есть ряд встреч, где продакт менеджеры общаются, спорят, доказывают важность ценностей. В итоге, в каждый момент времени есть чёткое приоритезированная верхушка бэклога. Задача PBR процесса - понять эту работу и проработать до того состояния, что её можно брать в спринты. Мы довольно много экспериментировали, пробовали разные подходы. Как этот процесс выглядел в декабре? Вот есть Mirо, туда приносится верхушка бэклога из Notion, вот карта дежурств команд на саппорте. Мы договаривались на каждый спринт, сколько команд из 6 команд разработки идёт на “дежурство” (третью очередь саппорта). В начале это было 2-3 команды. Позже это количество упало до одной команды. Качество продукта выросло. Но так или иначе мы договариваемся, сколько команд нам нужно на саппорте. Если мы ожидаем, что у нас идёт большой прирост новых фич или клиентов, мы можем в следующем спринте это количество увеличить. У нас есть такая гибкость. Те команды, которые идут на саппорт в следующем спринте автоматически не идут на спринт. Соответственно, исходя из этого мы смотрим, нужно ли им участвовать на PBR или нет.
Пара слов о том, как мы чаще всего проводим PBR. Мы на старте перемешиваем членов команд, и такие смешанные группы отправляются в комнату в Zoom, где они вместе прорабатывают некоторое количество связанных элементов бэклога. В комнатах также работают один, два или сколько нужно продакт менеджеров, помогают понять ценность, суть проблематики. На эти встречи мы также стараемся звать тех, кто знает, с чем сталкиваются пользователи. Мы можем позвать человека, который на саппорте поднял какую-то проблему. Или мы зовем человека из client onboarding, который рассказывает что знает от клиентов. То есть, мы пытаемся всеми силами помочь командам увидеть ценность и важность работы. В ходе этих дискуссий рисуются разные графики, диаграммы, внутренняя документация, и на выходе есть более понятный, проработанный элемент бэклога. Возможно, в этом процессе большой элемент разбился на какое-то количество мелких, и этот процесс повторяется в этих комнатах с разными людьми до тех пор, пока на выходе у нас не появится верхушка бэклога, достаточная для того, чтобы начать следующий спринт. Иногда мы назначаем дополнительные PBR, если мы понимаем, что нужно больше, иногда нет. Правила LeSS - до 10% спринта посвящать проработке бэклога наперед. Мне кажется, мы никогда не влазили за 10%, но где 5-7% времени у нас на это уходило регулярно.
Алексей Кривицкий: И последнее в этом кейсе, о чем мы хотим поговорить. У нас есть бэклог, да мы его проработали, да мы спланировали общий спринт, и команды взяли себе в спринт-бэклоги, то чем они занимаются. Саша, вопрос к тебе - как команды взаимодействуют внутри спринта? Как по сути выглядить многокомандная работа над одним продуктом? Как вы работаете с зависимостями, общей работой?
Алекс Гоголь:
Несколько практик:
Just talk. Самое действенное, что ты можешь сделать для того, чтобы узнать в каком статусе задача - узнать что тебе нужно сделать по этой задаче. Просто пойти к человеку, который может тебе помочь с этим и просто поговорить.
Общий чат. До Flip Event наши команды между собой взаимодействовали уже достаточно много. Но была проблема. Раньше у каждой команды была своя ответственность, свое секретное братство. Самая первая вещь, которая у нас появилась это общий чат на всех и чат на несколько команд. У нас произошел сдвиг от чатов команд, к чатам тем. Например, есть чат, который называется "РРО" (касовые операции и тп). И каждая команда, которая начинает делать фичу по РРО просто добавляется в этот чат. Сразу его себе мьютят и потом пассивно участвуют в дискуссии, когда например, дежурят, либо активно участвует в дискуссии, либо когда они что-то разрабатывают. То есть, там обсуждаются как технические вопросы, так и вещи в стиле: “Привет, я никогда не работал с какой-то частью данных, которых мы отправляем в налоговую, с какими-то отчетностями. Помогите мне! Поделитесь экспертизой.”
Community. Это похоже на чаты тем, но она собирается больше под какую-то цель. У нас 2 коммьюнити, в которых я участвую - это definition of done и коммьюнити инженерной культуры. В последнем мы принимаем какие-то решения: как дальше будем развиваться, какие инженерные практики у нас будут, что мы будем менять у себя в разработке.
Git blame. Сейчас нет команды, которая отвечает за что-то одно. И вот, когда ты копаешься в коде и видишь незнакомый кусочек кода, то смотришь, кто этот код написал, приходишь к этому человеку и просишь его помочь разобраться в программировании этого элемента. Таким образом у вас получается взаимодействие, которое основано на простой неформальной коммуникации.
Илья Ковальчук: Со своей стороны в инжиниринге, в разработке вижу большое количество возможностей заниматься теми вещами, которыми мы раньше не занимались. Многие говорят об инженерных практиках, о том, что нужно писать юнит тесты, что нужно делать код ревью. Мы чувствуем, что в этом есть необходимость и это то, что нужно развивать. Дальше мы будем фокусироваться на развитии инженерных практик, мы будем инвестировать в нашу инфраструктуру. Думаю, что дальше будет больше!
У січні Олексій Кривицький провів вебінар із командою Poster, щоби поділитися кейсом переходу та роботи в рамках Large-Scale Scrum (LeSS). Українська версія матеріалу.
Сьогодні у нас в PandaDoc більше ніж 40 команд, які працюють разом над розвитком продукту. Ця стаття має на меті розкрити вам структуру та процеси у компанії, як воно є, та показати поточний стан нашої організації, основні правила та рекомендації, яких ми дотримуємося.
Це переклад матеріалу "General System Behavior and Morphology", оригінал якого розміщений за цим посиланням.
1. Якщо щось може піти не так, це станеться.
Це вічне як «закон Мерфі», досить суворе спостереження насправді є узагальненою версією коментаря, зробленого капітаном ЗПС США Едом …
