Як бізнес-аналітику подружитись із девелопером

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

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

У цій статті я хочу поєднати «хардову» і «софтову» сторони співпраці цих двох світів: представника бізнесу і технічну сторону. Ось декілька порад для ефективної та дружньої співпраці.

1. Взаєморозуміння та повага

Hard Side

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

Soft Side

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

Якщо розробник відчуває, що він не просто «doer» (виконавець), а його чують і навіть прислухаються, в майбутньому це забезпечить кращу мотивацію та результати. Бо у людини буде відчуття, що він є частиною чогось більшого і його вплив приносить профіт.

2. Якісна комунікація

Hard Side

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

Soft Side

По собі точно знаю, що інколи так ніяково задати питання, бо з усього сказаного розробником ти зрозумів тільки " а давайтеˮ і «зробимо за пару спрінтівˮ. А девелоперу, водночас, часто соромно перепитати ціль цього спрінта чи актуальні пріоритети чи що то за «Userfeed», в якому ми збираємо фідбеки по функціоналу від юзерів.

І це все є великими «блокерами» для нашої результативної співпраці.

Тож, відкрито обговорюйте проблеми та пропонуйте рішення. Не бійтеся перепитати про незрозумілі моменти або сказати, що це рішення ми зараз не можемо собі дозволити і треба придумати "дешевшуˮ альтернативу. Це допоможе уникнути непорозумінь, конфліктів і затримок у роботі.

3. Документація та вимоги

Hard Side

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

Soft Side

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

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

Гнучкість і готовність адаптуватися допоможуть підтримувати мирний робочий процес.

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

4. Спільна робота над рішеннями

Hard Side

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

Soft Side

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

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

5. Постійне навчання

Hard Side

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

Soft Side

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

6. Людяність

Soft Side

Всі ми люди і поза робочими мітингами. Можемо ображатись, демотивуватись, переживати негаразди чи банально хворіти.

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

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

Висновок

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

Подружитися з розробниками — це інвестиція в успіх проєкту та задоволення від роботи в команді.