Каковы предупреждающие признаки надвигающейся гибели, на которую стоит обратить внимание в проекте? [закрыто]

66

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

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

  • смена руководства
  • недостаточно квалифицированная команда
  • появление превосходящего конкурента во время цикла разработки
  • над / под управлением

После того, как вы поработали над несколькими такими проектами, возможно ли на ранней стадии определить, когда проект обречен на провал?

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

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

ConroyP
источник
Роберт Гласс написал «Универсальный эликсир и другие вычислительные проекты, которые потерпели неудачу». Эта книга, опубликованная в 1977 году, представляла собой набор столбцов, которые он написал ранее, и каждый из них рассматривал проект, который провалился, в поисках причин неудачи. Книга делает ОТЛИЧНЫЙ список предупреждающих знаков.
Джон Р. Штром
Две статьи - « Патология проекта» и « Отчет о хаосе» . Дайте марш смерти хорошо читать , если вы после книги.

Ответы:

70

Героическое Кодирование

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

Fishtoaster
источник
12
Единственный повод для того, чтобы тянуть всю ночь, это обратиться к СПЕЦИАЛЬНОЙ проблеме за КОНКРЕТНЫЙ негибкий срок. Может быть, это только я, но код, который я пишу в три часа утра, когда я ворчливый и лишенный сна, имеет тенденцию выглядеть кроваво-отвратительным, увиденным в жестоком дневном свете.
BlairHippo
5
Ну, другое оправдание, что я студент. Плохое планирование проекта является нормой для курса. :)
Fishtoaster
20
О боже Колледж. Я помню, как сидел перед моим терминалом, когда взошло солнце, толкая *«и &» более или менее случайно перед переменными в моем коде C ++, в надежде, что эта чертова штука начнет работать. Я не скучаю по колледжу.
BlairHippo
2
Ранее в этом году у нас был такой проект - один парень регулярно работал до 2 часов ночи, а я начинал 4 часа утра. Однако мы выполнили свою работу, несмотря на нелепые временные рамки, наложенные на нас (мы были полны решимости завершить работу в установленные законом сроки) Мы все еще приводим в порядок и проводим рефакторинг сейчас!
Крис Бакетт
3
Я собираюсь подвергнуть опасности мою карму и указать, что «героическое кодирование» является запоздалым индикатором. Проекты попадают в беду задолго до того, как они достигают фазы, когда начинается «героическое кодирование». Обычно есть много ранних индикаторов проблем, которые появляются задолго до того, как кодирование начнется всерьез. К сожалению, они слишком часто игнорируются. Роберт Гласс много писал на эту тему в «Универсальном эликсире» и в других книгах. Игнорировать его на свой страх и риск.
Джон Р. Штром
44

Когда программисты начинают побеждать в аргументе «Код ужасен, нам нужно начинать все заново». на любом зрелом приложении.

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

Кроме того, однажды вам придется объяснить руководителю проекта, почему после 6 месяцев работы вы получаете почти до 85% возможностей и 150% ошибок, которые было в приложении при запуске.

оборота JohnFx
источник
9
Разве это не просто краткое изложение печально известного переписывания Netscape?
Jasarien
9
joelonsoftware.com/articles/fog0000000069.html
Джереми Хейлер
4
Я не согласен. Существует ряд опасностей для переписывания (например, синдром второй системы), но если вы знаете об этом, переписывание не более опасно, чем любой другой проект «зеленого поля».
nikie
4
Иногда вам нужно ампутировать и заменить что-то, что сделает приложение сильнее, лучше, умнее. Но ключевое слово здесь - ампутировать, а не убивать и воскрешать.
Эрик Реппен
2
Это может быть в значительной степени верно, но не строго верно. Я проходил такой проект около 9 месяцев назад, и он был успешным. Он потратил больше половины времени на разработку тестов, чтобы доказать, что это правильно и что старые / новые ошибки не были внесены в новую версию, и тем временем обнаружил кучу новых ошибок в существующей. (Хотя, я полагаю, это делает этот ответ верным как предупреждающий знак )
Изката
41

Новый инструмент для решения проблем.

Когда люди начинают планировать использовать незнакомые инструменты, я не против, но я присматриваю за этим. Когда они начинают планировать все объявленные преимущества этих инструментов в графике, я беспокоюсь. Веселые примеры:

  • Мы можем сократить график на месяц, потому что мы собираемся попробовать использовать объектно-ориентированный язык (хотя все, что у нас есть - разработчики).
  • Мы попробуем эту новую схватку, которая исправит все наши проблемы с процессом!
  • Я знаю, что это на полпути к проекту, но что если мы изменили ORM на что-то новое?

Новые технологии и практики хороши, но вы почти никогда не получаете всех преимуществ от ворот.

Fishtoaster
источник
3
Однажды я был в проекте, в котором было две вилки из-за двух интерфейсов - настольного и портативного гаджета. Оценки времени основывались на том, что мы можем использовать эти новые блестящие "EJB" вещи для повторного использования кода уровня модели между ними. К сожалению, база данных была настолько ужасным гнездом крысы, что все данные, извлеченные из нее, должны были быть получены из конкретных тщательно сконструированных SQL-запросов; полное заполнение бобов было бы слишком жестоким ударом по производительности. Когда оказалось, что (удивительно!) Версия для настольного компьютера требует больше данных, чем версия для портативного компьютера, график ушел прямо в ад.
BlairHippo
2
«Замечательно! Теперь, когда мы спасли среду модульного тестирования, мы можем начать сокращать время с этой продолжительной фазы контроля качества!»
Arkaaito
ха ха ха Отлично. +1 за новый инструмент решит все мои проблемы.
fast_now
40

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

Так в основном; Нет письменных требований

Это поцелуй смерти.

Джон Макинтайр
источник
3
Или хуже, письменные требования, которые никто не читает. На самом деле, я был в проектах, где были написаны обширные требования, и они никогда не предъявлялись программистам.
JohnFx
1
@ Adolf Garlic - Письменные требования не обеспечат вас по времени или по бюджету, но вы никогда не будете соответствовать ожиданиям, если ожидания не будут озвучены, не будут закреплены все серые области и будут постоянно меняться (ваши мысленные идеи будут меняться ).
Джон Макинтайр
5
Однажды я попросил бизнес-аналитика сказать, что требования не нужны. Какова снова работа бизнес-аналитика? Ах да, чтобы написать требования! Мы бы получили такие требования, как сделать эту работу, как это делает hkjk.com.
HLGEM
1
Если вы разрабатываете для индивидуального продукта для одного клиента, конечно. Но если вы пишете следующую версию Powerpoint или следующую версию собственной системы программного обеспечения, я не вижу в этом смысла. Вы всегда будете больше узнавать о требованиях во время разработки (например, что некоторые требования бесполезны, а другие неосуществимы). Я бы лучше использовал эти знания и изменил требования в процессе разработки, чем выпуская некачественный продукт.
nikie
1
@nikie - я не говорю, что требования должны быть статичными и никогда не изменяться. Я говорю, что вы должны записать это, чтобы предотвратить неправильное общение и предотвратить изменение идей в голове людей с течением времени. Если требования должны измениться, измените их, но сохраните текущие требования записанными. Имеет ли это смысл?
Джон Макинтайр
33

Отключение управления

Когда ответственные за сроки, функции, персонал и т. Д. Отсоединяются от людей, ответственных за реализацию проекта. Это может привести к:

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

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

Fishtoaster
источник
+1 за ваш первый предмет. Я был клиентом в сценарии, о котором вы упомянули, и он плох для всех (никто не хочет неожиданный счет, и никто не хочет спорить о его оплате).
fearoffours
+1 аминь. Будучи там, сделал это, не хочу снова оказаться в таком положении.
Эван Плейс,
+1 за то, что я живу со всеми этими пулями (кроме, может быть, 4-го).
AShelly
Отличный ответ. Даже если вы не удосужились уточнить, и просто поставите «Отключение управления», ваш ответ стоил бы +10.
Джим Г.
25
  1. Когда ключевые разработчики уходят, а менеджменту все равно

  2. Когда ключевые разработчики уходят, и ни один из других разработчиков не заботится

Номер один обычно указывает на менеджеров, которые сильно оторваны от динамики команды (кто является «10-кратной суперзвездой», кто приличные программисты, как они взаимодействуют друг с другом и т. Д.).

Номер два обычно указывает на серьезное отсутствие интереса со стороны остальных разработчиков.

MrDatabase
источник
24

Первый раз, как правило, кто-то говорит: «У нас нет времени на…».

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

Mawg
источник
8
есть ссылка на это? было бы здорово использовать боеприпасы ...
Алекс Фейнман
1
Назовите это «первым законом управления программным обеспечением
Мога
1
@ Алекс Фейнман: IIRC Code Complete содержит множество ссылок на подобные статистические данные.
nikie
21

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

Mawg
источник
Благодарю. Всегда помните, вы можете сделать это быстро, дешево или работать ... выбирайте любые два
Mawg
21

Когда менеджмент слишком слаб, чтобы сказать «нет» бизнесу.

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

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

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

Еще один верный признак того, что приближается неудача, - это назначать новых разработчиков на самую сложную, самую критическую часть процесса, а не на людей, которые уже понимают текущую систему. Затем не следите за ними внимательно, чтобы увидеть, действительно ли они выполняют свою работу должным образом или у них есть вопросы (БОЛЬШОЙ БОЛЬШОЙ КРАСНЫЙ ФЛАГ, если вопросов нет). Новые сотрудники должны подвергаться мониторингу, пока вы не узнаете, что они действительно обладают навыками, которые, как они утверждали, были. Я до сих пор помню, как провел одно болезненное лето, переделывая работу (уже истек срок, когда я ее получил) нового сотрудника, который получил критическую часть проекта и сказал всем, что все было хорошо в течение нескольких месяцев, а затем ушел без уведомления через неделю после указанного срока. и ничто из того, что он делал, не годилось для использования.

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

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

HLGEM
источник
Да, новости улучшаются по мере их продвижения :)
Ганс Вестербик
18

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

Вальтер
источник
6
Однажды у меня был менеджер, который хотел привлечь в проект интерфейсного веб-кодера (правильное решение), но из-за того, что кто-то еще в проекте давно заболел, ему захотелось написать в контракте с новым парнем, что ему не разрешили заболеть.
Джон Хопкинс
1
@Jon - Это грустно ... смешно, но очень грустно!
Уолтер
16

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

GrandmasterB
источник
16

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

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

user281377
источник
1
Самые высокие показатели оборота, которые я видел, были на двух проектах. Один был стабильным проектом, который продолжал развиваться, а другой был известным обреченным проектом в банке. Я никогда не был так счастлив быть безработным, как эти двое.
Дэвид Торнли
11

Вы "на 90% готовы", доставка на следующей неделе, но это нормально, потому что все, что у вас осталось, это "тестирование".

Скотт Уитлок
источник
2
Кажется очень смешным, когда ты это говоришь. Случилось со мной, хотя. В то время это было не смешно.
+1000 происходит там, где я все время работаю T_T
Сонго
1
Забавно, что в каждом графике тестирование является последним шагом, как будто тестирование не обнаружит никаких ошибок. Если нет, зачем беспокоиться о тестировании?
JohnFx
Не волнуйтесь, «клиент проверит это для нас» :-(
Mawg
10
  • Все физически и умственно истощены
  • Клиенты / пользователи явно недовольны временными рамками или тем, что они видят
  • Первоначально красивый дизайн теперь чувствует себя скомпрометированным
  • Вы отказались от доставки с некоторыми относительно существенными ошибками, которые вы бы действительно исправили, но не сможете
  • Вы остаетесь гордостью в акте доставки, а не в том, что вы отправляете - ближе к менталитету выживших, чем к профессиональной гордости
  • Команда боится, что есть определенные вещи, которые не работают, игнорируют эти разделы и надеются на лучшее, потому что боятся того, что может быть там.
  • Все убеждены, что они сделали все возможное (и они правы)
  • Люди проявляют признаки выгорания (общий пессимизм, незаинтересованность, гнев)

(Из статьи Джима Маккарти « Динамика разработки программного обеспечения» ).

Джон Хопкинс
источник
+1 за «Вы остаетесь гордостью за акт доставки, а не за доставку». Это так верно (хотя я видел это только в моих менеджерах. Мы, разработчики, знали, что вышло за дверь ... первыми ногами)
10

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

оборота Mawg
источник
Что за ковбой кодер?
Creative Magic
Википедия - твой друг en.wikipedia.org/wiki/Cowboy_coding
Mawg
Не знал, что это термин, спасибо! Уэлп, я возвращаюсь к своему ранчо ...
Creative Magic
9

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

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

оборота ChrisF
источник
6
В водопаде нет ничего плохого, если его правильно использовать. К сожалению, он никогда не используется правильно :)
чеснок
@adolf - я думал об одном проходе через водопад. Несколько мини-водопадов, вероятно, в порядке.
ChrisF
По моему, Agile - это просто серия водопадов. Очень немногие могут сделать водопад правильно,
эрг
@mawg - моя точка зрения была о том, что одна длинная итерация плохая, тогда как серия коротких итераций (как бы они ни управлялись) лучше.
ChrisF
1
Напоминает мне о проекте по разработке электронных вещей, в которых нет прототипов, намеченных в ... Верный признак надвигающейся катастрофы.
quick_now
9

Разработчики Бегут без ума от диапазона

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

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

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

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

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

У премьер-министра даже хватило смелости прилететь на CDR (Critical Design Review) только для того, чтобы прервать встречу с клиентом и закипеть. Когда он потребовал оплатить его путевые расходы в рамках проекта, ему вежливо сказали прелюбодействовать.

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

Эван Плейс
источник
8

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

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

Когда предметы на критическом пути делаются одновременно, а не по порядку. (Если мне потребуется использовать инструмент X, а программист A только начинает его собирать, моя задача будет отложена.)

Когда менеджеры передают код на День Благодарения.

Когда вы начинаете получать электронные письма с отметкой даты и времени позже 11 часов вечера и ранее 6 часов утра.

Когда на каждый вопрос о том, как справиться с какой-то сложностью встречается один и тот же ответ: «Не беспокойся об этом пока».

Когда они все еще вносят изменения в день, вы переходите в QA или запускаете.

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

Когда команда базы данных и команда приложения не общаются друг с другом.

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

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

HLGEM
источник
2
Ключевым моментом в вашем первом абзаце является то, что, если руководство делает это, сроки, вероятно, уже обречены, а бонусы недостижимы.
Дэвид Торнли
1
@ Дэвид Торнли, да, это именно так.
HLGEM
6

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

Ключ, однако, заключается в том, чтобы заранее определить неудачный проект. Я думаю, что единственным реальным «признаком гибели» в этом случае будет полное отсутствие определения «когда мы закончим». Если мы не знаем это по смещению, мы обречены на провал ИМО.

Яко Преториус
источник
1
ака "определение выполнено", по согласованию с ИТ и бизнесом
Адольф Чеснок
6

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

  • Компания решает, чтобы младшие разработчики проектировали и разрабатывали новые функции, и назначает более дорогих старших разработчиков, чтобы исправить их ошибки.
  • Компания передает сторонним поставщикам критически важные программные компоненты, которые не обладают необходимыми знаниями в этой области.
  • Циклы времени кризиса настолько сближаются, что здоровье людей рушится.
  • Таблетки, которые ведет ваша команда, заставляют самому спать каждую ночь, чтобы он не работал.
  • Клиент отправляет заказы на изменения быстрее, чем вы можете их проанализировать.
  • Вы должны выполнить несколько лет работы за несколько недель, но руководство отказывается заморозить функцию.
  • У ваших поставщиков оборудования явно возникают проблемы с доставкой работоспособного продукта в срок, и лица, принимающие решения в вашей компании, не будут рассматривать какие-либо альтернативы.
  • Разработчики прототипов устройств нуждаются в том, чтобы у них был шанс встретиться с вероятным нереалистичным графиком, который убирают и дают топ-менеджерам, чтобы они чувствовали себя хорошо.
  • Первая неделя: «О, дерьмо, код содержит ошибки. Все перестают делать новые функции и исправляют ошибки». Неделя вторая: «О, дерьмо, мы не собираемся соблюдать график функций. Все прекращают исправлять ошибки и писать новые функции». Повторяйте до бесконечности.
  • Разработка ведется в одной стране, а контроль качества - в другой стране, на полпути по всему миру, поэтому для получения сообщения об ошибке всегда требуется 24 часа, и хотя бы один из участников обсуждает сложные технические проблемы. на языке, которым они не владеют.
Боб Мерфи
источник
Я бы дал тебе миллион за этот последний пункт.
HLGEM
5

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

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

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

Vaccano
источник
5

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

  • Абсурдно грандиозные цели . Например, «принципиально переосмыслите способ работы людей с компьютерами».
  • Совершенно нереальные сроки . Обычно это происходит потому, что они считают, что могут переписать исходную кодовую базу гораздо, гораздо меньше времени, чем первоначально требовалось.
  • Нереалистичные представления о совместимости . Как и вера, вы можете переписать и сохранить все маленькие причуды без каких-либо дополнительных усилий.
  • Всегда «шесть месяцев» от основного срока, который, кажется, никогда не наступит . Или, если это произойдет, еще один этап добавляется в конце проекта, чтобы компенсировать.
  • Должен потреблять огромное количество ресурсов . Обычно высасывая кровь из одного или нескольких известных продуктов.
  • Вовлечение с использованием совершенно новых технологий, которые еще не были доказаны . Таким образом, они избавляются от всех проблем масштабируемости с помощью новой технологии.
Крис Смит
источник
4

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

Я еще не слышал, чтобы менеджер сказал что-то подобное, и чтобы это не оказалось ложью.

Джейсон Бейкер
источник
Lolx! Это точно; Встреча "Вы, возможно, слышали rumo (u) rs ...").
Mawg
4

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

  • Управление удваивает команду, чтобы закончить быстрее.
  • разработчики начинают «хоронить» ошибки, чтобы уложиться в сроки, и, хотя это очевидно, это игнорируется при проверке кода.
OKAN
источник
3

Когда руководство одновременно тянет проект в разные стороны и вагон остается на месте.

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


источник
LOL, я работала над исследованием рабочей силы таким образом, хотя это было еще хуже, поскольку оба лидера пытались завязать роман с одной и той же женщиной. Если Билл сказал «да», то Боб сказал «нет», и наоборот, худший проект, над которым я когда-либо работал. Я умолял меня переназначить.
HLGEM
3

Смотрите эту краткую статью: Когда ИТ-проекты идут правильно .

Отсутствие какого-либо из элементов, указанных в статье, должно вызывать сигнал тревоги:

Поэтому убедитесь, что ваш проект имеет все следующее, если нет, то вы должны быть обеспокоены:

(процитировать вышеупомянутую статью :)

  1. «Во-первых, они основаны на четком видении того, что должно быть достигнуто».

  2. «Вторая характеристика касается поддержки и приверженности различных сторон, вовлеченных в бизнес, особенно высшего руководства».

  3. «В-третьих, это понимание проблем, которые необходимо решить».

  4. «Последняя общая характеристика заключается в том, что были предоставлены достаточные ресурсы и навыки».

therobyouknow
источник
Отличная статья! Мне нравится подход «когда дела идут хорошо».
user8865
3

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

Ницан Вакарт
источник
1
Я думаю, что это статистика запуска, а не общая статистика проекта программного обеспечения.
Эрик Реппен
2
Вот одна ссылка, случайно взятая в Google, которая, кажется, предполагает, что она не ограничивается стартапами. Также см. Превосходное Rapid Development г-на Макконнела для получения дополнительной информации по этой теме.
Ницан Вакарт