Как умирают проекты
В теории софт бессмертен, написал раз — используй вечно. На практике все несколько сложнее и снова и снова приходится работать то гробовщиком то некромантом. Делюсь своими наблюдениями и выводами.
Факторы риска
В одной из прошлых статей я уже описывал, что программа это в первую очередь идея, а не реализация.
Пока идея интересна и пользуется спросом — программа будет жить, будучи хоть сто раз переписанной, переделанной и портированной.
Но есть факторы, которые сильно ухудшают шансы на выживание, а то и вообще приводят к преждевременной смерти, даже если проект вполне успешен.
Все практически как у живых людей.
Ниже я расскажу о некоторых из таких факторов, которые наблюдал за свою карьеру в еще живых, полуживых и уже мертвых проектах.
Возможно вам они покажутся знакомыми и позволят сделать определенные выводы о состоянии дел в вашем собственном проекте.
Фактор первый: усложение жизни юзерам
Сложность в использовании, забагованность и нестабильность, медленная работа — для вашего пользователя особой разницы нет.
Для него это все проходит по одной и той же категории:
Никому не нравится делать свою жизнь сложнее чем она уже есть, тем более если это делает какой-то кривой софт, которому даже #бало не набьешь.
вы когда-то давно заняли нишу, где никакого другого софта просто не было, ваше решение — единственное из существующих на тот момент. Поэтому вы легко и просто, никак не вкладываясь в разработку и качество, годами выкручивали пользователям руки: плевали на их требования и пожелания, не реагировали на отчеты об ошибках и так далее — вообщем вели себя как типичный монополист.
И какое-то оно действительно работало.
Но «голодные времена» прошли, а новое поколение юзеров не желает мириться с «древним говном из прошлого», без намеков на любовь к пользователю.
В итоге ваша программа отправляется в музей утиль или в лучшем варианте — на полное переписывание с нуля, c неслабыми рисками провала.
Вообщем вот такой «проектный пох#изм» — первая и самая частая причина смерти проекта.
Фактор второй: потеря актуальности
Кто помнит софт для записи CD и DVD дисков? А плееры типа Winamp? А ведь были еще дискеты и DOS4/GW, который стоял на каждом компьютере.
Вообщем так бывает что софт, даже очень хороший банально теряет свою актуальность и становится ненужным.
Предсказать такое заранее — малореально, остается только адаптироваться и догонять.
Поэтому, например самые успешные из бывших CD-burnerов стали записывать образы на флешки и тем самым выжили, оставшись на рынке.
Современные же тенденции — к все большему абстрагированию от платформы или среды выполнения и сокрытию технических деталей.
Как раз для вычленения идеи и паттернов использования. С прицелом на то что в будущем платформа поменяется.
Например вы знали, что большая часть популярных онлайн-сервисов неоднократно меняла и «движки» и даже языки реализации?
Первые версии Amazon были на Lisp, Си и перле. А Facebook был когда-то реализован на PHP. Также как и Вконтакте, если кто вдруг не знал.
Но интерфейс и паттерны использования — все те же.
Фактор третий: праздность и расслабленность
Многие не понимают что успех вообще и успешный проект в частности — не статичные состояния и не финишная черта, а процесс.
Но только соблазн на все забить и начать отдыхать после достижения первого приличного результата — слишком велик.
И тогда процесс разработки постепенно начинает скатываться:
падает качество кода, появляются заплатки и костыли, пропадают комментарии. В репозиторий начинает попадать нерабочий код.
Затем скатывается и управление проектом: исчезает релиз-цикл, релизные ветки, метки сборки.
Все это часто происходит на фоне частой смены и руководства и членов команды разработки. С разрывом цепочки передачи проектных знаний — пришедшие новые сотрудники вынуждены изучать полученный проект «на бегу», попутно решая горящие проблемы.
Естественно что ни к чему хорошему это не приводит и чаще всего заканчивается закрытием такого проекта.
Если проект большой и более-менее стабильный — приходит другая напасть:
Нанимаются дорогие консультанты, рисуются презентации и ваяются бесконечные прототипы и демо.
В то время как основная стабильная версия никак не развивается и медленно устаревает.
Проходит какое-то время и разочарованные пользователи уходят не видя развития, а демо и прототипы так никогда и не доводятся до ума:
реализовать прототип на Scala + sbt + jRebel — это одно, сделать на таком крупный проект — сильно другое.
Дорогие консультанты очень о многом не говорят, даже за деньги.
Фактор четвертый: соитие со слоном
Не совсем то о чем вы подумали, но полагаю что «то самое» тоже заканчивается плохо. Вообщем так получилось, что ваш софт обслуживает крупный бизнес. Условного слона.
В этом есть как очевидные материальные плюсы так и минусы — в виде очень большого риска порвать рабочее отверствие адаптировать софт в будущем под кого-то попроще.
Я уже писал как-то, что каждая крупная компания — уникальна, в том числе уникальна и ее внутренняя ИТ-инфраструктура.
Поэтому ориентируясь лишь на «слонов», проект рискует умереть сразу после того как такой слон перестанет его пользовать — частая история для корпоративного ПО.
создать нечто настолько адаптируемое что его смогут использовать в работе сразу несколько крупных компаний-слонов и не порвать.
Получается не сразу, не у всех и не всегда.
Поэтому Siebel CRM такой один, как и SalesForce.
Большинство таких проектов — умирают.
Эпилог
Мне сложно дать однозначную оценку этому явлению — смерть проекта:
Стоит ли пытаться реанимировать, переделывать, восстанавливать или просто забить и похоронить? Все-таки софт это не живой человек, моральной дилеммы никакой нет.
Поэтому основной мотив тут все же экономический:
Насколько это разумно, будет ли интересно и окупится ли — серьезные вопросы, на которые вам стоит ответить перед началом «реанимации».
А я лишь могу с этим делом помочь — пишите.