Делюсь статьей 5 Ways to Avoid Repeating Past Project Mistakes в продолжение темы заблуждений в работе аналитика тут. В статье сформулировано несколько общих ошибок, которые не стоит делать аналитикам, добавила к ним пару примеров из своего опыта под значком 🔎
#1 Строить предположения относительно своей роли в команде
Оказавшись в новой команде, аналитики строят предположения относительно того, что ожидается от них в этой роли и пропускают некоторые обязанности или области требований. Какие ошибки при этом можно сделать:
- По незнанию нарушить границы ролей других участников команды, если предположить, что какие-то из задач ожидаются именно от БА.
- Не делать те артефакты, что ожидались, а по своему предположению усердно работать над артефактами, которых никто не хотел.
- Точь в точь следовать должностным инструкциям и не понять, что команда ждет чего-то еще, о чем не попросили в явном виде.
🔎 Задачи бизнес-аналитика бывают настолько разными в разных командах и компаниях, что иногда даже при устройстве на работу можно запросто обнаружить себя в каких-то неожиданных задачах. Например, где-то от аналитика ожидаются детальные прототипы в Фигма, а где-то это задача дизайнера и можно невольно отобрать часть чужого хлеба.
Второй пункт напомнил мне работу в одном из проектов, где от меня ожидался формальный документ с облегченным описанием процесса, для того, чтобы команда могла пройти принятые в компании формальные процессы и начать разработку. Это был мой первый опыт таких проектов и вместо ожидаемого описания процесса я именно “усердно” работала над функциональной декомпозицией модулей будущей системы. В результате потратила много сил, чтобы уложиться в срок, при этом работу оценили только за огромное количество страниц и неплохую структуру, а не за ценность для достижения целей команды.
Чтобы избежать этого лучше напрямую уточнять ожидания от вашей работы, стараться понять “образ результата”. Не всегда получится правильно понять картину только с чьих-то слов, поэтому чаще всего я прошу показать мне примеры подобных артефактов, которые в команде считают удачными. Если опасаетесь, что после такого вопроса вас сочтут некомпетентным, то можно пояснить, что вы работали с десятком техник и хотите понять, какие приняты в команде. Если примеров нет (вы делаете что-то, чего до вас в команде еще не было), то хорошо работает универсальный подход - как можно раньше показать первый вариант тем, кто будет с ним работать. Этот запрос нужно время от времени повторять и повторно попросить обратную связь на следующем шаге работы.
#2 С опозданием вовлекать заинтересованные стороны
Бывает, что аналитик работает над проектом без привлечения всех необходимых заинтересованных сторон. Иногда заинтересованные совсем рядом за углом и не потому, что они там прячутся, а потому, что их не пригласили. Иногда они слишком заняты, чтобы прийти на встречу. Иногда аналитики сами избегают общения с кем-то и пытаются решать задачу обходными путями.
🔎 О запоздалом вовлечении заинтересованных я немного рассказывала тут, не буду повторяться.
#3 Слишком рано начать заниматься улучшением документации
Бывает, что аналитик тратит слишком много времени на совершенствование документов и моделей. Это прекрасная тактика для прокрастинации и часто она связана с недостаточным вовлечением заинтересованных сторон. Хотя это выглядит очень продуктивным, когда вы сидите за компьютером и поправляете язык ваших требований или выравниваете линии на диаграмме, на самом деле это не приносит реальной ценности. Соберите черновики документов и используйте их для проведения рабочей встречи с заинтересованными сторонами, так вы много узнаете из разговора и задача будет двигаться быстрее.
#4 Держать в фокусе “что”, а не “почему”
Первые шаги работы над задачей лучше использовать для поиска бизнес-целей и причин, которые вызвали задачу. Если слишком поспешить фокусироваться на “что”, вместо “почему”, это может привести к рассогласованности ожиданий разных заинтересованных сторон. Такое бывает особенно часто в условиях ограниченного времени, когда от аналитика ожидаются только требования для начала разработки, или, когда заинтересованные стороны совершенно уверены в решении, и ожидают, что вы им поможете перенести детали на бумагу.
🔎 У каждого аналитика найдутся примеры, когда вариант решения выдается за цель или потребность. При этом ожидания по срокам бывают очень оптимистичными, всем понятно же, что делать… Такой сценарий неприятен тем, что аналитик может обнаружить несоответствие этого варианта решения реальным целям или потребностям, которые ожидается закрыть. Тогда приходится объяснять несоответствие команде и стейкхолдерам, которые уже настроены на результат, поэтому нужны особенно сильные аргументы.
#5 Допускать разрастание границ задачи
Случается так, что чем дольше аналитик работает над решением, тем больше оно становится. Это может происходить, если слишком сильно ориентироваться на бизнес, который в свою очередь плохо понимает возможности реализации. Еще так получается, если у вас доверительные отношения со стейкхолдерами и они рассказывают о своих реальных проблемах, в которых хотелось бы им помочь. При этом границы задачи растут и вы рискуете получить негатив от других участников команды, которым придется сокращать эти границы, чтобы задача вписалась в бюджет и сроки.
🔎 Добавлю пару слов от себя. Приходилось вам слышать что-то вроде: “Вчера провели встречу с заказчиком и они опять всем недовольны и накидали новых требований”? Чаще всего это симптом того, что
- фокус вашей работы сместился с “почему” на “что”, то есть вы обсуждаете решение, которое не закрывает потребностей заинтересованных сторон и они пытаются адаптировать решение своими дополнениями, но не рассказывают зачем им это нужно в целом;
- в вашу задачу пытаются перенести доработки, которые не были приняты в какую-то другую задачу;
- автоматизируемый процесс действительно сложнее, чем показалось при планировании, вероятно, недостаточно времени было выделено на исследование предметной области и контекста или контекст изменился.
