Привет, Хабр. На связи Максим Иванов, директор по развитию компании Modus.
Сегодня хочу поговорить про «наболевшее». Я лично и мы в целом в компании любим и свою работу, и наших заказчиков. Российский рынок в целом сложный – сложнее только Ближний Восток и Азия, и ему присущи свои «вредные привычки, но иногда попадаются заказчики, проекты которых в самом начале «пахнут жареным». Про такие привычки и про то, какие проекты и каких заказчиков мы не берем, я и расскажу.
Заказчики в Европе и в России
Итак, каков портрет среднестатистического крупного заказчика «не из РФ» - например, из Европы или США.
В большинстве своем (примерно 90%) – это частный бизнес, основная цель которого – получить прибыль. Те компании, которые работают по госзаказу, в основном, не имеют ничего общего с классическим российским госзаказом: они значительно меньше наших госкорпораций, например, «Ростеха» или «Ростелекома», и просто выполняют заказы со стороны государства или работают по схеме грантовой поддержки. Соответственно, собственники скрупулезно просчитывают не только стоимость внедрения IT-решений, но и владения, и экономят бюджет.
Соответственно, чаще всего западные заказчики берут «коробку» и подстраивают свои процессы под нее, если это требуется. «Кастом» заказывают редко, если это изначально не заказная разработка. Вендора выбирают по функционалу, по надежности, количеству внедрений и т.п.
В России – ровно наоборот: заказчик, который берет «коробку» – это редкость, прямо пропорциональная тому, как европейцы покупают «кастом». Из-за хаотичности процессов подстроить процессы под систему – нереально. И вот тут, на этапе составления ТЗ и работы над проектом начинается самое «интересное».
Как не нужно делать, если Вы - заказчик
Ниже – типичные паттерны поведения. Так и хочется добавить – «постарайтесь так не делать!».
1. Перенос хлама из старой системы
Заказчик просит перенести старые фичи и функционал, чаще всего, даже не анализируя, используются они или нет. Т.е. из старой системы, которую хотят заменить, пытаются перетащить весь балласт, от которого, по идее, как раз нужно избавиться. Учитывая, что некоторые системы работают пять лет и больше – представьте, сколько всего ненужного там скопилось.
2. Сохранение не нужного платного ПО
Почти похожая ситуация – хотят оставить плагины, платные расширения и т.п., которые приобретались для предыдущей системы. И, опять-таки, не влияет, насколько часто ими пользуются, насколько они удобны и можно ли сделать по-другому и т.п. Просто хотят сохранить бюджет, потому что – что? – правильно, предыдущая разработка тоже была кастомной.
1 и 2 пункты, в целом, решаемы. Да, это приводит к долгим, сложным переговорам, но, как правило, удается убедить сохранить только то, что действительно нужно.
3. Правки ради правок, разрозненные требования
Почему-то во многих компаниях считается, что если сотрудник не внес свою лепту или ценный комментарий, то он не эффективен и зря занимает место в рабочей группе. Поэтому один из плохих «советов» - это собрать комментарии со всех, независимо от того, разбираются ли они в тематике или нет, и внести все в ТЗ. Не нужно так.
4. Заказчик пытается сложить все фичи от разных вендоров в один продукт
Самый плохой вариант. То есть, некоторое время компания исследует рынок и отмечает для себя понравившиеся фичи (спойлер – которые могут друг с другом никак не состыковываться). В итоге вместо ТЗ получается Франкенштейн, за которого не хочет браться ни один опытный вендор. Если такой все-таки находится, то, как правило, проект погрязает просто в огромном количестве бесконечных доработок, правок и переделок, потому что все работает не так, как хотелось бы.
У нас есть пример, когда заказчик 4 года собирает требования с разных вендоров. На этот рыночный ресерч они потратили очень много денег, но, судя по еще одной анкете, до сих пор не пришли к какому-то решению. Напомню – 4 года.
Еще один пример: компания «Галактика» пошла по примерно такому пути: они начали сами, как вендор, внедрять в «Юкосе» решение-Франкенштейна. И под активной непрекращающейся кастомизацией они закончились, как бизнес, и не смогли развиться во что-то большее, хотя в то время они были лидером на рынке.
Обычно, такие ситуации видно, и мы в них стараемся не участвовать.
5. Максимально - собственная разработка, минимум внешних решений.
Пример – Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются. При этом, огромные корпорации этим мешают развитию рынка, потому что они или скупают потенциальных конкурентов (но это общемировой опыт, тут наши не исключение), или разрабатывают нерелевантный продукт, пылесосят рынок труда и т.д.
Я склоняюсь к тому, что все вышеперечисленное - это следствие особого этапа рынка и его сегментов. Госкорпорации аккумулируют огромные бюджеты, отношение к которым отличается от частных компаний. Причин множество и они, в общем-то, не про коррупцию, а про организационные проблемы и особенности законодательства.
Любая доработка для заказчика - это дополнительные расходы на специалиста, который должен появиться в штате или быть нанят и будет поддерживать и развивать отдельный продуктовый трек. При этом, часто клиенты хотят разработать кастомную фичу, но стоимость разработки переложить на вендора, т.к. он потом будет ее «продавать».
Вендор же, в свою очередь, выпуская любой релиз должен учитывать совместимость с кастомом. Соответственно, он может реализовать фичи только в продукте, а не у конкретного заказчика. При этом, если вендор не проведет анализ спроса, то может оказаться в ситуации, когда эта фича затем оказывается ненужной ни одному заказчику или очень редко используется. И это превращается в 2 проблемы:
1. Он не может это продать кому-то еще.
2. Вынужден тратить деньги на поддержку этой фичи, т.к. если хотя бы один заказчик ею уже пользуется – то нужны развитие, техническая поддержка, багфиксинг, тестирование, отладка при новых релизах и т.д.
Альтернатива – выделение отдельных блоков в самостоятельные плагины, которые дорабатываются и покупаются отдельно. Чтобы создать свой маркетплейс плагинов, вендор должен до этого дорасти.
Вывод один – подбирать заказчиков также тщательно, как они подбирают вендора. И ждать - рынок будет меняться постепенно, синхронно со зрелостью и большей коммерциализацией (спойлер –нет).
Комментарии (7)
saboteur_kiev
10.11.2023 16:36+6Учитывая, что некоторые системы работают пять лет и больше – представьте, сколько всего ненужного там скопилось.
"Системы" обычно работают гораздо дольше. Некоторые системы за 5 лет едва успеваешь нормально написать, вообще не понимаю что это за предприятия, которым нужен кастомный софт, и для которых 5 лет это уже старье и ненужное...
SpiderEkb
10.11.2023 16:36+3Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются
Вы привели пример компаний, которые ничего не собираются продавать. Все, что они делают - делают исключительно для себя, для автоматизации собственных бизнес-процессов.
У нас (Альфа-Банк) все ровно точно также. Мы не продаем программный продукт. Мы банк. Но у нас огромное количество бизнес-процессов, которые требуют автоматизации.
Если говорить о той конкретной области, где работаю я. Это "Управление разработки центральных банковских систем". То, что работает на центральных серверах. Автоматизированная Банковская Система (АБС).
Сразу скажу, что центральные сервера у нас работают на специфической платформе IBM i. АБС (точнее, ее ядро) было когда-то выкуплено вместе с исходниками (и это не российская разработка).
С тех пор в АБС было внесено огромное количество изменений и дополнений - где-то что-то изменяется в бизнес-процессах, где появляются новые. Меняются (или появляются новые) требования законодательства или регулятора... Где-то проводится оптимизация существующего. Доработки ведутся постоянно.
Естественно, что вести доработки силами своей команды для банка выгоднее (это было установлено еще лет 6-7 назад, если не больше).
Любая доработка делается и внедряется быстрее своими силами чем каждый раз договариваться с вендором
Любая доработка обходится дешевле своими силами чем каждый раз заключать договор с вендором.
Платформа в РФ распространена мало - вендоров с достаточном уровнем экспертизы по этому стеку (а это и платформа и специализированный язык на ней) практически нет (есть пара-тройка, мы с ними сотрудничаем, но достаточно ограниченно). У нас же за последние годы собрана сильная в этой области команда разработчиков.
Так что ваш пример неудачен. Это не тот случай, когда компания один раз купила продукт (пусть даже кастом) и потом им пользуется без внесения изменений. В крупных корпорациях выгоднее держать свои отделы разработки которые будут заниматься оперативной доработкой и поддержкой системы, автоматизирующей все бизнес-процессы.
GospodinKolhoznik
10.11.2023 16:36+2Пункт 1, про перенос "хлама" можно свести к "пишите функционал, который надо писать и не пишите, который не надо". Отличить одно от другого, это задача на порядки более сложная, нежели просто написать код. И конечно, исполнителю очень хотелось бы, чтобы заказчик её каким то волшебным образом решил. Но это так не работает.
aik
10.11.2023 16:36+1Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются
Чья проблема-то? Эти корпорации не собираются ни с кем конкурировать, они разрабатывают продукт под себя. Зачем им его продавать? А свой отдел разработки гораздо более оперативен и гибок, чем сторонние вендоры и интеграторы.
SpiderEkb
10.11.2023 16:36+2В целом недовольство понять можно - хочется присосаться к жирному клиенту.
Но тут есть еще один момент - внутренние разработчики ближе к внутренним же бизнес-процессам и более погружены в конкретную предметную область. Что дет еще одно преимущество внутренней разработке перед внешней.
Кроме того, у нас еще есть принципиальное условие - все исходники контролируем мы. Ради этого были выкуплены исходник нашей АБС. Ради этого, даже при работе с вендорами, приемка идет на уровне исходных кодов (код-ревью делаем мы, поставки собираем и тестируем мы, аналитика тоже наша). Тут все просто - банк не хочет ставить себя в зависимость от вендора в плане mission critical инфраструктуры.
Вообще вендоры у нас привлекаются в тех случаях, когда не хватает своих, внутренних, ресурсов. И это всегда получается и дольше и дороже (как-то проскакивала стоимость, заявленная вендором за неделю разработки - наш разработчик в месяц получает кратно меньше). А иногда еще и с качеством бывают проблемы (у нас бывали ситуации, единичные случаи, но бывали, когда приходилось в категорической форме отказываться от конкретного разработчика на стороне вендора т.к. его уровень не удовлетворял нашим запросам).
SmileyK
10.11.2023 16:36+1Статья конечно будет в минусах, так технический портал и тут больше взгляд с колокольни коллег с области их работы внутри компании.
У нас есть пример, когда заказчик 4 года собирает требования с разных вендоров. На этот рыночный ресерч они потратили очень много денег, но, судя по еще одной анкете, до сих пор не пришли к какому-то решению. Напомню – 4 года.
да, такое присутствует не в компаниях где бюрократизированный процесс и зачастую пока они выбирают вектор автоматизации и решения тут либо уже этот проект не нужен, либо продукт уже совсем не тот за тот период пока выбирали.
5. Максимально - собственная разработка, минимум внешних решений.
Тут направление отнюдь не бюджетов(не только) даже и не желания вести прям принципиально свою разработку, данные компании изначально идут с вектором построения экосистем и агрегируя в себе максимально возможное количество сервисом для их предоставления собой - что будет если они наберут кучу коробок которые покрывают от части какой-то функционал. а потом пойдут в интеграцию этих коробок между собой это большие расходы как финансовые так и временные для обсуждения с каждым вендором, а можно ли это делать и так далее, естественно и вендора такие разработки будут считать "кастомными" и так как это компания поставщик она нацелена давайте не будем забывать на получение прибыли.
когда приходилось в категорической форме отказываться от конкретного разработчика на стороне вендора т.к. его уровень не удовлетворял нашим запросам).
Так же коллега выше правильно говорит, вендор просто решит задачу костылем так как это кастомная для него разработка, а заказчик имея такой костыль не сможет далее оперировать где-то этим костылем...
Я думаю обсуждение отдельной (собственной разработки это совсем другое направление.
Но в целом да, не желание приобретать коробку связанно с тем, что зачастую не компетентный персонал, сам не знает чего хочет и не знает что будет нужно в будущем для формирования четкого требования к коробки и ее возможной кастомизации или ее интеграции.
..Так же нужно не забывать, что своя разработка тоже выходит не дешевая, когда вы разрабатываете что-то большое вам нужна большая экспертиза, а это взращивание собственного персонала, поддержание но тут да несомненный плюс возможности быстрой гибкости, кастомизации и самостоятельности.
ncix
Обычно вендоры всё-таки стараются не лезть во внедрение. Понятно что не всякому Газпрому получается отказать, если он захочет видеть в проекте именно вендоров, но всё же описанные боли - это больше к интеграторам.
К особенностям добавлю гигантские сроки запуска проектов. От формулирования потребности до запуска тендера в некоторых ГБУ и даже ПАО легко может пройти год и больше, даже если все участники процесса в этом реально заинтересованы.
И, не знаю как на западе, но у нас собирает потребности и пишет ТЗ обычно не заказчик а будущий подрядчик.