Axon Digital

Система поставки

Документація як механізм поставки

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

Чому документація зазвичай вмирає

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

Один опис — один ланцюг

  1. 01

    Бізнес-процес

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

  2. 02

    Флоу

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

  3. 03

    Дизайн

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

  4. 04

    Код

    Фронтенд і бекенд будуються з того самого флоу, тому не можуть розійтися у двох різних трактуваннях одного правила.

  5. 05

    Виконуваний сценарій

    Той самий флоу в придатній до запуску формі: кроки на кшталт «зроби це — має бути видно те» і правила, які мусять справджуватися завжди.

Дві перевірки, одне джерело

  • Поведінка

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

  • Дизайн

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

Що відбувається, коли перевірка падає

Інженер керує агентом, у якого є звіт про падіння, опис флоу та порушене правило, і той готує виправлення. Рішення про влиття ухвалює людина.

Як виглядає сценарій

Мета
Клієнт додає платну опцію до активної підписки й бачить нову ціну ще до підтвердження.
Чому це важливо
Хибна ціна на підтвердженні руйнує довіру до білінгу та створює навантаження на підтримку.
Кроки
  1. 01Відкрити сторінку підписки — видно поточний тариф і ціну.
  2. 02Додати платну опцію — перерахована ціна з’являється до підтвердження.
  3. 03Підтвердити — нова опція та ціна відображаються в підписці.
Правила, які мусять справджуватися
  • Ціна, показана до підтвердження, дорівнює сумі списання.
  • Ту саму опцію не можна додати двічі.

Інструменти змінюються, механізм — ні

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

Чого машина не вирішує

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

Перевірка, якій немає з чим зіставляти, повідомляє про це, а не видає вердикт. Ця межа закладена в процес, а не залишена на добрі наміри.

Опис процесу показує, де він повторює сам себе, але рішення змінювати процес — ваше, не наше.

Люди й агенти в одному контурі

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

Що це змінює для вас

  • 01

    Регресії виявляються раніше, ніж їх побачать ваші користувачі.

  • 02

    Опис системи залишається актуальним, бо від нього залежить поставка.

  • 03

    Нова людина входить у проєкт через документацію, а не через чиюсь пам’ять.

  • 04

    Виправлення не чекає, поки звільниться розробник.

Хочете такого рівня контролю на своєму проєкті?

Подивимося на вашу систему й визначимо, які флоу описати та перевіряти першими.