Почему много проектов программного обеспечения перестали работать сегодня? [закрытый]

Плохое управление.

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

существует разъединение между людьми, которые имеют дело с фактами и вещами (как программисты) и люди, которые имеют дело с другими людьми (как типы продаж и менеджеры). Программисту факты являются фактами и должны иметься дело с. Продавцу факты - то, что другие люди думают и изменяемы.

существуют также различия между материальными и неосязаемыми фактами. Никто не думает, что рабочие могли создать большой мост через месяц, если бы они были действительно мотивированы; они видят всю сталь и бетон и другой материал, который должен быть перемещен и зафиксирован в положение. Программное обеспечение намного менее материально, и испытывает недостаток в физических ограничениях: в то время как даже не теоретически возможно создать мост в течение месяца, возможно, что команда могла создать крупный проект в течение месяца как "все", что они должны сделать, добираются, все исправляется в первый раз. Физически возможно ввести тысячи строк кода в день; это просто, что шанс, что они применимы, как, так близко к нулю, это не имеет значения. Фактическая производительность главного разработчика является на самом деле довольно невпечатляющей в подсчете слов, сравненном, чтобы (сказать) производительность журналиста.

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

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

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

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

Нерациональное.

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

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

Закон

Hofstadter Это всегда занимает больше времени, чем Вы ожидаете, даже когда Вы принимаете Закон Hofstadter во внимание.

Плохое планирование.

Не прямой ответ, но я обнаружил, что Виртуальный файл дела представляет собой увлекательное исследование о том, как большой финансируемый правительством хорошо финансируемый проект все еще может потерпеть неудачу.

Вы также можете добавить основную причину сбоя программного проекта.

Другая IEEE Spectrum Online статья « Почему программное обеспечение не работает » исследует этот самый вопрос. Он суммирует основные моменты следующим образом:

• Нереалистичные или не сформулированные цели проекта
• Неточные оценки необходимых ресурсов
• Плохо определенные системные требования
• Плохо отчетность о состоянии проекта
• Неуправляемые риски
• Плохое общение между клиентами, разработчиками и пользователями
• Использование незрелых технологий
• Невозможность справиться со сложностью проекта
• Неаккуратные практики развития
• Плохое управление проектами
• Политика заинтересованных сторон
• Коммерческое давление

Различные программы

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

Крайние сроки

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

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

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

Даже с идеальными требованиями и связанными определениями слишком много разработчиков не знают то, что они делают.

Только посмотрели на типы вопросов, которые задают здесь. Вы перешли бы к доктору, который задал тот же эквивалентный вопрос. scarey вещь состоит в том, что они спрашивают и не знают, как учиться или рассуждать.

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

А лучшее измерение успеха проекта было бы - действительно ли пользователи счастливы? Это помогает бизнесу делать деньги? Как быстро будет полученная справка денег восстанавливать стоимость системы? Их более трудно измерить, чем простой план, все же.

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

Используя Виртуальную систему Досье ФБР это сводится к плохому управлению программой. Программа имела требования перед одиннадцатым сентября и ожидания после 11 сентября. Если бы правительственное управление сделало их задание то были бы модификации контракта.

http://government.zdnet.com/?p=2518

"Из-за открытого контракта с немногими гарантиями, SAIC пожинала больше чем $100 миллионов, поскольку проект стал больше и более сложным, даже при том, что его программное обеспечение никогда не работало правильно. Компания продолжала встречать запросы bureau’s, принимая платежи несмотря на ясные знаки, что подход FBI’s к проекту был плохо испорчен, по словам людей, которые были вовлечены в проект или позже рассмотрели его для правительства".

, Хотя 105 000 000$ для 700 000 строк кода доходит до 150$ на строку кода. Не слишком плохо.

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

, Но для проекта программного обеспечения намного более легко отменить все. Если мост или здание наполовину закончены, назад нет никакого пути. Половина инфраструктуры существует. Это очень видимо, и это берет деньги для удаления его.

Для проекта программного обеспечения можно нажать Shift-Delete, и никто не замечает.

Его просто очень трудная работа сделать точный анализ затрат.

Последняя статистическая величина, которую я слышал, была то, что 90% проектов или со временем или по бюджету. Таким образом, если Вы полагаете, что, перестав работать, выйдите из немного.

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

IT Project Failures - это блог о неудачах проекта, который может иметь несколько ответов здесь, если кто-то хочет прочитать об этом.

Сам я думаю, что большая часть этой проблемы связана с вопросом о возможности точно определить, что ожидается через x месяцев при $ y, когда на самом деле ответ гораздо более открытый. Например, если компания заменяет систему ERP или CRM, есть большая вероятность, что не будут выполнены все требования точно, и поэтому будут некоторые изменения, исправления ошибок и дополнения, которые появятся в результате принятия таких решений. большой проект. Для аналогии рассмотрим, сколько учеников, поступающих в среднюю школу или университет, могли бы указать свое точное расписание на все 4 года, не посещая никаких занятий, и фактически придерживаться этого в конце. Я думаю, что очень немногие делают это, поскольку некоторые люди меняют специальности или курсы, которые они хотели пройти, не предлагаются, или происходят другие вещи, которые изменяют ожидаемый результат, но как это отражено в плане проекта, который мы начали здесь, и пока мы Мы думали, что идем туда, и мы оказались на пятом месте.

Ссылка Construx выше очень хороша!

Многими проектами управляют на розовом изображении действительности. Менеджеры склонны приводить в действие, уговаривают разработчиков на оптимистические оценки. Но скажите, 20-недельные проекты "перекрикиваются" к 10 неделям. Фаза требований теперь составит 1 неделю вместо 2. После 1 недели не закончены требования, но проект идет дальше. Теперь Вы работаете над ненадежной основой - и в расширенном расписании!

Это может быть забавно. Однажды был этот старый парень в комнате противоположная шахта. Его должность была системой adminstrator. Но система, он предполагался к adminsiter, не была там. Это никогда не заканчивалось, хотя управление думало, что было. Парень играл в игры приблизительно в течение года, прежде чем он скучал и шел дальше.

самая забавная часть? Управление подняло новую вакансию после того, как он уехал!

Было проведено несколько хороших исследований по этому вопросу. Я рекомендую эту ссылку с веб-сайта Construx (компания Steve McConnells).

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

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

Люди/компании гордо не кричат об их отказах, столько привычки случаев быть когда-либо услышанными.

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

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

1111 Почему это не получается? Я думаю, что все просто: вы получаете то, за что платите.

1112 Программное обеспечение похоже на банковский счет, а не на изначальную слизь. Если вы не вкладываете в это ресурсы (время, деньги, сосредоточенность, усилия), вы не получите ничего из этого, кроме неудачи и затрат. Таким образом, вы должны вложить вещи в свой проект, и иногда самая ранняя работа закладывает основу на долгие годы. Вы не можете бросать грязь в свой компьютер и ожидать новой мыши через два года и 10 миллионов долларов спустя, поэтому также необходимо приложить усилия.

Одной из самых больших проблем сегодня являются «разработчики бюджета» в стране третьего мира. Я не завидую им их частью рынка, но для хорошо финансируемого стартапа Силиконовой долины, чтобы найти их и получить бюджетную основу (каркас или даже прототип), это сделать плохие инвестиции в будущее. Это та же самая бюджетная структура, которая сегодня доставляет моим друзьям много хлопот. Это работает сейчас; это работало, когда это было написано, но это не было написано хорошо, и немногие даже нашли время, чтобы поддержать это. Если бы компания остановилась и переписала программное обеспечение так, как оно должно было быть написано вначале , у них не было бы всей этой проблемы. Могут ли они позволить себе время? Нету. Они должны сделать это прибыльным, прежде чем они успеют об этом.

Итак:

• Не берите на себя то, что вы не можете себе позволить: время, деньги, усилия, сосредоточенность и т. Д.
• Не пропустите планирование!
• Не бойтесь переписать рано , когда это считается больше всего. (Позже это будет хуже, чем поездка к стоматологу, поверьте мне.)
• Не стоит недооценивать силу бюрократии, чтобы помешать вам сделать это правильно.
• И не будьте дешевы там, где вы должны проводить большую часть своего времени. Это будет стоить вам позже, гарантировано. А если не вы, тогда кто-то другой возьмет пулю за вас.

Неудача - это решение, на самом деле это скорее обвинение.

«Проект превысил бюджет и время более чем на 10%».

Какой бюджет? Какой график?

6 месяцев назад я написал план, в котором говорилось, что это займет 6 месяцев.

3 месяца назад пользователи просили больше вещей. Я дал им план, который сказал, что это займет еще 9 месяцев.

В прошлом месяце мне сказали, что проект превысил бюджет на 6 месяцев и, следовательно, «провал».

Но подождите. Он доставил то, что хотели пользователи. Это было над «оригинальной» оценкой. Это было под пересмотренной оценкой. Пользователи хотят больше. ЭТО хочет меньше.

Причина номер один: отказ управления проектами .

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

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

(С точки зрения программистов - я не менеджер проекта, но я часто участвовал в этом процессе).

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

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

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

Таким образом, неопределенные вещи увеличиваются, ясные вещи сводятся к минимуму, и то, что действительно убивает вас, - это то, что вы не думали, что будет неопределенным.

Это - потому что никто, кажется, больше не читает. Каждая причина, почему сбои проектов были проанализированы снова и снова. Только необходимо прочитать три книги для знания, почему 80% проектов перестали работать:

Крайний срок: Роман Об управлении проектами (Tom Demarco, опубликованный 1997) Это - большое введение, и это довольно интересно. Peopleware: Продуктивные Проекты и Команды (Tom Demarco, опубликованный 1987) Мифический Месяц Человека: Эссе по Разработке программного обеспечения (Fred Brooks, опубликованный 1975)

Мы как профессия просто, кажется, забываем все каждые 3-5 лет (см., что "централизованные вычисления неэффективны; позвольте клиентам обработать его" по сравнению с облачными вычислениями).

Честно, я думаю, потому что большинство программистов не очень хорошо в том, что они делают (и я не означаю просто проворачивать код). Люди на stackoverflow являются, вероятно, исключением. Я не знаю об остальной части Вас, но как программист консультанта/контракта я работал в или вокруг многих мест, и отношение посредственных или бедных программистов к хорошим - приблизительно от 10 до 1.

Одни из моих преимуществ всегда оценивали точно и затем поставляли вовремя и на или в соответствии с бюджетом - я всегда стремлюсь к прибытию в 10% под стоимостью и вовремя. Затем мне нравится говорить моему клиенту что, потому что я добился цели за меньшее количество $$, чем ожидалось, которые из "отдельно оплачиваемых предметов" хотели бы Вы включать?

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

Мой ответ довольно необычен по сравнению с остальным, но довольно часто встречается здесь: жуки-убийцы. У меня был проект на две дополнительные недели (50% дополнительного времени) из-за одного переключения в исходный код, о котором я не знал, пока не копался в исходном коде (в справке или в Интернете не было ничего задокументированного).

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

• Сиднейский оперный театр : с его изящными парусами, доминирующими над Сиднейской гаванью, Сиднейский оперный театр, возможно, является одним из самых узнаваемых зданий в мире. Тем не менее, с точки зрения управления проектом, это была впечатляющая неудача. Когда строительство началось в 1959 году, его стоимость оценивалась в 7 миллионов долларов, а на строительство потребовалось четыре года. Окончательно он был завершен в 1973 году за более чем 100 миллионов долларов.

  [...]

• Проект Орион : Эта масштабная работа по разработке новой фотографической системы Advantix от Kodak, по общему мнению, была очень хорошо организована с точки зрения управления проектом. PMI признал ее международным проектом 1997 года, а Business Week выбрал систему как один из лучших новых продуктов 1996 года (Adams, 1998). Но цена акций Kodak упала на 67% с момента внедрения системы Advantix, отчасти из-за того, что компания не смогла предвидеть ускоряющийся переход на цифровую фотографию.

• Корпоративный интранет : Финч описывает проект, который включал внедрение корпоративной интранет для глобализации и улучшения коммуникации. С традиционной точки зрения проекта он не соответствовал критериям успеха, но незначительно. Это произошло с опозданием на месяц и, как считается, было выполнено с небольшим перерасходом бюджета. Но и руководитель проекта, и высшее руководство сочли проект успешным. Аппаратное и программное обеспечение было успешно установлено с минимальными нарушениями работы, что позволило всем сотрудникам получить доступ к корпоративной внутренней сети. Однако после внедрения сотрудники лишь ограниченно использовали возможности интрасети. Таким образом, основная цель проекта не была достигнута. В этом случае и менеджер проекта, и высшее руководство сосредоточились на слишком узкой цели.

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

  [...]

• Оптимизация производственного предприятия : Компания по производству бумаги, имеющая пять заводов в Северной Америке, решила увеличить свои производственные мощности, приступив к программе устранения узких мест. Была сформирована проектная группа для установки необходимого оборудования, которой было поручено завершить работы за 18 месяцев, стоимость которых составила 26 миллионов долларов. Но почти сразу же команду проекта попросили отложить основные расходы до тех пор, пока не будет решена не связанная с этим проблема с денежными потоками. Вместо того, чтобы полностью прекратить работу, команда приняла стратегию прототипирования технологий, на которых была основана программа устранения узких мест, и фактически разработала несколько более дешевых и эффективных решений. Даже когда проект получил разрешение на продолжение, команда продолжила тот же подход. В итоге проект длился пять лет, но в результате увеличилась мощность в три раза по сравнению с первоначальным обязательством. Неудивительно, что компания немедленно выделила еще 40 миллионов долларов на продолжение программы.

  [...]

Итак, какие из этих примеров были действительно успешными? Примеры, такие как Зимние Олимпийские игры 2002 года и Медно-обогатительный комбинат в Бату-Хиджау, предполагают, что они действительно успешны, потому что они не только соответствовали традиционному определению успеха руководителей проектов, но и соответствовали восприятию успеха спонсорами проекта.

В начале посмотреть на примеры как Project Orion, корпоративный Интранет и обновление ноутбуков, мы обратите внимание, что традиционные метрики начать терпеть неудачу. Эти проекты считает успехи в проекте определение успеха менеджеров, но не удалось встретиться со спонсорами » критерий успеха. Проект Орион пример весьма поразителен, так как этот проект был признан PMI (Project Management International) в 1997 году как Международный проект года. Но это не увеличило доход, потому что они не предусмотрели внедрение цифровых фотоаппаратов.

Наиболее интересны примеры Оптимизация производственного предприятия и Сиднейский оперный театр. Они оба не удалось выполнить традиционный проект показатели успеха менеджеров, но были в факт считается успехом. Это особенно шокирует, когда вы видите что в Сиднейском оперном театре «перерасход 1300%» и «превышение графика на 250%».

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

Что вы думаете об этом заключении? Как вы действительно определяете успех?

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

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

http://www.clean-code-developer.de/ У них невероятная причина! и их философия, если продвигаться вперед, могла бы создать новый слой героев, поскольку основной поток разработчиков и ИТ-профессионалов в наши дни настолько гнилой.

Я работаю над чем-то похожим здесь, в Бразилии, потому что мне нравится наша профессия - воплощение программного обеспечения в жизнь, как PM, так и разработчика программного обеспечения (.NET), и я терпеть не могу людей, которые воспринимают программирование как ничто иное, как они чтобы заработать большие деньги почти без усилий.

... конечно, я не собираюсь останавливаться на ночь перед компьютерной гениальностью. но немногие значимые делали это не раз.