По той бік огорожі: бізнес-аналітик про роботу в ролі продакт-оунера

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

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

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

З чого все почалося

Трохи про компанії, в якій я працював. Це був величезний вертикально інтегрований металургійний холдинг з численними підрозділами, складною економікою, мільярдними доходами та майже 80 тисяч співробітників по всьому світу — типовий ентерпрайз.

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

Історія почалася з того, що у мого керівника відкрився третє око, за допомогою якого він побачив образ того, що неодмінно зробить роботу нашої компанії більш ефективною, а життя її генерального директора — легкої, як вересневий вітерець. Цей образ з'явився керівнику у вигляді якогось «інструменту» (так він його назвав), який повинен був, по-перше, показувати, в якому стані знаходиться бізнес; по-друге, вміти відслідковувати всі KPI; в-третіх — давати можливість «провалюватися» в будь-які цифри і витягувати з ним деталі, тобто мати функцію drill down (хоча ми тоді ще не знали, що це так називається).

Мені було доручено вивчити кращі практики на ринку і знайти такий інструмент. Я взявся за цю задачу з властивим мені на той момент завзяттям (тобто не поспішаючи) і з'ясував, що нам потрібна Business Intelligence. Ми вивчили існуючі в той час рішення (Tableau, Dundas, Power BI, щось ще), і нам все шалено сподобалося. Не сподобалася тільки ціна. Прямо сильно не сподобалася.

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

Ми не стали впадати у відчай і вирішили знайти субпідрядника, який спеціалізується на подібних рішеннях і зробить для нас «Табло».

З'являється IT-компанія

В цьому місці розповіді на сцену виходить молода, динамічна IT-компанія, назву якої я не розголошуватиму з етичних міркувань. У її портфоліо значилося близько 500 успішних проектів в області рішень для бізнесу.

Ми зустрілися з представниками компанії, позначили свої побажання, показали приклади продуктів, які нам подобаються, і уклали контракт. Нас запевнили, що все зрозуміли і все зроблять як треба. Я був призначений представником бізнесу і головною контактною особою. Так я, сам того не відаючи, став продакт-оунером.

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

До слова сказати, IT-компанія пропонувала нам і діскавері-фазу, і онсайт, і користувальницькі інтерв'ю. Ми відмовилися. Тому що, по-перше, це довго і дорого, по-друге, конфіденційність і безпеку ніхто не відміняв (нічого у нас по заводу шастати!), ну і, по-третє, ми все розповімо самі, не треба вам з цими користувачами говорити.

Пару слів про обмеження

Вони є в будь-якому проекті. У нашому випадку ми були обмежені технологією, а саме SharePoint. Причина була теж дуже типовою для ентерпрайза. SharePoint хтось колись купив без конкретної мети; швидше за все, у покупця був неосвоєний бюджету, а у продавця — якась акція на кшталт «3 за ціною 1» або «кожному третьому покупцеві — SharePoint в подарунок». Як би там не було, SharePoint у нас був, і його треба було якось використати.

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

Поні бігає по колу

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

Це невеликий, але дуже показовий приклад. Читачі, зрозумійте, у бізнесу немає ні можливості, ні бажання розбиратися в тому, що таке структуровані або неструктуровані дані. Також бізнесу незрозуміло, чому не можна просто взяти «эксельку», де є формули, і запрограмувати, щоб працювало за формулами, як в «эксельке», тільки краще.

У нас було ще кілька зустрічей, де ми обговорювали одне і те ж. Я зрозумів, у чому була проблема: аналітик IT-компанії банально не розумів того, що я кажу, бо не знав мови, на якому я розмовляю. Це ще один показовий приклад. Справа в тому, що люди, які довгий час працюють в конкретному бізнесі і звикають використовувати певну термінологію і жаргонізми, щиро вважають, що всі навколо розмовляють точно так само. Виявилося, що аналітик не надто розумів, що таке робочий капітал або фрі кеш-флоу. Коли я став розжовувати кожен термін і пояснювати його значення, справа нарешті пішла швидше. Мені пояснили, що таке структуровані дані. Я видав хлопцям потрібну табличку, звичайно ж, заповнивши її не реальними даними, а якимось сміттям, тому що конфіденційність, безпеку, всі справи. Це мені потім ще гукнулося.

Перше демо

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

Щось пішло не так

Мені прислали на затвердження специфікацію, сторінок 30-40 убористого тексту. Я вже згадував, що працював у той час досить багато і мав купу паралельно йдуть складних завдань. На цей проект я міг виділяти не більше 10% свого часу, і, по правді кажучи, мені не дуже хотілося читати документ. Тому просто переглянув ключові, як мені здавалося, місця, де були формули, і завізував специфікацію.

Це ще один маленький, але дуже показовий приклад. Дорогі читачі, продакт-оунеры далеко не завжди уважно читають ті вимоги, які ви надсилаєте на погодження.

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

У підсумку

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

Здавалося б, повна катастрофа! Але за фактом ніхто сильно не засмутився. Так, були витрачені зусилля і гроші, але ці гроші були в межах допустимого бюджету. Самі по собі витрати в звітності величезного холдингу були такими незначними, що при будь-якому drill down'е навряд чи вийшли б за межі рядка «інші витрати». Нікого не покарали і не звільнили.

Читачі, саме таким чином на теренах энтерпрайзов народжуються і гинуть сотні внутрішніх продуктів. І це нормально. Це життя.

Отримані уроки

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

Вивчайте бізнес клієнта

Докладне вивчення бізнесу клієнта допоможе аналітику бути в темі і краще розуміти замовника, що економить час обом. Далеко не кожен буде відкрито ділитися інформацією про свій бізнес, але це не безвихідь. Сайти crunchbase.com або owler.com допоможуть вам отримати верхнеуровневую інформацію про компанію-клієнта, її доходи, останніх інвестиції, злиття і поглинання.

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

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

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

Створюйте глосарій

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

Управляйте очікуваннями

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

Навчайте клієнта

Клієнт не зобов'язаний нічого знати про особливості SDLC та інших нюансах розробки. Важливо поступово і ненав'язливо знайомити його з основними кроками і фазами ваших процесів. Тут все залежить від готовності клієнта сприймати цю інформацію. Гарним приводом розповісти про процеси та ролі в проекті є kick-off-зустріч. Важливо не просто сказати: «Це Петя, він бізнес-аналітик. А ось це Вася, він проектний менеджер». Розкажіть, хто такий аналітик, чим і навіщо він буде займатися, за що відповідає і яка від нього користь проекту. Також не заважає згадати, які умови необхідні для того, щоб користь була максимальною. Наприклад, доступність ключових стейкхолдерів, формат комунікації, можливість ознайомитися з інтерфейсом поточної системи (якщо вона існує), вивчити і описати поточні процеси в компанії і т. д.

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

Пропонуйте рішення

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

Припустимо, клієнт просить вас зробити йому «свій внутрішній скайп», тому що звичайний «Скайп» не є достатньо безпечним. Можна відразу приступити до аналізу продукту, декомпозировать функціональність, зафіксувати ключові вимоги щодо безпеки і почати робити свій скайп». Але якщо задатися питаннями, навіщо «Скайп» потрібен клієнту і як він його використовує, можна з'ясувати, що в 99% випадків з допомогою цієї програми працівники будуть передавати один одному файли і спільно над ними працювати, обговорюючи правки по телефону. Тоді навіщо потрібна репліка «Скайпу»? Зробіть секьюрный аналог Google Docs з можливістю паралельної роботи! Це рішення буде набагато більше відповідати потребам бізнесу. Але клієнт може не знати про Google Docs, що йому відомо тільки про «Скайпі», тому про нього і говорить. Ваше бачення ширше: ви можете запропонувати найкраще рішення і зробити клієнта щасливим. Щасливий клієнт повернеться до вас ще не раз з новими цікавими завданнями.

Висновок

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

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

Завдання бізнесу, як він її розуміє, — заплатити гроші і отримати результат. І бізнес очікує від нас, аналітиків, як від професіоналів своєї справи, максимальної віддачі і відповідальності за результат.

Здоров'я нам!

Ілюстрація Уляни Патоки

Опубліковано: 21/04/20 @ 10:00
Розділ Різне

SEO Блог