Lean-уроки невеликої IT-компанії

Лілль — велике місто на півночі Франції,  у ХІХ та на початку ХХ століття процвітало завдяки текстильній промисловості, яка була основою його економічного розвитку. Сьогодні дві колишні фабрики перетворилися на технологічний хаб міста, і зовсім поруч розташована невелика ІТ-компанія “No parking”.  

Мене зустрічає керівник компанії Перрік Пене. Долучаючись до його невеликої команди з восьми людей, я насамперед запитую про походження назви компанії.
«No Parking, — пояснює він, — це інформація в русі, яка ніколи не застоюється. 

Компанія створила інструмент управління часом Opentime ще 20 років тому. Спочатку це було внутрішнє рішення для власних потреб IT-компанії. Згодом, на прохання бухгалтера, інструмент адаптували для одного з клієнтів — і саме з цього моменту Opentime вийшов на ринок. Сьогодні ним користуються понад 200 компаній та організацій.  

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

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

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

Як і будь-яке якісне програмне забезпечення, Opentime оновлюється кілька разів на день з урахуванням виправлень або нових функцій, запропонованих користувачами. Перрік, не бажаючи надокучати клієнтам масовими анкетами Net Promoter Score, просить команду фокусуватися лише на нових користувачах після того, як вони ознайомилися з продуктом, та на тих, хто просить додаткові функції, щоб зрозуміти, що ще потребує вдосконалення. Для кожної такої взаємодії він показує, як застосувати цикл PDCA, щоб вирішити проблему так, щоб клієнт залишився повністю задоволений. 

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

Проте оптимізація існуючого продукту — лише частина ролі головного інженера. Дослідження нових потенційних клієнтів і бізнес-можливостей, аналіз дій конкурентів та відгуки від lean-компаній регіону (Перрік очолює місцеву Lean-спільноту) надихають його на створення нових функцій. 

Минулого року була запущена нова програма Fissa, що значною мірою базується на Opentime. Вона дозволяє збирати дані про робочий час та відвідуваність за допомогою електронного годинника або веб/мобільного інтерфейсу, інтегрованого з системою управління персоналом. Нещодавно команда також розробила модуль Skillofi, який дозволить керувати матрицями навичок співробітників. 

Перрік також показує мені модуль Kanban, який наразі використовують лише він і його команда. Ідея полягає в тому, щоб надати можливість керування завданнями (цей тип програмного забезпечення широко застосовується в IT), але з додаванням підходу Kanban, прозорості часу виконання та можливості вирівнювання навантаження (Heijunka). 

Усі завдання, які потрібно виконати, розбиваються на Kanban-картки, незалежно від того, чи йдеться про тестування перед виробництвом, профілактичне обслуговування, поновлення сертифікатів чи запити користувачів. Передбачувані завдання плануються заздалегідь і вирівнюються, а непередбачувані (запити користувачів або завдання, виявлені під час гемба-кайдзен) інтегруються у потік.  

Кожній Kanban-картці призначається дата початку, і в ідеалі її слід виконати протягом восьми годин. Перрік і команда обмежують максимум до чотирьох Kanban-карток на людину на день, враховуючи час очікування між двома діями на одній картці. Ці правила дозволяють планувальнику рівномірно розподілити навантаження по всій команді та у часі (Heijunka). Інструмент надає перегляди навантаження для кожного учасника та загальний огляд команди. 

Звісно, якщо обіцянку не вдається виконати, спрацьовує Andon (сигнал або систему оповіщення про проблему у виробничому процесі чи роботі команди).  Для Перріка це можливість побачити, як швидко можна застосувати контрзаходи — наприклад, звільнити час, щоб поглинути затримку, відтермінувавши менш термінові завдання або надавши допомогу. Це дуже візуальний спосіб балансування навантаження та потужностей команди. 

Цінність для клієнтів може виникнути лише через розвиток  команди. Перрік щотижня проводить кілька gemba-сесій, щоб глибше зануритися у незнайомі або недостатньо опановані сфери — будь то код, SQL-запити, дизайн, SEO чи маркетинг. Ідея полягає в тому, щоб протягом року поступово опрацьовувати складну технічну тему та відкривати нові напрями роботи з визначеним лідером по кожному напрямку, переглядати результати кожні три тижні та робити послідовні цикли PDCA. 

Перша gemba-сесія, в якій я беру участь, присвячена маркетингу.
«Ми продовжуємо розвивати та вдосконалювати продукт, але у нас справжня проблема з тим, щоб нас помітили або знайшли», — пояснює Перрік. У Хлоє (голова відділу маркетингу)  є два паралельні kaizen-напрями з цього питання: по-перше, розвиток партнерств для підвищення видимості Opentime; по-друге, оптимізація SEO сайту, щоб користувачі могли легше знаходити їх в інтернеті без додаткових витрат на видимість. 

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

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

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

Потім вони відкривають нову лінію щодо технічної документації, бо Хлоє нічого про неї не знає і потребує допомоги. Контрзаходи передбачають співпрацю з одним із Project Manager компанії No Parking, щоб надати потрібну технічну інформацію та підтвердити інтеграцію інтерфейсу. 

Хлоє та Перрік домовляються одночасно тримати відкритими не більше чотирьох PDCA. 

Але тут стає ще цікавіше. Хлоє могла б просто делегувати завдання, створивши Kanban у Opentime, і чекати, поки один із технічних Project Manager команди розв’яже його — відома тактика, яку часто застосовує наш мозок: ми намагаємося економити енергію і схильні забувати про проблему, як тільки хтось інший бере на себе відповідальність за її виконання. 

У No Parking, надихаючись практиками парного програмування та взаємних рецензій, віддають перевагу роботі в парах: Technical Project Manager ділиться технічними знаннями, а Хлоє — досвідом у питаннях маркетплейсів. Разом вони працюють над завданням і одночасно навчаються. 

Хлоє доводиться узгоджувати час і доступність Project Manager (у якого також є власні завдання з кодування чи kaizen) та оцінювати складність або час, потрібний для виконання її запиту. Це також можливість, якщо потрібно, підготувати завдання краще наступного разу. 

Я регулярно бачу, як Перрік повертається до первісної мети (чого ми прагнемо досягти) і запитує Хлоє про її власне бачення «наступного кроку». Це справжня крива навчання: команда створила спеціальні токени (конкретні URL), щоб відстежувати, хто заходить на їхній сайт Opentime і звідки, і перевіряти, чи працюють партнерства. 

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

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

1. досліджувати (стежити за ринком, зустрічатися з партнерами, клієнтами та потенційними замовниками, аналізувати конкурентів, слухати Lean-фідбек тощо), 
2. залучати нових клієнтів, 
3. виставляти рахунки, 
4. обговорювати kaizen хоча б з двома членами команди — будь то код, дизайн, клієнти чи маркетинг. 

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

Ми продовжуємо Gemba разом із Перріком. Леа, яка відповідає за дизайн, працює над Cascading Style Sheets (CSS). У своєму останньому kaizen вона вже виявила та виправила кілька проблем у дизайні програмного забезпечення та сайту, включно з дефектами та невідповідностями, деякі з яких виникли через різні версії софту. 

Після обговорення Леа, яка має чітке уявлення про цільову архітектуру, визначає наступний крок — спроєктувати поточну CSS-архітектуру. Зокрема, вона хоче створити матрицю між CSS-файлами та версіями програмного забезпечення, щоб бачити, який файл використовується в якій версії. Саме з такого точного спостереження за поточним станом вона зможе зрозуміти, як рухатися до бажаної цільової архітектури. 

За кілька столів від нас Джефф, Technical Project Manager, працює над покращенням продуктивності програмного забезпечення. Інструменти для управління часом містять величезну кількість даних про кожного співробітника щомісяця, а HR-відділи часто потребують історичних витягів, іноді за дуже тривалий період, і ці експорти забирають багато ресурсів. 

Лорі, теж Technical Project Manager, займається мобільним додатком програмного забезпечення, продуктивність якого до цього часу не відстежувалася. Тепер спеціальні датчики надсилають сповіщення, якщо додаток починає гальмувати. Лорі отримала перший урок із цього kaizen: вона виявила небезпечні копіювання коду. Замість того, щоб виправляти кожен випадок окремо, їй потрібно перепроєктувати загальну архітектуру, щоб уникнути дублювання, а потім оновити центральний модуль.

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

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

Виклики, які Перрік ставить перед командою, мають великий сенс з бізнесової точки зору, і результати це підтверджують: всі великі клієнти продовжили контракти до 2026 року (Перрік прагне відтворити концепцію Toyota щодо довічних клієнтів: деякі з них працюють з компанією з 2006 року), а маркетингові зусилля потроїли кількість нових лідів при тому ж бюджеті (і без онлайн-реклами!). 

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

Джерело статті: https://www.planet-lean.com/articles/no-parking-lean-lessons-in-a-small-software-firm