Я брав участь у такій кількості агенційних проєктів, що краще не рахувати, з обох боків столу. Закономірності того, які з них вдаються, а які зриваються, майже не залежать від технічної роботи. Код зазвичай нормальний. Що насправді різниться — це форма співпраці навколо коду. І чотири конкретні звички, схоже, щоразу роблять різницю — у будь-якій галузі.
На цих чотирьох звичках ми збудували нашу студію. Жодна з них не вигадлива. Більшість викликають легкий дискомфорт.
Звичка перша: справжня демонстрація в кінці кожного спринту, на справжній URL
Не скриншот. Не відео. Не пробіжка по localhost. Адреса, яку клієнт відкриє з телефона дорогою додому і зламає, клікнувши не туди.
Це найважливіша звичка — і та, якої більшість агенцій непомітно уникає. Бо незручно. Воно ще не готове. Грубе по краях. Половина кнопок нікуди не веде. Не хочеться випускати таке під своїм ім'ям.
Випускайте все одно — на межі спринту, не раніше.
Раніше ми проводили такі демонстрації щоп'ятниці. Потім перестали. Щотижневі демо звучать чудово, доки не поживеш усередині цього циклу: до середи команда вже працює на показ — кодить так, щоб п'ятничне демо виглядало добре, а не так, щоб система будувалася правильно. Робота починає прогинатися під видовище. Ми перейшли на жорсткі двотижневі спринти з демонстрацією в самому кінці — і якість зросла по всіх напрямах. Демонстрація стає природним артефактом спринту, а не окремою річчю, яку команда мусить ліпити поверх роботи.
Демонстрація в кінці спринту досі робить три речі, на які ніщо інше не здатне. Вона ловить розбіжність очікувань за два тижні, а не за квартал — клієнти інколи самі не знають, чого хочуть, поки не побачать це не зовсім таким. Вона виховує звичку завершувати в первісному сенсі цього слова: доводити річ до стану, з яким може взаємодіяти людина. І вона створює недвозначний запис прогресу, який клієнт може показати раді директорів, співзасновникам, інвесторам. Останнє важить більше, ніж зазвичай усвідомлюють агенції.
Ця дисципліна також змушує команду думати про розгортання з першого тижня. Системи, які розгортаються на межі кожного спринту, рідко мають кошмарні дні перемикання. Системи, які розгортаються лише раз у самому кінці проєкту, мають їх завжди.
Звичка друга: записуйте кожне архітектурне рішення
Не у Slack. Slack — для одноденного; архітектурні рішення одноденними не бувають. У markdown-файл усередині репозиторію, з датою, з одним інженером-власником, оформлений як короткий ADR: що ми вирішуємо, чому розглянули інші варіанти, що обираємо і чим готові пожертвувати.
ADR — це документ на один екран. Ми пишемо щонайменше один на тиждень, іноді три. Вони живуть у docs/adr/ поряд із кодом, і файл проходить рев'ю в тому самому pull request, що й реалізація. Майбутні ми вдячні приблизно у вісімдесяти відсотках випадків, а налагоджувальні сесії в дусі "цікаво, чому ми зробили цей дивний вибір" скорочуються вдвічі.
Цінність — у дисципліні. Артефакт — побічний ефект. Якщо ви не можете записати, чому зробили вибір, ви насправді його не розумієте — це програмування архітектури на відчуттях, і за це ви заплатите.
Звичка третя: одноразовий Slack, довговічне все інше
Ми обмінюємося з клієнтами величезним обсягом контексту у Slack. Контекст незамінний. Гілки в Slack — ні. Slack ми за задумом тримаємо як одноразовий.
Якщо інформація потрібна довше за один день — вона має опинитися в чомусь довговічному. Рішення йдуть в ADR. Помилки — в трекер задач. Розгорнутий відгук — у коментар до pull request. Зміни плану — у дорожню карту, з датою і відповідальним.
Це звучить бюрократично. Це економить колосальний час. На третьому місяці проєкту запитання "де ми про це домовилися?" не повинно вирішуватися як "треба годину гортати Slack". Воно має вирішуватися як "подивись в ADR, другий абзац". Різниця у вартості пошуку — це різниця між проєктом, що накопичує цінність, і тим, що її втрачає.
Звичка четверта: один відповідальний інженер на кожну ділянку системи
В агенційних командах є хронічна хвороба — розмита відповідальність. До системи автентифікації прикладалися троє інженерів; не володіє нею жоден. Коли в суботу автентифікація ламається, черговий пише у Slack "хто знає цей код?" — і відповідь звучить як "усі потроху, спитайте Джеймі, ой, Джеймі у відпустці".
Викоріньте це. У кожної значущої ділянки системи — автентифікація, платежі, пошуковий конвеєр, процес розгортання, схема бази — має бути рівно один інженер, чиє ім'я до неї прикріплене. Він не єдиний контриб'ютор. Він — той, хто відповідає на дзвінок чергового о другій ночі, і єдиний, хто може схвалити структурну зміну.
Це не про ізольовані вотчини. Це про відповідальність без двозначності. Коли Джеймі у відпустці і автентифікація ламається, команда знає: написати Джеймі, до понеділка рішень не ухвалювати, ескалювати до архітекта, якщо щось мусить вийти негайно. Ось як виглядає відповідальність на рівні ділянки.
До того ж це виховує помітно сильніших інженерів. Ті, хто володіє ділянками, ростуть швидше за тих, хто перескакує між ними. У кожній команді, з якою я працював, інженери-довічні учні — це ті, у кого була глибока відповідальність "я цим володію". А ті, хто так і не стає сильним, — це ті, хто ніколи нічим не володів.
Що ці чотири мають спільного
Усі вони — форми скорочення люфту — в інженерному сенсі, тобто розриву між наміром і реальністю. Без них цей розрив тихо накопичується по ходу проєкту, доки не стає завеликим, щоб закрити. З ними розрив виходить на поверхню щотижня — і його одразу затискають.
Жодна не про те, щоб бути розумнішим. Усі — про те, щоб бути чеснішим, частіше, у письмовій формі, з людьми, що платять за роботу. Виявляється, саме це і є тривкою конкурентною перевагою будь-якої агенції, що працює в цьому просторі.
Хороша новина для клієнтів, які обирають агенцію: ці чотири звички легко перевірити запитанням. "Як часто ми отримуємо справжню демонстрацію?" "Де живуть архітектурні рішення?" "Хто володіє автентифікацією?" Відповіді скажуть вам усе потрібне за п'ять хвилин.
Хороша новина для агенцій, що думають їх запровадити: ці звички накопичують ефект. Перший проєкт іде важко. П'ятий іде сам.