Сервис – это очень важная часть нашей работы. Технические специалисты зачастую недооценивают эту сторону нашего бизнеса. А между тем клиенту нужен не только наш код, но и сопутствующие услуги + уверенность в том, что все идет как надо.
Большая часть нашей работы незаметна для клиента. Это создание базы данных, исправление ошибок, оптимизация, развертывание, работы на сервере, тестирование, проектирование, создание DAL и BLL. C другой стороны заказчик хорошо видит, как быстро мы выполняем его запросы, он видит ошибки на тестовом сайте, видит недоработки, видит просроченные задачи по дедлайнам и т.д. Учитывая этот момент, мы должны уделять некоторую часть нашей деятельности именно работе с клиентом: написание отчетов, обновление плана, обучение клиента, консультации по различным решениям.
Мы должны четко понимать, что ценит клиент в нашей работе. Зная это и закрывая эти места, мы создаем хороший фундамент для взаимного доверия.
Я бы выделил здесь – следующие моменты:
По поводу отчетности своей работы. Это нужно делать не только для клиента, но и для менеджера проекта.
Мы рассматриваем только удаленный способ работы. Критически важно быть прозрачным для клиента и для менеджера проекта. Они обязательно должны представлять когда и сколько вы работали, что делали, и какие проблемы сейчас есть на проектах.
Для себя мы используем систему учета времени, в которую разработчики вносят время каждый день. Таким образом, мы представляем загрузку каждого разработчика и что конкретно он сделал за это время.
Существуют некоторые более жесткие варианты, когда программистов контролируют посредством периодических скринов с экранов разработчиков. На мой взгляд, эта мера подрывает доверие между менеджером и разработчиком. Главная задача разработчика – постоянно выдавать результат. Если он выдает результат за приемлемое время, то пусть работает так, как ему нравится. Если не выдает, то такой контроль не поможет. Тут нужно либо переобучение, либо замена исполнителя на проекте.
Следующий момент – это отчет по проекту (внутренний и для клиента). Его составляет либо менеджер проекта, либо старший разработчик на проекте. Он должен включать следующую информацию:
Отчеты надо делать не реже недели, чаще можно. Главное, чтобы заинтересованные лица были в курсе.
Важный момент. Если есть проблемы на проекте – сначала обсудите это внутри и только потом можно давать информацию клиенту. Иначе могут быть проблемы с непониманием со стороны клиента.
Также важный элемент сервиса – это общение. Как вы общаетесь с клиентом? Просто переписка или живое общение? Живое общение в большинстве случае более предпочтительнее, т.к. устанавливает более личный контакт с заказчиком + позволяет быстрее решать вопросы по проекту и однозначно понимать, что хочет заказчик. Когда следует переходить на текст? Тогда, когда заказчик начинает садиться на уши, не продуктивно расходуя ваше время. В этом случае мягко дистанцируйтесь от клиента путем переписки (по скайпу или по почте).
Очень важный момент! При возникновении трений и проблем с клиентом ни в коем случае не избегайте клиента.
Лучше начинайте с ним общаться в 2 раза больше, чтобы как можно быстрее устранить проблему. В противном случае избегание клиента приведет в конечном итоге к его потери.
Кстати, насчет клиента. Клиенты бывают разные. Некоторых очень сложных клиентов возможно лучше и «увольнять», но решать это должна компания, а не отдельно взятый программист. Потеря любого клиента – это сотни тысяч рублей недополученной выручки в год для компании. Поэтому ваша задача как разработчика – сделать все, чтобы клиент ни в коем случае даже не задумывался сменить подрядчика на разработку веб приложения. В случае любых проблем с клиентом сразу сообщайте менеджеру проекта. Если считаете, что менеджер неадекватно отреагировал на ваше предупреждение, то смело обращайтесь старшему менеджеру. Это очень критичный вопрос и решать его надо аккуратно и оперативно.
Перейдем к сдаче результата задачи. Давайте наглядное представление клиенту, как выглядит результат работы и как можно его проверить. Используйте скрин + URL. Также делайте пометки об особых случаях. Никогда не пишите много воды. Никому не хочется тратить время на пустые отчеты. Пишите структурировано, коротко и по делу.
Очень важный момент. После выполнения задачи обязательно делайте проверку на сервере. Очень плохо, когда задача вроде бы сделана, но совсем не работает на сервере, где будет смотреть клиент. Еще хуже, если ваша задача привела к тому, что приложение вообще не работает на сервере. Это очень-очень плохой знак для клиента и для менеджера проекта.
В своей системе мы ввели, что при сдаче задачи исполнитель указывает скрин результата на сервере – неявно он хотя бы немного тестирует свою работу на сервере. Еще раз повторяю, вы можете быть очень хорошим и толковым программистом, но если вы систематически допускаете грубые тупые ошибки – это создает определенную ненужную напряженность в проекте.
Напоследок хотелось бы сказать о внутреннем сервисе. Хороший сервис надо оказывать не только клиентам, но и своим коллегам, и подчиненным. Требуйте (но не злоупотребляйте) и от других сервиса по отношению к себе. Повышайте «культуру паса» – помогайте другим разработчикам, решайте сложные вопросы и делитесь с другими своими решениями. Просто используйте изложенные выше принципы применительно к своим коллегам, эффект не будет сразу виден, но результат будет долгосрочный.
В данный момент, моя задача – сделать сервис нашей компании как основу конкурентной стратегии. Хороший сервис для РФ и СНГ – довольно редкая вещь (да и не только в СНГ, но и за рубежом – если говорить о туристическом бизнесе).