Як перейти на новий фреймворк і не вбити якість продукту

Стаття написана у співавторстві з Мері Ротарь , Co-Founder IAMPM.

У статті розглянемо досвід зміни SDLC і підходу до роботи з якістю в проекті на ScrumBut. Охопити всі аспекти не вийде, тому зупинюся на найбільш цікавих і найбільш болючих сторони проекту.

Думаю, історія буде корисна менеджерам і всім, хто відповідає за кінцевий результат перед замовником.

Як все починалося

У ті роки, коли в Києві взимку ще був сніг, а Андрій Шевченко грав у «Динамо», я працював РМ'ом у невеликій проектній команді з семи чоловік, яка розробляла для великого замовника.

Новий проект був пов'язаний з обробкою документів в одній з держустанов:

система перетворювала вхідні документи за допомогою вбудованого механізму, який ми придбали у третьої компанії;
ці документи викладалися на онлайн-порталі з різними рівнями доступу: деякі були повністю відкриті, інші — тільки для авторизованих користувачів;
портал відвідували близько 300 тис. унікальних користувачів на місяць, що для цього ресурсу було досить непогано.

Всередині, в бек-офісі, з продуктом працювало близько 50 співробітників, які відповідали за наповнення порталу як контент-редактори і контент-менеджери. Цей відділ безпосередньо використовував ЗА наше. Другий відділ займався інфраструктурою і підтримкою серверної частини, а третій — контролював два попередніх. Причому поставити нам завдання могли співробітники кожного відділу.

З чим зіткнулися

У той час, коли я прийшов в проект, там був постійний хаос і проблеми: ми не потрапляли у власні оцінки, команда не вкладалася в строки, пріоритети розподілялися за відомим принципом HiPPO . Доводилося занурюватися і вивчати, чому так відбувається.

Проблема 1. За все відповідає підрядник. Тобто ми

Оскільки функціональність порталу забезпечували три відділи, при виникненні проблем відповідальних не знаходилося . У кожного були свої залізобетонні відмовки, і якщо треба було вирішити якісь питання, ми починали ходити по колу.

В держсекторі робота спочатку поставлена за принципом, що замовник прав без варіантів. Або так — підрядник завжди не правий :) Ми як підрядники повинні підкорятися рішенням замовника, але в разі проблем винними, природно, зроблять нас.

Нам було складно фокусуватися на реальній поставці, на те, що приносить цінність клієнта, тому що постійно виникало питання: «На кого покласти відповідальність?». З замовником обговорювали в основному не потрібну функціональність, а те, як покарати невинних і нагородження непричетних. Ці обговорення іноді тривали 3-4 години.

Проблема 2. Ні планування, зате є дедлайни

Замовник не міг чітко сформулювати, як розвивати продукт, тому що багато моментів вимагали узгодження з вищими інстанціями. Він підпорядковувався міністерству, а оскільки це держсектор, такі узгодження розтягувалися нехай не на місяці, але на тижні точно. Гаразд, що я приукрашиваю: одного разу ми чекали 7 тижнів відповідь на запит одного з компонентів системи.

Поки чекали відповіді знову, треба було працювати. І ми робили так, як вважали за потрібне, не завжди потрапляючи до бачення міністерства. Бережливе виробництво? Усунення втрат? А не, не чули.

Пізніше доводилося переробляти якісь завдання, і це впливало на якість не кращим чином. Тим більше, що не було ясності, потрібно буде знову доробляти завдання або це все-таки фінальна версія, яку можна фіксувати і віддавати на прод.

Погано було і те, що ми працювали в постійних дедлайни: терміни були «просто вчора», «зовсім вчора» і крайній варіант, коли у нас навіть «завтра було вчора».

Негативні моменти ситуації:

такий стиль роботи серйозно розбалансував команду;
додаткові завдання накочувалися на ті, які ще не зроблені або навіть не розпочато;
техдолг перед замовником за функціональністю постійно зростав.

Через слабо збудованих процесів ми випускали сирий продукт. Основними інструментами поставки були надія і схрещені за посиніння пальці: а раптом цього разу система не ляже і не доведеться виходити в ніч щось лагодити.

Процес практично відсутній зворотний зв'язок діяла в режимі: «Це не так, ви зробили неправильно». За великим рахунком, кожен реліз проходив в очікуванні проклять, які ми отримаємо від замовника після первинного тестування. Успіх релізу вимірювався пропорційно кількості «WTF?»: чим менше, тим краще.

В таких умовах проект функціонував кілька місяців до мене і ще якийсь час разом зі мною, поки ми розбиралися з тим, що відбувається. Команда успішно-неуспішно пиляла потрібний софт, постійно «вигрібаючи» від клієнта. При цьому ми намагалися стежити за якістю функціоналу і намагалися поліпшити результат роботи, нехай навіть з допомогою поганий зворотного зв'язку.

На цьому етапі було складно говорити про питання якості. Було необхідно якось устаканити процес розробки, впровадити передбачувані і повторювані активності, які будуть корисні і команді, і нашому клієнту, щоб він все-таки міг отримувати щось передбачуване у визначені строки.

Як підготувати команду до змін

У той час я познайомився з Scrum-фреймворком, прочитавши одну з найвідоміших на той момент книг про нього — Scrum and XP from the trenches by Henrik Kniberg. Книга обескураживала простотою. Ось вже дійсно «срібна куля»: як Хенрік домігся успішного успіху в короткі терміни з простим інструментом.

Основна думка: є якийсь рамковий фреймворк, який дозволить менеджеру з командою взяти процеси під контроль і залучити замовника (а це для мене було на той момент найголовнішим!) у спільну роботу. Бінго!

Отже, озброївшись знаннями з книги і ще з пари джерел, я пішов до своєї команди і сказав: «Хлопці, з понеділка ми будемо жити за Scrum'у».

І тут я зробив відразу дві помилки, з якими стикаються багато, коли намагаються поліпшити якість процесів в організації/проекту: по-перше, почав революційні, а не еволюційні зміни, «з понеділка», а не з етапу підготовки. По-друге, в команді не була створена атмосфера необхідності змін.

Якщо різко впроваджувати великі нововведення на проекті, з'являється ризик зіткнутися з наступними проблемами:

Опір на рівні людей, яким з цими змінами жити. Людина звикає навіть до незручним умов, вибирає горезвісну зону комфорту і не готовий її міняти. За принципом «гірше не буде», якщо ви зрозуміли, про що я ;)
Вплив різких масштабних змін одразу ж приводить до зниження продуктивності, породжуючи збільшення стресу і недовіри до агентів змін і самої ідеї.

Відповідно і втрати можуть бути дуже серйозними. В цьому плані я згоден з канбан-методом і циклом Демінга—Шухарта — всі зміни потрібно впроваджувати еволюційно: ви робите маленький крок, аналізуєте результат, робите виправлення — і йдете далі.

Скажу відразу, мені знадобилося три спроби, щоб самому розібратися у фреймворку і переконати команду, що перехід на Scrum поліпшить якість процесів і продукту в нашому конкретному випадку. Це важливий момент, так як Scrum «надівається» далеко не на всі проекти.

Після пояснень, спільних міркувань і декількох експериментів, наприклад, впровадження фізичної дошки, команда прийняла новий підхід.

Ключові аспекти роботи з зацікавленими особами

Незважаючи на прийняття командою необхідності змін, замовник не особливо хотів мінятися. Так що довелося адаптуватися до умов: ми рухалися маленькими кроками і намагалися показати клієнту очевидну вигоду впровадження нового фреймворка.

Оскільки на стороні клієнта були гравці різного рівня, ми з командою виробили певні тактичні підходи: кому і що можна продати з Scrum'а.

У той час софт ми постачали «кагбэ on demand» (на вимогу). Вимога зазвичай виглядало так: «Коли, нарешті [кілька нецензурних вигуків], ви нам щось поставите?!».

Коли ми просили зафіксувати вимоги, замовник заперечував: «Ми не можемо зафіксувати вимоги, тому що вони постійно змінюються». Я пропонував: «Давайте так: якщо на своїй стороні зможете зафіксувати вимоги на тиждень або дві, то ми за цей час з високою часткою ймовірності поставимо те, що хочете».

Для замовника це було хорошим аргументом, тому що він теж звітував перед своїм керівництвом і так було легше обіцяти щось міністерству у конкретні терміни.

З кожним ми торгувалися про своє. Департаменту, який займався налаштуванням системи, запропонували: «Ви більше не будете несподівано отримувати від нас збірку і залишатися пізно ввечері на роботі, намагаючись охопити всі ці зміни на продакшн. Тепер будете знати, що кожен другий четвер отримаєте набір нового функціоналу і зможете його ставити на свої продсервера».

Ми продали команді саппорта продакшн-серверів постачання кожні два тижні по четвергах, а за це отримали супровід в тестуванні: вони виступали нашим user acceptance testing. Команда саппорта розгортала наш білд у себе на тестовій середовищі, тестувала і повертала помилки. Великий менеджмент про ці помилки не знав, тому що ми вирішували питання у своєму тісному світі шляхом переговорів.

Перетворіть замовника союзника

Однією з проблем, яку ми хотіли вирішити, було відсутність чітких вимог до продукту:

Представник замовника постачав нам вимоги про роботу системи у формі якихось думок. Ці ідеї про продукт народжувалися у нього зазвичай або напередодні зустрічі, або в ході нашого обговорення.
Специфікації та документація відсутні.
Три відділу замовника, про які я говорив на початку, вкидали нам ідеї та завдання без всякої пріоритизації.

З трьох відділів ми вибрали один, який безпосередньо відповідав за працездатність продукту. Разом з замовником вирішили, що ключовою людина для команди — той, хто контролює 50 контент-менеджерів в обраному відділі. І тільки ця людина може виступати для нас, підрядників, ролі product owner'а і постановника задач.

Тепер до нашого product owner'у стікалися побажання трьох відділів, і він отримав якусь формальну владу над тим, що в продукті буде впроваджуватися. Якщо надходили завдання з інших відділів, ми відправляли «постановників» до product owner'у і тільки в тому випадку, коли він давав добро, брали завдання в роботу.

Що вийшло в результаті

Коли відстояли перед замовником конкретної людини в ролі product owner'а, отримали серйозного союзника. Розуміючи, що потрібно кінцевим користувачам, яких, як я говорив, було більше 300 тис. унікальних, product owner міг тепер ставити пріоритети та вирішувати бізнес-завдання.

Як результат, за три місяці кількість платних користувачів порталу збільшилася на 50%. Побудувавши якісний процес збору вимог і отримання зворотного зв'язку, ми допомогли замовнику не тільки виконувати його обов'язки, але і заробляти самій організації і конкретним співробітникам, тому що фахівці отримували премії.

Відповідно, у нас з'явилося багато вдячних колег на стороні клієнта, тому що замовник зрозумів: якщо формулювати свої очікування і потреби більш чітко, ми будемо їх швидше і краще реалізовувати.

Ми також отримали гарна підмога в тестуванні. Коли product owner побачив, що може впливати на продукт, підключив свою команду тестувати разом з нами. Продукт був непростим, мав складну архітектуру і використовував ЗА стороннього розробника. Потрібно було зістикувати специфікації, як будуть обмінюватися даними компоненти, відстежувати, на чиєму боці можливі дефекти. Звичайно, не обходилося без конфліктів.

У подібній ситуації замовник зазвичай самоусувається: «Ви, хлопці, технарі, самі між собою розберіться», але з появою product owner'а ситуація змінилася.

З'явився один чоловік, який приймав рішення, що необхідно реалізовувати. Product owner акумулював у собі конфлікти, приоритизировал роботу з дефектами, активно фасилитировал нашу спільну роботу. Кількість конфліктів значно зменшилася. Можу навіть сказати, що ми перейшли на партнерсько-приятельські відносини, так як області відповідальності були чітко позначені і ситуації « з нашого боку кулі вилетіли, проблеми на вашій стороні » через 3-4 місяці повністю зникли.

Оптимізація поточних процесів

Налагодити процеси набагато важливіше, ніж відразу вводити технічні практики: парне програмування, код-рев'ю і так далі. Впровадження окремих практик на початку трансформації не приносить користі, а тільки розхитує і так не дуже міцну процесну модель проекту. Тому спочатку ми привели в порядок поточні процеси: впорядкували вимоги, комунікації, і розібралися, хто за що відповідає.

Попрацювали з вимогами

До впровадження нового фреймворку вимоги від замовника надходили до нас від різних людей і в різному форматі. Оскільки не було загального плану розвитку проекту, то не всі ці «хотілки» ув'язувалися з концепцією, яка була в голові керівника.

Тому ми впровадили процес управління вимогами з явно виділеної роллю аналітика — людини, який фіксував запити від product owner'а, вносив їх у Jira і Confluence. Однією з цілей була чітка фіксація всіх запитів замовника і, головне, обліку змін.

Розмежували відповідальність

З крос-функціональністю у нас не вийшло, якщо розуміти під цим, що будь-який учасник команди здатний робити роботу за іншого. Наприклад, якщо аналітик простоює, то чому б йому не протестувати разом з тестувальником.

Враховуючи досить складну структуру продукту, спроби залучити до ряду операцій непрофільних людей були чреваті проблемами для нас і замовника. Ми виділили конкретних фахівців, які відповідали за певний етап: програмували, тестували, писали вимоги, налаштовували серверну частину — і не виконували інші обов'язки. Якщо у працівника не було завдань, він «простоював», але не робив зайву роботу «про запас». Рефакторинг, наведення порядку з документацією, формалізація процесів — завжди було чим зайнятися.

Такий підхід дозволив прописати процеси розробки, тестування, а потім узгодити із замовником, за якими правилами пишемо код за якими сценаріями тестуємо. І це серйозно спростило роботу з командою замовника, яка розміщувала наш софт на продакшн-серверах.

Так як у нас не було доступу до цих серверів, ми чітко описали вимоги до системного ПО, елементи конфігураційного управління, правила роботи з релізами. Цей документ був доступний в будь-який час і нам, і замовнику.

Впровадили Built-in Quality

Термін Built-in Quality (вбудоване якість) означає, що контроль якості продукту відбувається не в самому кінці, а планується для всіх етапів розробки. Мета такого контролю — щоб кожен елемент рішення в кожному инкременте відповідав прийнятим стандартам.

Вбудоване якість — це основа, яку необхідно впроваджувати в ДНК процесу. Ми домовилися з замовником, що не будемо пропускати ні один з кроків, важливих для поставки якісного продукту.

Наприклад, часто виникає ситуація, коли потрібно терміново поставити на продакшн та замовник пропонує: «Давайте пропустимо тестування і зробимо швидше, а пізніше що-небудь придумаємо».

Ми не погоджувалися йти без тестування, навіть при зовнішньому тиску за термінами. Інакше потім могли виникнути серйозні проблеми з кінцевими користувачами.

Інший важливий аспект роботи з якістю — це вироблення ясних зон відповідальності — хто за що відповідає. Для визначення ролей кожного учасника команди в моделі комунікацій використовують RACI-матрицю :

Responsible — відповідальний за якусь задачу.
Accountable — який стверджує, що перевіряє, відповідальний за загальний результат.
Consulted — той, з ким консультуються для виконання.
Informed/interested — людина, якого інформують про те, що завдання виконано.

RACI-матриця дозволяє вибудувати певну ланцюг подій і призначити відповідального для кожного етапу: хто робить якусь роботу, хто поінформований про цю роботу і так далі. Вона допомагає проектній команді виявити області, за які ніхто не відповідає, або є кілька відповідальних, що практично автоматично веде до колективної безвідповідальності.

Якщо «непокриті» етапи не виявити і не призначити керівника, це може серйозно знизити якість проекту .

Перебудова процесів зайняла у нас близько півроку: пара місяців пішла на боротьбу з інертністю мислення команди і замовника, решту часу — на роботу з процесами.

Замість висновку

Перед тим як впроваджувати щось нове, потрібно сформувати у людей потребу в змінах. Якщо ефективність роботи всіх влаштовує і немає почуття проблемності ситуації, то перейти на інші моделі процесів буде нелегко. На цю тему є гарна книжка Джона Коттера «Наш айсберг тане» . Там в жартівливій формі на прикладах пінгвінів описані базові принципи впровадження змін.
Наступний крок — прийняти необхідність змін. Коли люди усвідомили, що зміни потрібні, починайте підготовку. Тут я рекомендую почитати про канбан-методі, наприклад, книгу Kanban from the Inside Майка Барроуза.
Проаналізуйте поточну ситуацію: проблеми та причини їх появи, від кого надходять вимоги, як розподіляються обов'язки в команді.
Вирішіть, що можна оптимізувати: поточні процеси, взаємодію із замовником, відповідальність.
Впроваджуйте зміни невеликими порціями, відстежуйте, як вони відображаються на проекті, і рухайтеся далі до нових стандартів якості.

Опубліковано: 17/07/20 @ 10:00
Розділ Різне

SEO Блог