11 шагов к продуктивной коммуникации с заказчиками в IT

[VitaminND]

1. Сроки — святое

Сразу виден подход с точки зрения менеджера.

А с точки зрения разработчика - сроки можно более-менее точно определить, если есть подробное ТЗ, которое не меняется вообще никак. И то будет плюс-минус. Значит, надо называть в плюс.

А разработать такое ТЗ - очень часто будет по времени больше, чем разработать решение. Но никто не хочет разрабатывать подробное ТЗ, а хотят соблюдение сроков и без запаса по времени.

Я пока не видел действенных способов называть точные сроки, ведь разработчик всегда выполняет уникальные задачи.

[eipanteleev]

Важно уточнить, что я не занимал в IT менеджерской позиции - на протяжении 4-х лет в аналитике данных работаю исполнителем.

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

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

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

Если просто говорить об оценке сроков, то тут обычно есть 2 подхода:

1. Называть сроки с запасом;

2. Брать сроки на предварительное исследование проекта, которое позволит более точно назвать сроки по самому проекту.

[Cordekk]

Я сам аналитик, но с навыками программиста, и могу сказать, что аналитику проще соблюдать договоренности по срокам.

[Praytmen]

А по вроде всё ясно - не говори завтра, если сам понимаешь, что даже после завтра не сможешь сделать. Куда проще.

[Cordekk]

Если понимаете, что не успеваете, предупредите заказчика заранее. Сообщите о переносе, назовите новую дату и причину сдвига. 

это надо держать в уме, это важно, но с учетом дальнейших пунктов. В лоб это не работает.

Письменная коммуникация медленная и часто приводит к недопониманию из-за «домысливания» тона. Устно решите вопрос за 15 минут, а в тикет просто внесите итоговое резюме.

В целом созвоны надо планировать, также как и другие работы, и не созваниваться на 15 минут. У вас это написано так, что если идет недопонимание, надо быстро созвониться. Но быстро не значит продуктивно.

Говорите на понятном языке

Это правильно. А вообще должен быть общий язык - DDD реально работает.

Управляйте ожиданиями

Это в общем-то к срокам в первую очередь относится.

10. Фиксируйте договоренности

Вот это самое важное и надо ставить на первое место.