Привет. Меня зовут Евгений Ширанков, и я возглавляю команду платформенных сервисов Яндекс 360.
Путешествие в мир архитектуры распределённых систем следует начать с основы основ любого проекта — сбора требований. Мы поговорим о том, зачем собирать функциональные требования. Как хорошо собранные требования влияют на бизнес и помогают разработчикам принимать более зрелые и взвешенные решения.
Давайте для начала проговорим очевидную мысль: не зная требования, нельзя сделать хорошее решение. Давайте приведу пример. Что будет, если вам дать задачу собрать машинку из конструктора, но при этом не дать инструкцию? Конечно, какую-то машину вы соберете, например, гоночную. Но очень может оказаться, что на самом деле нужна была машина для перевозки грузов. И придется или все переделывать заново, или возить грузы на спорткаре. Ни тот, ни другой вариант обычно никому не нравится. И, конечно, было бы проще, если бы инструкцию по сборке нам дали сразу. Но давайте задумаемся: даже если инструкции у нас есть, уверены ли мы, что грузовая машина то, что нам правда нужно? Зачем нам вообще потребовалось возить грузы?
Каждый проект или задача, которую мы делаем, возникла не просто так. У нее есть какая-то первопричина, проблема, которую она решает. И часто, когда заказчики к нам приходят с проектом, они приносят конкретные решения проблемы, которые, кажется, им единственно возможны. Однако, как правило, у любой проблемы всегда бывает более одного способа решения. И наша задача, как инженеров, не просто делать то, что принес заказчик, а выяснить, почему этот проект вообще надо делать, какую проблему он решает. Опытные инженеры хорошо понимают устройство системы и могут предложить более простые в разработке и в то же время более дешевые в поддержке решения, которые решают изначальную проблему и устраивают продукт.
Давайте вернемся к примеру про конструктор машинки. В случае сборки грузовой машины может оказаться, что изначальная проблема была в том, что на игрушечной стройке у кранов кончились батарейки и грузовая машина нам нужна, чтобы их возить по мере необходимости. Эта проблема более сложная, нежели просто постройка грузовика. Для перевозки батареек нужны погрузщики, манипуляторы для их установки. Их постройку также стоило заложить в проект. Возможно, лучшим решением будет переходить батареек на аккумуляторы, это поможет сэкономить ресурсы на дистанции. А еще и решить проблемы с электропитанием можно совершенно по-другому, подключив строительные экраны к розетке.
Зная изначальную проблему, которую мы решаем, можно не только сэкономить ресурсы или построить более стройное решение, но и значительно влиять на сам продукт, на его качество, на то, как он работает и то, каким его видят наши пользователи. Умение решать проблемы, а не просто делать задачи, это именно то, что характеризует опытного инженера, который правда умеет строить сервисы.
Для того, чтобы решать проблемы, нужно погрузиться в контекст продукта. Без понимания происходящего и истинных вызовов, с которыми сталкивается наш продукт, без понимания долгосрочной стратегии его развития, нельзя придумать по-настоящему оптимальное архитектурное решение. А чем более оптимальное решение принимает инженер, тем больше пользы он приносит бизнеса и тем выше его ценность.
Давайте рассмотрим пример. Представим себе, что поступила задача дать возможность администраторам организации Яндекс 360 отличать анимированные фоны в продуктах для своих сотрудников. Чтобы понять, как это спроектировать, надо обратиться к менеджеру и выяснить, какой должен быть пользовательские сценарии, какие ограничения есть и как функциональность должна выглядеть. После этого можно отправляться продумывать архитектуру. Но подождите. В самом ли деле мы узнали всё необходимое нам? Давайте подумаем ещё раз.
В реальности надо копнуть глубже в первопричины проекта. Возможно, кажется так, что проект появился из-за большого числа жалоб на потребление трафика от администраторов какого-то одного клиента. У этого клиента много разбросанных по стране филиалов, где каналы связи стоят дорого. А анимированные фоны довольно требовательно к трафику. В итоге вместо реализации не слишком востребованной фичи можно помочь одному конкретному клиенту, просто разово выключив анимированные фоны в организации, и сэкономить несколько месяцев работы целой команды разработки.
Давайте рассмотрим еще один пример на этот раз из реальной жизни. На определенном этапе развития нашего билинга нам потребовалось сделать скидки на тарифы. Например, на новый год, на черную пятницу. И главное — это надо было сделать быстро, так как на носу был очередной праздник. Давайте подумаем. Праздники — события предсказуемые. Все они есть в календаре, и мы можем заранее к ним подготовить скидки. К тому же их не так уж много, пять-десять в год. Кажется, что мы можем создавать такие акции силами разработки.
Но давайте попытаемся копнуть глубже и обратимся к маркетинговой стратегии Яндекс 360 всех лет. Окажется, что маркетинг Яндекс 360 планирует через полгода начать массово проводить акции не только по календарным праздникам, но по произвольным событиям и инфоповодам, раздавая промокоды со скидками на тарифы. Предсказать число инфоповодов сложно, но их будет точно на порядок больше, чем количество праздников, на которые мы изначально рассчитывали. Поэтому мы, как опытные инженеры, осознав весь контекст решаемой задачи и вектор развития требований, приняли решение вложиться немного больше в разработку скидочной механики. Сделали так, чтобы скидки могли заводить сами маркетологи без участия разработки так быстро, как и может хотеться, не ограничивая рост желания бизнеса техническими ограничениями.