Майкл Балле нещодавно відвідав нас у Тheodo. Після його прогулянки в Gemba, він прямо сказав нам, що ми неправильно робимо витягування, тому що не розуміємо цілі.

Ми були приголомшені і намагалися пояснити, чому ми думали, що насправді витягуємо. «У нас є спринти, які тривають всього лише 1 тиждень, а наші user stories менше ніж 1 день» - сказав співзасновник компанії Бенуа. Спринт – це період часу, протягом якого ми створюємо функції ПО наших клієнтів, що організовані в user stories. У нашій сфері спринти зазвичай тривають від двох тижнів до 1 місяцю, а user stories від 1 до 5 днів, тому ми думаємо, що у нас все чудово.

«Будь ласка! Якщо на виробництві оператору потрібно більше ніж 10 хвилин, щоб зробити щось, це означає, що він не справляється з роботою» - відповів Майкл. Одразу після цього, Бенуа, наш Lean коуч, Регіс Медіна та я почали думати про те, як ми могли скоротити час на виконання задач нашими розробниками, які тривають більше ніж 10 хвилин.

Розділіть роботу та побачте проблеми

Я вирішив провести експеримент з одним із наших технічних лідерів команди Ніколасом Бутіном. Зараз він очолює команду з двох розробників, що провалили 5 спринтів за останні 10 тижнів.

Я провів з ними 2 години, у той час як він створював user stories. Перед тим, як він почав писати код, я попросив його розписати та визначити кроки (максимум 10 хвилин), які він повинен був зробити для створення user story. Потім він визначив час, який на його думку, потрібен для кожного кроку. Якщо він не знає, як зробити щось, чи він не може виконати крок або йому не вистачатиме часу, я сказав йому, що він може звернутися за допомогою в будь-який час, коли він відчує, що йому потрібна буде допомога, просто, як оператор з заводу Toyota, який потягне за мотузку Андон.

Ніколас працював над формою підписки, для відкриття онлайн полісу страхування життя, де просять клієнта сплатити мінімальну суму грошей, яку він хоче покласти на нього. Ніколас поділив user story на 8 етапів, що в цілому склало 22 хвилини і 10 секунд (замість приблизно 4 годин, як спочатку команда передбачала):

Заповнити онлайн-форми, щоб перейти до 4 кроку та побачити сторінку, де буде видно кінцевий результат – 3 хвилини.

Знайти схожі частини коду, щоб скопіювати та вставити – 30 хвилин.

Знайти куди вставити скопійований код, вставити його та адаптувати до вибірки даних – 10 секунд.

Написати автоматичний тест-кейс – 10 хвилин.

Замінити дані вибірки на реальні, які треба витягнути з бази даних, відповідно до підписаного контракту – 1 хвилина.

Протестити його у браузері – 30 секунд.

Розмістити код на платформі валідації – 2 хвилини.

Тест на платформі валідації – 5 хвилин.

За умови, якщо він не зустрінеться з жодною із проблем, Ніколас зможе випустити story у 10 разів швидше, ніж очікувалось раніше.

Коли він почав кодити, я спостерігав за ним з хронометром у руці та записував все, що він робив. Перша проблема виникла на 2 кроці, Ніколас намагався знайти три рядки коду, у файлі, який містив більше як 300 рядків коду. Вочевидь це було занадто довго, і нам знадобилося 2 хвилини, щоб знайти правильний кусок коду.

Як тільки він вставив цей код у потрібний файл, сторінка поламалася. Дизайн був не таким, як ми очікували, деякі блоки вмісту були зміщені або відсутні. Ми зрозуміли, що він скопіював не всі рядки потрібного йому коду. Дві години потому, Ніколас виконав 6 кроків з 8, які він зазначив. Три кроки було виконано у розрахований час, та ми з'ясували, що два кроки були відсутні в потоці. Він тягнув за Andon 4 рази. Йому знадобилося трохи менше ніж 4 години, щоб завершити user story, як і розраховувала команда (тому тривалий процес не вплинув на план виробництва).

Ми виділили час, щоб проаналізувати проблеми, з якими Ніколас зустрівся на кожному кроці.

До них відносяться: відсутність знань технологій та інструментів, які він використовував, складність, щоб прочитати код та недотримання внутрішніх правил кодування, і той факт, що його IDE (Integrated Development Environment – базовий редактор коду), не було налаштовано.

Наскільки це можливо, ми зверталися до кореня проблеми, щоб розв'язати. Всі проблеми, які ми не могли одразу розв'язати, Ніколас додавав у свій to-do list. У кінці дня він був сповнений енергії та ентузіазму. «Сьогодні день, коли я вивчив більше, ніж за весь період роботи в Theodo» – сказав він мені.

Розв'язати маленькі проблеми, щоб виростити лідерів

Експеримент виявився успішним і тому ми вирішили його поширити серед усієї команди Ніколаса. Результати були чудові: за 8 тижнів поспіль кожний спринт виконувався вчасно. За останні 4 тижні, вони поліпшили свою продуктивність на 40%. Більш того, коли ми змогли розв'язати проблеми, ми змогли відтворити дух Kaizen у команді та виявили, що у нас з'являється все більше можливостей для розвитку лідерських якостей.

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

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

https://planet-lean.com/lean-work-theodo-software-development/