Краткая инструкция по управлению заказчиками для программистов

[mihali4]

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

Конечно, не хотят. Никто не хочет. А некоторые хотят приносить пользу своим проектам, но не знают как это лучше делать. Или знают, но не ту книжку прочитали, поэтому от них один вред. В общем, разные заказчики бывают.

Первое, что нужно запомнить: заказчики на самом деле полезные (и не идиоты, нет).
Второе: заказчик, на самом деле, такой же ресурс, как программист или дизайнер.
Третье: основная задача менеджера проектов (мы-то с вами знаем кто на самом деле рулит вселенной (дьявольский смех)) – научиться управлять заказчиком так же эффективно, как программистами.

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

Основная сложность в управлении заказчиком как ресурсом состоит в том, что заказчик ни в коем случае не должен знать, что он ресурс. Более того, заказчик должен искренне верить в то, что причиной всей этой движухи, на самом деле, является он сам. Если бы не он… Да подумать страшно, что было бы!

Именно в таком состоянии от заказчика больше всего пользы.

Заказчики (да почти все) страдают дефицитом внимания. Не пишите им длинных писем. Идеальное письмо состоит из двух строчек. Максимум – из трех. Причем их этих трех строчек (лучше двух) должно быть понятно в чем проблема и каковы варианты ее разрешения. Помимо этого Идеальное Письмо Заказчику должно отвечать на вопрос “Чем грозит тупка с выбором решения” и “Когда решение нужно принять”.

По поводу решений. Вы, разумеется, лучше заказчика знаете что ему нужно. Вы, разумеется, уже продумали все варианты, учли все риски, посчитали ресурсы, отбросили заведомо дурацкие идеи и уже поставили задачу в разработку (потому что дедлайн, как всегда, “вчера” и времени на рассусоливания нет).

Гениальное Письмо Заказчику все в тех же трех строчках (лучше в двух) аккуратно и незаметно подводит заказчика к выбору правильного решения.

По поводу дедлайнов. Нормальный человек хочет работать только в том случае, если эта работа предотвратит вселенскую катастрофу. И даже такую ответственную работу нормальный человек не сделает в срок. А заказчик – человек (нет, ну правда!). Поэтому если требования вам нужны край к пятнице, пишите Истеричное Письмо заказчику про понедельник. В лучшем случае, вы получите их к среде (если как следует поистерите в понедельник и вторник). В худшем – к пятнице.

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

В результате подпольных многолетних исследований, была выведена эталонная фраза, с которой нужно начинать любое истеричное письмо: “Коллега, у вас проблемы”.
Если у вас весьма доверительные отношения с заказчиком, слово “проблемы” можно заменить на любое другое, более емкое слово. Что-то вроде: "Коллега, Вам пипец..."

Немаловажно, впрочем, сохранить местоимение “у Вас”, "Вам". Заказчик не всегда отождествляет себя с проблемами своих проектов. Некоторые ошибочно полагают, что проблемы у “программистов, которые опять ни фига не делают!”.

И, да, Истеричные Письма наиболее эффективны, если использовать их редко. А то получится как в сказке про мальчика и волков.

[mihali4]

По поводу задач. Не бойтесь ставить заказчику задачи. Он ресурс (только, тссс! никому!), он должен их выполнять. Это, в конце концов, в его же интересах. Ставьте задачи так же, как вы ставите их программисту. Вы же не просите его: “Напиши-ка мне код, дружок!”. А почему вы просите заказчика сказать вам зачем вообще все это нужно?

Задача должна быть ясной, измеримой, согласованной, реалистичной и определенной во времени (эгегей! Ну вы же менеджеры!).

По поводу языка. Заказчики ни черта не смыслят в технологиях. И не должны. Когда вы говорите им “фэдээска не синкает” они никак не могут связать это с “картинки не отображаются”. Они впадают в истерику. Они рыдают и кричат “Все сломалось!”. Говорите с ними на человечьем языке. Или говорите им что-нибудь успокаивающее вроде “Вам лучше этого не знать. Все под контролем. Сейчас все заработает.”. Это помогает, правда.

По поводу возраста. Относитесь к заказчикам, как к детям. Учите их. Делитесь знаниями. Разрешайте придумывать имена для серверов.
Заказчики - классные. Правда. И это так здорово, когда в один прекрасный день вы услышите в трубке: “Редактор не может зайти в бэк-офис… У вас опять сервер сессий навернулся?”.

[фЁдОр]

Сообщение от mihali4

Учите их. Делитесь знаниями.

Что Вы собственно с нами и делаете, причем бесплатно . Спасибо за статью.