Чому більшість технічних проектів провалюються ще до їхнього початку

За роки своєї кар'єри я спостерігав за численними проектами цифрової трансформації, які здавалися успішними, але виявилися дуже дорогими провалами. Раз за разом мене залучали для порятунку проектів, які тривали 12-18 місяців і в які внутрішні команди або зовнішні постачальники вклали значний час і ресурси. Коли організації звертаються за допомогою, всі їхні бюджети вичерпані, моральний дух команд на найнижчому рівні, а рівень розчарування серед керівництва високий. Хоча початкові цілі могли бути чітко визначені, фактичні результати значно нижчі за очікування. Провал технічних проектів рідко починається на етапі розробки — він починається на етапі планування, коли команди пропускають структуроване відкриття. Саме відкриття перетворює сиру концепцію на план розробки, який інженери можуть упевнено виконати.

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

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

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

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

Бізнес-контекст та стратегічна узгодженість

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

Технічне картування ландшафту та ідентифікація ризиків

• Проведіть детальний аналіз поточних систем та архітектурних обмежень
• Інтегруйте точки та технічні залежності
• Визначте потенційні ризики та стратегії їх мінімізації

Виявлення вимог та оцінка високого рівня

• Визначайте та виявляйте бізнес-потреби, шляхи користувачів, епічні історії, функціональні вимоги, використовуючи методики agile backlog grooming та перевірені шаблони з реальними прикладами
• Сприяйте проведенню структурованих семінарів
• Розумійте, де необхідні спеціальні практики Agile, щоб відповідати внутрішній пропускній здатності, регіональній залученості та структурі зацікавлених сторін

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

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

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