Я являюсь разработчиком в команде из 5 человек и считаю, что наш проект движется к катастрофе. Я сейчас опишу почему, но мой вопрос: как мне себя вести?

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

Что мне делать в этом случае? Должен ли я приложить дополнительные усилия, или я должен просто успокоиться? А что мне сказать менеджеру?

Причины, по которым этот проект обречен на провал:

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

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

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

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

Сделав это, продолжайте добросовестно работать над проектом.

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

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

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

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

Я рекомендую вам уделить немного времени чтению 2 книг.

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

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

3 простые и циничные стратегии для поддержания карьеры / здравомыслия.

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

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

3. План аварийного выхода на Т + 1: предоставьте себе несколько вариантов и подготовьте почву для потенциальной внутренней или внешней передачи сейчас. Разговаривать с людьми; нет никакой причины ждать, пока другие решат, что делать с вами, когда финансирование проекта будет сокращено или погрязнет в неизбежной «давке» людей, мигрирующих через пару месяцев.

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

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

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

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

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

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

По сути, сумма опыта, извлеченного из неудач, является тем, что питает истинный успех.

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

1) Сосредоточьтесь на личном превосходстве - стремитесь писать все более качественный код, соответствовать все более высоким стандартам качества и функциональности.

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

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

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

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

Кроме того, вам действительно нужно присматривать за номером 1.

• Документ все
• сохраняйте все электронные письма, чаты
• Попробуйте найти выход из проекта, если это все возможно

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

Это все относительно перспективы.

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

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

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

Вам необходимо определить, что это за проблемные элементы, и решить их.

• крайний срок давления
• контроль качества
• профессионализм
• руководство со стороны руководства

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

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

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

Вы будете намного счастливее.

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

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

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

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

1) Делай свою работу. Не беспокойтесь о проекте в целом, пока выполняете свои обязанности.

2) CYA. Если проект потерпит неудачу, и вы подозреваете, что менеджер начнет обвинять всех, кроме себя, убедитесь, что у вас есть достаточно доказательств того, что вы сделали все, что от вас требуется (см. Пункт 1).

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

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

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

Также:

4) Оппортунистический рефакторинг - твой друг.

1. Прилагать усилия; но не за счет вашей семьи или вашего здоровья.
2. Вести учет всех важных проектных решений; тем более, что они относятся к вашей работе.
3. Поддерживайте сетевое взаимодействие и оставляйте свои возможности открытыми, если ситуация становится слишком сложной или вы становитесь жертвой массового увольнения.
4. Постарайтесь не думать о вашем проекте как о «провалившемся проекте». Всем нравятся люди, которые остаются позитивными и борются изо всех сил перед лицом невзгод. Поэтому, как можно дольше, старайтесь быть таким человеком. Позитивный взгляд, решительность и решительность всегда хороши для рабочего места.
5. Если вы ожидаете неудачный проект, то вы ожидаете посмертной встречи. На посмертной встрече все будут привлечены к ответственности. Будьте готовы защищать весь ваш код. [Примечание: Как правило, вы всегда должны писать чистый код, чтобы потом его было легче защитить.] Если у вас есть электронная почта или документ для разработки, которые вдохновляли ваши решения, то это даже лучше.
6. На этой посмертной встрече старайтесь оставаться позитивными; и только представьте доказательства своей электронной почты и проектного документа, если ваши суждения, усилия или качество исполнения поставлены под сомнение.

Что мне показалось наиболее эффективным, так это рекомендация Роберта Л. Рида о том, как бороться с давлением графика . Вот что пишет Рид:

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

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

Когда вы говорите, что проект «обречен на провал», это основывается на вашей оценке того, какие задачи необходимо выполнить и сколько усилий потребуется для каждого из них. Сделайте эту оценку явной , понятной и подробной . Разделите задачи на составные части; объясните как можно подробнее, как будет потрачено время разработки.

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

Как только вы обсудите этот подробный график со своим менеджером, будьте готовы проявить гибкость. Ваш менеджер может сказать: «Задача X не займет месяц; самое большее - неделю» или «Задача Y совершенно не нужна, исключите это из графика». Вы, конечно, можете обсудить эти вопросы, но гораздо важнее достичь взаимопонимания между вами и вашим менеджером по какой-то реалистичной версии графика. Таким образом, если вам не выделяют время, скажем, на тестирование, тогда у вас есть явная директива не проводить тестирование, а не просто «неожиданно истощать время». И вполне возможно, что ваш менеджер на законных основаниях желает явно сократить определенные углы, чтобы доставить вовремя - есть много случаев, когда это »

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

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

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

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

Вот некоторые наблюдения, которые я помню.

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

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

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

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

Эти знания, посмертные уроки могут быть неоценимыми, если они усвоены правильно, очень успешная карьера на руководящих должностях может зависеть от того, насколько хорошо они усвоены, как объясняется в этом блестящем ответе на WP :

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

На более практическом замечании можно рассматривать подход «следующий выпуск / обновление» как возможный выход из строя. По совпадению или нет (я думаю, что нет ), но оба сбоя, которые не повредили моей карьере, шли по очень похожим сценариям: релиз Nбыл полной катастрофой, релиз N+1был терпимым, релизы N+2и позже были просто успехом.

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

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

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

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

• ^{Вполне вероятно, что пройдет довольно много времени между заморозкой кода для запланированного выпуска и решением руководства полностью его исключить. Это время - ваш шанс: если вы сосредоточите свои усилия на исправлении известных проблем и надлежащей «евангелизации» прогресса, это может иметь значение (как это когда-то было для меня).}

Здесь уже есть множество практических (и других) советов, но для меня ключами к этой тайне являются следующие два пункта (выделение мое):

Срок составляет 1,5 месяца

а также

... мы фактически унаследовали этот проект (вместе с беспорядком) около 1-2 месяцев назад от другой команды разработчиков под тем же менеджером ...

Так....

Добро пожаловать в команду Пэтси Мстители

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

Исправление: Предыдущая команда была заменена, ~ 3 месяца до крайнего срока.

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

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

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

Суровые? Да. Но в то время как плохое планирование (по крайней мере!) Предыдущими командами / менеджерами - это не ваша вина, «неудача в доставке» будет .

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

Команда из 5 человек и 1,5 месяца. Новая команда имела проект только в течение 1-2 месяцев, поэтому новая команда даже не прошла обучение . Принимая грубые предположения о размере этого проекта, мне кажется, что новая команда ни за что бы не прошла курс обучения, даже если бы у проекта не было проблем вообще.

Так что, я (все еще) думаю, что тебя подставили.

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

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

Но всегда помните : не берите советы по карьере от незнакомцев в Интернете.

Это невероятная возможность для вас! Давайте возьмем предпринимательскую точку зрения на это.

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

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

Признайте вашу возможность улучшить свои навыки.

[1] Отмена проекта действительно будет успешной. Неудача будет тратить хорошие деньги после плохого.

Что ты можешь сделать

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

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

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

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

Что вы не можете сделать, но ваше руководство, вероятно, должно

• Они не должны добавлять больше людей в проект, чтобы «помочь» увидеть это

• Немедленно позвоните клиенту и сообщите ему плохие новости. Почему это хорошая идея? Хорошо, я оставлю цитату из манифеста для гибкой разработки программного обеспечения, но даже без него даже любители водопада ненавидят неприятные сюрпризы. Если клиент заранее знает, что этот проект обречен на провал, он будет недоволен, но будет гораздо счастливее, если вы скажете ему, что у него есть проблемы до того, как он пойдет им в лицо, и что вы на нем, и делаете все возможное, чтобы удовлетворить Это. Клиент может сделать много вещей, но большинство из них не хуже, чем узнать в последнюю минуту, что у них нет результата (или они есть, но это не пригодного для использования качества). Заказчик будет признателен за это, поскольку он сможет отложить наем сотрудников по тестированию, офшорных ИТ-специалистов, изменить свои внутренние планы обучения, и все это только потому, что вы были честны с ними.

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

• Обновите свое собственное высшее руководство, это также поможет им сохранить свою работу ...

То , что вы должны НЕ делать

• Попросите добавить больше людей в проект (см. Это )

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

• Скулить, жаловаться или негативно относиться к проекту, руководству, плохому дизайну, который вы унаследовали, разработчикам-новичкам, которых вы наставляете, что вам требуется 3 часа, чтобы объяснить им, что вы делаете что-то, что занимает у вас 1 час, будьте позитивны так же, как и вы Можно.

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

• Винить людей (или себя), это не помогает, никогда

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

Это только мои два цента, YMMV

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

• Качество статического кода можно определить с помощью большого количества инструментов статического анализа. Вы можете сделать это так просто или подробно, как считаете нужным. Метрики, которые я предлагаю вам начать с:
  • Цикломатическая Сложность
  • Размер вашего кода (например, Nr строк на функцию / класс, количество файлов, количество таблиц ...)
  • Определите, какие модули слишком велики
  • Размножение.
  • Приверженность к стилю кода
• Уровень дефектности
  • по KLOC по модулю или подсистеме (определите проблемные части вашей системы)
  • Вы можете рассчитать, сколько на члена команды, но я думаю, вы должны оставить это для себя
  • решено против найдено
  • время, необходимое для устранения ошибки (возможно, если это склонно сделать график этого)
  • возможно, сделайте оценку того, сколько времени нужно, если это продолжается с текущей скоростью
• планирование
  • Время экстраполяции используется для встроенных функций. Учитывайте сложность функции. Это не должно быть очень точным. То, что вы хотите передать с этим, будет выглядеть так: «Функции A, B и C примерно одинаковы по сложности с D, E и F. С функциями ABC используется 170%, если запланированное время. Если ничего не изменится, мы ожидаем того же требуется время для DEF "или по линии" Средняя функция занимает на X% больше времени, чем рассчитано. У нас нет оснований предполагать, что остальную функциональность проще построить, поэтому мы должны компенсировать это в будущем планировании Бесполезно иметь планирование, если оно нереально.
  • Постарайтесь иметь ежемесячный или, желательно, даже более короткий график выпуска. Если только внутренний. Это может помочь вам в экстраполяции времени, необходимого для проекта. Это также может уберечь вас от принятия нереалистичных обязательств (если вы не беретесь за новую работу до того, как будет сделан релиз). Составьте планирование для каждого цилиндра и убедитесь, что новые функции входят только в следующий цикл (т. Е. Они никогда не могут быть добавлены в текущий цикл).
• Тестовое покрытие: объясните «нормальные» значения тестового покрытия и покажите, каково ваше текущее покрытие
• Документация: сколько% фактически задокументировано? Как хорошо?
• Модульность:
  • На основе класса (сцепление и сцепление)
  • Пакет на основе
  • На основе подсистемы (сколько существует каналов связи?)

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

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

Также пока в графике можно сказать 1 с половиной месяца осталось. Это, вероятно, не "офигительная" дата. Некоторые клиенты могут забрать то, что у вас есть, к этой дате, даже если это еще не все. Некоторые клиенты могут предложить дополнительное финансирование, так как они уже вложили много денег в проект. Иногда сама компания может взять на себя дополнительные расходы, чтобы обеспечить удовлетворенного клиента. Все это вне вашего контроля. Делайте свою работу в меру своих возможностей. Это даст руководству возможность работать с ним, что может превратить проект по ликвидации последствий стихийных бедствий в историю успеха. Я видел это много раз.

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

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

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

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

То, что вы рассматриваете как полный провал, может не восприниматься как таковое всеми, в зависимости от точки зрения. В идеальном мире каждая функция будет завершена, элегантно и независимо закодирована независимо от других систем и каждой тестируемой строки кода. Я не видел ни одного проекта, который выглядел бы так в 1-й редакции. В реальном мире реализация проекта означает принятие некоторых компромиссов, возможно, даже не хватает некоторых ключевых функций, но продукт может быть поставлен и даже при том, что он будет бета-качества в лучшем случае По крайней мере, вы получите отзыв о том, что нужно исправить в первую очередь. Плюсом этого является то, что оно может информировать руководство о том, что программное обеспечение никогда не выполняется, и вместо того, чтобы пытаться разработать определенный v 1.0 в вакууме, лучше итерировать и реагировать на изменения гибким способом. Наконец, для вас, как разработчика в этой должности, Я думаю, что ключевым моментом является разработка как можно более хорошего кода в этих условиях - документируйте его, самостоятельно пишите тесты (особенно для внешних зависимостей) и используйте свои знания системы, чтобы сообщить, какие функции действительно важны и должны - и какие из них могут подождать неделю или месяц. Высказывай свои мысли и оправдывай их, как ты. Вместо того, чтобы готовиться к плану В, будьте готовы к тому, что вы и другие бедные люди, вероятно, исправите весь этот ошибочный и еще не сделанный код, ПОСЛЕ того, как продукт будет поставлен - как указано выше, это означает, что вы должны писать свой код в модульном развязанном виде - если вы думаете, что код персистентного слоя плох, надеюсь, вы сможете заменить его полностью в следующей ревизии. И, наконец, не отчаивайтесь - работа с такой ситуацией является частью того, что вы за него платят, и это учебный процесс. Независимо от результатов этого конкретного проекта, это будет считаться ценным опытом в будущем.