Всем привет. Меня зовут Вика. Я работаю в компании Магнит уже 10 лет. Начинала свой путь в компании я на позиции аналитика, далее стала руководителем сектора аналитики, а после и руководителем команды разработки.

Основную проблему, которую я наблюдаю в затягивающихся задачах:

1. Заказчик, который не понимает, какой эффект он получит от задачи.

2. Аналитики, которые боятся отстаивать свое мнение.

Эти две проблемы еще на этапе начала работы над задачей создают очень много проблем для проектирования и разработки решения.

Сегодня детальнее я бы хотела поговорить о второй проблеме.

Основная задача аналитика в работе моей команды: быть посредником между бизнесом и командой разработки. В этом и состоит сложность, т.к. аналитик должен уметь «разговаривать» на двух языках. Когда аналитик уже опытный, у него есть навык разговора на двух языках, а также он уже сработался с заказчиком и многие требования понимает с полуслова. Но как помочь новым аналитикам ничего не упустить?

На мой взгляд, главной ценностью аналитика является:

• умение задавать правильные вопросы, чтобы определить истинную потребность, и заставить заказчика самого задуматься о необходимости требований

• умение перенести требования в четкий алгоритм действий для достижения поставленной цели.

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

Для своих новых сотрудников я создала список вопросов, которые нужно задать заказчику и команде для синхронизации.

Первая встреча с заказчиком. Какие вопросы задавать

Чтобы качественно перенести потребность бизнеса в реализацию, аналитик должен понимать бизнес-процесс или основную цель, которую хочет достичь заказчик, на всех этапах. Основные вопросы, которые следует задать бизнесу в ответ на требования:

1. Зачем нам нужна эта функция?

2. Как вы будете ее использовать?

3. Для кого мы делаем эту функцию/Кто ее будет использовать?

4. Какие форс-мажорные ситуации бывают и какие стоит заложить?

5. Критерии приемки.

Когда на первой встрече с бизнесом аналитик на каждое требование задает 4 основных вопроса, то процесс и требования будут прозрачными и понятными. Не обязательно задавать вопросы бизнесу, главное – задать их себе. Если требование сформулировано четко и очевиден процесс, то некоторые вопросы можно упустить. Аналитик должен задавать эти вопросы до тех пор, пока он не получит четкий сформулированный ответ. Например, ответ: «Сократятся трудозатраты» не является понятным. Полный ответ должен выглядеть примерно таким образом: «При автоматизации сбора и выгрузки отчетности, сократятся ежедневные трудозатраты специалиста "волшебного" отдела на 3 часа».

Полезный совет: «Как избежать фразы: «Так исторически сложилось»». Если вы разрабатываете масштабный инструмент, который будет жить и использоваться не один год и несколькими подразделениями, описание неочевидного процесса лучше внести в ТЗ в качестве комментария или пояснительной записки. Так вы предотвратите большое количество недопониманий в будущем. Сделайте одолжение себе будущему и всем последователям после вас. Многие вещи со временем теряются и спустя лет пять сложно понять, зачем это было сделано.

Переходим к первой части написания СТ

После первой встречи стоит крупноблочно описать процесс и требования. На этом этапе появляются вопросы:

6. Где мы реализовываем требования?

7. На каком этапе процесса в целом должно быть реализовано данное требование?

8. Какие ограничения для требования?

9. Будет ли данная реализация удобна и интуитивно понятна?

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

Каждое описанное крупноблочно требование стоит проверить по следующим критериям:

1. Полнота

Необходимо убедиться, что учтены все варианты, которые может принимать параметр. Например, что делать, если появляется деление на 0? Если есть деление на какой-то рассчитываемый параметр, то, чисто теоретически, этот параметр может быть нулевым. Это нужно предусмотреть в процессе написания ТЗ. Также, например, при использовании неравенства, должны быть предусмотрены и описаны все варианты значений.  Если у вас описаны случаи, когда один параметр больше или меньше другого, а вариант равенства не описан, то возможна ситуация, когда ваш алгоритм не отработает.

2. Необходимость

Не все требования являются необходимыми. Здесь стоит опираться на четыре вопроса, которые мы задали заказчику на первой встрече. Если заказчик не может объяснить, кому нужно это требование или как он будет это использовать, то возникает вопрос: «Точно ли необходимо это делать?»

3. Правильность

Требование не должно вызывать противоречие со смежными системами и не должно отрицать истины, заложенные в инструмент. Если небо голубое, нельзя требовать, чтобы оно стало красным. При анализе требования по этому критерию, стоит посмотреть на инструмент в целом, а также посмотреть на инструменты, с которыми есть зависимость.

4. Осуществимость.

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

5. Приоритезация.

Если смотреть на идеальную картину, то все требования должны быть приоритизированы. Это очень выручает, если у вас ограниченный срок или бюджет на реализацию задачи. Часть требований будет критичными, без которых невозможна работа инструмента. Без других требований можно обойтись. Имея приоритезацию требований, можно разделить требования на итерации и спланировать работу по выходу релизов.

6. Однозначность.

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

7. Проверяемость.

Любое описанное требование необходимо иметь возможность проверить. Требование: одновременно с инструментом должно работать большое количество пользователей, - не является проверяемым. А вот требование: одновременно с инструментом должны работать 200 пользователей – проверяемое требование.

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

Встреча 2. Задаем уточняющие вопросы

На второй встрече стоит пройтись по всем возникшим вопросам.

Если есть пункты, которые нет возможности реализовать, то должно быть предложено альтернативное решение или указано обоснование, почему невозможно реализовать. Ну не должен аналитик говорить: «Потому что!» в качестве обоснования?

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

По каждому новому требованию необходимо вернуться к вопросам первой встречи и начать новый цикл проверок к каждому требованию.

Формирование итогового СТ

Требования обсудили, ограничения обсудили, на словах заказчика все устраивает. Вносим в СТ и идем к заказчику за согласованием.

Согласование

Согласование требований часто не происходит с первого раза. У меня был случай, когда заказчик отказался согласовывать требования, т.к. у него не было времени, чтобы вникнуть в сложный алгоритм с кучей формул. Бывает и такое.

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

С данным заказчиком мы согласовали алгоритм расчета. Весь алгоритм я изобразила в виде блок-схемы на 1 листке А4. Это более чем устроило заказчика.

Передача в разработку

Перед началом разработки лучше организовать встречу, на которой коротко объяснить разработчику и тестировщику зачем мы это делаем и какой результат хотим получить. Если есть реальные данные или примеры – то вы просто находка!

Дальше идет разработка и взаимодействие с командой разработки, но это совсем другая история…