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

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

Все мы сталкиваемся с проблемами и идем к своему руководителю (менеджеру / ведущему аналитику, если вы джун / куратору итд), чтобы получить решение наших проблем. Как обычно это происходит? Приходим, обрисовываем проблему, руководитель слушает и говорит, что нужно делать. Вы рады? Конечно, проблема решена.

Но в долгосрочной перспективе ничего хорошего такой подход не принесет:

Скажу сразу - приоритизировать свои задачи сложно. Я дошла до четких установок про то, как приоритизировать только тогда, когда несколько лет после работы аналитиком поработала Product Owner'ом, менеджером проекта и руководителем отдела.

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

Также вольно можно говорить о приоритетах в любой другой работе, но мне ближе аналитика для примера.

Что такое приоритизация задач? Это сортировка всех задач, которые валятся на аналитика в порядке их важности и сроков выполнения.

Тема про приоритеты в работе очень тесно связана с такими soft skills, как ответственность и самостоятельность. Руководитель отдает вам право принимать решение, как вы управляете собственным временем, и верит, что работа будет сделана в срок и в полном объеме, а если у вас есть вопросы, что важнее, то вы придете к нему заранее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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