Цю статтю ми підготували по завершенню вебінару Олексія Кривицького з командою Poster про перехід та роботу в рамках Large-Scale Scrum (LeSS). Запис вебінару можна переглянути на нашому Youtube каналі.
У дискусії брали участь:
- Алекс Гоголь, шість років працює Full Stack Developer у Poster. Бачив компанію, коли вона була ще доволі малою.
- Юлія Кастерова, QA Engineer у Poster. Минулого місяця виповнилося 4 роки, як працює в Poster. Починала в support, у відділі чатів, й ось плавно дійшла тієї позиції, де зараз.
- Олексій Кривицький, Scrum master чи LeSS master у Poster. На part-time основі допомагає Poster перейти на LeSS та правильно його використовувати.
- Кирило Рекецький, Рroduct manager у Poster. Встиг попрацювати під час попереднього й нинішнього планування, бачив, як усе змінилося.
- Ілля Ковальчук, Head of Engineer. У Poster вже майже 7 років. Бачив компанію дуже маленькою, розміром в одну кімнату. І продовжує тут працювати, коли в Poster більше ніж 200 людей з офісами в кількох країнах та понад 100 клієнтів.
Олексій Кривицький навмисно зібрав розмаїтну, крос-функціональну команду, щоб із різних точок зору розповісти про те, як Poster готувався до переходу на LeSS, та яким чином команда працювала останні півроку.
Що таке Poster?
Poster це українська продуктова компанія. ЇЇ продукт — програма автоматизації процесів закладів для HoReCa (Hotels, Restaurants, Café) від А до Я, які приймають і годують своїх гостей. Ця програма наводить лад у бізнесі та допомагає контролювати продажі, прибуток, склад та виробництво. Місія Poster — полегшувати ведення бізнесу.
Коротко кажучи, щоразу, коли ви заходите в кав’ярню чи ресторан, ваше замовлення приймають, чек надходить на кухню, щоби страву могли приготувати, водночас зі складу списується якась кількість продукції. Ці продажі потрібно якимось чином враховувати. Наприклад, у McDonald's ваше замовлення фіксують у касовому терміналі (POS-терміналі). Poster робить те ж саме, але в сучасному світі, на планшеті, і робить це з дуже класним клієнтським досвідом.
У Poster досить складний домен, оскільки з технічного боку, крім хмарної платформи, команда підтримує велику кількість hardware-пристроїв. Це створює певні особливості. Оскільки Poster працює в ядрі бізнесу, у команди багато взаємодій із законодавством. Наприклад, наразі в Україні активно працюють із Програмним РРО (Реєстратор Розрахункових Операцій). З 1 січня 2022 року в Україні набув чинності закон, згідно з яким використання касових апаратів стало обов’язковим для ФОП 2–4 груп, які проводять розрахункові операції.
У dev-відділі Poster понад 50 осіб. Це продуктова й інженерна команда. Окремо є команда, що займається інфраструктурою, великий відділ технічної підтримки та продажів. 70 % команди знаходиться в Дніпрі (Україна), і близько 30 % працює дистанційно. Причому ті, хто перебувають у Дніпрі, теж здебільшого працюють дистанційно.
Клієнтами Poster є понад 20 тисяч закладів у світі. Команда Poster вважає, що є хоча б в одній країні, якщо в цій країні є хоча б один платний клієнт. Наразі таких країн понад 100. Останні кілька років Poster активно інвестує в Латинську Америку. У них там є офіс та команда, яка займається підтримкою та продажами в цьому регіоні. Зокрема, є продукт іспанською.
Чому LeSS?
Ілля Ковальчук: Ми живемо вже в постковідний період, і наша історія з LeSS дуже добре співвідноситься із початком цього періоду. Той сегмент бізнесу, у якому ми працюємо, зазнав значних змін через коронавірус. Зачинені ресторани відразу змінювали бізнес-модель — переходили на доставлення. І в той момент, коли всі наші клієнти перейшли на доставлення, їм потрібне було не те, що робить наш поточний продукт, а зовсім інше. З усього відділу в 50 осіб ми змогли витягнути по одній людині з кожної команди, зібрали спецзагін, який займався розв’язанням проблем та нових потреб наших клієнтів. Ми не змогли одночасно розгорнути всю компанію для того, щоби дати нашим клієнтам те, що їм було потрібно. І це змусило нас серйозно замислитися про те, чи правильно ми все робимо.
Олексій Кривицький: Тобто до того, як ви перейшли на LeSS чи про нього замислитися, у вас уже була якась кількість команд? До речі, скільки їх було?
Ілля Ковальчук: На той момент ми мали 12 команд. У нас були великі команди по 8–10 осіб, і були команди з однієї-двох осіб. Ми знали правило (перше правило Скрама) і ми намагалися тримати не більше 10 людей у команді.
Олексій Кривицький: Проте за такої умови, особливістю було те, що кожна команда мала якийсь свій вузький фокус, свій напрямок, свої компоненти чи свою фічу? І ти стверджуєш, що це заважало вам разом працювати над чимось спільним?
Ілля Ковальчук: Так, усе правильно. Це були команди, яким належали певні частини системи. Ми називаємо їх компонентами. І попри те, що важливо працювати над чимось одним, вони продовжували працювати над тими завданнями, які є в них у беклозі зі своїм компонентом, навіть якщо це зараз не найважливіше й не найпріоритетніше для компанії.
Олексій Кривицький: З погляду бізнесу, з яких причин було обрано саме LeSS як фреймворк? Яким був перехід, процес переходу?
Ілля Ковальчук: Для мене, як для керівника, дуже привабливою частиною LeSS була історія з можливістю фокусуватися на чомусь одному. Частина про один беклог — це можливість сфокусувати весь відділ на чомусь головному. І я думаю, що це те, що, власне, було ключовим selling point для менеджменту, і загалом для компанії.
Основні страхи із переходом на LeSS
Олексій Кривицький: Після того, як менеджмент компанії відвідав тренінг з LeSS та побачив, що це вирішить їхні проблеми, як далі розвивалися події всередині компанії? Якими були ваші перші думки та побоювання, після того, як ви озвучили намір переходу на LeSS? Що тоді почало відбуватися в компанії?
Юлія Кастерова: Перше, що прозвучало в голові «Стоп, я QA, що зі мною буде далі?». Потім, коли з’явилося трохи більше контексту, стало все зрозуміло. Але виникло побоювання того, що дуже багато нових доменів, нових функціональностей, з якими ти ніколи не стикався. Було багато складних ділянок системи, які дуже страшно зачепити. Тобто, коли кожен QA був у своїй команді до переходу на LeSS, ми трошки побоювалися брати завдання в тестування з інших команд, бо думали: «О Боже, це темний ліс, грець із ним». І були кейси, коли ми навіть відкладали фічі, чекаючи на повернення тестувальника із цієї команди з відпустки або з лікарняного. Також турбувалися щодо sharing інформації.
Олексій Кривицький: Де перебували тестувальники до переходу на LeSS? У командах?
Юлія Кастерова: У нас кожна команда займалася певною сферою, і в кожній команді був тестувальник, який був експертом у цій темі. Наприклад, коли я займалася ЄДАІС (Єдина державна автоматизована інформаційна система в Росії), у нас була маленька вузькоспрямована команда із 2–3х осіб. І мені було, наприклад, страшно занурюватися в тему фіскалізації в Україні, з якою я ніколи не працювала. відповідаючи на твоє запитання, кожен тестувальник був у конкретній команді, яка мала свою експертизу.
Олексій Кривицький: Кириле, питання до тебе: що відбувалося в клані product owner-ів, product manager-ів? Адже LeSS стверджує: «Якщо ви до цього працювали так, що кожна команда мала свій Product Owner-а і свій беклог — забудьте про це, тепер у вас один Product Owner на всіх!». І тепер потрібно вирішити, хто ця одна людина — це буде один із тих, хто був раніше чи хтось інший? До того ж вам треба склеїти всі беклоги в один. Я впевнений, що такі зміни спричинили деякі внутрішні переживання. Поділись, якщо можеш, будь ласка.
Кирило Рекецький: Перше, що лякає продактів — це те, що потрібен лише один Product Owner. Довелося мало не з кожним індивідуально говорити про те, що нічого страшного, бо кожен має свої страхи і свою мотивацію. Для когось страшно втрачати свою стару команду, бо прив’язалися до людей. Хтось не впевнений із приводу того, чи сподобається йому працювати з усім продуктом, а не виключно зі своєю дитиною (=компонентом), яка формувалася впродовж кількох років. Загалом, ти знаходиш усі ці страхи та побоювання, і намагаєшся просто придумати, як це все вирішити, і як показати, що з цього буде пуття. Наприклад, одна з найяскравіших розмов була з розробниками моєї тоді ще команди: «Ми з вами рухаємося дуже швидко в межах нашої сфери, та елемента беклогу, але не завжди наш елемент беклогу супер пріоритетний для всієї компанії. Тому робити швидко, але не те, що потрібно — це не те, що допоможе компанії досягнути успіху».
Олексій Кривицький: Схоже на непростий внутрішній конфлікт. Якісь команди займаються чимось надважливим, а інші — ні. І для продакту це має вигляд, як глибинна робота зі своїм «Его» — віддати свою команду в загальний пул команд на благо компанії — і самому залишитися без команди. За такої умови знати і сподіватися, що твої навички продакт менеджменту будуть потрібні та необхідні в майбутньому. Скільки зараз в 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's більше не потрібні, потрібен лише один, а інших давайте звільняти або перекваліфікувати. Це неправда, вони ще більше потрібні, тому що тепер стратегія продукту одна, і потрібно набагато більше часу провести в дискусіях про стратегію та продукт для того, щоби її сформувати. Тому всі ті навички, які були раніше у PO, вони дуже потрібні.
Друга річ — це, так би мовити, інженерне побоювання. Раніше у всіх інженерів і команд був вузький фокус, вузьке володіння кодом, і будь-яка людина скаже «ownership і focus — це класно». А тепер, як у LeSS, у нас немає фокусу й немає володіння. Але насправді, у нас є й те й інше, тільки вони тепер ширші, на весь продукт! Ледве забігаючи наперед, ми не стверджуємо, що після того, як компанія перейшла на LeSS, усі команди зможуть робити все. Це хибна думка. Усе ще є спеціалізація, усе ще є старі навички, старі знання. Але що важливо — тепер ви можете осмислено ухвалювати рішення, яка команда, над чим працює із загального беклогу, а робити це просто тому, що так склалося.
Чому вибрали LeSS замість LeSS Huge?
Олексій Кривицький: Для мене, як для LeSS коуча (чи LeSS майстра? чи є такий термін?), вибір між каркасами LeSS та LeSS Huge — це досить важливе питання на старті LeSS трансформації. LeSS Huge — це такий собі недо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 Flip Event?
Олексій Кривицький: Наступна частина нашої дискусії — процес переходу на 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 (недосяжним стандартом). Ця версія посередині була тим, що команди фактично вже могли починати робити у перші спринти. Там були пункти про документацію, про onboarding клієнтів. Те, що раніше робилося суто поза командами. Це була друга велика частина нашого Flip Event. Трохи нижче ми ще обговоримо DoD у розрізі перших LeSS-спринтів.
Третя частина — про нові команди. Команди можуть самостійно сформуватися, перебудуватись, якщо дати людям таку можливість. Ми знали за кількістю людей, що має з’явитися шість команд. Ми розставили порожні стільці у вигляді шести кіл. Люди взяли листи А4, виписали на них свої навички, знання: «я вмію тестувати», «я знаю JavaScript» тощо. Після чого ми попросили всіх менеджерів відійти на 20 хвилин і пішла самоорганізація з формування команд. За 20 хвилин ми покликали менеджерів. І запустили раунд фідбеку. Наприклад: у такій команді занадто багато знання такої компоненти, і, відповідно, брак в інших командах. А в іншій команді дуже багато новачків. Після раунду фідбеку цикл самоорганізації повторюється без менеджерів ще 20 хвилин.
Ілля Ковальчук: Коли створювалися команди, менеджмент міг дати свій фідбек після певного туру ітерації. Поділитися думкою, що саме не підходить. Був цікавий момент із командою, де зараз Сашко. У мене були свої побоювання щодо формування цієї команди, і ми домовилися з хлопцями, що залишимо команду як є, якщо вони готові. Але при цьому домовилися, якщо в момент роботи ми одразу побачимо ті речі, яких ми боїмося, команда отримає цей фідбек і потрібно буде приймати рішення. Власне, уже скільки часу минуло, і я до хлопців жодного разу не приходив!
Олексій Кривицький: Загалом, десь за 2–3 ітерації ми сформували адекватні команди. Усі були задоволені. Це були неідеальні команди, таких не буває. Але, що важливо, усі погодилися, що можуть жити з такою структурою. До речі, через півроку, ви зараз живете цими командами, вірно? Чи були якісь сильні перестановки?
Алекс Гоголь: Нічого не змінилося. Саме з команди до іншої команди нікого не переводили. Тобто до нас приходили нові люди, їх додавали до команд, але у складі не було жодних змін, з моменту того, як ми сформувалися вперше.
Перші десять LeSS спринтів.
Олексій Кривицький: Ми в Poster працюємо дистанційно. Добре, що Poster не придбав новий «LeSS automation tool». Тому що проблема не в інструментах, проблема в людях. Використовуємо Zoom та Notion, як такий Spreadsheet, який нам дозволяє менеджити один загальний беклог і це наш фактично knowledge base з усією документацією. Ми використовуємо Miro, коли нам потрібно візуально щось зробити разом. Це шматок нашої спільної дошки, зліва дошки з PBR та з плануванням спринтів. У свій час ми проводили це все у Miro копіюючи картки з Notion. Праворуч ви бачите дошки з ретроспективою, кожна команда має свою дошку, і кожна команда проводить ретроспективи. Спринт рев’ю проводимо в Zoom, туди приходять усі: і інженерний департамент, і люди з саппорту, і будь-хто. Це відкрита зустріч у компанії, де ми дивимося наш веб-продукт, на його інтеграцію. Хтось може показати, як друкуються чеки в реальному часі, і це наш спринт ревью. Але, звичайно ж, не все гладко. Ми вчимося працювати разом і це є суть LeSS — вчитися, отримувати дані, реагувати й тим самим покращувати нашу організацію роботи. Це колективний процес. І ніхто заздалегідь не знає, як краще робити щось. Це постійні експерименти. Іноді, звісно ж і провальні. Але це і є — learning.
Юлія Кастерова: На старті більшість розробників мали відчуття того, що ми дуже повільно рухаємося. На прикладі моєї команди, у нас пішло пів спринту на те, щоби розгорнути проєкт, бо проєкт був складний, знань не було. Я, напевно, цього ніколи не говорила, але тут хочу висловити подяку менеджменту. Нас ніколи не квапили і говорили: «Все окей. Ніхто не чекає якоїсь супер продуктивності, якихось шалених швидкостей роботи, бо всі все розуміють, усі люди, усім треба спершу навчитися». І це дуже добре, отримати таку підтримку та знати, що тебе розуміють.
Ілля Ковальчук: Я хочу доповнити Юлю. Я пам’ятаю свої думки та спогади в один із перших спринтів. Я дуже чітко спіймав себе на думці, що «ось зараз, більша частина компанії працює над найважливішою бізнес-ідеєю, яка в нас є. Так, повільно, але разом. Очевидно, що всі дуже залучені, усі намагаються». І це вперше за історію Постера, щоби така велика кількість людей працювала разом над найважливішим.
Поліпшення в Definition of Done
Юлія Кастерова: Завдання створення 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.
Як відбувається робота далі? Зазвичай, після того, як ми вже вважаємо, що ми завершили роботу над фічею або в процесі розробки, ми просто відзначаємо картки із завданням (чекбокси), що все зроблено та фіча вважається закритою, готовою. Це не якась ідеальна картинка, і це ще не кінець. Завжди прилітають побажання чи зауваження про те, що чогось не вистачає, чи щось не зручно. Тому це нескінченний процес розвитку.
Олексій Кривицький: Додам, що хлопці вирішили в якийсь момент, що фіча називається «готовою», тільки якщо щонайменше один клієнт почав нею користуватися. Тобто, вони не тільки стали ширше дивитися на продукт і глибше володіти загальним кодом, а і взяли всередину команд частину процесів, якими раніше займався інший функціональний відділ у компанії. Мені було дуже приємно, як Скрам-майстру, спостерігати за тим, як ви хочете на себе взяти багато відповідальності та ініціативи. З іншого боку, це було дуже хвилююче. Але що важливо — вчитися брати менше фіч, але доводити їх до більшої готовності. Це культурна зміна.
PBR (Product Backlog Refinement)
Олексій Кривицький: Кириле, як відбувається робота із загальним беклогом? Ми озвучили, що в нас один головний product owner і величезна кількість product managers. Як ви домовляєтеся про те, що потрапляє в беклог?
Кирило Рекецький: У нас шість product managers (далі «продакти»). Ми розподіляємо ініціативи та проблеми між собою. Продакт збирає всю інформацію від саппорта, від фаундера, від девелоперів, вхідну інформацію, й перетворює це на високорівневе завдання чи проблему.
Приблизно така картина. Продакт шукає якісь інсайти ззовні, опрацьовує завдання після релізу, щодо можливості деліверингу. Тобто, клієнти вже підключилися до цієї нової фічі, вони розуміють цю фічу, які фідбеки дають клієнти. Ми проводимо так зване коридорне інтерв’ю, коли ми спілкуємося з клієнтом, щоби зрозуміти, чи розуміє він фічу, яку проблему вона вирішує, які є інсайти. Зараз наш саппорт підключається та самостійно проводить ці інтерв’ю. Це все дає дуже багато інформації для того, щоби фіча реалізовувалась у кілька ітерацій:
Перша ітерація — якийсь MVP.
Друга ітерація — більш-менш повноцінна фіча.
Третя ітерація — якісь покращення.
Власне, продакт після того, як обробив всю інформацію, готує картку для беклогу. Після нього є певний definition of ready. Картка йде на пріоритезацію продактам. Продакти визначають, що ми плануємо, що можемо взяти в PBR, а що після PBR візьмемо розробляти,і у якому пріоритеті. Важливий момент, що на етапі PBR картка може бути повернена продакту. Якщо продакт слабо її опрацював, або в ній дуже багато суперечливих моментів. Продакт, в ідеалі, повинен уособлювати знання щодо проблеми клієнта і власне заделіверити команді саму суть проблеми, не її розв’язання. А команди в нас уже настільки самостійні, що вони у 80 % випадках вигадують краще рішення, ніж будь-хто інший.
Олексій Кривицький: Напевно, варто розповісти як проходить сам PBR. На малюнку шматочок нашої Miro дошки (PBR у грудні)
Як описав Кирило, є ряд зустрічей, де продакт менеджери спілкуються, сперечаються, доводять важливість цінностей. У підсумку, у будь-який момент часу є точна пріоритезована верхівка беклогу. Завдання PBR процесу — зрозуміти цю роботу та опрацювати до такого стану, що її можна брати у спринти. Ми досить багато експериментували, тестували різні підходи. Як цей процес виглядав у грудні? Ось є Mirо, туди приносимо верхівку беклогу з Notion, ось картка чергувань команд на саппорті. Ми домовлялися на кожен спринт, скільки команд із 6 команд розробки йде на «чергування» (третю чергу саппорту). На початку це було дві-три команди. Згодом ця кількість знизилася до однієї команди. Якість продукту зросла. Але, так чи інакше, ми домовляємось, скільки команд нам потрібно на саппорті, якщо ми очікуємо, що в нас йде великий приріст нових фіч чи клієнтів, ми можемо в наступному спринті цю кількість збільшити. Ми маємо таку гнучкість. Ті команди, які йдуть на саппорт у наступному спринті, автоматично не йдуть на спринт. З огляду на це, ми дивимося, чи потрібно їм брати участь на PBR чи ні.
Кілька слів про те, як ми зазвичай проводимо PBR. З самого початку ми перемішуємо членів команд, і такі змішані групи відправляються в Zoom кімнати, де разом опрацьовують деяку кількість пов’язаних елементів беклогу. У кімнатах також працюють один два або скільки потрібно продакт менеджерів, допомагають зрозуміти цінність, суть проблематики. На ці зустрічі ми також намагаємося запрошувати тих, хто знає, з чим стикаються користувачі. Ми можемо запросити людину, яка в саппорті підняла якусь проблему. Або ми запросимо людину з client onboarding, яка може розповісти, що вона знає від клієнтів. Ми намагаємося всіма силами допомогти командам побачити цінність та важливість роботи. Під час цих дискусій створюємо різні графіки, діаграми, внутрішню документацію, і на виході є зрозуміліший, опрацьований елемент беклогу. Можливо, у цьому процесі великий елемент розбився на якусь кількість дрібних, і цей процес повторюється в цих кімнатах із різними людьми доти, доки на виході в нас не з’явиться зрозуміла верхівка беклогу для того, щоби розпочати наступний спринт. Іноді ми призначаємо додаткові PBR, якщо ми розуміємо, що потрібно більше, іноді ні. Правила LeSS — до 10 % спринту присвячувати опрацюванню беклогу наперед. Мені здається, ми ніколи не використовували більше 10 %, але регулярно десь 5–7 % часу витрачали на це.
Олексій Кривицький: І останнє в цьому кейсі, про що ми хочемо поговорити. У нас є беклог, ми його опрацювали, спланували спільний спринт, і команди взяли собі в спринт-беклоги, чим вони займаються. Сашко, питання до тебе — як команди взаємодіють усередині спринту? Як насправді виглядатиме багатокомандна робота над одним продуктом? Як ви працюєте із залежностями, спільною роботою?
Алекс Гоголь:
Декілька практик:
Just talk. Найдієвіше, що ти можеш зробити для того, щоби дізнатися, у якому статусі завдання, — дізнатися, що тобі потрібно зробити з цього завдання. Просто піти до людини, яка може тобі допомогти з цим та просто поговорити.
Загальний чат. До Flip Event наші команди взаємодіяли між собою вже досить багато. Але ж була проблема. Раніше кожна команда мала свою відповідальність, своє таємне братство. Найперша річ, яка в нас з’явилася, це загальний чат на всіх і чат на кілька команд. У нас сталося зрушення від чатів команд, до чатів тем. Наприклад, є чат, який називається «РРО» (касові операції тощо). І кожна команда, яка починає робити фічу по РРО просто додається до цього чату. Одразу його собі м’ютять і потім пасивно беруть участь у дискусії, коли, наприклад, чергують, або беруть активну участь у дискусії, коли вони щось розробляють. Тобто, там обговорюються як технічні питання, так і речі в стилі: "Привіт, я ніколи не працював із якоюсь частиною даних зі звітами, які ми надсилаємо до податкової. Допоможіть мені! Поділіться експертизою."
Community. Це схоже на чати тем, але вони збирається для якоїсь мети. У нас 2 ком’юніті, у яких я беру участь — це definition of done та ком’юніті інженерної культури. В останньому ми приймаємо рішення: як далі розвиватися, які інженерні практики в нас будуть, що ми будемо змінювати у себе в розробці.
Git blame. Наразі немає команди, яка відповідає за щось одне. Наприклад, коли ти копирсаєшся в коді й бачиш незнайомий шматочок коду, то знаходиш, хто цей код написав, приходиш до цієї людини і просиш допомогти розібратися в програмуванні цього елемента. Таким чином, у вас виходить взаємодія, що базується на простій неформальній комунікації.
Що далі?
Ілля Ковальчук: В інжинірингу, у розробці бачу велику можливість займатися тими речами, які ми не робили раніше. Багато хто говорить про інженерні практики, про те, що потрібно писати юніт тести, що потрібно робити код-рев’ю. Ми відчуваємо, що в цьому є потреба, і це те, що треба розвивати. Наш фокус — розвиток інженерних практик. Будемо інвестувати в нашу інфраструктуру. Думаю, що далі буде більше!
Comments