Работа над неудачным проектом - одна из немногих общих черт программистов, независимо от используемого языка, отрасли или опыта.
Эти проекты могут быть отличным опытом обучения, душераздирающими бедствиями (или обоими!) И могут происходить по множеству причин:
- смена руководства
- недостаточно квалифицированная команда
- появление превосходящего конкурента во время цикла разработки
- над / под управлением
После того, как вы поработали над несколькими такими проектами, возможно ли на ранней стадии определить, когда проект обречен на провал?
Для меня большой знак - жесткий и быстрый внешний крайний срок в сочетании с ползучестью . Я видел проекты, которые были хорошо спланированы и выполнялись точно по графику, ужасно сходили с рельсов, как только начали поступать запоздалые запросы о функциях, и их добавили к окончательному «результату». Авторы этих запросов получили прозвище Коломбо из-за того, что редко выходили из комнаты, не прося «просто еще одной вещи».
Какие предупреждающие знаки, на которые вы обращаете внимание, вызывают тревогу надвигающейся гибели в вашей голове?
источник
Ответы:
Героическое Кодирование
Программирование до поздней ночи, долгие часы работы и много сверхурочных часов - верный признак того, что что-то пошло не так. Кроме того, мой опыт показывает, что если вы видите кого-то, кто работает допоздна в какой-то момент в проекте, это только ухудшается. Он может делать это только для того, чтобы вернуть свою единственную функцию в срок, и он может добиться успеха; однако, ковбойское кодирование, подобное этому, почти всегда является результатом неудачи планирования, которая неизбежно вскоре вызовет еще больше. Итак, чем раньше в проекте вы это увидите, тем хуже будет со временем.
источник
*
«и&
» более или менее случайно перед переменными в моем коде C ++, в надежде, что эта чертова штука начнет работать. Я не скучаю по колледжу.Когда программисты начинают побеждать в аргументе «Код ужасен, нам нужно начинать все заново». на любом зрелом приложении.
Вы можете подумать, что можете построить его лучше или лучше понять проблему, но на самом деле это не так. Ох, и все эти уродливые патчи? Они являются исправлениями для реальных проблем, которые вы, вероятно, будете повторно вводить при переписывании.
Кроме того, однажды вам придется объяснить руководителю проекта, почему после 6 месяцев работы вы получаете почти до 85% возможностей и 150% ошибок, которые было в приложении при запуске.
источник
Новый инструмент для решения проблем.
Когда люди начинают планировать использовать незнакомые инструменты, я не против, но я присматриваю за этим. Когда они начинают планировать все объявленные преимущества этих инструментов в графике, я беспокоюсь. Веселые примеры:
Новые технологии и практики хороши, но вы почти никогда не получаете всех преимуществ от ворот.
источник
Для меня самая большая проблема, которую вы можете заметить сразу же, это когда бизнес рассматривает письменные требования как пустую трату времени.
Так в основном; Нет письменных требований
Это поцелуй смерти.
источник
Отключение управления
Когда ответственные за сроки, функции, персонал и т. Д. Отсоединяются от людей, ответственных за реализацию проекта. Это может привести к:
Поэтому, когда кажется, что руководство не заинтересовано в проекте, плохо общается, не слушает клиентов или не слушает команду разработчиков, бегите за холмами.
источник
Когда ключевые разработчики уходят, а менеджменту все равно
Когда ключевые разработчики уходят, и ни один из других разработчиков не заботится
Номер один обычно указывает на менеджеров, которые сильно оторваны от динамики команды (кто является «10-кратной суперзвездой», кто приличные программисты, как они взаимодействуют друг с другом и т. Д.).
Номер два обычно указывает на серьезное отсутствие интереса со стороны остальных разработчиков.
источник
Первый раз, как правило, кто-то говорит: «У нас нет времени на…».
Обычно предшествует чему-то, чего у нас нет времени, например документации или обзорам кода (которые статистически находят и исправляют больше ошибок, чем что-либо еще, включая все формы тестирования)
источник
Позвольте клиенту, маркетингу или руководству выбрать дату, а затем попытаться вернуться к воображаемому графику
источник
Когда менеджмент слишком слаб, чтобы сказать «нет» бизнесу.
Это приводит к крайним срокам, которые никогда не будут соблюдены, что приводит к неуверенности в ИТ-отделе, что приводит к тому, что разработчики создают хаки (то есть доступ к базе данных, работающий на чьей-то машине ... где-то), что приводит к кошмару для ИТ, когда ' критическая система »должна быть перенесена, что приводит к ...
источник
Первый плохой признак, о котором я могу подумать, - это когда руководство не желает передавать плохие новости по цепочке или клиенту в надежде на то, что оно исчезнет - то есть управление с помощью желаемого мышления. Я не могу вспомнить, сколько раз разработчики доказывали, что они не могут уложиться в сроки, которые могут быть неделями или даже месяцами раньше, и все же никто не хочет говорить клиенту. Я редко видел клиента, который не стал бы сдвигать крайний срок, когда есть реальная причина, когда необходимость объясняется заранее; Я часто видел разозленного клиента, когда ему говорили в день окончания срока, что он не будет выполнен и что его не встретят и на следующий день, но через два месяца в будущем. На данный момент они, справедливо могу добавить, ставят под сомнение ваши процессы - почему вы не знали этого раньше.
Еще один верный признак того, что приближается неудача, - это назначать новых разработчиков на самую сложную, самую критическую часть процесса, а не на людей, которые уже понимают текущую систему. Затем не следите за ними внимательно, чтобы увидеть, действительно ли они выполняют свою работу должным образом или у них есть вопросы (БОЛЬШОЙ БОЛЬШОЙ КРАСНЫЙ ФЛАГ, если вопросов нет). Новые сотрудники должны подвергаться мониторингу, пока вы не узнаете, что они действительно обладают навыками, которые, как они утверждали, были. Я до сих пор помню, как провел одно болезненное лето, переделывая работу (уже истек срок, когда я ее получил) нового сотрудника, который получил критическую часть проекта и сказал всем, что все было хорошо в течение нескольких месяцев, а затем ушел без уведомления через неделю после указанного срока. и ничто из того, что он делал, не годилось для использования.
Другой верный признак неудачи - это когда разработчики работают над частями, которые зависят от того, что делается в первую очередь, а эти вещи не выполняются или даже не запускаются. Если руководство не может назначить работу в правильном порядке, вы спускаетесь по трубам.
Конечно, функция «ползучести», не отодвигающая крайний срок каждый раз, является одним из самых распространенных признаков того, что дела пойдут плохо. Вы добавляете 20 часов работы к моей тарелке, срок сдвигается на 20 часов. Если этого не произойдет, проект потерпит неудачу, гарантировано.
источник
Один верный признак, который я видел в своей карьере, - это когда руководство начинает говорить о привлечении большего количества тел, чтобы составить время в расписании. Я на самом деле никогда не видел больше тел на помощь проекта.
источник
Когда нетехнические менеджеры начинают настаивать на принятии технических решений, которые они никоим образом не могут принять. Большой, большой красный флаг!
источник
Самый очевидный признак - высокая текучесть кадров. Когда все ищут новую работу, вы, вероятно, тоже должны.
Другой очень очевидный признак - отсутствие прогресса. Если прошел год, и кажется, что вы не ближе к цели, вы обречены. Это происходит, особенно когда требования изменяются быстрее, чем вы можете их реализовать.
источник
Скучающие члены команды.
источник
Вы "на 90% готовы", доставка на следующей неделе, но это нормально, потому что все, что у вас осталось, это "тестирование".
источник
(Из статьи Джима Маккарти « Динамика разработки программного обеспечения» ).
источник
Ковбойские кодеры, большие эго и принятие их руководством
источник
Если план проекта предусматривает одну итерацию проектирования, разработки, тестирования и развертывания - классический водопад - для проекта, продолжающегося более 1 месяца, я бы пробежал милю.
Вам не нужно быть полностью гибкими, но короткие циклы разработки позволяют продемонстрировать прогресс каждому (клиенту, руководству и самим разработчикам) и справиться с изменившимися требованиями, когда это неизбежно произойдет.
источник
Разработчики Бегут без ума от диапазона
Это произошло, когда вы поняли, что другие разработчики (или, к сожалению, вы) разработали компонент, который значительно отличается от проекта, и что он не подхвачен до тех пор, пока не начнется тестирование системы / UAT. Я не говорю об ошибках; Я говорю о значительных системных компонентах, которые не имеют функций или не требуют функциональности и никогда не пройдут UAT без значительных переделок. Эта проблема указывает на то, что:
источник
Когда ключевой разработчик проекта не проверял какой-либо код в течение нескольких недель, и наступает серьезная веха.
Это была работа по контракту, и более опытный разработчик и премьер-министр решили, что они хотят объединиться, чтобы попытаться добиться большего, поэтому другой разработчик удерживал 3 недели в качестве заложников критического кода. В конце концов, мы уволили некомпетентного премьер-министра (который потратил 6 месяцев на подготовку проекта к разрушению) и поговорили с разработчиком.
Достаточно сказать, что остальная часть проекта была мазохистским маршем смерти, замораживание спецификаций было отложено, клиенту дали кучу льготных функций, чтобы компенсировать ужасное планирование, которое PM покинул, и качество проекта пострадало. все вокруг из-за этого.
У премьер-министра даже хватило смелости прилететь на CDR (Critical Design Review) только для того, чтобы прервать встречу с клиентом и закипеть. Когда он потребовал оплатить его путевые расходы в рамках проекта, ему вежливо сказали прелюбодействовать.
Я могу легко идентифицировать по крайней мере с 5 из других ответов, найденных здесь, которые повлияли на этот проект. Короче говоря, я усвоил много тяжелых уроков в своем первом серьезном проекте по программированию.
источник
Моим первым знаком был один, когда они спросили, сколько сверхурочных часов каждый из нас выделит на следующие десять недель, и предложили наемным работникам бонус за сверхурочную работу в зависимости от успеха проекта и соблюдения сроков.
Другие основные признаки, которые я видел: определение требований идет по графику, а дата окончания не переносится. Мы были позади, прежде чем мы могли даже начать. Они отняли время у проектирования, поэтому мы начали с разработки базы данных и дизайна сайта, но ожидали, что они будут выполнены вовремя, в том числе путем импорта таблиц, которые еще не были разработаны и созданы.
Когда предметы на критическом пути делаются одновременно, а не по порядку. (Если мне потребуется использовать инструмент X, а программист A только начинает его собирать, моя задача будет отложена.)
Когда менеджеры передают код на День Благодарения.
Когда вы начинаете получать электронные письма с отметкой даты и времени позже 11 часов вечера и ранее 6 часов утра.
Когда на каждый вопрос о том, как справиться с какой-то сложностью встречается один и тот же ответ: «Не беспокойся об этом пока».
Когда они все еще вносят изменения в день, вы переходите в QA или запускаете.
Когда вы начинаете проводить ежедневные встречи, которые занимают несколько часов, чтобы обсудить ваше отсутствие прогресса. О, это было бы потому, что я весь день на собраниях. Ежедневная 5-минутная встреча в порядке, ежедневная встреча, которая длится более часа, не в порядке.
Когда команда базы данных и команда приложения не общаются друг с другом.
Когда клиент не может предоставить обещанную информацию вовремя. Особенно, когда это файлы импорта данных, и вам нужны эти данные в базе данных, чтобы проверить, как работает код.
Когда вы подумываете об установке стоп-сигнала возле офиса какого-то менеджера, чтобы сообщить, безопасно ли приближаться к нему в тот день
источник
Я думаю, что обычно легко обнаружить провальный проект, когда приближается крайний срок. Как вы уже сказали, крип функции в сочетании с установленным сроком - это верный способ убить проект.
Ключ, однако, заключается в том, чтобы заранее определить неудачный проект. Я думаю, что единственным реальным «признаком гибели» в этом случае будет полное отсутствие определения «когда мы закончим». Если мы не знаем это по смещению, мы обречены на провал ИМО.
источник
Я был в трех маршах смерти за последние пять лет. Вот несколько вещей, которые помогли мне почувствовать надвигающуюся гибель.
источник
Для меня это когда те, кто отвечает за набор функций (то есть менеджеры, владельцы продуктов, клиенты ...), перестают заботиться или, кажется, безнадежно относятся к своим ответам. Вопросы об особенностях встречаются с апатией и унынием. Понятно, что они потеряли инвестиции или доверие к проекту.
Это случилось для меня, когда в проекте, в котором я участвовал, произошла «смена руководства». Я задавал вопросы о том, как это должно работать, и вдруг ни у кого не было реального мнения.
Некоторое время спустя проект был отменен, и весь красивый код, который я написал, был свернут.
источник
Пол Вик написал отличный пост несколько лет назад о проектах черной дыры . Я думаю, что все советы актуальны. (Я отредактировал пункты и резюме для длины.)
источник
Я мысленно перевожу: «Все хорошо. Нам не о чем беспокоиться». на «Мы все облажались» каждый раз, когда я слышу, как это говорит руководство. Обычно вы слышите, как менеджеры добавляют это случайно на несвязанных собраниях («Да, кстати, все идет хорошо. Нет причин для беспокойства!»), Но это еще больший красный флаг, когда собрание специально назначается, чтобы сказать это.
Я еще не слышал, чтобы менеджер сказал что-то подобное, и чтобы это не оказалось ложью.
источник
пара моментов из мертвого проекта, частью которого я был:
источник
Когда руководство одновременно тянет проект в разные стороны и вагон остается на месте.
Однажды я был вовлечен в проект, которым руководили два парня. Либо они не разговаривали друг с другом, либо у каждого есть какое-то эго, которое нужно разрешить, но они направляли нашу работу в противоположную сторону примерно каждую неделю или около того. Не заняло много времени, чтобы понять, что никогда не будет никакого результата. С удовольствием мое участие длилось всего несколько месяцев.
источник
Смотрите эту краткую статью: Когда ИТ-проекты идут правильно .
Отсутствие какого-либо из элементов, указанных в статье, должно вызывать сигнал тревоги:
Поэтому убедитесь, что ваш проект имеет все следующее, если нет, то вы должны быть обеспокоены:
(процитировать вышеупомянутую статью :)
«Во-первых, они основаны на четком видении того, что должно быть достигнуто».
«Вторая характеристика касается поддержки и приверженности различных сторон, вовлеченных в бизнес, особенно высшего руководства».
«В-третьих, это понимание проблем, которые необходимо решить».
«Последняя общая характеристика заключается в том, что были предоставлены достаточные ресурсы и навыки».
источник
Статистически запуск программного проекта - это верный признак того, что он потерпит неудачу, как это делает подавляющее большинство из них ...
источник