Who wants to be an analyst, або як я став аналітиком
- Stsiapan Sazanavets
- 3 лип. 2022 р.
- Читати 13 хв
Мене звати Степан, у сфері ІТ я вже більше 7 років, але повноцінним бізнес/системним аналітиком працюю десь половину цього часу. Хочу розказати історію, як я потрапив у бізнес-аналіз, з якими проблемами і приколами стикався і за що я люблю цю професію.
Part 1. Перший досвід і «гулі»
Я прийшов у сферу як практик, не пройшовши жодні курси і вивчаючи все самостійно – набиваючи гулі і читаючи книжки :) Якщо ви пройшли академічне навчання, потім здали сертифікацію і загалом все чітко і по плану – це інший шлях, зі своїми «приколами».
Почну з початку, як кажуть, - з моменту входу в професію і першого (разу) досвіду.
Особисто у мене все почалося із заглиблення. Заглиблення – це така робота, коли тобі дають великий (і тупий) напильник, показують купу необробленого матеріалу і картинку з «конем». Завдання – випиляти коня. При цьому замовник на нього потім залізе і спробує проскакати кілометрів так з 10. Правда, швидко зрозуміє, що кінь лише віддалено нагадує первинний задум, взагалі неживий і використовувати його максимально ефективно можна тільки як вішалку для одягу (майже як стілець в кутку кімнати).
Звичайно, поки ти молодий і зелений, працюєш ти навіть не з цілим конем, а швидше з правим заднім копитом чи лівим вухом, це як пощастить. Буває, що й інші частини тіла трапляються....
Можна легко здогадатись, що коні в мене виходили то без ноги, то без голови, то без хвоста. Іноді голема вдавалось навіть оживити – але творіння були в кращих хоррор-традиціях. Тим не менше, структуру коня і його можливості (в моєму випадку кінь = ERP-система) я вже знав і навіть міг підказати невезучому користувачу, що стояти ззаду коня не варто – можна і в чоло отримати. Загалом, з бізнес-аналізом, на перших порах, робота була пов’язана мало і більше нагадувала сисадміна/техпідтримку/консультанта з магазину в одній людині. Але варто віддати належне: вона прищепила увагу до деталей і навчила емпатії. Без цих навичок важко бути аналітиком – зрозуміти біль стейкхолдера, уникнути missed requirements, та і досконало сторі не написати.
Одного разу я знищив 50000 записів на продакшн базі, які (Слава Богу, науці і Україні) завдяки крутому колезі і частковому дублюванні даних у двох БД, потім були відновлені. Пам’ятаю цей життєвий урок і тепер спочатку запускаю всі запити на стейджинг-середовищі (а краще локально або ж взагалі в БД не сунусь, наскільки це можливо).Вперше оптимізовував бізнес за допомогою 3-х галочок (чек-боксів) узгодження документа і кількох правил. Роздав доступ різним користувачам і забезпечив неможливість натиснути одну галочку, якщо вже натиснули іншу. Був задоволений собою як слон. Правда, користувачі все одно роздруковували цей документ і носили на підпис керівникам...
Було весело – ми багато літали у відрядження, багато спілкувались, і через кілька років проєктна команда відчувалась як сім’я. Я нарощував софт-скіли, тестував UI, робив запити в БД (хехе), багато спілкувався з кінцевими користувачами і навіть побував в телефонній техпідтримці. І одного разу побачив у колеги творіння Вігерса «Розробка вимог до програмного забезпечення». Переді мною відкрився портал (у пекло) у світ якісних вимог та системного підходу до їх опису. Досі вважаю її чудовим посібником із входу в бізнес-аналіз. Але курси, звичайно, краще :)
Паралельно з читанням Вігерса у вільний час на роботі все більше з’являлося активностей на кшталт “подивитися, як працює керівник відділу, вислухати скарги (і лайку) - все записати і передати розробникам”. На той момент я не знав, як правильно назвати мої записки. Це тепер я вже знаю, що таке single user requirements documented by natural language. Або bugreport (залежно від того, як голосно лаявся користувач, озвучуючи зауваження).
Перші техніки збору вимог - інтерв'ю та спостереження - теж були одразу випробувані на практиці, а потім уже підкріплені теорією. Дещо пізніше стало відомо, що перед тим, як проводити інтерв'ю стейкхолдеру, потрібно підготувати адженду, накидати питання, а краще прийти з прототипом. А на початку шляху ти з максимально чемним виглядом заглядаєш у кабінет і такий: "Як у Вас справи? Працює система?" і слухаєш годину, як бідолаху дістала робота, і взагалі начальник у нього - ***** (цензура не дозволяє написати це слово, тому що багато керівників можуть впізнати себе). Але після таких розмов я виходив із чіткою думкою “потрібно полегшити йому життя” і продовжував читати корисні ресурси, щоб розуміти, як саме це можна зробити.
Через кілька років роботи з ERP, кілька місяців посиленої підготовки та чимало витрачених нервів, я пішов в іншу компанію та повноцінний (ура!) бізнес-аналіз, про що розповім далі.
Підсумувати першу частину хочу ось чим:
1. На початку дуже потрібен ментор. Без нього ніяк. Інформації море, і варто трохи копнути - відразу тонеш. Круто, якщо у ментора все по поличках і є (хоча б якийсь) план, якого ви дотримуєтеся. Мене мій перший ментор навчив бути скрупульозним, малювати IDEF0 діаграми (і трошки BPMN), і що кінцевому користувачеві потрібні максимально детальні інструкції.
2. Буде багато промахів. Спочатку – взагалі темрява, потім менше. До цього потрібно бути готовим і намагатися не сприймати кожен як останній (на цьому місці роботи). На жаль чи на щастя, помилки – дуже дієвий механізм мотивації та адаптації, і ми на них не так уже й погано вчимося. Тут під “ми” я маю на увазі тих, хто хоче рости, а не просиджувати штани на роботі.
3. З бізнес-аналізу дуже є багато інформації та теорії, зокрема. Підходів до вимог кілька, технік маса, моделей та нотацій теж вистачає. А якщо першого ж року відкрити BABOK, то можна і втратити розум. Основна порада – дізналися щось нове і одразу застосовуємо, інакше забудеться. На практиці дуже важливо мати спільне розуміння між командою розробки та замовником, а цього можна досягти, просто спілкуючись з обома сторонами. Так, займає багато часу, так, не завжди ефективно – зате працює. А використовуючи багатий аналітичний інструментарій, ми лише підвищуємо якість та швидкість своєї роботи, хоча ціль залишається незмінною
Part 2. Як розвиватись (а головне, навіщо)?
Взагалі, до думки, що настав час йти з першої роботи, я прийшов не відразу. Постійне життя у русі та зміна місць були явно до душі, відрядження я любив. Але в якийсь момент прийшло розуміння (у мене часто буває, що щось, що випадково спало на думку, закріплюється в голові надовго), що хочеться отримувати інший досвід, застосовувати англійську мову і взагалі спробувати вже намалювати ту саму схемку Chemical tracking system з книги Вігерса, але вже для свого проекту.
В один момент я дозрів і звільнився. Йшов без офера на руках, практично «у нікуди», на свій страх і ризик.
Опинитися віч-на-віч із ринком було за відчуттями як зустріти гопника в темному провулку. Наче 5 років досвіду, а релевантного майже немає. Начебто і знайомий з типами вимог у теорії, але працював на практиці тільки з користувацькими і лише доопрацьовував специфікацію з функціональними. Начебто і проходив весь життєвий цикл проєкту, але чим саме займається аналітик на фазі Presale або Discovery – відповісти не так просто. На додачу до хвилювання, якого навіть не море, а цілий океан, бо в житті було «півтора» співбесіди, та й то кілька років тому. Ось і ситуація була як у анекдоті, де відвідувач тренажерної зали зустрічає хулігана. «Можу зробити 5 по 15 присідань», а от ухилитися від удару – навряд чи.
Курйозів було багато. Якось отримав відмову від компанії, тому що «не знає, ким хоче бути через 5 років». Та я в той момент не знав до ладу, хто я, не те щоб розуміти, куди розвиватися. Хоча тестове завдання з BPMN і знайомство з Camunda пізніше стали в нагоді. Тож загалом відмовили по суті, і за досвід їм вдячний :)
Відмов було більше, ніж я очікував. Десь не проходив через відсутність досвіду роботи з англомовним замовником, десь не підходив по скілам, що були на той момент. Якось пощастило потрапити на тип співбесіди «м’ясорубка» в одній великій компанії. Це коли тебе 1.5 години мучать технічними та не дуже питаннями, складаючи повний профіль твоїх знань, щоб знати, до якого замовника можна тебе прилаштувати. Вийшов я звідти спітнілий, вимотаний і з повною впевненістю, що я проживаю на дні океану і друга мого звуть Патрік. Але пізніше на запит мені дали розгорнутий відгук, та й я сам брав в примітку питання, на які не зміг відповісти під час співбесіди. Цей момент вважаю переломним у кар'єрі, оскільки я вперше дізнався, наскільки широка сфера знань аналітика і скільки ще потрібно вивчити. До речі, на сайті Хабр є стаття «250 питань системному аналітику» - її дуже раджу, так як багато з них на тій співбесіді якраз і питали.
Яким же був мій подив, коли мені запропонували співпрацювати. Поки мене продавали замовникам, я поспілкувався з PM і попросив список літератури від уже досвідчених аналітиків, щоб розуміти, що потрібно ще вивчити. Пройшов кілька внутрішніх співбесід, зрозумів, що питають і як краще відповідати. У результаті, щоправда, потрапив у зовсім іншу компанію, так як не щастило – то один замовник відмовиться від розширення проектної команди, то інший задасть нестандартне питання, від якого я розгублюся :)
Ще кілька тижнів пройшло у співбесідах. У мене був план, і я його дотримувався: висновки робити після кожної співбесіди, записувати питання та зберігати тестові завдання для подальшого розбору. Відчував, що з кожною наступною співбесідою стає легше та й відповідав впевненіше. У результаті отримав 2 офери, один з яких прийняв.
Нещодавно натрапив на статтю про ефект Даннінга-Крюгера (зображення вище). Як же це життєво! На власній шкурі знаю, що працює все саме так. Хочеться вірити, що долину розпачу вже подолав і йду вгору, тому що момент, коли було отримано довгоочікуваний офер, дуже сильно нагадував Пік Дурості з наступним усвідомленням, що «поле неоране» попереду та розпачем. Озираючись на свій шлях і бачачи, скільки ще доведеться пройти, думаю, що наша сфера не те щоб нескінченна, але точно розширюється за законами Всесвіту :) Якщо в якийсь момент ти вважаєш, що вже все знаєш, найімовірніше, ти помиляєшся. Але в тому й весь шарм для людини, відкритої до вивчення нового.
Насамкінець метафора, щоб коню з першої частини не було нудно. Думаю, що багато хто стикався з викликом електрика додому. Як правило, добрий майстер приходить на виклик з ящиком інструментів і дрібницями, які використовуються найчастіше (або зателефонує і запитає, в чому проблема, а потім купить заздалегідь, що потрібно). Так і в бізнес-аналізі: чим більше досвіду у нас є, тим більше ми приносимо з собою на проєкт і можемо використовувати для допомоги замовнику (і не бігаємо в паніці, тому що на вивчення запиту клієнта - тиждень, а то й менше).
Варто розвиватися, щоб бути корисним у будь-якій ситуації, незалежно від домену, масштабу та етапу життєвого циклу проєкту. Поки досвіду немає - з собою у нас тільки кмітливість і вміння швидко вчитися, але й ці навички мають відчутну межу.
І трохи порад на завершення:
1. Досвід співбесід та досвід роботи – це кардинально різні навички. Кожному, хто на початку шляху, раджу погоджуватися на співбесіди та після кожної проводити роботу над помилками. Брати на замітку питання, шукати відповіді, просити фідбек.
2. Не сумувати, якщо співбесіда пройшла погано. «Завалене» інтерв'ю стає козирем у рукаві, як тільки буде «загуглене» перше запитання з тих, на які було важко відповісти, і знайдено на нього відповідь.
3. Трохи ірраціонального - реально «ваша» компанія найме вас неодмінно. Коли ти самотній, щоб знайти пару, потрібно ходити на побачення (у даному випадку на співбесіди)
4. Технічний, але недосвідчений аналітик (на мій погляд) набагато ефективніший у роботі, ніж досвідчений, але який працює «як завгодно» і «як звик»
5. Хороша практика - збирати всю корисну інфу у хмарі та структурувати її (наприклад, у notion). Notion загалом чудовий інструмент, але сам про нього не знав, поки не побачив у Олі Рапопорт :)
6. Професійні та близькі до них книги не такі нудні, як здаються. Пам'ятаю, як мені сподобалася Ціль Голдратта, яка не поступається сюжетом і глибиною пригодницьким романам.
7. Сфера IT передбачає постійний розвиток. Технології змінюються і кількість інформації зростає у прогресії. Розвиваються інструменти – і ми маємо за всім цим встигати. Інакше залишимося на нескінченному сапорті застарілого ПЗ, а не на вістрі індустрії
8. Бонус! Книги, які рекомендую вивчити на початку шляху (і запеняю щодо них, тому що сам читав)
Андрій Дмитрович Перерва "Шлях аналітика"
Карл Вігерс "Розробка вимог до програмного забезпечення"
IREB Foundation level Handbook або Requirements engineering Fundamentals
Software requirements memory jogger
Part 3. Мама, забери мене назад
Компанію змінив, онбординг пройшов, пора починати роботу.
На початку шляху завжди страшно (спойлер, страшно завжди, просто менше). Ментор завжди зайнятий, замовник тисне, PM наполягає на тому, що документи повинні бути написані вчора і узгоджені позавчора, розробники смикають кожні 10 хвилин, 5000 change requests надійшло вранці поштовими голубами... Список причин для стресу можна продовжувати нескінченно, і у кожного з нас він свій, персональний.
Мій перший проєкт у ролі бізнес-аналітика був складним у тому, що до нього не було досвіду взаємодії з англомовними замовниками та ведення всієї документації англійською. Після ГОСТів 19/34 з їх пояснювальними записками і програмами та методиками випробувань бачити нормальний Vision and scope, SRS або просто опрацьовану user story за відчуттями, подібно до ситуації, коли ти з батьківського Москвича сів у першу у своєму житті іномарку. Концепція аналогічна - те ж кермо та колеса, але рівень кардинально інший, як і швидкості. Доводилося постійно заглядати у вкладку браузера з перекладачем (до речі, особистий лайфхак, Reverso часто дає фрази в потрібному контексті, що набагато корисніше за переклад «слово в слово») і п'ятсот тисяч разів перечитувати те, що написав. На перше інтерв'ю з product owner я прийшов із двома аркушами А4, списаними дрібним почерком. Очікувано, кілька разів не зрозумів відповіді, обмежившись фразою "Ok, I got you", хоча got я в той момент тільки те, що потрібно терміново покращувати рівень сприйняття нейтів-спікерів. Рази три заплутався у своїх же записах і повертався до пропущених запитань, ламаючи логічний розвиток інтерв'ю. Але благо, з кожним новим тижнем було все легше і легше, адаптація працювала – замислювався я про неї чи ні. Зі страхом бути незрозумілим і через хвилювання не пояснити свою думку, боровся за допомогою візуального контенту. Та й взагалі, дуже допомагало не приходити з порожніми руками на дзвінки – ти завжди демонструєш якесь «домашнє завдання» на екрані. Це може бути адженда, mind map, схема, прототип або приклади реалізації (наприклад, пам'ятаю, як показував механізм виділення кількох листів прямо з gmail). Навіть із не найкрутішою англійською це допомагало (і продовжує допомагати) донести думку і отримати цінний фідбек.
Другий "стрес" у мене був пов'язаний з тим, що ніколи до цього не писав детальні User stories, і в цілому звик фіксувати вимоги звичайною мовою, зідзвонюючись пізніше з розробником, щоб пояснити спірні моменти. Invest критерії, definition of ready та definition of done - це щось ельфійською, так? На допомогу приходили всі ресурси з прикладами - від Хабр до інститутів бізнес-аналізу. У той момент я ще не чув про IREB - їхній handbook дуже просто і зрозуміло розжовує роботу з вимогами як з одиночними, так і зі специфікаціями і дає вказівки, куди заглибитися. Прищеплене університетом «не знаєш – гугли» рятувало. Хоча зараз, згадуючи, де я тоді шукав приклади, хочеться відправити себе «минулого» на повноцінний курс чи кілька воркшопів по тематиці. Тоді я чомусь був впевнений, що в інтернеті повно безкоштовної та релевантної інформації. Ага (смайлик рукалице), аж бігом.
Третій страх - раніше небачені технології та "тули". До цього були десктопний додаток і SQL, з чим після кількох років справляєшся досить легко. А тут понеслося: 50 відтінків аутсорсу. Різні БД, мікросервісна архітектура з купою API, веб і мобільні додатки, дизайни в Figma, прототипи в Axure, скетчі в Balsamiq ... І в усьому потрібно було змогти розібратися, тому що потрібно тримати матеріали в актуальному і узгодженому стані. Та й просто буває потрібно накидати screenflow, щоб замовнику проілюструвати ідеї на черговому дзвінку. З моєю цікавістю розбиратися в новому інструменті на кшталт Figm'и завжди в задоволення, аби час був. Тішить, що його вистачало – зараз розумію, що в умовах жорсткого дедлайну витратити пів дня на навчання – небачена розкіш.
Іноді закрадається думка: «Зітріть мені пам'ять — я хочу пережити це все знову». Перший досвід у професії має свій особливий шарм. Так, бувало стресово. Так, завжди сумнівався у результатах своєї роботи. Але мені пощастило потрапити до оточення, де не боїшся ставити запитання. А коли команда відкрита до твоїх постійних «чомучок» і досвідченіші колеги діляться накопиченим багажем знань, відчуваєш, що готовий гори звернути. Що, сподіваюся, у мене й виходило.
Part 4. Хто я?
Поки ти новачок у професії, "екзистенційні" питання у голові виникають рідко. У тебе постійно щось горить, щось не встигається, дні забиті потрібними та не дуже мітингами. Таски "нарізаються" менеджером проекту, якісь завдання для розвитку ставить ментор. У такому кругообігу проходять, мабуть, перші кілька років. Працюєш собі і особливо не замислюєшся ні про свою роль на проектах, ні про роль у команді, ні про те, навіщо ти вранці прокидаєшся і підключаєшся на дейлік.
Перші питання про те, хто я і навіщо роблю свою роботу, виникали ще під час зміни компанії та приходу у повноцінний бізнес-аналіз (про цей момент писав у першій частині). Але тоді було не до пошуків "сенсу життя", вистачало й інших, більш пріоритетних моментів. Сфера наша досить велика, проекти у всіх різні, і, найголовніше, обов'язки на проектах також різні. Мені доводилося бути і технічним письменником, і трохи дизайнером, і тестувальником, займатися системним аналізом - і нарешті, бути бізнес-аналітиком :) І оскільки коло обов'язків було широким, мені було неймовірно складно пояснити, чим я займаюся на роботі. Мама досі, мабуть, думає, що я програміст.
Так ось, що ж я за звір такий?
Починаючи працювати як аналітик, я часто використовував фразу "я – це посередник між замовником та проектною командою". Оскільки вона описувала якраз те, чим я займався – спілкувався із замовником, документував вимоги та заводив таски після узгодження скоупу робіт із командою. Як же я глибоко помилявся і як добре, що до мене все ж таки дійшло, що бути "посередником" - це шлях не те, щоб у нікуди, але який веде до гарантованих проблем. Розуміння почало змінюватися, коли теоретичні знання стали складатися з досвідом та магічним чином створювати ясну картинку в голові. Я тоді відчув себе як дитина трьох років, якій вдалося правильно поєднати дитячий пазл із великими яскравими елементами. Хіба що не "угукнув" радісно :)
Раз згадав про поєднання теорії з практикою - на цьому моменті хочу висловити окрему подяку за читання BABOK усередині BA Unit'а компанії, де я працював, без них метаморфози моєї свідомості почалися б значно пізніше.
Загалом, не дуже люблю BABOK. Усі, хто мене знає, не раз чули, як я плююся отрутою в його бік і як мене дратують філософські формулювання та розмиті терміни звідти (слухав подкаст від українських хлопців про сертифікацію і впізнавав себе - хто не слухав, As a User I want to see №41). Але дивно, що правильні слова, які глибоко в’їлись в пам’ять і які найкраще пояснили мені, в чому суть роботи, я знайшов саме в BABOK. А прочитані пізніше Agile Extension та IREB Fundamentals лише зміцнили мене у думці, що це так і є. Наводжу ці слова як ілюстрацію.
Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders.
The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.
Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.
Пропустити через себе величезну кількість інформації, розкласти все "по поличках", визначити скоуп та контекст системи/продукту. Докопатися до суті проблеми (без root cause ніяк), провести impact-аналіз. Досягти того, щоб рішення відповідало потребам замовника і реально "вирішувало цю саму проблему". Три великі сині кити нашої роботи :)
Щоправда, власний досвід та Agile Extension підштовхують мене додати ще один, четвертий пункт, не менш важливий (це не цитата, а моя думка, але дозволю собі її також виділити).
Business analyst is responsible for building and maintaining shared understanding between all (at least most of them) persons involved in the project
Цю частину я люблю, мабуть, найбільше. Команда, яка розуміє, які потреби замовника вона вирішує, і мотивована виконувати роботу якісно і саме так, як замовнику потрібно (think as a customer, моє улюблене). Замовник, який чітко усвідомлює, яку проблему ми вирішуємо і що команда працює на його благо, не покладаючи рук.
На мою думку, добрий аналітик нагадує іноді сімейного психолога. А сім'я являє собою щось на зразок Містер і Місіс Сміт, де з одного боку замовник, а з іншого - проектна команда, і вони іноді готові вбити один одного. А ти спокійний, ти готовий вислухати обидві сторони, виявити емпатію та поставити правильні запитання. І поки "пацієнти" дадуть відповіді на питання, вони самостійно зрозуміють, у чому проблема, і дійдуть до вірного рішення. Тому сприяє здорова дружня атмосфера на зустрічах/дзвінках, розбавлена доречним гумором і доповнена інформативними діаграмами і прикладами.
А також постійний збір фідбека та робота над помилками. І це все – моя (наша) робота.
І якщо хтось говорить, що BA на проекті не потрібен/не є обов’язковим – це просто він не працював з добрим аналітиком в команді.
Є підстави вважати, що я вірно обрав професію. Тому що можу отримувати задоволення від усіх її аспектів: від розмаїття проектів і завдань, від спілкування з реально розумними людьми (які набагато розумніші за мене), від креативних активностей у вигляді створення діаграм і дизайну продукту, від моментів, коли докопався до суті проблеми і коли замовник затвердив розроблене командою рішення... І найголовніше, коли бачу, що зробив чиєсь життя краще, сприяючи перетворенню ідеї, що виникла в голові, на щось матеріальне.
(переклад Nataliya Hrabovska)
Новини та статті з бізнес-аналізу:
Коментарі