По ту сторону изгороди: бизнес-аналитик о работе в роли продакт-оунера
Меня зовут Кирилл, я работаю бизнес-аналитиком и сервис-менеджером в офисе бизнес-анализа в 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-компанию. Мол, вон у нас тысячи сотрудников ходят «заменеджеренные», и что, мы с этими не справимся? Мы постоянно задавали вопросы вроде «ну это же не финальная версия, да?», «дизайн же станет лучше, да?», «у нас же еще будет приемочное тестирование, да?». На что непременно получали утвердительный ответ.
Что-то пошло не так
Мне прислали на утверждение спецификацию, страниц
Это еще один маленький, но очень показательный пример. Дорогие читатели, продакт-оунеры далеко не всегда внимательно читают те требования, которые вы им высылаете на согласование.
Пришло время приемочного тестирования. Продукт впервые был проверен на реальных данных, а не на тех выдуманных, которые использовались при разработке. И здесь стало понятно, что эта штука помимо того, что выглядит ужасно, еще и считает неправильно. Это был полный провал. Дальше предстояли долгие месяцы доработок.
В итоге
Проект занял в два раза больше времени, чем изначально планировалось. Дизайн лучше не стал. Пользоваться продуктом никто не хотел. Генеральный директор, наш главный стейкхолдер (тот, чья жизнь должна была стать легкой, как сентябрьский ветерок) о продукте даже не узнал.
Казалось бы, полная катастрофа! Но по факту никто сильно не расстроился. Да, были потрачены усилия и деньги, но эти деньги были в пределах допустимого бюджета. Сами по себе расходы в отчетности огромного холдинга были такими незначительными, что при любом drill down’е вряд ли вышли бы за пределы строчки «прочие расходы». Никого не наказали и не уволили.
Читатели, именно таким образом на просторах энтерпрайзов рождаются и гибнут сотни внутренних продуктов. И это нормально. Это жизнь.
Полученные уроки
Оглядываясь на эту ситуацию с вершин сегодняшнего опыта, хочу дать несколько советов тому аналитику, который работал со мной на проекте. А вместе с ним и вам.
Изучайте бизнес клиента
Подробное исследование бизнеса клиента поможет аналитику быть в теме и лучше понимать заказчика, что экономит время обоим. Далеко не каждый будет открыто делиться информацией о своем бизнесе, но это не тупик. Сайты crunchbase.com или owler.com помогут вам получить верхнеуровневую информацию о компании-клиенте, ее доходах, последних инвестициях, слияниях и поглощениях.
Чтобы углубиться, можно покопаться в статьях и пресс-релизах компании. Если предприятие достаточно большое и имеет форму акционерного общества, то на корпоративном сайте часто публикуются финансовые отчеты и стратегические планы — это отличный источник. Почитайте отзывы сотрудников на таких сайтах, как, например, glassdoor.com. Эта информация поможет вам понять культуру компании, а также обнаружить какие-то внутренние проблемы и боли, о которых клиент решит вам не рассказывать.
Обратите внимание и на аналогичные компании в индустрии, изучите, как они работают, как устроен их бизнес. Не стоит пренебрегать консультацией коллег: возможно, у кого-то из ваших знакомых был опыт работы с подобной компанией, а это еще один отличный источник инсайдерской информации.
Что таким образом можно узнать? В первую очередь — бизнес-модель: как компания зарабатывает, как приносит пользу своим клиентам, как создает ценность. Дальше исследуем структуру бизнеса: сколько в нем работает сотрудников, какое место в общей структуре компании занимает департамент, для которого вы проектируете решение, были ли в последнее время какие-то крупные инвестиции. Так можно понять стратегию компании, увидеть, в каком направлении она собирается развиваться. В целом любая информация может пригодиться в зависимости от аспектов вашего проекта, но вышеперечисленное — основа, которая будет полезна в любом случае.
Создавайте глоссарий
Словарь основных терминов и их значений сделает встречи более продуктивными и поможет избежать недоразумений в требованиях. Это несложно: как только вам попадается незнакомый термин либо термин, который может иметь несколько значений, записывайте его и просите клиента пояснить значение. Такой подход может быть не всегда уместным в контексте ваших встреч, тогда есть смысл записать все слова, подыскать им определения и на одной из встреч попросить уделить десять минут, чтобы пройтись по глоссарию и утвердить его с представителями бизнеса. Поясните, для чего это нужно и каких трудностей поможет избежать, — вам не откажут.
Управляйте ожиданиями
Важно помнить, что, если бизнес платит деньги и не получает того, что ожидает, виноватыми всегда будете вы, а бизнес может потребовать деньги обратно. Учитесь понимать, что важно для клиента. В нашей организации много внимания уделялось оформлению, мы тратили часы, выверяя положение графиков и цвета. Попросите клиентов расставить приоритеты ключевых принципов, таких как дизайн, точность расчетов, скорость работы, юзабильность, безопасность и т. д. В нашем случае дизайн занимал бы одно из первых мест. Подрядчику, который понимает, что важно для клиента, проще управлять ожиданиями и правильно расставлять акценты при презентации сырых версий продукта.
Обучайте клиента
Клиент не обязан ничего знать об особенностях SDLC и прочих нюансах разработки. Важно постепенно и ненавязчиво знакомить его с основными шагами и фазами ваших процессов. Здесь все зависит от готовности клиента воспринимать эту информацию. Хорошим поводом рассказать о процессах и ролях в проекте является kick-off-встреча. Важно не просто произнести: «Это Петя, он бизнес-аналитик. А вот это Вася, он проектный менеджер». Расскажите, кто такой аналитик, чем и зачем он будет заниматься, за что отвечает и какова от него польза проекту. Также не мешает упомянуть, какие условия необходимы для того, чтобы польза была максимальной. Например, доступность ключевых стейкхолдеров, формат коммуникации, возможность ознакомиться с интерфейсом текущей системы (если она существует), изучить и описать текущие процессы в компании и т. д.
Аналитики, если вас никто не представил, сделайте это сами. Расскажите каждому стейкхолдеру со стороны заказчика, кто вы и зачем нужны проекту: это важно для успеха вашей работы.
Предлагайте решения
Чаще всего в нашей практике клиент приходит с готовым решением, которое «осталось только реализовать». Мой опыт показывает, что в большинстве случаев «готовое решение» клиента не является таковым и не решает его проблем. Чаще всего энтерпрайз-клиент не знает, как создавать софт (несмотря на то, что сам он может думать иначе). И его «решение» — на самом деле просто попытка объяснить свою проблему языком, который, как ему кажется, вы поймете. На первых порах вашей работы с клиентом не концентрируйтесь на реализации решения. Разбирайтесь, почему клиент придумал именно такое решение. Не «как» и «что», а «почему». Не стесняйтесь предлагать решения, если видите в них ценность для бизнеса клиента: это ваша работа.
Допустим, клиент просит вас сделать ему «свой внутренний скайп», потому что обычный «Скайп» не является достаточно безопасным. Можно сразу приступить к анализу продукта, декомпозировать функциональность, зафиксировать ключевые требования по безопасности и начать делать «свой скайп». Но если задаться вопросами, зачем «Скайп» нужен клиенту и как он его использует, можно выяснить, что в 99% случаев с помощью этой программы сотрудники будут передавать друг другу файлы и совместно над ними работать, обсуждая правки по телефону. Тогда зачем нужна реплика «Скайпа»? Сделайте секьюрный аналог Google Docs с возможностью параллельной работы! Это решение будет гораздо больше соответствовать потребностям бизнеса. Но клиент может не знать о Google Docs, ему известно только о «Скайпе», поэтому о нем и говорит. Ваше видение шире: вы можете предложить лучшее решение и сделать клиента счастливым. Счастливый клиент вернется к вам еще не раз с новыми интересными задачами.
Заключение
В заключение позволю себе задать риторический вопрос: что же должен был сделать продакт-оунер в той истории, чтобы проект был более успешным? Мой ответ: ничего.
Я понимаю, что для большинства читателей это не очень комфортная мысль, и подчеркиваю, что это утверждение будет верным именно в случаях с энтерпрайзом. Для сотрудников в энтерпрайзе курирование одного или нескольких проектов может быть далеко не основной их деятельностью, да и в целом энтерпрайз не стремится разбираться в том, как работает это ваше IT, какие там процессы, что там можно и чего нельзя.
Задача бизнеса, как он ее понимает, — заплатить деньги и получить результат. И бизнес ожидает от нас, аналитиков, как от профессионалов своего дела, максимальной отдачи и ответственности за результат.
Здоровья нам!
Иллюстрация Уляны Патоки
