project-management
February 27, 2023

Как умирают проекты

В теории софт бессмертен, написал раз — используй вечно. На практике все несколько сложнее и снова и снова приходится работать то гробовщиком то некромантом. Делюсь своими наблюдениями и выводами.

Личное кладбище проектов. Есть у каждого доктора программиста.

Факторы риска

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

Пока идея интересна и пользуется спросом — программа будет жить, будучи хоть сто раз переписанной, переделанной и портированной.

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

Все практически как у живых людей.

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

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

Поехали.

Надеюсь что ваше корпоративное ПО выглядит не так.

Фактор первый: усложение жизни юзерам

Сложность в использовании, забагованность и нестабильность, медленная работа — для вашего пользователя особой разницы нет.

Для него это все проходит по одной и той же категории:

усложенение жизни.

Никому не нравится делать свою жизнь сложнее чем она уже есть, тем более если это делает какой-то кривой софт, которому даже #бало не набьешь.

Да, допустим вам повезло:

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

И какое-то оно действительно работало.

Но «голодные времена» прошли, а новое поколение юзеров не желает мириться с «древним говном из прошлого», без намеков на любовь к пользователю.

В итоге ваша программа отправляется в музей утиль или в лучшем варианте — на полное переписывание с нуля, c неслабыми рисками провала.

Вообщем вот такой «проектный пох#изм» — первая и самая частая причина смерти проекта.

Таким когда-то записывались CD/DVD и даже BlueRay диски.

Фактор второй: потеря актуальности

Кто помнит софт для записи CD и DVD дисков? А плееры типа Winamp? А ведь были еще дискеты и DOS4/GW, который стоял на каждом компьютере.

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

Предсказать такое заранее — малореально, остается только адаптироваться и догонять.

Поэтому, например самые успешные из бывших CD-burnerов стали записывать образы на флешки и тем самым выжили, оставшись на рынке.

Современные же тенденции — к все большему абстрагированию от платформы или среды выполнения и сокрытию технических деталей.

Как раз для вычленения идеи и паттернов использования. С прицелом на то что в будущем платформа поменяется.

Например вы знали, что большая часть популярных онлайн-сервисов неоднократно меняла и «движки» и даже языки реализации?

Первые версии Amazon были на Lisp, Си и перле. А Facebook был когда-то реализован на PHP. Также как и Вконтакте, если кто вдруг не знал.

А теперь там Java и Golang.

Но интерфейс и паттерны использования — все те же.

Nokia знает толк в фейлах и провалах.

Фактор третий: праздность и расслабленность

Многие не понимают что успех вообще и успешный проект в частности — не статичные состояния и не финишная черта, а процесс.

Постоянный процесс.

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

Далеко не все могут устоять.

И тогда процесс разработки постепенно начинает скатываться:

падает качество кода, появляются заплатки и костыли, пропадают комментарии. В репозиторий начинает попадать нерабочий код.

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

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

Естественно что ни к чему хорошему это не приводит и чаще всего заканчивается закрытием такого проекта.

Если проект большой и более-менее стабильный — приходит другая напасть:

бесконечное прототипирование.

Нанимаются дорогие консультанты, рисуются презентации и ваяются бесконечные прототипы и демо.

В то время как основная стабильная версия никак не развивается и медленно устаревает.

Проходит какое-то время и разочарованные пользователи уходят не видя развития, а демо и прототипы так никогда и не доводятся до ума:

реализовать прототип на Scala + sbt + jRebel — это одно, сделать на таком крупный проект — сильно другое.

Дорогие консультанты очень о многом не говорят, даже за деньги.

Иди сюда сладкий

Фактор четвертый: соитие со слоном

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

В этом есть как очевидные материальные плюсы так и минусы — в виде очень большого риска порвать рабочее отверствие адаптировать софт в будущем под кого-то попроще.

Я уже писал как-то, что каждая крупная компания — уникальна, в том числе уникальна и ее внутренняя ИТ-инфраструктура.

Поэтому ориентируясь лишь на «слонов», проект рискует умереть сразу после того как такой слон перестанет его пользовать — частая история для корпоративного ПО.

Это настоящее искусство:

создать нечто настолько адаптируемое что его смогут использовать в работе сразу несколько крупных компаний-слонов и не порвать.

Получается не сразу, не у всех и не всегда.

Поэтому Siebel CRM такой один, как и SalesForce.

Большинство таких проектов — умирают.

Эпилог

Мне сложно дать однозначную оценку этому явлению — смерть проекта:

Стоит ли пытаться реанимировать, переделывать, восстанавливать или просто забить и похоронить? Все-таки софт это не живой человек, моральной дилеммы никакой нет.

Поэтому основной мотив тут все же экономический:

есть ли в этом профит или нет.

Насколько это разумно, будет ли интересно и окупится ли — серьезные вопросы, на которые вам стоит ответить перед началом «реанимации».

А я лишь могу с этим делом помочь — пишите.