Подрядчики-интроверты и их тихая роль в вашем банкротстве

Мы в Зионек не психологи, а разработчики – специализируемся на сложной интеграции, внедряем CRM, разрабатываем интернет-магазины и сложные высоконагруженные порталы. Тем интереснее, что именно мы совсем недавно сделали маленькое открытие в психологии — мы обнаружили, что помимо людей-интровертов, существуют ещё и компании-интроверты. Ниже — история о том, какие потери вас могут ожидать, если нанять на ключевую задачу в вашем бизнесе компанию-подрядчика, которая является скрытым или явным интровертом.

Для начала — что я имею в виду? Представьте себе типичного интроверта, но только — не человека, а целую компанию. Такая компания-подрядчик старается поменьше говорить с заказчиком. В такой компании никто не пытается вникнуть в его процессы; вместо этого, все действуют попроще: вот заказчик сформулировал задачу, как смог — и подрядчик-интроверт ничего не уточняет. Он просто делает «как нам сказали».

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

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

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

Вернёмся, однако, к нашей истории и нашему открытию. Некая успешная компания (назовём её «Чашки Ltd.» — мы бы не хотели, чтобы эту компанию можно было идентифицировать), продающая свою услуги и товары через интернет, приняла решение обновить дизайн своего сайта, а также улучшить свои внутренние процессы и внедрить CRM. Для работ по сайту они пригласили студию веб-дизайна, а когда основные работы по редизайну были завершены, пригласили нас для внедрения CRM.

Хотя наша работа практически никак не касалась сайта, заказчик нам его показал — «посмотрите, как нам красиво переделали сайт!» — и мы его внимательно изучили. И увидели, что там применены фундаментальные архитектурные решения, которые обязательно должны приводить к сбоям в работе сайта и к сбоям приёма платежей. Напомню, что это была новая версия сайта.

Заказчик сразу подтвердил нашу уверенность. «Ну да, так и есть, обновление у банка выходит, — и мы не можем принимать оплату. Ищем программиста, чтобы всё поправить. А у него времени нет, и ничего не работает. Всегда у нас так было».

За много лет, «Чашки Ltd.» привыкли к постоянно возникающим техническим проблемам на своем сайте. Не будучи техническими специалистами, они думали, что иметь сайт — автоматически означает иметь проблемы с сайтом. Но мы-то с вами знаем, что это совсем не так!

Конкретно, речь идёт о том, что на сайте, сделанном на основе 1С-Битрикс: Управление Сайтом (БУС), все модули e-commerce — то есть модули интеграции с банками для приёма оплаты на сайте — были кастомной разработки, то есть «самописные». Другими словами, разработчики не использовали стандартные (бесплатные!) модули оплаты, имеющиеся для Битрикс. Вместо этого, для каждого банка и способа оплаты они разработали «с нуля» собственные решения. Это и было фундаментальной архитектурной ошибкой.

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

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

Может быть много причин, почему сайт изначально, в своей первой версии, был сделан на базе архитектурных решений, которые сейчас оказались очевидно ошибочными. Почему разработчики с самого начала не подключили стандартные модули оплаты?

Возможно, что в первых версиях сайта вообще не было планов принимать оплату онлайн. Или были ещё какие-то соображения, но так или иначе, на сайте на основе 1С-Битрикс Управление Сайтом, разработчики изначально не стали использовать модуль Интернет-магазин (и это сделало невозможным впоследствии применение стандартных модулей приема платежей Битрикс без глубокой переделки сайта).

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

Тем временем, компания «Чашки Ltd.» продолжала расти. Технические проблемы усугублялись с усложнением сайта и ростом трафика, однако команда компании, полностью погруженная в свой бизнес и своих клиентов, при найме веб-студии для улучшения сайта сформулировала свои пожелания к новому сайту просто как «хотим улучшить дизайн». К несчастью заказчика, студия оказалась подрядчиком-интровертом: не задавая вопросов и никуда более не вникая, дизайнеры взялись за красивость сайта. Они вообще ничего не сказали заказчику о фундаментальных технических проблемах, которых не могли не видеть. Они не предложили сделать хорошо. Сейчас, при переделке сайта, был бы прекрасный момент избавиться от наследия неправильных решений и наконец сделать сайт, который будет работать без сбоев. Однако, подрядчик оставил очевидные архитектурные ошибки системы вне поля своего внимания.

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

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

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

Мы поговорили с разработчиками из этой студии, и оказалось, что за всё время работы они ухитрились ни слова не сказать заказчику о фундаментальных проблемах на его сайте (то есть в их зоне ответственности) просто потому, что, по их мнению, у них была другая задача.

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

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

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

Поэтому, если мы видим, что что-то не так, мы клиенту сразу прямо об этом скажем, и обязательно возьмем у него ясное и четкое подтверждение — вы правда хотите дальше платить за кастомное решение? Вы точно уверены? Вы посчитали и знаете, сколько это будет вам стоить в перспективе? Мы 20 раз зададим вопрос, прежде чем сделаем неправильно.

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

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

Итак.

1. В среднем, каждый модуль в 1С-Битрикс: Маркетплейсе обновляется 3 раза в год (но бывает, когда и 8 раз обновляется модуль) (на примере Сбера https://marketplace.1c-bitrix.ru/solutions/sberbank.ecom2/#tab-log-link и Альфы https://marketplace.1c-bitrix.ru/solutions/kupilegko.payment/#tab-log-link )

2. В минимальном варианте, с учетом тестирования на тестовых стендах и релизе, одно обновление будет занимать 10 часов.

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

4. Средняя стоимость часа, на момент написания этой статьи, около 3 000 руб, если покупать у компаний, и 2 000 — если у фрилансеров (хотя они тоже сейчас подтягиваются по ценам).

Давайте теперь переведём эти часы в рубли. Допустим, интеграций всего три (хотя на деле их часто больше). Допустим, каждая ломается всего три раза в год (хотя на деле, мы видим, что Сбер, например, обновляется и 8 раз в год). И еще вам нужно предложить покупателям еще один новый вид оплаты. При таких условиях — ваши прямые затраты составят минимально 500-600 тысяч рублей. Однако не забудьте прибавить время, которое вам придется отнять от ваших рабочих задач, чтобы скоординировать и организовать всю эту дополнительную работу.

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

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

Итак, что же мы видим? Мы видим, что неправильное архитектурное решение обходится очень дорого, и так же, как айсберг Титаника, основная часть потерь скрывается от взгляда.

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

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

И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/ и вот наша страница контактов. Пишите, звоните — мы вас поймём, проконсультируем, поможем!

Да и кстати, напишите внизу в комменте — как вам наш комикс? На самом деле, я вытащил для этой статьи картинки из другой истории, но кажется получилось неплохо. Где поставите вашу запятую? :)