01. Вивчаємо роботу зсередини.
Перша розмова стосується ситуації, яку ви хочете змінити. Що затримує виконання? Де виникають повторні виправлення? Якої інформації бракує людині, що ухвалює рішення? Потім разом із працівниками, які ведуть конкретну справу, проходимо весь її шлях. Погляди керівника й безпосереднього виконавця допомагають побачити той самий процес із різних боків.
У великій організації одне замовлення або документ може пройти через кілька відділів. Ми шукаємо місця, де змінюється відповідальний, виникає очікування або втрачається контекст. Саме там часто є найбільші можливості спростити роботу.
- Мета проєкту та поточний спосіб її досягнення.
- Люди, які користуватимуться рішенням та ухвалюватимуть рішення.
- Найпоширеніший маршрут і ситуації, що викликають труднощі.
02. Упорядковуємо правила, дані та обсяг першого етапу.
Просимо надати характерні приклади: форму, документ або звіт без персональних даних і зайвої конфіденційної інформації. Оцінюємо не лише правильний сценарій, а й пропуски, дублікати та виправлення. Визначаємо, хто може змінювати дані й коли потрібне погодження.
Обираємо невеликий, але завершений фрагмент процесу. Він має містити початок, послідовність дій і корисний результат. Такий обсяг дає змогу перевірити рішення в роботі. Також фіксуємо залежності й елементи, які свідомо залишаємо на потім.
- Що запускає справу і як ми визначаємо, що її завершено?
- Хто відповідає за кожну групу даних?
- Як опрацьовуємо виняток або скасування рішення?
Найважливіше на початку
Починаємо з конкретної роботи та розмовляємо з людьми, які її виконують.
Перший етап охоплює завершений процес і найважливіші винятки.
Прототип, критерії тестування та приймання стосуються тих самих завдань користувача.
03. Перевіряємо ідею на прототипі.
Проєктуємо основні екрани та проходимо завдання майбутнього користувача. Чи зрозумілий йому статус? Чи знаходить він документ? Чи знає, чому не може виконати операцію? На цьому етапі перевіряємо формулювання, послідовність дій та інформацію, потрібну для ухвалення рішень.
Прототип допомагає обговорити спосіб роботи. Він не видає себе за готову систему: реальні інтеграції, контроль доступу та збереження даних ще потрібно реалізувати й протестувати. Узгоджені висновки перетворюємо на обсяг робіт, який можна виконати та прийняти.
04. Створюємо рішення разом з усіма потрібними зв’язками.
Поєднуємо інтерфейс із правилами, даними та необхідними системами. Перш ніж планувати повноцінний обмін інформацією, перевіряємо доступність API, документації та середовищ. Визначаємо, який інструмент є джерелом конкретних даних і як інтеграція поводитиметься під час збою або повторного надходження події.
Розвиваємо проєкт узгодженими частинами, які можна показати й перевірити. Нові ідеї фіксуємо та оцінюємо щодо мети. Так важлива зміна свідомо впливає на обсяг робіт, а не непомітно змінює очікування щодо строків і вартості.
05. Тестуємо й те, що може піти не за планом.
Перевіряємо сценарії, визначені під час аналізу: правильний перебіг, відсутні дані, некоректні права доступу та нетипові рішення. В інтеграціях перевіряємо повторні спроби й недоступність джерела. Під час міграції порівнюємо дані, щоб переконатися, що їхній зміст збережено.
Користувачі можуть перевірити важливі завдання у звичному для себе контексті. Застосунок на телефоні потребує іншого підходу, ніж панель для роботи за столом. Критерії приймання пов’язуємо з конкретними результатами та погодженим обсягом.
- Чи може користувач завершити потрібну справу?
- Чи бачить і змінює він лише дозволену інформацію?
- Чи зрозуміле повідомлення про помилку та чи визначений порядок її опрацювання?
06. Запускаємо з урахуванням роботи компанії.
Якщо процес дозволяє, починаємо з пілотного запуску для обраної групи або частини даних. Це дає змогу порівняти роботу з попереднім порядком і скоригувати деталі, перш ніж розширювати доступ. В інших випадках погоджуємо момент переходу та дії на випадок проблем.
Перед прийманням визначаємо відповідальність, спосіб інформування користувачів і порядок опрацювання звернень. Права на код, доступи, документація та правила передавання проєкту визначаються договором і погодженим обсягом. Обговорюємо їх завчасно, щоб компанія знала, що отримає і як зможе розвивати рішення.
07. Оцінюємо результат і плануємо наступні кроки.
Повертаємося до проблеми, з якої починали. Перевіряємо час виконання завдання, тривалість очікування, кількість виправлень або інший заздалегідь обраний показник. Не кожна перевага має виглядати як графік: важливим результатом може бути можливість дізнатися статус без пошуку людини, яка ним володіє.
Підтримку, резервні копії, моніторинг, оновлення та реакцію на звернення визначаємо в межах погодженої співпраці. Нові модулі з’являються на основі спостережень користувачів і пріоритетів компанії. Завдяки цьому розвиток відповідає реальним потребам, а основний процес залишається під контролем.
Із чого почнемо розмову?
- Права, доступи та відповідальність за підтримку узгоджуємо до передавання рішення.
- Оцінюємо результат щодо проблеми й початкового стану, а не кількості доданих функцій.
