Автор: Мария Соцкова, Senior BA в EPAM

Привет! Меня зовут Мария Соцкова — я уже больше года работаю на позиции Senior BA в EPAM. Я вошла в айти в 2014 году сначала как специалист поддержки в одной продуктовой компании в Херсоне. Хотя изначально я никогда не хотела работать с людьми так тесно. Выпускаясь из академии НБУ в 2012, мысль попасть во фронт-офис в банке вселяла в меня ужас, потому что общение с людьми меня утомляет. Поэтому я “спокойно” провела 2 года в бек-офисе одного из крупнейших коммерческих банков Украины. Перейти в поддержку, где нужно очень много общаться со злыми и не очень пользователями IT продукта, было для меня большим стрессом и большим ростом. Удивительно, но когда я научилась общаться с пользователями, мне даже понравилось. Постепенно я как-то пронялась идеей сделать продукт лучше, опираясь на ежедневный фидбек от юзеров. Я бомбардировала R&D отдел просьбами от пользователей. Постепенно у меня вырос большой беклог фич, о которых просили пользователи. Через какое-то время я попала в тот самый R&D отдел компании и встретилась с ситуацией, когда я начала проектировать эти же самые фичи. Я научилась изучать конкурентов, прототипировать интерфейс и писать документацию. У проектировщиков не было какого-то единого стандарта ведения документации, поэтому мне пришлось самой вырабатывать свой стандарт описания задач для разработчиков. Я факапила очень много, много стыдилась своих ошибок и, как ни странно, постепенно росла на них.

Мария Соцкова

И я бы никогда не ушла из той продуктовой компании, если бы передо мной не встал вопрос переезда в Киев. Я приняла решение попробовать поработать в аутсорсе. Уже не помню, что мною двигало. Возмножно, мысль о том, что в аутсорсе жизнь протекает динамичнее, чем в продуктовых компаниях. Мне казалось, что в динамичном и хаотичном аутсорсе я вырасту как бизнес аналитик куда быстрее. Так я пришла в аутсорс. Я хотела попасть в компанию, где у меня будет ментор, но сложилось по-другому. Я была единственным БА в компании и стала сама себе ментором. И я лажала, много….я не знала как писать SRS, читала Вигерса…читала в метро ВАВОК и пыталась сама что-то делать. Бывали моменты, когда я по часу писала одну страницу документации, потому что много сомневалась и по сто раз переписывала, или не знала что писать.

После этого прошло время: я поработала еще в одной компании, открыла для себя БА-конференции и курсы, написала сотни страниц различной документации (юз кейсов и юзер сторей), рисовала десятки диаграм, открыла для себя БА коммьюнити и попала в самую крупную айти компанию Украины. Сегодня я работаю на продуктовом проекте внутри аутсорса, связанном с People Domain и являюсь ментором в виртуальном офисе Veteranius — это благотворительная инициатива, которая помогает ветеранам АТО обучиться IT-шной профессии. Работа с менти вдохновила меня на написание этой статьи. Навреное, впервые я осознала, что уже что-то знаю и могу поделиться этим с другими. Надюсь, то, что вы прочтете, будет вам полезно, ну или хотя бы, нескучно ;)

Requirements elicitation

Выявление требований — отвтественный этап. От него во многом зависит качество поставленных задач команде разработки. In a nutshell, процесс происходит так: вы планируете, как вы будете выявлять требования, выявляете их, а потом перепроверяете то, что выявили.

Plan elicitation

Раньше я никак особо не занималась планированием выявления требований, а зря. Последствием отсутсвия плана стали “дырки” в требованиях, которые выявлялись уже на этапах дизайна требований (написания документации и создания прототипов). Небольшой спойлер: на сегодняшний день я использую так называемый Definition of Ready-чеклист как ориентир, который мне показывает, что должно быть выявлено. Definition of Ready для команды является мерилом того, готова задача к тому, чтобы ее можно было брать в разработку или нет. Для меня же — это чеклист всего того, что я должна выявить и в чем должна убедиться, прежде чем отдам задачу на оценку девелоперам. В моем идеальном мире, Definition of Ready — это не пылящийся на Confluence документ, а рабочий чеклист, который я использую каждый раз как занимаюсь выявлением требований. На текущем проекте у меня есть два списка Definition of Ready для двух разных типов задач. Они сформировались эмпирически, когда я начала вести списки того, что обязательно нужно выявить, прежде чем садиться за описание результатов выявления требований (в моем варианте — это черновик User story с Acceptance Criteria).

Вообще, в BABOK рекомендуют составлять Elicitation Activity Plan, что я всегда делала интуитивно, но никогда так официально не называла. В самом начале этот план больше выглядел как хаотичные записи в блокноте в виде вопросов и ту-ду пунктов. И это нормально на начальном этапе проекта, когда у членов команды только формируется единое видение на то, каким мы хотим видеть проект и что мы будем для этого делать.

Conduct elicitation

Чаще всего для меня подготовка к выявлению требований и само выявление шли рука обруку:

1. Brainstorming + Interviews

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

1. Interviews + Data mining

Чтобы понять, к каким источникам данных должен подключаться наш сервис, я сначала выходила на человека, который мог бы мне помочь разобраться, где вообще искать данные. Проводила с ним интервью, узнавала, где могут находиться необходимые мне данные. Затем я подключалась к БД и изучала данные более детально, чтобы понять, подойдут ли они нам.

Confirm elicitation results

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

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

UI/UX Prototyping

Я знаю ребят, которые не любят прототипировать, но для меня это просто незаменимое умение. Показать на картинке, а еще лучше — на интерактивном прототипе — куда более четкое донесение мысли. Здесь просто нет шансов понять это как-то по другому, ведь у всех перед глазами один прототип.

А еще в прототипировании хорошо то, что делать их довольно быстро и дешево, и их можно тестировать на пользователях до того, как дело дошло до разработки. На этапе тестирования прототипа можно выявить критичные “баги” в логике или в UI.

A success story with prototyping

Когда у нас в команде уже вырисовалось понимание того, что, по нашему мнению, должно быть в нотификации для пользователя, мы не понимали, верны ли наши догадки. Побрейнштормив, мы решили сделать прототип интерфейса нашего продукта с настоящим UX-текстом и протестировать его на конечных потребителях. Мы организовали около десятка мини-интервью, где показывали прототип и просили у пользователей фидбек. Результаты интервью нас удивили: пользователи “разгромили” наш прототип. Был и плюс: мы получили ценную информацию о том, что люди действительно ожидают увидеть и как они хотят это видеть.Мы переделали прототип и прогнали его через второй круг интервью. Прототип уже был встречен пользователями теплее, но все равно требовал много доработок. И мы сделали еще один прототип и снова опросили людей. Нашу третью версию практически все опрошенные встретили с одобрением, а некоторые даже с восторгом.Так мы определились с внешним видом и наполнением продукта.

An unsuccess story with prototyping

В одном из моих первых проектов “from scratch” передо мной стояла задача сделать wireframe. Я работала над мобильным приложением и так хотела сделать все хорошо, что слишком увлеклась. Я взялась делать интерактивный прототип всего, описанного в документации функционала мобильного приложения, в Axure. Я потратила неделю на то, чтобы сделать прототип. Он был довольно детализированным, цветным и…похожим на плохонький дизайн, а не на макет. Когда клиенту презентовали мою работу, то он принял макет за дизайн и был разочарован. Клиент не подписал с нами контракт на разработку. С того момента меня попросили не делать high-fidelity прототипы и не использовать цвет на макетах, рекомендуя пользоваться 50ю оттенками серого, чтобы дать клиентам понять, что БА-прототип — это “костяк”, а не финальный дизайн.

Документация и другие артефакты

Когда-то я работала на полставки и у меня было два проекта. Я не успевала писать документацию по одному из проектов и мне дали в помощь тестировщика. В первый день, после того, как утром я объяснила ему, как обычно я пишу SRS, после обеда увидела его в каком-то удрученном настроении. Подошла, спросила, как дела. Ответ последовал: “Я не розумію, як ти це робиш. Я дві години думав, а написав всього півсторінки”.

Громоздкая документация

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

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

Документация с привязкой к UI

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

Слишком краткая документация

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

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

Mind your audience

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

Работа в команде

We’re all humans. И хоть мы и формируем проектную команду — каждый из нас индивидуален как человек. Мне кажется, очень многое на проекте зависит от того, какая психологическая атмосфера сложилась в команде. Я считаю, что отношения в команде должны быть построены на уважении и честности. Ведь очевидно, что если между участниками напряженные отношения, скрытые конфликты, а воздух заряжен пассивной агрессией, то вряд ли такая команда эффективна.

Эскалируйте

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

Если бы такая ситуация повторилась сегодня, то я бы эскалировала Head of PMO и CTO, так как не обязана решать разногласия между ними. Но на тот момент, у нас в компании просто таких должностей не было, и мне пришлось как-то самой с этим разбираться. Я выслушала обе стороны и попыталась донести до ПМа консерны разработчика по поводу задачи, но тот даже слушать не хотел. Помирить их так и не получилось, поэтому я на какое-то время стала прослойкой между ними, и как ни увительно, но разработчик закрыл задачу и конфликт иссяк.

Не берите на себя больше, чем можете потянуть

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

Когда-то мне пришлось несколько месяцев совмещать обязанности PM/BA. Я даже сделала н мем в честь этого периода своей жизни:

Я продолжала делать БА работу, которой было достаточно много на проекте и еле успевала контролировать договоренности с клиентами. Точнее не успевала совсем, поэтому спустя неделю-другую, чтобы проект не прогорел, обязанности ПМа забрал на себя наш СЕО. Если бы этого не случилось, то я выгорела бы вместе с проектом.

Отделяйте работу от вашей личной жизни

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

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

У меня был случай, когда я, будучи юным миддлом, пришла работать в компанию, где в то время Head of PMO выстраивал процесс работы над Inception фазой. Между мной и дизайнером вспыхнул конфликт интересов, который я не сразу осознала. Дизайнеру было скучно сидеть без работы, пока не зашли новые проекты. А мы как раз утверждали то, что во время Inception фазы БА делает макеты. Таким обрзом, я забрала тот единственный кусок работы, который мог тогда достатьсяскучающему дизайнеру. Между нами было много напряжения. Отношения не ладились. Когда же руководитель PMO заметил, что явно что-то не то происходит между мной и дизайнером, то он собрал совещание, на котором вынес на обсуждение этот самый вопрос с макетом. Обсуждение было построено максимально демократично: каждого, кто относился к PMO, просили высказать свое мнение. Однако, когда дошла очередь до дизайнера, вместо того, чтобы прямо высказать, что он думает, он ответил: “мне добавить нечего”. Конфликт так и не был разрешен. Уже после того, как дизайнер ушел из компании, я узнала, что он хотел стать БА и что он чувствовал со мной большую конкуренцию. Навык открыто говорить о том, что тебя что-то не устраивает, довольно ценный в таких ситуациях. Жаль, что далеко не все хотят его развивать.

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