Теорія та практика реалізації проєктів з розробки програмного забезпечення на замовлення
Акт перший: Жили-були…
Компанія – розробник ПЗ розробила велику аналітичну систему для загальнонаціонального замовника, а також забезпечує постійну підтримку системи надалі. Згодом система починає застарівати і компанія замовника приймає рішення створити нову версію. Компанія має зростаючі амбіції і новий проєкт було оголошено «проєктом міжнародного рівня». Збір і обробка інформації закінчується готовим технічним завданням на розробку програмного забезпечення. Тут і виникають перші розбіжності між очікуваннями звичайного клієнта (який має досвід роботи зі старою версією програми) і потенційного замовника. Звичайний замовник має сильний вплив на проєкт, тому компроміс виявився дуже близьким до його позиції. На жаль, узгоджений компроміс не був чітко зазначений у вимогах до розробки ПЗ, і тут починається точка біфуркації! Версія, як результат розробки, і версія клієнта, «як вийшло».
Акт другий: Запуск процесу
Три виділені команди наймаються для розробки окремих частин проєкту паралельно з командою Компанії-розробника. Планувалося почати з опису процесу автоматизації бізнес-процесів, але насправді все стартувало з переробки вже наявної системи, як єдиного джерела технічної інформації. Тут з’являється друга розбіжність: ролі та обов’язки команд і гравців сформульовані не чітко. У результаті всі 5 «акторів» на сцені справляються із завданнями на власний розсуд. І все це в темній кімнаті, «під свічкою суб’єктивності». Говорячи «під свічкою суб’єктивності», ми маємо на увазі, що кожна команда працює згідно зі своїми внутрішніми планами, засобами відстеження помилок, управління версіями, тощо. Відсутність централізованої системи «перегріває» Команду-розробника, яка в цій ситуації відповідальна за управління плануванням, відстеженням помилок тощо.
Акт третій: Процес відновлення
Нарешті всім стає зрозуміло, що ситуація безповоротно провальна, і після традиційного «полювання на відьом» ухвалюються перші кроки для поліпшення загального робочого процесу. Спочатку це лише загальне формальне планування, звітність, інструменти… Хороша спроба, але недостатня! Що далі? Загальні ролі та обов’язки + процедура ескалації. Ескалація не працює! … Внутрішній аудитор?! … немає результату?… Зовнішній аудитор! (має хороший рівень довіри з боку менеджера проєкту або спонсора). Ідеальний результат! Відстеження питань. Так! Спільне сховище документів і джерел? Відкласти …
Акт четвертий: Прохолодний вітер
Процес налаштований добре, але клієнт очікував на готовність продукту в зазначений термін. А очевидно, що система не може бути завершена у встановлені терміни. Жорсткі переговори виносять на поверхню такі проблеми: дискусії призвели до напруженості у відносинах між Клієнтом і Розробником, а остаточне прийняття майже всіх запитів клієнта створює додаткову проблему з часом/бюджетом і процесом. З двох поганих варіантів було обрано… обидва (крах відносин, крах плануванню). Наслідок конфлікту – реорганізація управління в Компанії розробника. Більше того, це було зроблено не одним пострілом, але подовжено велику роботу протягом деякого періоду («полювання на відьом 2»). Це справді не зовсім сприятливо впливає на клімат у команді, але основні процеси встановлені та працюють, тож розробка триває, і продуктивність сильно збільшилася.
Акт п’ятий: Кінець
Новий менеджмент Компанії-розробника нарешті стабілізував внутрішній процес: робочий компроміс між правильним формальним процесом і мінімальна організація. Це дало можливість повністю переключитися на задоволення очікувань клієнта … але занадто пізно. Так, був якийсь позитивний ефект: роботи тривали, але в будь-якому разі замовник очікував більшого і раніше. Остаточний поворот жорстких переговорів із клієнтом закінчився скасуванням контракту. Таким чином, практично готовий до використання продукт (бета-версія) не має застосування, як великими клієнтами, так і міжнародним замовником.
Помилки, які призводять проєкт до краху:
Відсутність конкретної стратегії управління очікуваннями клієнта. Якщо клієнт «жорсткий», слід планувати і контролювати очікування клієнта. Найгірший результат – розширення конфлікту і відмова від деяких запитів на зміни і, зрештою, прийняття всього «як є». Відсутність досвіду управління великими проєктами за участю міжнародних і розподілених команд. Досвід роботи вітчизняних команд розробників «в офісі» не дає гарантій ефективності проєкту при застосуванні тих самих методів управління до офшорної команди. Місцеві проєкти є більш стабільними та мають сильнішу тенденцію до самоорганізації. Таким чином, насправді, розпочинаючи місцевий проєкт як «вузькоспеціальний», можна очікувати реалізацію процесу десь на рівні 2 – 3 після досить короткого періоду часу. У розподілених проєктах ця «самоорганізація» практично неможлива, тож потрібно потурбуватися заздалегідь про планування та здійснення процесу управління розподіленими офшорними командами. Чітке уявлення про роль і обов’язки для кожного гравця, а також конкретні правила ескалації можуть заощадити багато часу, особливо на початкових стадіях. В іншому разі можна зіткнутися з дублюванням роботи.
