Продуктове планування

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

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

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

В угоді декларуються продуктові ризики, які ми намагаємось зменшувати при кожній можливості. Ці декларації допомагають нам приймати більш продумані рішення, що економить час. Якщо від самого початку відомо, що продуктових гіпотез буде багато, ми оберемо найшвидші і найекономніші способи перевірки кожної з них. Якщо ми реалізуємо важливу функціональність продукту з використанням 3rd-party, то ми обов'язково продумаємо сценарій відмови від цієї залежності. Інакше користувачі продукту можуть постраждати від тривалої непрацездатності цієї функціональності, якщо 3rd-party припинить вирішувати свою задачу.

Цей комплекс заходів робить результат більш прогнозованим/передбачуваним, продукт більш якісним, а усіх учасників команди – більш впевненими у своїх діях.

Технічне планування

Найбільша технічна складність молодого проєкту – вимоги, що постійно і неминуче змінюються. Це нормальний процес, бо на цьому етапі підприємець тільки починає побудову бізнес-моделі. Зрозуміло, що все без виключень може змінитися. Водночас, для розробників продукту це часто стає скринькою Пандори. Іноді зміна найнепомітнішого, з точки зору бізнесу, аспекту функціональності може призвести до великих проблем в розвитку продукту. Часто в таких випадках правильним рішенням буде не просто переробити функцію, але й привести до узгодженості інші залежні модулі продукту. Правильне технічне і архітектурне планування продукту робить ці проблеми передбачуваними, загрози – керованими, а видатки на розвороти продукту – оптимальними. А ще це робить розробників щасливішими.

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

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

Основою є визначення загальної конструкції системи і базових архітектурних принципів. Коли бачення клієнта цілком зрозуміле і вхідні консистентні, рішення приймаються швидко. Виходячи з можливих сценаріїв розвитку і їх ймовірності ми визначаємо оптимальні стартові обмеження по архітектурі. Стандарти розробки будуть визначені на наступних етапах і ми будемо доповнювати їх в процесі розвитку продукту. А на цьому етапі короткий набір правил побудови продукту буде більш ефективним. Ці правила відповідають на головні питання, що виникають перед технічним лідером команди в процесі робіт. Наприклад, «як забезпечувати працездатність найбільш важливих підсистем?», «як оптимізувати вартість будь-якого майбутнього інкременту?», «коли і з яких причин треба перебудовувати процеси розробки на більш суворі?». Так ми визначаємо основний вектор розвитку продукту і готуємось до змін будь-якого рівня.

Далі ми плануємо стартовий формат робіт в плані технічних цілей і процесів на продукті, а також стратегію зміни цього формату робіт. Разом з тим, пріоритезуємо частини продукту – за важливістю для бізнесу і очікуваною змінюваністю, визначаємо рівень уваги до їх технічної якості. Вирішуємо в якому форматі ми організовуємо критику технічних вимог, code review, як тестуємо продукт, як проводимо релізи, як контролюємо bus factor. Формулюємо технічні обмеження, в які продукт має вписуватися, наприклад, «сторінка в 90% випадків має завантажуватись не більше ніж за 200 мс» або «головне АРІ на production має коректно працювати при RPS 50». Постійна підтримка таких обмежень допомагає гарантувати стабільну роботу продукту і спрощує прийняття локальних рішень.

Далі треба спланувати позиції з питань технологій – це похідна з попередніх аспектів. Як правило, головні технології, за типом основної мови програмування і фреймворку, СУБД і основних 3rd-party визначаються ще в процесі збирання вхідних. Тут ми вирішуємо більше технічні питання, максимізуючи рентабельність і зручність процесу розробки. Це питання CI/CD, 3rd-party другорядної важливості, політика з додавання сторонніх залежностей, системи логування, моніторингу і оповіщень… Вибір нашого клієнта – визначитись у цьому аж до важливих деталей, або знати тільки важливе для його бізнесу.

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

Організація командної роботи

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

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

Ми вважаємо, що після кожного спілкування маємо продукувати артефакти. Що й для чого обговорювали? До чого дійшли? Які наступні кроки? Після комунікації відповіді на всі ці питання мають бути зрозумілими для всіх членів команди і надаватися для відновлення. Інакше решта учасників команди просто не зможуть самостійно узнати відповіді на важливі для них питання. Поза тим, ми надаємо перевагу можливості віднаходити відповіді на питання самостійно, перед витрачанням часу наших колег. Відтак, як правило, ми ведемо спілкування у трьох місцях: Gitlab, Slack та Notion.

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

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

Текстове спілкування з клієнтом ми зазвичай ведемо у Slack. Це обумовлено його кращим на ринку UX й зручною системою оповіщень. Ще у Slack крутий пошук і це полегшує пошук обговорення кожного важливого питання. Так само тут ми проводимо внутрішні операційні перемовини. Переговори ми плануємо за допомогою Google Calendar. Для дзвінків, крім Slack, ми також користуємося Google Meet.

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