Карьера в IT. Системный аналитик, часть 5. Сбор требований⁠⁠

Всем привет.

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

Для этого придумали и сформулировали не мало методологий - давайте в них разберемся.

Интервьюирование

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

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

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

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

Это что касается теории. Однако на практике - в большинстве случаев это уже устарело, потому что у вас, почти всегда, будет ровно одна точка входа в бизнес-требования в виде PO или просто выделенного человека, достаточно высокой должности (уровня зам или руководителя определенного направления компании), которые сами ответят вам на все вопросы, без привлечения толпы лиц. И именно этот человек будет тем самым рупором, через который идет трансляция целей бизнеса на команду разработки.

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

Пара важных моментов:

1. Всегда готовьтесь к интервью. Я не знаю почему, но даже опытные аналитики это не всегда делают, к моему сожалению. Не должно быть такого, что вы приходите на встречу, вам предлагают начать диалог и задавать вопросы, а вы такой: "Ой, да я даже не знаю, давайте вы расскажете просто что вам нужно". Очень желательно, заранее подготовить список вопросов или просто понять концепцию разговора, т.к. именно вы должны быть его драйвером.

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

Прототипирование

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

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

Прототип может быть:

• Статическим, показывающим положение элементов в интерфейсе или структуры данных;

• Динамическим - с возможностью демонстрации поведения системы по наступлению определенных событий;

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

Но у такого подхода есть и ряд минусов:

• Сильно увеличивает трудозатраты, особенно если не удастся переиспользовать интерфейс для экономии времени разработки, т.к. стоит понимать, что сам процесс прототипирования отнимает достаточно большое количество времени, если это не на салфетке на встрече нарисованный макет интерфейса;

• Заказчики могут акцентировать фокус своего внимания на красоту и дизайн прототипа их системы вместо обсуждения действительно важных вопросов реализации. Поэтому важно постоянно уводить нить их рассуждения от "Блин, тут кнопка не в наших корпоративных цветах, надо это поправить", к обсуждению того, как эта кнопка должна работать и что должно происходить по ее нажатию.

Анализ документации

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

Данный подход выполняет сразу несколько целей:

• Сократит время последующего анализа потребностей и проблем заказчика. Кроме этого облегчит взаимодействие с заказчиком и другими членами команды разработки, т.к. вы больше вникните в процесс и будете разговаривать на одном языке;

• Возможно вы сможете получить ту информацию, которой уже (или еще) из представителей заказчика не обладает.

Для начала требуется определить с какой документацией необходимо и желательно работать. Это можно сделать у представителя заказчика, который может предоставить нам список необходимой “литературы”, релевантной относительно текущих процессов. Либо, если вам предоставили доступ к каким-либо информационным ресурсам заказчика - поискать такие документы самостоятельно.

Мозговой штурм

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

Такой формат не позволит вам выбрать что-то наилучшее или оптимальное, однако позволит по накопившимся идеям получить быструю обратную связь, отследить реакцию заказчика на них, выбрать несколько наиболее подходящих и далее “копать” в том направлении, развивая эти идеи.

Перед тем как проводить такой штурм, в любом случае требуется определить цель. Без чёткой цели идеи будут предлагаться уж совсем несуразные. Возможно, вам будет весело, но вот продуктивно ли? Сомневаюсь.

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

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

Анализ конкурентных продуктов

Кроме всех вышеперечисленных способов - можно применить еще один, достаточно интересный. Если вы не разрабатываете что-то совсем новое и уникальное, не делаете “rocket science”, то скорее всего у вашего продукта или системы уже есть аналоги. И очень не глупой идеей будет проанализировать их, посмотреть на отзывы пользователей, самому попользоваться данной системой (если это возможно) и сделать на основании этого выводы о преимуществах и недостатках данного продукта.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.S. Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.