Я працюю в ІТ вже майже 15 років, з них 5 — архітектором. За цей час встиг наробити безліч помилок і надивився на безліч чужих. Тож маю що розповісти. Хочу поділитися своїм досвідом і розповісти про найпопулярніші помилки під час проєктування та розробки архітектури застосунків. В цій статті поговоримо про так звані soft skills помилки, які трапляються в процесі консалтингу. А в другій статті я продовжу про технічні помилки. Сподіваюся, стаття допоможе вам уникнути невдач.

Типові помилки в процесі консалтингу

Помилка 1. Робити те, що просить клієнт, а не те, що йому насправді потрібно

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

Найперше та найважливіше — з’ясувати реальну бізнес-проблему клієнта і зрозуміти, як її розв’язати. Це завдання бізнес-аналітика та архітектора. Зовнішніх консультантів наймають саме для цього.

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

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

Ми вже майже попрощалися із замовниками, і тут я запитав, чим їх не влаштовує робота в Excel. З’ясувалося, що їм потрібно було, щоб дані постійно копіювалися і була можливість одночасного доступу до них з різних місць, так щоб дані були однакові (consistent) для всіх користувачів. А ще клієнти дуже непогано зналися на SQL. І тут рішення прийшло само собою — зробити міграцію даних в SQL-базу, яка зберігатиметься в хмарі та копіюватиметься автоматично, а користувачі матимуть одночасний доступ з різних точок планети. Це рішення мало схоже на комерційний застосунок, але це саме те, чого потребував клієнт і саме за ту ціну, яку він міг заплатити.

Якщо ми чітко розуміємо проблему, то можемо запропонувати краще і дешевше рішення.

Помилка 2. Не готуватися до сесій з потенційним клієнтом

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

Підготовка до pre-sale. Перша зустріч з клієнтом — це етап pre-sale. Від неї значною мірою залежить, чи підпишуть з вами контракт. Тому потрібно зібрати якомога більше інформації про сам проєкт, компанію, сферу її діяльності, конкурентів, аналогічні рішення на ринку. Адже без цих знань ми не зможемо бути корисними. До того ж розуміння контексту допоможе підібрати оптимальну проєктну команду.

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

Інший можливий сценарій — у замовника низькі показники продуктивності (performance), він хоче, щоб виявили причину та усунули її. Найраціональніше рішення — під’єднати системи, що допомагають знайти схожі проблеми, впровадити тестування навантаження (Performance Testing) і з’ясувати їх причину. Для команди консультантів, які не є експертами в такому типі тестувань, це неочевидно, тому вони пропонують провести довгу і дорогу discovery-фазу. Навряд чи клієнт погодиться.

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

Підготовка до discovery-фази. Ця тема заслуговує окремої статті, але ось основні, на мій погляд, пункти:

Приділіть ще більше уваги вивченню інформації про клієнта і проєкт, ніж під час підготовки до pre-sale. На цьому етапі у вас повинно бути вже більше контексту і можливостей знайти дані.
Підберіть команду (про це докладніше поговоримо далі).
Підготуйте адженду — це ніби очевидний етап, але його часто пропускають, особливо початківці. Були навіть ситуації, коли команда прилетіла до замовника за океан і стукала у зачинені двері офісу, оскільки заздалегідь не узгодила адженду.

Щоб під час discovery не виникло непорозумінь, раджу сюди вносити таку інформацію щодо кожної зустрічі:

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

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

Така підготовка значно підвищить шанси на успіх.

Помилка 3. Неправильно підібрана проєктна команда

На pre-sale мають бути залучені спеціалісти, які не лише мають найвищу технічну експертизу, а й можуть говорити мовою бізнесу і зрозуміти бізнес-проблеми.

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

Якщо говорити про discovery, то головні дійові особи тут:

Архітектор — закриває нефункціональні вимоги та дизайн.
Бізнес-аналітик — функціональні вимоги й потреби бізнесу.
Технічні експерти у вузькій галузі, залежно від потреб проєкту.

У кожного члена команди має бути чітка роль. Інакше може виникнути дві ситуації:

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

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

Помилка 4. Не визначити чіткі вимірювані значення нефункціональних вимог

Один з головних обов’язків архітектора під час консалтингу — це зібрати нефункціональні вимоги (non-functional requirements), їх ще називають атрибутами якості (quality attributes). Це тема, на яку люди пишуть цілі книжки. Але розберімось хоча б в основних помилках, які суттєво впливають на успіх проєкту.

Запитуючи у клієнта про вимоги до якості майбутнього рішення, часто у відповідь можна почути, що воно повинне бути швидким, безпечним, що код має бути якісним тощо. Приймати це як вичерпну відповідь — величезна помилка. Потрібно домовлятися про чіткі критерії, які можна виміряти. Інакше в певний момент виявиться, що поняття «швидкий застосунок» ви з клієнтом розумієте по-різному. Але вже буде пізно щось виправляти.

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

Звучить складно, тому розгляньмо знову на прикладі з мого досвіду. Було звичайне discovery. Ми з клієнтом почали обговорювати нефункціональні вимоги. На той момент уже було зрозуміло, що потрібно працювати із сервісами AWS, щоб зменшити витрати на DevOps і налаштування інфраструктури. Коли дійшли до обговорення доступності (availability) застосунку, клієнт сказав, що хоче 99,98%.

На моє питання, чому саме така цифра, він не відповів нічого суттєвого, тільки сказав, що десь чув і все. Для загального розуміння тут варто зазначити, що загалом ті сервіси Amazon, які ми збиралися використовувати, мали доступність 99,95%. Коли я почав йому пояснювати, що для забезпечення доступності 99,98% нам треба буде робити нестандартне рішення, яке значно підвищить вартість проєкту, замовник погодився на 99,95%. Якби ми це не обговорили, то або проєкт врешті обійшовся б клієнту набагато дорожче, або він би залишився незадоволеним нашою роботою.

Якщо вас цікавить, як правильно підготуватися до фаз discovery і pre-sale, що може піти не так і як уникнути типових помилок, рекомендую прочитати мою книжку Consulting Outbreak: Manager and Software Architect Could be Friends