«Це ж маленька кнопочка. Чому три дні?» Я чув цю фразу стільки разів, що міг би зібрати з неї окремий музей. Замовник бачить на екрані кнопку завбільшки з ніготь і щиро не розуміє, як на неї можна витратити більше за годину. А за кнопкою насправді стоїть нова таблиця в базі даних, перевірка прав доступу, перерахунок трьох звітів, сповіщення бухгалтерії, обробка ситуації, коли двоє людей натиснули її одночасно, і тести, щоб за місяць усе це не зламалося після чергової правки. Кнопка це верхівка айсберга. Під водою девʼять десятих роботи, яких замовник не бачить і, чесно кажучи, не зобовʼязаний бачити.
Але ось що я зрозумів за роки практики: замовники, які хоч трохи розуміють, що під водою, отримують систему швидше, дешевше й краще. Не тому, що розробники їх більше люблять, а тому, що такі замовники ухвалюють інші рішення.
Айсберг під кожною кнопкою
Програмування підступне тим, що складність у ньому не видно ззовні. Коли будують будинок, будь-яка людина розуміє, що другий поверх дорожчий за фарбування стін, а перенесення несучої стіни після зведення даху це катастрофа. У софті все виглядає однаково: екран, кнопки, поля. І прохання «додайте поле у форму» зовні нічим не відрізняється від прохання «нехай система сама рахує знижку за історією замовлень клієнта», хоча перше коштує годину, а друге може коштувати тиждень і зачепити пів системи.
Звідси народжується більша частина конфліктів між замовником і виконавцем. Замовник думає, що його обманюють, роздуваючи строки. Виконавець думає, що замовник не поважає його праці. Обидва витрачають енергію на недовіру замість роботи. А проєкт тим часом стоїть.
Що змінюється, коли замовник розуміє
Розповім про типову розмову. Клієнт просить зробити так, щоб звіт оновлювався миттєво, у реальному часі. Ми пояснюємо: звіт збирає дані з десяти тисяч замовлень, миттєве оновлення потребуватиме переробити спосіб зберігання даних, це два тижні. Клієнт, який не хоче розбиратися, каже: «Мене не хвилює як, мені треба миттєво». І отримує два тижні роботи й рахунок. Клієнт, який хоче зрозуміти, питає: «А навіщо мені миттєво? Я дивлюся цей звіт раз на день зранку». І зрештою звіт оновлюється щогодини, це займає пів дня, і всі задоволені.
Розуміння не означає, що замовник має стати програмістом. Воно означає, що він може поставити правильне питання: що тут дорого і чому? Чи є дешева альтернатива, яка розвʼязує девʼяносто відсотків задачі? Що зламається, якщо ми зробимо це зараз швидко, а не правильно? Ці три питання заощаджують більше грошей, ніж будь-які переговори про ставку.
- Конфліктів менше, бо строки перестають здаватися довільними.
- Зʼявляються дешеві альтернативи, які виконавець часто соромиться пропонувати, якщо відчуває, що замовник чекає лише «так».
- Стосунки стають довгими, а довгі стосунки з командою, яка знає Вашу систему, це величезна економія на кожній наступній задачі.
Є й менш очевидна вигода. Виконавець, якого розуміють, перестає закладати в оцінку «податок на недовіру». Коли команда знає, що кожну зайву годину доведеться доводити з боєм, вона страхується: оцінює із запасом, уникає ризикованих, але вигідних для замовника рішень, робить суворо за буквою ТЗ, навіть коли бачить, що буква веде в стіну. Довіра цей податок скасовує, і гроші починають іти на роботу, а не на самозахист.
Емпатія працює в обидва боки
Задля справедливості, це не лише задача замовника. Добрий виконавець зобовʼязаний пояснювати. Якщо розробник на питання «чому три дні» відповідає «бо так», це не професіоналізм, а зверхність. Я вимагаю від наших архітекторів і менеджерів уміння пояснити складність простими словами, через аналогії зі світу замовника. Власникові ресторану можна пояснити так: «Додати страву в меню легко. А додати страву, яку готують із продуктів трьох різних постачальників із різними строками доставки й обліковують на складі за грамами, це вже зміна роботи кухні». Він одразу розуміє.
Розуміння проблем одне одного це як два альпіністи в одній звʼязці. Якщо кожен тягне у свій бік і не знає, де в іншого опора, обидва зірвуться. Якщо вони бачать, на чому стоїть напарник, вони піднімаються швидше й безпечніше, ніж поодинці.
Найдорожча фраза в проєкті: «Мене не хвилює, як Ви це зробите».
Як це застосувати
Якщо Ви замовник, спробуйте на наступній зустрічі з командою розробки зробити одну просту річ: на будь-яку оцінку, яка здається Вам завищеною, замість «чому так довго» запитайте «з чого це складається і що тут найдорожче». Ви здивуєтеся, як часто відповідь на друге питання закінчується фразою «а взагалі, якщо Вам не критично ось це, можна зробити втричі швидше». Якщо виконавець не може відповісти, це теж цінна інформація про нього.
Ми в Ingello намагаємося робити складність видимою від самого початку: у наших проєктах є прототип, де замовник бачить екрани, і архітектурний опис, де видно, що стоїть за кожним екраном. У проєктах на Fractal це особливо наочно, бо систему описано декларативно, і замовник може буквально побачити, скільки сутностей і звʼязків зачіпає його «маленька кнопочка». Розуміння заощаджує гроші й час, а ще нерви, які, як відомо, не відновлюються. Взаєморозуміння Вам, колеги.
