Как обучать Заказчика: Часть 2

Продолжаю большую тему о том, как нужно обучать Заказчика. Но этот пост, в отличие от предыдущего, будет также содержать советы о том, как подготовить свою команду.

Промежуточные результаты работы

Промежуточные результаты работыПромежуточные результаты работы – это всегда наказание для славянской команды (хотя что-то мне подсказывает, что и не для славянской тоже). Есть хорошая русская пословица, которой по умолчанию стараются следовать все программисты: «Дураку и начальнику недоделанную работу не показывают».

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

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

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

  • Заказчик не знает, на что конкретно нужно обратить внимание в данной презентации.
  • Заказчик не знает, как реагировать на ошибки в продукте.
  • Команда не знает, как реагировать на ошибки в продукте
  • Заказчик не понимает, куда дальше будут направлены усилия. То есть куда дальше будет развиваться функциональность, которую презентовали.
  • Команда не знает, какими способами показать продукт заказчику.

Что делать:

Для этого необходимо четко описать, что конкретно является целью данного показа. И главное это сделать ДО того, как начнется сам показ. При этом вы обговариваете правила приема замечаний и предложений. Если вы рассматриваете отчет Х, то неработоспособность кнопки Z не будет восприниматься как замечание.

ПМ (или технический лид) должен выступать жестким модератором беседы во время показа продукта. Его задача – удерживать фокус на том, что является темой показа. Если Заказчика все же тянет в сторону другой фичи, то можно предложить вынести обсуждение в другую встречу или поговорить об этом в оставшееся время.

Проверить продукт на том окружении, на котором будет происходить показ. ПМы часто наступают на эти грабли и половина времени встречи тратится на то, что ПМ и команда судорожно ищут «какого же … компонента не хватает на этом компьютере, чтобы все запустилось». Естественно, Заказчик думает о том, что вы тратите его время впустую.

Вести запись предложений и замечаний. Именно они являются целью ваших показов. Если некоторые из них непонятны, то необходимо их прояснить еще во время показа. Как та или иная функциональность должна быть изменена в рамках текущего приложения. После этого «протокол замечаний и предложений» должен быть записан и разослан участникам встречи. Кстати, это не обязательно должен писать ПМ :).

Реальный продукт всегда лучше презентаций. Если вы показываете слайд-шоу, значит результаты вашей работы неудовлетворительные. Есть всего несколько исключений из этих правил.

Подготовить команду для презентации. Почти в каждой команде есть человек, который при обнаружении ошибки во время презентации начинает с пеной у рта доказывать, что «это не баг, а фича». Или кто-то станет оправдываться «на моем компьютере все замечательно работает…». Не нужно оправданий, нужно просто записать замечание и ПОСЛЕ презентации разобрать. Самым хорошим выходом из этой ситуации будет письмо Заказчику, где вы поблагодарите его за помощь в поиске дефектов и отчитаетесь о том, что баг уже пофикшен.

Почему показ промежуточных результатов важен:

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

Вывод (почти рекламирую SCRUM): Если правильно подготовить Заказчика и команду, то показ промежуточных результатов из неприятной обязанности можно превратить в полезный инструмент. Не зря в SCRUM так много внимания уделяют “Demo”, когда команда презентует то, что было закончено в рамках спринта.

Продолжение следует…

Nov 1st, 2010
  1. Roman
    Nov 2nd, 2010 at 15:46 | #1

    Текст вверху замечательно интегрирует опыт, набитый шишками ;) в ходе реальной работы.

    Раз уж речь идёт именно в контексте айти-аутсорсинга:
    1. я бы добавил несколько характерных англоязычных терминов подобных презентаций, чтобы с Заказчиком общаться на одном языке. Например, “MoM”.
    2. более частым встречается запрос Заказчика “дайте демо-версию!” – возможно, особенностям этого стоит посвятить отдельную статью.

    Кстати, презентация прототипов – это ж не только Scrum. Часто это просто презентация прототипов :)

  2. Nov 3rd, 2010 at 08:08 | #2
    Roman :
    Текст вверху замечательно интегрирует опыт, набитый шишками в ходе реальной работы.

    2. более частым встречается запрос Заказчика “дайте демо-версию!” – возможно, особенностям этого стоит посвятить отдельную статью.

    Роман, с удовольствием прочту и опубликую (если она попадет в формат блога) Вашу историю. Пожалуйста, присылайте ее на story@anotherpm.com

Leave a comment