Customer satisfaction для программистов: Доверие и прозрачность

23 февраля 2015 г.

Есть отличная статья Управленческие инструменты: Почему заказчики требуют дурацкие отчеты? от компании Stratoplan. Рекомендую прочитать саму статью, а здесь я коротко опишу как мы используем матрицу 2x2 в своей работе.

Рисуем матрицу, где по одно оси «Прозрачность» вашей работы для заказчика, а по другой «Доверие» заказчика к вам:

У нас получилось 4 сектора с разными уровнями доверия и прозрачности. Как вы думаете, в каком из квадратов лучше всего находиться? Скорее всего вы скажете C или D, где доверие к нам высокое. Если доверие к нам, как к профессионалам, высокое, то это даёт большую свободу и ответственность. Если же у заказчика к нам низкое доверие, то скорее всего заказчик пытается много контролировать: мы пишем детальные отчеты по каждому движению, спорим по вопросам, которые должны быть в границах нашей компетенции и т.п. Всё это рождает проблемы и замедляет развитие проекта.

Давайте рассмотрим в динамике как мы будем двигаться к высокому доверию со стороны заказчика:

  1. Изначально, скорее всего, мы находимся в квадрате А — низкое доверие и низкая прозрачность процессов. Даже если заказчик говорит, что верит вам как себе, всё равно вы с ним ещё не работали и по факту он вам не доверяет. Из квадрата А мы начнём двигаться в сторону С, но как это сделать? Прыгнуть сразу в С вряд ли получится, доверие не рождается на ровном месте. Наш способ повышения доверия будет связан с повышением прозрачности процессов, т.е. мы выбираем путь A → B → C.
    Чтобы прозрачность повысилась мы можем: делать Impact Mapping, делать Story Mapping, визуализировать текущую работу на Kanban-доске, каждый день делать стендапы, проводить демо и ретроспективы, делать частые релизы и т.д. Любыми способами стараемся повышать прозрачность нашей работы.
  2. Если удалось повысить прозрачность, то мы переходим в квадрат В (низкое доверие и высокая прозрачность) — заказчик начал понимать Что, Как и Почему происходит на проекте. У заказчика возникает чувство контроля над процессом, причём инициатива на нашей стороне, за счёт этого постепенно повышается и доверие.
  3. Время перехода B → С (прозрачность высокая и доверие высокое) всегда разное, но по опыту могу сказать, что оно занимает обычно 2-4 месяца. Работа в квадрате С требует с нашей стороны значительных усилий, но за это мы получаем высокую лояльность заказчика.
  4. В этот момент происходит странная штука — команды начинают расслабляться, причем как разработчики, так и заказчики. Заказчики могут перестать приходить на демо. А зачем? Там и так всегда всё классно. Заказчики могут начать игнорировать планирования, ведь разработчики понимают куда идёт проект и что сейчас важно. Разработчики со своей стороны перестают делать ежедневные релизы, проводить ретро и т.п.
    Со временем мы уходим из С в квадрат D. Доверие со стороны заказчика высокое, но такой прозрачности как раньше уже нет. Такое положение дел очень удобно для всех сторон.
  5. Чем опасен квадрат D? Представьте себе, что вы находитесь в D и произошла какая-то серьезная проблема. Раньше для заказчика всё было прозрачно и можно было отследить корень проблемы, теперь мы просто в хороших отношениях с высоким уровнем доверия. Достаточно одной серьезной проблемы или ряд проблем, чтобы вы перешли из D сразу в А. Прозрачности процессов уже нет, все расслабились и доверие резко упало. Отсюда нам придется проделать весь пусть снова и начать работу по переходу в С через В. Есть оптимистичная стрелка из А обрато в D, но в реальности я не видел, чтобы так было.

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

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

Иллюзия прозрачности

В человеческой природе много багов, которые мешают жить и выстраивать грамотную коммуникацию. Один из них называется «иллюзия прозрачности». Ниже цитата из статьи Кто молчит - сам виноват, о том как мы создаем себе заботы:

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

Такая уверенность в психологии называется иллюзией прозрачности.

Иллюзия прозрачности (illusion of transparency) – это склонность людей переоценивать умение окружающих понимать наше внутреннее состояние.

Как говорит Дэнни Перекальски на своих выступлениях: «Я вижу огромные возможности для развития!». Надо побороть баг с иллюзией прозрачности и жить станет эффективнее.


Серия статей «Customer satisfaction для программистов»:

Комментариев нет:

Отправить комментарий

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...