Каждый разработчик сталкивался с тем, что проект пошёл не так, как надо, и если вы этого не сделаете, то вы это сделаете. Чтобы помочь вам решить, когда что-то пойдет не так, у нас есть несколько красных флажков программного проекта, на которые следует обратить внимание. Мы также дадим несколько советов, но в некоторых случаях просто пора заканчивать.
# 1 Плохие требования
Плохо определенные или плохие требования в проекте — это поцелуй смерти для большинства проектов. Для программиста строгие и четко определенные требования являются краеугольным камнем успешного проекта. Без этого даже клиент, как правило, не уверен в том, каким будет конечный результат.
Ожидания и плохая коммуникация — это то, что в конечном итоге убьет проект, но требования — это то, где мы начинаем видеть трещины. На самом деле у нас есть целая статья как раз о разработке требований, которую вы можете найти здесь. Предполагая, что требования не могут быть сохранены, проект следует отклонить до того, как он будет разработан.
# 2 Ползучесть области
Расползание масштаба — еще один распространенный убийца проекта. Это позволяет кому-то добавить в проект дополнительный объем, сохраняя при этом сроки и бюджет точно такими же. Лучший способ справиться с расползанием масштаба — выделить больше времени для требований и работы над MVP. Если ваш новый объем прописан в четко определенных тикетах, он будет оцениваться отдельно.
Как правило, учет такой степени детализации должен остановить расползание области действия. Расползание масштаба обычно связано с плохим управлением клиентами и рабочими процессами. Если вы управляете клиентами и ваши рабочие процессы настроены правильно, вы не столкнетесь с этой проблемой.
#3 Технические трудности
Не просто песня Racer X. Технические трудности охватывают широкий круг тем, в первую очередь технические подвиги, которые невозможны или потребуют гораздо больше времени, чем позволяет первоначальный график. В основном это происходит из-за того, что сами разработчики не имеют достаточного опыта работы с проектами определенного типа.
Лучшее, что здесь можно сделать, — это учесть стадию прототипирования, на которой вы сможете построить разумное доказательство концепции. Тогда вы сможете лучше оценить, что потребуется для создания полного проекта.
