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