Я ж менеджер, нащо мені архітектура?

6 July 2022

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

  • Складність: легко

  • Час: 5 хв

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

На початку кар’єри таких базових технічних знань цілком достатньо, але, розвиваючись далі, менеджер відповідає вже не лише за координацію командних дій, а й за досягнення цілей. Щоб створювати якісний продукт у задані терміни, менеджеру знадобиться більш глибоке розуміння технічних аспектів, і для цього треба заглибитися в архітектуру.

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

1. Домовитися з архітектором

Я ж менеджер, нащо мені архітектура 1

Хороша архітектура якнайкраще відповідає інтересам замовника й команди: її легко розширювати, змінювати, тестувати, налагоджувати, й пізніше, з наростанням рівня складності й розмірів, додаток все одно працює швидко й без збоїв.

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

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

Звичайно, технічним спеціалістам часто не подобається, що «нетехнарі» втручаються у їхню роботу. Домовитися можна, якщо дотримано два критерії:

  • Розуміння архітектури. Це означає, що менеджер достатньо розбирається в термінології, щоб розуміти, про що говорять розробники й саме архітектор; знає метрики for architecture quality і на що вони впливають.
  • Спілкування лише на рівні цінностей компанії. У архітектора не повинно виникати відчуття, що його вирішили перевірити чи проконтролювати, або, що РМ зайнявся мікроменеджментом і намагається виконати задачі замість архітектора.

Коли менеджер розуміє, про що говорить архітектор, якими категоріями міряє продукт, то може навести аргументи, наприклад, щодо естимації та обсягів тестування або наполягти на впровадженні змін у розробників.

2. Переконати клієнта

Я ж менеджер, нащо мені архітектура 2

Часто буває, що клієнт вривається посеред проєкту з ідеєю: «Хочу інакше, я вигадав нову кнопку, переробіть!»

І менеджеру недостатньо просто розуміти, що ця кнопка не потрібна. Потрібно ще й довести замовнику, чому ідея неможлива чи невигідна, або не підійде зараз.

Ці тонкощі можна переконливо пояснити лише знаючи, як влаштована архітектура продукту.

Ще приклад. У кожному проєкті рано чи пізно з’являється технічний борг — накопичується щось недороблене чи доводиться створювати тимчасове рішення на користь швидкості. Коли техборг починають виправляти, на це йде час розробників. Замовник не завжди розуміє, звідки береться техборг і може думати, ніби розробники просто доробляють свої ж «косяки», які чомусь не виправили раніше.

Завдання менеджера в такій ситуації — аргументовано довести клієнту, що техборг з’явиться у будь-якому випадку, його виправлятимуть і на це знадобиться час, гроші тощо.

Розуміння архітектурних процесів допоможе обґрунтувати розмір бюджету на ризики чи витрати на потрібний рівень безпеки. Якщо не пояснити замовнику, чому необхідно вкласти більше грошей у безпеку, може вийти як в одному кейсі:

Команда робила додаток, який збирав дані користувача. РМ-у на старті не вдалося переконати замовника виділити додатковий бюджет на захист, тому одного ранку розробник побачив на екрані напис: «Поверну базу даних за 100 біткоїнів». Додаток зламали і вкрали дані користувачів.

Іноді замовник просто не здогадується про важливість якихось нефункціональних вимог. Тому необхідно, щоб менеджер поставив правильні питання, отримав потрібну інформацію та доніс її до розробників.

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

3. Знайти найкраще рішення для проєкту

Я ж менеджер, нащо мені архітектура 3

Правильні питання допомагають з’ясувати, чого хоче замовник насправді й запропонувати найкраще рішення. Якщо менеджер чи бізнес-аналітик обговорив із клієнтом важливі технічні аспекти на старті проєкту, розробникам буде легше побудувати оптимальну архітектуру.

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

У ході проєкту замовник може приходити до РМ-а з пропозиціями щодо покращення та розширення функціоналу. Добре, якщо РМ точно знає, як використовувати метрики й як зробити аналітику перед впровадженням нової фічі, інакше команда дарма згаяє час.

Як з’являється марна задача, добре видно на перебільшеному прикладі. Хоча фіча тут надумана, сама схема, на жаль, буває часто.

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

Розробники пішли робити, а коли зробили, замовник каже: «Ця штука не допомагає відстежувати час на одягання. А раптом у процесі зборів людина заварюватиме каву? Це ж розтягує час? Виходить, ми збираємо неадекватні дані, що не призводять до запланованого результату. То навіщо ми це робимо?»

У результаті всі працювали, витрачали час, а впровадження нової оригінальної фічі не призвело до бізнес-результату: не підвищило retention або кількість користувачів.

Delivery Mind Архітектура та управління тех командою

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

Інший приклад. Ви починаєте роботу над програмою і на старті потрібно вирішити, де зберігати дані: на фізичному сервері або у хмарі. Це два абсолютно різні підходи й вартість у них теж різна.

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

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

Якби на початку роботи обговорили, що для цього конкретного додатка дані вигідніше зберігати на залізі, — замовник заощадив би гроші.

Наприклад, РМ міг би запитати: «Як багато користувачів плануєте залучати й за який час?»

ВА міг би провести аналіз ринку, побачити динаміку цін та запропонувати клієнту відповідний спосіб зберігання.

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

Робота з архітектурою критично важлива на старті проєкту, коли закладають фундамент: обирають мову програмування, структуру зберігання даних, framework розробки. У поточному проєкті фундамент вже закладено, але в процесі все одно доведеться опрацьовувати пропозиції від замовника. Якщо це будуть якісь функціональні рішення, вони торкнуться змін архітектури й потрібно пояснити, наприклад, чому не все можна зробити прямо зараз.

У результаті розбиратися з архітектурою доведеться, якщо хочете конструктивно спілкуватися з solution architect, розраховувати попередню вартість розробки, ставити правильні питання клієнту та впливати на вибір рішення.

Уля Днипрова

Уля — копірайтер IAMPM. Завжди готова допомогти молодим авторам порадою і просто любить говорити про маркетинг, тексти і сенси.