Какое‑то время я участвовал в различных ролях в проекте с вендором по поддержке и развитию российского модуля «Расчеты с персоналом» в Microsoft Dynamics AX. И недавно, просматривая нарезку из интервью директора по продуктам и программам «АвтоВАЗа» Олега Груненкова блогеру Амирану Сардарову, меня триггернула фраза: «Можно, а зачем?». Ведь очень похожий ответ мы получали от представителей вендора на большинство наших предложений по улучшению модуля в системе. Почему производители так делают и что за этим стоит

Наверное, я не открою секрет, что, как и за очень многим в этом мире, за этим стоят деньги. Какой бы ни была компания, она всё равно принимает все решения исходя из того, сколько это будет стоить и сколько это принесёт денег. И неверно, чем компания больше, тем эта взаимосвязь сильнее. Если в молодом стартапе founder может поставить всё на zero в надежде вытянуть счастливый билет, то в корпорации — огромное количество флажков, за которые никто заходить не будет.

И чем зрелее продукт, тем выше стоимость изменений и цена ошибки.

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

Если сравнивать разработку для вендора с обычной разработкой (что собственной, что заказной), то, кроме обычных этапов разработки, пусть и доведенных до предела: спецификаций всех типов, прошедших все возможные согласования; программного кода, не просто работающего, а оформленного по всем правилам и стандартам (наименования, пробелы и отступы); инструкций, результатов тестирования и т. п., — был еще отдельный челлендж в виде «совместимости версий». То есть при создании нового или, ещё хуже, изменении старого функционала нужно было не просто очень хорошо все сделать, но и как‑то обеспечить возможность автоматической установки этого обновления на предыдущую версию от вендора с миграцией всех связанных исторических данных. И неважно, что автоматически это никто не ставил, так как все внедрения содержали свои локальные доработки, — но это было требованием лицензионного соглашения.

Таким образом, эта совместимость не только съедала существенную часть бюджета, так как требовала по факту отдельной реализации, как и сама исходная доработка, но и существенно ограничивала манёвр для нововведений, чтобы технически вообще можно было трансформировать одно в другое.

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

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

Продолжение обязательно будет