Работа над ошибками: пути к усовершенствованию российского ПО

Размышления на полях ЦИПР 2025. Директор по развитию бизнеса UserGate Эльман Бейбутов выступил спикером панельной дискуссии "Скрипит, но едет. Доработка отечественного ПО и создание системы рейтингования".

Понимание пирамиды приоритетов при разработке ПО

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

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

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

К сожалению, на осознание этой ошибки уходит очень много времени. Нередко случается, что компания долго ведет разработку функциональности не в том русле и понимает свою ошибку только через 3–5 лет. В итоге приходится пересобирать продукт заново — на других технологиях, на других базах данных и даже на другом стеке программирования.

Что ведет к минимизации ошибок?

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

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

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

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

Повышение частоты релизов: лучше чаще вносить небольшие качественные и функциональные изменения, чем выпускать крупные и редкие обновления. Это снижает нагрузку на команду, упрощает тестирование и позволяет быстрее исправлять уязвимости, что, опять же, работает на стабильность и производительность. Если в продукте обнаруживается уязвимость, это нормально и естественно. Есть много примеров, когда ПО сначала считалось безопасным, а потом в них выявлялись слабые места одно за другим. От этого никуда не деться, и нужно изначально строить процесс с пониманием этого факта. Необходимо также определить, по каким каналам информация об уязвимостях и патчах будет доноситься до клиентов. Мало просто выложить патч — клиентам нужно доходчиво объяснить, почему патчить ПО необходимо. Можно также рассмотреть опцию автообновления, когда патч устанавливается автоматически, порой даже незаметно для клиента.

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

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

Система рейтингования ПО: выигрывают все

Ускорить устранение ошибок в отечественном ПО и повысить его качество могла бы система рейтингования. О ее необходимости сегодня говорят многие, но мало кто хочет возглавить это движение и стать в его главе. Это главный барьер, который препятствует ее появлению. Второй барьер — отсутствие методологии, и, как следствие, понимания, как именно рейтинговать ПО. Чтобы исключить ситуации, когда производитель занимает лидирующие позиции просто потому, что он подогнал критерии оценки под себя, система рейтингования должна формироваться с привлечением всех сторон: разработчиков, производителей, регулятора, причем регулятор в идеале должен сыграть объединяющую роль.

Когда такая система появится, компании смогут сократить время и средства, которые тратятся на поиск подходящего решения. Сейчас тысячи российских юрлиц, вставших на путь импортозамещения, проводят тестирования, привлекают интеграторов, тратят множество человеко-часов только на то, чтобы найти нужный продукт. В масштабах страны это огромные средства. А если появится авторитетная и объективная система рейтингования, заказчики смогут на нее положиться, ориентируясь, скажем, на топ-5 решений в своих классах и выбирая среди них.

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

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