Ежедневно в своей работе я общаюсь с различными людьми — клиентами, разработчиками, QA-специалистами, техническим и нетехническим персоналом на стороне клиентов. Очень важной, а возможно и главной, миссией специалиста в его ежедневной работе является то самое, что на Западе описывается фразой to make customer happy, которая включает в себя достаточно много составляющих, необходимых для достижения успеха. Комфорт клиента при работе с командой играет не последнюю роль в этим списке.

© CCBImages

Анализируя работу проектных команд, а также проводя аудиты проектов и процессов в IT-компаниях, я смог определить для себя список проблем, при которых клиент не чувствует комфорта при работе с командой или разработчиком. Одной из основных проблем, которая заставляет некоторых клиентов отказаться от услуг отечественных разработчиков, — отстутствие качественных моделей общения и репортинга, ожидаемых заказчиком на старте работы.

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

Ответы на вопросы

Очень часто, задав вопрос, клиент получает в ответ фразу, которая мало о чем ему говорит. Являясь человеком, заинтересованным в своем проекте, и пытаясь понять больше, он начинает выяснять детали и переписка затягивается на 10–15 имейлов. В результате поглощено множество полезного времени, на которое были запланированы другие задачи. Решение проблемы, на самом деле, очень простое: закладывайте больше описаний в свой первый ответ, пытайтесь быть максимально простыми в изложении и помните, что не каждый заказчик имеет технический бекграунд и будет в состоянии вас понять.

Качественный репортинг

Клиенты очень любят видеть прогресс как в пределах итерации, так и в пределах отдельно взятой задачи. 10–15 минут работы в день над небольшим отчетом по задачам, которые были сделаны и которые вы планируете сделать в ближайшее время, не станут для вас большой проблемой. Клиент же будет спокоен, видя, что команда работает и обеспечивает определенный результат.

Реакция на проблемы

В случае непредвиденной проблемы, описанной клиентом, получив уведомление о проблеме, разработчик первым делом начинает проверять, что произошло. Сообщает же об этом клиенту, лишь обнаружив проблему, а иногда делает это уже и после того как с ней справился. Здесь заведомо заложен риск того самого некомфортного состояния клиента. Сообщив об ошибке системы, ведущей к некорректной работе, заказчик остается не в курсе того, что происходит. Поэтому первое, что должен сделать человек, получивший оповещение о проблеме, — это сообщить, что уведомление получено и проблема получила соответствующее внимание. В ходе работы над возвращением системы в нормальный режим разработчик должен давать клиенту регулярные короткие отчеты, сохраняя тем самым его спокойствие. Игры «в молчанку» дадут лишь обратный результат.

Управление изменениями

Многие сталкивались с тем, что заказчики часто просят поменять или добавить некоторый функционал, внося тем самым изменения к запланированному списку задач. Всегда стоит помнить, что заказчик почти никогда не видит в этом изменений к заранее намеченному плану. Желание разработчика помочь клиенту, как правило, вызывает множество позитивных эмоций со стороны клиента, но всегда стоит помнить о том, что лучше заранее объяснить почему это передвинет сроки, чем объяснять потом почему запланированный набор задач не был сделан вовремя.

Документация

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

Итог

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