Архив за Август, 2009

Пример отчета по тестированию

Суббота, Август 22nd, 2009

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

Как правило ЛПР (лицам принимающим решения) требуются ответы на следующие вопросы:
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] Нечто подобное я имел несчастье наблюдать в одном из проектов.Небольшая экономия денег обернулась необходимостью распечатывать список ошибок и передавать его на бумаге. Со всеми вытекающими.

Вторичные эффекты материальной стимуляции

Суббота, Август 22nd, 2009

Иногда мне валится спам вот с такими “многообещающими” заголовками: “За что платить зарплату сотрудникам: практикум управленческих решений” или “Зарплатные схемы, поощряющие активных сотрудников и вымывающие лентяев“.  Читаешь и думаешь: “А ведь это кто-то применять будет”. И всех последствий не учтет. А последствия могут быть самыми неожиданными.

Пример 1. Вот, например, пересматривая старый добрый советский фильм “Деревенский детектив”: http://rutube.ru/tracks/2272116.html?v=d37f45ed8e4587f0cc3c992a399fb8d0

Фактический  результат совсем не соответствует запланированному. А подумать перед внедрением? Минут десять?

Пример 2. В некой  фирме решили сделать месячную премию зависимой от  завершения проекта. Завершен проект в отчетном месяце - есть премия, не завершил (проект трехмесячный) - нет премии. Как вы, наверное, догадываетесь, все проекты вдруг стали одномесячными или меньше. У многомесячного проекта не было даже шанса начаться. Его или неоправданно били на кучу частей, резко удлиняя срок, или отфутболивали методом изобретательных итальянцев. Естественно, зачем делать полезный для фирмы проект, но лишать себя премии, когда можно сделать бесполезный и премию получить. Логично?

Пример 3. В некой  фирме решили выбирать лучший отдел и вручать ему месячную премию. Для определенности зададим структуру фирмы.

  • Есть несколько отделов разработки ПО.
  • Есть отдел технических писателей
  • Есть отдел маркетинга
  • Есть юротдел
  • Есть отдел дизайна
  • Есть отдел системного администрирования (а куда ж без него)
  • Ну, и пусть будет отдел тестирования
  • Есть еще отделы, но они не участвуют в проектах

Над каждым проектом работает 2 и более отделов. Как правило 4-5.
Кстати, вопрос к знатокам стимуляции и мотивации. Каковы будут вторичные эффекты такой месячной премии?

Ревью семинара «Управление производством на основании численных данных» и «Теория ограничений и линейное программирование»

Понедельник, Август 10th, 2009

В прошлый понедельник, 3 августа произошло замечательное событие. Стас Фомин нашел ошибку в решении Голдатта. (Задача на оптимизацию производства в разных вариантах)
Как говорит сам Голдратт, он давал эту задачу тысячам менеджерам и только один из сотни мог решить ее правильно.

Ошибка найдена в последнем варианте задачи. Что еще интересно, Стас показал, что в N-продуктовом производстве число ограничений меньше или равно N. В отсутствии девиаций и возможности абсолютно точных измерений, это действительно так.

Отчет, видео: http://team.custis.ru/2009/08/blog-post_06.html.

Мои искренние поздравления Стасу.