Заказал одно - получил другое: почему команда делает не то, что просишь?

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

Начнем с того, что обычно, так или иначе, есть три звена в работе над задачей:

- бизнес-заказчик (это могут быть и руководители компании и руководители отделов, чьи процессы нужно автоматизировать или включить в свои);

- постановщики задачи в команду (ПО, бизнес-аналитик, ПМ - названия не так и важны, это люди, которые являются точкой входа для заказчика)

- команда разработки.

Основные виды проблем, из-за которых заказчик получает не то, что заказывал

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

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

3. Будем честными, даже если вам дошла качественная постановка задачи, бывают творцы и на стороне разработки, которые на полном серьезе считают, что сделают лучше и правильнее. И потом, когда презентуют результат, очень удивляются, что же не так.

4. Также у любого требования есть разница в понимании между людьми, которые находятся в разных контекстах. Бизнес-заказчик очень хорошо знает предметную область и ему все очевидно, тогда как команда может вообще еще не разбираться в предметной области. Тогда возникает много вопросов и, при плохо выстроенных процессах, выяснение деталей будет постоянно теряться, изменяться или стопориться между тремя группами. Это приводит либо к затягиванию согласований, либо к появлению большого числа расхождений между тем, что хотели бизнес-заказчики, и тем, как их поняли исполнители.

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

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

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

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

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