Менеджер, как и бизнес-аналитик или продакт owner — роли «локомотивные», потому что отвечают за движение процесса в нужном направлении. Успешно «дотащить» IT-проект в правильную точку, менеджеру помогает харизма, управленческие навыки и техническая экспертиза. Минимальный уровень — научиться действовать, опираясь на знания стандартного жизненного цикла разработки ПО.
В начале карьеры таких базовых технических знаний вполне достаточно, но, развиваясь дальше, менеджер отвечает уже не только за координацию командных действий, а еще и за достижение целей. Чтобы создавать качественный продукт в заданные сроки, менеджеру понадобится более глубокое понимание технических аспектов, и для этого надо вникнуть в архитектуру.
Вот три главных преимущества, которые получит РМ, ВА или РО, если начнет больше разбираться в архитектурных процессах.
1. Договориться с архитектором
Хорошая архитектура наилучшим образом отвечает интересам заказчика и команды: ее легко расширять, изменять, тестировать, отлаживать, и позже, с нарастанием уровня сложности и размеров, приложение все-равно работает быстро и без сбоев.
На больших проектах, архитектурные решения продумывает специалист с должностью solution architect и кажется, что так легче для менеджера. Однако в ситуации есть и «минус»: часто бывает, что solution architect считает, что дело менеджера — управлять готовыми решениями, которые придумал или выбрал архитектор.Вопросы РМ-а остаются без ответа, потому что архитектор воспринимает их как вмешательство в чужую роль.
А менеджер, не зная всех тонкостей, не может правильно спланировать риски, оценить скоуп, рассчитать стоимость, — и ему труднее управлять проектом.
Конечно, техническим специалистам часто не нравится, что «нетехнари» вмешиваются в их работу. Договориться можно, если соблюдены два критерия:
- Понимание архитектуры. Это значит, что менеджер достаточно разбирается в терминологии, чтобы понимать, о чем говорят разработчики и конкретно архитектор; знает метрики for architecture quality и на что они влияют.
- Общение на уровне ценностей компании. У архитектора не должно возникать ощущения, что его решили проверить или проконтролировать или, что РМ занялся микроменеджментом и пытается выполнить задачи вместо архитектора.
Когда менеджер понимает, о чем говорит архитектор, какими категориями меряет продукт, то может привести аргументы, например, по эстимации и объемам тестирования или настоять на внедрении изменений у разработчиков.
2. Убедить клиента
Часто бывает, что клиент врывается посреди проекта с идеей: «Хочу по-другому, я придумал новую кнопку, переделайте!»
И менеджеру мало просто понимать, что эта кнопка не нужна. Нужно еще и доказать заказчику, почему идея невозможна или невыгодна, или не подойдет прямо сейчас.
Эти тонкости можно убедительно объяснить, только зная, как устроена архитектура продукта.
Еще пример. В каждом проекте рано или поздно появляется технический долг — накапливается что-то недоделанное или приходится создавать временное решение в пользу скорости. Когда техдолг начинают исправлять, на это уходит время разработчиков. Заказчик не всегда понимает, откуда берется техдолг и может думать, будто разработчики просто доделывают свои же «косяки», которые почему-то не исправили раньше.
Задача менеджера в такой ситуации — аргументированно доказать клиенту, что техдолг появится в любом случае, его будут исправлять и на это понадобится время, деньги и т.д.
Понимание архитектурных процессов поможет обосновать размер бюджета на риски или траты на нужный уровень безопасности. Если не объяснить заказчику, почему необходимо вложить больше денег в безопасность, может получиться как в одном кейсе:
Команда делала приложение, которое собирало пользовательские данные. РМ-у на старте не удалось переубедить заказчика выделить дополнительный бюджет на защиту, поэтому однажды утром разработчик увидел на экране надпись: «Верну базу данных за 100 биткоинов». Приложение взломали, и украли данные пользователей.
Иногда заказчик просто не догадывается о важности каких-то нефункциональных требований. Поэтому необходимо, чтобы менеджер задал правильные вопросы, получил нужную информацию и донес ее до разработчиков.
Собранные ответы облегчат работу архитектора или тимлида: не придется потом переделывать, можно правильно рассчитать стоимость, и вы не потеряете деньги, время и нервы команды.
3. Найти лучшее решение для проекта
Правильные вопросы помогают выяснить, чего хочет заказчик на самом деле и предложить лучшее решение. Если менеджер или бизнес-аналитик обсудил с клиентом важные технические аспекты на старте проекта, разработчикам будет легче построить оптимальную архитектуру.
Например, менеджер знает, почему для MVP подходит один тип архитектуры, а при масштабировании проекта — другой, соответственно, предложит клиенту нужное решение. В итоге, выигрывают все: заказчик получит качественный продукт, а команде не придется постоянно что-то переделывать.
В ходе проекта заказчик может приходить к РМ-у с предложениями по улучшению и расширению функционала. Хорошо, если РМ точно знает, как использовать метрики и как сделать аналитику перед внедрением новой фичи, — иначе, команда зря потратит время.
Как появляется ненужная задача, хорошо видно на утрированном примере. Хотя фича здесь надуманная, сама схема, к сожалению, бывает часто.
Допустим, команда делает приложение, которое отслеживает длительность и расстояние бега. Заказчик захотел дополнительную оригинальную фичу — чтобы программа показывала, сколько времени человек тратит от момента включения приложения до выхода на улицу, то есть, сколько занимает обуть кроссовки, надеть спортивный костюм и т.д.
Разработчики пошли делать, а когда сделали, заказчик говорит: «Эта штука не помогает отслеживать время на одевание. А вдруг,в процессе сборов, человек будет заваривать кофе? Это же растягивает время? Получается, мы собираем неадекватные данные, которые не приводят к запланированному результату. Так зачем мы это делаем?»
В итоге, все работали, тратили время, а внедрение новой оригинальной фичи не привело к бизнес результату: не повысило retention или количество пользователей.
Понимая архитектуру, менеджер сможет помочь команде выбрать решение для конкретной бизнес-задачи, проанализировать пользу внедрения той или иной фичи, провести приоритизацию пользовательского функционала.
Другой пример. Вы начинаете работу над приложением и на старте нужно решить, где хранить данные: на физическом сервере или в облаке. Это два совершенно разных подхода и стоимость у них тоже разная.
Клиентам предложили облачный способ хранения, как самый оптимальный, но никто не проанализировал бизнес-тренды — снижение цен на железо, которое подешевело, из-за падения криптовалюты. И хотя можно было выгодно купить сервера, сфокусировались на облаке.
Все идет хорошо, а затем, когда клиент захотел набрать больше данных пользователей и масштабировать проект, оказалось, что в облаке это обойдется гораздо дороже, чем было бы на собственном железе.
Если бы в начале работы обсудили, что для этого конкретного приложения данные выгоднее хранить на железе, — заказчик бы сэкономил деньги.
Например, РМ мог бы спросить: «Как много пользователей планируете привлекать и за какой период времени?»
ВА мог бы провести анализ рынка, увидеть динамику цен и предложить клиенту подходящий способ хранения.
Правильные вопросы и анализ, помогают найти лучшее решение для проекта сразу, а не после месяцев разработки.
Работа с архитектурой критически важна на старте проекта, когда закладывают фундамент: выбирают язык программирования, структуру хранения данных, framework разработки. В текущем проекте фундамент уже заложен, но в процессе все равно придется обрабатывать предложения от заказчика. Если это будут какие-то функциональные решения, они затронут изменения архитектуры и нужно суметь объяснить, например, почему не все можно сделать прямо сейчас.
В итоге, разбираться с архитектурой придется, если хотите конструктивно общаться с solution architect, рассчитывать предварительную стоимость разработки, задавать правильные вопросы клиенту и влиять на выбор решения.