Открыть список
Как стать автором
Обновить

Что бесит заказчика

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

1) Непрозрачность ценообразования

Многие студии пренебрегают необходимостью прикладывать к компреду таблицу с пояснением — откуда берется цена.

Важно понять, что заказчик должен понимать — сколько стоит каждый этап, каждый модуль, сколько стоит день разработчика. Только в таком случае заявления студии «функциональность выросла/ваши требования изменились, что привело к увеличению цены»- могут иметь право на жизнь. Если в компреде написано «ваш проект займет ХХ месяцев и будет стоить ХХХХХХХХХХХ рублей», то тем самым студия отдает себя в рабство. что конечно, ей будет неприятно признавать впоследствии.

2) Отвратительные компреды

Компреды часто пишутся так, будто автор хотел написать статью в журнал. Вместо четкого описания проекта — много слов о величии компании-разработчика, заверения в клиентоориентированности (лживые на 99%), и много прочих ненужных слов. При этом сам проект часто непродуман.

Идеальное коммерческое предложение содержит:
— максимально детальное описание будущего проекта
— сроки и стоимость разработки с приближением 5-10% (конечно, только по описанному в компреде функционалу). Этот пункт должен быть разбит на этапы согласования и отдельные модули — для большей гибкости.
— краткое (КРАТКОЕ!!!) описание компании с приложением портфолио, подходящего данному конкретному случаю.

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

3) Необязательность и неаккуратность
Необязательность и неаккуратность часто проявляется уже на этапе подготовки компреда — когда даже точные даты получения компреда от разработчика невозможно добиться — «нам нужно время, чтобы написать индивидуальный компред именно для вас».

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

Тексты написанные «в порыве вдохновения» невозможно читать.

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

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

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

Классическим является представление о триаде «качество-стоимость-сроки», в которой можно выбрать только 2 пункта. Это понимает любой вменяемый человек — дешево, быстро и хорошо не бывает. Но даже если вы платите выше рынка — сроки все равно будут сорваны.

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

5) Отсутствие нормального взаимодействия между менеджерами заказчика и клиента
На недавнем сборище, где обсуждались взаимоотношения заказчика и исполнителя, представители студий массово сетовали на следующие проблемы:
— некомпетентность заказчика
— изменение требований по ходу проекта
— «потребительский терроризм»

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

С другой стороны, основными проблемами управления проекта исполнителем(как они видятся со стороны заказчика) являются:

* отсутствие своевременной связи между компаниями

О проблемах клиент узнает тогда, когда уже начинает злиться и звонить исполнителю. Это уже достаточно раздражает человека.
Клиенту важно «держать контроль» над проектом, понимать, что делается, куда идут его деньги, и когда он может ждать результата.
Отсутствие понимания важности этого (пусть даже чисто психологического) контроля со стороны проджектов студий практически гарантировано превращает любую мелкую проблемку (а они, безусловно, неизбежны) в повод для обмена претензиями.

Отдельного упоминания заслуживают оправдания менеджеров студий. Болезнь ключевого члена команды может встретить понимание и сочувствие заказчика один раз, ну — два, при длительном проекте. Но когда дизайнер болеет 3 дня каждую неделю — проджект теряет доверие клиента, и заставляет того ужесточать требования к контролю над проектом. Что, в свою очередь, порождает недовольство проджекта, падение качества управления проектом, и приводит к нарастанию конфликта по спирали.

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

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

Наконец, в качестве курьеза — самое абсурдное оправдание задержки работ: «ну, дизайнер — творческий человек, мы не можем загнать его в рамки графика».

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

* Недоступность менеджера

Генетически связанная с предыдущей проблема. Человек, работающий на клиента, должен в рабочее время быть доступен — если не по аське, то по телефону, или на крайний случай — по мылу. И отвечать на мейлы и асечные сообщения должен он сразу. ну хоть сообщить, мол, «получил, точно отвечу на ваш вопрос тогда-то». Обидно, когда тебя игнорируют, не придают тебе значения. к этому можно относиться с юмором, можно не обращать внимания, но «осадочек-то остается». Менеджер студии ВСЕГДА должен быть доступен.

* Размытая ответственность

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

* Смена ответственных лиц ведет к пересмотру обязательств

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

Таким образом, основной мой тезис: коллеги, давайте разговаривать друг с другом, но все наши дружеские беседы тщательно фиксировать, а затем — точно придерживаться обязательств :)))

Уточнения, возражения, дополнения и прочие комментарии — приветствуются!
Теги:project managementменеджмент проектовменеджмент интернет-проектов
Хабы: Чулан
Всего голосов 21: ↑16 и ↓5 +11
Просмотры640

Похожие публикации

Лучшие публикации за сутки