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

Комментарии 49

Идея здравая. Осталось только заставить другую сторону как положено соблюдать это дополнение.
Получается, скажу честно, не всегда. Неравные силы, например, у небольшой студии и крупного сырьевого холдинга :)
Последний абзац - золотые слова!
Но в целом - нечего нового...
Очень важный момент при работе с Заказчиком - определить (чтобы назначили) одного конкретного человека, с которым и будет вестись обсуждение! Как только получается добиться этого, так проект или доводится до конца и все довольны, или проект не доводится до конца, но претензий со стороны Заказчика нет.
В реальности, пока директор организации не назначит "контактёра" - работа не двигается..

Пожалуй, надо добавить такой пункт в договор, хотя бы моральная поддержка :)
Более того, мы вписываем в договор номера телефонов и email контактных лиц, а также оговариваем сроки ответов на сообщения и т.п.

Заказчики очень удивляются, но после прочтения такого договора серьезнее уже к процессу относятся.
Занимаюсь и поддержкой..
В среднем раз в год появляется у компании новый человек, который "отвечает" за сайт :) Это просто ужас - опять и снова учить и объяснять почему нельзя такие большие картинки ставить, почему лучше давать информацию, а не перекрашивать пункты меню.. Ну это так, для ответа.. :)
Перекрашивать пункт меню - ерунда. Часто каждый новый работник считает своим долгом объявить, что всё сделанное до него - полная фигня и нужно срочно переделывать.
Поставьте ему wiki и пишите все инструкции туда. Получится хорошо структурированная инструкция, в которой новый сотрудник может найти ответы на свои вопросы. А в крайнем случае - всегда проще кинуть ссылку, чем объяснять все заново.
А я блог сделал с ответами на часто встречающиеся вопросы :)
И при возникновении проблем пересылаю на ссылки в блоге.. Иногда читают.. :)
В закладках целый раздел с ссылками на faq - часто используется :)

Проблемы решаются и это - часть работы.

Из "философских".. :)
Возможно ли ожидать, что уровень подготовленности Заказчиков повысится?
Повышается ли уровень разработчиков с точки зрения работы с клиентами?
Как уровень разработчиков влияет на уровень Заказчиков и наоборот?

Тема ушла в сторону..
Спасибо за конкретные советы - чужой опыт - великая вещь!
Я как раз выступаю со стороны заказчика.

>Возможно ли ожидать, что уровень подготовленности Заказчиков повысится?

Разумеется. Как минимум, неопытный сотрудник поработав на проекте становится опытней. К тому же есть тенденция перехода сотрудников из студий на сторону заказчика при внедрении крупных проектов.

>Как уровень разработчиков влияет на уровень Заказчиков и наоборот?
По разному. Некоторые пытаются думать за заказчика и предлагать ему варианты решения, другие действуют по принципу "раз нам ничего не сказали, то делаем как хотим". и то и другое в итоге ужасно. Как вариант - в крупных студиях можно вводить должность аналитиков-консультантов со специализациями. Например "интернет-магазины", "корпоративные сайты". Такие сотрудники будут не просто заниматься созданием сайта, а консультировать по связанным с сайтом бизнес-процессам. Но это весьма дорогое удовольствие.
Пару недель была у меня история, когда при интеграции проекта на предприятии,проджект-менеджер пошел на поводу у кассирови даже под этим соусом начали новую итерацию разработок. Благо вовремя поступил сигнал о том, что что-то идет не так, пришлось вмешаться. Мораль: договор-договором но и собственные сотрудники должны однозначно идентифицировать его смысл особенно в части комуникаций.
идея хорошая, но в больших компаниях неэффективная.
чаще всего страдают от смены ответственных со стороны клиента из-за банальной текучки кадров или карьерных перемещений внутри оного.
тогда надо каждый раз перезаключать приложение, но оно в такой ситуации не спасает.
На случай смены кадров, отпуска и т.п. — стараемся фиксировать этапы, закрывать приемку актами и получать оплату. Чтобы при смене "голов" меньше было геморроя — этапы-то какие-то уже закрыты, и переколбашивать все по прихоти = платить за это деньги.
Достаточно указать в договоре, что при смене ответственного лица стороны обязаны уведомить об этом друг друга. Если проект средний ил ивыше по сложности, то со стороны заказчика обязательно должен быть свой менеджер проекта. Иначе работа превратится в квест "Как найти Иван Иваныча из отдела сервиса и получить от него нужную информацию, особенно если он в отпуске". Опять же, в такой ситуации и со стороны студии и со стороны заказчика есть ответственные лица, которые отвечают за проект и владеют полной информацией по нему.
Отличная идея. На мой взгляд.
Был случай у нас когда доволльно хорошо идущий проект после смены человек отвечающего за сайт со стороны заказчика вылился в судебное разбирательство со всеми вытекающими.
А почему так вышло?
Один человек сменил другого.
Был адекватный - стал неадекватный (как оказалось потом).
А потом предыдущий вообще уволился.
А потом их начальство посмотрело и сказало - "Так это ж совсем не так, как было в начале! Возвращайте наши денежки."
А мы и ни сном ни духом, что этот новый человек никому ничего не показывал, ни с кем не советовался и т.д.
В гражданский суд. Вы-то действовали по договору. Надеюсь, всю необходимую рабочую переписку ваши сотрудники хранят?
Это дела давно минувших дней ) Просто в качестве иллюстрации привёл.
Если мне память не изменяет, дело развалилось. Но нервы...

P.S. Сотрудники не мои )
Поэтому по максимуму фиксируйте сдачу-приемку этапов, закрывайте их отдельными актами и оплатой.
Уверяю вас так и было. Именно поэтому кроме нервов ничего не было задето.
Люди, это обычное приложение любого нормального договора. Тут даже обсуждать нечего. Странно, что для кого то это показалось "идеей".

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

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

Если просто выложить — ну будут скачивать, опять под копирку переписывать.
Обсуждение-то это понятно, просто, возможно, надо с чего-то начать. Я вот например не менеджер и даже не владелец, но мне просто интересно посмотреть на грамотный договор.
а ты не следил, сколько из этих договоров было списано с шаблона ЮМИ Студии? ;)
я был в шоке, когда узнал масштаб промышленного шпионажа
Пару-тройку точно видел. А как разошлось по Питеру коммерческое предложение и шаблон ТЗ, которые я писал зимой далекого уже 2003 года! :-)
Пока гром не грянет и петух не клюнет многие о таких вещах не задумываются.
К сожалению.
Я определяю "ответственного" еще на уровне брифинга. У меня сейчас сложилась именно та ситуация, которая определяет важность этого момента: директор школы, для которой я делал сайт (который уже готов) только спустя три месяца после утверждения макета решил на него взглянуть и "ужаснулся", что-же ему "подсунули". Что выбрал ответственный - то и подсунули. Когда она ко мне подошла с претензиями я ей прямо сказал, что по нашему договору ее претензии и выеденного яйца не стоят.
НЛО прилетело и опубликовало эту надпись здесь
Agile-разработка — это классно, когда работаешь над собственным проектом.
Для решения проблем с клиентами в договоре обязательно должно быть прописано не только контактное лицо со стороны заказчика, но и такой момент:все материалы и изменения принимаются в письменном виде + заверены печатью и подписью директора компании заказчика, обсуждение рабочих моментов ведется только с контактным лицом со стороны заказчика и материалы принимаются только от него. Процесс разработки делится на этапы, каждый этап закрывается актом: дизайн готов - акт, верстка готова - акт, CMS установили - акт и т.п. + В договоре должен быть пункт о том что если требования заказчика не соответствуют взгляду на создания сайтов компаниии подрядчика и могут привести к ухудшению юзабилити, работоспособности или визуального восприятия сайта - компания подрядчик имеет право не выполнять требования заказчика. Все это пишется в мягкой и завуалированной форме - потом так же мягко убеждаем заказчика в том что эти пункты включены в договор не зря, а для того что бы их сайт был успешным и не только окупил потраченные на него средства но и принес прибыль.
>> В договоре должен быть пункт о том что если требования заказчика не соответствуют взгляду на создания сайтов компаниии подрядчика и могут привести к ухудшению юзабилити, работоспособности или визуального восприятия сайта - компания подрядчик имеет право не выполнять требования заказчика. Все это пишется в мягкой и завуалированной форме
вы может просто не подписывать ТЗ на этап спорить до хрипоты. никто не заставит вас делать что вы не хотите, если вы под ТЗ подпись не поставили
У нас есть пункт, который звучит так:

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

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

С уважением...
ну по уму на каждый вопрос проекта должно быть строго одно ответственное лицо. тогда если уж идиота назначили — будет значит гадость сделана
Перед тем как вы выписываете в договор ответственное лицо со стороны заказчика, следует проверить его на адекватность на этапе сбора требований к проекту. Если человек явно неадекватен или очень поверхностно представляет себе разработку сайта - следует посоветовать руководителю компании выбрать другое ответственное лицо, если он в конечном итоге хочет получить эффективный сайт.
Еще лучшим приложением к договору станет устав проекта, в котором кроме всего прочего перечислены все влияющие на процесс лица и их полномочия. В уставе полномочия и сферы ответственности расписаны более четко, перечислены случаи когда лицо влияет на принятие решения, а когда нет. О нем неплохо написано у Андрея Куликова, ну и я описывал его составление на примере одного из проектов.
Зачем разработчику влезать в кухню заказчика? Особенно если это большая компания, со своими подводными камнями, конфликтами интересов, подсиживанием и т.п.? Тем более, что со стороны заказчика ВСЕГДА должно быть лицо принимающее решение. Другое дело, что этот сотрудник может сказать, что-то вроде "а статью о компании вам должна прислать Марь Петровна, вот ее адрес". Но именно он ответственен за то, чтоб ыэта статья была прислана и не дело разработчика выклянчивать обещанное. Это должен быть человек, который всегда знает на каком этапе находится оплата счетов, как выполняются обязательства со стороны студии и со стороны компании-заказчика, проводить (либо контролировать) окончательный баг-трекинг и т.п. А если ответственных несколько, то и ответственность весьма размытая
Действительно, зачем? :) О том что разработчик должен общаться с заказчиком не написано ни в самой статье, ни в тех ссылках что я привел :) Это задача аккаунт- или проджект-менеджера, в зависимости от компании.
Под разработчиком я понимаю представителя компании-разработчика. Точно так же как под заказчиком - представителя компании, которая заказывает разработку.
Может быть и незачем, но по факту всегда приходится вникать, чтобы не получилось описанной в этой статье ситуации про лебедя, рака и щуку. Оно-то конечно хочется, чтобы все было хорошо и выстроено аккуратно. Но в реальности всегда получается так, что на процесс со стороны заказчика влияет много людей и часто общаются с разработчиком также много людей, а не одно контактное лицо. Всякие ведь ситуации возникают — например, нужно прикрутить модуль онлайн-оплаты, а кухней его работы заведует рекламный отдел и отдел продаж. Руководитель проекта со стороны заказчика потратит гораздо больше времени на выяснение того, что нужно разработчику, чем если просто даст его контакт. При этом у человека из отдела продаж может быть свое видение оплаты через сайт, отличное от мнения руководства. И он будет его продвигать. Вот и интрига образовалась. И от них никуда не деться, как бы ни хотелось. Только если поставить между разработчиком и заказчиком аккаунт-менеджера, который будет разруливать эти вопросы. Но опять же, всех вопросов он закрыть не сможет.
>Руководитель проекта со стороны заказчика потратит гораздо больше времени на выяснение того, что нужно разработчику,

Быстрее - не значит лучше.

>Вот и интрига образовалась.

Есть есть менеджер проекта со стороны заказчика, то с интригой разбирается он. Если же нет, то может быть что угодно

>Только если поставить между разработчиком и заказчиком аккаунт-менеджера, который будет разруливать эти вопросы
И как он будет разруливать спор начальников отделов сервиса и оптовых продаж - информацию о ком из них вынести на главную страницу?
"Иногда надо просто фигачить" © :) Понятно, что нужно максимально уходить от этого, но никакая методика от этого не спасет, если проект достаточно объемный. Или если коммуникация плохая.

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

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

А еще, по опыту коллеги-программиста (не менеджера!), которому в 3 ночи на 9 марта звонил заказчик, надо прописывать аналогичный перечень контактных лиц со стороны студии.
А у нас так и есть. Правда, когда я об этом написал, статью заминусовали.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории