«Вредные привычки» российских IT-заказчиков
Привет, Хабр. На связи Максим Иванов, директор по развитию компании Modus.
Сегодня хочу поговорить про «наболевшее». Я лично и мы в целом в компании любим и свою работу, и наших заказчиков. Российский рынок в целом сложный — сложнее только Ближний Восток и Азия, и ему присущи свои «вредные привычки, но иногда попадаются заказчики, проекты которых в самом начале «пахнут жареным». Про такие привычки и про то, какие проекты и каких заказчиков мы не берем, я и расскажу.
Заказчики в Европе и в России
Итак, каков портрет среднестатистического крупного заказчика «не из РФ» — например, из Европы или США.
В большинстве своем (примерно 90%) — это частный бизнес, основная цель которого — получить прибыль. Те компании, которые работают по госзаказу, в основном, не имеют ничего общего с классическим российским госзаказом: они значительно меньше наших госкорпораций, например, «Ростеха» или «Ростелекома», и просто выполняют заказы со стороны государства или работают по схеме грантовой поддержки. Соответственно, собственники скрупулезно просчитывают не только стоимость внедрения IT-решений, но и владения, и экономят бюджет.
Соответственно, чаще всего западные заказчики берут «коробку» и подстраивают свои процессы под нее, если это требуется. «Кастом» заказывают редко, если это изначально не заказная разработка. Вендора выбирают по функционалу, по надежности, количеству внедрений и т.п.
В России — ровно наоборот: заказчик, который берет «коробку» — это редкость, прямо пропорциональная тому, как европейцы покупают «кастом». Из-за хаотичности процессов подстроить процессы под систему — нереально. И вот тут, на этапе составления ТЗ и работы над проектом начинается самое «интересное».
Как не нужно делать, если Вы — заказчик
Ниже — типичные паттерны поведения. Так и хочется добавить — «постарайтесь так не делать!».
1. Перенос хлама из старой системы
Заказчик просит перенести старые фичи и функционал, чаще всего, даже не анализируя, используются они или нет. Т.е. из старой системы, которую хотят заменить, пытаются перетащить весь балласт, от которого, по идее, как раз нужно избавиться. Учитывая, что некоторые системы работают пять лет и больше — представьте, сколько всего ненужного там скопилось.
2. Сохранение не нужного платного ПО
Почти похожая ситуация — хотят оставить плагины, платные расширения и т.п., которые приобретались для предыдущей системы. И, опять-таки, не влияет, насколько часто ими пользуются, насколько они удобны и можно ли сделать по-другому и т.п. Просто хотят сохранить бюджет, потому что — что? — правильно, предыдущая разработка тоже была кастомной.
1 и 2 пункты, в целом, решаемы. Да, это приводит к долгим, сложным переговорам, но, как правило, удается убедить сохранить только то, что действительно нужно.
3. Правки ради правок, разрозненные требования
Почему-то во многих компаниях считается, что если сотрудник не внес свою лепту или ценный комментарий, то он не эффективен и зря занимает место в рабочей группе. Поэтому один из плохих «советов» — это собрать комментарии со всех, независимо от того, разбираются ли они в тематике или нет, и внести все в ТЗ. Не нужно так.
4. Заказчик пытается сложить все фичи от разных вендоров в один продукт
Самый плохой вариант. То есть, некоторое время компания исследует рынок и отмечает для себя понравившиеся фичи (спойлер — которые могут друг с другом никак не состыковываться). В итоге вместо ТЗ получается Франкенштейн, за которого не хочет браться ни один опытный вендор. Если такой все-таки находится, то, как правило, проект погрязает просто в огромном количестве бесконечных доработок, правок и переделок, потому что все работает не так, как хотелось бы.
У нас есть пример, когда заказчик 4 года собирает требования с разных вендоров. На этот рыночный ресерч они потратили очень много денег, но, судя по еще одной анкете, до сих пор не пришли к какому-то решению. Напомню — 4 года.
Еще один пример: компания «Галактика» пошла по примерно такому пути: они начали сами, как вендор, внедрять в «Юкосе» решение-Франкенштейна. И под активной непрекращающейся кастомизацией они закончились, как бизнес, и не смогли развиться во что-то большее, хотя в то время они были лидером на рынке.
Обычно, такие ситуации видно, и мы в них стараемся не участвовать.
5. Максимально — собственная разработка, минимум внешних решений.
Пример — Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются. При этом, огромные корпорации этим мешают развитию рынка, потому что они или скупают потенциальных конкурентов (но это общемировой опыт, тут наши не исключение), или разрабатывают нерелевантный продукт, пылесосят рынок труда и т.д.
Я склоняюсь к тому, что все вышеперечисленное — это следствие особого этапа рынка и его сегментов. Госкорпорации аккумулируют огромные бюджеты, отношение к которым отличается от частных компаний. Причин множество и они, в общем-то, не про коррупцию, а про организационные проблемы и особенности законодательства.
Любая доработка для заказчика — это дополнительные расходы на специалиста, который должен появиться в штате или быть нанят и будет поддерживать и развивать отдельный продуктовый трек. При этом, часто клиенты хотят разработать кастомную фичу, но стоимость разработки переложить на вендора, т.к. он потом будет ее «продавать».
Вендор же, в свою очередь, выпуская любой релиз должен учитывать совместимость с кастомом. Соответственно, он может реализовать фичи только в продукте, а не у конкретного заказчика. При этом, если вендор не проведет анализ спроса, то может оказаться в ситуации, когда эта фича затем оказывается ненужной ни одному заказчику или очень редко используется. И это превращается в 2 проблемы:
1. Он не может это продать кому-то еще.
2. Вынужден тратить деньги на поддержку этой фичи, т.к. если хотя бы один заказчик ею уже пользуется — то нужны развитие, техническая поддержка, багфиксинг, тестирование, отладка при новых релизах и т.д.
Альтернатива — выделение отдельных блоков в самостоятельные плагины, которые дорабатываются и покупаются отдельно. Чтобы создать свой маркетплейс плагинов, вендор должен до этого дорасти.
Вывод один — подбирать заказчиков также тщательно, как они подбирают вендора. И ждать — рынок будет меняться постепенно, синхронно со зрелостью и большей коммерциализацией (спойлер –нет).
