Топ-10 технічних помилок РМ і ВА у спілкуванні з замовником

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

• обсяг, прийняття та термін виконаних робіт;
• особливості інтеграції зі сторонніми системами;
• комунікація в архітектурних питаннях;
• оцінювання;
• загальна комунікація.

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

Обсяг, прийняття та термін виконаних робіт

Case 1. Рефакторинг чинної функціональності

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

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

У процесі роботи компанія-розробник зіткнулася з такими проблемами:

• зірвані строки доставки;
• додаткові вимоги в ході приймання;
• невідповідності під час приймання робіт.

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

1. Грамотно організуйте етап дослідження. Обов’язково за участі клієнта та з формуванням чітких критеріїв приймання (acceptance criteria). Тобто всі загальні тези в плані розробника мають бути замінені на чіткі задачі. На глибокий бізнес-аналіз, комунікації з клієнтом та попереднім QA-спеціалістом необхідно мінімум два тижні – не намагайтеся встигнути все за два-три дні.
2. Розбийте проєкт на підрозділи (sub-scopes). Коли ви починаєте працювати над новою задачею, дуже складно правильно оцінити весь обсяг робіт, які мають бути виконані. Особливо це актуально для проєктів, за якими надходить неповна інформація. Розбиття на підрозділи дозволить контролювати кожний етап проєкту, а саме витрачені на них кошти й час.
3. Збільште маржинальність у випадку фіксованої ціни. Якщо фінансову частину проєкту затверджено заздалегідь, обговоріть із представниками топменеджменту ризик не вкластися в поточний бюджет. 
4. Перегляньте попередні контракти й обсяг робіт. Це розв’язання проблеми виникнення додаткових вимог. Щоб зрозуміти, що вже було зроблено за проєктом, підніміть всю наявну документацію і використовуйте отриману інформацію для подальшого планування роботи. Ця порада буде доречною вже на етапі дослідження.
5. Забезпечте приймання робіт на основі чітких acceptance criteria. Це допоможе уникнути проблем, що можуть виникнути при прийманні робіт, і цим зекономити ваші кошти й час. 

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

• Брати точкову участь у дослідницькій фазі. Він має розуміти, над якими важливими функціями продукту доведеться працювати, і як формуються критерії приймання.
• Надіслати замовнику листа з обсягом робіт, домовленостями по їх прийманню та чіткими acceptance criteria. Також у листі має бути прописана інформація щодо регулярності приймання робіт (наприклад, після кожного спринту). В ідеалі всі деталі потрібно вказати в контракті.
• Надавати клієнту всю необхідну інформацію за проєктом: презентацію, посилання на продакшн, кількість витраченого часу, а також додаток із вказаним обсягом робіт і критеріями приймання. Всі коментарі мають надсилатися у цій гілці, а не окремими листами.
• Бути присутнім на демо та місячному перегляді результатів (monthly steering). Тут можуть підніматися питання щодо можливих проблем. Наприклад, якщо клієнт не виконує процес валідації критеріїв приймання, у команди розробників може виникнути затримка.

Case 2. Перевірка концепції (PoC) 

Перевірка концепції має певну специфіку, що призводить до труднощів у роботі розробників. Проєкти PoC характеризуються:

• складністю визначення потреб клієнта;
• обмеженим бюджетом;
• стислими термінами виконання.

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

Проблеми, які виникли під час співпраці:

• додавання нової функціональності в ході розробки;
• суперечливі питання під час приймання робіт.

Щоб уникнути подібних проблем варто дотримуватися таких рекомендацій:

1. Детально ознайомлюйтеся з контрактом та обсягом робіт. Звертайте увагу на всі деталі. Наприклад, якщо потрібно розробити мобільне рішення, уточніть, який саме тип додатка цікавить клієнта – iOs, Android і т.д. Це позбавить вас проблем при прийманні робіт.
2. Уточнюйте гіпотези ключових функцій та формуйте макети – mockups. Це допоможе зрозуміти, чого саме хоче клієнт. Витрачайте на цей етап не менше двох тижнів. Виконайте глибокий бізнес-аналіз, причому залучіть до нього архітектора чи CTO. 
3. Виконайте пріоритизацію функцій. Які з них мають бути реалізовані обов’язково, а які – бажано? Те ж стосується і типу розроблюваного ПЗ – визначтеся, додаток для якої платформи має бути створений першочергово.
4. Обґрунтуйте причини архітектурного рішення і наявності технічного боргу. Грамотно прийняте технічне рішення – запорука успіху вашого PoC проєкту.

Case 3. Реалізація проєкту на основі готового технічного рішення

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

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

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

Розглянемо шляхи подолання вищезазначених проблем.

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

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

Інтеграція зі сторонніми системами

Case 4. Система не працює

Для зменшення негативного впливу цього типу проблем важливо мати перелік функціональності, яка залежить від конкретної інтеграції. У разі виникнення проблеми це дозволяє одразу інформувати клієнта, що потрібно перевірити певні функції, і з’являється можливість виправити всі дефекти одразу. 

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

Case 5. Перевищення кошторису в задачах інтеграції

Завжди, коли існує задача на інтеграцію зі сторонніми системами, перед тим, як брати її в роботу, потрібно оцінити цю інтеграцію, а саме:

• наявність необхідних прав;
• присутність певних обмежень;
• існування специфіки;
• відповідність потребам проєкту.

Крім того, потрібно закладати в кошторис всі наявні ризики й обов’язково обговорювати їх з клієнтом.

Комунікація в архітектурних питаннях

Case 6. Зменшення темпу розробки при переході від MVP до фази Active Development

Головне розв’язання цієї проблеми – комунікація з клієнтом з приводу причини вибору попереднього архітектурного рішення. Також потрібно пояснити замовнику, що якщо він планує розвивати проєкт, доцільним буде перехід на сервіс-орієнтовану архітектуру. Це стане своєрідною інвестицією у стабільність швидкості розробки.

Case 7. Запит/тенденція на збільшення кількості користувачів системи

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

Далі потрібно внести задачі на оптимізацію і тільки після цього можна відповідним чином змінювати технологічну дорожню карту (road map) – здійснювати масштабування та збільшення кількості користувачів. 

Помилки в оцінюванні

Case 8. Неефективність оцінювання та збільшення залежностей при розробці

Коли команда починає працювати над великим обсягом робіт (epic) дуже важливо проговорити контекст із керівником команди розробників (team lead) та розбити його на менші історії. Це допомагає здійснювати більш ефективну оцінку проєкту.

Загальні проблеми в комунікації

Case 9. Часте перемикання контексту і як результат незадоволення від отриманої роботи

Не дивлячись на використання системи управління проєктами (наприклад, Jira), клієнту важко відстежувати прогрес команди. Для того, щоб розв’язати цю проблему, потрібно візуалізувати беклог, історію, пріоритет, задачі та оцінку – можна прописати цю інформацію у звичайній Excel-таблиці. Цей документ потрібно використовувати під час планування та у тижневих звітах. Так замовник буде розуміти, в якому напрямку рухається проєкт.

Case 10. Неочевидний результат роботи команди розробників

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

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

Наш базовий місячний курс, протягом якого ви максимально заглибитесь у професію бізнес-аналітика: Business Analysis Intensive Online.
Тренінг допоможе Вам систематизувати накопичений досвід і отримати оптимальний, концентрований набір знань для успішного управління проектами: Project Management: Deep Dive Online.