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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скучающие члены команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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