Привет, меня зовут Александр Майстренко, я Chief Technology Officer в компании Фокстрот.
В статье опишу два реальных кейса, которые случились совсем недавно. В каждом из примеров углубленная техническая экспертиза РМ-а могла бы уберечь компанию от финансовых и других потерь. В силу разных обстоятельств я не буду озвучивать названия компаний.
Потеря репутации
Первый кейс совсем свежий. В одном крупном интернет-магазине была обнаружена уязвимость в безопасности при передачи данных с фронтенда на бекенд. Любой пользователь на фронтенде мог подменить ID добавляемого в корзину товара, и на бекенде это никак не валидировалось.
Группа лиц воспользовалась этой уязвимостью. Они добавили в корзину и оплатили Playstation 5 — товар, которого у магазина нет в наличии. От предложения магазина вернуть деньги они отказались и требуют предоставить оплаченный товар. Таким образом, магазин вынужден предоставить Playstation 5, хотя приставки по факту нет в наличии. Финансовые расходы, соответственно, полностью ложатся на плечи компании.
Между тем, эту проблему легко можно было предотвратить, если бы РМ разбирался в теме безопасности и настоял, чтобы разработчики продумали этот вопрос и не допустили бы JS инъекции. Подробнее о том, как защитить IT-продукт, рассказывают на курсах TechMind и Delivery Mind.
Потеря времени
В одной компании появилась идея разработать инструмент, который поможет сотрудникам выполнять свою работу быстрее и качественнее. Создав свой собственный, компания рассчитывала экономить деньги и не покупать сторонние решения.
К сожалению, у менеджера не было понимания, какие вопросы важно задавать на старте, поэтому для архитектуры выбрали монолит. Решение создали, и хотя при этом не применялись никакие best practices, инструмент справлялся со своей задачей. И всё бы ничего, если бы компания не решила продавать инструмент другим заинтересованным сторонам как SaaS.
Как только клиентов и функций системы стало больше, появились проблемы с отказоустойчивостью и производительностью, а компания начала нести репутационные и финансовые потери. Чтобы разобраться в ситуации, наняли опытного тимлида. Постепенно монолит начали переводить в микросервисную архитектуру, и проблемы практически исчезли. А ведь их можно было вообще не допустить, знай менеджер основы архитектурных решений.
Как Chief Technology Officer могу сказать, что если менеджер игнорирует или уделяет мало внимания техническим вопросам в проекте, потери неизбежны.
РМ — это человек, который отвечает за доставку проекта в нужную точку и в нужное время. Но как он может полностью взять процесс под контроль, когда непонятно, почему технические специалисты выбирают то или иное решение? Сможет ли РМ без технической экспертизы убедить клиента выделить финансы на безопасность, получится ли защитить команду перед заказчиком, не прибегая постоянно к помощи техлида? Возможно, вы считаете, что менеджеру вообще не стоит вникать в технические подробности, а просто отдать планирование рисков по архитектуре, интеграции, безопасности технической команде? Решать вам.