Как правильно построить процесс взаимодействия между заказчиком и разработчиком?

Как правильно построить процесс взаимодействия между заказчиком и разработчиком?

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

Кто ответственный?

Вспомним момент создания рабочей группы и подготовки материалов — рассматривая этот процесс, мы задекларировали обязательное официальное назначение сотрудника-менеджера проекта со стороны заказчика. Именно этот сотрудник и должен стать «лицом и голосом» компании в процессе разработки сайта. Очень часто заказчик допускает ошибку, проигнорировав этот момент и следствием становится проблема «хвостов» за которые никто не отвечает, а в случае возникновения тех или иных рабочих вопросов со стороны исполнителя — проблема отсутствия человека, который может дать быстрый, четкий и согласованный ответ. В итоге либо процесс разработки приостанавливается до момента получения утверждения со стороны заказчика (а для этого необходимо получить согласие всей рабочей группы), либо исполнитель принимает решение на свой страх и риск, что в последствии грозит несоответствием ожиданиям заказчика и проблемами для самого исполнителя.

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

Как согласовать?

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *