Одна из самых показательных ситуаций для оценки взаимодействия заказчик-исполнитель — ремонт в квартире. Отличие от услуг, скажем, парикмахера — в отношении к большим суммам денег, а это очень заметно сказывается на остроте восприятия.

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

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

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

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

Надо ли говорить, что в итоге ремонт делал второй, даже при немного большей оценочной стоимости санузла? А за снятие-установку розеток мы переплатили, если не ошибаюсь, 150 рублей, что на фоне остальных расходов — копейки. Как вообще можно доверять человеку, у которого кругом проблемы?

А как часто заказчикам приходится слышать про проблемы программистов, верстальщиков и дизайнеров? Лучше бы они этого не слышали вообще, особенно на этапе выбора исполнителя. Куда проще довериться тому, кто даже еще не получив денег, уже начал думать о возможностях.

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

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

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

Дизайнер, который на просьбу заказчика исправить фон на более темный, начинает рассказывать, что никто сейчас так не делает и это не модно, очень похож на продавца рубашек, который утверждает, что рубашки с карманами сейчас не делают, потому что в них постоянно что-то складывают, и они от этого оттягиваются. На самом же деле продавцу рубашек не хватило денег на еще несколько моделей, а дизайнер боится, что его примут за плохого дизайнера из-за этой мелочи, но своим разговором делает еще хуже. А еще ему переделывать много, это ж вообще капец. А что мог сделать дизайнер? Конечно же, он мог использовать ум и воображение заказчика перед тем как что-либо решать.

Где-то у Уэлча был пример про сотрудника, который сказал своему начальнику, что тот за ту же зарплату мог бы использовать не только его руки, но еще и голову. А тут это — вообще за его же деньги.

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

Проясните заранее, что может быть критично. Спланируйте работу так, чтобы эти вопросы решал тот, кому это критично.

Ну, и напоследок, все, то же самое, но кратко:
1. Разговор о возможностях, повышает веру в хороший результат.
2. Даже разговор о проблемах, лучше строить через возможности их решений.
3. Чем прозрачнее процесс, тем адекватнее оценка результата.
4. Чем раньше заказчик узнает о предстоящих расходах, тем быстрее он решит этот вопрос.
5. Чем яснее круг критичных вопросов, тем проще включать заказчика в работу так, чтобы он сам подсказывал ответы на критичные вопросы.

Что показано в примерах:
1. Использование Shared Views для генерации типовых интерфейсов на основе метаданных моделей
2. ControllerFactory, который умеет запускать generic-контроллеры
3. Расширение ViewEngine, которое позволяет создавать и переопределять виртуальные View-parts


Список интересных мест в исходниках, с которых стоит начать их изучение:

SharedViews-and-TemplateHelpers

Контроллеры:
\Controllers\DictionaryColorsController.cs, DictionaryDepartmentsController.cs

Сами shared views:
\Views\Shared\ListSelect.cshtml, Update.cshtml

Template Helper для таблиц:
\Views\Shared\DisplayTemplates\Table.cshtml

Метаданные для объектов:
\Models\Color.cs, Department.cs



GenericControllers

Сам generic-контроллер:
\Controllers\DictionaryController.cs

Регистрация generic-контроллера и маппинг моделей:
\Global.asax.cs, строки 28-30

Фабрика generic-контроллеров:
\GenericControllerUtil\GenericControllerFactory.cs

Регистрация фабрики для поддержки generic-контроллеров:
\Global.asax.cs, строка 39

Расширение ViewEngine для работы виртуальных View:
\GenericControllerUtil\CustomViewLocationsViewEngine.cs

Сами виртуальные View:
\Views\DictionaryController`1\Color\Footer.cshtml

Регистрация расширения ViewEngine для поддержки виртуальных функций:
\Global.asax.cs, строка 41

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

Вход свободный. После регистрации.

Сайт: http://www.dotnetconf.ru/
Доклады: http://www.dotnetconf.ru/Discussion
Регистрация: http://www.dotnetconf.ru/Registration

Для тех, кто сомневается, стоит ли выступать на конференциях: http://blog.byndyu.ru/2011/02/blog-post.html

Но, видимо, после такого предисловия я ожидал, что в книге сразу будут даваться конкретные решения, а при чтении первой части у меня очень часто возникал вопрос «и это все?», после которого хотелось закрыть книгу. Пожалуй, до раздела с анализом и выводами я дочитал только лишь потому, что автор подготовил меня к такому развитию событий во введении, и пообещал все-таки сделать свой анализ.

Кроме освящения и анализа различных холиваров, в этой книге упоминается еще одна правильная мысль: проблемы, стоящие перед программистами, по своей сути — не новы, и, как следствие, те или иные споры и решения можно найти и в других областях, решающих задачи. Эта же идея, кстати, есть и у М. и Т. Поппендик в их «Бережливом производстве ПО».

Креативное программирование 2.0 на озоне.