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

Классно, когда в компании уже есть механизм оценки требований или оценку ведут архитекторы / PM-ы / PO и прочие люди, которые никак не являются аналитиками. Но у нас в компании не было сложившейся модели оценки, и каждая команда тратила большое количество времени, оценивая запросы клиентов. Тогда нам пришлось разработать собственную схему оценки требований, потратив на это много времени - сначала набирая опыт и проверяя его, затем внедряя и объясняя сотрудникам методику.

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

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

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

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

Сколько раз вы ставили задачу, получали результат, который вас не устраивает, но принимали решение не давать обратную связь, потому что это - выход на конфликт?

И в конце-концов просто говорили "спасибо", и переделывали задачу сами?

Не вижу, но знаю, что вы улыбаетесь - ответ положительный.

Но на длинной перспективе не давать корректирующую обратную связь опасно и не продуктивно:

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

Среди инфосферы аналитиков стали часто появляться статьи при критерии качества работы аналитиков, и там все софт-скиллы так и описываются одной фразой: "оставить хорошее впечатление о себе". Но как можно это сделать, если тебе приходится изо дня в день "приземлять" требования, уточнять миллион деталей и вообще заставлять людей думать. А это, как мы знаем, в принципе никто не любит делать.

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

Привет, Хабр! Меня зовут Мария и я уже три года работаю руководителем отдела в компании, делающий софт. До этого я больше 10 лет работала бизнес‑аналитиком, и сталкивалась по работе как с другими аналитиками, так и с владельцами компаний, в которых работала. В рамках работы руководителем отдела мне приходилось сталкиваться с наймом новых людей, и с разрешением различных конфликтных ситуаций, вызванных действиями (или в рамках этой статьи — проактивными действиями) своих сотрудников. Я поделюсь в этой статье своими впечатлениями о неоднозначном софт‑скилле «проактивность», который так хотят видеть в сотруднике все работодатели. Но только по началу.