Як викувати процес самому. Досвід компанії 2ГІС

Михайло Вязанкин

Михайло Вязанкин ( mihey911
Я розповім вам історію про одну перевантажену команду.

У нас була команда, не дуже велика, 20 осіб висококваліфікованих фахівців — розробників, тестувальників, DevOps. У цій перевантаженою команди була дюжина замовників, в основному, внутрішніх. Ця дюжина замовників постійно билася за пріоритети. Для команди це великий стрес, напруженість, команді не зрозуміло, що буде далі — кожен день може якась нова бізнес-завдання прилетіти. В таких умовах Scrum, який два роки у них працював і до якого вони звикли, почав ламатися, commitment (те, що вони обіцяли зробити на спринт) вони зробити не могли, тому що вдавався хтось дуже важливий і хотів щось дуже цінне. А цінне — це гроші, їх треба робити.

І команда від цього втомилася, і готова була змінюватися. Це важлива умова.

Спочатку я мав намір дати вам набір рекомендацій і рецептів по організації процесу, однак простіше рецепти пояснювати на прикладі, тому буде історія з невеликими отвлечениями про те, що і чому ми робимо, і як вам це можна робити у себе.

Про себе. Програмувати я розпочав у 11 років. У професійному IT працюю вже більше шести років, з яких три роки я — менеджер. Працював у кількох компаніях, керував проектами від маленьких до великих, найбільші   близько 40 чоловік в команді. Останні роки захоплююся Agile-методологіями, активно цікавлюся тим, як це все можна оживити, що можна з цього зробити, різними дослідженнями, експериментами.

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

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



Перше — нам потрібно було не втратити мотивацію, тому що важко, напружено, люди починали втомлюватись. Треба було їм зробити просто, легко, щоб їм було працювати в кайф. Природно, звідси випливає, що нам потрібні були зрозумілі пріоритети.

Зрозумілі пріоритети — це найболючіша частина. Як виявилося, мало, хто знає, як зробити пріоритети зрозумілими.

З цього наступна мета — нам потрібна передбачуваність.

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

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



Так, ми могли пофіксити той Scrum, який був. Приміром, commitment хлопці не дотримувалися — з-за пріоритетів не робили те, що обіцяли. Ми могли взяти і почати навчати їх цей commitment дотримуватися — витратити купу сил і нервів, зовнішні умови не змінилися б, а хлопці б пихкали і страждали… Ми все робили б по Scrum, але невідомо, що з цього вийшло б.

Ми могли зібрати з цеглинок щось нове, тобто викинути Scrum і сказати: «Хлопці, давайте свій процес з голови придумаємо». Тоді захоплювалися такою цікавою штукою, як Essence від інституту SEMAT. Ми його використовували не так, як цей інститут хотів його використовувати, а більше зверталися до нього як до довідника, який зібрав у собі всі елементи IT-процесів і описував їх плюси, мінуси, і сполучуваність. Подивилися, не сподобалося.

Був у нас варіант оголосити kanban. Декларативно. Менеджер прийшов і сказав: «Завтра у нас kanban». Ми зважили плюси і мінуси такого варіанту, здалося, що в такому випадку команда не досягне самостійності практично ніколи.

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

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



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

У нас була установка, що команда хоче як краще. Більшість команд хоче як краще, і хоче зробити так, щоб у них робота була класна, щоб вона приносила результат. Не дуже багато професіоналів просто приходить, зарплату отримує і йде. І ми вирішили допомогти команді зробити як краще. Це теж допомагало нам не боятися, тому що ми знали, що ми не одні такі, не одні розуміємо проблему й не одні будемо її вирішувати, тобто команда нам буде допомагати.

Також ми прийшли до розуміння, що нам потрібно йти маленькими кроками. Є таке чудове поняття — кайдзен (kaizen), воно дещо перегукується з kanban'ом — коли ви дуже-дуже повільно, точковими мазками весь свій процес рухаєте кудись в «добре». Кайдзен дозволяє отримати класний бонус, коли можна відкотити застосовані зміни, тобто щось поміняли — мазочек зробили, зрозуміли, що стало погано, швиденько прибрали, як, начебто, нічого і не було.

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

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



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

Ми склали таку Roadmap:



У нас був зламаний Scrum, ми з нього взяли і викинули спринти, сказали: «Все, ми, типу, зараз по kanban працюємо».

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

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

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

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

Власне, як це все відбувалося, як команда через все це йшла?

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



Ретроспективи ми проводили, не як зазвичай прийнято — раз у 2-4 тижні. Коли у нас виникала якась проблема, ми збиралися на ретроспективі, обговорювали цю проблему, і менеджери накидали ідеї, як можна вирішити проблему. Команда або брала ідею, або спростовувала, або пропонувала контридею, але на порядок краще, тому що вона знала якісь свої механіки. Тому ретроспективи — це найефективніший інструмент і, мабуть, це найкраща точка впливу на такі команди, які ви хочете потім в Agile кудись. Ретроспективи — це прям золото.

Я постараюся не зациклюватися на якійсь kanban атрибутиці, на якихось речах, які властиві для Agile. Це було не важливо. Ми, наприклад, спробували таку штуку, як фізична дошка — вивішувати стікери на дошці по колоночкам. Але у нас була дуже ЦЕ шна команда, яка не любила фізичні дошки, і закінчилося тим, що team lead кожен день в гордій самоті переважував ці стікери, а потім десь там у таск-трекері повторював. Ми двічі спробували це, на другий раз у нас просто вся дошка обсипалася під кінець, тому що всі забили. Не треба, так не треба. Ми це все замінили класної автоматизованої дошкою, виводили її на великий екран — ефект той же, але фізична дошка виявилася нам взагалі не потрібна.

Ще один цікавий момент. Як я вже говорив, ми йшли дрібними кроками, і в процесі вони виглядали, наприклад, як «створити в Jira кнопочку». Просто створюєш кнопочку. Здавалося б, з точки зору великого процесу, з точки зору бізнесу, створити кнопочку — якась фігня. Але вона нам заощадила купу нервів тестувальників. Розробники перестали недовірливо ставитися до kanban'у. Завдяки цій штуці всі зрозуміли, що таке потік, і від цієї «нещасної» кнопочки ми отримали стільки бонусів, що зусилля по створенню кнопочки несумірні з отриманими бонусами. Тому, коли вам пропонують маленька зміна, не варто відмовлятися, варто спробувати. Її потім легко можна відкотити, якщо це не сподобається.

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

Наступна зміна у нас було приблизно через три-чотири місяці — ми почали вводити ліміти. Ліміти — це фізична фактичне обмеження на якийсь виконується тип робіт. Наприклад, у вас розробників двоє, вони навряд чи зможуть фізично одночасно делать12 завдань. А ми, як люди розумні, говоримо: «Нехай вони по дві задачі роблять». І ось у нас якийсь ліміт сам собою вимальовується — чотири завдання. Оптимально, коли розробник час не витрачає, не перемикається між завданнями, коли над однією працює. І kanban говорить нам про те, що бажано ці ліміти наближати до одиниці. Оптимально — за кількістю людей, які роботою займаються.

Другий важливий ліміт, який ми ввели, — це кількість завдань, що виконуються зараз командою в цілому. Ми сильно урізали вхідний потік. У нас була величезна кількість замовників, і ми з цими замовниками домовилися таким чином: ми всім замовникам розповіли про завдання, які нам ставлять інші замовники, тобто всі замовники знали, що у нас зараз дуже багато завдань. І якщо їм потрібно було щось пріоритетне, вони могли піти і домовитися з «сусідами», попутно з'ясувавши, яка з задач зараз для бізнесу важливіше. Це принесло багато болю і страждань, як замовникам, так і PM, але зате це дозволило нам зосередитися на важливих завданнях і не перевантажувати команду. Завдання ми стали виконувати набагато швидше.

Ще раз про ретроспективи. Все те, що я розповів, як це було, все було введено через ретроспективи, ми все це обговорювали з командою на ретроспективах. Фактично єдиний інструмент, який можна команді безболісно впроваджувати, через який команді можна якусь ідею насаджувати. Все інше, якщо вони не готові зараз вас слухати, вони просто пропустять повз вуха, ви вийдете просто з кімнати, а вони забудуть. В одне вухо влетіло — в інше вилетіло.

У підсумку, що у цієї команди вийшло, якого успіху вони досягли?



Ми отримали той самий пул завдань, коли всі замовники знають про все — він відкритий і зрозумілий. Бійка за пріоритети припинилася сама собою за кілька місяців, пріоритети стали зрозумілі, передбачувані, і ми змогли дуже швидко бізнес-завдання вирішувати. Наскільки швидко? Наприклад, завдання — рекламної компанії потрібно дуже швидко зробити промостраницу. Ми її виконання з двох тижнів до двох робочих днів скоротили.

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

Наприклад, у них зараз є прикольна посаду, називається «наглядачем». Це людина, яка кілька днів відповідає за всю вхідну на команду пошту і розкидає задачки. Посада виборна і перехідна. Зазвичай розробники на пошту, взагалі, не люблять відповідати, вона їх дратує, але коли вони розуміють, що через кілька днів вони це віддадуть комусь, так жити стає легше. Пошту вони стали регулярно розбирати, швиденько на неї відповідати, всім стало нормально. І, як бонус, ми в цій команді отримали таку класну штуку як continuous delivery. Це коли ми вранці зробили завдання, а ввечері вона вже «в бою». Через автоматику прогнали, і в залежності від важкості завдання, за кілька годин, а, може бути, навіть хвилин, вона може потрапити на всі сервери. Такий у нас досвід вийшов.

Як цей досвід можна спроектувати на себе, якщо ви з командами працюєте, не важно, з якими, і ви хочете щось застосовувати, навчити чогось команду?



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

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

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

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

Контакти
» mihey911
» twitter
» Блог компанії 2ГІС

Ця доповідь — розшифровка одного з кращих виступів на конференції з управління та підприємництва WhaleRider.

На сайті конференції ви можете підписатися на список розсилки, де опубліковані розшифровки кращих доповідей з декількох останній Whale Rider. Через цей же список можна стежити за підготовкою до нової конференції.

Ну і головна новина — ми почали підготовку весняного фестивалю "Російські інтернет-технології", в який входить вісім конференцій, включаючи WhaleRider.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.