Как бизнесу наладить общение с командой разработки. Часть 2

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

Формализация требований
Избегайте ненужных конфликтов за счет формализации требований. Все требования, договоренности и сроки должны быть зафиксированы. Устные договоренности не имеют смысла, если их не фиксировать. Все могут вынести разные вещи из встречи, кто-то забыл, кто-то не услышал. В итоге мы получаем кучу конфликтов на приемке или кучу обманутых ожиданий, которых вообще не должно было быть. Выберите инструмент и фиксируйте все. Проработайте задачу в том виде, как вы бы хотели ее видеть, как пользователь системы, тогда вы сможете ожидать, что получите именно то, что заказали. Иначе, вы получите, что-то, что может быть далеко от ваших ожиданий. Но если они не зафиксированы, то никакой конструктивной критики и работы над ошибками не получится. Будут только конфликты и потеря мотивации. Как хорошо фиксировать требования в задаче на разработку вы можете посмотреть в нашем руководстве по описанию задач.

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

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

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

Заключение
Я общался с многими ПО и понимаю их проблемы: надо и развитие продукта проработать, и бюджеты утвердить, и встретиться с клиентами и пользователями и многое другое. Где тут взять время на команду? Тут нужно понимать, что если вам все же нужна команда, то все, что я написал нужно делать. Не успеваете сами? Наймите человека, который будет работать с командой, расписывать задачи, ходить на встречи, будет все время на связи. На определенном этапе развития проекта брать помощь не просто можно, но и нужно.

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

Максим Шаламов
_____________________

Если у вас есть сложность с организацией работы своей разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.

#советы #бизнесу #agile #управлениекомандой #руководителю