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

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

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

МегаФон ПроБизнес

Получите Кешбэк 100% за запуск рекламы с МегаФон Таргетом!

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585

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

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

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

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

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

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

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

Новый дизайн со старыми проблемами

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

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

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

И да останутся архитектурные проблемы на сайте во веки веков, аминь

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

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

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

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

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

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

Архитектурные проблемы, о которых молчал подрядчик

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

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

Я хочу обновить дизайн

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

«Заказчик просто сказал обновить дизайн»

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

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

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

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

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

В этой связи нелишним будет сослаться на серию наших статей о том, почему мы отказались от брифов при выявлении потребностей клиентов и разработки ТЗ и чем мы их заменили при внедрении CRM и веб-разработке.

Убытки от подрядчика-интроверта (посчитаем в рублях)

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

В среднем каждый модуль в 1С-Битрикс: Маркетплейс обновляется 3 раза в год (но бывает и 8 раз). В минимальном варианте с учётом тестирования на тестовых стендах и релизе одно обновление будет занимать 10 часов.

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

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

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

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

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

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

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.