Почему сегодня многие проекты программного обеспечения терпят неудачу?

Question

Пока существуют программные проекты, мир задается вопросом, почему они так часто терпят неудачу.

Я хотел бы узнать, есть ли список или что-то подобное, что показывает, сколько программных проектов сегодня не работает. Было бы неплохо, если бы было сравнение за последние 20-30 лет.

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

EDIT: Практически невозможно четко определить термин «сбой». Предположим, что сбой означает: проект был более 10% от бюджета и времени. По моему мнению, 10% +/- хороший диапазон для предложения/тендера.

EDIT: До сих пор (11 февраля) кажется, что большинство плакатов согласны с тем, что отказ проекта в основном является провалом управления проектами (независимо от того, что означает отказ). Но ИМХО это выходит, что большинство разработчиков не довольны этой ситуацией. Может быть, потому, что менеджер не наказывается, когда проект не увенчался успехом, но ленивые, некомпетентные команды разработчиков?

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

Я спрашиваю себя: как мы можем улучшить его? Или у нас есть возможность его улучшить? Кажется, что все не удовлетворены тем, как это происходит сейчас. Можем ли мы закрыть разрыв между этими двумя мирами? Должны ли мы (разработчики) объявлять забастовку и бороться за «высокие требования к качеству» и «реалистичные/итерационные периоды времени»?

EDIT: Ральф Вестфаль и Стефан Lieser основали новое "сообщество" под названием: Clean-Code-Developer. Цель группы - повысить профессионализм в разработке программного обеспечения. Независимо, если у разработчика есть степень или многолетний опыт, вы можете быть частью этого движения.

Чистый код Разработчики живут в соответствии с принципами , как SOLID каждый день. Профессиональный разработчик является крупнейшим рецензентом собственной работы. И у него есть внутренняя система ценностей , которая помогает ему улучшаться и стать лучше.

Проверьте это на: Clean Code Developer

EDIT: Наша компания делает в данный момент вещь под названием «Разработка приложений и техническое обслуживание бенчмаркинг». Это сервис, предлагаемый IBM для получения отзывов от кого-то внешнего по качеству вашего программного обеспечения и т. Д. Когда мы получим результаты, я расскажу вам больше об этом.

Answer 1

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

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

Answer 2

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

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

Другой IEEE Spectrum Online статья "Why Software Fails" рассматривает этот вопрос. В нем обобщаются основные моменты следующим образом:

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

Hofstadter's Law

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

Answer 8

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

Answer 9

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

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

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

Хотя $ 105 000 000 для 700 000 строк кода составляет 150 долларов США за строку кода. Не плохо.

Answer 10

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

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

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

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

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

Answer 11

Несовершеннолетние.

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

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

Answer 12

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

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

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

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

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

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

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

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

Answer 13

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

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

Answer 14

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

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

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

Answer 15

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

The Deadline: Роман об управлении проектами (Том Демарко, опубликованный в 1997 г.) Это большое введение и это довольно интересно. Кадровое Продуктивные проекты и команды (Том Демарко, опубликованные 1987) Мифический человеко-месяц: Очерки по инженерии программного обеспечения (Фред Брукс, опубликованной в 1975 году)

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

Answer 16

Неспособность - это суждение - скорее обвинение, действительно.

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

Какой бюджет? Какое расписание?

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

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

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

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

Answer 17

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

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

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

Answer 18

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

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

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

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

Answer 19

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

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

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

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

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

Как говорится, «Я могу сделать это: дешево, быстро или хорошо. Теперь выберите любые два из них». Все хотят всех троих, включая меня. Но если вы не инвестируете время, планирование и , то работайте, чтобы сделать ваш проект успешным с самого начала ... тогда не ожидайте ничего, чем вы можете гордиться позже. Будет чувствовать себя подделанной Моной Лизой, где вы и любой другой инженер, как и вы, можете увидеть дефект здесь и там, который не должен был быть с самого начала.

Итак:

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

Answer 20

Проведено хорошее исследование. Я рекомендую this link с сайта Construx (компания Steve McConnells).

Answer 21

Ссылка на Construx выше, это действительно хорошо!

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

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

Самая забавная часть? Менеджмент открыл новую работу после того, как он ушел!

Answer 22

Различных повестки

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

Сроки

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

Answer 23

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

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

Answer 24

Будучи над бюджетом и временем, не является хорошим определением неудачи (и фактически быть в бюджете и времени не всегда означает успех). Возьмите следующие примеры, представленные Хью Вудворд, PMP, в Expert Project Management - Project Success: Looking Beyond Traditional Project Metrics:

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

  [...]

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

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

  [...]

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

  [...]

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

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

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

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

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

Answer 25

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

Answer 26

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

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

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

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

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