В процессе работы над проектом неизбежны комментарии и правки со стороны заказчика.
Для исполнителя эти способы можно расположить в таком порядке по убыванию предпочтения:
✔ Специализированная система ведения проекта или баг-треккер. Проблемы и ошибки сопровождаются текстовым пояснением и скриншотами
✔ Электронная почта
✔ Видеосвязь через Skype с отображением экрана
✔ Текстовые сообщения в мессенджерах, такие как ICQ и Skype
✔ Телефон
✔ Личная встреча
Для заказчика этот список, как правило, расположен в противоположном порядке. То есть, для него как раз удобнее, если вы найдёте время приехать к нему в офис и лично увидеть, в чем заключается ошибка. Если этот вариант не удается осуществить, то он может позвонить исполнителю по телефону в удобное для заказчика время.
Почему эти варианты крайне неудобны для исполнителя?
Если человек по любому поводу вынужден ехать к вам в офис, то на основную работу остаётся значительно меньше времени. Более того, за то время, пока исполнитель едет к вам в офис и обратно, он мог бы исправить ошибку, находясь на своем рабочем месте. Что вы получаете в итоге? Затягивание сроков проекта.
Телефонные звонки тоже сложно назвать самым эффективным способом сообщить о списке ошибок. Причин тут несколько:
✔ Слушая вас по телефону, разработчику надо успеть записать куда-то себе в блокнот суть ошибки. Это отвлекает от собственно вникания в суть проблемы. Т. к. если он не успеет записать, то о проблеме вообще потом не вспомнит. Это особенно актуально ввиду того, что иногда список таких правок в аудио формате может быть весьма внушительным.
✔ Далеко не все программисты – аудиалы. В основном у них развит визуальный способ восприятия информации
✔ Техническую информацию сложно воспринимать на слух практически всем
✔ В момент звонка разработчик может находиться не у компьютера, а то и вовсе в неудобном дла разговора месте, например, в метро или общественном транспорте.
Вот основные требования к отчетам об ошибках:
✔ Все ошибки должны быть максимально подробно задокументированы: при каких условиях возникает, как выглядит
✔ Ошибка должна быть учтена в каком-то списке в письменном виде, иначе про неё неизбежно забудут.
✔ Описание ошибки должно быть воспроизводимым в своем исходном виде, чтобы его можно было перечитать несколько раз. Это связано не с тем, что ваш исполнитель феноменально непонятлив. Просто ошибку далеко не всегда можно воспроизвести и значение может иметь любая мелочь.
✔ Список ошибок можно перечитывать несколько раз и вычеркивать исправленные ошибки.
✔ Под эти требования наилучшим образом подходят системы ведения проектов и контроля ошибок, такие как ActiveCollab, FengOffice, BaseCamp, Mantis, Bugzilla, Trac. Спросите, в какой из указанных систем предпочитает работать ваш разработчик. Наверняка у него одна из них уже установлена на сервере.
Если вы категорически не хотите работать ни в одной из этих систем, есть смысл использовать обычную электронную почту, составлять подробный список ошибок при тестировании и требовать от разработчика отчета об их исполнении. Да, вам не послышалось. Теперь, когда вы все правильно задокументировали, вы можете требовать отчет уже со стороны разработчика, а не мямлить “А помните я вам звонил по телефону месяц назад, вы тогда ехали в метро и вас плохо было слышно? Вам удалось исправить те ошибки, о которых я вам говорил? Какие именно? Да я уже и сам не помню.”