Какое‑то время я участвовал в различных ролях в проекте с вендором по поддержке и развитию российского модуля «Расчеты с персоналом» в Microsoft Dynamics AX. И недавно, просматривая нарезку из интервью директора по продуктам и программам «АвтоВАЗа» Олега Груненкова блогеру Амирану Сардарову, меня триггернула фраза: «Можно, а зачем?». Ведь очень похожий ответ мы получали от представителей вендора на большинство наших предложений по улучшению модуля в системе. Почему производители так делают и что за этим стоит?
Наверное, я не открою секрет, что, как и за очень многим в этом мире, за этим стоят деньги. Какой бы ни была компания, она всё равно принимает все решения исходя из того, сколько это будет стоить и сколько это принесёт денег. И неверно, чем компания больше, тем эта взаимосвязь сильнее. Если в молодом стартапе founder может поставить всё на zero в надежде вытянуть счастливый билет, то в корпорации — огромное количество флажков, за которые никто заходить не будет.
И чем старше продукт, тем выше стоимость доработки и цена ошибки. Приведу пример из своего опыта. По моим ощущениям, из всего бюджета на саму разработку новой фичи в этом проекте мы тратили около десяти процентов бюджета. И чем она была сложнее, тем этот процент был только меньше.
Если сравнивать разработку для вендора с обычной разработкой (что собственной, что заказной), то, кроме обычных этапов разработки, пусть и доведенных до предела: спецификаций всех типов, прошедших все возможные согласования; программного кода, не просто работающего, а оформленного по всем правилам и стандартам (наименования, пробелы и отступы); инструкций, результатов тестирования и т. п., — был еще отдельный челлендж в виде «совместимости версий». То есть при создании нового или, ещё хуже, изменении старого функционала нужно было не просто очень хорошо все сделать, но и как‑то обеспечить возможность автоматической установки этого обновления на предыдущую версию от вендора с миграцией всех связанных исторических данных. И неважно, что автоматически это никто не ставил, так как все внедрения содержали свои локальные доработки, — но это было требованием лицензионного соглашения.
Таким образом, эта совместимость не только съедала существенную часть бюджета, так как требовала по факту отдельной реализации, как и сама исходная доработка, но и существенно ограничивала манёвр для нововведений, чтобы технически вообще можно было трансформировать одно в другое.
Поэтому, если это не было законодательным требованием, поддержка которых тоже была закреплена в лицензионном соглашении, у нового функционала почти не было шансов. Это уже не говоря о том, что этот функционал должен еще и подходить всем, то есть в него нужно закладывать гибкость, которая также увеличивает стоимость.
В результате все эти накопленные наработки, с одной стороны, являются рыночным преимуществом решений с историей, но, с другой стороны, висят гирей и мешают их развитию. И сила компании — в умении балансировать между преемственностью версий и инновациями.
Выбирая между готовым решением и разработкой, нужно это учитывать. Мое мнение, что нужно выбирать:
- Готовое решение от крупного вендора, если функционал определен регуляторами, редко меняется, а если меняется, то эти изменения обязательны для всех. И главное, функционал этого решения уже устраивает вас или вы знаете, кто и как вам его доработает отдельно от вендора, так как ждать этих изменений от него можно очень долго.
- Готовое решение от крупного вендора для неформализованных функций, если вы готовы использовать существующий функционал согласно заложенной в продукт методологии, отказавшись от своего видения, и в будущем готовы трансформироваться вместе с видением вендора. Этот кейс иногда осознанно выбирают, когда не могут выстроить процессы изнутри и ломают их под систему от лидера рынка. Но часто аппетит приходит во время еды, и, внедрив такой инструмент, все равно скатываются к своей разработке, чтобы удовлетворить свои потребности, а внедрение коробки просто даёт возможность их лучше сформулировать.
- Готовое решение от мелкого вендора, если вы являетесь его якорным заказчиком и он готов без оглядки на других развивать его под вас, или вы готовы взять эту коробку за основу и дальше развивать его самостоятельно.
- В остальных случаях стоит подумать об заказной разработке (своя — если есть соответствующая культура, а планы развития позволяют загрузить полноценную команду на период, оправдывающий ее найм и слаживание). При этом заказная разработка может быть как с компанией без функциональной экспертизы, но выстроенной системой разработки, так и со стартапом, у которого есть видение этого функционала. И здесь выбор в первую очередь зависит от наличия внутренней экспертизы.
При этом сейчас назревает некоторое разочарование в собственной разработке. У этого может быть много причин, в том числе и технологического характера, но я считаю, одна из главных — это непонимание, что и зачем делается. Вообще, в целом, очень многое зависит от понимания, чего вы хотите и что вам это даст. Любая система с любым способом внедрения (коробка, разработка, внешняя, внутренняя, продукт, проект) ничего не даст, если компания к этому не готова. Просто собственная разработка давала иллюзию возможности начать что‑то делать, а уже потом разберемся, что и зачем.
Продолжение обязательно будет