Ликвидация ошибок в проекте

Ликвидация ошибок в проектеВ процессе работы над проектом неизбежны комментарии и правки со стороны заказчика.

Для исполнителя эти способы можно расположить в таком порядке по убыванию предпочтения:

✔ Специализированная система ведения проекта или баг-треккер. Проблемы и ошибки сопровождаются текстовым пояснением и скриншотами

✔ Электронная почта

✔ Видеосвязь через Skype с отображением экрана

✔ Текстовые сообщения в мессенджерах, такие как ICQ и Skype

✔ Телефон

✔ Личная встреча

Для заказчика этот список, как правило, расположен в противоположном порядке. То есть, для него как раз удобнее, если вы найдёте время приехать к нему в офис и лично увидеть, в чем заключается ошибка. Если этот вариант не удается осуществить, то он может позвонить исполнителю по телефону в удобное для заказчика время.

Почему эти варианты крайне неудобны для исполнителя?

Если человек по любому поводу вынужден ехать к вам в офис, то на основную работу остаётся значительно меньше времени. Более того, за то время, пока исполнитель едет к вам в офис и обратно, он мог бы исправить ошибку, находясь на своем рабочем месте. Что вы получаете в итоге? Затягивание сроков проекта.

Телефонные звонки тоже сложно назвать самым эффективным способом сообщить о списке ошибок. Причин тут несколько:

✔ Слушая вас по телефону, разработчику надо успеть записать куда-то себе в блокнот суть ошибки. Это отвлекает от собственно вникания в суть проблемы. Т. к. если он не успеет записать, то о проблеме вообще потом не вспомнит. Это особенно актуально ввиду того, что иногда список таких правок в аудио формате может быть весьма внушительным.

✔ Далеко не все программисты – аудиалы. В основном у них развит визуальный способ восприятия информации

✔ Техническую информацию сложно воспринимать на слух практически всем

✔ В момент звонка разработчик может находиться не у компьютера, а то и вовсе в неудобном дла разговора месте, например, в метро или общественном транспорте.

Вот основные требования к отчетам об ошибках:

✔ Все ошибки должны быть максимально подробно задокументированы: при каких условиях возникает, как выглядит

✔ Ошибка должна быть учтена в каком-то списке в письменном виде, иначе про неё неизбежно забудут.

✔ Описание ошибки должно быть воспроизводимым в своем исходном виде, чтобы его можно было перечитать несколько раз. Это связано не с тем, что ваш исполнитель феноменально непонятлив. Просто ошибку далеко не всегда можно воспроизвести и значение может иметь любая мелочь.

✔ Список ошибок можно перечитывать несколько раз и вычеркивать исправленные ошибки.

✔ Под эти требования наилучшим образом подходят системы ведения проектов и контроля ошибок, такие как ActiveCollab, FengOffice, BaseCamp, Mantis, Bugzilla, Trac. Спросите, в какой из указанных систем предпочитает работать ваш разработчик. Наверняка у него одна из них уже установлена на сервере.

Если вы категорически не хотите работать ни в одной из этих систем, есть смысл использовать обычную электронную почту, составлять подробный список ошибок при тестировании и требовать от разработчика отчета об их исполнении. Да, вам не послышалось. Теперь, когда вы все правильно задокументировали, вы можете требовать отчет уже со стороны разработчика, а не мямлить “А помните я вам звонил по телефону месяц назад, вы тогда ехали в метро и вас плохо было слышно? Вам удалось исправить те ошибки, о которых я вам говорил? Какие именно? Да я уже и сам не помню.”

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