Как Вы возвращаете провальный проект на ходу? [закрытый]

Гибкий рефакторинг. Определите и расположите по приоритетам то, что хочет клиент, и затем создайте самый важный материал в коротких спринтах из существующего кода. Человек удачи :)

Там, выполнил эти шаги:

Стабилизировались

• , собирают реальную историю: насколько хороший/плохой кодовая база, насколько хороший/плохой разработчики, что действительно должно быть сделано (пустая минута кости), когда она должна быть сделана
• , уменьшают сверхурочное время (усталые люди, хорошие или плохие, не работайте хорошо)
• , удаляют плохое, вводят новый/хороший - допускают ошибку на стороне замены (многие могли быть сожжены и ценить даже принудительное изменение)
• , удаляют доступ к коду bad/un-required (внимание на 20% кодовой базы, которая обеспечивает 80% значения)
• помещенные основные методы кода, на месте гарантирующие, что только хороший код входит (не повреждайте основу больше)

Управление

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

, Продвигаются

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

Vyas, я чувствую, что, возможно, записал этот вопрос. Мое предыдущее задание включило возрождение проекта KVM, который перестал работать после разработки года. Спецификации были в форме руководства пользователя и опыта разработчиков с аналогичными продуктами. Я закончил тем, что преподавал C 3 программистам блока и повторно проектировал с нуля. Мы принесли продукт успешно на рынок за 4 месяца. (Затем я ушел в отставку. Пойди разберись.)

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

1. Команда неопытных программистов работает 24x7
10. Никакое техническое лидерство / или Кодер Ковбоя, который может взять технические вопросы

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

8. Этап после этапа отсутствовал
9. Команда не может придумать дату поставки, поскольку никто не соглашается относительно кванта работы, на самом деле должен быть сделан
3. Клиент кричит, который он даже не мог сделать, основной материал (Сохраняющий/Запрашивающий) и т.д.

• , Берет маленькие укусы! Ломают каждую часть в максимально возможной степени, затем имеют дело с маленькими компонентами. Вы определите "глюки" рано и будете лучше способны определить объем целого проекта.
• Определяют Ваши интерфейсы. Каждый раз, когда можно изолировать блок, , делают это. Это позволяет параллельную разработку, потому что Вы уже выбрали параметры, предварительные условия, предположения, что происходит внутри, и возвращаемые значения. Можно погасить его, и создают другие модули и тесты независимо.
• Располагают по приоритетам. Внимание на дефекты и проблемы, которые влияют на клиента сначала. Новые возможности являются последними. При необходимости задержите функции вместо того, чтобы поставить содержащий ошибки код.
• Возлагают обязанности. Волонтеры предпочтены, каждый в его области знаний, но один лицо должно быть ответственно за каждую задачу.
• дефекты Дорожки, и запись все, что поможет Вам воспроизвести, располагается и фиксирует их. Документ любой, которые остаются во время доставки, таким образом, клиент не будет удивлен.

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

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

2. Ошибки исправлены только для представления новых ошибок
5. Никакие автоматизированные модульные тесты aggr vate ситуация

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

7. Сторонние компоненты использовали, становятся узкими местами, не протестированными на фитнес во-первых

• решения для Мозгового штурма, когда Вы не кодируете. Не позволяйте им остановить Ваш успех если вообще возможный. Можно ли инкапсулировать или кодировать ли вокруг них? Замените их?

Общие предложения:

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

Удача - держите нас в курсе!

Что когда-либо Вы делаете, сделайте это шаг за шагом.

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

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

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

, Таким образом, вот план действий:

1. Определяют критическую часть, которую необходимо изменить
2. , Изолируют код, который подразумевает, что это поведение
3. Находит, что любое происшествие этого кода в остальной части кода
4. Осуществляет рефакторинг использование этого знания, и крупный TDD
5. Интегрируют, тестируют и фиксируют, пока эта конкретная часть, работы
6. Возвращаются к шагу

, Не Ясно дает понять ситуацию боссу: это займет время, деньги и будет болезненно. Объясните, почему, что Вы сделаете, и что у Вас нет никакого другого пути или он перестанет работать СНОВА.

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

Никакое чудо. Просто метод и терпение.

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

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

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

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

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

Вот хорошая книга по предмету:

Распутывание Катастрофы: Возвращение Проектов программного обеспечения на ходу

Сводка имеет 14 объектов. Вы не можете сделать их всех. Так, каков первый шаг?

Вот то, что необходимо сделать сначала - добираются один улучшенная вещь.

• у Вас есть фундаментальные проблемы качества. (#2-5)
• у Вас есть архитектура и проблемы компонента. (#6, 7)
• у Вас есть проблемы расписания. (#1, 8, 9)

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

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

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

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

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

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

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

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

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

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

Если действительно необходимо было получить его на ходу (если откачка не является опцией)

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

я предложил бы некоторую форму Гибких, так как является самым легким успешно реализовать без ГУРУ, но необходимо быть ОЧЕНЬ строгими об этом, включая Соединение, Безжалостный Рефакторинг, Обзоры, Пронзив функциональность, Видимость, TDD, однонедельные циклы, 8-часовые рабочие дни (Да, дольше, чем 8 имеют тенденцию вредить производительности больше, чем справка, поскольку Вы, кажется, заметили)...

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

не забывают о стороне управления его. Недельные повторения для запуска (демонстрация КАЖДУЮ НЕДЕЛЮ). Постоянная адаптация. Очень короткие стоять-взлеты каждый день для решения проблем. (Придерживайтесь 15 минут макс., таблица более длинные проблемы, и т.д.), диаграммы Burndown, рабочая группа с клиентом на нем.

Вы не можете только иметь 15-минутной встречи каждую неделю и 2-недельных повторений и назвать ее Гибкой, но если Вы делаете ее правильно, она просто МОГЛА БЫ дать Вам шанс. Вы могли бы привести ХОРОШЕГО гибкого консультанта для обучения Вас на начале работы.

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

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

Если Вы можете, убежать.

В противном случае необходимо остановить все операции, которые делают проект нестабильным - включая кодирование и фиксацию дефектов.

Оценивают, где Вы

, Разбивают требования в намного меньшие "этапы"

Read некоторые практические книги ("Практические советы для освоения системы Проекта программного обеспечения Mcconnell" приходят на ум.

Определяют все проблемы и риски. Передайте все те, которые ко всем включенным.

Работа над каждой частью по одному.

Празднуют улучшения и этапы, поскольку они достигнуты.

Удача. Ваш сценарий звучит довольно плохим. Это не может быть salvageable - и вещи должны измениться для поправлений.

• Удостоверяются, что Вы не козел отпущения
• расползание границ проекта Сокращения
• функциональность Trim "требования"
• Реализация более быстрый dev цикл (возможно, Agile/Scrum/XP/whatever)

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

Maxim
1: Удостоверьтесь, что это не "Марш смерти"

Ellie
2: Удостоверьтесь, что поставило работы 3: Осуществите рефакторинг & кодовая база Realgin к Архитектуре / Лучшие практики 4: Посмотрите на то, что является реальными проблемами: команда технически competenet для поставки?

Kendall
5: Гарантируйте availaibility Технического Лидерства

счет K
6: Реализуйте Гибкие Процессы (По крайней мере, автоматизированные модульные тесты, если не TDD, короткие повторения, которые делают успехи видимые), 7: Получите клиентское закрытие сделки 8: будьте готовы вывести то, что не может работать (принятие желаемого за действительное в стороне)

Warren
9: Удостоверьтесь команда memebers, которые остаются данными шанс запустить более чем [1 125]

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

jsl4980
11: Вам нужно закрытие сделки по графику от Вашей команды (большая часть импорта) & клиент [Это поднимает больше вопросов. Что, если Ваш клиент спрашивает, достаточно ли команда компетентна придерживаться Вашего расписания? Что, если Вы сами знаете, что временные шкалы команда делают предложение просто, показывает их отсутствие понимания]

Ather
12: команда фиксируется?
13: Вы официально QA?

Patrick
14: Запустите, перепроектируйте и повторно соответствуйте лучшим практикам Архитектуры/Дизайна для модулей все же, чтобы быть разработанными.

Это больше не о техническом лидерстве, это теперь об управлении проектами.

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

1) Идентифицируют спонсоров проекта и заинтересованные стороны - и официальные и реальный .

2) Переходят к ним и запрашивают, чтобы проект "пошел темный" в течение недели.

3), Если они не соглашаются, убегите от этого проекта.

4), Если они действительно соглашаются, назовите тайм-аут проекта в течение недели - все останавливается.

5) Проводят ту целую неделю, говорящую с важными людьми на проекте определить реальное состояние проекта.

6), Пока занятый теми обсуждениями, начните формулировать план восстановления проекта, подчеркнув возможные компромиссы между объемом, расписанием, бюджетом и персоналом.

7) В конце недели, решите, которые (если таковые имеются) Ваших возможных сценариев проекта выполнимы.

8) Забирают лучший из этих сценариев спонсорам проекта и заинтересованным сторонам, и начинают согласовывать.

9), Когда путь вперед будет согласован, перезагрузите проект и молитесь - возможно не в том порядке.

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

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

, от проекта отказались его создатели из-за ситуации с маршем смерти и ушел после удаления всех комментариев в коде и выполнении другой путаницы. Никто не знал win32 / материал MFC также.

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

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

, После того как клиент был убежден, и мы, где способный для покупки некоторого времени некоторое давление было устранено. Это вернуло некоторую надежду в команду, и мы начали усердно работать навсегда. 6 месяцев спустя я был продвинут на руководителя проекта, и 9 месяцев спустя у нас была наша отправка фиксации (много демонстраций прогресса и явно более удовлетворенного промежуточного клиента).

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

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

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

Вещи могли бы отличаться для Вас, но, чтобы Вы решили.

Удача

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

0) опции добавляющего Остановки или функции через команду. Позвольте ошибкам быть обращенными, в то время как следующие шаги подняты к шагу 5, затем остановите устранение ошибки & возобновите разработку комплекта:

1) Применяют то, что я называю Обратный Закон об Укомплектовании персоналом: Более слабые члены команды замедляются лучше и более быстрые, и обычно для последнего проекта программного обеспечения нужны удаленные люди, не добавленный. Так, необходимо оценить качество членов команды как отдельные участники. Устраните более слабый штат из команды потому что, по-видимому, существуют некоторые. Это лучше всего сделано путем рассмотрения их кода и исследования их исправлений ошибок и фигуры, кто делает код хуже по сравнению с лучше, и прервите их для команды. Это не время наставнику, Вы испытываете необходимость в лучших людях, чтобы иметь изменение "фиксации" ситуации в оптимальный промежуток времени. Если Вы не можете уволить их или повторно присвоить им, иметь их получающий кофе или что-то для всех остальных оставленных.

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

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

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

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

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

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

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

Удачи!

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

Прежде всего будьте разрешены, что можно перестать работать - если Вы не можете признать, что, не берите проблему. И это включает быть козлом отпущения (это действительно происходит). Управление не посмотрит на него в тех терминах (т.е. они намеренно/сознательно 'не настраивают Вас'). Но это - действительность корпоративной среды; при принятии ответственности (часто с большим количеством платы, чем те, которые не делают), то голова для блока, если вещи не удаются. Необходимо быть готовы придерживаться его для долгого пути также. Я был когда-то размещен в клиентский сайт на 8 месяцев для фиксации уменьшающегося проекта. И как Вы видели, один из других плакатов блога здесь потратил за 9 месяцев до того, как версия выпуска была готова.

Теперь, принимая Вы хорошо с возможностью его идущий все грушевидные несмотря на Ваши усилия, это - то, что я предлагаю:

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

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

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

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

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

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

• я рекомендовал бы против Вас или Вашей команды кодирования, работающей смешные часы поставить. если Вы обычно уезжаете в 17:00, уезжаете в 18:30 или 19:00 вместо этого. Вы и Ваши кодирующие мальчики можете последовательно поддерживать час или две из дополнительной работы в течение многих недель подряд и возможно 4-5 часов за выходные. работа до 21:00 или 22:00 каждую ночь будет приводить к перегоранию примерно через 2 недели (некоторые могут пойти дольше). после той точки Ваше дополнительное время на проекте причиняет больше вреда, затем хорошего. в маловероятном случае Ваш босс не соглашается с этим, сделайте выбор; сделайте то, что они спрашивают (т.е. работа больше часов) или говорят, что "я уже передал дополнительные часы работе над этим проектом - я здесь для долгого пути, и я собираюсь сделать этот проект, если это - смерть меня. но это - предел того, сколько времени я готов вставить. у меня есть другие обязательства сохранить за пределами работы" < - , но быть готов к последствиям (помнят, политическая ситуация так же как техническая).

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

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

• сборка - в утилитах восстановления, особенно если программное обеспечение имеет повторяющиеся проблемы, которые трудно прикрепить вниз. например; может потребоваться 12 часов, чтобы разыскать ошибку и зафиксировать его, может потребоваться 2 часа, чтобы вставить утилиту (чтение 'взлом') для решения проблемы в настоящее время. время и импульс имеют essessen, и к сожалению временные меры могут быть необходимы.

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

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

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

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

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

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

Убежавший или находят новое задание. Это марш смерти , и им нужна коза ствола колонны.

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