Я уже писал статью о крупных лажах, которые я сделал.
Я вот тут покопался в мозгах, прошелся по всем заваленным проектам, которые я знал и разбил их на две категории: Бизнес и технарьская. Правда, и в ту и в другую входят разнообразные менеджерские решения. Просто одни касаются именно проекта с технической стороны, а другие с бизнес стороны.
Технарьские проблемы:
— Очень неправильный изначальный estimate (чаще всего неправильная оценка сложности нескольких крупных задач)
Чаще всего такое происходит в том случае, если кто-то не слишком умелый оценивает проект. Решается чаще всего, тем что это делает не один человек, а два человека, причем хотя бы один из них должен быть хорошо знаком с областью проекта, а второй с большим опытом работы (и estimat’ов).
— Отсутствие технического лидера (или другого опытного человека) на проекте.
Проблема возникает потому, что разработчики решают проблемы ка непопадя и некому увидеть плохое качество решения задач. В конечном итоге, в конце проекта обнаруживается, что весь проект держиться на соплях.
Решение, просто — добавить технического лидера на проект.
— Развития конечного продукта на базе прототипа.
Стандартная проблема. Есть прототип, нужно выпускать первую версию, так как времени мало, то версия строится на базе прототипа. В результате на прототип (с отсутствием архитектуры) наворачивается много функциональности и архитектура не выдерживает такого количества фигни.
Правильное решение, либо привести прототип к нормальной архитектуры, либо не пытаться сэкономить время на стартование с прототипа.
Бизнес проблемы:
— Установка нереалистично коротких сроков.
Тут все просто. Технари говорят, нам нужно 12 месяцев. Бизнес отделение отвечает — есть только шесть.
Зачастую пробелема не решаема. Если вы находитесь на таком проекте — бегите с него к чертовой бабушке. Через 6 месяцев таки обнаружится что время нужно еще и бизнес отделение начнет пинать технарей и искать куда бы слинять, так как денег от продаж ждать надо будет долго.
— Установка завышенных требований к первой версии
Чаще всего это происходит, когда версия номер четыре портируется на другую платформу или копируются чужая программа или пытаются написать идеальную программу. В таком случае, выпуск проекта очень затягивается, так как идет полировка миллиона кусочков проекта.
Правильное решение, выписать какая функциональность абсолютно критична для проекта, какая хороша, какая не особо нужна. И работать только над самой критичной. В случае, если остается время, то можно его потратить на то, что хорошо бы написать.
Даже при портировании нужно разбивать на несколько версий.
— Слишком большое количество разнообразной требуемой функциональности.
Это скорее происходит на версии три-четыре и т.п. Когда программа обвешивается по самое нихочу разнообразной функциональностью, которая зачастую конфликтует с другой функциональности.
Решение это проблемы состоит в том, что раз в пару лет, возможности программы должны пересматриваться и старая и не нужная функциональность должна выкидываться.
— Малое внимание к проекту
Как написал в комментариях eko, зачастую либо заказчик, либо product manager забывает, что если вложить денег и назначить программистов, это еще не значит, что проект будет успешный.
Нужно, достаточно постоянно пробовать программу и сверять, то ли получается, что вообще изначально хотелось или программа начинает мигрировать в непонятную сторону.
Вроде из своего опыта ничего не забыл.
