После ухода SAP из России перед ООО «ЛАБ СП» встала задача поддержки существующих клиентов.
«Когда SAP перестал поддерживать клиентов в России, надо было что-то делать - разрабатывать ИТ-решения для того, чтобы продолжать их поддерживать», - рассказывает Андрей Филатов, управляющий партнёр ООО «ЛАБ СП», ex. генеральный директор SAP CIS.
«Мы поняли, что только на SAP далеко не уедешь и нужно заниматься чем-то новым. Решили продавать решения других российских разработчиков, ведь у нас есть доступ к клиентам и связи с ними остались неплохие».
Общение с разработчиками выявило ряд проблем, с которыми мы столкнулись. Что российским разработчикам не хватает, чего они не умеют делать?
«Ситуация на рынке такова, что разработчики часто не учитывают важные моменты в своей деятельности», - отметил Филатов.
Чтобы систематизировать эти проблемы, «ЛАБ СП» выделила четыре смысловых уровня зрелости разработчиков ПО: функциональный, технологический, интеграционный и юридический.
Эти и другие аспекты работы российских разработчиков активно обсуждались на форуме «ИТ-мир по-русски», где Андрей Филатов, управляющий партнёр ООО «ЛАБ СП», представил свою точку зрения.
Функциональный уровень: продукт, команда и процессы
На функциональном уровне ключевыми являются инструменты: продукт, команда, процессы.
«На этом уровне мы определяем, что разрабатываем и для кого, когда у нас появляется идея. С этим у нас никогда дефицита в стране не было», - подчеркнул Филатов. «Вопрос в том, как разрабатывать, сколько это должно стоить, и как правильно подойти к процессу разработки».
Особое внимание стоит уделить команде. «Не обязательно всю команду держать в штате. Можно нанимать команду разработчиков, допустим, из Воронежа. С учетом маржи компании-разработчика, это будет дешевле, чем нанимать таких же программистов в Москве. Аутсорсинг разработки реально работает».
Однако, работа с распределенной командой несет свои вызовы: перенос сроков разработки, сложность в оценке разработчиков, неэффективное использование ресурсов, значительные затраты на ФОТ, высокая конкуренция на рынке труда, выгорание и текучка персонала.
Одной из ключевых проблем является оценка квалификации программистов. «По резюме и интервью они все могут быть очень крутые. Кто там по факту у вас окажется?» - задается вопросом Филатов. Кроме того, лояльность разработчиков часто оставляет желать лучшего: «Разработчику предложили где-то на 3 копейки больше, он сразу встал и ушел».
Согласно исследованию Егора Денисова-Бланча из Стэнфордского университета, 14% инженеров-программистов, работающих удалённо, практически не выполняют никакой работы (инженеры-призраки), по сравнению с 9% в гибридных ролях и 6% в офисе.
«То есть, если человек работает удалено, он может свои услуги продавать в 3-4 компании, вы ему платите зарплату, а работает он на кого-то другого. Это распространенная проблема, и цифры взяты из исследований Стэнфордского университета, то есть это глобальная проблема».
Для решения этой проблемы «ЛАБ СП» использует решение партнера, которое анализирует данные из Jira, GitHub и российских каналов. «Система собирает аналитику по каждому разработчику и может сразу показать, кто плохо работает. Это очень удобно».
Технологический уровень: платформы, данные, AI-ассистенты, тестирование, совместимость и benchmarking
На технологическом уровне ключевыми являются платформы, данные, AI-ассистенты, тестирование, совместимость и benchmarking.
Филатов отметил широкое использование Open Source платформ. «Мало кто сейчас разрабатывает программное приложение с нуля, все берут готовую платформу и разрабатывают. Ничего плохого здесь нет, но надо следить за open-source. Он хоть и бесплатный, но не всегда свободный. Если вы взяли платформу, которая по стандарту OpenGPI, то вы не имеете права присваивать все результаты своей разработки. Вы обязаны их отдать в комьюнити». Он также предупредил о планируемой Минцифрой «чистке реестра» российского ПО от решений, нарушающих правила лицензирования.
AI-ассистенты помогают экономить время, но требуют постоянного контроля и проверки. «Разработки очень помогают сэкономить время, реально может быть меньшее количество разработчиков. Но все равно за ними надо следить, за ними надо проверять, потому что пока еще они не идеальны».
Разработчики часто упускают из виду тестирование и совместимость.
«Разработчик создал продукт исходя из какого-то своего стека инфраструктурного ПО, операционной системы и базы данных. А когда мы это продаем заказчику, у него может быть другой ИТ-ландшафт. И он далеко не всегда готов переходить на ваш ландшафт, чтобы вашу разработку в свою инфраструктуру разместить». Важен вопрос версионности и тестирования совместимости обновлений.
Benchmarking позволяет проверить функционирование приложения в разных условиях нагрузки. «Если у вас 10 человек работает в системе, или 100 человек, или 1000 человек, у вас система ведет себя по-разному, и это надо тестировать, проверять. Это позволит определить требования и критерии для работы вашей программы».
Интеграционный уровень: жизненный цикл ПО и данных
«Когда мы интегрируемся в ИТ-ландшафт заказчика, мало кто из разработчиков думает о том, какое место его приложение занимает в этом цикле. Очень мало приложений, которые работают изолированно, и не нужна интеграция с другими».
Важна интеграция, совместимость форматов данных и соблюдение базового жизненного цикла ПО: обновление, поддержка, консалтинг, поставка, адаптация, интеграция.
«Мы как разработчики должны этот цикл поддерживать и желательно управлять, потому что если вы не управляете, то у вас дополнительные расходы на поддержку этого цикла».
Разработчики также часто не учитывают жизненный цикл данных. «Приложение, которое работает с данными, накапливает их. Оно может работать не 1 год, а 2, 3, 5, 7 и возникает ситуация, что у вас приложение «пухнет», требует очень много места, памяти и т.д., оно начинает тормозить из-за того, что оно перегружено. Важно продумать архивирование, загрузку данных и управление форматом данных».
Юридический уровень: IP Rights, контракты, риски, анализ кода
Филатов напомнил о необходимости соблюдения лицензионных требований Open Source компонентов. «Я уже сказал про OpenGPI. В Apache тоже можно переиспользовать и присваивать результаты своей разработки. Но, если использовать компоненты Apache, надо указывать, что используются компоненты Apache».
Гораздо более серьезные проблемы возникают при работе с крупными enterprise-заказчиками. «У SAP была привилегия. SAP, когда приходил, даже к очень крупным игрокам: Лукойл, Газпром, Никель, и те говорили, мы контракты только на своих подписываем форматах. SAP говорил, а нам все равно, не хотите, мы пошли», - рассказал Филатов. Однако, по его словам, российские компании такой привилегией не обладают.
«При этом нельзя на все соглашаться. Потому что, как правило, если это заказная разработка, и они платят вам за это деньги, они пишут в своих контрактах, что становятся правообладателями всего кода, что вы написали. А дальше вы пошли к другому заказчику, и тоже такой же договор. А вы уже с первым начали нарушать тот договор, который вы подписали», - предупредил эксперт. В таком случае, заказчик может подать в суд как на разработчика, так и на его клиента.
Единственный способ избежать подобной ситуации, по мнению Филатова, - это договариваться с заказчиком и подписывать дополнительные соглашения, в которых будет указано, что компания-разработчик имеет право на переиспользование кода без каких-либо ограничений и без необходимости оплаты.
Еще один опыт, которым поделился Андрей Филатов, связан с переходом разработчика из одной компании в другую, занимающиеся разработкой конкурирующих продуктов. «Сманила одна компания разработчика у своего конкурента. Пришел разработчик и начал обновлять, переписывать, переделывать кусок софта. Дальше компания, с которой он уволился, подала в суд за то, что он переиспользовал её код», - рассказал эксперт. В результате анализа кода было выявлено совпадение, что привело к судебному разбирательству.
Для защиты от подобных ситуаций, Филатов рекомендует заключать с разработчиками особые соглашения. «Если у вас сотрудник просто числится как сотрудник, а на самом деле занимается разработкой, а потом он уволится и эту разработку сам начинает продавать на рынке, конкурируя с вами, вам очень сложно будет доказать, что это ваше», - предупредил он.
Необходимо подписывать дополнительное соглашение о том, что разработчик передает компании все, что он делает в рабочее и в нерабочее время, и получать за это вознаграждение, чтобы соглашение имело юридическую силу.
В заключение, Андрей Филатов подчеркнул, что юридические аспекты разработки ПО так же важны, как и функциональные, технологические и интеграционные. Игнорирование этих вопросов может привести к серьезным финансовым и репутационным потерям. Поэтому, компаниям-разработчикам необходимо уделять пристальное внимание лицензионным требованиям, контрактным обязательствам и защите интеллектуальной собственности.
Эта тема вызвала живой интерес участников форума «ИТ-мир по-русски», и, несомненно, потребует дальнейшего обсуждения в профессиональном сообществе.