Мой первый рабочий день в аналитике выглядел так: доступы, несколько задач в Jira по паре предложений каждая - и все. Изучить сам продукт, местный Confluence и то, как здесь принято описывать требования, предлагалось по ходу дела. Разобралась. Но потратила на это месяцы вместо недель. Теперь, оглядываясь назад, вижу, что дело было не в сложности продукта, а в отсутствии выстроенного процесса.

Я - Ирина, бизнес/системный аналитик. Начинаю здесь личный блог и первым постом выкладываю тот самый чек-лист, которого мне тогда не хватило.

🤔Так что же такое грамотный онбординг аналитика?

1. Человек, которому можно задать глупый вопрос.

Не “спрашивай, если что”, а конкретный человек, который знает, что он наставник, и согласен им быть. Иначе новичок два дня гуглит то, что объясняется за пять минут.

2. Разрешение не брать сложные задачи в первые недели.

Аналитик, который пишет требования к системе, которую еще не понимает, создает работу, а не закрывает ее. Дешевле дать время на старте, чем переделывать потом.

3. Не вся база знаний, а пять основных ссылок.

“Вот наше пространство в Confluence” - это не онбординг. Онбординг - это “начни с этих пяти статей, вот эти разделы устарели, остальное изучишь по мере надобности”.

4. Один актуальный шаблон документа требований.

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

5. Договоренность о том, что считается готовой постановкой.

Кто ревьюит, по каким критериям, сколько это занимает. Без этого “готово” у каждого свое.

6. Правило для задач в бэклоге.

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

7. Формат дейли, за которым кто-то следит.

Полтора часа с подробным пересказом вчерашнего дня - это не синхронизация. Строгие временные рамки и лимит в три вопроса решают проблему полностью. Если ничего из перечисленного в вашем онбординге нет, новичок, как ни крути, потратит на самостоятельную адаптацию немало оплачиваемого(!) времени.

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

Дальше в блоге будет то же самое, но глубже: разборы своих постановок, User Story, схем интеграций и разборы собственных ошибок, без морали в конце.

❔А теперь вопрос к вам: чего не хватило в онбординге лично вам? У меня ощущение, что пункт про “пять ссылок вместо всей базы” пропускают вообще все.

Открыта к предложениям, если вашей команде нужен сильный аналитик.

#системныйаналитик #бизнесаналитик #онбординг #ITкоманда #требования