Я являюсь разработчиком в команде из 5 человек и считаю, что наш проект движется к катастрофе. Я сейчас опишу почему, но мой вопрос: как мне себя вести?
Крайний срок - 1,5 месяца, и я чувствую, что независимо от того, что мы делаем, этот проект провалится. Я придерживаюсь мнения, что мы должны просто прекратить проект и прекратить тратить наше время, но с политической точки зрения наш менеджер не может этого сделать.
Что мне делать в этом случае? Должен ли я приложить дополнительные усилия, или я должен просто успокоиться? А что мне сказать менеджеру?
Причины, по которым этот проект обречен на провал:
- С приближением крайнего срока многие из обязательных функций не завершены
- Приложение нестабильно и очень сложно в использовании
- Система очень сложная, код очень сложный для понимания, очень сложный для изменения - модель данных слишком управляема сложной реляционной базой данных (более 100 таблиц)
- Неясное руководство; менеджер реагирует на новую информацию с серьезными изменениями
- Почти нет автоматических тестов или юнит-тестов
- Сильно зависит от других систем, но пока нет интеграционных тестов
Фактически, мы фактически унаследовали этот проект (вместе с беспорядком) около 1-2 месяцев назад от другой команды разработчиков под тем же менеджером, который работал над ним в течение нескольких месяцев.
источник
Ответы:
Сообщите о своих проблемах самым лаконичным и неконфронтационным способом вверх по служебной лестнице. Суммируйте риски, но не навязывайте им свое заключение.
У руководства всегда должен быть выбор того, что делать, но ваша задача - оценить ситуацию и сообщить о ней. Используйте электронную почту, чтобы оставить след на бумаге, когда дела пойдут на юг.
Сделав это, продолжайте добросовестно работать над проектом.
Имейте в виду, что вы можете знать не все, что нужно знать о проекте, его спонсорах и финансовых решениях, стоящих за ним. Управленческие решения, которые кажутся вам глупыми, на самом деле могут основываться на умных рассуждениях, которые вам не видны.
источник
Держите бумажный след (например, дневник, сохраненные электронные письма и т. Д.). Включайте только факты и объективные наблюдения. Оставьте все выводы до тех, кто (если кто-нибудь) читает то, что вы написали.
Как разработчик, если вас не рассматривают как препятствие для проекта, вы, скорее всего, отлично справитесь с указанием пальцем, что, несомненно, произойдет. Ваш менеджер, возможно, не так удачлив, но здесь это не актуально.
Просто на общих принципах, обновите свое резюме и убедитесь, что вы время от времени встречаетесь с другими разработчиками за пределами вашей компании. Если вы не являетесь членом какой-либо локальной группы разработчиков, присоединяйтесь ко 2 или 3. Это займет годы, чтобы создать сеть друзей и знакомых, но в конечном итоге это того стоит. Обязательно смотрите на это как улицу с двусторонним движением - если вы можете помочь заполнить вакансию в вашей компании кем-то способным, это так же хорошо, как то, что кто-то помогает вам найти работу.
источник
Я рекомендую вам уделить немного времени чтению 2 книг.
«Марш смерти» - каноническая книга, описывающая патологический стиль управления проектами, широко распространенный в разработке программного обеспечения. Из-за сжатия расписания, расширения функций или неправильного управления многие проекты оказываются в плохом состоянии; это помогает понять, что вы не одиноки, и ваш проект - не единственный марш смерти. Автор Эдвард Вашдон делит тупиковые проекты на 4 сектора, каждый из которых имеет разные стратегии выживания. Иногда единственной стратегией выживания является уход. Я думаю, что эта книга поможет вам понять, каков ваш выбор, и сузить то, что вы можете и не можете делать.
Катастрофа Распад написан больше для руководителей проектов. Он нацелен на то, чтобы понять, как сортировать сломанный проект: что нужно урезать, что можно урезать и как донести это до клиентов? «Обычное» управление программными проектами вовлекает нас в грязные проекты, и мы не избежим наших проблем, используя то же самое мышление, которое нас вовлекло в них в первую очередь. Эту книгу читать немного труднее, чем « Марш смерти» , но ее стоит иметь на своей книжной полке.
источник
3 простые и циничные стратегии для поддержания карьеры / здравомыслия.
Посмотрите, как разваливается поезд, сойдите с поезда: провальные проекты ужасны для морали, и если у вас не будет навыков управления ниндзя, это может оказать негативное влияние на вашу карьеру. Прыгайте сейчас, если вы видите любую мягкую посадку.
Если это не сработает, держите голову подальше: люди начнут искать виновных людей - не делайте это легко для них! Эскалация опасений может привести к тому, что цепочка управления будет правильным решением, но она неэффективна и рискованна. Ваш собственный менеджер вряд ли передаст ваши опасения, и обход его / ее не только сделает вас обоих плохо выглядящими, но и заклеймит вас как «нарушителя спокойствия», то есть такого человека, которого можно обвинить в подрыве проекта и т. Д. Это, конечно, также означает быть профессионалом, вкладывать свои часы, но без героизма.
План аварийного выхода на Т + 1: предоставьте себе несколько вариантов и подготовьте почву для потенциальной внутренней или внешней передачи сейчас. Разговаривать с людьми; нет никакой причины ждать, пока другие решат, что делать с вами, когда финансирование проекта будет сокращено или погрязнет в неизбежной «давке» людей, мигрирующих через пару месяцев.
Приносим извинения, если это звучит слишком цинично, но если вы правильно назвали это, то нет никаких причин страдать от неприятностей, встречающихся на вашем пути. Будь профессионалом, будь оптимистом, но всегда будь реалистом.
источник
Какое влияние окажет этот провальный проект на вашу карьеру в фирме и за ее пределами? По моему опыту, просто связь с успешными проектами не является показателем вашего личного совершенства.
Качества, которые вы проявляете перед лицом невзгод, а иногда то, что выглядит как определенный провал, часто замечаются вышестоящими, в большей степени, чем вы думаете. И я говорю не только о вашем непосредственном руководителе.
Я лично видел, как моего непосредственного менеджера уволили за некомпетентность, а затем в тот же день меня повысили до должности. Не приятно, но это показало, что люди смотрят на меня, и мне нравится то, что я делал.
Часто тот же хаос и дезорганизация, которые сопровождают неудачный проект, дают вам возможность сиять.
Итак, посмотрите на проект следующим образом: какую возможность предоставляет этот провальный проект, чтобы свет осветил все мои сильные стороны и лучшие качества? Какие уроки я извлекаю из этого опыта, который сделает меня лучшим профессионалом и лучшим человеком?
По сути, сумма опыта, извлеченного из неудач, является тем, что питает истинный успех.
Примечание: Томас Оуэнс спросил, какие конкретные вещи человек может сделать в подобном проекте. У меня есть несколько общих предложений, которые я использовал в качестве личных указаний в этих ситуациях. Поможет ли это проекту бедствия чудесным образом добиться успеха? Нет - но я обнаружил, что это помогло мне правильно взглянуть на вещи и обрести личный успех, несмотря на плохую ситуацию.
1) Сосредоточьтесь на личном превосходстве - стремитесь писать все более качественный код, соответствовать все более высоким стандартам качества и функциональности.
2) Сосредоточьтесь на личных показателях - сколько кода вы пишете, что порождает последующие ошибки? Уменьшите это соотношение как можно ниже. Когда вас просят предоставить оценку поставленной перед вами задачи, вы в целом точны или считаете, что вы слишком много или недостаточно буферизировали график? Когда вы действительно задали задачу, предоставляете ли вы хороший уровень обратной связи о ходе работы, включая заблаговременное уведомление о проблемах с графиком доставки?
3) Сосредоточьтесь на показателях команды - это только некоторые вещи, которые мне не нравятся: другие члены команды отстают из-за зависимости от задачи, над которой вы работаете? Хорошо ли вы делегируете или разделяете свои задачи / подзадачи другим в команде? Вам трудно общаться с одним или несколькими членами команды? Все области, над которыми я работаю, регулярно улучшаются.
источник
В такой ситуации, как самая низкая ступенька лестницы, вы можете сделать так много, чтобы помочь проекту.
Кроме того, вам действительно нужно присматривать за номером 1.
источник
Неудачные проекты могут быть токсичными для души, вызывать депрессию, переутомление и низкую самооценку.
Это все относительно перспективы.
Я работал над ужасными проектами, когда сидел напротив другого парня, у которого на лице каждый день была улыбка. О, как я хотел ударить эту улыбку с его лица.
Некоторых людей не беспокоит текущее положение дел в проекте. Они наслаждаются своим вкладом, своими задачами и работают в сфере своих интересов. В то время как другие, имеют сильную негативную реакцию на текущее положение вещей. Это все о наших ожиданиях от нашей повседневной работы.
В то время как вы можете делать часть работы, которая вам нравится. В текущем проекте есть элементы, которые вам не нравятся.
Вам необходимо определить, что это за проблемные элементы, и решить их.
Есть много команд и компаний, которые не считают вышеупомянутые аспекты развития важными. Я обнаружил, что они часто думают следующее.
Эти проблемы не твои. Это их, и вы не должны тратить энергию на их поведение. Если вы не один из тех парней, которые улыбаются и наслаждаются своей работой, даже если она движется к скале, вам следует подумать о поиске места для
like minded
разработчиков.Вы будете намного счастливее.
источник
Старайтесь активно искать новый способ добиться успеха в проекте. Подумайте, как вы можете предложить некоторые альтернативы. В данный момент ваш начальник, вероятно, измотан тем, что проект провалился, разве он не оценит, что кто-то пришел с решениями, а не с проблемами?
Может быть, есть способ разделить функции на ступенчатые результаты? Часто существуют степени «должен иметь», поэтому посмотрите, можете ли вы выделить их по приоритетам и сгруппировать их по этапам. Лучше иметь какой-то продукт в конце срока, чем ничего. Или рассмотрите возможность разделения команды между людьми, работающими над новой функциональностью, и другими, работающими над стабильностью. Таким образом, вы можете продемонстрировать некоторый прогресс в обоих направлениях.
Если эти усилия увенчаются успехом, вы покажете, что являетесь участником команды, который может найти способ добиться успеха, если нет, вы все равно продемонстрируете, что не сдаетесь и будете работать над поиском решения.
источник
Похоже, большинство проектов, в которых я принимал участие. Это, вероятно, не закончится так плохо, как вы думаете, однако:
1) Делай свою работу. Не беспокойтесь о проекте в целом, пока выполняете свои обязанности.
2) CYA. Если проект потерпит неудачу, и вы подозреваете, что менеджер начнет обвинять всех, кроме себя, убедитесь, что у вас есть достаточно доказательств того, что вы сделали все, что от вас требуется (см. Пункт 1).
3) Сделайте несколько вежливых предложений по улучшению. Не издайте предупреждающих звонков, не будьте мрачными и мрачными, просто будьте вежливы и тонки.
Например, если команда не пишет эффективные модульные тесты (или какие-либо тесты), напишите несколько модульных тестов ближе к тому, что вы хотели бы увидеть, и назовите причину, как это помогло вам решить конкретную проблему или сэкономило ваше время.
Что бы это ни случилось, если вы хотите повлиять на изменения, сосредоточьтесь на позитивных шагах, которые имеют конкретные результаты. Этот проект может никогда не оказаться победителем, но, возможно, команда сможет подготовиться к следующему.
Также:
4) Оппортунистический рефакторинг - твой друг.
источник
источник
Что мне показалось наиболее эффективным, так это рекомендация Роберта Л. Рида о том, как бороться с давлением графика . Вот что пишет Рид:
Когда вы говорите, что проект «обречен на провал», это основывается на вашей оценке того, какие задачи необходимо выполнить и сколько усилий потребуется для каждого из них. Сделайте эту оценку явной , понятной и подробной . Разделите задачи на составные части; объясните как можно подробнее, как будет потрачено время разработки.
Как только вы это сделаете, у вас будет прочная основа для обсуждения проблем с руководством. По всей вероятности, после того, как вы разбили свою оценку на все конкретные задачи, которые необходимо выполнить, вы сможете продемонстрировать, что работа занимает больше времени, чем у вас - возможно, намного, намного больше.
Как только вы обсудите этот подробный график со своим менеджером, будьте готовы проявить гибкость. Ваш менеджер может сказать: «Задача X не займет месяц; самое большее - неделю» или «Задача Y совершенно не нужна, исключите это из графика». Вы, конечно, можете обсудить эти вопросы, но гораздо важнее достичь взаимопонимания между вами и вашим менеджером по какой-то реалистичной версии графика. Таким образом, если вам не выделяют время, скажем, на тестирование, тогда у вас есть явная директива не проводить тестирование, а не просто «неожиданно истощать время». И вполне возможно, что ваш менеджер на законных основаниях желает явно сократить определенные углы, чтобы доставить вовремя - есть много случаев, когда это »
Оценка дает вам конкретное содержание для обсуждения и обсуждения. Это ставит вас на одной странице; это поможет вам почувствовать уверенность в том, что ваш менеджер учел ваши опасения. И это приводит вас к тому, что, если ваш менеджер прямо задает вопрос о невозможном, это будет совершенно очевидно для вас обоих. Если проект хорошо и действительно обречен, вы ясно дадите понять, и ваш менеджер сам решит, как именно он хочет, чтобы вы проводили время.
источник
Так как ваш менеджер знает, что он, вероятно, потерпит неудачу, вы лучше, чем большинство Я хотел бы рассмотреть вопрос о работе с менеджером и посмотреть, есть ли какие-либо части / функции приложения, которые могут быть исключены.
Слишком часто мы думаем, что каждый запрос клиента является «убийцей сделки», и стараемся изо всех сил пообещать доставку. Пока кто-то не работает с клиентом и не исследует его глубже, вы не сможете принимать эти решения. Если вы не можете этого сделать, все равно постарайтесь дать то, что считаете наиболее важным. Иногда проще попросить прощения, чем разрешения.
источник
Я участвовал в трех проектах, которые были явным провалом. Это было довольно больно, но, оглядываясь назад, два из трех не имели негативных последствий для моей карьеры, и даже третий не был концом света.
Вот некоторые наблюдения, которые я помню.
Разработчики на младших должностях («код на спецификацию», «исправить ошибку» и тому подобное) не сильно пострадают, если они не ослабнут из-за снижения морального духа в команде. На таких позициях разумная и даже иногда успешная стратегия выживания могла бы просто делать все возможное.
Программисты на более высоких, влиятельных должностях были бы лучше готовы поделиться негативными последствиями провала проекта. Предполагается, что архитектор, технический руководитель, старший разработчик будут оказывать достаточно большое влияние, чтобы считаться ответственным за успех или провал проекта.
На руководящей должности лучше подготовиться к неудачам «косвенно», проанализировав, что пошло не так и что можно было сделать лучше.
Эти знания, посмертные уроки могут быть неоценимыми, если они усвоены правильно, очень успешная карьера на руководящих должностях может зависеть от того, насколько хорошо они усвоены, как объясняется в этом блестящем ответе на WP :
На более практическом замечании можно рассматривать подход «следующий выпуск / обновление» как возможный выход из строя. По совпадению или нет (я думаю, что нет ), но оба сбоя, которые не повредили моей карьере, шли по очень похожим сценариям: релиз
N
был полной катастрофой, релизN+1
был терпимым, релизыN+2
и позже были просто успехом.Прогуливаясь на вашем месте, я, скорее всего, приложил бы некоторые усилия для подготовки / продвижения идеи «следующего релиза». Составьте (и сообщите !) Что-то вроде примерного списка известных проблем, которые вы хотели бы исправить после запланированного выпуска. Составьте неофициальную черновую дорожную карту для следующих выпусков.
Подумайте, как вы могли бы донести эти идеи до людей вокруг вас, как вы могли бы повлиять на управление, чтобы рассмотреть этот план. Если в проекте есть кто-то с хорошими маркетинговыми навыками, постарайтесь вовлечь их в амортизацию ущерба от сбоев, обернув предстоящий выпуск в более плавные термины, такие как «ранний доступ», «бета-версия», «предварительный просмотр клиента», «вводный выпуск», такие вещи, как это.
Подумайте о плане резервного копирования на случай, если старшие сотрудники окажутся глухими к этой идее. Помните выше рассказ о «исправлении более ста известных ошибок»? действительно, есть шанс что-то изменить.
Менеджмент может показаться глухим к идеям следующего выпуска, но у них есть хорошие шансы пересмотреть их перед лицом убедительных доказательств прогресса качества проекта.
источник
Здесь уже есть множество практических (и других) советов, но для меня ключами к этой тайне являются следующие два пункта (выделение мое):
а также
Так....
Добро пожаловать в
команду ПэтсиМстителиУ предыдущей команды были дела поважнее ... чем провал. И каким-то образом менеджер согласился с этим. Смена команды в столь сжатые сроки - не лучший шаг для руководства проектом, так что ... что с этим?Исправление: Предыдущая команда была заменена, ~ 3 месяца до крайнего срока.
-> Узнайте, как предыдущей команде разработчиков удалось сбежать, и сделайте это. <-3 месяца - это едва ли достаточно времени, чтобы ускорить работу системы такого очевидного размера, тем более исправить ее архитектуру, добавить тесты и завершить ее. Тебе нужно больше времени
И если вы не можете этого сделать, если вы не уверены в том, что проект будет продлен на неопределенный срок, или ему помогут магические эльфы или что-то в этом роде, вы не захотите оставаться последним, кто остался с сумкой.
Суровые? Да. Но в то время как плохое планирование (по крайней мере!) Предыдущими командами / менеджерами - это не ваша вина, «неудача в доставке» будет .
Предыдущая команда под залог .Предыдущая команда была выгнана на обочину. О чем тебе это говорит? Это говорит мне, что вы - оборотная команда ... и ваш менеджер рассчитывает на вашу героику, чтобы спасти день.Команда из 5 человек и 1,5 месяца. Новая команда имела проект только в течение 1-2 месяцев, поэтому новая команда даже не прошла обучение . Принимая грубые предположения о размере этого проекта, мне кажется, что новая команда ни за что бы не прошла курс обучения, даже если бы у проекта не было проблем вообще.
Так что, я (все еще) думаю, что тебя подставили.
Если это так - и только вы можете решить, что является правдой или во что вы хотите верить - вы никому не должны объяснения или извинения за то, что ушли с пути этого крушения поезда. Вы должны быть осторожны об этом, хотя.
Я серьезно сомневаюсь, что менеджер не знает, что проект находится под угрозой, а это означает, что мягкие объяснения не принесут вам ничего, кроме негативного внимания. Если ваш менеджер не мистер Роджерс , ваше будущее в опасности.
Но всегда помните : не берите советы по карьере от незнакомцев в Интернете.
источник
Это невероятная возможность для вас! Давайте возьмем предпринимательскую точку зрения на это.
Предполагая, что руководство хочет, чтобы этот проект был успешным, вы в состоянии помочь им в этом. Причина, по которой эта реализация так важна, заключается в том, что вы должны развить убежденность и уверенность в том, что предупреждающие знаки, которые вы видите, на самом деле приведут к провалу проекта [1].
Это ваш шанс отработать важные навыки системного мышления и межличностного общения. Понимайте и визуализируйте проблемы и потенциальные возможности, которые упускаются, чтобы вы могли разработать стратегию, позволяющую сообщать о них максимально четко и просто.
Признайте вашу возможность улучшить свои навыки.
[1] Отмена проекта действительно будет успешной. Неудача будет тратить хорошие деньги после плохого.
источник
Что ты можешь сделать
Относитесь к этому с точки зрения собственного самосовершенствования, это «их» проект, но также и ваш, возьмите на себя ответственность, даже если вы знаете, что это не удастся. Почему? потому что а) вы можете помочь ему чуть-чуть потерпеть неудачу, б) во время испытаний, это то место, где вы учитесь больше всего в) вы должны измерить себя с помощью своих собственных метрик совершенства, прилагая все усилия, вы можете не спасти проект, но вы может в конечном итоге все еще гордится собой
Поговорите с другими коллегами-разработчиками и посмотрите, что они думают, вы, вероятно, обнаружите, что многие разделяют одно и то же разочарование, если все сделано осторожно (не заставляйте людей думать, что вы хотите начать мятеж или что-то еще), тогда это может помочь не только вам, но и другие
Игнорирование проблемы не заставит ее уйти, если говорить о том, как, несмотря ни на что, преодолеть все трудности, например, по крайней мере, получить приличную необходимость, или, если основной вариант использования «вау-фактора» сделан правильно, может сделать это Проект провалился менее жалко. Как это сделать? ну, мало идей о том, «когда дела идут плохо, дела идут плохо» или «отчаянные времена оправдывают отчаянные меры» и другие клише, например: массовое использование OSS, экстремальное программирование / гибкие методологии, хакатоны на выходные (только добровольцы, не принуждают людей к рабочие выходные). Это время, когда вы можете проявить лидерство (осторожно, если вы не занимаетесь руководящей / старшей должностью команды), но вы можете воспользоваться этим преимуществом и стать их пересмешником, просто дайте людям почувствовать, что они могут получить этот проект чуть менее неудачно, чем все знают, что так и будет.
Убедитесь, что ваше руководство знает, но очень, очень внимательно, если они знают, они будут благодарны вам за то, что вы говорите им это неконфронтационным, спокойным способом, если они этого не сделают, они оценят это еще больше, и удивляйтесь, почему никто не сказал им об этом раньше. Вы должны сказать им это как услугу, без какой-либо эмоциональной стороны, просто фактов и без повестки дня. Если они спросят вас, что, по вашему мнению, они должны делать (что является хорошим знаком, но редким), тогда смотрите следующий раздел.
Что вы не можете сделать, но ваше руководство, вероятно, должно
Немедленно позвоните клиенту и сообщите ему плохие новости. Почему это хорошая идея? Хорошо, я оставлю цитату из манифеста для гибкой разработки программного обеспечения, но даже без него даже любители водопада ненавидят неприятные сюрпризы. Если клиент заранее знает, что этот проект обречен на провал, он будет недоволен, но будет гораздо счастливее, если вы скажете ему, что у него есть проблемы до того, как он пойдет им в лицо, и что вы на нем, и делаете все возможное, чтобы удовлетворить Это. Клиент может сделать много вещей, но большинство из них не хуже, чем узнать в последнюю минуту, что у них нет результата (или они есть, но это не пригодного для использования качества). Заказчик будет признателен за это, поскольку он сможет отложить наем сотрудников по тестированию, офшорных ИТ-специалистов, изменить свои внутренние планы обучения, и все это только потому, что вы были честны с ними.
вместе с заказчиком придумайте способы сделать что-то из проекта, наиболее распространенным является удаление вещей. например, могут быть некоторые функции, которые слишком сложно разработать так, как они были спроектированы, и если клиент согласится на небольшие изменения и упрощения, некоторые функции станут проще.
Обновите свое собственное высшее руководство, это также поможет им сохранить свою работу ...
То , что вы должны НЕ делать
Попросите добавить больше людей в проект (см. Это )
Бросайте / ищите другую работу (по крайней мере, пока), это то, чему вы можете научиться, и что сделает вас однажды лучшим разработчиком или лучшим менеджером. Вы научитесь ценить многие вещи лучше, лучше управлять временем, лучше проектировать, лучше писать код и лучше работать с коллегами и менеджментом. Ищите работу после того, как эти 2 месяца закончатся, если вам не нравится работать там, не по какой-либо другой причине.
Скулить, жаловаться или негативно относиться к проекту, руководству, плохому дизайну, который вы унаследовали, разработчикам-новичкам, которых вы наставляете, что вам требуется 3 часа, чтобы объяснить им, что вы делаете что-то, что занимает у вас 1 час, будьте позитивны так же, как и вы Можно.
Критикуйте руководство и станьте мишенью в качестве источника проблем, они находятся в одной лодке, и они могут знать то, чего вы не знаете, все, что вы можете сделать, это обновить их (всегда обновляйте своего непосредственного менеджера, никогда не обходите его / его)
Винить людей (или себя), это не помогает, никогда
Принимайте это слишком серьезно, если только это не медицинское оборудование, никто не может умереть, если вы пропустите сроки, это программное обеспечение, мы пропустим сроки для жизни, расслабьтесь.
Это только мои два цента, YMMV
источник
Найдите проблемы, с которыми сталкивается ваш проект, и постарайтесь четко определить, насколько это объективно возможно. С каждой «метрикой», которую вы определяете, убедитесь, что вы определили, почему вы считаете эту метрику важной. Вы хотите, чтобы ваш менеджер понял, к каким последствиям приведет, если определенный показатель не окажется в «приемлемом диапазоне». Вам нужно будет дать некоторые рекомендации для каждой метрики, чтобы указать, какие значения являются «Хорошими», «Приемлемыми», «Проблемными» или «Плохими». Определите каждый критерий заранее. Если возможно, вы можете описать, что будет минимально необходимо для успеха проекта, и сопоставить это с текущим проектом.
источник
Вы должны пойти на работу и делать то, что вы будете делать в любом проекте, независимо от того, был он успешным или нет. Вам платят за выполнение вашей работы. Сделайте это в меру своих возможностей. Предполагая, что вы не являетесь руководителем или руководителем проекта, вы не обязаны решать, следует ли отменить программу или нет. Вы решили расслабиться так же, как вы принимаете решение отменить проект. Это не часть вашего описания работы.
Однако, в целом, это не означает, что вы должны работать 50, 60 или более часов в неделю, чтобы попытаться соответствовать графику. Еще раз, это задача менеджмента выяснить, как достичь целей проекта. 50 + часовая рабочая неделя не является разумным вариантом, если они не хотят платить сверхурочно, а вы не хотите откладывать семейную жизнь. Еще раз, это была работа руководства, чтобы составить достижимый график. Они не могут предположить, что могут заставить сотрудников игнорировать их семейную жизнь, чтобы соответствовать нереалистичным графикам.
Также пока в графике можно сказать 1 с половиной месяца осталось. Это, вероятно, не "офигительная" дата. Некоторые клиенты могут забрать то, что у вас есть, к этой дате, даже если это еще не все. Некоторые клиенты могут предложить дополнительное финансирование, так как они уже вложили много денег в проект. Иногда сама компания может взять на себя дополнительные расходы, чтобы обеспечить удовлетворенного клиента. Все это вне вашего контроля. Делайте свою работу в меру своих возможностей. Это даст руководству возможность работать с ним, что может превратить проект по ликвидации последствий стихийных бедствий в историю успеха. Я видел это много раз.
источник
Я могу только повторить то, что сказали другие, но я подчеркиваю: всегда стремитесь к своей лучшей работе и держите бумажный след. как по CYA, так и по техническим причинам.
Любая неудача на вашем пути зависит от личного характера руководства; но позвольте мне сказать вам, что ад находится на приемном конце некомпетентного, лживого руководства. Но самое худшее, что вы оставите со своим уважением к себе (и сверстникам), нетронутым.
Держите хорошие записи технических аспектов вашего Марша смерти. Когда вы получаете неизбежный вопрос об интервью , вы были на неудачном проекте; почему это не удалось и что вы сделали, чтобы попытаться предотвратить это? Управление дураками - это не ответ, даже если это причина.
источник
Это может быть простой способ предположить, что это неизбежный и полный провал, и просто отказаться от проекта. Как консультант меня часто приглашают помочь с проектами, которые находятся на разных стадиях дегенерации, провалились или потерпели неудачу, и часть того, за что мне платят, - это оживление и завершение таких проектов.
То, что вы рассматриваете как полный провал, может не восприниматься как таковое всеми, в зависимости от точки зрения. В идеальном мире каждая функция будет завершена, элегантно и независимо закодирована независимо от других систем и каждой тестируемой строки кода. Я не видел ни одного проекта, который выглядел бы так в 1-й редакции. В реальном мире реализация проекта означает принятие некоторых компромиссов, возможно, даже не хватает некоторых ключевых функций, но продукт может быть поставлен и даже при том, что он будет бета-качества в лучшем случае По крайней мере, вы получите отзыв о том, что нужно исправить в первую очередь. Плюсом этого является то, что оно может информировать руководство о том, что программное обеспечение никогда не выполняется, и вместо того, чтобы пытаться разработать определенный v 1.0 в вакууме, лучше итерировать и реагировать на изменения гибким способом. Наконец, для вас, как разработчика в этой должности, Я думаю, что ключевым моментом является разработка как можно более хорошего кода в этих условиях - документируйте его, самостоятельно пишите тесты (особенно для внешних зависимостей) и используйте свои знания системы, чтобы сообщить, какие функции действительно важны и должны - и какие из них могут подождать неделю или месяц. Высказывай свои мысли и оправдывай их, как ты. Вместо того, чтобы готовиться к плану В, будьте готовы к тому, что вы и другие бедные люди, вероятно, исправите весь этот ошибочный и еще не сделанный код, ПОСЛЕ того, как продукт будет поставлен - как указано выше, это означает, что вы должны писать свой код в модульном развязанном виде - если вы думаете, что код персистентного слоя плох, надеюсь, вы сможете заменить его полностью в следующей ревизии. И, наконец, не отчаивайтесь - работа с такой ситуацией является частью того, что вы за него платят, и это учебный процесс. Независимо от результатов этого конкретного проекта, это будет считаться ценным опытом в будущем.
источник