До работы в Диасофте я двадцать лет был на другой стороне баррикад — работал в руководстве ИТ в банках и страховых компаниях. За это время через меня прошли десятки проектов заказной разработки. Некоторые из них я вспоминаю с гордостью. Некоторые — с содроганием.
Недавно мы с коллегами по рынку собрались в эфире телеграм-канала для разработчиков Dev Q&A обсудить, что вообще происходит с заказной разработкой в России. У нам пришли CTO, техлиды, коммерческие директора — люди, которые каждый день варятся в этом котле: Роман Смирнов («Девелоника»), Андрей Почтов (АЭРО), Олег Елманов (Fusion), Яна Шакленина (Outlines Tech), Алексей Сушков («Севен Груп»), Тимур Васильев (Tech Lead, USA), Павел Куликовский (Цифра Банк), Алексей Каньков (Revizto).
Говорили о том, почему иногда проекты превращаются в лотерею, хотя технологически все давно выровнялись. Почему заказчик иногда долго ждёт результат — и получает полуфабрикат. Как платформы и стандарты могут снять эту боль. И конечно, про ИИ: когда нейросеть реально «сделает как у Сбера за 5 минут», а когда это просто хайп, который дезориентирует заказчиков.
Собрал ключевые мысли из разговора — дальше от третьего лица, чтобы мои реплики не выглядели нескромно.
Чёрный ящик вместо проекта
«Для меня всегда было очень рискованно делать заказную разработку без жёстких ограничений. Если я видел контракт вида “вот ТЗ, через год принесём готовый код”, то с вероятностью 90% ничего хорошего из этого не выходило», — говорит Александр Сахаров, директор по работе с партнёрами компании «Диасофт».
«Приходили люди, приносили полуфабрикат: он не проходил нагрузочные испытания, не проходил контроль информационной безопасности, не проходил функциональное тестирование, интеграционно не вставал, данные туда не заливались. В итоге команда говорила: “Мы уже все деньги проели, пошли работать в другое место, а вы тут сами дальше разбирайтесь”. А часто в банках это большие деньги — могло быть потрачено несколько миллиардов рублей. Самая большая боль в заказной разработке — отсутствие прозрачности».
Тимур Васильев, Tech Lead (USA), знает эту боль с обеих сторон: «У нас был аналогичный опыт: полностью отдали новый проект на реализацию на несколько лет, а потом нам принесли совершенно не то что нужно. Почти все поставщики пытаются сэкономить: сделать как можно быстрее, забрать деньги и забыть о проекте. Грамотное выстраивание взаимодействия со стороны заказчика, подбор подрядчика — это огромная головная боль. На это мы тратили массу времени. Вероятно, временами нам было бы быстрее сделать всё самим, чем выстраивать такой процесс».
Непрозрачность процесса порождает непредсказуемость цены. «Вопрос цены особенно интересен, когда компания выходит на конкурентные закупки: разница в ценах от разных вендоров может отличаться в разы», — отмечает Яна Шакленина, CPO Outlines Tech. «Часто сталкиваемся с тем, что заказчик даёт задачу “оцените проект” без деталей по внутренней инфраструктуре, без выбранного решения. Конечно, цены будут разниться. Мы иногда проигрываем конкурентную основу, потому что предлагаем более качественные решения — хотим как лучше. А вперёд выбегают те, кто говорят: “Сделаем быстро”, применяют конструкторы и платформы быстрой сборки, а в итоге всё реализовано на коленках. Самое интересное — заказчик подсаживается на такого исполнителя, потому что деньги уже вложены и нужно доводить продукт до целевого состояния».
Алексей Каньков, Senior Backend Developer в Revizto, смотрит на проблему глазами того, кто пишет код: «Когда я вижу задачу, могу сказать примерно срок: две недели плюс π, умноженное на случайное число от 1 до 10. Две недели мне точно хватит, а дальше — как получится. Когда мы делаем что-то кастомное — это “пойди туда, не знаю куда, принеси то, не знаю что”. Оценить время, которое потратит конечный исполнитель вроде меня, практически нереально».
«Если проследить цепочку, кто же это оценивает, выяснится, что оценивают все, кому не лень, но никто до конца задачу не понимает. Более того, зачастую ТЗ написано так, что если читать строго по форме — там написано “сделай то, не знаю что, но очень быстро”», — добавляет Сахаров.
Платформы и стандарты: как включить свет
«Как я решал эту проблему? Задавал стандарты производства, которые подрядчики должны были соблюдать. Если кто-то делает заказную разработку, желательно, чтобы они работали на понятной мне прозрачной платформе, которая позволила бы закрыть мои риски. Например, если все программисты встали и уехали в другую страну или ушли на двойную зарплату в другое место работы, я мог бы нанять других, и они не сказали бы: “С этим кодом разобраться невозможно, надо всё переписать”. В моём понимании реализовывать бизнес-логику в виде чистого кода странно при наличии множества low-code решений — open source и коммерческих. Нарисованный аналитиками бизнес-процесс понятен, в нём можно разобраться, переставить кубики. То же касается логики хранения данных: если есть визуальный инструмент для создания и связывания данных с процессами — это проще. Аналогично с юнит-тестами по определённым правилам, с автотестами на базе нарисованных процессов. Тогда я могу раз в квартал или раз в месяц смотреть прогресс: сколько процессов сделано, сколько покрыто тестами, сколько тестов успешно, сколько экранных форм нарисовано и подвязано к процессам. Могу хоть как-то это контролировать. Если есть платформа — можно разбить задачи на типовые кусочки: количество процессов, экранных форм, объектов. Внутри каждого объекта у нас в компании есть нормативы. Эти нормативы перемножаются — получается нормативная стоимость. В неё с вероятностью 70% люди должны укладываться или показывать в ТЗ места, которые непонятны или ненормативны. Их можно обсуждать отдельно — получается нормальный разговор. На нашей платформе команда из 4–5 человек — условно, один аналитик, один фронтендер, “половинка” бэкендера, треть девопса и немного тестировщика — выполняет работу, для которой раньше требовалось 10–15 человек. При этом код на выходе полностью открытый, независимый, а вопросы производительности, омниканальности и безопасности решены “под капотом”. Это очень важно для окончательной приёмки», — объясняет Александр Сахаров.
Алексей Сушков, руководитель блока программных решений «Севен Груп», уточняет границы применимости: «Если у вас простой процесс, low-code спасёт — можно накидать простой портал на том же Bitrix, где уже готов большой конвейер. Но как только появляется нестандартный запрос — это либо глубокая кастомизация, либо попытка написать что-то рядом. Это всегда поиск баланса, и даже существующие конструкторы оставляют возможность глубокой кастомизации кода, потому что все понимают: всё предусмотреть невозможно».
Говорить и уметь говорить – разные вещи
«Технологические проблемы давно решены. У всех опытные команды, технологически мы все примерно одного уровня — можем сделать одно и то же. Но самое главное в заказной разработке — и мы все об этом говорим, но не явно — это коммуникации между исполнителем и заказчиком. От того, как мы строим эти коммуникации, зависит, сделаем ли проект, уложимся ли в срок и бюджет. Системность и методологичность коммуникаций — самое важное», — говорит Роман Смирнов, коммерческий директор «Девелоники», FabricaONE.AI.
Андрей Почтов, CTO компании АЭРО, формулирует ещё жёстче: «Все провальные проекты на моём опыте объединяет один факт — коммуникация с заказчиком не была налажена. Я вообще не верю в историю, что можно отдать проект на год и потом прийти, а он готов. Или написать ТЗ, отдать и прийти. Очень важны коммуникация, глубокое вовлечение заказчика, демо — это банальные вещи, но они работают».
Но вовлечённость тоже требует меры. «Если заказчик каждый день приходит и спрашивает: “Покажи демо, что изменилось?” — это будет тормозить команду, технические специалисты будут не очень рады такому подходу. Задача, наверное, больше исполнителя — того, кто заключает договор — так выстроить коммуникацию, чтобы к нему и компании было доверие у заказчика. Сразу обозначать прозрачные точки приёмки и правила взаимодействия во время выполнения заказа. На своей практике видел, когда заказчиков пускали вплоть до рабочих чатов, и они задавали много вопросов, которые отвлекали команду разработки. Важно соблюдать баланс между информированием заказчика и его вовлечённостью в процесс», — говорит Павел Куликовский, Tech Lead в Цифра Банке.
Яна Шакленина, CPO Outlines Tech, предлагает критерий для этого баланса: «Коммуникации бывают разные — когда это 55 созвонов в неделю, обсуждение на обсуждении, вопрос на вопрос — это очень тяжело. Для каждой коммуникации должно быть понимание: коммуникация ради чего? Коммуникация ради понимания бизнес-процесса и технологии, которая выбрана для решения. Тогда исполнитель работает более эффективно. В этом случае можно снизить количество созвонов, но и не уходить сильно в стандартизацию».
Зрелость заказчика – критерий отбора?
«Заказчик бывает разной степени зрелости и исполнитель тоже бывает разной зрелости. Мы стремимся выбирать зрелых заказчиков, потому что работать с незрелым очень тяжело — заказчик, который ничего не знает про заказную разработку, может вас измучить. Работать с совсем незрелыми — себе дороже. Если есть интересный заказчик, но вы понимаете, что придётся его всему обучить, — это будут инвестиции в повышение его зрелости», — говорит Роман Смирнов, коммерческий директор «Девелоники», FabricaONE.AI.
Олег Елманов, генеральный директор и владелец IT-интегратора Fusion, описывает, как выглядит зрелый заказчик на практике: «Сейчас зрелый заказчик уже делает техническую документацию, формирует стек и держит внутри компании IT-команду, которая сопровождает и развивает проект. У нас часто бывает, что мы приходим после предыдущего подрядчика, и работаем уже с годным кодом. Можем встраиваться, подхватывать и развивать дальше — это нормально работает. Чем опытнее компания-разработчик, тем более зрелого заказчика она берёт в партнёры. Если заказчик не готов работать с нормально выстроенной структурой подрядчика, он идёт на рынок фрилансеров или начинающих интеграторов».
Алексей Сушков, руководитель блока программных решений «Севен Груп», предлагает другой подход – выращивать: «Мы как эксперты рынка можем не то, чтобы навязывать правила игры, но обучать заказчиков и повышать их уровень зрелости. Если заказчик не понимает, что такое заказная разработка и как ведётся коммуникация, мы берём свой стандарт: “Проектом управляем так, идём так, отчитываемся так”. Тем самым стандартизируем свои процессы, делаем их прогнозируемыми. Даже если заказчик не готов по какому-то уровню — подтягиваем его до себя и обучаем. Через это выстраиваются партнёрские отношения и доверие».
«Мы на рынке 35 лет, прекрасно видим конкуренцию, разную степень зрелости заказчиков и вынуждены в этом жить. При этом у нас, как у старой консервативной компании, большие накладные расходы. Мы пришли к выводу, что нужна платформа, которая управляет процессами и снимает с людей рутину. Она должна освободить разработчиков, аналитиков и DevOps-инженеров от скучной работы, чтобы они фокусировались на создании ценности. На нашей платформе на базе визуальных моделей автоматически формируется вся бэкенд-обвязка, прописываются и публикуются API, настраивается API-management. Всё это сразу обкладывается юнит-тестами и делается по единым стандартам. Сюда же подключается искусственный интеллект: скрипты можно не писать кодом, а генерировать промптами на русском языке. Эту платформу используем мы сами и наши заказчики, она не создаёт вендор-лока. На ней может работать любая IT-компания», — говорит Александр Сахаров.
Продукт не «для», а «вместе»
«Мы привыкли делить участников на “заказчика” и “разработчика”, позиционируя себя как создателей системы. Но на самом деле в заказной разработке создателями любой системы являются оба лица. Заказчик тоже участвует в разработке. Существует даже термин не “разработка технического задания”, а “открытие ТЗ” и исследование предметной области, которое происходит совместно. Не всегда понятно, на ком лежит больше ответственности — на нас или на клиенте, — потому что мы делаем продукт вместе», — говорит Роман Смирнов.
Тимур Васильев рассказывает, как эта модель работает на практике: «После того как нам принесли совершенно не то, что нужно, компания перестроилась: мы подключили людей из аутсорс-команды внутрь компании — они составляли рабочую силу, а руководили ими наши сотрудники, которые знали, как всё должно работать. Процесс пошёл значительно лучше, особых проблем не было. При этом это всё ещё была заказная разработка».
«Со стороны заказчика должен быть бизнес-аналитик или функциональный заказчик, которые помогают формировать требования на старте. Чем более размытые требования, тем дороже проект — это всегда так. Если задачу прорабатывают заказчик и исполнитель совместно, результат всегда интереснее. Плюс механизмы отслеживания прогресса: двухнедельные или месячные демо — их можно привнести в любой процесс, водопадный или Scrum, неважно. Плотное взаимодействие с человеком, который понимает бизнес, говорит с ним на одном языке и может объяснить исполнителю, что конкретно надо — это сокращает разрыв между ожиданием и реальностью. Без совместной работы мало что получается. Правильная передача проекта — когда вы бережно передаёте контракт другому подрядчику или заготавливаете документацию, чтобы через год или три кто-то пришёл и продолжил развивать — это действительно важно. Этот процесс должен быть включён в разработку. Если заказчик сам этого не понимает, исполнитель должен навязывать эту историю, потому что сменяемость команд никто не отменял. Полная, понятная документация и преемственность — это всегда хорошо», — говорит Алексей Сушков.
Когда нейросеть «сделает как у Сбера за 5 минут»
«Рынок входит в эпоху сильной турбулентности, и это связано в том числе с появлением ИИ — инструментов вроде Cursor, которые ускоряют разработку. С одной стороны, исполнители получают возможность демпинговать, если умеют применять ИИ. С другой — у заказчиков появляется дезинформация. В запрещённых соцсетях любят выкладывать посты про онлайн-инструменты с подписью “за 5 минут можно сделать приложение как у Сбера или Т-Банка”. Технически подкованный человек поймёт, что это нереально. А если человек от бизнеса никогда не сталкивался с ИИ и не представляет, как реализуются сложные приложения, он может поверить. Потом ему называют реальную цену в 20 миллионов, а он говорит: “Вот же, за 5 минут можно сделать, почему так дорого?”» — говорит Павел Куликовский.
Алексей Каньков смотрит на ИИ с энтузиазмом практика: «Я очень люблю искусственный интеллект, начал использовать его ещё до того, как это стало мейнстримом. Буквально два дня назад я написал библиотеку полностью с помощью ИИ — грубо говоря, “навайб-кодил”. Это работает уже сейчас и неплохо, особенно если задавать рамки. Для небольших компаний, которым нужно что-то приземлённое, а не заоблачное, этот момент уже близок. Думаю, в течение года-двух обычный человек сможет получать реальные рабочие результаты. Сейчас я, как программист, могу добиться от ИИ правильного кода. Обычный пользователь пока не сможет сделать это от начала до конца без проблем».
Андрей Почтов, CTO компании АЭРО, уточняет границы: «Простые сайты — наверное, да. Я сам активно пользуюсь этим, “вайбкожу”, но как бывший разработчик понимаю: если человек не знает, как система должна работать изнутри под конкретный бизнес и нагрузку, он правильно задачу не поставит. Генеративные модели работают на входных данных: что скажешь, то и сделают или не сделают. Поэтому я надеюсь, что работа разработчиков ещё долго останется востребованной, именно потому что заказчики часто сами не знают, как делать».
«Рынок через год-два очень сильно переформатируется. Глядя на то, как искусственный интеллект помогает нам уже сейчас, мы понимаем, что скоро это будет совершенно другое качество моделей и иные подходы. Нам уже сейчас приходится перестраивать свои пайплайны и бизнес-процессы — в аналитике, разработке, тестировании — под использование генеративного ИИ. Эта внутренняя перестройка и повышение зрелости под современные тенденции происходит повсеместно. Через пару лет мы можем собраться и увидеть совсем другой рынок», — говорит Роман Смирнов.
Яна Шакленина обращает внимание на парадокс: «Все хотят сократить косты и уменьшить команды, нанимая очень опытных людей, которые будут использовать ИИ для ускорения. Но кто будет внедрять и обучать эти модели? Это большой вопрос, и, к сожалению, не все заказчики это понимают».
Что дальше?
«Если какие-то компании с помощью ИИ умудряются снижать ценник за производство фичи с условных 10 миллионов до одного, об этом стоит задуматься. Такие игроки со временем могут не выдержать конкуренции или просто “умереть”, потому что качество их работы будет очень низким. И даже если на рынке появилось несколько таких демпингующих компаний, я не уверен, что стоит немедленно снижать свой ценник ниже реальной себестоимости. Качество почти всегда стоит денег», — говорит Тимур Васильев.
«Рынок турбулентный. Многие компании эту турбулентность не переживут — я уже вижу, как некоторые не пережили. Мелкие быстро умрут, большим нужно перестроиться: наращивать эффективность, внедрять ИИ, ловить волну хайпа», — добавляет Андрей Почтов.
«Та турбулентность, которую сегодня отмечали спикеры, во многом связана с высоким хайпом вокруг ИИ. Но хайп этот не на пустом месте: от технологий есть реальный профит и эффективность, если их использовать грамотно», — говорит Яна Шакленина.
«Индустрия через год станет другой по разным причинам: турбулентность, уход компаний, приход ИИ. Но в этом и прелесть нашей сферы — она постоянно меняется и двигается вперёд», — отмечает Роман Смирнов.
«Основная проблема в том, что у каждой компании, большой или маленькой, бизнес-процессы абсолютно разные. У нас нет стандарта или ГОСТа по управлению процессами, бухгалтерией. У всех свои хотелки, свои особенности. Поэтому заказная разработка никуда не уйдёт», — резюмирует Алексей Сушков.
А как считаете вы? Поделитесь своим мнением в комментариях или в телеграм-канале для разработчиков Dev Q&A.
Автор: apsaharov
