Генеральний директор, Москва
Мова не про те, як зробити згубний проект хітом, а про те, як зістригти зі свідомо паршивої вівці найбільшу кількість вовни. Але попередньо приреченому дітищу потрібно поставити сумний діагноз. Про те, як це зробити і завалити проект найбільш ефективно, в матеріалі з рубрики «П'ятничний менеджер» розповідає учасник Товариства Олег Пашинін.
Пропрацювавши тривалий термін в IT-сфері, починаєш розуміти, що як би ти не хотів, частина проектів провалюється. За оцінками деяких експертів, кількість таких проектів доходить до 60%. Перефразовуючи класика, можна сказати, що всі успішні проекти успішні однаково, а кожен провальний - провалений по-своєму. У кожному разі можна знайти свою ключову причину провалу. Ось деякі з них:
1. Нереальні проектні терміни і бюджет
«... менеджера з маркетингу навряд чи особливо хвилює реалістичність пропонованого їм плану і бюджету, оскільки його основна мета - отримати комісійну винагороду або принести задоволення своєму босові». Едвард Йордан, «Смертельний марш».
2. Непрофесіоналізм учасників проектів
«Всі компанії, що надають послуги в ІТ, стають жадібними і намагаються рости швидше, ніж можуть знаходити талановитих людей ...». Джоел Спольскі, «Джоел про програмування».
3. Політичні інтриги навколо проектів
«... відмінною рисою безнадійних проектів є настільки сильний вплив політики, що вона може звести нанівець всі зусилля виконати хоча б яку-небудь роботу». Едвард Йордан, «Смертельний марш».
4. Мінливість вимог до систем в ході виконання проектів
«Однією з найпоширеніших причин некерованості проектів є мінливі вимоги». Роберт Гласс, «Факти і помилки професійного програмування».
Причини різні, підсумок один - провал. Але він не приходить відразу. Провал терпляче чекає свого часу, відзначаючи промахи, проблеми, конфлікти, зриви термінів і інші свідоцтва свого неминучого торжества. Причини провалу присутні, як правило, з самого початку проекту, але навряд чи хтось готовий закрити проект на старті. Адже головне - вплутатися в бійку. Але чим більше зусиль і (грошей!) Йде на проект, тим менше шансів його закрити. Виникають все нові і нові проблеми, до яких залучається все більше коштів і людей. Кожен член проектної команди самовіддано включається в боротьбу. Подолання вже стає самоціллю: дорога - все, мета - ніщо. Думаю, що і вам не раз доводилося спостерігати типові етапи розвитку провального проекту.
Етапи розвитку провального проекту
- Терміни надання технічного завдання починають затягуватися. Занепокоєння немає - це буває.
- Технічне завдання представлено на погодження. У Замовника виникає легке здивування - в документах занадто багато «води», частина вимог не відповідає тому, що обговорювалося з проектною командою. Починається процес узгодження. Всі сповнені рішучості швидко усунути недоліки.
- Процес узгодження технічного завдання затягується. З'являються перші ознаки занепокоєння в зв'язку з порушенням термінів. До цього ставляться з розумінням, адже важливі не документи, а сама система.
- Підійшов термін поставки першого релізу системи, який Виконавець повинен встановити на обладнання Замовника. Виконавець повідомляє, що все готово, але потрібно почекати ще пару днів.
- Установка системи йде повним ходом, але поки безрезультатно. Систему повинні були встановити ще два тижні тому.
- Терміни узгодження ТЗ давно пройшли, але це вже не дуже хвилює. Заклопотаність пов'язана з тим, що ніяк не вдається налагодити систему.
- Система встановлена, але працює погано. Частина функціоналу не реалізована зовсім, частина реалізована не так, як очікувалося, і все одно не працює через велику кількість помилок. Невдоволення Замовника наростає.
- Встановлюються нові релізи системи, але кожен наступний реліз працює не кращий за попередній. Протоколи зустрічей вже не ведуться. Зустрічі перетворилися у взаємні претензії. Про те, що технічне завдання до сих пір не погоджено, вже ніхто не згадує.
- Складаються довгі списки помилок системи, які потрібно усунути. Нові релізи системи містять виправлення нових помилок, але виявляються старі помилки, які були виправлені раніше в попередніх релізах.
- Виконавець вимагає початку дослідної експлуатації системи і підписання актів приймання, але користувачі відмовляються працювати в системі, так як вона їм не подобається і часто падає.
- Акти приймання етапу розробки технічного завдання підписуються з обіцянкою Виконавця виправити все пізніше.
- Запізнення проекту вже становить 30% - 50%. ТЗ узгоджується заднім числом.
- Встановлено, нарешті, всі компоненти системи. Основні критичні помилки виправлені, але працювати в системі неможливо через незручності функціоналу.
- Замовник просить переробити функціонал. Виконавець не погоджується без додаткової оплати, так як функціонал розроблений відповідно до ТЗ. Замовник відмовляється приймати систему. Йде довгий період нерозуміння, що робити з системою.
- Відбуваються зміни на стороні Замовника (змінюються люди / процедури / процеси тощо). У зв'язку з змінами, що відбулися стає зрозуміло: щоб хоч якось почати працювати в системі, її потрібно переробити відповідно до змін, що відбулися. Укладається додаткова угода на доопрацювання системи. Щоб не втратити обличчя, керівництво домовилося оголосити про новий етап проекту.
- Йде тривалий етап доопрацювання. Терміни перевищені вже в два рази. Співробітники Виконавця і Замовника втомилися від проекту, але не знають, як його припинити. На проекті змінюється керівник проекту Виконавця і частина проектної команди. Нова проектна команда заново збирає вимоги.
- Замовник розуміє, що існуюча система працювати не буде. Стара технологія роботи здається вже не такий поганий, в порівнянні з новою системою. Замовник максимально гальмує впровадження системи, не знаючи як вийти з цього впровадження.
- Йде довгий процес переговорів. В результаті сторони домовляються про приймання системи. Розмір грошової винагороди Виконавця істотно знижений. Акти закриваються. Провал не потрібен жодній зі сторін, тому за мовчазною згодою проект вважається успішним.
- Виходить прес-реліз про успішне впровадження системи.
Ось він, нарешті, довгоочікуваний фінал. Тобто начебто не провал. Але ми-то знаємо ...
До чого були всі ці безсонні ночі, мішки під очима, сварки з колегами, вбивство нервових клітин, якщо система все одно не працює, премій немає, а очікувана професійна задоволеність так і не наступила? Витрачений величезний бюджет, а що ми отримали в результаті?
«Як сказав мені старий раб перед таверна:
'Ми, озираючись, бачимо лише руїни'.
Погляд, звичайно, дуже варварський, але вірний ».
И.Бродский
Але ж було б набагато ефективніше спрямувати зусилля на благородну справу - збереження коштів рідної компанії при збереженні власного здоров'я і душевної рівноваги. Іншими словами - не намагатися врятувати проект, а, навпаки, втопити його якомога раніше. Упевнений, що ви вже знаєте або здогадуєтеся, як це зробити.
Що необхідно зробити, щоб провалити проект найбільш результативно.
- Вивчіть перед проектом резюме фахівців проектної команди Виконавця. Відкидайте кандидатури співробітників до тих пір, поки ви не переконаєтеся в наступному:
- Вам представлені наймолодші співробітники компанії Виконавця, які прийшли в команду недавно і не мають проектного досвіду.
- Співробітники проектної команди ніколи раніше спільно не працювали.
- Профіль фахівців проектної команди максимально далекий від вашої предметної області, а архітектура запропонованого рішення не відповідає інфраструктурі компанії.
- Керівник проекту Виконавця заляканий і поводиться невпевнено.
- Проекти, які виконували співробітники проектної команди, не були завершені або завершені невдало.
- Поставте нереально стислі терміни проекту.
- Визначте максимальну кількість проектних документів, що вимагають узгодження.
- Складіть гранично довгий список співробітників, що погоджують проектну документацію з вашого боку.
- Затягуйте узгодження технічного завдання. Відмовляйтеся підписувати проектні документи, посилаючись на невідповідність ГОСТам, внутрішнім стандартам вашої компанії, слабку деталізацію або невідповідність бізнес-процесам.
- Постійно змінюйте вимоги до системи.
- Частіше проводьте ротацію співробітників вашої проектної команди і предметних фахівців.
- Якщо відчуєте, що проектна робота, проте, почала стабілізуватися, попросіть замінити проектну команду Виконавця через зрив термінів етапів проекту. Почніть знову, з пункту 1.
Погодьтеся, все це зробити набагато простіше, ніж гинути за проект. При цьому ви нічого не втрачаєте. Провал проекту - це вже не провал, а ваш успіх. А якщо проект все ж завершено успішно, система впроваджена, значить це дійсно хороша система, яка загартувалася в боротьбі завдяки вам. Ви в будь-якому випадку залишаєтеся у виграші. І може бути навіть з премією. За успішно виконаний проект або як результат економії коштів вашої компанії.
Удачі на проектах!
'' За оцінками деяких експертів, кількість таких проектів доходить до 60% ''.
З особистого досвіду вважаю що це відсоток на рівні 75-80%, а деякі проекти тільки з 2 або 3 рази виходять.
У будь-якому проекті присутсвуют ці причини провалу.
Іноді навіть кілька одномоментно.
Головне в будь-якому проекті це вміння домовлятися Виконавця і Закакзчіка.
Всім би нам адекватних замовників.
Вважаю, що хороший Виконавець з досвідом здатний дізнатися Замовника з такими '' недоліками '' і вчасно відмовитися від проекту, якщо не знає як їм протистояти. Інакше - це жадібність, через яку так низький відсоток успішних проектів.
Чи не жадібність губить It-проекти. А недолік жадібності :-). Все, що відбувається на звичайному проекті описано правильно, з хорошим гумором, подекуди переходить в добрий сарказм. І висновок хороший - вигнати некомпетентну команду якомога швидше :) А ось дискусію на тему, що ж зробити, щоб звичайний проект вийшов при звичайній команді, можна і продовжити. У мене простий рецепт. Потрібно більше грошей і часу! Ризики - неминучі. ТЗ буде кривим, хоч ти у. ся. Фахівці виконавця будуть чинити опір змінам до останнього, так, як ніби б'ються з ворогом Батьківщини. Будуть мінятися і вимоги, і фахівці Замовника. В житті не побачите повністю компетентну команду Виконавця. Ну і що? Все це вирішується простим збільшенням бюджету в міру необхідності. Або закладанням ризиків в початкову ціну простим збільшенням її в три рази. Готовність Замовника платити, не скупитися - дуже важлива. А ось готовність Виконавця братися за великий проект за три копійки через нестачу жадібності і конкуренції просто небезпечна.
Олена Дегтярьова, адже ІТ-фахівці ніколи відкрито не визнаються, що дурять народ, довірливий до технічного прогресу))) Я був би щасливий знайти людей, '' довірливих до технічного прогресу ''. Навіть не так: '' небайдужих '' (довіру сам створю - це моя робота). При виконанні цієї головної умови моєї роботи - спробував би хто у мене задурити. Щоб подолати байдужість людей до прогресу, викорінити споживацьке ставлення (до ІТ, зокрема) - що тільки не доводиться робити.