Парадокс кастомизации или как не попасть в заложники программистам?
Да, к сожалению очень большая часть компаний находится в заложниках у программистов. Сейчас расскажу – почему.
Мы, как компания, много работаем с предпринимателями, поставляя ИТ-решения, которые помогают организовать бизнес-процессы. Это и интернет-магазин, и CRM, и мобильное приложение и много чего ещё.
Большую часть рабочего времени мы тратим на то, чтобы сделать решение, которое сразу, без доработок можно было бы использовать внутри бизнеса клиента. Однако бывают случаи, когда типовое решение требует доработки. Небольшой, но доработки. Иногда это объективная специфика в работе клиента(у нас нужно чтобы работало вот так, а по другому не получится), а иногда просто самореализация собственника (мы не хотим подстраиваться под мир, пусть мир подстроится под нас).
В итоге, после поиска разных решений рождается запрос на доработку (кастомизацию) ИТ-решения. Чего тут такого, правда? Есть программа, её можно изменить.
Надо сказать, что многие даже начинающие предприниматели исходят из того, что любую штуку под него может разработать программист. Он для этого и программист, чтобы делать так как мне надо, верно?
Что же возникает потом и почему компания берётся в заложники?
Для ответа на этот вопрос нужно в целом понимать как происходит жизнь любой программной штуки, которую использует компания.
Вначале штуку выбирают и покупают, потом внедряют, а потом используют.
В обычной логике человека любую штуку нужно выбрать, купить, ну и если нужно, чуть доработать и использовать.
Этот паттерн мышления(логика), в случае с ИТ-продуктами несёт для бизнеса большую угрозу.
Представим, что софт – это велосипед. Нужно уметь кататься на нём(в основном все этот навык получили в детстве). Выбрали, катаемся.
У ИТ-продуктов есть особенности. Чтобы выбрать – нужно посмотреть на себя(свои процессы) изнутри. Совещания, обсуждения, выбираем варианты, смотрим, тестируем. Время/деньги. Чтобы кататься на этом велосипеде нужно внедрить систему и научить себя и персонал ездить на ней. Пробуем, учимся, консультируемся. Время/деньги. Чтобы ИТ-велосипед ездил – его нужно обновлять/обслуживать. Ну и тут мы мыслим как: ну будет вопрос – обратимся в программисту, который дорабатывал(если была доработка) – он обновит/обслужит. Всё логично.
Но есть нюансы:
1. Внедрив какое-то решение, компании очень тяжело его поменять. Все привыкли, всё уже едет. Менять дорого и долго.
2. Изменения, которые требует ИТ-продукт достаточно много.
Представляем ситуацию на примере велосипеда. Вот едим мы на велосипеде, а дорога по которой мы едем изменилась с твердой на песчаную (государство, например, так решило) и теперь нам экстренно надо поменять колёса. Производитель велосипедов уже подготовил решение – новые колеса, которые сам производитель может и поменять за пару часов.
Но мы когда покупали велосипед решили поменять(доработать) конструкцию рамы под себя и теперь эти колеса не подходят – что делать? А мы едем, остановиться мы не можем, или можем, но не надолго.
Правильно – создавать новые колёса, уже под текущую раму, либо менять раму назад... И тут мы уже никак не обойдёмся без программиста, к которому мы идём на поклон.
Логика думаю примерно понятна.
А теперь представьте, что у вас изменения ни раз в год, а например каждый месяц.
Вы каждый месяц меняете раму, колеса, а еще у вас этих велосипедов 100 штук. В итоге, вы задумываете построить свой цех и самим выпускать велосипед. Но вы не занимались этим никогда... И, вероятнее всего вы это не осилите, и в какой-то момент вы говорите – выкиньте все старые велосипеды и давайте возьмем типовой велосипед от производителя.
Но как же? Нам нужна наша особенная рама... Нет, мы привыкнем ехать на такой, которая у производителя, зато завтра если что-то поменяется – мы быстро адаптируемся.
В общем совет простой – берите типовое решение и используйте его, если нет веских причин делать что-то своё. Если заказываете доработку(кастомизацию) – принимайте решение осознанно, учитывая все риски и потенциальную цену владения ИТ-решением, в противном случае окажетесь в заложниках у программистов(это как раз те ребята, которые умеют создавать новые колеса и новые удобные на первый взгляд рамы).
Учитывайте также – если ваш ИТ-продукт(по аналогии с велосипедом) кто-то доработал(например, повесил туда дополнительный фонарь, а в конструкции он предусмотрен не был) – стоимость владения таким велосипедом не просто увеличивается, а растёт в геометрической прогрессии.
Каждое следующее обновление вашего ИТ-продукта будет стоить всё дороже и дороже. И многие предприниматели этого не осознают на старте, а потом очень сожалеют, что не использовали типовой продукт. Ну сейчас же оно катается и не стоит ничего в обслуживание? Да, сейчас катается, и не стоит. Но в мире ИТ-продуктов изменения гораздо большие, чем при езде на велосипеде. Меняется много чего и это требует обновления и обслуживания системы. Были ли 5 лет назад маркетплейсы? а 10 лет назад мобильные приложения? А как продвигались интернет-проекты 15 лет назад? В мире онлайн-продаж раз в 5 лет происходит как минимум одна революция. И желательно, чтобы вы были к ней готовы, не тратили время на переучивания и пересаживания на новые велосипеды.
Вывод простой: если вы что-то заказали у фрилансера или вы купили продукт и доработали его, то знайте – с вероятностью 100% вы попадаете в зависимость к программистам, потому что обновить эту штуку будет стоить денег и чем дальше, чем дороже.
Какой путь решения тут возможен – если можете – откажитесь от кастомизации и используйте готовые ИТ-продукты, которые обновляются и поддерживаются вендором(типа Адвантшоп). Это позволит вам съэкономить время, деньги и нервы, получая вовремя актуальные обновления. Если же вы объективно решили кастомизировать ИТ-продукт – умножайте стоимость владения продуктов на 10 от стоимости типового продукта. Это будет близкая к реальной оценка.
