Всем привет!

Неоднократно сталкивался в ИТ-сообществе с мнением, что разработчикам бы работу работать, а не “вот это вот все”. Под “этим всем” скрываются видео и круглые столы от менеджмента, разъясняющие стратегию компании, полезные тренинги от HR, всякая социальная активность типа бейджиков на корпоративном портале, и конечно же, понимание сферы бизнеса - индустрии, в которой работает компания.

Максимум на что готовы многие коллеги по сфере ИТ - понятные им исследования поведения юзеров с помощью A/B или UX тестирования и прочей бигдаты (не к ночи будь помянута :)). То есть, цифры.

Вопрос в том, а можно ли качественно выполнять свою работу, не понимая, что (а точнее, кто) за этими цифрами скрывается? Какие в индустрии правила игры? Чего ждут от компании-лидера? Какие фичи стоит приоритизировать, а на какие не стоит тратить сил и времени? Почему этот коммерческий директор так настойчиво уже год пушит эту непонятную доработку???

Возможно, для джуна, выполняющего простые задачки, это и не критично, но что насчет мидлов и сеньоров? Особенно для тех, кто планирует расти в продактов и выше. Ведь никакая бигдата не сможет объяснить, почему новая фича не встретила успеха у юзеров. Чтобы видеть полную картину происходящего и развивать свои продукты в правильном направлении, нужно понимать, чем живет рынок и его обитатели.

В статье ниже буду рассказывать, как команда управления знаниями решает эту задачу, и почему это вообще лежит в зоне ответственности knowledge management.

Сразу скажу, что все написанное ниже одинаково применимо к абсолютно любой компании, которая имеет свой штаб разработчиков, но ведет бизнес в другой сфере (банки, маркетплейсы, любые другие услуги). Но раз уж Exness работает в индустрии финансов, мои примеры будут касаться именно этого рынка. Ваше исполнение тех же подходов будет строиться на вашей сфере бизнеса и предпочтениях клиентов в ней.

Как и зачем мы даем базовое понимание индустрии

Понимание рынка, в котором работает компания, позволяет продактам развивать свои продукты с учетом всех трендов, понимая, что ждет клиент от продукта, и что в нынешней инкарнации продукта клиентов может не устраивать.

Мы пользуемся разными способами познакомить сотрудников с индустрией, в которой работает компания: финансовыми услугами, рынками, психологией наших клиентов. 

С самого первого дня в компании для 100% сотрудников (да-да, для офис-администраторов и бухгалтеров тоже :)) проводится онбординговый тренинг, посвященный основам трейдинга, продуктам компании (как технологическим, так и финансовым), наравне со знаниями о компании, ее стратегии, организации, культуре и ценностях. 

Это не просто формальность для галочки - по итогам онбординга, все новички проходят экзамен по изученному материалу. 

Это не одноразовая акция. Экзамен повторяется каждый год. Поэтому все сотрудники в достаточной степени знают наши продукты, бизнес и сферу деятельности компании в любой момент времени. 

Зачем это нужно суппорту и продажам, всем понятно (понятно ведь?). Но зачем это нужно разработке, если разработчики не разговаривают с клиентами напрямую? 

Все очень просто, разработчики общаются с людьми внутри компании. Достаточно часто эти люди являются заказчиками от бизнеса, представителями отделов продаж, маркетинга, поддержки, которые могут спрашивать как работают наши продукты, можно ли реализовать ту или иную фичу, почему происходит та или иная ошибка? Ответить им комментом из кода не получится - наши собеседники обычно опыта в разработке не имеют. Им нельзя просто сказать, что if (p_coefficient_k == 3) {this.txtResult.Text = MyDialog.textBox1.Text; <...>}. Они не поймут. Им нужно объяснить словами. Причем, желательно, теми же, которыми пользуются участники рынка.

С другой стороны эти же люди: внутренние заказчики, поставщики бизнес-требований, коммерческий менеджмент - ставят разработке задачи. Как этих людей можно понять, если ты не разбираешься в индустрии? Ведь они присылают пожелания к продукту, обосновывая их назначение и важность на своем, коммерческом языке. Нужно быть, как минимум, в курсе основ индустрии, чтобы отвечать на вопросы “зачем?” и “как?” для каждой запрошенной доработки.

А если совсем хорошо разобраться в индустрии, можно и вовсе начать предлагать бизнесу новые фичи, которые потенциально могут взлететь. По моему опыту, человек, обладающий техническим образом мышления и, в то же время, пониманием рынка, на котором оперирует компания, может инициировать очень профитные идеи и реализовывать их так, как ожидают будущие юзеры. И тогда разработка превращается в полноправного участника процесса развития продукта, а не просто в исполнителя, пишущего код и читающего цифры в отчете об A/B тесте.

Личный опыт или "курсы программирования"?

Понятно, что для такого верхнеуровнево понимать индустрию мало. Мало почитать книжки про трейдинг, чтобы разбираться в ожиданиях трейдеров от продуктов. Мало сходить на курсы по маркетингу, чтобы разбираться в рынке онлайн-рекламы. Точно так же, кстати, как мало закончить рандомный курс по Python, чтобы сразу же стать кодером уровня “бог” и грести бабло руководить разработкой в серьезной компании. Нужно еще и знать, чем живут клиенты, пользователи разрабатываемых продуктов. 

Есть много способов выяснить, что нравится, и что не нравится в твоих продуктах клиенту. Можно проводить UX-тестирования, можно анализировать поведение клиента внутри продукта с помощью различных средств сбора аналитики, но собственный опыт пользования не заменит ничто. 

Это все равно что писать научные работы о психологии поведения человека в экстремальных условиях, например, ни разу не сходив в банальный поход в лес с ночевкой. Или исследовать по научным работам поведение пользователей соцсетей, при этом не имея аккаунта ни в одной из них. Можно аналитически сопоставлять факты и цифры из сотен источников, но практическое применение таких исследований будет под вопросом.

Только самостоятельно побывав на месте клиента, можно почувствовать его ощущения от того, как быстро (или медленно) срабатывает кнопка, насколько удобно (или нет) расположено меню в личном кабинете, и какого отчета не хватает в приложении, чтобы принимать правильные решения. 

Мало знать индустрию в теории - нужно быть частью индустрии.

Я могу уверенно об этом говорить, потому что тоже прошел весь этот путь - от онбордингового тренинга до проведения собственных семинаров. Я пришел в компанию с нулевым пониманием финансовой сферы (после 8 лет в сфере информационной безопасности). Как менеджер по управлению знаниями, я должен был общаться со всеми подразделениями компании, добывать информацию у одних, объяснять ее другим. И могу сказать, что этот процесс не был гладким до тех пор, пока я не получил свой собственный опыт пользования нашими продуктами. 

Также я могу сказать, что получить качественный, осмысленный собственный опыт без прохождения базового обучения невозможно. Когда ты приходишь из другой индустрии, пользование новым продуктом для тебя становится просто тыканьем в кнопки и гаданием. Независимо от наличия прошлого опыта в разработке и технического образования. И только понимая, как рынок твоей компании устроен изнутри, можно принимать решения, имеющие под собой аргументацию хотя бы немного похожую на клиентскую. Для развития продукта, в том числе.

Пара слов про мокасины

Я думаю, многим известен метод “Один день в чужих мокасинах” (возможен другой перевод, но мокасины в нем обычно присутствуют :)). Он заключается в том, что ты ходишь за человеком след в след и выполняешь все те действия, которые ежедневно выполняет он, чтобы понять, в чем заключается его работа и что в ней можно улучшить. Метод очень действенный, потому что ты начинаешь чувствовать то же, что чувствует наблюдаемый, а не просто рассуждать о его впечатлениях в теории.

Конечно, походить за нашими клиентами у сотрудников возможности нет (даже без учета пандемии и социальной дистанции). Так почему бы не дать сотрудникам возможность самим побыть нашими клиентами.

Для этого мы (команда управления знаниями) проводим различные активности. Например, даем всем посоревноваться в трейдинге. Каждый сотрудник может в течение 1-2 недель торговать на виртуальных средствах, пользуясь нашими собственными продуктами. То есть, жать на те же кнопки, использовать те же фичи, получать те же эмоции, наблюдая за изменением цен. 

Возвращаемся к тезису, что разработчику бы код кодить, а не вот это вот все. Участие в конкурсах - дело сугубо добровольное. Насильно никто никого не заставляет, бонуса не лишает, карму не минусует. И тем не менее, процент участвующих представителей разработки стабильно высок. В чем же профит?

По итогам этого опыта, собирается огромное количество обратной связи от сотрудников компании, которые поставили себя на место клиента и столкнулись со всеми теми же условиями, которые мы предоставляем пользователям наших приложений. Участники обсуждают происходящее, делятся своими историями. Не нужно набирать фокус-группы и сидеть над тестерами с блокнотом. Все уже здесь, в корпоративной сети. Можно заметить интересную историю, которая натолкнула на идею для улучшения продукта, и подойти к ее автору на кухне, поболтать, выяснить детали. 

А можно самому столкнуться с неудобством, вспомнить, что однажды кто-то из коммерческого департамента говорил об этом, но в тот момент вы (на основе своих теоретических представлений о хорошем) решили, что не так уж это и неудобно. Но от собственного опыта же вы уже не сможете так легко отмахнуться :) 

Согласитесь, это очень действенный метод познания клиентского опыта, который не сравнится ни с какой бигдатой и прочими цифровыми средствами аналитики.

Кстати, на прошлых рабочих местах я довольно часто слышал от разработчиков, что они не понимают, какова их личная роль в бизнесе компании (да-да, этот вопрос их действительно интересует!). Участие в подобных активностях позволяет получить ответ на этот вопрос. 

Разумеется, победители получают брендированные призы - это конкурс все-таки! А компания при этом получает неоценимый опыт, и может дальше развивать свои продукты, принимая в расчет также и личные ощущения от пользования продуктами в боевых условиях.

Почему этим занимаются специалисты по управлению знаниями

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

Разложим определение знаний на составляющие в примере с внутренними торговыми конкурсами:

• Имеющаяся информация = онбординговый тренинг, на котором получены базовые знания о трейдинге, а также (возможно) прочитанные книги, статьи и блоги.

• Условия = торговля с помощью разработанных “своими руками” продуктов.

• Задача = победить в конкурсе.

• Результат - опыт (независимо от места в итоговой таблице).

Сотрудники получают опыт (= знания) через подобные инициативы, а значит, задача команды управления знаниями выполнена. 

Какой от этого выхлоп для компании и для бизнеса? 

• Все сотрудники понимают друг друга и говорят на одном языке, что сокращает время на коммуникации с коллегами и принятие решений.

• Решения принимаются с учетом собственного реального опыта.

• Всегда можно прийти ногами к коллеге, оставившему фидбек, и посмотреть, как это выглядит на его компьютере, уточнить пожелания и т.д. Все это довольно затруднительно сделать с обычным клиентом (Я не подписывался быть вашим бета-тестером! (с)) или с бигдатой, которая вообще просто цифры, и может только подтвердить или опровергнуть гипотезу.

• Бизнес-требования становятся понятнее, а причины запрошенных доработок и их важность не нужно разжевывать и объяснять на пальцах. 

Все это вместе уменьшает time-to-market, сокращает риски ошибок, связанных с непониманием причины доработок (зачем это делается, и что конкретно ожидается на выходе) и неверной приоритезацией задач, и просто улучшает коммуникации между бизнесом, разработкой и client-facing командами.

В общем, не стоит пренебрегать возможностью погрузиться в рынок, на котором оперирует твой работодатель. Трава становится зеленее, если ты не просто пишешь продукт, но и знаешь, как он на самом деле используется, не из аналитических исследований, а из собственного опыта. А в случае Exness, это еще и помогает сотрудникам лучше управлять личными финансами, что тоже немаловажно :)