Comments on: Как строить взаимоотношения с заказчиками/подрядчиками?

By: Victor Ronin

Victor Ronin — Tue, 08 Dec 2009 15:24:30 +0000

Интересно. Впервые слышу это название, но оно действительно очень точно описывает суть того, что нужно сделать.

By: Дядя Эдик

Дядя Эдик — Tue, 08 Dec 2009 07:00:30 +0000

Это называется протокол встречи. На самом деле, бюрократия документооборота полезна

By: Victor Ronin

Victor Ronin — Tue, 24 Nov 2009 03:57:35 +0000

Насчет исправления всех ошибок – сложный вопрос. Даже, тот который хотел чтобы ошибок не было, не ставил это обязательным требованием оплаты.

То, что стоит делать – это в случае, если описание проекта достаточно слабое (расплывчатое), то переводить проект на почасовку. Это конечно дело достаточно сложное – убедить заказчика тратить не константную сумму.
Собственно говоря, я привожу следующий аргумент – так как описание проекта не точное, то мы не можем дать сумму по деланию этого проекта. Либо нам придется по добавлению, изменению требования, постоянно дообговаривать дополнительные суммы по изменениям (на что будет тратиться достаточно много вашего и нашего времени).

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

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

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

Ну и само собой – если таки работаете попроектно, то платеж должен быть разбит на части. Сдали прототип – оплата, сдали Alpha – оплата. Каждая из стадий должна иметь критерии приемки (идеально обговоренные вначале). Тогда в самом конце, когда время дойдет до release, если заказчик очень заартачился – во первых основная часть
денег уже на руках (то есть не только у вас, но и у заказчика есть риски), во вторых, можно уже говорить – что вот, смотрите, все стадии были успешно сданы, да – баги есть, но это нормальная часть процесса.

Сложности возникают, когда денег на руках нет, остается вроде 2% работы (баги), но заказчик может выкручивать руки как хочет, учитывая то, что он знает, что исполнителю теряет очень много (риски высокие).

By: Victor Ronin

Victor Ronin — Tue, 24 Nov 2009 03:32:00 +0000

Та ду… У меня пару моментов были, которые сейчас как вспомню, так аж нехорошо становится.

By: Sergey Kiselev

Sergey Kiselev — Tue, 24 Nov 2009 01:24:06 +0000

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

Есть более интересный вопрос: как вы объясняете заказчику что не ВСЕ ошибки будут исправлены в конце проекта? Просто иногда заказчик может отказаться подписывать акт приемки передачи при наличии малейших ошибок. Также некоторые заказчики просто требуют чтобы ВСЕ ошибки были исправлены, и хотят в случае не исправления ВСЕХ ошибок финансовую ответственность исполнителя. Вообщем интересен ваш взгляд на мир

By: point

point — Mon, 23 Nov 2009 22:52:58 +0000

Спасибо за статью.

“Горячая голова – самый худший советник”.
На 100% согласен. Решения, принятые сгоряча, аукнуться потом ни раз.