255 ступеней

При написании отчета следует понимать: Кому отчет? Зачем? Что на его основании будут делать?

Как правило ЛПР (лицам принимающим решения) требуются ответы на следующие вопросы:
1) Это можно продавать/устанавливать или нужно доработать/выкинуть?
2) Какова степень уверенности?
3) Как называется то, о чем идет речь?

Напишем отчет в виде краткого резюме по текущему состоянию продукта.
——————————————————————–
Продукт СМФ (проект “Банзай”), версия 158/32ф.

Было выполнено 60% тестов из запланированных. Тестирование было прекращено ввиду большого числа ошибок, закрывающих доступ к тестированию.

В настоящий момент полностью неработоспособны 18 из 150 юзкейсов.
Полностью неработоспособны 3 из 45 критически важных юзкейсов.
Работает с оговорками 93 юзкейса.
39 юзкейсов реализованы хорошо.

Я не рекомендую поставку данной версии клиентам. Версия ограничено пригодна для ознакомления с возможностями программы. Оценочное время готовности продукта: декабрь - 30%, февраль - 70%. Полагаю, нам не стоит приурочивать рекламную компанию к рождеству.
Отчет подготовлен 17 сентября сего года лидером тестирования проекта “Банзай” имярек.
——————————————————————–

Повторюсь.
Кому отчет? Зачем? Что на его основании будут делать?

В отчет о тестировании не должны входить метрики, связанные с приоритетами и жизненным циклом ошибок.
Так например метрики :
связанные непосредственно с ошибками (по статусам/приоритетам и т.д.),

скажут что нибудь только тому человеку, который прекрасно понимает процесс. А, например, менеджеру по продажам не скажут ничего. Т.е. вообще ничего.
- У нас в этой версии остались неисправленными 15 важных, 78 маловажных ошибок.
- А сколько должно быть? Вот я слышал, что продукт Х был выпущен с несколькими сотнями тысяч известных неисправленных ошибок. И очень успешный продукт. А тут всего 93. Так выпускаем или нет?

Человек же, который понимает процесс и в нем участвует, должен быть подключен к системе бактрекинга. Должен. Если он управляет процессом, то эту статистику он сам должен просматривать в этой системе с некоторой периодичностью. Не ему должны поставлять такой отчет, а он должен его и сам формировать, и сам просматривать, и сам принимать решения на его основе. Иначе какой же он руководитель?

Метрики
по времени решения/открытия, числу возвратов и т.п.
могут понадобиться для анализа процессов и расшивки узких мест. (при вопиющих просрочках это повод задуматься о лишения премии/увольнении менеджера проекта и/или топ менеджера) [1]. Т.е. действительно, если есть такая практика, то можно формировать отчет, в который войдут:

• процент возвратов,
• среднее время исправления дефектов, с разбивкой по приоритетам,
• и т.д.

и не войдут:

• номер версии и даже название проекта (отчет будет помесячным)
• оценка работоспособности программы

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

В приведенном выше примере отчет говорил не о том, какие есть ошибки, а каково состояние проекта. Поэтому в нем должны быть метрики проекта и не должно быть метрик ошибок. Кроме того, и это самое важное, отчет о тестировании должен содержать не столько данные системы, сколько экспертное мнение специалиста, сформированное на основе этих данных.
Развивая тему дальше.

Мой опыт показывает, что список ошибок включать в отчет бессмысленно, его все равно никто из руководства не читает. Такой список хорош, только если работник не может быть подключен к системе бактрекинга. Например, из-за экономии денег генеральному директору или дизайнеру интерфейсов не купили компьютер . [2]

(с) мой от января 2005

---

[1] В допущенном браке и проблемах с производительностью виноват шеф и  босс (т.к. нанял такого шефа). Смотри например: http://www.ashmanov.com/pap/ashrul2/ (раздел “Закручивание гаек не работает”), или эксперимент с красными бусами Э. Деминга (найти можно здесь: http://www.management.com.ua/qm/qm047-2-6.html)[2] Нечто подобное я имел несчастье наблюдать в одном из проектов.Небольшая экономия денег обернулась необходимостью распечатывать список ошибок и передавать его на бумаге. Со всеми вытекающими.

Это сообщение создано Суббота, Август 22, 2009 в 20:23 в категорию Всё новое. Вы можете подписаться на сообщения RSS 2.0 Вы можете оставить комментарий или послать trackback на это сообщение.