Как вы управляете проектами, оставленными другими сотрудниками? [закрыто]

Бывает, что кто-то внезапно покидает компанию. Теперь его работа должна быть завершена, и вам назначают ее. Не зная, что он задумал (было сделано 90% или 9%), как вы справляетесь с остатком?

1. Должен ли я начать с нуля? Что, если это было сделано на 90%?
2. Должен ли я попытаться понять, что он сделал? Что, если это была просто чепуха?

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

Итак, начните с быстрого просмотра всего источника и посмотрите, что у вас есть. Если это ясно, тогда легче всего закончить то, что отсутствует. Проведите юнит-тесты, чтобы узнать, что работает, а что нет.

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

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

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

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

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

Затем вы можете снова сесть с вашим менеджером, чтобы принять решение.

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

1) Остатки этого проекта 2) Причины, по которым вы попали в этот беспорядок в первую очередь

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

В любом случае, вам нужно немедленно предпринять следующие шаги:

а) Скажите своим менеджерам, что у вас большая проблема

б) Получить спецификацию проекта и получить полное представление о том, что вам нужно достичь - или поговорить со спонсорами проекта, если нет спецификации.

с) Обсуждение с менеджерами / клиентов и т.д. , и выяснить , если у кого есть / думает , что они имеют какие - либо идеи , что состояние проекта есть.

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

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

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

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

Сделав все это, вы сможете оценить, сколько еще осталось сделать.

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

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

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

Затем вам нужно будет рассмотреть, какая документация была оставлена. Есть ли письменные требования? Существуют ли конкретные задачи - отслеживаются ли задачи каким-либо образом? Кто-нибудь проверял это - если так, они будут знать, что сделано, а что нет.

Я думаю, что план действий будет:

1. Отметьте, какие требования были выполнены (путем быстрого просмотра системы, как это сделал бы тестер)

2. Посмотрите на код - вы можете понять это? Это хорошо написано?

Ясно, что если все готово на 90%, а код хорошо написан, вы просто доработаете его.

Пока не упоминается.

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

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

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

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

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

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

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

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

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

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

Как только вам удастся спасти проект, не забудьте похвастаться этим в следующем обзоре производительности.