Хитро -*@[%№ -умный заказчик. Часть 2

Продолжу тему, начатую в 1-й части. Напомню, нас интересуют ситуации, когда заказчик «чудит». Ниже я приведу несколько примеров таких ситуаций, «основанных на реальных событиях», и какое могло бы быть решение. Но важно сразу понимать, что чудес не бывает, практически каждое решение приводит к необходимости ЗАРАНЕЕ ДОГОВАРИВАТЬСЯ О КОНКРЕТНЫХ ВЕЩАХ. Речь идет о профессиональном, вдумчивом инициировании проекта, т.е. договоренностях ДО НАЧАЛА РАБОТ.

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

Теперь представьте, что вы – исполнитель, и вы допустили, что в вашем контракте не конкретика, а «космические корабли бороздят просторы вселенной…». Такой заказчик сможет выжать из вас все соки, и на самом деле будет прав. Вы скорее всего не захотите ругаться и жертвовать репутацией, в конце концов он платит. Для вас это выльется в потерю денег. Если не описаны критерии приемки функционала, или не регламентировано по каким процессам мы работаем, или не настроен инструментарий объективного отражения качества и количества работы, то вы рискуете вечно полировать зеркальный шар за бесплатно, и виноваты в этом будете именно ВЫ, а не заказчик.

ВЫ – это: продажники, ответственные за технико-коммерческие предложения, менеджеры проектов и другие, кто влияет на договоренности с заказчиком.

Пример 1. Проблемное условие приемки: «Хочу чтобы отчет (в веб приложении) выдавался быстро».

На самом деле возникают вопросы: быстро это сколько секунд?, на каком объеме данных?, какой по объему сам по себе отчет?, на каком серверном (и-или) пользовательском «железе»?, какова должна быть ширина канала связи сервер-мир и мир-пользователь? Какой максимальный объем данных и объем отчета может быть?, и т.п. Это вопросы требований, пусть даже понадобится для их выяснения сделать прототип или потратить больше времени на обсуждения и расчеты.

Пример 2. Проблемные процессы: не было договоренности о стандартах кодирования, обсуждении архитектурных решений, применении код ревью и юнит тестирования. Девиз заказчика – надо педалить, а заниматься архитектурой, код ревью и другой чепухой некогда. Что естественно привело к разочарованиям как по поводу неработающего продукта, так и по поводу взаимоотношений вообще, с требованием все переписать за бесплатно.

Здесь нужно на УРОВНЕ КОНТРАКТА договариваться КАК мы работаем, и ЧТО будет, если мы намеренно выкидываем код ревью, тестирование и прочие практики.

Пример 3. Совсем уж знакомая проблема – заказчик не отвечает вовремя в проекте Fixed Price. Это значит команда простаивает, зарплата скорее всего не уменьшается, а сумма денег от заказчика не увеличивается.

Решение – на УРОВНЕ КОНТРАКТА прописать ОТВЕТСТВЕННОСТЬ ЗАКАЗЧИКА. Или сделать модификацию контракта с incentive fee, т.е. когда и заказчик и исполнитель заинтересованы работать быстрее и лучше. Своими глазами видел контракт, где было указано — «если заказчик не отвечает в течение времени Т, и это вызывает простой команды, то заказчик оплачивает неустойку в размере денежного эквивалентна на содержание команды за время простоя Т».

Пример 4. Субъективные суждения, я бы даже сказал – ощущения, о так называемом performance, под этим как минимум подразумевается качество и количество работы. Т.е. заказчик говорит – «вы в этом месяце, релизе, году работали хуже», и требует скидку, бесплатную работу и т.п. При этом отсутствует объективное понимание на цифрах и фактах, что такое «хуже».

Решение – на УРОВНЕ КОНТРАКТА (может быть и не с самого начала взаимоотношений, т.к. может быть неясно еще что такое «хорошо») прописать ПРИЕМЛЕМЫЙ УРОВЕНЬ СЕРВИСА, и самое главное – обеспечить объективность замеров. Делается это с помощью такого ИНСТРУМЕНТАРИЯ как тайм-, таск-, дефект- трекеры, или любого другого, способного сделать необходимые вам замеры. Прописываются КОНКРЕТНЫЕ данные, метрики, источники данных, формулы, графики, частота анализа, отчетность и т.п.

От примеров перейду к вопросам Когда?, Кто? и Как?

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

Далее, его неотъемлемой частью (приложения, отдельные документы, его разделы – как вы решите) должен быть документ(ы) с требованиями, т.е. – ЧТО делаем. Тут все равно, какую методологию и тип контракта вы применяете, если это Fixed price,то, понятно, должны быть подробные требования, если это нечто «гибкое», то должны быть указаны высокоуровневые требования и рамки проекта (продукта).

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

КАК – это:

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

В моей практике этот документ называется Устав Проекта, его можно назвать и по-другому, но суть должна остаться той же – описание КАК мы работаем.

Когда – естественно до начала работ и одновременно с обсуждениями контракта, т.к. это его неотъемлемая часть. Если некоторые пункты из КАК не ясны на момент подписания контракта, то можно так и написать, что будет выяснено тогда-то, отвечает такой-то. Но ни в коем случае не вычеркивать.

Кто – те, кто занимаются предпродажной подготовкой: продажники, технические специалисты, ответственные за технико-экономическое предложение.

Tags: , ,

Comments are closed.