Почему крупные ИТ-проекты имеют тенденцию терпеть неудачу или имеют большие перерасходы / затраты? [закрыто]

Я всегда читаю о крупномасштабных проектах по трансформации или интеграции, которые являются полной или почти полной катастрофой. Даже если им каким-то образом удастся добиться успеха, стоимость и график выдувания огромны. Какова реальная причина того, что крупные проекты более склонны к провалу. Может ли agile использоваться в подобных проектах, или традиционный подход все еще остается лучшим.

Одним из примеров из Австралии является проект расчета заработной платы в Квинсленде, в котором они изменили критерии успешности тестирования, чтобы выполнить проект.
Посмотрите еще несколько неудачных проектов в этом вопросе ( на Wayback Machine )

Есть ли у вас личный опыт, которым можно поделиться?

Основная причина - это расширение сферы действия , которое книга «Прагматичный программист» описывает как:

• особенность наворотов
• ползучий футуризм
• ползучесть требований

Это аспект синдрома вареной лягушки.

Идея различных «гибких» методов состоит в том, чтобы ускорить обратную связь и, мы надеемся, корректировать эволюцию проекта во времени.

Но другая причина - управление выпуском : если вы не готовы выпустить проект (каким бы несовершенным он ни был), скорее всего, он потерпит неудачу (потому что выпущен слишком поздно, со слишком многими ошибочными функциями и сложнее исправить / обновить / Обновить).

Это не означает, что у вас должна быть фиксированная дата выпуска, но это означает, что вы должны быть в состоянии в любое время создать работающую версию вашей программы, чтобы протестировать / оценить / выпустить ее.

В блоге « Поздние проекты опаздывают на один день » содержится еще много примеров:

Я знаю, что «получить реальный», что нужно сделать, это изогнуть область и сохранить фиксированную дату запуска, но это не сработает, если есть согласованная функциональность, которая не может быть завершена вовремя.

Вот почему мы не защищаем спецификации или «согласованную функциональность». В этом корень проблемы: мы говорим, что вы знаете все о том, что вам нужно и как это будет реализовано даже до того, как будет нарисован первый пиксель или написана строка кода. ,

Когда вы предсказываете жесткое будущее на гибком настоящем, вы попадаете в беду. Жесткие фьючерсы являются одними из самых опасных вещей. Они не оставляют места для открытий, появления и ошибок, которые открывают новые двери.

Обычно сложность проекта недооценивается .

У Стива МакКоннелла (из известной «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 000 000 долларов США все равно займет 2 месяца 2 000 000 долларов США независимо от того, сколько заявок вы получите. Если вы думаете, что делать это правильно - это дорого, подождите и посмотрите, как дорого это сделать неправильно.

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

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

Стоимость не исключает графика в глазах «менеджмента», что является важным отличием. Как мы знаем, «девять женщин не могут родить ребенка за один месяц» , тем не менее, вы удивитесь тому, сколько людей считает, что проблемы уменьшаются в глубине по отношению к сумме денег, которые им бросают. Плохое управление проектами, часто проявляющееся в форме микроуправления, является основной причиной большинства проектов (по моему опыту). Микроуправление начинает действовать, когда «руководство» понимает, что что-то выходит из-под контроля, и они не понимают, почему.

Когда это не является причиной, ожидаемый результат проекта, вероятно, не был приемлемым для начала. По моему опыту, если сроки проекта слишком короткие, люди будут настолько бояться делать ошибки, которые приводят к «двойной работе», что они вообще ничего не делают.

Вот почему руководство должно быть заполнено опытными программистами, имеющими историю ведущих команд, которые создавали успешные проекты. Такой человек может сказать: «Мы никак не можем сделать это ответственно», несмотря на возможный доход, и не будем долго руководить, поэтому многие из нас (в конечном итоге) отвечают на MBA, а не на PHD.

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

Время от времени вы сталкиваетесь с чем-то, что было хорошо спланировано, хорошо понято, реалистично и, казалось бы, прямо вперед. По какой-то причине, через шесть месяцев развития все изменилось. Бывает. Однако редко случается так, что основной причиной проекта становится прославленная свиная бочка.

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

Большую часть времени сочетание двух или более из следующих:

• проблема сотрудничества между отделами
• политика ... слишком много политики ...
• неправильная команда
• нереальное планирование
• изменение масштаба без соответствующей методологии
• недостающая информация

Хорошая книга на эту тему: Марш смерти .

Люди склонны думать, что разработка программного обеспечения является прогностическим процессом, пытаясь измерить и оценить вещи на год вперед. Это невозможно! Сборка программного обеспечения - это не производство болтов.

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

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

Программные проекты всех размеров «имеют тенденцию терпеть неудачу» или «имеют перерасход». Вы не слышите о перерасходе средств в бизнесе за углом, но вы делаете слышать о том , как система Virtual Case ФБР или система обработки багажа аэропорта Денвера. Поэтому я буду утверждать, что не все большие системы дают сбой, и что не все большие системы имеют перерасход средств / график.

Я пришел в больших системах , которые пришли в на время (график перемещается один раз и только один раз в течение проекта) и по спецификации (у меня не было доступа к бюджетной информации, поскольку мы были всего лишь одним из многих поставщиков). Еще меня поразила (и я немного об этом написал на этом сайте) крупная интегрированная система управления клиентами для крупного (в первых 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, и задается вопрос о том, когда обновляться. Изменения в объеме и желаемой функциональности, либо потому, что требования были собраны неправильно, либо кто-то изменил свое мнение, - это еще одна пара моментов, которые уже были рассмотрены.

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

Причина, по которой хорошо применяемые гибкие процессы, по-видимому, не страдают от этой проблемы, объясняется простой причиной. Вы не можете начать большой проект гибким способом. Вы можете выбрать один или другой.

Благодаря быстрому процессу вы никогда не заглядываете в одну или две итерации в будущее проекта. нет плана на следующие 2 года, только на следующие две недели. Когда ваше мнение так коротко, вы должны пойти на несколько компромиссов. Вы никогда не сможете начать с плана «Заключительное слово в виджетах» для любого вида создаваемого виджета. Самое большее, вы можете начать с «Виджета, который может всплыть», потому что это большая часть работы, которую вы можете выполнить за одну или две итерации.

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

По сути, крупные проекты могут потерпеть неудачу, поскольку они направлены на решение всех проблем всех потенциальных клиентов. Гибкий проект никогда не преследует эту цель, вместо этого он решает в каждой версии только одну критическую проблему, которая может возникнуть у одного клиента. Однако через некоторое время гибкий проект может решить множество критических проблем для многих клиентов.

• Неспособность отправить фактическим пользователям

Большие проекты имеют неприятную тенденцию годами переходить в «инфраструктурный» режим и забывают о создании реальных функций конечного пользователя и их отправке. К тому времени, когда он выйдет, его очень дорого менять, и, как правило, самые большие концептуальные изменения заканчиваются после первого реального бета-тестирования.

• Неспособность точно оценить стоимость

Если кажется, что проекты перерастут окупаемость инвестиций, они будут отменены.

• Неспособность контролировать качество

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

Они забыли закон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если вы принимаете во внимание закон Хофштадтера.

Вещи, которые я видел в веб-разработке:

• Слишком много поваров - Major B & M Retailer, где акцент внезапно сместился на сеть. Внезапно 20 руководителей департаментов преследуют каждую инициативу, чтобы произвести впечатление на нового головного сыра. Когда-то мне приходилось внедрять новые иконки, потому что легальным не нравился внешний вид старых.

• Чрезмерное внимание к сопоставлению спецификаций с достижением целей - «Значки IE6 немного блекнут по сравнению с IE7. Пожалуйста, отбросьте ту работу, которая важна для даты запуска, и уделите ей 0,05% нашей клиентской базы, чтобы делать ужасные вещи, которые займут дни внедрить и еще больше замедлить работу IE ».

• Плохие инструменты, выбранные не разработчиками, которые даже не удосужились спросить совета у своих внутренних разработчиков.

• Плохие разработчики выбирают инструменты - «Зачем платить 20 компетентным разработчикам Java приличную зарплату, когда мы можем отдать на аутсорсинг 200 человек с неграмотным кодом, которые слишком мало знают, чтобы использовать контроль версий? так как они одновременно и с людьми из разных стран, работают на бэкэндах в первую очередь для 3 больших приложений.

• Плохая / Сломанная Архитектура - Слои на слоях испуганного кода «сделай вчера» людьми, которые были уволены или теперь являются менеджерами.