Важно построить хорошие отношения не только с заказчиком, но и с командой. Без этого не будет ни успешного продукта, ни радости от работы. Ключевое здесь — «построить», нужно прикладывать определенные усилия, которые будут вести к здоровым отношениям в команде.
Важно построить хорошие отношения не только с заказчиком, но и с командой. Без этого не будет ни успешного продукта, ни радости от работы. Ключевое здесь — «построить», нужно прикладывать определенные усилия, которые будут вести к здоровым отношениям в команде.
Кто пишет: Елена Горопека, в IT-индустрии 10 лет; начинала с тестирования ПО, затем перешла в бизнес-анализ и продукт-менеджмент. Ведёт канал «О бизнес-анализе и не только», где пишет об управлении продуктами, проектами и людьми.
Есть разработчики, которые любят обсуждать и придумывать фичи, всегда предлагают улучшения и идеи для продукта. Есть инженеры, которым всё равно, что кодить, главное иметь четкие и понятные требования.
Думаю, очевидно, к кому стоит иди с вопросом: «А как ты думаешь, как в нашей системе запилить вот это?», а кто будет демотивирован от постоянного отвлечения от кодинга.
Может быть ваш QA-инженер мечтает перейти в бизнес-анализ со временем? Так берите его с собой на некоторые миты, дайте потренироваться описывать стори или проверить качество ваших же требований. И вам профит, и коллега замотивирован перформить на проекте.
Часто у инженеров есть интерес поработать с конкретной технологией, а фронтенд-разработчик хочет переходить в бэкенд. Дерзкий iOS-ник может очень трепетно относиться к UI приложения — так пусть сам с дизайнером и выбирает, какие анимашки использовать. Учтите это при распределении задач — и мотивация пойдет вверх.
Думаю, это одна из отличительных черт хорошего менеджера — уметь понять про каждого, что его мотивирует, и найти ему именно такой фронт работы.
Почему-то бизнес-аналитики часто забывают, что команде неоткуда взять контекст проекта, если им его не рассказать. Это вам кажется, что всё очевидно и логично, а для них часто складывается ощущение, что у продукта нет никакого роудмапа и стратегии.
А это важно знать и для психологического комфорта (чувство определенности, чувство цели, вот это вот всё), и для каждодневных решений по архитектуре и имплементации. Так что каждый спринт-планнинг логично начинать с краткого овервью: какой у нас средне- / долгосрочный план, укладываемся ли мы в сроки, есть ли важные изменения, какие в целом настроения у заказчика. И уже после этого планировать ближайший спринт.
Привлекайте команду для придумывания решений на рефайнементе. Так вы и решение лучше найдете, и повысите вовлеченность ребят.
Часто бизнес-аналитики не рассказывают на дейликах о своей работе. В результате у команды складывается ощущение, что БА ничего не делает. Отсюда завышенные ожидания к требованиям: «почему не прописаны все-все детали», «мне неудобно читать в таблице, переделай формат в 10й раз».
А если на каждом дейлике вы будете кратко, но четко говорить, чем вы занимались и чем планируете, у команды будет понимание вашей зоны ответственности. И что она заключается не только в написанных требованиях, но еще в куче времени на подумать, проанализировать, приоритизировать, написать столько-то сторей, согласовать столько-то решений.
Особенно важно это делать, когда у вас объективно сложный заказчик и стейкхолдеры. Команда должна понимать, что вы очень много времени и нервов тратите на менеджмент стейкхолдеров, и ограждаете их от этого веселья. В таком случае коллеги будут намного спокойней относится к косякам в требованиях, а то и помогать вам, если нужно.
От всяких лишних митингов, где инженеры нужны «для галочки». От нереальных дедлайнов и бесконечных переработок. От писем заказчика «срочно сделай вот это, плевать на спринт». От необходимости шантажом и ультиматумами выбивать время на улучшения архитектуры и решения техдолга.
Если хотите, чтобы команда быстро и качественно работала, — создайте условия для этого.
А как вы строите отношения с командой? Делитесь лайфхаками в комментариях!
Мнение авторов блогов может не отражать позицию редакции.
Вы потратили на этот материал две минуты. Потратьте ещё 15 секунд, пожалуйста.
dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз.
Но мы справляемся — с вашей помощью. Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 170 читателей поддерживают нас донатами.
В 2023 году мы хотим собрать 1000 читателей-подписчиков. Помочь нам можно через Patreon. Сейчас средний чек — около 10$, но мы рады любой сумме. В Беларуси Patreon заблокирован. Мы будем добавлять другие способы. Спасибо, что прочитали это сообщение.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Что-то дальше не очень хочется читать. Какя-то каша. Но я попробую.
<Время спустя>
Попробовал. И даже до конца дочитал. Очень тяжело читать из за странной лексики. Читаешь вроде русское слово, но чтобы понять что оно значит надо сообразить что это таким образом использованное английское и только потом становиться понятно.
Ну... на в кус и цвет как говориться. Но такого рода жаргон не выглядит профессионально. Ведь не сложно переключить раскладку и использовать оригинал если уж не знаете русского близкого аналога (что нормально когда начинаешь употреблять термин впервые на иностранном языке)
Пользователь отредактировал комментарий 28 марта 2023, 15:18