Я же менеджер, зачем мне архитектура?

Я же менеджер, зачем мне архитектура?

16 марта 2023

  • Автор: Уля Днипрова

  • Сложность: не сложно

  • Время: 5 мин

Менеджер, как и бизнес-аналитик или продакт owner — роли «локомотивные», потому что отвечают за движение процесса в нужном направлении. Успешно «дотащить» IT-проект в правильную точку, менеджеру помогает харизма, управленческие навыки и техническая экспертиза. Минимальный уровень — научиться действовать, опираясь на знания стандартного жизненного цикла разработки ПО.

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

Вот три главных преимущества, которые получит РМ, ВА или РО, если начнет больше разбираться в архитектурных процессах. 

1. Договориться с архитектором

зачем менеджеру архитекрура 1

Хорошая архитектура наилучшим образом отвечает интересам заказчика и команды: ее легко расширять, изменять, тестировать, отлаживать, и позже, с нарастанием уровня сложности и размеров, приложение все-равно работает быстро и без сбоев. 

На больших проектах, архитектурные решения продумывает специалист с должностью solution architect и кажется, что так легче для менеджера. Однако в ситуации есть и «минус»: часто бывает, что solution architect считает, что дело менеджера — управлять готовыми решениями, которые придумал или выбрал архитектор.Вопросы РМ-а остаются без ответа, потому что архитектор воспринимает их как вмешательство в чужую роль. 

А менеджер, не зная всех тонкостей, не может правильно спланировать риски, оценить скоуп, рассчитать стоимость, — и ему труднее управлять проектом.

Конечно, техническим специалистам часто не нравится, что «нетехнари» вмешиваются в их работу. Договориться можно, если соблюдены два критерия: 

  1. Понимание архитектуры. Это значит, что менеджер достаточно разбирается в терминологии, чтобы понимать, о чем говорят разработчики и конкретно архитектор; знает метрики for architecture quality и на что они влияют.
  2. Общение на уровне ценностей компании. У архитектора не должно возникать ощущения, что его решили проверить или проконтролировать или, что РМ занялся микроменеджментом и пытается выполнить задачи вместо архитектора. 

Когда менеджер понимает, о чем говорит архитектор, какими категориями меряет продукт, то может привести аргументы, например, по эстимации и объемам тестирования или настоять на внедрении изменений у разработчиков. 

2. Убедить клиента 

зачем менеджеру архитектура 2

Часто бывает, что клиент врывается посреди проекта с идеей: «Хочу по-другому, я придумал новую кнопку, переделайте!»

И менеджеру мало просто понимать, что эта кнопка не нужна. Нужно еще и доказать заказчику, почему идея невозможна или невыгодна, или не подойдет прямо сейчас. 

Эти тонкости можно убедительно объяснить, только зная, как устроена архитектура продукта. 

Еще пример. В каждом проекте рано или поздно появляется технический долг — накапливается что-то недоделанное или приходится создавать временное решение в пользу скорости. Когда техдолг начинают исправлять, на это уходит время разработчиков. Заказчик не всегда понимает, откуда берется техдолг и может думать, будто разработчики просто доделывают свои же «косяки», которые почему-то не исправили раньше. 

Задача менеджера в такой ситуации — аргументированно доказать клиенту, что техдолг появится в любом случае, его будут исправлять и на это понадобится время, деньги и т.д. 

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

Команда делала приложение, которое собирало пользовательские данные. РМ-у на старте не удалось переубедить заказчика выделить дополнительный бюджет на защиту, поэтому однажды утром разработчик увидел на экране надпись: «Верну базу данных за 100 биткоинов». Приложение взломали, и украли данные пользователей.  

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

Собранные ответы облегчат работу архитектора или тимлида: не придется потом переделывать, можно правильно рассчитать стоимость, и вы не потеряете деньги, время и нервы команды. 

3. Найти лучшее решение для проекта

Зачем менеджеру архитектура 3.1

Правильные вопросы помогают выяснить, чего хочет заказчик на самом деле и предложить лучшее решение. Если менеджер или бизнес-аналитик обсудил с клиентом важные технические аспекты на старте проекта, разработчикам будет легче построить оптимальную архитектуру. 

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

В ходе проекта заказчик может приходить к РМ-у с предложениями по улучшению и расширению функционала. Хорошо, если РМ точно знает, как использовать метрики и как сделать аналитику перед внедрением новой фичи, —  иначе, команда зря потратит время. 

Как появляется ненужная задача, хорошо видно на утрированном  примере.  Хотя фича здесь надуманная, сама схема, к сожалению, бывает часто. 

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

Разработчики пошли делать, а когда сделали, заказчик говорит: «Эта штука не помогает отслеживать время на одевание. А вдруг,в процессе сборов, человек будет заваривать кофе? Это же растягивает время? Получается, мы собираем неадекватные данные, которые не приводят к запланированному результату. Так зачем мы это делаем?» 

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

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

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

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

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

Если бы в начале работы обсудили, что для этого конкретного приложения данные выгоднее хранить на железе, — заказчик бы сэкономил деньги. 

Например, РМ мог бы спросить: «Как много пользователей планируете привлекать и за какой период времени?»
ВА мог бы провести анализ рынка, увидеть динамику цен и предложить клиенту подходящий способ хранения.

Правильные вопросы и анализ, помогают найти лучшее решение для проекта сразу, а не после месяцев разработки. 

Delivery Mind

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

В итоге, разбираться с архитектурой придется, если хотите конструктивно общаться с solution architect, рассчитывать предварительную стоимость разработки, задавать правильные вопросы клиенту и влиять на выбор решения. 

 

 

Уля Днипрова

Уля — копирайтер IAMPM. Всегда готова помочь юным авторам советом и просто обожает разговаривать о маркетинге, текстах и смыслах.