Чому великі ІТ-проекти, як правило, не спрацьовують або мають великі перевищення вартості / графіку? [зачинено]

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

Одним із прикладів Австралії є проект заробітної плати в штаті Квінсленд, де вони змінили критерії успішності тестування для реалізації проекту.
Дивіться ще кілька невдалих проектів у цьому запитанні ТА ( на Wayback Machine )

Чи маєте ви якийсь особистий досвід, щоб поділитися?

Основна причина - збільшення обсягу , яке книга "Прагматичний програміст" характеризує як:

• особливість цвітіння
• повзучий Featurism
• повзання вимог

Це аспект синдрому вареної жаби.

Ідея різних "спритних" методів полягає в прискоренні зворотного зв'язку та, сподіваємось, - вчасно виправити еволюцію проекту.

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

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

Повідомлення в блозі " Пізні проекти спізнюються на день ", містить ще багато прикладів:

Я знаю, що «робити реальні речі» - це розширити сферу застосування та зберегти фіксовану дату запуску, але це не працює, якщо буде узгоджено функціональність, яка не може бути завершена вчасно.

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

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

Зазвичай складність проекту занижена .

Стів Макконнелл (слава "Code Complete") має список класичних помилок .

Деякі неефективні практики розвитку обираються настільки часто, так багато людей, з такими передбачуваними, поганими результатами, що вони заслуговують називатися "класичними помилками" ...

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

Загальний знаменник цього списку полягає в тому, що вам не обов'язково буде швидко розвиватися, якщо ви уникнете помилки, але ви обов'язково отримаєте повільний розвиток, якщо цього не уникнете ...

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

Люди

№1: Підрив мотивації ...

№ 2: Слабкий персонал ...

№ 3: Безконтрольні працівники проблем ...

№4: Героїка ...

№5: Додавання людей до пізнього проекту ...

# 6: Шумні, переповнені офіси ...

№ 7: Тертя між розробниками та клієнтами ...

№ 8: Нереалістичні очікування ...

№ 9: Відсутність ефективного спонсорства проекту ...

№ 10: Відсутність вставки для зацікавлених сторін ...

№ 11: Відсутність введення користувачем ...

№ 12: Політика над сутністю ...

# 13: Бажане мислення ...

Процес

# 14: Надмірно оптимістичні розклади ...

№ 15: Недостатнє управління ризиками ...

№ 16: Вихід з ладу підрядника ...

№ 17: Недостатнє планування ...

№ 18: Відмова від планування під тиском ...

№ 19: Даремно витрачений час під час нечіткого переднього кінця. "Нечіткий передній край" - це час до початку проекту, час, який зазвичай витрачається на процес затвердження та складання бюджету ...

# 20: Зміни активності вгору за течією ... Також відомий як "стрибки в кодування" ...

№ 21: Неадекватний дизайн ...

# 22: Коротке змінення гарантії якості ...

№ 23: Недостатній контроль управління ...

№24: Передчасна або занадто часта конвергенція. Незадовго до запланованого випуску продукту є поштовх до підготовки продукту до випуску - поліпшення продуктивності продукту, друк підсумкової документації, включення кінцевих гачків системи довідки, шліфування програми інсталяції, відключення функціоналу, яке не буде. готові вчасно тощо.

# 25: Опускання необхідних завдань із оцінок ...

# 26: Планування наздогнати пізніше ...

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

Товар

№ 28: Вимоги до позолочення. Деякі проекти мають більше вимог, ніж потрібно з самого початку ...

# 29: Повзучастість ...

№ 30: Розробка позолочених розробників. Розробники захоплюються новою технологією і іноді прагнуть спробувати нові функції ... - незалежно від того, чи потрібно це в їхньому продукті ...

# 31: Наштовхни мене, потягни на переговори ...

№ 32: Розробка, орієнтована на дослідження. Сеймур Крей, дизайнер суперкомп'ютерів Cray, каже, що він не намагається перевищити інженерні межі в більш ніж двох областях одночасно, оскільки ризик виходу з ладу занадто високий (Gilb 1988). Багато програмних проектів могли б навчитися уроку у Cray ...

Технологія

№ 33: Синдром срібло-кулі ...

# 34: Завищені заощадження від нових інструментів чи методів ... Особливий випадок завищених заощаджень виникає, коли проекти повторно використовують код з попередніх проектів ...

# 35: Інструменти комутації посеред проекту ...

№ 36: Відсутність автоматизованого керування вихідним кодом ...

Більший проект = Більше складності
Більше складності = Більше невизначеностей
Більше невизначеностей = важче оцінити
важче оцінити = Погані оцінки
погані оцінки = перевитрати витрат

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

Люди, що складають ставки, не хочуть витрачати свій час, якщо у них немає шансів на перемогу, тому їхні звичайні оцінки перестають триматися. Я знаю людей, які замість перемикачів POE вказали звичайні комутатори, щоб зекономити 80 доларів. Але проект потребував POE, оскільки у нього були IP камери. Ці 80 доларів потрібно витратити, але зараз це поза специфікацією.

Я твердо переконаний, що 2-мільйонний проект на 2 мільйони доларів все-таки займе 2 місяці 2 000 000 доларів, незалежно від того, скільки пропозицій ви отримаєте. Якщо ви думаєте, що зробити це правильно, дорого, зачекайте і подивіться, як дорого це зробити неправильно.

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

Іншою причиною є упереджені оцінки оптимізму: щоб виграти торги, для розрахунку ціни використовуються найкращі оцінки. Чим більше проект, тим менша ймовірність найкращого сценарію. Правила торгів роблять ймовірним, що найоптимістичніший правопорушник отримає акцепт, тому навіть якщо 5 постачальників роблять реалістичну оцінку, а шостий - занадто оптимістичним, оптимістичний виграє торги та згодом не відповідає. Тож це свого роду негативний вибір.

Вартість не виключає розкладу в очах "управління", що важливо розрізнити. Як ми знаємо, «дев'ять жінок не можуть народити дитину за один місяць» , але ви здивуєтеся тому, як багато людей думають, що проблеми зменшуються в глибині по відношенню до кількості грошей, яка кидається на них. Погане управління проектами, що часто виявляється у вигляді мікроменеджменту, є провідною причиною більшості проектів (на мій досвід). Мікроменеджмент починається, коли "менеджмент" розуміє, що щось виходить з-під контролю, і вони не зрозуміли, чому саме.

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

Ось чому менеджмент повинен бути заповнений досвідченими програмістами, які мають історію провідних команд, які створювали успішні проекти. Така людина може сказати "Ні в якому разі ми не могли б зробити це відповідально", незважаючи на можливий дохід, і не буде довго в управлінні, саме тому багато хто з нас (в кінцевому рахунку) відповідають на MBA замість PHD.

Я втратив підрахунок кількості компаній, в яких я працював, де непрограміст відповідав за найм програмістів. Одного разу у мене було інтерв’ю, де менеджер з найму не хотів нічого робити, окрім як обговорити недавню спортивну подію (я думаю, це була футбольна гра). Якщо людина, якій ви керуєте, черпає більше натхнення у тренера з НФЛ, ніж Кнут, проект збирається на танк.

Час від часу ви стикаєтеся з чимось добре спланованим, добре зрозумілим, реалістичним і, здавалося б, прямим вперед. З будь-якої причини, через шість місяців розвитку, все змінилося. Це буває. Рідко, однак, трапляється причина, що проект став прославленою свининою.

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

Більшість випадків це комбінація двох або більше з наступного:

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

Приємна книга на тему: Березень смерті .

Люди схильні думати, що розробка програмного забезпечення - це процес прогнозування, намагаючись виміряти та оцінити речі на рік вперед. Це неможливо! Будівельне програмне забезпечення - це не виробництво болтів.

Слідуючи тій же «тенденції», вони намагаються зробити величезний аналіз (знову на рік вперед), думаючи, що вони покриють усі можливості, а згодом перетворюють програміста на простого машиніста. Чому можна думати, що це може спрацювати? Така поведінка просто призводить до поганих оцінок і великої кількості бюрократії.

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

Програмні проекти всіх розмірів "мають тенденцію до відмови" або "мають перевищення вартості". Ви не почуєте про перевитрату на бізнесі за рогом, але ви робите чути про те , як система Virtual Case ФБР або система обробки багажу аеропорту Денвера. Тому я висловлю твердження, що не всі великі системи виходять з ладу, а також не всі великі системи мають перевищення вартості / графіку.

Я натрапив на великі системи, які ввійшли вчасно (графік змінився один раз і лише один раз під час проекту) та специфікацію (я не мав доступу до бюджетної інформації, оскільки ми були лише 1 з багатьох постачальників). Тим, що мене все ще вражає (і я про це трохи писав на цьому сайті), була велика інтегрована система управління клієнтами для великого (у перших 100 із 500 статків) фінансового клієнта. Я підрахував, що вони заплатили близько $ 100 тис. / День (більше року) за зарплату людей під час конференційних дзвінків.

Що стосується системи поводження з багажем, менеджери програмного забезпечення заявили, що "на основі проектів такого розміру та складності знадобиться 4 роки, щоб створити та налагодити цю систему". Менеджери з продажу та виконавчої служби сказали, що "аеропорт відкриється через 2 роки, ми сказали клієнту, що це займе 2 роки, тому у вас є 2 роки, щоб зробити це". Тест на те, чи є ви програмістом чи керівником, є простою відповіддю на наступне питання: "чи запізнилася система впорядкування багажу чи вчасно?"

Якщо замовник точно знає, чого хоче (а їх мало хто робить), він буде дуже далеко на шляху до того, щоб тримати під контролем витрати та час (а це люди, які, як правило, непогано застосовують офшоринг). Якщо ваш проект повинен відповідати всім можливим особливостям, про які, можливо, ваші клієнти можуть мріяти, і кожен окремий відділ має право вето на те, коли їхні золоті брички додаються до проекту, то ви приречені на відмову від невдачі з самого початку (як, наприклад, у ФБР) Проект VCF).

Сприйняття реальності

Ось найкращий опис цієї проблеми, яку я коли-небудь знайшов. Дерево гойдалки від businessballs.com

Мене познайомили з концепцією "Сприйняття Реальності" на початку свого програмування. За це я щиро вдячний. Я вважаю, що це найбільша причина того, що будь-який проект провалюється, не лише ІТ- проекти.

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

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

І так далі, і так далі.

Я був на одному проекті кілька років тому, для клієнта. Мене привезли після завершення тендеру та плану проекту. Був постійний тиск, щоб йти швидше, швидше, і смішні рішення щодо скорочення витрат, велика перевантаження персоналу, ніяких ресурсів для них; ніяких столів, комп’ютерів, нічого.

Нарешті, я виявив, що проект був виставлений на 7 місяців і 16 мільйонів доларів. Я підрахував, що на звороті конверта це повинно бути 24 місяці і від 50 до 100 мільйонів. Я встановив зустріч зі своїм менеджером та його менеджером, і представив свою справу, і як ми НЕ приїжджали ніде поблизу часу, коли чи бюджету; вони принизили всі проблеми. Наприкінці засідання керівник директора зателефонував і повідомив обом цим керівникам, що я сказав, за винятком недоліків у початковій заявці.

У мене був шанс відмовитись від проекту, коли вони змінили технології на ту, до якої я не був кваліфікований. Я з кимось говорив набагато пізніше. Проект в кінцевому підсумку був скасований, коли він був приблизно наполовину ... за 12 місяців і 35 мільйонів доларів.

Гучні великі проекти відштовхують людей говорити: "це помилка". Помилок не допускається.

Докладно пояснюючи відповідь VonC:

Ці великі проекти мають ментальність "все або нічого". Проект, як визначено, повинен бути випущений за один раз - часто, оскільки це перехід від існуючої системи.

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

Яке рішення цього?

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

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

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

Фактор, який торкнувся, але ще не вирішено:

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

Якщо компанія не може оцінити належним чином, це дивно, що вони також не можуть правильно створити систему?

Майкл Крігсман на ZDNet має блог, присвячений "Невдачам ІТ-проекту ", який може зацікавити тут.

Ще один момент полягає в тому, що при тривалих проектах, що тривають роки, як правило, або є модернізація, щоб розглянути, або альтернативні рішення, наприклад, чи можна зараз проект робити в хмарі, а не на місці, щоб щось почало з'являтися все більше і більше, що при розгляді це не було даною датою початку проекту. Наприклад, хоча можна починати, коли щось становить 6,0, до моменту першої фази може бути 6,3 або 6,4, і питання про те, коли потрібно оновити, задається питанням. Зміни в обсязі та бажаній функціональності, тому що вимоги були зібрані неправильно чи хтось передумав, - це ще одна пара моментів, які вже були висвітлені досить багато.

Чи можна спритно використовувати у подібних проектах або традиційний підхід все ще є найкращим.

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

Завдяки гнучкому процесу, ви ніколи насправді не переглядаєте одну чи дві ітерації у майбутнє проекту. не існує «плану» на наступні 2 роки, лише наступні два тижні. Якщо ваш погляд такий короткий, вам доведеться зробити кілька компромісів. Ви ніколи не можете починати з плану створення "Остаточного слова у віджетах" для будь-якого виду, який ви розробляєте. По крайній мірі, ви можете почати з "Віджету, який може розморозити", тому що саме про більшу роботу ви можете виконати за одну чи дві ітерації.

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

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

• Неможливо доставити фактичним користувачам

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

• Невдача точно оцінити вартість

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

• Неможливість контролю якості

При достатній кількості дефектів можливий темп руху вперед впаде до нуля або нижче. Без прогресу взагалі важко сперечатися щодо подальшого існування.

Вони забули Закон Гофстадтера: Це завжди триває довше, ніж ви очікували, навіть якщо ви враховуєте закон Хофстадтера.

Те, що я бачив у веб-розробці:

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

• Зайвий фокус на відповідності специфікаціям щодо досягнення цілей - "Піктограми IE6 злегка зів'яли в порівнянні з IE7. Будь ласка, відмовтеся від цієї критичної роботи, яку ви робите, і ви відвідуєте 0,05% нашої клієнтської бази, щоб робити жахливі речі, що займуть днів щоб ще більше застосувати та уповільнити досвід IE ".

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

• Погані розробники, вибрані інструментами - "Навіщо платити 20 грамотним Java-розробникам гідну зарплату, коли ми можемо передати 200 ледве кодів грамотних хлопців, які знають занадто мало, щоб використовувати контроль версій?" оскільки вони одночасно та з людьми в різних країнах працюють на задньому плані насамперед для трьох великих додатків.

• Погана / зламана архітектура - шари на шари панікованого, виконуваного вчора коду людьми, які були звільнені або зараз менеджери.