Что делать, если вы разработчик в проекте, который заведомо потерпит крах? Если всё очень плохо, и выхода, кажется, нет? Такой вопрос задал один из пользователей в специальном разделе Stack Exchange. Мы выбрали самые интересные ответы.

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

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

Что мне в этом случае делать? Мне работать больше или просто расслабиться? И что сказать менеджеру?

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

1. Дедлайн скоро, а многие из первостепенных функций ещё не окончены;
2. Приложение нестабильно и сложно в использовании;
3. Система очень сложна, в коде трудно разобраться, крайне непросто вносить изменения;
4. Слишком сложная база данных (более 100 таблиц);
5. Мутное управление;
6. Почти никакого автоматизированного или модульного тестирования;
7. Никаких интеграционных тестов, хотя продукт во многом опирается на сторонние системы.
8. На самом деле, мы просто унаследовали этот проект вместе с его бардаком пару месяцев назад — до этого над ним работала другая команда во главе с тем же лидером.

Расскажите о своих сомнениях

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

У менеджеров всегда должен быть выбор, что делать; но ваш долг — оценить ситуацию и что-то донести до них. Пошлите email или оставьте записку на столе, если всё катится коту под хвост.

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

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

Багаж знаний

Потратьте немного времени, чтобы прочесть две книги.

Death March (рус. «Путь камикадзе») — это каноническая книга, которая описывает ущербный управленческий стиль, который широко распространён в сфере разработки программного обеспечения. Из-за сжатия сроков, излишнего усложнения, бесхозяйственности многие проекты плохо заканчивают. Книга помогает понять, что вы не одиноки на этом смертельном марше. Автор Эдвард Йордон классифицирует бесперспективные проекты на 4 категории, в каждой из которых существуют разные стратегии спасения. Иногда единственный выход — просто уйти. Эта книга поможет вам выяснить, какие варианты у вас есть, и узнать, что вы можете или не можете сделать.

Catastrophe Disentanglement написана больше для менеджеров проектов. Она нацелена на то, чтобы помочь отсортировать подорванный проект: что нужно убрать, что нужно вернуть, как донести это до потребителей. «Традиционное» управление проектами часто приводит нас в тупик, и мы не сможем выбраться из него, пользуясь теми же методами. Эту книгу несколько труднее читать, чем «Путь камикадзе», но очень неплохо иметь её на книжной полке.

Останьтесь там же, но имейте варианты

1. Работайте много, но не в ущерб семье или здоровью;
2. Записывайте все критичные решения, особенно если они касаются вашей работы;
3. Продолжайте налаживать связи и имейте несколько запасных вариантов, если ситуация станет слишком сложной или вы станете жертвой массовых увольнений;
4. Попытайтесь не расценивать свой проект как провалившийся. Всем нравятся люди, которые сохраняют хороший настрой и продолжают бороться перед лицом судьбы. Так что оставайтесь таким человеком так долго, насколько это возможно. На рабочем месте всегда хороши боевой дух, мужество и решительность.
5. Если вы предчувствуете провал проекта, значит, вы предчувствуете и разбор полётов. И там каждого настигнет ответственность. Приготовьтесь защищать весь свой код. (К слову, всегда пишите код понятно, чтоб потом проще было за него отчитываться). Если у вас есть письма или фрагменты ТЗ, которые повлияли на ваши действия, тем лучше.
6. На этом разборе полётов сохраняйте бодрый настрой и обоснованно отмазывайтесь, если вас призовут к ответу.

Источник:
Как вести себя девелоперу загнивающего проекта — Цукерберг Позвонит