Александр Борисов
9 сентября 2011

Здравствуйте, Артём!

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

Спасибо!



Александр!

Проблема в том, что клиент думает, будто дизайн заканчивается на картинках. На деле большая часть дизайнерских решений принимается на этапе разработки — причём неважно, осознаёт ли это клиент. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Почему дизайнеры не нарисовали листалку — специально или забыли? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404-я ошибка при ширине экрана 2000 пикселей?

В этом огромном потоке вопросов очень небольшая часть затрагивает бизнес и реально волнует клиента.

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

Естественно, получается уродец. Дизайнер кладёт скриншоты в портфолио, на реальный продукт без боли не взглянешь.

Ещё год назад бюро пыталось осуществлять авторский контроль над разработкой через клиента:

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

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

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

Решения в любом проекте принимаются постоянно. Ни подписание ТЗ, ни утверждение чертежа не способны зафиксировать конструкцию будущего самолёта. Если вы создаёте пользовательский интерфейс, большая часть решений во время его разработки будут дизайнерскими — кто бы их ни принимал. Лучше, чтобы решения принимали дизайнеры совместно с клиентом, а затем напрямую, через технического директора, транслировали их в разработку.

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

Как реагировать на заявления клиента о том, что их разработчики смогут справиться своими силами? Представьте себе — я не могу здесь посоветовать. О том, как действую я — в совете о ФФФ:

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

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

Получается, что мне не приходится убеждать клиента, потому что у меня просто нет альтернативы. Конечно, мне жаль, если мой клиент пойдёт по пути других клиентов других студий, но это будет его решение».

P. S.
Это был пятничный совет по взаимоотношениям с клиентом. Хотите получить совет по самой эффективной системе переговоров без оружия? Присылайте вопросы.
P. P. S.
Совет помог? Напишите в комментариях.
P. P. P. S.

Дата следующего набора в Школу стажёров пока неизвестна.

 
Мы напишем вам, когда будет открыт набор. Без спама.

Поделиться

Комментарии

Максим Россомахин
9 сентября 2011

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

Алексей Копылов
12 сентября 2011

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

Сейчас мы стараемся не продавать проектов без авторского надзора.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

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

Вот такой веб 2.0.

Несмотря на то, что между нами была договорённость о работе по ФФФ, клиент был в бешенстве 4 Расскажите, пожалуйста, вносят ли клиенты свои правки в макеты? Как защищать ОЧЕНЬ простые дизайнерские решения? Хочется всё старое выбросить и сделать заново 2




Недавно всплыло

Я бы покрасил стены новой рабочей студии белой краской. А коллега хочет клеить обои 3 Расскажите об управляемости. Домашнее задание 4 Что такое модальность и почему её принято ругать? Вторая часть 4 5