О матрице взаимных ожиданий.

Expect the unexpected

Частая проблема — сотрудники отдела убеждены, что коллеги из соседнего отдела не делают то, что от них требуется. Сотрудники соседнего отдела, в свою очередь, понятия не имеют, что от них требуется именно это. Болезнь особенно характерна для крупных компаний. Для диагностики проблемы руководителю (особенно, если они пришёл «снаружи») надлежит составить следующую таблицу:

Ожидания разработки Ожидания тестирования Ожидания внедрения
Обязательства разработки Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства тестирования Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Сами Сало:
Теему Селянне:
Олли Йокинен:
Обязательства внедрения Яркко Иммонен:
Петри Контиола:
Лаури Корпико:
Олли Мяяття:
Осси Вяанянен:
Лассе Кукконен:

 
В примере три отдела — разработка, тестирование, внедрение. В каждом работает по три сотрудника:
Разработка: Яркко Иммонен, Петри Контиола, Лаури Корпико.
Тестирование: Олли Мяяття, Осси Вяанянен, Ласси Кукконен.
Внедрение: Сами Сало, Теему Селянне, Олли Йокинен.
 
Таблица расшаривается на всю компанию. Это важный момент — заполнить её должны не только руководители подразделений, но и сотрудники. Каждый сотрудник пишет, что именно он ожидает от других отделов.
 
 
После заполнения может получиться следующее:

Ожидания разработки Ожидания тестирования Ожидания внедрения
Обязательства разработки Олли Мяяття:
Основной поток должен работать без ошибок на компьютере разработчика.

Осси Вяанянен:
Передаваемый код должен быть покрыт модульными тестами.

Лассе Кукконен:
Передаваемый код должен содержать комментарии.
Сами Сало:
Соблюдение сроков разработки, предоставление пояснительной записки.

Теему Селянне:
Быстрое исправление дефектов, обнаруженных заказчиком.

Олли Йокинен:
Умение проводить доработки, взаимодействуя с внедренцем напрямую.

Обязательства тестирования Яркко Иммонен:
Своевременное предоставление тестовых планов.

Петри Контиола:
Участие в выработке варианта реализации.


Лаури Корпико:
Своевременно давать фидбек по протестированной доработке.
Сами Сало:
Передавать только доработки, не содержащие дефектов.

Теему Селянне:
Не затягивать тестирование.

Олли Йокинен:
Умение быстро выявлять причины дефектов, найденных заказчиком.

Обязательства внедрения Яркко Иммонен:
Предоставление грамотных ТЗ.


Петри Контиола:
Своевременные ответы на вопросы в процессе разработки.

Лаури Корпико:
Быстрые темпы приёмки.
Олли Мяяття:
Внедренец, обращающийся с возможным дефектом, должен предоставить грамотное описание этого дефекта.

Осси Вяанянен:
Внедренецы должны принимать участие в регрессионных тестах.

Лассе Кукконен:
Внедренцы должны обеспечивать обратную связь после передачи протестированной доработки.

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

Отдел Обязательство Показатель План
Разработка Основной поток перед сдачей на тест работает на компьютере разработчика без ошибок. Количество замечаний тестировщика но ошибкам в основном потоке в доработках, сданных на тест. (Фиксируется в задаче на тестирование). Количество замечаний по ошибкам в основном потоке за месяц/Количество доработок за месяц не более 0,3.

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Передаваемый код должен быть покрыт модульными тестами. Процент покрытия процедур модульными тестами. (Фиксируется в задаче на тестирование) Среднее покрытие процедур модульными тестами не ниже 90 % в месяц.
Доработки должны сдаваться в срок. Разница между датой дедлайна и датой передачи доработки заказчику (Фиксируется автоматически по закрытию задачи на сдачу заказчику) Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на доработку по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

Дефекты, пришедшие от клиента должны закрываться максимально быстро. Среднее время закрытия дефекта. (Фиксируется в дефекте) Среднее время закрытия дефектов с признаком «дефект от клиента» не больше 2 рабочих дней.
Тестирование Своевременно предоставлять тестовые планы. При передаче требований в работу, к задаче на разработку должна быть прикреплена ссылка на тестовый план. Процент покрытия передаваемых доработок тестовыми планами не ниже 95 %
Передавать внедренцам только доработки, не содержащие дефектов в основных и альтернативных потоках. Количество дефектов от клиента на протестированные данным тестировщиком доработки. Отношение количества дефектов от клиента на доработки данного тестировщика к количеству переданных доработок не выше 0,3

Пример:
10 доработок в месяц, 5 ошибок. Факт = 5/10 = 0,5, план не выполнен.
10 доработок в месяц, 2 ошибки. Факт = 2/10 = 0,2, план выполнен.
Тестирование должно проводиться максимально оперативно. Среднее отклонение фактических дат от плановых. Среднее отклонение фактических дат от плановых не выше корня квадратного от среднего количества плановых дней на доработку.

Пример:
В среднем, 9 дней на тестирование по плану. Среднее отклонение от плана: 2 дня. sqrt(9)=3; 3 меньше 2, план выполнен.

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

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

Подобный подход способен решить массу внутренних проблем и конфликтов.