Тут в прошлой статье мне задали вопрос: «как строите взаимоотношения с заказчиками/подрядчиками ? Т.е. устные договоренности, бумажные договора, риски, действия при срабатывании рисков и т.д.»
Скажу честно, в технической стороне менеджмента я чувствую себя гораздо более компетентным, чем в работе с заказчиками. Впрочем, я думаю это свойственно большинству технарей. Тем не менее, последние X лет (где-то от 5 до 7, смотря как считать) кое чему меня научили.
Самое важное — это документировать все ваши отношения. Поверх благих намерений, которыми вымощенная дорога в ад, лежит мощный трехметровый слой из устных договоренностей.
Не обязательно даже заказчик зараза и хочет вас кинуть. Просто, человеческая память так устроена, что она не может точно воспроизвести сказанную фразу даже несколькодневной давности. Вот и получается, что вы в начале проекта сказали — это займет четыре с половиной — пять с половиной месяцев. Заказчику запомнилась цифра четыре месяца, вам запомнилось — пять с половиной. Проект продлился пять месяцев и неделю. Вам кажется, что вы сдали раньше на неделю, заказчику кажется, что вы просрочили на месяц и неделю.
В целом, все, что важно для вас и заказчика и может быть определено заранее — должно быть в контракте. Чаще всего это
— деньги
— сроки
— объемы работы
Ну и стандартный кусок контрактов
— собственность (кто владеет чем по окончанию проекта)
— что вы гарантируете (а что нет)
— о невмешатесльстве в бизнесы друг друга (а-ля наем чужих сотрудников)
— окончание контракта
— эксклюзивность
В целом, если вы поищите большинство consulting agreement’ов будут иметь все эти пункты.
Если что-то заранее не может быть определено, лучше всего запишите в контракт либо диапазон (например 4-6 месяцев), либо методику по которой будет определяться значение («длительность проекта буду указана в дополнение к контракту после исследования предметной области»).
Кстати, еще одна важная вещь. Контракт не высечен в камне. Если происходят какие-то изменения, то можно подписать дополнения к контракту. Это правильнее, чем держать их в голове.
Вторая вещь, которой я лично пользуюсь — это честность и открытость. В контракте не возможно предусмотреть 100% ситуаций. Плюс, никакой контракт не удержит заказчика от ухода к другому исполнителю. Поэтому, как по мне, лучше в открытую обсуждать с заказчиком информация, которая для него важна.
Третье, я считаю, что нужно быть проактивным. Например заказчик не оговорил, насколько часто нужна отчетность — предложите ему ваш стандартный вариант и попросите его дать вам знать, если он хотел бы от вас другую частоту отчетности. Ведь понятно, что если заказчик вам не сказал про отчетность, то он все не будет счастлив тому, что вы исчезнете на два месяца погрузившись в разработку.
По поводу рисков. Как по мне, тема отдельная и большая. Единственное, что по этому поводу могу сказать, что я обычно считаю, что один раз — случайность, два раза — совпадение, три — закономерность. То есть, если заказчик выкидывает какой-то фортель первый раз и при этом он был на хорошем счету — то вполне это дело можно пропустить, но если проблема серьезная и повторяется три раза, то лучше всего сворачивать сотрудничество. Как показывает практика — отсутствие сотрудничества лучше, чем плохое сотрудничество.
Насчет подрядчиков. В целом все тоже самое. Единственное, проактивность стоит воспринимать по другому. Со стороны заказчика под проактивностью я понимаю — постановку задач, их приоритезацию и объяснений тех критериев, которые для него важны. Подрядчики — люди и не умеют читать мысли. Очень многие заказчики наступают на грабли, что они ожидают чего-то от исполнителя, что никогда не было оговорено.
Ну и пару мелких замечаний.
— Если заказчик или подрядчик не хочет подписывать (разумный) контракт, то стоит ооочень серьезно задуматься о дальнейшем сотрудничестве. Аналогично, если из контракта пытаются выбросить стандартные пункты. Большинство контрактов обтачивались достаточно долгий срок, чтобы быть достаточно универсальными.
— Чтобы не происходило в переговорах с заказчиками и подрядчиками, пытайтесь оставаться спокойными. Горячая голова — самый худший советник.
Спасибо за статью.
«Горячая голова – самый худший советник».
На 100% согласен. Решения, принятые сгоряча, аукнуться потом ни раз.
Та ду… У меня пару моментов были, которые сейчас как вспомню, так аж нехорошо становится.
С документированием всего и вся согласен безоговорочно. Сколько с меня крови выпили за то, что были такие устные договоренности. Поэтому надо взять за правило, после каждой встречи с заказчиком писать основные обсуждаемые мысли (решения) и высылать данный документ заказчику (возможно за подписью заказчика). Жить станет на порядок проще, главное побороть лень и уверенность что устных договоренностей достаточно.
Есть более интересный вопрос: как вы объясняете заказчику что не ВСЕ ошибки будут исправлены в конце проекта? Просто иногда заказчик может отказаться подписывать акт приемки передачи при наличии малейших ошибок. Также некоторые заказчики просто требуют чтобы ВСЕ ошибки были исправлены, и хотят в случае не исправления ВСЕХ ошибок финансовую ответственность исполнителя. Вообщем интересен ваш взгляд на мир 🙂
Насчет исправления всех ошибок — сложный вопрос. Даже, тот который хотел чтобы ошибок не было, не ставил это обязательным требованием оплаты.
То, что стоит делать — это в случае, если описание проекта достаточно слабое (расплывчатое), то переводить проект на почасовку. Это конечно дело достаточно сложное — убедить заказчика тратить не константную сумму.
Собственно говоря, я привожу следующий аргумент — так как описание проекта не точное, то мы не можем дать сумму по деланию этого проекта. Либо нам придется по добавлению, изменению требования, постоянно дообговаривать дополнительные суммы по изменениям (на что будет тратиться достаточно много вашего и нашего времени).
В случае, если проект описан хорошо, то просто вводится подушка на пофикс багов. Причем чем более дотошное описание, тем больше подушка (так как заказчик дотошный).
А в целом, для любых достаточно сложных, длинных и неоднозначных проектов — почасовая оплата — обязательное дело. Если заказчик на нее не соглашается, то лучше и не начинать. Ну разве что исключение, если можно выставить сумму которая явно перекроет все затраты.
Уж не помню сколько я раз влетал на этом, когда брались делать, а потом по ходу накапливались изменения, технические сложности, баги и проект выходил в глубокие минуса.
Ну и само собой — если таки работаете попроектно, то платеж должен быть разбит на части. Сдали прототип — оплата, сдали Alpha — оплата. Каждая из стадий должна иметь критерии приемки (идеально обговоренные вначале). Тогда в самом конце, когда время дойдет до release, если заказчик очень заартачился — во первых основная часть
денег уже на руках (то есть не только у вас, но и у заказчика есть риски), во вторых, можно уже говорить — что вот, смотрите, все стадии были успешно сданы, да — баги есть, но это нормальная часть процесса.
Сложности возникают, когда денег на руках нет, остается вроде 2% работы (баги), но заказчик может выкручивать руки как хочет, учитывая то, что он знает, что исполнителю теряет очень много (риски высокие).
Это называется протокол встречи. На самом деле, бюрократия документооборота полезна 🙂
Интересно. Впервые слышу это название, но оно действительно очень точно описывает суть того, что нужно сделать.