Заказчик и Исполнитель – взаимоотношения как основа успеха проекта

Доклад супер! Столько инсайдов в одном месте!

да, все хорошо.
осталось непонятно кто делает проект. кто конкретно ВКАЛЫВАЕТ над каждой конкретной проблемой. Не обсуждает ее, не решает в какие сроки ее разрулить, а кто конкретно работает. ;-) Пока что фигурировали только топ-менеджеры, руководители проекта, контракт-менеджеры, объект-менеджеры и прочие "менеджеры". Поэтому справедливо, когда клиент считает что и лям - это много, а "автор" рассчитывает на 3-5 лямов... ;-)

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

Ну да, главное не качество продукта, а качество впаривания..

(1) support,
Спасибо!

(2) CheBurator,
Тема была про взаимоотношения. А проект делает объединенная рабочая группа (ОРГ). Об этом есть в предыдущей статье.
По поводу 5 или 1 миллиона, я говорил об адекватности восприятия клиента. Есть рынок, цену можно легко проверить.
По поводу распределения ресурсов. Не так просто измерить, т.к. люди выполняющие какие-то административные функции на одном проекте (объект-менеджер), одновременно могут быть консультантами, аналитиками или программистами на другом проекте. Кроме того, это зависит от масштаба проекта. На маленьком проекте, многие административные функции не рациональны. На большом проекте на административные функции может уходить более 10% ресурсов.

(3) genayo,
Впарить можно один раз. А у нас много клиентов приходит по рекомендации заказчиков.

(5) Ответ ни о чем. Мы не говорим о куче проектов. Мы говорим об одном проекте. У проекта есть бюджет. Есть ресурсы. Интересно было бы знать какова в проекте доля ресурсов, приходящаяся на решение административно-организационных задач и собственно на техническое вопрлощение проекта.

(6) UR1, Спорный вопрос. Зачастую уровень топменеджеров таков, что они даже не поймут, что им "впарили" продукт с неадекватным соотношением цена/качество, и вполне себе будут довольны и не будут отговаривать других от использования этого продукта. Впрочем, допускаю, что это не ваш случай.

(7) CheBurator,
От 3 до 20. Зависит от масштаба проекта.
Хотя все равно не очень понятно. Если на проекте сам руководитель пишет код и проч. Затраты на него считать административными или техническими?

(8) genayo,
Не сталкивались. Обычно это всего лишь вопрос времени, когда именно до руководства дойдет (или им объяснят) что им "впарили".

Не смог удержаться: лучше бы это назвать ОПГ - объединённая программистская группа))) Точнее раскрывает суть)

Если по теме - то присоединяюсь к вопросам и вообще взгляду ЧеБуратора на сие.

(11) Yashazz,
ОРГ это не только программисты. Лет 15 назад, мы тоже думали, что главное - это классные программисты и тогда все будет хорошо.
По-моему, на вопросы ЧеБуратора я ответил.

Статья интересная. 5 копеек, если позволите.
Первая сторона - вторая сторона, спорный момент. Путаница будет. Да и приоритеты расставлять, кто первый кто второй как то не комильфо.
Двустороння ответственность в любом договоре предусмотрена, на то он и договор, а не челобитная.
По поводу "Плохой - хороший полицейский" полностью согласен. Схема рабочая, сам использую.
Ставить заказчика на место, мягко, это тоже нужно. Это про то, что начинают учить как работать, особенно веселит, если этим занимается бухгалтер со словами "Чё там отчет делать, из ёкселя скопировать и всё...". Бывает и такое.
По поводу "хотелок", людям нужно объяснять, что это выходит за рамки изначального проекта/тех.задания. Кто везет на том и едут.
Если проект удался, и заказчик доволен результатом, но недоволен что не получилось вас "поюзать", ну его нафиг, неадекват какой-то.
П.С. Структура статьи - просто образец. Прочитав один раз, дальше достаточно по выделенному пробежаться чтобы восстановить статью в памяти.

(13) &rew,
Первая и Вторая стороны - это чистая психология, попытка уравнять. Позиция Заказчика: я плачу деньги и вы будете делать, что я хочу. К счастью, не всегда, но часто. Пока путаницы не возникало. И еще - это, то на что обращается внимание, отход от стандарта.
Да, нужно объяснять про рамки ТЗ, но и с той стороны тоже пытаются объяснять.
Да, неадекват, но компания очень большая и очень известная и кроме обслуживания могли бы быть еще проекты...
О структуре статьи - даже как-то неожиданно. Спасибо!