Сегодня - классное чтиво про API для новичков. Если слабо с этим сталкивались, то рекомендуем к прочтению: https://bootcamp.uxdesign.cc/apis-a-breakdown-for-non-technical-product-managers-6c3d7051107d

Всем пламенный привет!

Чтобы разбавить немного ленту ссылей, начнем новую рубрику заметок: типовые ошибки IT-аналитика и как не грустить из-за них попробовать их не совершать. Постараемся по существу и на личных примерах, которые оставляли и оставляют шишки разной степени болючести. Ваши примеры и комменты, as always, much appreciated.

Сегодня начнём с главной, думается, проблемы (ошибка #1) — полный игнор бизнес-требований. Как из логики, так и из опыта, по масштабу потенциальных последствий равных ей нет. Все (ранее) или большинство (нынче) отечественные и не только IT-компании благополучно скипают эту часть на проектах. Как следствие, многие проекты приводят к грустным заказчикам, которым итоговую убервафлю некуда присунуть. И компания наша такая, соответственно: "Ой, а что случилось? :( Неси ещё бабла, мы готовы код пилить вечно".

Раньше мы не владели модными терминами "стратегический анализ" и "дискавери". Аналитик для нас был человеком, которому нужно уметь участливо слушать заказчика, чтобы пересказать это потом бородатым и нелюдимым разрабам. Соответственно, аналитики работали только с требованиями к решению (и даже не с требованиями ЗЛ в контексте языка).
Потом к нам начали просачиваться модные книги и тренинги, и стало понятно, что сферический аналитик вначале пытается понять, зачем система, что за она и в каком скоупе. И если что за она и в каком скоупе мы выясняли и раньше — само собой как-то получалось, по наитию — то "зачем она нужна" и до сих пор не особо нашло отклик ("ну куда я, дрожащий аналитик, полезу…"). Достаточно сказать, что примерно половина проектов, в которых я участвовал, итогом поимели грустных клиентов, уныло машущих ручками пачкам денег. Половину из них, оглядываясь назад, можно было спасти адекватным стратегическим анализом. Продукт для масс-потребителя, который вообще не нашел свою нишу; бизнес-система для продажи, которая не имела никаких преимуществ над топовыми игроками рынка; мобильное приложение, которое просто шло "в довесок" к сайту, при этом не будучи вообще никому нужным — вот несколько примеров "выгодных для исполнителя" проектов. С другой стороны, не могу нарадоваться, когда поползновения в сторону анализа стратегии встречаются заказчиками с приятным удивлением и хвалебными одами. А если это еще приводит и к внезапным инсайтам с их стороны ("блин, да, не подумал о "зачем", вот тут спасибо") — совсем зачетно.

Как не допустить ошибку: всегда хотя бы чуточку работайте с требованиями уровня "Зачем" (бизнес-требованиями).
Варианты:
1) Ваша компания/подразделение/команда и так это делает в ногу с заветами BABOK или крайне открыта к изменениям в этом плане. Отлично, тогда просто идите по главам из типового Vision and Scope: письмами, беседами и прочими коммуникациями несите в мир счастье.
2) Вы не работаете с такими требованиями — поставленная задача ограничивается только распилом досок:
2.1) "Диа кастома, мы понимаем, что ты хочешь напилить как можно больше досок асап, но не мог бы ты уделить хотя бы одну встречу обсуждению стратегии и концепции системы. Наш преомегалютый опыт намекает, что это сильно поможет нам сфокусироваться в дальнейшем на проекте, не терять корневые цели и принесёт сплошные бенефиты".
2.2) Дальше смотрите по временной доступности и эмоциональной реакции на подобную идею.
Дешево и сердито: Lean canvas для продуктов ("диа кастома, а давай на встрече заполним совместно вот такую клевую табличку. Покумекаем и впишем в процессе обсуждения. Мы возьмем с собой ключевых членов команды, а ты бери тех, кто может дать ценный инпут в стратегию и позиционирование") или же кастомно сделанный Lean canvas (заменив продуктовые секции на бизнес-цели, бизнес-риски и зависимости).
Основательно: серия интервью или воркшопов с проработкой бизнес-целей, критериев успеха, бизнес-рисков, зависимостей, категорий пользователей, вариантов и образа решения.

Что при этом стоит помнить:
- SMART для целей не обязателен. Предпочтителен, но не жизненно необходим, если у всех туго идет. Понимать бизнес-эффект от разработки решения даже без циферок — уже благое дело. А если еще будет четенькая трассировочка всех требований сверху-вниз (или же попросту Impact Map), то вообще огонек-огненный.
- Цели нужно помогать выработать, а не выспрашивать. Многие на вопрос "Дай нам сюда бизнес-цели по SMART" уйдут в астрал на несколько дней — на этом можно и похерить энтузиазм стейкхолдеров. "Вот, что такое БЦ; вот, как они помогут проекту и нашему участию; вот, чем круто хотя бы попытаться их засмартовать… А давай попробуем, м? Мы поможем наводящими вопросами и генерацией идей."
- Не нанесите несчастье своей компании в погоне за счастьем для заказчика. Помните, что итогом идеального стратегического анализа может быть отказ от разработки решения в принципе или выбор более подходящего решения, которое будет ни разу не оптимальным с точки зрения доходов вашего работодателя. Лавируйте тут аккуратно, с консультациями с вашим ПМом, БА и прочими высокими дядьками.
- Держите выработанные цели ("зачем") всегда в фокусе вашей деятельности в дальнейшем. Очевидно, что просто их сформулировать и забросить в Confluence тухнуть — так себе идея. Старайтесь всегда отражать всю вашу деятельность и выработанные единицы скоупа/требования от "Как это поможет в достижении целей заказчика". И не стесняйтесь говорить о таком заказчику, когда будет найдена нестыковка.

Ошибка #2 (дабы не было скучно, они не будут структурированы по тематикам — системности вам и так на работе хватает :)) — пропуск непрямых пользователей и их требований.
Это то, чем запросто страдают аналитики, когда не имеют какой-либо теоретико-практической базы за плечами. Непрямые пользователи — это те, кто потребляют результаты системы, но не пользуясь ей, а опосредовано. К нашему счастью или несчастью, зачастую именно они являются источниками ключевых пользовательских требований и диктуют наполнение системы.

Пример из личной практики: система для экспорта отчетной информации о кредитах. Прибежал, значит, заказчик и говорит такой: нужна система, которая из баз данных А и Б объединит информацию в один отчет формата X и позволит его экспортнуть в PDF. "Не базар, заказчик, какой отчет нужен?" Огненным сигналом на этом этапе уже служит полное отсутствие вопросов вида "А на кой ляд тебе все это надо?" — об этом говорили в ошибке #1. В общем, заказчик, как оно часто и бывает, послужил эрзац-заменителем пользователей (что в целом отдельная тема для разбора полетов) и надиктовал мегасуперформат, который благополучно и был запилен. Внезапно, через пару месяцев заказчик прилетает вновь и плачет, что систему нужно полностью переделать, ибо планеты криво выстроились, подножку по жизни поставили и вообще у него все вокруг редиски, а он Д'Артаньян. По факту разбора беды поняли следующее:
а) Пользователи с его стороны систему вообще не пользуют. И именно на этом этапе внезапно уразумели к тому же, а кто они вообще (сотрудники кредитного отдела) и зачем она им (предоставлять отчеты в государственный контролирующий орган).
б) Почему они ее не пользуют: стороннему органу отчеты надобны в совершенно ином формате, чем тот, который надиктовал заказчик. А потому труженикам проще, как и раньше, ручками их колбасить.
в) И заказчик, и аналитики — те еще градостроители.

Как не допустить ошибку: 1) не забывать в явном виде заниматься процессом с умным названием "Идентификация и анализ ЗЛ", 2) идти при этом по чеклисту, в котором в том числе будет указано, что пользователи могут быть прямыми и непрямыми, а заодно человеками и нет (тут тоже можно пропустить ряд важных требований), 3) как бы невероятно ни звучало, но если есть все-таки непрямые пользователи, их требования нужно попытаться извлечь напрямую у них или хотя бы через заказчика. Если тяжко идет, то совсем не лишним будет согласовать с заказчиком результаты анализа ЗЛ, задавая при этом нужные вопросы.
Как оно могло бы быть в альтернативной вселенной в примере выше: "Заказчик, вот категория юзеров "Сотрудники кредитного отдела", ага? —> Нафига им система вообще? —> А, для передачи другим? А есть требования от этих других? Может, если это гос. орган, то где-то необходимый им шаблон отчетов описан? Или, может, можно с ними согласовать финальный вариант?"

Пара отличных заметок о коммуникации на английском для тех, кому актуально:
https://blog.english4it.online/12-phrases-that-will-make-your-emails-more-professional-5baf7b2afcd7
https://blog.english4it.online/5-things-that-make-you-sound-rude-in-english-and-what-to-do-about-it-cf4fc7655f9f

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

Тут можно выделить две абсолютно типовые подпроблемы:
1) Навязывание документации без учёта фидбэка.
Как не стоит делать:
На курсе нас научили / на проекте так исторически сложилось, что мы делаем вот такие убернавороченные срски, сторьки и юз кейсики в лучших традициях предков. А потому, узри, команда, мой гений!
Проблема в том, не всякая команда поднимет бунт, если им что-то не нравится или не работает так, как могло бы в идеальном мире. Классно, если есть ретроспективы, где кто-то под общий шумок может и заметить, что с документацией что-то не так. Но может быть и так, что половину ваших трудов люди не читают, ибо непонятно/сложно/много-бесполезно.
Как стоит сделать: как только вы оказываетесь на новом для себя проекте, соберите фидбэк команды по поводу шаблонов документации, которые вы планируете использовать. Покажите им пример описания требований в виде стори, вертикальных кусков спеки, прототипов, диаграмм, после чего устройте воркшоп / вышлите опросник / подойдите к каждому лично и пообщайтесь — в общем, соберите честный фидбэк насчёт того, хватает ли информации для выполнения работы, нет ли лишнего и понятен ли язык и контент. Естественно, после этого обработайте результаты и в частности те моменты, где на базе фидбеков начинает прослеживаться подобие системной проблемы. Адаптированная под проект и команду документация всегда лучше универсального шаблона на все времена.

2) Отсутствие обучения команды пользованием артефактами.
Хороша ли ситуация, когда ваша модель данных на безукоризненном UML выглядит для джуна Васи как что-то, прилетевшее из космоса? И потому он благополучно скипает это (или, что ещё хуже, интерпретирует по-своему)?
Ваша задача, как вы понимаете, прокоммуницировать информацию. Важно постараться не путать её с задачей "показать всем, какие я высокоинтеллектуальные артефакты писать умею". Тут также могут помочь опросы и получение фидбэка всякими иными способами. И если адресатам вашей документации что-то не очень ясно, то, с одной стороны, вы можете пойти по пути в пункте 1 выше, а с другой — не стесняйтесь сделать мини-тренинг:
- Вот, как читать и в какой последовательности идти по документу, когда вам поступает задача на реализацию/тестирование фичи
- Вот, как интерпретировать мои UML-модели, прототипы, юз кейсы и пр.
- Вот, где у вас есть свобода действий ("могу сам придумать"), а вот где её нет
- Вот, что делать, если что-то неясно или есть подозрения в неполноте и прочих проблемах ("идти ко мне :)" )

Ошибка #4 также касается коммуникации с вашими партнёрами по счастью (проекту, ага) — нечеткие зоны ответственности, что приводит либо к дублированию работы (причём с непонятным уровнем компетентности в ряде случаев), либо к пробелам в ней. Первое часто вызывает переделки друг за другом и конфликтные ситуации, а второе — пробелы в (спасибо, кэп) проделанной работе и последующее хаотичное тыкание пальцем "Отныне, Вася, этим будешь заниматься ты." 

Давайте вспомним, на чем фокусируется сферический аналитик в вакууме. На требованиях. Поняв, что такое требования в идеальном измерении, вполне несложно дедуцировать, где должна начинаться и заканчиваться ваша работа. Но есть пара нюансов: 1) под требованиями и 2) под границами работы аналитика в компаниях/отделах/командах могут понимать и принимать всякое. Те, кто проходил курс от ITMINE, вероятно помнят, что с требованиями пересекается (создавая при этом "серые" области) ряд иной проектной информации: проектно-менеджерские штуки; то, "как" реализовать требования (design specifics); UI и пр. И раз ряд информации может иметь разных авторов в плане проработки, то и налицо потенциальные непонятки, кому и чем заниматься.

Часто встречающиеся кейсы и как с ними жить:
- Бизнес-аналитик прорабатывает структуру базы данных — либо потому, что так исторически сложилось, либо потому что команда или ПМ считают, что это натурально его компетенция. А девелоперы потом допиливают, ибо без слез на БД от БА смотреть нельзя.
Решение:
Если вы СА, то, вероятно, все в норме. Если же БА, то а) проговорите команде/автору процессов (ПМ, тим лид, etc.), что есть требования и что именно они — вотчина аналитиков. Например, "я как аналитик буду ограничиваться логической моделью данных, как и должен; я научу команду её правильно интерпретировать; в трансформацию же её в физическую реализацию лезть не буду, дабы не навредить криворукостью".

- Схожая по причинам ситуация: аналитик прорабатывает работу с внешним API, причём даже в таких вопросах, как "какой технически способ интеграции выбрать" и "в каких временных точках обращаться к эндпойнтам". Метод решения ситуации аналогичен предыдущему (если вы не СА и естественным образом не принимаете это за свой спектр деятельности): "я девочка, я хочу платье я аналитик, я отвечаю за требования ("что" вложить в систему, а не" как" это реализовать). Мы точно эффективно используем ресурсы? Я точно тот человек, который это лучше всех продумает? А вам точно кайф потом за мной все переделывать? Может, я остановлюсь вот тут и тут (использование API в контексте требований), а дальше уже вы подхватите (технические нюансы его использования)? Или же давайте вместе сядем и по ходу процесса каждый будет давать инпут в том ключе, где он компетентен. "

- Аналитик и дизайнер/юиксер делают одну и ту же работу или спорят, кому что делать. UI и UX—  это также часто серая область. Кто-то где-то относит это к требованиям, иные же — к деталям реализации. Есть вполне простое решение: если помимо аналитика есть люди, умеющие проработать UI/UX лучше, то считаем это не-требованиями и везде в артефактах БА не касаемся UI от слова совсем (не считая внешних ограничений, когда, например, заказчику нужен именно такой вот UI и никак иначе). Пусть будет полная свобода действий у дизайнера и им подобных ролей (и не будет пересечений в работе, не считая совместных коммуникаций с заказчиком). Если таких людей нет, то а) если для вас UI — cornerstone продукта, успехов вашей команде :), б) аналитику стоит считать это требованиями и включить в разных соприкосновениях в свои требования.

- На аналитика возложены сакральные активности по обсуждению сроков, бюджетов, команды, процессов, whatever. На самом деле, не видится тут ничего плохого, если а) обсуждалка таких вопросов у аналитика выросла, б) как и в кейсах выше, это договорено с ПМом, в) вы совмещаете роли. Обратная ситуация наблюдается часто. "Эй, аналитик, а че ты этого не сделал и этого не донёс? Заказчик сидит и не понимает, когда продакшн-деплоймент будет." И бедный аналитик принимает за мантру обсуждать теперь такие вопросы.

В следующий раз: "Э, слышь, аналитик, а чего ты там наобещал заказчику? Ты у меня спроси сначала, когда подобные материи обсуждаете". И у аналитика начинает рваться шаблон.
Что с этим делать, думаю, уже понятно: сесть с ПМом и обсудить, кто за что отвечает. "Давай очертим границы затрагиваемой информации, чтобы не противоречить друг другу и не оставить при этом пробелов."

Все эти проблемы схожи и имеют одинаковые решения. И решение тут в том, чтобы проактивно прояснить зоны работ и ответственности. И это не булшит-вординг, а практический экшн айтем. Сделайте это (идеально) на старте вовлечения в проект. Весьма маловероятно, что это сделают за вас, кстати. Или хотя бы сделайте/делайте такое по мере возникновения проблем с размытой ответственностью. Не обязательно все делить на "моя хата с вот этого вот края" — многие вещи можно делать коллаборацией. Главное помнить, что A по RACI только один :)

И снова пара отличных заметок о коммуникации на инглише. Что особенно радует, так это практическая применимость советов автора — это все действительно расхожие выражения, к которым так или иначе мы приходим и добавляем в свой словарик по мере накопления опыта.
https://blog.english4it.online/12-english-phrases-for-work-conversations-every-professional-should-use-b82261d26f1c
И тут же — общие советы по коммуникации, под которыми можно подписаться всеми руками (кроме пункта про синхронность/асинхронность — там весьма спорные утверждения, например, про массовое визибилити сообщений): https://blog.english4it.online/5-communication-trends-you-should-start-using-5f7c1a528fd1

На очереди у нас, на первый взгляд, довольно забавная ошибка #5, которая не для всех, но многих актуальна — сопротивление голосовому общению :)

Мы знаем, что аналитик — это комбинация двух ключевых "направлений": коммуникации и анализ. Мы также знаем (или как минимум часто бывает такое наблюдение), что человек склонен кайфовать только от одной из этих сторон (при этом, соответственно, вторая вызывает лютую грустяшку, а порой и панику).
Если вы истинный экстраверт, то высока вероятность, что перетереть что-то с ЗЛ — в кайф, а вот для того, чтобы погрузиться в спеку на часы и писать/выверять/систематизировать полотна текста, нужно долго бодаться с прокрастинацией. И обратное: если вы "спекоковырятель", то перспектива сделать презентацию заказчику, да еще и, например, на неродном языке, может приводить в ужас. Соответственно, о вторых и пойдет речь (мне это знакомо как на личном опыте, так и в виде проблемы при работе со многими менти).

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

Что с этим делать? Если вы чувствуете, что написанное — про вас, то бишь налицо тотальное доминирование переписки, а не устного общения, и это не вызвано политикой компании, недоступностью заказчика для иных каналов и прочими объективными обстоятельствами (т. е. по сути это вызвано сугубо вашим личным выбором и предпочтениями), то призываю переосмыслить этот выбор, как бы ни не хотелось этого делать. Предлагаю просто взять на веру, что со временем это придется сделать, если вы не хотите застыть на месте в плане продуктивности. Да, это может быть некомфортным в моменте (взять и провести презентацию команде; позвонить проактивно заказчику и пообщаться с ним голосом; собрать ЗЛ со стороны заказчика на фасилитируемый вами воркшоп). Но тут есть и хорошие новости: опыт показывает, что практически всегда это всего лишь вопрос обыденности этих активностей. Провести звонок первые 5-50 раз может быть волнительным и некомфортным. Делать это в следующие разы — плевое безболезненное дело. Тотальное засилье переписки в культурах некоторых компаний иногда доходит до такого абсурда, как писать письма коллеге в соседней комнате, хотя бы даже из-за неохоты отрывания попы от стула. На некоторых тренингах по коммуникациям есть даже простое упражнение, которое крайне доступно показывает проблематику этого: команда обменивается записками на стикерах, чтобы выполнить какой-нибудь мини-проект (например, сделать башню из бумаги по требованиям заказчика), при этом им вообще запрещено общаться голосом. Можете представить, сколько по времени она выполняет такой проект? Попробуйте просто представить (а еще лучше, конечно — соберите что-нибудь в кулак и попробуйте на практике), что вы как аналитик извлекаете информацию не письмом, а голосом. Задумывались ли вы над тем, насколько это будет быстрее и эффективнее за счет целой кучи факторов? Да, у переписки есть ряд преимуществ, но по факту они либо ситуативны, либо достижимы и в устной коммуникации:
- Вы можете тщательно обдумать каждое ваше слово (да, если контент требует такого, то несомненно не стоит идти и шпарить голосом первое, что придет в голову)
- У вас есть письменное подтверждение факта коммуникации и ее контента (знаем/помним про агенды и протоколы?)
- Асинхронное общение позволяет собеседникам ответить в оптимальное для них время

Но есть, при этом, один главный минус: это капец как долго и трудозатратно. Просто в разы. Есть и иные аргументы: невербальная коммуникация; возможность оперативно, в сравнении с письмами, расширить/изменить диалог; гораздо меньшая вероятность неверно считать эмоции и больше возможности наладить приятный контакт.

Кейс, который не раз встречался в практике: “Насяльника, у меня тут заказчик молчит / порет чушь / не всю информацию дал :(” -> “%юзернейм%, камон, иди вот прямо сейчас и позвони ему тогда.” -> “:(:(:(:(” Надеюсь, что это не про вас, потому что такое сильно лимитирует вашу привлекательность как спеца и дальнейший рост :)

Полезная заметка о декомпозиции user stories (кому-то напоминалка, а кому-то, вероятно, и новые идеи): https://medium.com/@eiki1212/9-patterns-of-user-story-splitting-b1498ecad8dd

Ошибка # 6 весьма глобальна по своей сути, а потому заварите чайку и приготовьтесь к длиннопосту — мы поговорим про узкий арсенал техник у аналитика.

Когда такое бывает? Подобное наблюдается, когда у аналитика нет багажа знаний о том, что бывает как-то иначе, нежели в его мире. Т. е. аналитик не читает книжки, не смотрит видосики, не общается в проф. чатиках и не проходит курсики. А если аналитик еще и работает в узкоспецифичной в любом значении среде (процессы, заказчики, культура, домен), то часто это вызывает серьёзный застой. Я собеседовал множество аналитиков с приставкой senior (ну а какую им себе еще поставить, если там, откуда человек пришел, он проработал 7+ лет?), когда в процессе рука так и не смогла отлипнуть от лица. Типовой усредненный кейс в этом контексте: “я звался аналитиком, семь лет работал над перекладыванием инфы из эксельки одного формата в эксельку другого формата, ибо иного и не требовалось от меня; не разу не слышал про какие-то там юзер стори и прочие слова, которые вы тут лопочете; насыпайте мне вагон бабла!” Аналогичное можно сказать и про джунов/миддлов, у которых процесс накопления знаний и кругозора ограничивается сугубо случайно рекомендованными видосами на YouTube (в более печальных случаях — постами в ленте Instagram).

Подобное ярко заметно не только на интервью, но и в общении — часто их посылы идут в комбинации с постулатом “Зачем нужно обучение и развитие, пфф… Сам разберусь, пока не жаловались.” Речь тут, конечно, не про всех, прошедших подобные пути, — люди часто умеют вполне себе качественно и системно самообучиться и поддерживать свой кругозор и навыки.

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

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

Начнем с извлечения информации/требований. Вот прилетает к вам заказчик и говорит, что его компании нужно некую систему забабахать для сотрудников.
Что есть в арсенале (и, как следствие, в плане действий) у аналитика, который действует “по наитию”? Потрындеть с заказчиком, вестимо (иногда еще и сугубо письменно — см. предыдущую ошибку).
Что есть у аналитика с багажом подходов? Все известные нам техники извлечения требований: интервью, воркшопы, опросы, наблюдение, анализ интерфейсов, документации, обратная инженерия и пр. Как минимум они есть в виде чеклиста в голове или базе знаний, что уже эпик вин — не обязательно при этом иметь глубокий практический опыт применения каждой из них. И такой аналитик может составить себе “немного иной” план, нежели тупо написать заказчику письмо с посылом “Сыпь в меня требованиями, я внемлю.” Например, такой:
- Согласовать с заказчиком и провести первичный сбор информации с конечных пользователей анкетированием.
- Провести персональные интервью с теми, чьи ответы надо раскрыть и уточнить.
- Изучить документацию на стороне заказчика по вопросам X и Y.
- Провести итоговый воркшоп с заказчиком, главами отделов и лидами своей команды, чтобы донести и обсудить в реальном времени итоги сбора информации и выработать план действий. Что-то подсказывает, что и для проекта, и для самого аналитика вероятность успеха во второй ситуации чуточку повыше.

Рассмотрение того, какие есть бест практики и техники и когда они полезны — это фактически курс по БА, поэтому дальше буду относительно краток.
Анализ информации/требований:
“По наитию” = “Опа, а тут у нас пробел :( Пошёл я обратно к заказчику :(:(” и тому подобные наблюдения, зависящие только от внимательности автора и расстановки планет в небе.
С багажом техник: понимание типов требований и информации по БА и пользование этим как чеклистом для извлечения и анализа полноты извлеченного, понимание характеристик (качеств) требований разных видов и рекомендаций по их обеспечению, знание визуальных моделей разных видов и направленности (а чем с больших сторон мы смоделируем решение, тем больше неполноты/противоречий и прочих проблем мы найдем), специфические техники, в разы облегчающие работу с качеством требований (CRUD, матрицы трассировки, юз кейсы и типы их сценариев, техники приоритизации и пр.). Например, а вы знаете, что такое CRUD/CRUDL? Если нет, то вы даже не представляете, насколько владение 4/5 буквами и умение вспомнить про них в нужный момент может повлиять на полноту прорабатываемых вами требований :)

Документирование информации:
“По наитию” = “А я вот знаю сторьки, знаю Confluence… а большего мне и не надо!” Сюрприз-сюрприз: далеко не всегда и не везде user stories в том формате, который принят лично у вас на проекте (а чаще всего это означает не особо осмысленный рандомный подход к подаче требований, всего-лишь исторически принятый командой),

позволят эффективно донести инфу до стейкхолдеров (и тут будет уместным отметить, что еще и понимание того, кто такие стейкхолдеры и зачем и как их идентифицировать и прорабатывать — также чууууточку увеличивает вероятность успеха вашей работы).
С багажом техник: как минимум знание о и понимание разных видов артефактов и систем хранения информации (V&S, SRS, ТЗ, User Stories, RMS, Confluence и пр.) может помочь вам выбрать нужные гвозди, когда придется думать, чем забить целевые доски. Естественно, это включает в себя и хотя бы базовое понимание того, когда и что уместно и в каких условиях сработает лучше. А представьте теперь, что можно еще и понимать, что и зачем нужно вообще от документирования и хранения информации в разных ситуациях и уметь продумать эти аспекты для проекта (редактирование, чтение, версионирование, история изменений, коллаборативная работа, трассировка, ведение атрибутов требований — да, бизнес-анализ может быть иногда слегка навороченнее, чем механически сторьки писать :))

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

Что хочется отметить по итогу:
Часто вижу уверенные заявления вида “У меня во всех ситуациях тупо работает подход X, что вы мне тут усложняете жизнь всякими ругательными словами?” или “Зачем усложнять такую простую работу, как анализ требований? Собери требования, донеси до команды — вот 2-3 подхода, просто делай это, и не надо мне голову забивать всем этим умным булшитом.” Тут важно понимать, что есть большая разница между тем, когда 1) такое исходит от человека, знакомого с большинством бест практик и сделавшим осознанный выбор в сторону любимых подходов (и их адаптации к разным ситуациям), и 2) тем, когда подобное идет от банальной неосведомленности — от людей, незнакомых с тем, что бывают различные проекты, ситуации, культуры и заказчики, а заодно и не осознающих, что практически на каждую ситуацию уже кем-то придуман свой вполне себе работающий велосипед. Да, вы можете забивать одни и те же гвозди одним и тем же молотком, и это может вполне себе работать. Только вот работать работу можно по-разному. Когда вы узнаете об иных подходах, позволяющих сделать то же, но эффективнее с любой позиции (качество, время, эффорты), вы едва ли сделаете себе и проекту хуже. А потому повторим то, с чего начали: мощь аналитика — в широте набора техник, которыми он владеет для решения задач и умении составить из них работы на конкретном проекте. Не замыкайтесь на том, с чем работаете сейчас: читайте правильные книжки, ресурсы, каналы (ага, как этот ;)), проходите хорошее обучение время от времени — в общем, не забрасывайте саморазвитие. А еще лучше — пробуйте по факту всего этого разные техники и подходы — это и контент для резюме, и практический опыт, который позволит собирать все более крутые комбинации техник в будущих проектах.

Ошибка #7 — непроговоренные/неявные ожидания. Это нетривиальный момент, потому что далеко не всегда фиксится простым “делай сюда, а туда не делай”. Обычно, чтобы быть аккуратнее с ожиданиями, которые могут вызвать конфликт, нам нужно вначале наступить на эту граблю несколько раз.

Что это означает? У нас есть некая картина мира относительно того, как должен или не должен поступать человек. И редко мы стопаем себя в процессе оценки и пытаемся применить пресловутое критическое мышление, оперируя вместо этого такими категориями, как “Это же очевидно / логично / нормально. Именно поэтому я ожидаю, что должно быть вот так.” Соответственно, и мы, и другие (например, ваша команда или стейкхолдеры со стороны клиента) формируем эти ожидания на базе собственных представлений, часто не задумываясь о том, а с какой, собственно, стати. Давайте на примере пары реальных кейсов:

1) Ситуация, скорее, грустная. Многим этот пример будет знаком, т. к. я часто делюсь им на тренингах. На старте проекта аналитики в команде работали аки пчелки, общаясь с заказчиком и по утрам, и по вечерам, а в особо запущенных случаях еще и ночью. Со временем запал ноулайфера спал, т. к. и проект перешел в фазу саппорта, и аналитики повзрослели. И тут все ярче стала проявляться раздражительность заказчика. Списали это на финансовые проблемы с продажей системы и просто привыкли к этому и регулярным хождениям по минному полю при написании писем. Сам заказчик, при этом, стал локальным мемом, про которых аналитики в курилках часто общаются в духе “Ну как, снова мозг тебе вые(л)?” Так получилось, что спустя пару лет довелось пересечься с заказчиком на одном из корпоративов. И, внезапно, он оказался огненным чуваком, с которым дернуть пивка — кайфовое дело. Соответственно, в процессе сего дела пошел разговор по душам, и всплыла интересная штука: оказывается, то, что аналитики делали вне работы, воспринималось как само собой разумеющееся (часть сервиса), и когда это перестали делать, заказчик подумал, что качество услуг резко снизилось и приобиделся. Как только это было донесено заказчику в личном общении, реакция была вполне ожидаемая: “Епрст, а че вы сразу не сказали? А я тут себе картин негативных нарисовал…”

2) Ситуация, скорее, веселая. Есть профильное сообщество X. Оно делится материалами, проводит мероприятия и всячески по-иному наводит движ. И вот после очередного мероприятия идет анализ обратных связей, среди которых встречается что-то в духе “Все было неплохо, но сильно напрягло отсутствие вегетарианской пиццы на ланче." Немного контекста: сообщество некоммерческое, люди там активничают даже не за еду, мероприятия в плане организации — это порой пара месяцев геморроя с уговариванием людей со всех сторон, у которых часто склонны меняться планы (докладчики, кухня, помещение, финансы и пр.). При этом само посещение мероприятия — либо бесплатное, либо сугубо с компенсацией еды. Соответственно, с одной стороны у нас есть ожидания одного человека (потребителя): “Ну ок, еще один профильный ресурс. Ну лан, посмотрим, че там. И вообще, пусть борются за мое внимание, сообществ много.” (я утрирую и всего-лишь полагаю, что подобное может крутиться в голове человека с подобным фидбэком). С другой стороны, у нас есть мысли человека, который был вовлечен в организацию на протяжении пары месяцев: вначале много мата, а потом “Ну и зачем мне всем этим заниматься? Мы тут стараемся, что-то делаем бесплатно; мало того, что интереса, кроме самого процесса создания чего-то крутого, никакого. А человеку, блин, тут пиццы вегетарианской не хватило на конференции с проф. докладами. Вы там вообще уже “уху” “ели"? После этого у человека наступает демотивация делать нечто подобное впредь. Именно для этой ситуации не факт, что подойдут решения, описанные ниже, но я привел это, чтобы показать, к чему может привести mismatch в ожиданиях, если его а) не осмыслить, б) вероятно, как-то с ним не поработать.

Что с этим делать?

Гарантированного практического решения не видится, но можно выделить два пункта, которые могут сократить либо вероятность, либо impact от таких ситуаций (причем как со своей, так и с других сторон):

1) Держать в голове, что это может быть источником проблем и попробовать хоть иногда проактивно подобное упреждать. Попробовать внедрить в практику, что в случае серьезных переговоров (с командой, заказчиком и иными подобными ролями) — например, на старте взаимоотношений (начало взаимодействий с заказчиком, работы в новой команде с девелоперами, тестировщиками и прочими ролями) — актуальным может быть аккуратно проговорить следующее: “Давайте, чтобы не было потом обмана ожиданий, проговорим следующие вещи: … Просто на всякий случай — сделаем неявное явным.”

2) Осваивать техники и подходы, которые касаются подобной проблемы. Из того, что есть в арсенале у БА, это, например:

- План коммуникаций с ЗЛ, суть которого — настроить и синхронизировать взаимные коммуникационные ожидания на старте (”Блин, ну я ж не ожидал, что ты уйдешь в отпуск в середине проекта”; “Ну я не думал, что тебе, чтобы заапрувить спеку, надо 5 дней ее вычитывать. А у нас сроки горят :(”; “Ну кто мог подумать, что если тебе что-то непонятно в требованиях, ты не подойдешь спросить, а сделаешь по собственному разумению”).

- Есть такое понятие, как анализ рисков у БА — это заранее подумать о том, что может пойти не так, и что с этим можно сделать (”Заказчик будет долго отвечать на письма. Заказчик не поймет документ с требованиями. Что я могу сделать уже сейчас, чтобы сократить вероятность/влияние этого?”). Именно на этом этапе у вас в качестве политики по работе с рядом рисков может контекстно всплыть решение “Правильно согласовать взаимные ожидания от работы”.

- Если мы говорим про требования и прочую информацию по БА, то в копилке аналитика есть такое понятие, как assumptions. Крайне полезный инструмент, который помогает лавировать в условиях неопределенности. “Мы полагаем, что вот такое решение будет оптимальным. Assumptions, при этом, следующие (если мы тут неправы, укажи нам на это): 1) систему будут использовать на Северном полюсе в варежках. 2) Юзеры — не ламеры, сами разберутся в трех кнопках без обучения. 3) GPS будет всегда доступен — перебоев не ожидается. Если предположения валидны, то тогда рекомендованное нами решение в силе.”

- А еще тут можно посоветовать (скорее уже как дополнительный фреймворк, который позволит выйти из ряда подобных ситуаций и сделать многие неявные вещи явными) вот такую заметку о том, почему люди могут чего-то не делать: https://habr.com/ru/companies/stratoplan/articles/220793/. Он не раз спасал от поспешных мыслей и реакций из разряда “Ах, он редиска такая! Ну раз ты так, то и я так.”

Пятничное и, надеемся, чуть более занимательное чтиво ☺️

Ошибочка #8 в терминологии Максима Дорофеева (замечательный автор книг и тренингов по проектному управлению и самоорганизации) — эффект дырявого стека.

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

- ответственность (вот вы пообещали сделать работу в срок, но профакапили — грустяшка 😞; а если еще и никому проактивно не сказали до дедлайна — совсем печалька 😡)

- самоорганизованность (за полным определением можно сходить в какую-нибудь Википедию; если вкратце, то, например, следить за своими задачами и их сроками — ваша и только ваша ответственность)

- тайм-менеджмент (вы в состоянии сами приоритизировать свои задачи по важности/срочности и действовать, исходя из этого)

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

- командная работа (вы, естественно, можете функционировать как часть команды и способны мириться с тем, что есть и другие мнения и подходы).

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

Что это такое? Наверное, картинка от автора покажет это наиболее наглядно: https://infostart.ru/upload/iblock/9c4/9c480c51b7cf7ffd7bdb7c73d44474af.jpg. Слегка перефразируя описанное в книге “Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо”, если человек неспособен вести аккуратный список задач, то весь стек заданий удерживается в голове, к чему она не приспособлена. И все, что в этот стек не помещается, «падает на пол». Грубо говоря, это продалбливание задач/дел, когда их много.

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

- Я как БА-менеджер закидываю сотрудника задачами. Или заказчик закидывает аналитика письмами. И добавим сюда условие, что это большой или очень большой поток. Можно даже еще усложнить ситуацию: у сотрудника аврал, попа горит, и все это на пяти проектах, которые он одновременно тянет. Если при этом старые задачи/письма/что угодно “забылись” или “потерялись”, ибо много всего, — это косяк, за который ответственен только исполнитель. И я сейчас не про критичность проблемы, которая может быть разной и в экстремальных условиях даже приемлемой и понятной, а про правильное взятие ответственности на себя. Ну а если это системная проблема (т. е. нет рабочего механизма для подобного, а есть только перегруженная весом проблем голова), то это грусть, и в большинстве случаев я резко не хотел бы дальше работать с этим человеком.

- Аналогичный пример, который я иногда наблюдаю на курсах и в менторинге: я могу закидывать людей материалами на “почитать при случае”, причем в условиях и так немалой нагрузки. И если наблюдается ситуация “О не, я это не видел / не читал / не планирую, потому что и так много всего, я просто не могу все это себе зафиксировать”, то а) учитывая, что мы еще только обучаемся, плюс человек никому ничего не должен в этом аспекте (в меньшей степени такое актуально для менторинга), то без проблем, понимаемо; б) если при этом проблема перекладывается на ментора/тренера (“не надо столько всего давать, когда и так все плотно — загружайте в мои планы информацию в меру”), то я в зависимости от контекста либо стойко смирюсь, либо мягко донесу описанное в предыдущем пункте — в рабочем окружении это будет ваша и только ваша проблема, и уже там у этого есть и ответственность, и последствия.

Что с этим делать? Капитан Очевидность, настало твое время:

1) Фиксировать все НЕ в голове. Честно, я редко встречаю аналитиков со стажем, у которых инструмент фиксации — память. Ведем речь про задачи? Инструмент для фиксации задач: блокнот, календарь, Todoist или прочее ПО для организации дел. Говорим про материалы и прочие заметки, которые могут понадобиться в будущем? Ровно аналогично, только ПО для этого будет слегка другое (все, думаю, слышали про Evernote, OneNote, Notion и им подобное). То есть это просто надо делать. И раз уже в теме: вот интересно, а есть такие, кто систематически проводит интервью со стейкхолдерами, не фиксируя извлеченную информацию, а держа полученное только в голове? Нужно ли пояснять, что это путь в ад? 🙈

2) Второй момент лишь косвенно касается озвученной проблемы, но для работы с “не забыть” есть прекрасный инструмент — чек-листы. Есть даже целые книги, которые посвящены чек-листам и тому, как с ними работать. И тут просто удивительно, насколько это банальный инструмент, о котором даже писать как-то неловко, и с другой стороны — как мало им пользуются. Смотрите, все просто. Вы собираетесь в отпуск. У вас была проблема когда-нибудь, что вы что-то не взяли и страдали от этого впоследствии? Вы хотели бы не допустить этого в будущем? Сделайте чек-лист в вашей системе заметок “Брать с собой в отпуск” и пополняйте его по мере наступания на грабли. Плюс внедрите себе практикой условный рефлекс: когда наступает событие X, я иду читать чеклист “Что сделать при событии X” (“Не забыть сделать при поступлении CR от заказчика”, “Не забыть описать в документе при добавлении новой фичи”, “Не забыть сделать после устной сессии с ЗЛ”).

Собственно, всё 🤷‍♂️ Подобная проблема встречается, и нередко. На проекте в первый раз вам, вероятно, объяснят, что это нехорошо (а может еще и расскажут описанное выше, если заинтересованы в вас). Если же вы и дальше с этим косячите… Скажем так: именно в силу наличия простых инструментов для решения этой проблемы и банального желания/нежелания подобное внедрить в практику, мне и многим другим аналитикам сложно понять и принять, когда в рабочей среде аналитик продолжает системно совершать ошибки такого плана. Ну и если обобщить до тех пунктов, с которых начинали: многие готовы работать над прокачкой аналитика с уровня X до уровня Y — это вопрос опыта и погружения в профессию; гораздо меньше людей готовы работать с прокачкой софт-скиллов, которые были упомянуты и не только, — это уже вопрос того, готов ли человек сам приложить усилия, чтобы обладать необходимым минимумом для работы в сфере интеллектуального труда. Что интересно, иногда люди банально не понимают, почему их не взяли на ту или иную вакансию (”рынок вообще пуст, 2 года уже ищу работу”) или по факту стажировки на фоне таких явлений, как, например, “забыл ответить интервьюеру в срок”, “сделал задание частично, потому что невнимательно прочитал условие”, “выключил камеру и провел собеседование на фоне шума поезда и за два метра от микрофона”, “в резюме сделал 100500 ошибок” и т. п.

Всем салют!

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

Все мы, кажись, знаем теорию: аналитик должен более-менее разбираться в области, автоматизировать которую нацелено решение. А потому не будем тут жечь красивыми теоретическими выкладками, а рассмотрим на пальцах, чем плохо это игнорировать. Личный опыт: работали кучкой аналитиков над долгоиграющим проектом из незнакомой финансовой области в US. Было это еще, когда динозавры по земле бегали, а все, что было давно — это как правило = “хз, кто такой хороший БА, нет курсов, книг и прочих мест, где можно уяснить, как надо, а потому делаем все по наитию”. И наитие подсказывало нам, что функция БА — выслушать заказчика и передать в разработку ровно то, что он глаголет. Главное, “белый шум” из его уст слушать очень внимательно. Так и поступали, причем в процессе интервью чаще всего не понимали вообще, о чем в плане бизнеса идет речь — в приоритете всегда было знакомые английские слова выделить из кучи полувнятных звуков. В общем, тупо фиксировали за заказчиком формулы и прочие бизнес-правила, не интересуясь, что все это значит. К чему это приводило:

1) Нам повезло с заказчиком и его ЗЛ, и в течение нескольких лет они терпеливо нам объясняли, что именно нужно задевелопить, прекрасно видя при этом, что мы вообще не пытаемся разобраться в бизнес-аспектах. Иной заказчик (особенно учитывая постоянную эволюции БА-области и повышение требований к аналитикам) мог бы и возопить: “Екарный бабай, мы уже это пару лет колбасим — ну разберитесь вы наконец в том языке, на котором я с вами общаюсь!” Т. е. как минимум это показатель вашего профессионализма в контексте общения с клиентом на его языке.

2) Сильно повышенная вероятность ошибок. Если белый шум, зафиксированный на звонке, зафиксировать криво, то понимание области не подскажет вам, что случился фейл. И да, были ситуации, когда после добавления очередной формулы в систему, невербальная реакция клиента была где-то на грани “Вы дебилы, да? Как можно было ТАК это понять?” Приходилось в курилке признавать, что да, мы такие 🤷‍♂️

3) Отсутствие генерации идей/решений от слова “совсем”. Помощи от нас как от людей, которые могут, понимая домен и суть решения, что-то полезное предложить, было где-то чуть меньше нуля. Ну, зато навыки отстраненного протоколирования развили огненно.

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

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

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

- Не упускайте, как мы ранее очерчивали в ошибке #1, изучение AS IS и бизнес-требований — именно тут вы активно погружаетесь в домен на старте.