Как я должен вести себя как разработчик в проекте, который направляется на неудачу?

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

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

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

Причины, по которым этот проект направляется на неудачу:

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

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

320 голосов | спросил 5 revs, 3 users 52%
Louis Rhys
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

20 ответов


308

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
101

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
86

Я порекомендую вам немного времени, чтобы прочитать 2 книги.

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

Мои литовые навыки с краской MS помогли мне сделать это!

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
56

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
34

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

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

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

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

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

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
22

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

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

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

  • Документировать все
  • сохранить все электронные письма, чаты обмена сообщениями
  • Попробуйте найти выход из проекта, если это возможно.
ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
21

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

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

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

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

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

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

  • предельное давление
  • контроль качества
  • Профессионализм
  • руководство по управлению.

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
12

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
11

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

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

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

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

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

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

также:

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
11
  1. Трудно работать; но не за счет вашей семьи или вашего здоровья.
  2. Хранить записи всех критических проектных решений; особенно, поскольку они относятся к вашей работе.
  3. Продолжайте работать в сети и держите свои возможности открытыми, если ситуация становится слишком сложной или вы становитесь жертвой массового увольнения.
  4. Попробуйте not подумать о вашем проекте как о «неудавшемся проекте». Каждый любит человек, которые остаются положительными и бороться трудно перед лицом невзгод. Поэтому как можно дольше старайтесь быть , который человек. Положительный прогноз, зернистость и определение всегда хороши для рабочего места.
  5. Если вы ожидаете неудачный проект, вы ожидаете посмертного собрания. На посмертном собрании все будут привлечены к ответственности. Будьте готовы защищать весь свой код. [Примечание. Как правило, вы всегда должны писать чистый код, чтобы его было легче защитить позже.] Если у вас есть электронный или дизайнерский документ, который вдохновил ваши решения, это еще лучше.
  6. На этом посмертном собрании старайтесь оставаться позитивным; и только представляют вашу электронную почту и оформляют документы, если ваше решение, усилие или мастерство ставятся под сомнение.
ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
7

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

  

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

     

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
4

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
4

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

Вот некоторые замечания, которые я помню.

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

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

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

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

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

  

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


В более практичной заметке можно рассматривать подход «next /update release» как возможный выход из отказа. Совпадение или нет (я думаю, not ), но обе ошибки, которые не навредили моей карьере, прошли по очень похожим сценариям: релиз N был полной катастрофой, релиз N + 1 был допустимым, выпускал N+1 и позже был простым успехом.

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

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

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

Менеджмент может оказаться глухим к идеям следующего выпуска, но есть хороший шанс для них пересмотреть перед лицом убедительных убедительных доказательств прогресса проекта.
  • Весьма вероятно, что между замораживающим кодом для запланированного выпуска и решением управления будет довольно много времени, чтобы полностью отказаться от него. Это время - ваш шанс: если вы сосредоточиваете усилия на устранении известных проблем и правильно «евангелизируете» прогресс, это может иметь значение (как это когда-то было сделано мной).
ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
4

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

  

Крайний срок составляет 1,5 месяца

и

  

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

Так ....

Добро пожаловать в Team Patsy Мстители

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

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

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

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

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

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

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

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

Итак, я (по-прежнему) думаю, что ты вален.

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
3

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
3

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

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

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

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

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

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

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

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

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

Что вам нужно NOT сделать

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

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

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
1

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

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

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
0

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

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18
0

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

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

ответил dthorpe 26 AM000000100000001831 2011, 10:58:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132