Когда работаю над большой задачей, отправляю первую версию описания требований команде и другим аналитикам с просьбой посмотреть и дать комментарии. Обычно мало надежды на развернутую обратную связь. На нее мало у кого находится время и интерес. Пока "мячик на стороне аналитика" не очень понятно зачем тратить время на какие-то задачи, которые еще не пришли в разработку. Тем не менее есть преимущества от такой траты времени
📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать ☺️
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.
Самопроверка при этом не отменяется, не стоит перекладывать на команду контроль соответствия формату, терминологии и орфографических ошибок.
Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут
Экономия времени на ревью в итоге выглядит поведением скупого, который платит дважды. В работе аналитиков тоже случаются баги и почему бы их не найти пораньше?
