«Недокоммуникация» как один из признаков украинского аутсорсинга
Ежедневно в своей работе я общаюсь с различными людьми — клиентами, разработчиками, QA-специалистами, техническим и нетехническим персоналом на стороне клиентов. Очень важной, а возможно и главной, миссией специалиста в его ежедневной работе является то самое, что на Западе описывается фразой to make customer happy, которая включает в себя достаточно много составляющих, необходимых для достижения успеха. Комфорт клиента при работе с командой играет не последнюю роль в этим списке.
© CCBImages
Анализируя работу проектных команд, а также проводя аудиты проектов и процессов в IT-компаниях, я смог определить для себя список проблем, при которых клиент не чувствует комфорта при работе с командой или разработчиком. Одной из основных проблем, которая заставляет некоторых клиентов отказаться от услуг отечественных разработчиков, — отстутствие качественных моделей общения и репортинга, ожидаемых заказчиком на старте работы.
В данной статье я бы хотел провести анализ основных проблемных направлений в общении между заказчиком и инженерами, что в дальнейшем может пригодиться некоторым из читателей для ретроспектив в своей работе. Я попытался выделить пять наиболее весомых причин, по которым клиент может чувствовать себя некомфортно в общении с разработчиком.
Ответы на вопросы
Очень часто, задав вопрос, клиент получает в ответ фразу, которая мало о чем ему говорит. Являясь человеком, заинтересованным в своем проекте, и пытаясь понять больше, он начинает выяснять детали и переписка затягивается на 10–15 имейлов. В результате поглощено множество полезного времени, на которое были запланированы другие задачи. Решение проблемы, на самом деле, очень простое: закладывайте больше описаний в свой первый ответ, пытайтесь быть максимально простыми в изложении и помните, что не каждый заказчик имеет технический бекграунд и будет в состоянии вас понять.
Качественный репортинг
Клиенты очень любят видеть прогресс как в пределах итерации, так и в пределах отдельно взятой задачи. 10–15 минут работы в день над небольшим отчетом по задачам, которые были сделаны и которые вы планируете сделать в ближайшее время, не станут для вас большой проблемой. Клиент же будет спокоен, видя, что команда работает и обеспечивает определенный результат.
Реакция на проблемы
В случае непредвиденной проблемы, описанной клиентом, получив уведомление о проблеме, разработчик первым делом начинает проверять, что произошло. Сообщает же об этом клиенту, лишь обнаружив проблему, а иногда делает это уже и после того как с ней справился. Здесь заведомо заложен риск того самого некомфортного состояния клиента. Сообщив об ошибке системы, ведущей к некорректной работе, заказчик остается не в курсе того, что происходит. Поэтому первое, что должен сделать человек, получивший оповещение о проблеме, — это сообщить, что уведомление получено и проблема получила соответствующее внимание. В ходе работы над возвращением системы в нормальный режим разработчик должен давать клиенту регулярные короткие отчеты, сохраняя тем самым его спокойствие. Игры «в молчанку» дадут лишь обратный результат.
Управление изменениями
Многие сталкивались с тем, что заказчики часто просят поменять или добавить некоторый функционал, внося тем самым изменения к запланированному списку задач. Всегда стоит помнить, что заказчик почти никогда не видит в этом изменений к заранее намеченному плану. Желание разработчика помочь клиенту, как правило, вызывает множество позитивных эмоций со стороны клиента, но всегда стоит помнить о том, что лучше заранее объяснить почему это передвинет сроки, чем объяснять потом почему запланированный набор задач не был сделан вовремя.
Документация
Достаточно противоречивый с точки зрения разработчиков, но очень важный пункт, на который обращает внимание заказчик. Будь то спецификация, техническая документация, пользовательская инструкция или даже комментарии кода — это то, что часто показывает отлаженный уровень процессов на проекте и, с его точки зрения внешних консультантов, уровень разработчиков. Стоит помнить, что не все заказчики понимают важность красивого кода, покрытого тестами. В случае отсутствия документации во время ревью проекта внешними консультантами это будет отмечено как проблема, которая должна быть исправлена. Решение проблемы более чем простое — писать и обновлять эту документацию, добавляя необходимое время к задачам или вынести это как отдельную задачу в итерациях.
Итог
Многие команды и разработчики учли это в своих процессах, многие считают эти и другие пункты важными для будущего улучшения процессов, некоторые не видят в этом смысла. Как использовать эти советы и использовать ли их — сугубо личное дело каждого, но главное к чему мы все должны стремиться — это делать завтра лучше, чем сегодня, в том числе и в работе над проектами и в общении с теми, от кого эти проекты зависят.
Алексей Кривицкий
Ljt
Mykola Gurov
Rodion Bykov
anonymous
Sergii Voloshyn
Kyryl Bilokurov
Beaver Green
undefined pointer
Нестор Иванович
Sergey Bushnyak
Jack Spektor
Sergey Bushnyak
Sergey Prokhorenko
Vasyl K
Jack Spektor
Sergii Maliarov
Oleg Artyomov
Taras Panasyuk
Kostiantyn Kudriavtsev
Sergii Maliarov
Нестор Иванович
Igor Skokov
Armen Polischuk
Rodion Bykov
51 комментарий
Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.