29 червня 2021 Anna Abramova опублікувала на сайті Art of BA статтю, переклад якої пропонуємо до Вашої уваги
Постановка проблеми
Часто, приймаючи в роботу новий проект як бізнес-аналітик, я бачу опис якогось програмного рішення, але не отримую на вхід інформацію, які проблеми воно покликане вирішувати тут і зараз, чому воно побудоване саме так, і як планується його розвивати надалі. Як постійний учасник/організатор професійних конференцій і тренер, я багато спілкуюся з колегами, в тому числі провідними аналітиками та керівниками проектів, і бачу, що це не поодинока проблема.
Чимало тім-лідів і різного роду керівників нарікають, що їхні колеги обмежуються опрацюванням одного рішення, не розглядають альтернативні варіанти, а також часто фокусуються на внутрішній реалізації системи, не уявляють контекст роботи користувача і поточну ситуацію бізнесу. Та й самі колеги-аналітики, приймаючи естафету в роботі над системою, нерідко нарікають на тих, хто не вклав у вивчення контексту достатньо зусиль до них або не задокументована цю інформацію. Для провідних фахівців, що відповідають за роботу команд, відсутність загального розуміння контексту і цілей критично тим, що їм доводиться постійно проводити глибоке рев’ю роботи аналітиків, що забирає час від більш високорівневих обов’язків, і на це рев’ю не завжди вистачає часу. Далі в статті розповім, чи справедливі такі нарікання, на мій погляд, що можна з цим зробити, і чи завжди потрібно щось робити саме з аналітиками чи можна поліпшити ситуацію іншими способами.
Чому недостатньо пильний розгляд розв’язуваної проблеми турбує колег? Часто він призводить до того, що реалізується не найкращий варіант для розв’язання поточної задачі. Зміни в робочих системах для бізнес-замовника майже завжди призводять до трансформації його поточного стилю роботи, і в разі неоптимального нового рішення воно стає невиправданим, а час людей на перенавчання і звикання до нового витрачено. Для команди розробників це у величезній кількості випадків виливається в нескінченне дописування і переписування системи, і часто своїм коштом.
Крім тимчасових і фінансових втрат для обох сторін це призводить не тільки до втрати лояльності одного клієнта, а й до репутаційних втрат на ринку в цілому. Навіть якщо ми говоримо не про аутсорс, а про команду всередині компанії, це може вплинути на прийняття її майбутніх пропозицій і виділення фінансування відділу в майбутньому.
Крім того, що без всебічного розгляду завдання рішення виходить логічно і архітектурно неповне, що обіцяє зайві трудовитрати в підтримці, це також призводить до невиконання вимог галузевих і державних регуляційних документів/стандартів, а це тягне неможливість використовувати нове рішення в цілому. Порушення вже відомих усім вимог до зберігання персональних даних може розглядатися як адміністративне правопорушення, і привести до штрафу. Державні організації пред’являють досить серйозні вимоги до безпеки введення і зберігання даних, також у них дуже специфічні вимоги до інтеграції, тут простим REST API не обійдешся. Що вже говорити про вимоги до зберігання, забезпечення доступу і деперсоналізації медичних даних, наприклад, радіологічних досліджень.
Що потрібно для задоволення запиту
З усіх проектних ролей місія «бачити завдання в цілому» найближча бізнес-аналітику, тому я хочу поговорити про діяльність, яка допоможе наблизитися до широкого розгляду завдання з точки зору саме цієї ролі. Я не відмовляю в такої потреби керівнику проектів, наприклад, але у нього все-таки фокус на тому, щоб знайти баланс між часом, обсягом робіт і задоволеністю замовника, тому можливість розглядати всі варіанти відсутня.
Отже, якщо ви вирішили серйозно взятися за переосмислення і аналіз поточної задачі, вам варто:
- розглядати задачу з точок зору різних зацікавлених сторін,
- розглядати весь життєвий цикл системи,
- аналізувати вхідну інформацію на повноту, якість і актуальність,
- виявляти ризики та обмеження,
- використовувати широкий набір аналітичних інструментів,
- розглядати кілька рішень,
- спочатку розглядати тривіальне рішення.
Можливо це і неповний список, але і його досить, щоб побудувати план саморозвитку або розвитку своєї команди на пару років, тому обмежимося поки ним.
Розглядати ситуацію з точок зору різних зацікавлених сторін. Точка зору бізнес-замовника і користувача, керівника проекту та архітектора, тім-ліда і техпідтримки – важливі фокуси уваги. Це не означає, що аналітик повинен подумати за всіх, це означає, що аналітику повинна бути доступна інформація про принципи архітектурного проектування поточної системи й управління цим проектом, про те, як планується підтримувати проект, в ідеалі і про те, за що саме платить спонсор. Якщо ця інформація ніде не задокументована, повинні бути доступні люди, які можуть відповісти на ці питання, і не треба соромитися шукати їх і ставити питання про контекст розробки.
Розглядати весь життєвий цикл системи. Також дуже важливо мати в голові часову перспективу життя розроблюваних продуктів. Потрібно пам’ятати, що продукт не тільки розробляється вами, а й підтримується – навіть якщо це всього півроку-рік, – вам доведеться самим відповідати на питання та узгоджено змінювати те, що ви зараз напрацювали, а потім передавати в підтримку іншим людям. Ще пам’ятайте: ваше систему точно рано чи пізно викинуть і замінять на іншу. Про це завжди говорилося в підручниках програмної інженерії, але до певного часу цей постулат можна було ігнорувати як абстрактний. Тепер, коли ми кожні 2-5 років міняємо телефони і ноутбуки, абстракція перетворилася в реальність, про яку щодня спотикається бізнес.
Головною цінністю для бізнесу є не ваша система, а інформація, яка в ній зберігається, і якщо у нього не буде впевненості, що ця інформація може бути безпечно збережена або експортована, ваша система бізнесу не потрібна. Тому думати наскільки довге і щасливе життя проживе те, що ви зараз робите – чи має воно бути прототипом, на якому ми моделюємо розв’язання задачі, або цінним джерелом інформації хоча б на десятиліття, – дуже важлива вправа.
Аналізувати вхідну інформацію на повноту, якість і актуальність, робити запити додаткової інформації. Ми отримуємо інформацію на вхід різними способами: іноді це технічне завдання, розписане до полів баз даних, іноді макет інтерфейсу, іноді просто кілька слів на кшталт «реалізувати можливість відображення списку замовлень в Особистому Кабінеті користувача».
В технічному завданні, створеному недосвідченим замовником, часто не вистачає інформації про цілі та обмеження системи, по макетах інтерфейсів неможливо однозначно відновити призначені для користувача сценарії та життєві цикли об’єктів, зображених на цих макетах, а в разі потреби відображати список замовлень ми ніяк не зможемо зрозуміти в яких умовах користувачі працюватимуть з продуктом, які у них ролі.
Запитувати додаткову інформацію про обмеження, ставити додаткові питання там, де в інформації видно прогалини, перевіряти, коли створений той чи інший артефакт, наскільки він актуальний і яке відношення до нього має той, хто буде приймати результат робіт – необхідні перші кроки при опрацюванні завдання.
Виявляти ризики та обмеження. Про ризики та обмеження я вже почала говорити в перших пунктах. У нас завжди є ризики, пов’язані зі зміною зацікавлених сторін або їх точок зору і побажань. Є обмеження, пов’язані з часом виконання завдань, поточною архітектурою, використовуваними інструментами. Є регулююча документація на рівні держави, галузі, компанії замовника. Є сильні та слабкі сторони команди й особисті переваги замовника. І, звичайно, неповні дані, на основі яких повинні бути прийняті рішення про архітектуру, вибір певних елементів інтерфейсу, вибір глибини опрацювання рішення: проектування стійкої архітектури чи впровадження “костиля”.
На моє глибоке переконання, завданням аналітика тут є бачити ризики і явно описувати обмеження. Аналітик працює з величезною кількістю інформації на різних рівнях абстракції і бачить прогалини й нестикування, які не можуть побачити інші. Порушити питання про ці нестикування – хороша ідея. В ідеалі, звичайно, ще пояснити до яких проблем вони можуть привести, але це не завжди в рамках компетенцій однієї людини, часто потрібне опрацювання з тим, хто відповідає за надання інформації – замовником, керівником проекту, архітектором, UX/UI-фахівцем. Може виявитися, що в цьому місці криється щось очевидне для замовника, але невидиме для вас, і це може вплинути на виконання багатьох суміжних завдань. У будь-якому випадку не варто намагатися читати думки і добудовувати логічні ланцюжки, краще проговорити невідповідність явно.
Що стосується обмежень – їх теж потрібно виявляти дуже ретельно, перш ніж кидатися щось робити або змінювати, прискіпливо досліджувати контекст: «Як це працює зараз? Чому так? »,« Що в цьому добре, а що краще змінити? »,« Що ні в якому разі не можна змінювати? »,« Що ми не можемо поміняти в рамках поточних домовленостей? »,« А можемо ми зробити так? ». Всі ці питання повинні передувати опису та реалізації якогось би там не було програмного продукту.
Використовувати широкий набір аналітичних інструментів. І я не маю на увазі Jira, Confluence, MS Visio, draw.io, Visual Paradigm або Enterprise Architect. Я маю на увазі вміння представляти інформацію для роботи та документування в різних видах: текстовому, графічному, пояснювати усно. Уміння моделювати і писати сценарії не тільки за певним шаблоном, а й вибирати представлення, найбільш підходяще для роботи в даному конкретному випадку, в даній конкретній команді.
Звичайно, вміння заповнювати шаблон, прийнятий в цій компанії – навик, який не можна недооцінювати, – особливо якщо шаблон актуальний і регулярно переглядається. При цьому варто розуміти, що працюючий шаблон – це не тільки набір полів, але і правила заповнення цих полів, і інформація про етапи процесу, які забезпечують інформацію для їх заповнення.
Володіти широким інструментарієм – це також постійно використовувати існуючі інструменти, розуміти їх обмеження і доповнювати ними один-одного. Потрібно описати взаємодію користувача з системою? Що краще підійде: User Story у вільному стилі, структурований Use Case, діаграма послідовності UML, діаграма діяльності UML? Це залежить від того, наскільки складна логіка стоїть за взаємодією, наскільки глибоко потрібно занурюватися в деталі реалізації в даний момент, з ким потрібно погоджувати це представлення. Кожен інструмент можна застосовувати і у кожного є свої обмеження. Use Case відмінно структурований, але дуже трудомісткий в описі, діаграма послідовності відмінно показує точки взаємодії, але погано працює зі складною логікою.
Для мене ідеальний підхід до опрацювання кожного завдання – використовувати 2-3 інструменти, обов’язково включати текстове і графічне представлення інформації. Це змушує мозок працювати в різних режимах і розглядати різні аспекти, не втрачаючи загальної картини.
Розглядати кілька рішень, в тому числі рішення, що нічого не потрібно робити. Часто, коли бізнес-замовник приходить до нас із запитом, він найчастіше просить нас реалізувати якесь конкретне програмне рішення. З огляду на перші три пункти цієї статті, ми цілком можемо побачити, що це рішення не єдине, і можливо навіть не найкраще. В такому випадку можна зробити дві речі: почати перевіряти рішення на стійкість і продумати кілька альтернативних рішень.
Перевірка рішення на стійкість – це уявне моделювання ситуації, як рішення поведе себе в тому чи іншому випадку. Тут можна задавати людині, що пропонує рішення, питання «А що, якщо так?», «А якщо користувач поведе себе так?», «А якщо стане недоступним джерело даних?», «А якщо законодавство зміниться?», «А якщо прийде в один день набагато більше користувачів, ніж ви очікуєте? ». Всі ці питання дозволять автору рішення самому краще його продумати і викличуть набагато менше опору, ніж пряма вказівка на недоліки, видимі зі сторони.
Якщо у нас занадто мало часу, або ми занадто занурені в контекст, ми стаємо зашореними і не бачимо альтернативних варіантів. В такому випадку можна навмисно поставити собі завдання опрацювати і запропонувати мінімум три рішення. Якщо фантазія не включається просто так, то можна користуватися різними принципами, наприклад, придумати три рішення по стійкості і трудомісткості: 1) найдешевше, але яке точно потрібно буде переробляти, 2) середнє по трудомісткості, але вимагає доопрацювань в подальшому, 3) архітектурно-продумане, але вимагає значних змін в системі. Є інший варіант генерації рішень, який часто використовують продавці і керівники проектів – продумати рішення, яке найбільш вигідно і цікаво вам, як виконавцю, наприклад, з точки зору зручності реалізації, підтримки та продовження співпраці з бізнес-замовником. На додаток до нього коротко накидати пару рішень, що показують можливі ризики. Зазвичай в цьому випадку також пропонують всі три рішення, але одне, потрібне вам, підноситься як діамант серед порожньої породи.
Спочатку розглядати тривіальне рішення. У пострадянському ІТ, схоже, розвинений психологічний комплекс, викликаний минулим, жадібністю і засиллям державних грошей в економіці, які потрібно просто освоїти і відзвітувати. Він проявляється в тому, що якщо прийшов запит щось зробити за гроші, то потрібно обов’язково це зробити. Навіть якщо це зашкодить бізнесу замовника, зіпсує наш програмний продукт і в рази ускладнить його підтримку. Часто колегам здається, що якщо ми не погодимося на все і відразу прямо зараз, то наступного разу нам не запропонують роботу.
У той же час, ситуація абсолютно аналогічна ситуаціям у інших сферах життя: ви ж самі, ймовірно, з більшим бажанням вдруге підете до лікаря (автомеханіка, косметолога, потрібне вписати), який не змусить вас після першого ж прийому проходити величезну кількість діагностики і дорогих процедур. Бізнес-замовник теж цінує, коли йому пропонують не просто руки, але експертизу, якої у нього немає. Обов’язково розглядайте разом з замовником переваги і недоліки нульового рішення – рішення нічого не робити. Задайте питання: «А що буде, якщо нічого не зміниться?». Це також допоможе виявити ризики і обмеження.
Що заважає всеосяжному підходу
Буває, що аналітик вже більше року працює в компанії, начебто вже міг вивчити галузь і продукт, інтерв’ювали його добре, про існування різних інструментів він знає, але ризики і обмеження до сих пір не підсвічує, і рішення до сих пір пропонує однобокі, що не враховують точки зору бізнесу, користувачів або архітектора. Можливо проблема тут не в конкретній людині, а в сформованій практиці роботи в вашій команді.
Ось фактори, які не сприяють широті мислення:
- коли аналітик задає керівнику проекту, тим-ліду, замовнику питання, які здаються неочевидними, або відповісти на які не так просто, він чує у відповідь «Навіщо це тобі?» або «Тобі це не треба.»,
- майже половина завдань, які ставляться фахівцеві, потрібно було зробити вчора,
- аналітик виконує дуже багато ролей: бізнес-аналітик, UX/UI-інженер, тім-лід, техрайтер, системний аналітик і ще підробляє за архітектора.
На опрацювання завдання «вшир і вглиб», повноцінний розгляд проблеми, потрібен час і дозвілля, як для заняття творчістю і філософією. Під «дозвіллям» я маю на увазі час, в який можна просто обробляти в голові накопичену інформацію. На одній з наших конференцій ми прийшли до висновку, що аналітику потрібно мінімум дві години на день «на подумати» без переривань на питання від команди, переговори та інші завдання. Якщо ж аналітик бере участь більше ніж в трьох зустрічах – живих або онлайн – в день з великим складом людей, весь час зайнятий розрулюванням поточних ситуацій і повинен швидко, як на конвеєрі, поставляти завдання в розробку, у нього ніколи не буде часу і внутрішнього ресурсу, щоб опрацьовувати свої завдання якісно з точки зору аналізу і проектування, він буде природним чином брати перше очевидне рішення і опрацьовувати його системно, але більше на рівні реалізації.
Ситуація, коли ми намагаємося «прокачати» співробітників замість того, щоб робити процес більш ефективним, найчастіше призводить до того, що співробітники навчаються і йдуть, так як при поточній організації роботи нові цікаві навички незастосовні. Тому перш ніж нарікати, що аналітики недопрацьовують, спочатку вирішіть, що ви насправді хочете від колег: щоб вони швидко працювали по усталеному процесу, або щоб вони відпрацьовували широку картину, що може привести до дуже непередбачуваним поворотів подій. Коли вам платять за людино-години, всебічний розгляд завдання і пошук підводних каменів не завжди є первинним пріоритетом, набагато вигідніше перший варіант. Якщо ж у вас є обмеження по часу і ресурсам, бачення цілої картини з самого початку, а потім і відстеження змін щодо первинної картини стає критичним для обох сторін контракту. У цьому випадку не тільки аналітику, а й решті команді, включаючи замовника, доведеться перебудовувати свою роботу, і істотно. Тому ви і ваше бізнес-керівництво повинно чітко розуміти навіщо це потрібно, і явно впроваджувати цю зміну.
Резюме
Крім історично складеної організації робіт в ІТ-компаніях і економічної ситуації, на можливість розглянути задачу в цілому діють як бажання, так і навички окремого аналітика:
- виявляти і аналізувати залучені в проект зацікавлені сторони як з боку замовника, так і з боку виконавця, враховувати їх інтереси,
- моделювати, хоча б в голові, життєвий цикл розроблюваних продуктів, як мінімум пам’ятати, що потрібно також здійснювати технічну підтримку і підтримку користувачів,
- з’ясовувати термін життя і призначення рішення, що розробляється,
- працювати з великою кількістю джерел даних і мати сміливість запитувати додаткову інформацію і задавати додаткові питання,
- виявляти і обговорювати видимі ризики,
- явно описувати обмеження: не тільки що і чому потрібно робити, але і що і чому робити не можна,
- вивчати, аналізувати і використовувати інструменти аналізу, які допомагають подивитися на ситуацію з різних точок зору, враховувати їх межі застосування: безпосередньо властиві інструменту, і накладаються контекстом роботи,
- використовувати 2-3 інструменти для вирішення будь-якої задачі – мінімально, написати пару рядків і накидати схему від руки на листку (графічному планшеті, в онлайн-додатку, вбудованому в Confluence плагіні, потрібне вписати),
- розглядати перше що прийшло в голову, або отримане від замовника, рішення в перспективі того, що може трапитися в майбутньому,
- розробляти разом з командою і пропонувати замовнику кілька альтернативних рішень на вибір, навіть якщо ви вже впевнені, що знаєте як краще,
- Розглядати тривіальне рішення – що буде, якщо нічого не робити?
Список вийшов великий, очі розбігаються, і на перший погляд незрозуміло з чого починати, і коли все це встигати. У той же час я впевнена, що більшість людей, що хоча б рік попрацювали аналітиками або в інших ролях, що вимагають щільної взаємодії з людьми, вже напрацювали значну частину цих навичок. До того ж ці пункти не просто доповнюють одне одного, але в процесі вирішення одного з цих завдань, автоматично виходить інформація для вирішення іншого.
Навіть якщо процес у вашій команді не перешкоджає повноцінній роботі аналітика, не варто намагатися впровадити всі ці навички одночасно. Як при будь-якому формуванні хороших звичок, потрібно брати їх по одному, і планомірно вводити в роботу, починаючи з однієї, найпривабливішої і необтяжливої для вас. Якщо вибрати з чого почати все ще складно, можна просто почати з кінця списку – розглянути тривіальне рішення, тобто продумати, що буде, якщо ви не упровадите рішення, що зараз розробляється.
І для того, щоб почати напрацьовувати у себе і колег новий підхід, не обов’язково чекати якогось нового великого проекту, можна застосовувати їх до будь-якої поточної задачі: запиту, на зміну, що прийшов від замовника, епіку або User Story в Jira, розробці нового макету інтерфейсу .