Щоб краще розібратися в процесах справжніх ІТ-проектів та ролі кожного спеціаліста в їх реалізації, ми запросили delivery-менеджера EPAM Владислава Соломонова. На вигаданому, однак реалістичному прикладі Владислав розповів, як відбувається розвиток ІТ-проекту, які ролі важливі на кожному його етапі та якими компетенціями має володіти ІТ-спеціаліст для ефективного вирішення своїх проектних задач. 

Владислав Соломонов:

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

PRESALE

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

Все починається з account-менеджера, який приймає участь в ініціації та закритті проекту, розробляє стратегію аккаунту, керує sales-процесами. В зону його відповідальності входить фінансова складова проекту, в тому числі прибутковість та досягнення цілей з виручки. Також account-менеджер відповідальний за безперервний розвиток відносин з клієнтом; він повинен забезпечити такі умови співробітництва, щоб принести клієнту якомога більше користі – допомогти виділитися на своєму ринку та підвищити конкурентоспроможність. Для цього account-менеджеру потрібно володіти наступними ключовими компетенціями: фінансова освіченість; розуміння, як працює бізнес великих компаній; розуміння галузі; великий досвід досягнення стратегічних бізнес-цілей за допомогою ІТ; та знання, як здійснювати digital-transformation. Account-менеджер – це фахівець з проведення переговорів, спеціаліст в галузі бізнесу і фінансів, з досвідом в ІТ.  

Архітектор і бізнес-аналітик знайомляться з проектом на більш глибокому, технічному рівні та оцінюють приблизні обсяги та вартість робіт. У нашому випадку, для більш точного визначення необхідних робіт архітектором і бізнес-аналітиком, було вирішено першочергово запросити на проект UX-команду, яка повинна з'ясувати, як досягти цілей клієнта з максимальним залученням користувачів. 

DISCOVERY

Завдання UX-команди полягає в тому, щоб спроектувати «досвід» користувача – не просто роботи з продуктом, але й взаємодії з брендом клієнта. В деяких випадках на першому етапі UX-команду можуть і не запрошувати. Проте, якщо мова йде про розробку готових користувацьких рішень, то інтерфейс потрібний і важливий. Звичайно, інтерфейс може бути продуманий і замовником самостійно, однак ефективніше, якщо дизайн спроектує команда того виконавця, який здійснюватиме розробку додатку.  

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

З UX-командою на проект приходить project-менеджер. На етапі Discovery до його завдань входять координація роботи UX-команди та фіксація домовленостей. В подальшому, сфера відповідальності project-менеджера суттєво розшириться. 

Дуже важливо, щоб на етапі Discovery до роботи підключились бізнес-аналітик і архітектор. Спільно з UX-командою бізнес-аналітик опрацьовує user stories – стислі формулювання намірів, які детально описують, що система повинна робити для користувача. Бізнес-аналітик «копає» глибше, ніж UX-спеціалісти: він розбирає ті рішення, які візуально не відображаються в додатку. Наприклад, за яких умов користувачу надсилатимуться листи з додатку? Хто має право редагувати інформацію про косметичний засіб, якщо, припустимо, його ціна повинна змінитися в «Чорну п'ятницю»? Чи має бути таймер, який поверне ціну до її попереднього значення? Від того, як виконає свою роботу бізнес-аналітик, багато в чому залежить швидкість усього процесу розробки. Бізнес-аналітики – це фахівці, які розуміють вимоги клієнта і вміють працювати з ними. Бізнес-аналітики проводять спеціальні зустрічі з клієнтом з метою виявлення вимог: інтерв'ю, воркшопи, анкетування. Крім того, вони вміють прототипувати й описувати бізнес-процеси, а також розуміють, як поставити максимально чіткі задачі команді розробників, щоб кінцевий результат повністю відповідав очікуванням та потребам клієнта. 

На основі поставлених бізнес-цілей, user stories та параметрів якості (нефункціональні вимоги), які підготував бізнес-аналітик, архітектор створює архітектурне рішення продукту. Щоб якісно виконати свою роботу, архітектору потрібні не лише відмінні знання всіх технологій розробки, але й розвинуті навички спілкування із замовником, а також розуміння його бізнесу. Архітектор – це фахівець, який відповідає за технічну проект-архітектуру продукту. Він достеменно розуміє, як спроектувати й розробити продукт з використанням технологій, щоб досягти бізнес-цілей клієнта і при цьому зберегти відповідні показники якості: масштабування, продуктивність, відмовостійкість. 

На нашому проекті фактично існує два рішення. Перше – додаток, який користувач безпосередньо бачить на планшеті (frontend). Друге – система на сервері, яка повинна керувати додатком: загальними налаштуваннями, набором продуктів, їх найменуваннями та цінами, вибором відеозаставок і т.д. (backend). Тому потрібно два архітектори, які працюватимуть разом, щоб створити сумісні рішення. Архітектор з frontend працює близько двох тижнів, а за подальшу інтеграцію frontend з backend та іншими сервісами (наприклад, email-розсилка, база даних продуктів) залишається відповідати архітектор з backend.

Отже, UX-команда презентувала дизайн, його узгодили з клієнтом. Бізнес-аналітик розробив user stories, архітектори спроектували архітектуру додатку. Бізнес-аналітик та архітектори спільно визначили необхідні роботи, їх обсяг, критерії і т. ін. Все це буде покладено в основу підсумкового плану, який візьме в роботу delivery-менеджер.

Delivery-менеджер несе повну відповідальність за виконання проекту. Основне завдання delivery-менеджера – забезпечити реалізацію проекту таким чином, щоб результат цілковито співпадав з очікуваннями замовника. Delivery-менеджер керує процесами планування та реалізації проекта, включаючи визначення пріоритетів для різних видів діяльності, відстежування досягнутого прогресу, ведення документації, створення Risk і Change Management процесів та їх дотримання. Наразі, ми знаходимося тільки на фазі Discovery, однак, delivery-менеджер вже має розуміти, що потрібно зробити зараз, щоб в кінці проекту чекав успіх. 

Delivery-менеджер повинен встановити структуру проекту і переконатися, що всі учасники усвідомлюють цілі та свої обов'язки. Крім того, delivery-менеджер спільно з account-менеджером спілкується із замовником, пропонує ідеї з оптимізації продукту, що розробляється, та бізнесу замовника в цілому. Delivery-менеджер – це технічний менеджер дуже високого рівня, це спеціаліст, який повністю відповідає за всі аспекти проекту та кінцевий результат. Він має величезний досвід управління проектами та досвід програмування, розуміє роботу кожного члена команди та володіє ґрунтовними знаннями про ІТ взагалі. 

STAFFING

Фаза Discovery закінчилася. Настав час формувати команди. Архітектор та delivery-менеджер запрошують на проект DevOps-інженера, performance-аналітика та лідів команд: з frontend і backend, з функціонального і автоматизованого тестування – всього чотири тімліди. Тімліди за участі архітектора та delivery-менеджера формують собі команди.

DEVELOPMENT

Починається фаза розробки. І в delivery-менеджера, особливо, якщо в нього є інші проекти, виникає дефіцит часу. Тому йому на допомогу приходить project-менеджер (за сумісництвом – scrum-майстер), який відповідає за внутрішні та зовнішні комунікації, побудову процесів та оптимізацію scrum. Зокрема, project-менеджер має проводити регулярні планерки, а також повідомляти статус проекта всім стейкхолдерам. Завдання project-менеджера – організувати процеси і щоденну роботу таким чином, щоб ніщо не заважало розробці та реалізації проекту в заданих параметрах бюджету/часу/якості. Оскільки технічна сторона питання залишається за delivery-менеджером, project-менеджер може не мати технічної освіти, проте повинен розуміти процес ІТ-розробки в цілому, мати досвід ведення проектів та відмінні комунікативні навички.

Задача DevOps-інженера на проекті – створити умови для безперервної розробки: встановити CI/CD, налагодити роботу інфраструктури, допомагати забезпечувати параметри якості. Таким чином, DevOps-інженер вміє працювати з CI/CD-процесами, інфраструктурою (хмари, сервери у внутрішній мережі), програмувати скрипти для забезпечення параметрів якості. 

Функціональні тестувальники, покликані тестувати frontend-частину, розбираються з результатами роботи UX-команди і бізнес-аналітика, а також пишуть тест-план і тест-кейси. Щоб виконувати свою роботу на високому рівні, функціональним тестувальникам неможливо обійтись без таких якостей, як увага до деталей і перфекціонізм. Тестувальники-автоматизатори, за умови правильно побудованої архітектури, можуть писати автоматизовані тести з першого дня розробки. Вони займаються покриттям тестами усього продукту. Тестувальникам-автоматизаторам також притаманні увага до деталей та прагнення досконалості, однак істотним для них буде й знання мови програмування, наприклад, Java або C#.

Весь цей час розробники пишуть код. Frontend-розробники зазвичай пишуть на JavaScript, Swift Objective-C для iOS, Kotlin або Java for Android, а backend-розробники – на Java, C#, Python і т.д. Для того, щоб спільними зусиллями отримати якісний код, програмістам потрібні не лише гарні технічні навички, але й вміння працювати в команді. 

Тімліди приймають активну участь в усіх фазах проекту. Як правило, delivery-менеджер делегує їм повноваження для прийняття деяких важливих проектних рішень. Тімліди ставлять задачі членам своєї команди та координують процес їх виконання. А щоб процеси в командах були добре налагоджені, тімліди повинні володіти не тільки бездоганною експертизою в програмуванні, але й лідерськими якостями, а також навичками ефективної комунікації (в тому числі – із замовником). Крім того ліди є менторами для своєї команди, допомагають з технічними питаннями і частіше за інших здійснюють code review.

ПЕРШИЙ РЕЛІЗ НА СЕРВЕРІ РОЗРОБКИ

Спочатку розробники пишуть код на своїх локальних машинах. Але в певний момент розгортається інтеграційний сервер, куди встановлюється 0.1 версія продукту. Це не повноцінний додаток, а MVP (Minimum Viable Product) – так би мовити «кістяк» програми. Його призначення – об'єднати локальні розробки в єдине ціле (перевірити роботу CI/CD) та провести перші загальні тести.  

Отже, ми випустили версію 0.1 продукту і продовжуємо нарощувати функціонал. Через деякий час розгортаємо функціонал на UAT (User Acceptance Testing) сервері, де команда з боку клієнта тестує майже готовий продукт. Клієнт також може залучити security-команду, яка сканує додаток на наявність загроз безпеки. Якщо такі загрози знайдуться розробники будуть зобов'язані їх усунути. 

Іноді до роботи підключається performance-аналітик. Його функції можуть виконувати й інші спеціалісти, однак без нього не обійтись, коли на проекті велика кількість серверів і при цьому важливий performance, тобто швидкодія. Швидкодія має вирішальне значення на банківських та трейдингових проектах, проектах розробки інтернет-магазинів та відео-хостингів, для звукових сервісів – усюди, де критичними є мілісекунди. Також performance-аналітика можна залучати на етапі Discovery, щоб оптимально налаштувати архітектуру. Цей спеціаліст вкрай потрібен ближче до завершення проекту, щоб проаналізувати performance вже майже готового продукту. 

З часом команда починає зменшуватися, на стадії UAT потрібні вже не всі. На проекті залишаються ліди з frontend та backend, тестувальник, delivery-менеджер і project-менеджер, один UX-дизайнер та частково – бізнес-аналітик. Вони доопрацьовують деталі продукту та узгоджують їх із замовником.  

HANDOVER

Handover – це процес передачі знань та відповідальності від DevOps-інженера виконавця DevOps-інженеру клієнта або SRE-команді (Site Reliability Engineers), які будуть відповідати за стабільність production.

Важливо, щоб після Handover виконавець в особі команди Application Support Engineers продовжував роботу з підтримки продукту. Application Support Engineers – це фахівці, які володіють першокласними навичками комунікації, щоб спілкуватися з користувачами й допомагати їм у вирішенні можливих проблем. Ці спеціалісти також володіють навичками DevOps для підтримки роботи інфраструктури. Крім того, вони здатні поставити задачі команді розробників, які можуть підключатися для вирішення технічних питань, які потребують змін у коді. 

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

Коли проект переходить у стадію підтримки, починається нове, захоплююче життя продукту: додаються такі ролі, як service delivery менеджер, release-менеджер та інші. Вони відповідають за роботу та поліпшення продукту, коли він вже використовується. Але це вже інша історія. 

*** 

Владислав Соломонов описав процес розробки лише в загальних рисах, однак і загального опису достатньо, щоб зрозуміти, що IT-проект – це складна єдність процесів, де важлива роль кожного. І спеціалісти-початківці без досвіду роботи можуть навчитися і спробувати себе в якості програміста, тестувальника, бізнес-аналітика або UX-дизайнера – ними можна стати «з нуля». А для того, щоб зайняти роль більш високого рівня, наприклад ліда, архітектора чи project-менеджера, потрібно багато вчитися і отримати великий досвід.