Александр Винницкий – последние статьи и новости

Олександр Вінницький, заступник генерального директора держкомпанії Prozorro, в колонці для MC.today розповідає про те, як вони в компанії впроваджували метод управління проектами Scrum, основи якого знали лише в теорії. Друзі, ми в редакції mc.today мріємо публікувати ваші історії. З вами сталося щось дивне і незвичайне на роботі, в поїздці, прямо на вулиці? Розкажіть про це нам, надіславши листа на news@mc.today. Два роки тому компанія Prozorro почала будувати власну ІТ-розробку. Олександр Вінницький. Джерело фото: особистий архів Гнучкі методології нам здавалися досить перспективними, ми багато чули про підхід з управління проектами Scrum, врешті-решт прийняли рішення про його втілення у нас. Але побудова власної команди розробки, ще й за принципами Scrum, основи яких ми знали тільки в теорії, виявилася непростою задачею. Нижче наш досвід про те, як ми впроваджували Scrum, які проблеми мали і як ми їх подолали. Насправді деякі з цих порад можуть виявитись корисними не тільки для тих, хто наважиться впроваджувати Scrum, а і для тих, хто зіштовхується з проблемами комунікації у своїй роботі. Scrum – це підхід до управління проектами з гнучкої розробки програмного забезпечення. Головні ролі: Scrum Master – опікується процесами і допомагає команді досягти результатів; Product Owner – представляє інтереси кінцевих користувачів; DevTeam – команда розробників. Упродовж кожного спринту (2-4 тижні) працівники створюють потенційно готовий до запуску програмний продукт або його частину. Зустрічі в Scrum: Стендап: щоденна коротка зустріч по статусу робіт. Пленнінг: зустріч щодватижні для планування нового спринту. Ретроспектива: «розбір польотів» в кінці кожного спринта, де аналізуються причини, що перешкодили досягненню поставлених цілей, або шляхи покращення ефективності роботи. Рефайнмент: обговорення та оцінка найпріоритетніших задач наступного промiжку часу перед пленінгом; мета – ретельно підготуватися до пленінгу. Проблема 1: навіщо ми витрачаємо на це час? Перша проблема, від якої потерпає багато команд, що починають використовувати Scrum, – це відчуття зайвості кількості зустрічей: всі ці пленінги, ретроспективи, стендапи та інше. Спочатку нас не покидала думка про те, що десяток людей просто вбивають свій час на незрозумілі обговорення замість того, щоб працювати. Це тривало місяць-півтора. Зустрічі тривали по кілька годин, люди починали заглиблюватися в дрібниці, сваритися або взагалі втрачали інтерес до обговорення. Позбавитися від цього деструктиву допомогла проста річ: ми зосередилися на суті кожного ритуалу Scrum, буквально йшли по інструкції і ввели жорстку модерацію, щоби не відволікатися на «ліві» розмови. Виявилося, що як тільки ви починаєте дотримуватися інструкції, обговорення стають короткими та продуктивними. Поясню на прикладі. Перший проект, який ми робили по Scrum’у, був пов’язаний з розробкою електронного кабінету для Держаудитслужби. Це кабінет для аудиторів, які перевіряють закупівлі на наявність порушень. На черговому стендапі (щоденні короткі зустрічі з приводу статусу робіт – прим. ред.) розмова знову зайшла у непотрібні деталі та з’ясування стосунків. Це відразу ж змусило мене як Scrum-майстра, тобто модератора та керуючого усім процесом, втрутитися та перервати обговорення, сказавши, що я почув про проблему і пропоную з нею розібратися на окремій зустрічі, а зараз не витрачаємо час команди та йдемо далі. Проблема 2: чому Scrum не вирішує всіх проблем? В якийсь момент у нас виникло саме таке питання. Нібито комунікація в команді налагоджується, зустрічі стають більш ефективними, але сказати, що ми кожні два тижні видаємо результат, як планували – не можна. Що ми робимо не так? Ми неодноразово обговорювали це питання на ретроспективах, «розборі польотів» в кінці кожного промiжка часу, де аналізували причини, що не перешкодили досягненню поставлених цілей. І сьогодні я можу впевнено сказати, що це найбільш корисні зустрічі в Scrum. Саме в результаті таких рефлексій народжувались ідеї, що втілювалися у нові інструменти або підходи. Наприклад, якось у нас «випав» промiжок часу, тому що один з розробників пішов у відпустку, про яку ніхто не знав на планінгу, і вся наша робота встала. Тоді ми почали вести календар відпусток, щоб заздалегідь бачити, хто буде відсутній і який час. Інший приклад: виявилося, що в нас виникало достатньо багато дрібних недоліків через низьку якість тестування. На ретроспективі з’ясувалося, що тестувальники просто не використовували певні інструменти тестування, якими користувались розробники. Ми швидко організували навчання, записали його на відео і внесли до нашої внутрішньої бази знань. До речі, база знань – це теж результат однієї з ретроспектив. Проблема 3: чи можна планувати процес без виснажливих зустрічей? Спочатку наші стендапи тривали майже годину. Враховуючи, що вони відбуваються кожного дня, це забирало в нас купу часу. Як тільки ми почали йти суворо за Scrum Guide і не відволікатися на зайве, вони скоротилися до 3-5 хвилин. А ось пленнінги (планування нового спринту раз на два тижні) забирали іноді 4-5 годин. Ми виходили з них «варені». Розробка програмного забезпечення – це взагалі непросто, а без ретельного підходу до планування робіт команда губиться у потоці операційних задач. Прорив відбувся, коли ми почали виносити опрацювання задач на окрему зустріч. Тобто ми виділили таку зустріч як рефайнмент (від англ. refinement – «очистка»), де обговорювали варіанти рішень для пріоритетних задач. Це дало змогу приходити на пленінг з підготовленою «домашньою роботою» і зосереджуватися лише на плануванні робіт на наступні 2 тижні. В результаті пленнінг ставав набагато коротшим, бо на ньому ми вже обговорювали те, що справді важливо, а не витрачали час на формування рішення. Поясню на прикладі. Припустимо, користувачі системи захотіли, щоби на порталі Prozorro можно було шукати тендери за параметром «використання нецінових критеріїв». Завдання команди – зрозуміти, як вона буде розробляти цей функціонал, скільки на це піде часу та які очікуються трудовитрати. Це все вимагає досить тривалого обговорення. Відповідно, щоб не робити це на зустрічі з планування, де формується майбутній спринт, ці речі обговорюється заздалегідь – на рефайнменті. Такий підхід значно прискорює зустріч з планування спринта, де часто може бути задіяний ТОП-менеджмент. Проблема 4: що робити з тими, хто не хоче змін? Всі розуміли, що треба людей запалити новою ідеєю. Навіть проведене дуже якісно навчання для всієї команди розробки продемонструвало, що ідея «заходить» далеко не всім. У Scrum команда має приймати багато рішень, тоді як за керівником лишається не так багато – усунення перешкод. Людям важко, коли їм доводиться брати на себе відповідальність за свою роботу, роботу інших, взагалі за те, що команда буде робити упродовж наступних тижнів. Що робити в такому випадку? Багато говорити з людьми, показувати їм переваги нових підходів, шукати разом з ними вигоди та сенси. Робота в Scrum-команді дає змогу не обмежувати себе лише тими стандартними завданнями, що притаманні певній функції, а ще й досить глибоко зануритися в завдання колег, що розширює знання і підвищує вартість на ринку праці. Наприклад, зазвичай відділ тестувальників отримує розробку, тестує її і віддає далі, на впровадження. В Scrum-команді все трохи інакше: тестувальник працює разом з розробником в одному кабінеті, і вони можуть обмінюватись досвідом використання різних інструментів. Так з часом тестувальник може навчитись писати прості скрипти, що дає змогу автоматизовувати тестування. В такому випадку простий QA (тестувальник) стає вже в рази дорожчим спеціалістом. Коли я пояснював це колегам, хтось включався і починав отримувати кайф від роботи, але були й ті, кому «не заходило». Доводилося розлучатися. Проблема 5: як перестати бути керівником і стати помічником? Зазвичай відповідальність за всі процеси та результат лежить на плечах керівника. В рамках Scrum лідерство на боці співробітника. Керівник лише задає напрям руху, а реалізацію бере на себе команда. Що ще робить керівник? Створює прийнятні умови для роботи команди та прибирає будь-які перешкоди на її шляху, вирішує проблеми. Якщо керівник звик до класичного підходу у керівництві, коли він приймає всі рішення, роздає усім завдання і потім контролює людей, то віддати ці функції команді буде складно. Що з цим робити? Зізнатися собі, що ти не можеш бути всюди одночасно, знати, як краще і як ефективніше. І довіритись людям, які безпосередньо працюють в процесі. Тут як зі змінами: або вдається прийняти їх, або краще і не чіпати той Scrum. Отже, що ми отримали від впровадження підходу Scrum? скорочення Time-to-market (час випуску на ринок) вдвічі; повний контроль поточних робіт та завантаження працівників; покращення точності визначення строків реалізації та обсягу робіт; раннє виявлення проблем і, відповідно, швидше їх вирішення; поліпшення комунікації в команді; iнструмент неперервного вдосконалення наших підходів та технічних засобів.