Дороф, я — Любик Кислюк, Lens production manager в Snap Inc. До Snap работал на должности COO в Robosoft industries, а также head of BA в Adtelligent. За 3 года в IT я много косячил сам и видел, как косячат другие, будучи как исполнителем, так и заказчиком. К сегодняшним советам я добавил офигительные кейсы из своей практики о том, почему так делать НЕ НАДО! Запасайтесь горячительными напитками и погнали!
Как не надо работать со стейкхолдерами и командой
Где бы вы ни работали и чем бы вы ни занимались — везде есть люди, с которыми нужно взаимодействовать, и от налаженной коммуникации с которыми зависит очень многое: продуктивность, дальнейшее сотрудничество, рейтинг вашей компании на рынке. Сейчас расскажу, как максимально быстро произвести о себе негативное впечатление в глазах всех этих людей.
1.Не согласовывайте требования с заказчиком
Вы понимаете, что хочет заказчик лучше него самого — к чему дополнительные митинги?
Чтобы заказчик сотрудничал с вашей командой максимально долго, нужно придерживаться следующей последовательности: сначала клиент вам озвучивает свою «хотелку», вы как аналитик разрабатываете бизнес-требования, обсуждаете их с командой разработки и прежде, чем брать эти требования в работу, утверждаете то, что вы разработали, с заказчиком. Некоторые пренебрегают этим простым правилом.
Я сам, бывало, грешил этим на начальных этапах, когда не хватало времени или же казалось, что я все понимаю до конца, и это именно то, чего хочет заказчик. На самом деле, важно, чтобы заказчик сам подписался под тем, что будет дальше идти в работу.
Запоминайте все на слух, верьте в свою память!
Очень хороший инструмент, который я советую своим студентам и стажерам для фиксирования требований — это диктофон. Он не раз меня спасал, причем в разных контекстах и ситуациях. Диктофон помогает решить три задачи:
- Вы ничего не упустите. Бывают такие случаи, когда стейкхолдер может быть неуловимым или говорить не совсем понятным языком, поэтому не всегда получается улавливать его мысли на лету.
- Вы не будете переспрашивать по 10 раз, если еще не успели вникнуть в терминологию и контекст нового проекта. Достаточно просто записатьна диктофон все мысли и пожелания стейкхолдера, а дальше, воспользовавшись базой знаний или помощью других специалистов, как-то расшифровать то, что он имел в виду.
- Если человек в дальнейшем начнет отказываться от своих слов, у вас будет доказательство обратного. Такое тоже иногда случается, причем не из-за того, что заказчик хочет повредничать, а из-за того, что он действительно мог забыть.
Ни разу на моей практике никто не отказывался от записи слов на диктофон, наоборот, все люди охотно соглашались. Главное — правильно подать использование этого инструмента, мотивируя тем, что записываете не для того, чтобы все, что скажет заказчик было использовано против него в суде, а чтобы ничего не упустить и разработать требования быстрее и качественнее.
Не стоит каждый раз спрашивать: «Можно ли вас записывать». Вы, как правило, будете работать в рамках компании довольно долго и достаточно всего один раз сказать: «Давайте для того, чтобы я ничего не упустил и чтобы требования были разработаны лучше, я запишу это на диктофон».
2. Храните будущую реализацию в тайне от технической команды
Ведите себя как эксперт во всех технических нюансах, а команде ставьте любые цели — вывезут. Если не справятся — надо менять команду.
Если вы планируете стать авторитетом и облегчить жизнь команде, прежде, чем утверждать бизнес-требования с заказчиком, нужно получить подтверждение команды о том, возможно ли это реализовать в принципе, и если да, то какие ресурсы для этого потребуются. Только после этого можно идти к стейкхолдеру и предоставлять реалистичный эстимейт.
Если вы сразу слышите от заказчика откровенную чушь(разработать ракету за $10) и понимаете, что это невозможно реализовать, говорите об этом уже на этапе обсуждения.
Когда вы не уверены в том, возможно реализовать запрос или нет, важно уточнить, что эти тонкости вам нужно обсудить с техническими лидом или любым другим менеджером, который руководит разработкой данного продукта.
После того, как вы утверждаете с техлидом, что это возможно сделать, можно давать ответ заказчику о том, в каком виде и в рамках какого бюджета вы готовы разрабатывать функционал.
3. Кому нужна оптимизация процесса взаимодействия с командой и заказчиком. Скучно!
Все, что объединяет команду и заказчика — вы, их верный товарищ бизнес-аналитик! Если всех перезнакомить, могут решить, что вы — лишняя менеджерская прослойка.
Взаимодействие с командой и заказчиком должно быть постоянным и непрерывным. Если заказчик внутренней и он добавлен вас ваш task tracker, то можно добавить дополнительную функцию, которая проставляет аппрув.
В моей практике на одном из проектов использовали jira и у нас был stakeholder, который хотел, чтобы без его согласия ни один ticket не проходил. Мы поставили на доске ticket, что статус ставки «need username approve». Ему каждое утро приходил список из этих ticket-ов, он их просматривал и аппрувал или деклайнил. Довольно эффективный механизм, у нас он хорошо себя проявил.
Еще один возможный вариант — это комментарий с утверждением от заказчики в документе с требованиями.
Мне удобно разрабатывать требования в гуглодоках, кто-то делает это в Confluence или Quip, вопрос вкуса. Если решите работать с гуглодоками — достаточно просто дать всем заинтересованным лицам доступ на комментирование и после того, как заказчику все нравится, он может в заголовке документа писать, что утверждает требования. Обычно этого достаточно для того, чтобы пустить их в работу.
Если вы, допустим, используете бумажную документацию, такое тоже иногда встречается, то аппрувом будет классическая подпись на бумаге. Человек подписывается под тем, что он заказывал.
Важно собирать вопросы технической команды и отвечать на них.
Один из вариантов механизма коммуникации — доступ на комментирования в разрабатываемый документ. Это также может быть какой-то регламентированный митинг, когда вы раз в неделю собираетесь для того, чтобы прогрумить те требования, которые собираетесь утверждать.
Во время разработки требований я бы рекомендовал дать доступ на комментирования хотя бы лиду, чтобы он сразу задавал вопросы о том, как вы описываете какие-то вещи, которые могут быть не до конца понятны и команде разработки. Отвечая на вопросы, они, во-первых, могут сделать какие-то предложения более оптимальные, чем те, которые вы описываете, либо сказать, возможно это реализовать или нет — словом, дать информацию, которую вы дальше будете транслировать на заказчика.
Но, как правило, митинги занимают какое-то время — это ресурсы, деньги, а глянуть одному человеку пробежаться по документу в течение 15-20 минут и сразу отсечь какие-то грубые ошибки или возможность/невозможность реализации, как мне подсказывает практика, довольно эффективно.
Собирайте фидбэк от команды о каналах коммуникации и механизмах взаимодействия.
Выслушивайте предложения и принимайте то, что может улучшить коммуникацию, ускорить процесс или снизить издержки (убрать лишний шаг из флоу, добавить или убрать какой-то митинг). Люди, на самом деле, как правило, очень охотно дают какие-то предложения и лучше отзываются в дальнейшем, если вы эти предложения слушаете, принимаете и применяете.
4.Анализируйте рынок только на этапе инициации проекта
Если постоянно анализировать рынок и конкурентов— когда работать?
Частая ошибка бизнес-аналитиков — делать конкурентный анализ на долгоиграющих проектах всего один раз, на этапе инициации. Важно анализировать конкурентов хотя бы раз в какой-то период , все зависит от домена, в котором вы работаете. Если это какой-то mobile gamedev, то конкурентный анализ нужен практически перманентно и постоянно. Если вы разрабатываете финансовые инструменты или какие-то более долгоиграющие продукты — нужно проводить анализ хотя бы раз в полгода.
Когда ребята, с которыми я работал, захотели разрабатывать один продукт в 2018 году , мы сделали конкурентный анализ, и поняли, что на рынке не хватает каких-то фич и мы порвем рынок, если зайдем с этими фичами. Потом отвлеклись на разработку других продуктов и через восемь месяцев решили вернуться к разработке этого продукта. Все тешили себя мыслью о том, что год назад ни у кого ничего не было, сейчас мы залетим на рынок и будем в шоколаде.
Я проявил инициативу, решил повторно сделать конкурентный анализ и выявил, что все эти фичи, о которых был разговор год назад, у двух конкурентов уже реализованы, в том или ином виде. Еесли бы я не сделал анализ, то несколько месяцев разработки пошли бы насмарку.
Должен ли BA заниматься конкурентным анализом, зависит от того, какова роль бизнес-аналитиков в данном проекте или продукте. Если заказчик хорош в своем домене и постоянно держит руку на пульсе, то аналитик не должен делать двойную работу. А если же заказчик, скажем, хочет что-то, но при этом не супер круто ориентируется в рынке, то аналитик должен как минимум выделить основных игроков и раз в какое-то время хотя бы просто заглядывать на их сайт, новостную ленту и следить за контентом.
Инструменты и ресурсы для анализа очень простые — конкуренты вам сами обо всем расскажут. Заходите на их блог и смотрите хронологию того, что они выкатывали и когда. Если же мы говорим о каких-то уже программных продуктах, то конкурентный анализ — это, как минимум:
- анализ трафика на сайт;
- B2C — элементарно зарегистрироваться на платформе или продукте конкурента и воспользоваться им — это уже это уже и есть бизнес-анализ;
- B2B — промышленный шпионаж. Конкурент сам все расскажет, если будет воспринимать вас как потенциального клиента.
Я сам однажды проводил B2B шпионаж, когда значительное количество времени развивал одну площадку для того, чтобы посредством нее пообщаться с конкурентами и воспользоваться их техническим решением. Это дало немало плодов. B2B сегмент сам по себе сложнее и промышленный шпионаж там серьезнее. Нужно иметь чуть ли не целый отдел или хотя бы нескольких человек, которые будут заниматься какими-то проектами, и смогут быть клиентами конкурентов.
Еще один инструмент промышленного шпионажа — поездка на выставки, где представители компаний очень много рассказывают о себе, вам достаточно просто отправить туда человека, который играет роль потенциального клиента. Конечно, не каждый конкурент вам расскажет, какие в проекте киллер фичи невесть кому, пока не подписал контракт, но, тем не менее, это тоже работает.
Как не разрабатывать требования
5. Можно наплевать на скорость в пользу качества
Перфекционизм превыше всего! Доводите до идеала требования любого запроса, даже если на это потребуется 20 лет!
Иногда «молодые» аналитики стараются разрабатывать требования очень скрупулезно не там, где это нужно и не учитывают, что рынок меняется каждую минуту.
Приведу пример из собственной практики, когда команда очень много времени потратила на разработку довольно стандартного функционала регистрации логина. Его требования растянулись на 20 страниц, где описали практически все, что можно было описать в природе, хотя, на самом деле, нужно было сконцентрироваться на ядре проекта, а этот функционал просто реализовать стандартно и по ходу следующих итераций уже его дорабатывать. Здесь важно оценить количество предоставленного времени и важности качества при разработке требований по аналогии с разработкой продукта.
6. Не приоритезируйте бэклог
Вы должны почувствовать сердцем, какая задача самая важная.
При формировании бэклога важно понимать, что он должен быть больше, чем на одну итерацию, так как могут смениться приоритеты или фича просто окажется ненужной и возникнет недогрузка команды.
Заказчик будет очень недоволен, потому что самое дорогое, что есть в IT для заказчика — это стоимость команды разработки, так что лучше старайтесь делать бэклог больше, чем на 1 спринт.
Бывают ситуации, когда очень сложно приоритизировать backlog.
Я работал над продуктом и столкнулся с ситуацией, когда заказчик говорит, что нужно срочно внедрять что-то одно, support говорит, не можем жить без чего-то другого, сейлз кричит:«Откладывай все, нам нужно продавать клиенту что-то третье!» Владелец бизнеса говорит: «Это все ерунда, давай мне делай вот это, я хочу, чтобы было как у конкурентов».
Вы сидите и понимаете, что у вас backlog на два месяца и у всех фич максимальный приоритет. В таких случаях есть очень полезная практика, которую я позаимствовал у scaled agile framework — WSJF.
WSJF (Weighted Shortest Job First) — система, которая позволяет оценить задачи по ряду факторов и собрать нумерованный список, в начале которого окажутся самые простые в реализации, но при этом и самые ценные с точки зрения бизнеса задачи.
Формула WSJF= Cost of Delay / Job size, где
Cost of Delay= (Business Value + Time Criticality + Risk Reduction or Opportunity Enablement).
А теперь покомпонентно:
- Business Value (бизнес ценность) — насколько фича будет полезна бизнесу и клиенту (чем больше, тем лучше).
- Time Criticality (временная критичность) — задачу нужно выполнять немедленно или можно подождать? Например, важно опередить конкурента (чем выше, тем лучше).
- Risk Reduction and/or Opportunity Enablement (фактор риска (или возможности)) — снижает ли данная фича риски или может, открывает возможности новых рынков?(чем выше, тем лучше).
- Job duration / size (сложность работы) — техническая сложность реализации фичи (чем меньше, тем лучше).
Если у бизнеса и команды есть время на оптимизацию рабочего процесса, идеальным способом применения WSJF будет проведение общего митинга с командой разработки и представителями клиента. Пусть каждая из сторон оценит задачи в стори поинтах, в результате чего сформируется общая таблица, состоящая из столбцов: Название фичи/инициативы, Business Value(чем больше, тем лучше), Time Criticality(чем больше, тем лучше), Risk Reduction and/or Opportunity Enablement (чем больше, тем лучше), Job duration / size (чем меньше, тем лучше).
После оценки каждой из фич по всем параметрам, станет понятно, за какую из задач стоит взяться уже завтра, а какая может подождать больше месяца.
Как не оформлять документацию
7. Не актуализируйте документацию
Все любят искать 200 отличий между документацией проекта и его реализацией.
Сейчас расскажу, чем может быть чревата неактуальная документация.
Я столкнулся с ситуацией, когда обеспечивал переход от удаленной на in-house команду. Проект был довольно сложный, разрабатывался на очень динамичном рынке и поэтому документация была старая.
Получилось так, что многие пункты в документации не актуализировали, потому что в команде не было бизнес-аналитика, просто Project Manager на этапе инициации описал, как будет выглядеть продукт, и дальше ничего не актуализировал.
Когда моя команда принималась за проект, то между тем, что написано в документации и тем, как продукт работал на самом деле, была огромная разница. Это очень сильно путало всех участников процесса.
Поддерживать документацию в консистентном виде не так сложно: достаточно после каждого спринта вносить изменения, которые произошли во время этого спринта. Какие-то вещи в документации по-любому будут не разработаны: что-то было невозможно, какой-то функционал изменили, но основная структура должна соответствовать реальности.
8.Оставьте теоретикам инструменты и техники бизнес-анализа
Зачем тратить время на теорию, когда на практике все по-другому! Разбирайтесь по ходу дела и не утруждайте себя ненужной информацией.
Хорошему бизнес-аналитику важно использовать в работе User Story, Use Case и UML диаграммы (state machine диаграммы, entity relationship или activity diagram), потому что они:
- позволяют более сложные вещи описать проще и понятней;
- помогают описать то, что словами описать невозможно в принципе;
- позволяет визуализировать требования, потому что намного проще воспринимать визуализацию системы, нежели ее текстовое описание.
В самом начале карьеры мне поручили описание одного очень сложного функционала и я, чтобы не ударить в грязь лицом, нормально так овертаймил, так как нужно было описать функционал в очень сжатые сроки.
Я не владел инструментами, о которых знаю сейчас, получается, у меня были какие-то задачи, но оружия для решения этих задач не было. Я сидел и думал, как бы описать требования так, чтобы было понятно. Помню, сидел на работе до утра, в обнимку с энергетиками. В итоге у меня получились user story, описание User flow и что-то наподобие Use Case, хотя ни одним из этих инструментов на тот момент я не владел. С точки зрения разработки требований, я был новичком и получилось, что я сам для себя и изобрел такой вот кривой вариант вышеперечисленных инструментов.
Когда я изучал инструменты и совершенствовал свои навыки, то понял, что мог бы потратить на это не ночи, а несколько часов, поэтому с тех пор всем советую расширять свой инструментарий. Некоторыми вещами вы возможно даже не воспользуетесь, но если вдруг столкнетесь с какой-то проблемой, у вас будет широкий арсенал вооружения для того, чтобы ее решить. Это на самом деле очень сильно ускоряет работу.
Что касается инструментов визуализации, лично я работал с:
- Balsamiq (для вайрфреймов и простых мокапов);
- Lucidchart (для диаграмм);
- Invision Studio (для сложных мокапов и динамических прототипов).
Инструментов, на самом деле, гораздо больше, но на начальном этапе вам будет достаточно этих трех.
9. Забудьте о структуре документации
Вы — художник, вы так видите и вам некогда наводить красоту в шрифтах и заголовках. Важна суть, а не форма!
Если вы все же планируете ускорить процесс разработки, документация должна быть не только понятной, но еще и удобной в навигации и приятной для чтения. Казалось бы мелочь, но я после того, как какое-то время уже поработал с документацией и увидел документ своего стажера, понял, что этот пункт нужно вынести в советы.
С точки зрения ценности, он описал все правильно, а вот с точки зрения форматирования, на это было больно смотреть и сложно ориентироваться. Дело не в перфекционизме, а в том, что разные шрифты и разные размеры заголовков путают, нарушается порядок вложенности и страдает логика.
Важно:
- разработать все шаблоны и стандарты документов с требованиями в рамках проекта, над которым вы будете работать;
- составить список документов, которые предполагается на этом проекте;
- убедиться, что все участники процесса знают о том, какие в проекте есть документы, на каких этапах они разрабатываются и на какие вопросы отвечают.
Например, возможно, вы с заказчикам приняли решение, что сначала делаете документ Product Vision, потом Product Requirement Document, и только после них — спецификации. Вы ставите об этом в известность команду и она ожидает увидеть не какие-то там документы, а бизнес-видение, PRD и детальные спецификации. Они понимают, что ничего другого к ним заходить не будет, и это нормально.
10. Оставьте команду без доступов к документации
Они не смогут плохо реализовать то, о чем не знают!
Убедитесь в том, что у всех участников есть необходимые доступы и необходимые права и участники получают вовремя нужные уведомления о важных изменениях.
При работе с гуглодоками, то я бы рекомендовал сразу при создании дока давать доступ на комментирование по ссылке в рамках компании (то есть только на корпоративные почты).
Если у вас нормально налажена коммуникация заказчиком, то вы вносите изменения и напоминаете ему через личный канал коммуникации, например, по телефону или в мессенджеры:«Я внес изменения в требования и мне нужен ваш аппрув».
Вы, как автор документа с требованиями, должны быть и модератором этого процесса. Вопросы, на которые уже ответили, комментарии, которые уже не релевантны — удаляйте! Они сохранятся в истории комментирования, а то, что было ценного в этих комментариях вносите в тело документа.
11. Забудьте хорошую идею, которая пришла в голову
Вы все запомните, не стоит нагромождать документацию!
Когда вы, например, разрабатываете документ под очередную итерацию и в голову пришла идея, реализация которой сейчас точно не войдет в скоуп, но при этом вы понимаете, что было бы неплохо внедрить ее в будущем — зафиксируйте эту идею в рамках документации проекта. Часто такие вещи забываются, а через пару месяцев вспоминаешь, что хотели еще разработать, но конкуренты уже вас опередили и внедрение фичи больше не имеет смысла. Так что для процветания продукта стоит ввести блок с предложениями и идеями от команды.
Выводы:
Чтобы меньше лажать, делайте выводы на основании моего опыта.
- Согласовывайте требования с заказчиком.
- Обсуждайте будущую реализацию с технической командой в процессе разработки требований.
- Оптимизируйте процесс взаимодействия с командой и заказчиком.
- Анализируйте рынок и конкурентов.
- Соблюдайте баланс скорость / качество.
- Приоритезируйте бэклог.
- Актуализируйте документацию.
- Используйте инструменты и техники бизнес-анализа.
- Придерживайтесь структуры документации.
- Убедитесь в том, что у всех участников есть необходимые доступы и они получают вовремя нужные уведомления о важных изменениях.
- Внедрите блок с предложениями и идеями.