Привет, Хабр! Меня зовут Мария и я уже три года работаю руководителем отдела в компании, делающий софт. До этого я больше 10 лет работала бизнес-аналитиком, и сталкивалась по работе как с другими аналитиками, так и с владельцами компаний, в которых работала. В рамках работы руководителем отдела мне приходилось сталкиваться с наймом новых людей, и с разрешением различных конфликтных ситуаций, вызванных действиями (или в рамках этой статьи — проактивными действиями) своих сотрудников. Я поделюсь в этой статье своими впечатлениями о неоднозначном софт‑скилле «проактивность», который так хотят видеть в сотруднике все работодатели. Но только по началу.
Небольшой поиск термина сразу же дает понять, что это такое - тут и принятие ответственности, и инициативность в предложении решений, и приложение максимума усилий, чтобы добиться желаемого. Все самое хорошее, и, если не учитывать подводные камни в реальной работе в компании, именно то, что нужно, чтобы продвигаться по карьерной лестнице.
Вот о подводных камнях и хочется поговорить.
Давайте посмотрим на примере.
Вася работает полгода аналитиком в команде, делающий проект заказной разработки. Процесс в команде простой - аналитик формализует требования и передает их архитектору. Затем они распределяются на разработчиков, и затем после реализации уходят в тестирование. Потом архитектор раз в 2 недели собирает выпуск и вся работа передается заказчику. Васин стаж работы не большой, он прошел недавно некоторые курсы по процессам работы в команде, и видит, что можно добавить шаг тестирования аналитиком перед передачей в основное тестирование, чтобы удостовериться, что бизнес-смысл требования соблюден. И Вася на одной из ретроспектив проактивно говорит, что это правильно и нужно сделать, и он готов прямо с завтрашнего дня ввести дополнительный статус в таск-трекере и заняться этим самостоятельно.
Все выглядит очень красиво, проактивно, любо-дорого посмотреть. В чем же может быть проблема?
Проактивность - это не только про предложение новых решений или изменение старых. В проекте это в первую очередь про влияние на одну из сторон проектного треугольника - сроков, бюджета и содержания. Любое изменение в проекте должно быть на что-то из этого направлено. Итак, о чем стоило подумать прежде, чем предлагать изменения:
На решения какой проблемы в проекте направлено предложение? Есть ли вообще проблема в проекте?
Например, после выпуска в продуктив Заказчик часто присылает замечания к реализации, и явно высказывает недовольство: "Это не то, что мы хотели". Тогда тестирование аналитиком, который общался с Заказчиком и понимает его бизнес, позволит на этапе разработки сразу же скорректировать реализацию и сократит трудозатраты на переделку в следующем релизе. Тогда трудозатраты на дополнительную работу аналитика в релизе окупятся (я бы сказала, перераспределятся - больше работы в конце релиза, меньше работы по ответам на недовольные письма в начале релиза). Плюсом будет еще повышение удовлетворенности Заказчика, а это немалого стоит.
Если простыми словами: работа участника команды - это часы, за которые платит компания. Меньше затраченных часов - больше прибыль от проекта (ну, в общем случае). Если возможно повлиять на количество переделок, то вы принесете компании пользу.
Проблемы могут быть любыми, но критерии успешности проекта практически всегда одинаковые.
Можно ли менять процессы в одном взятом проекте?
Очень часто процессы в проекте стандартизированы среди всех команд. Это сделано для того, чтобы сократить трудозатраты на погружение новых людей (и тут я не говорю о новичках в компании) в проект из других проектов. Стандартизация позволяет сразу определить понятный всем круг обязанностей сотрудников в проектах и не тратить время (=трудозатраты проекта) на обучение тому, как тут у вас все устроено.
Тут опять все упрется в сроки и трудозатраты.
Желание одного взятого аналитика "сделать правильно"
Самый сложный пункт, требующий от аналитика самоанализа. Хорошие аналитики, которые любят "разложить все по полочкам", эмоционально очень сильно страдают от непоследовательности и хаоса, происходящего в проектах. И стресс от отсутствия процессов (либо не работающих процессов) ведет к тому, что аналитики начинают предлагать изменить процессы и подходы.
Я много сталкивалась с такими аналитиками, и часто желание поменять что-то выливается в идею фикс. Но что происходит дальше? Аналитик предлагает изменение, менеджер проекта или руководитель отдела к нему не прислушивается или на пальцах не объясняет, почему это не нужно, и аналитик через полгода уходит из компании со словами "меня не слышат".
Тут вина двух сторон - аналитика и менеджера/ руководителя отдела.
Аналитику нужно очень четко понимать, что любое изменение процессов - это трудозатраты и срыв сроков по обязательствам в проекте. И без обоснования никто не будет менять ничего, если какой-то там аналитик сказал, что так "будет правильно". Почему вы решили, что это правильно? Почему именно так, а не по-другому будет правильно? Надо быть готовым не быть идеалистом, а защищать свои идеи. Лучше всего, если вы такие решения предлагаете и обсуждаете с командой. И, возможно, не один раз. И даже возможно, что идея, предлагаемая вами, перерастет после обсуждения команды во что-то еще. Не думайте, что вы только один такой умный, команда предлагает интересные идеи, к которым нужно быть открытым (это к вопросу о мозговом штурме на ретроспективе).
А менеджеру/ руководителю отдела нужно уметь не отмахиваться от идей сотрудников. И не зарубать их на корню, а выяснять причины и источники этих идей, потому что у аналитика может не быть полного видения картины проекта или процессов. Можно указать аналитику на путь, куда двигаться с идеей - как я уже говорила ранее: обсудить с командой, подумать над проблематикой в проекте.
Кого затронут изменения? Кто будет курировать изменения?
Практическая сторона дела. Вы просите что-то поменять, но кого затронут эти изменения, только аналитика или кого-то еще в команде? Кто будет контролировать, что эти изменения и договоренности соблюдаются? Какие критерии соблюдения договоренностей?
Очень классно вкинуть идею. Но вам нужно подумать над тем, как вы (или кто-то другой) потом измерит успех этой идеи. Может быть, в теории все выглядело прекрасно, но на практике не удобно.
Все эти вопросы требуют обсуждения - возможно, на ретроспективе с командой.
И главное - не нужно нудеть. Если какая-то идея "не прошла", не нужно каждую неделю напоминать всем, что в проекте есть проблемы, и вы предлагали идею по достижению прекрасного будущего, а вас не услышали. Тут уж либо идея была плохая (смиритесь), либо вы недостаточно обосновали ее необходимость (смотри вопросы по пунктам выше). Можно подумать еще, поговорить с менеджером проекта или руководителем, поштурмить с командой. Если проблемы есть, в любом случае их придется решать, и ваши озвученные идеи могут помочь найти оптимальное решение.
