Виды контрактов в заказной разработке
Эта статья, скорее - лирическое отступление, хотя для общей картины она тоже важна.
Сама схема оказания услуги в области заказной разработки ПО в целом достаточно хорошо сформирована, но, тем не менее, есть множество важных и не всегда очевидных деталей.
Для начала, перечислим традиционные модели взаимодействия клиента и исполнителя: Контракт с фиксированной ценой - Fixed price (FP), Повременная оплата - Time and material (T&M), Аутстафф - Outstaff.
Контракт с фиксированной ценой
Предполагает ответственность исполнителя за достижение определённых целей - как правило, зафиксированных в контракте и приложениях. Наиболее стабильный способ фиксации целей в таком контракте - детальные требования (см. артефакт "требования" - будет описан позже). На стороне исполнителя выполняется полный цикл работ от снятия требований до полной готовности продукта.
Ремарка: документ "требования" часто также называют "техническое задание", ТЗ, что не вполне верно. По ГОСТу требования есть часть ТЗ. Впрочем, пожалуй - самая важная.
Требования могут быть сформированы на начало контракта во всех необходимых деталях, могут быть очерчены схематично или могут вообще отсутствовать.
В том (нечастом) случае, когда заказчик предоставляет к началу контракта абсолютно полные и детальные требования (то есть - требования такой детальности, к которой привык исполнитель), проект может быть оценен с высокой точностью на начало контракта.
Отмечу, что только исполнитель решает, полны ли и детальны ли предоставленные заказчиком постановочные документы. В целом, если требования неполны, не всегда обязательно настаивать на их доработке до блеска. Иногда неполнота постановки является хорошим аргументом для контрактации по T&M и выполнения работ по agile.
Если требования отсутствуют или неполны, применяются две схемы контрактации.
В первой схеме исполнитель грубо оценивает затраты на проработку требований и контрактуется только на этот этап работы. По окончании этапа на основании детальных требований определяется стоимость работ по разработке системы и подписывается второй контракт.
Для того, чтобы заказчика устроил такой метод работы, исполнитель должен показать, что написанные требования будут в достаточной степени отчуждаемы, чтобы заказчик на втором этапе мог выбирать, остаться ли с этим исполнителем, или переключиться на другого.
Во второй схеме контрактации при неполных или отсутствующих требованиях контракт подписывается на весь объём работы. При этом исполнитель, имея нечёткую постановку, оценивает объём (срок и стоимость) схематически, имея в виду возможность уточнения сроков, стоимости или скоупа (состава) работ уже внутри контракта. В этой схеме исполнитель при сборе требований должен ставить перед собой задачу удержания состава проекта от раздувания заказчиком. Впрочем, эта задача стоит всегда и везде.
Один из типовых механизмов в такой схеме - разбиение всех сформированных требований на приоритеты, и отработка требований от наиболее важных до наименее важных по схеме "пока не кончатся деньги". Опять же, впрочем, разбиение требований на приоритеты необходимо при любом подходе.
Контракт T&M
Строго говоря при таком виде контракта стоимость работ не может быть оговорена на старте. Тем не менее, редкий заказчик готов оперировать оценкой стоимости работ в диапазоне от нуля до бесконечности. Как правило, исполнитель всё же называет опорную стоимость и срок. Иногда оговаривается безусловная максимальная цена и ключевые временнЫе точки в проекте, к которым должны быть сделаны релизы с той или иной функциональностью.
Контракты T&M довольно вариативны. В пределе при работе по такому контракту исполнитель может вообще не нести ответственность за сроки и стоимость, тогда схема приближается вплотную к аутстаффу (см. ниже) и, к примеру. менеджер проекта находится на стороне клиента. В другой крайности контракт T&M представляет собой практически fixed price контракт, но с ослабленными требованиями к составу релизов, стоимости и срокам. В такой контракт хорошо вписывается agile подход в той или иной его инкарнации. Например, жёсткий план проекта может быть заменён на беклог с уточнением состава релизов по ходу проекта. Впрочем, по сути, ничто не мешает делать то же самое и в проекте с фиксированной ценой. Другое дело, что в fix price проекте любая замена в составе функциональности проекта должна проходить жёсткую процедуру запроса на изменение (ЗИ, CR), а в T&M проекте схема согласования такого изменения может быть куда более расслабленной (в частности, не включать в себя точный подсчёт изменения сроков и стоимости проекта).
Аутстафф
В этом варианте контракта подрядчик вообще отвечает только за профессионализм сотрудников, которые от него работают на проекте. За требования, архитектуру, проектное управление и качество результата отвечает заказчик. Тем не менее, на таких проектах подрядчик может принимать очень глубокое участие в проектировании, постановке и проектном управлении - важно, что все эти функции он исполняет исключительно в режиме исполнения решений заказчика. Диапазон схем и здесь достаточно велик. В самом слабом случае подрядчик просто поставляет в команду разработки несколько линейных специалистов. В самом мощном случае фактическая экспертиза, проектные решения и иногда даже продуктовая/бизнес экспертиза находится на стороне подрядчика, а заказчик включает в команду лишь менеджера проекта, считая, что в этом случае он контролирует проект лучше.
Стороны и ресурсы
Необходимо отметить, что при любой схеме проекта практически любые ресурсы проекта - те или иные сотрудники, код, библиотеки, подсистемы, сервера - могут поставляться любой стороной проекта. Есть вещи незыблемые - например, при fixed price контракте исполнитель вряд ли допустит, чтобы менеджер проекта был не с его стороны - это выглядит как самоубийство. В остальном - вы вольны проектировать любой состав команды. Несколько примеров:
Два менеджера проекта - и подрядчик, и заказчик выставляют своего PM-а. Это - очень типовой и реально полезный вариант. Даже если со стороны заказчика нет полноценного проджекта, как минимум постоянный ответственный сотрудник должен быть аллоцирован.
Два архитектора - опять же, архитектор со стороны заказчика хорошо знает ландшафт и возможности команды заказчика и будет крайне полезен при принятии решений.
Аналитик со стороны заказчика - в дополнение к аналитику или группе аналитиков подрядчика сотрудник заказчика со знанием его бизнес-процессов и налаженной коммуникацией в среде сотрудников заказчика может сильно сократить затраты.
Дизайнер или проектировщик интерфейсов - иногда подключается исключительно из желания заказчика сократить затраты, иногда реально полезен как носитель знания о принятых глобальных правилах оформления или единообразного user experience на разных системах заказчика.
Очень важно в том или ином объёме подключать со стороны заказчика системного администратора или сотрудника группы devops. В противном случае все релизы и интеграции обойдутся команде в цистерны крови и километры измотанных нервов.
Ценность разработчиков со стороны заказчика, как правило, невелика, хотя, опять же, бывают варианты.
Консалтинг и точка принятия решений
Постулат: Решение принимает тот, кто за него платит. То есть - заказчик.
Постулат: Вы всегда консультируете заказчика. Вас потому и наняли.
Вас как подрядчика выбрали потому, что вы показали более высокие знания в той или иной области, нежели ваши конкуренты. Другое дело, в какой именно области вы показали знания.
Если вы не компания, которая внедрила десяток крупных проектов такого рода за последние пару лет, то вряд ли вас оценивают как бизнес-консультанта в этой тематике. При этом по факту, скорее всего, вы накопили достаточный опыт в более широком классе проектов и стремитесь поделиться им с заказчиком. Что, в силу вышесказанного, не находит в нём понимания. Он - профессионал в своей области, чему вы можете его научить?
В частности, конфликты такого рода возникают, когда ваш заказчик переводит бизнес из офлайна в онлайн. Он действительно хорошо знает сам бизнес, а вы действительно лучше него знаете специфику онлайн-решений. И видите, что клиент (при постановке бизнес-процессов, как правило) совершает дикую ошибку. И пытаетесь предотвратить. И - вас мягко, а иногда и жёстко, разворачивают со словами "Ты же программист? Иди, программируй. Не лезь в наши дела."
Повторю, вы рассматриваете проблему как смертельную, то есть - не верите в успешность проекта в случае, если ваше предложение будет проигнорировано.
В этом случае возможны несколько вариантов. В любом случае, начните с того, чтобы официально уведомить заказчика о своей позиции. Обозначить её нужно чётко и недвусмысленно, а уведомление произвести в рамках зафиксированного в договоре формата коммуникации, вплоть до заказного письма с уведомлением. Это само по себе наведёт получателя на мысль, что вы достаточно серьёзно относитесь к предмету.
Далее можно:
Сама схема оказания услуги в области заказной разработки ПО в целом достаточно хорошо сформирована, но, тем не менее, есть множество важных и не всегда очевидных деталей.
Для начала, перечислим традиционные модели взаимодействия клиента и исполнителя: Контракт с фиксированной ценой - Fixed price (FP), Повременная оплата - Time and material (T&M), Аутстафф - Outstaff.
Контракт с фиксированной ценой
Предполагает ответственность исполнителя за достижение определённых целей - как правило, зафиксированных в контракте и приложениях. Наиболее стабильный способ фиксации целей в таком контракте - детальные требования (см. артефакт "требования" - будет описан позже). На стороне исполнителя выполняется полный цикл работ от снятия требований до полной готовности продукта.
Ремарка: документ "требования" часто также называют "техническое задание", ТЗ, что не вполне верно. По ГОСТу требования есть часть ТЗ. Впрочем, пожалуй - самая важная.
Требования могут быть сформированы на начало контракта во всех необходимых деталях, могут быть очерчены схематично или могут вообще отсутствовать.
В том (нечастом) случае, когда заказчик предоставляет к началу контракта абсолютно полные и детальные требования (то есть - требования такой детальности, к которой привык исполнитель), проект может быть оценен с высокой точностью на начало контракта.
Отмечу, что только исполнитель решает, полны ли и детальны ли предоставленные заказчиком постановочные документы. В целом, если требования неполны, не всегда обязательно настаивать на их доработке до блеска. Иногда неполнота постановки является хорошим аргументом для контрактации по T&M и выполнения работ по agile.
Если требования отсутствуют или неполны, применяются две схемы контрактации.
В первой схеме исполнитель грубо оценивает затраты на проработку требований и контрактуется только на этот этап работы. По окончании этапа на основании детальных требований определяется стоимость работ по разработке системы и подписывается второй контракт.
Для того, чтобы заказчика устроил такой метод работы, исполнитель должен показать, что написанные требования будут в достаточной степени отчуждаемы, чтобы заказчик на втором этапе мог выбирать, остаться ли с этим исполнителем, или переключиться на другого.
Во второй схеме контрактации при неполных или отсутствующих требованиях контракт подписывается на весь объём работы. При этом исполнитель, имея нечёткую постановку, оценивает объём (срок и стоимость) схематически, имея в виду возможность уточнения сроков, стоимости или скоупа (состава) работ уже внутри контракта. В этой схеме исполнитель при сборе требований должен ставить перед собой задачу удержания состава проекта от раздувания заказчиком. Впрочем, эта задача стоит всегда и везде.
Один из типовых механизмов в такой схеме - разбиение всех сформированных требований на приоритеты, и отработка требований от наиболее важных до наименее важных по схеме "пока не кончатся деньги". Опять же, впрочем, разбиение требований на приоритеты необходимо при любом подходе.
Контракт T&M
Строго говоря при таком виде контракта стоимость работ не может быть оговорена на старте. Тем не менее, редкий заказчик готов оперировать оценкой стоимости работ в диапазоне от нуля до бесконечности. Как правило, исполнитель всё же называет опорную стоимость и срок. Иногда оговаривается безусловная максимальная цена и ключевые временнЫе точки в проекте, к которым должны быть сделаны релизы с той или иной функциональностью.
Контракты T&M довольно вариативны. В пределе при работе по такому контракту исполнитель может вообще не нести ответственность за сроки и стоимость, тогда схема приближается вплотную к аутстаффу (см. ниже) и, к примеру. менеджер проекта находится на стороне клиента. В другой крайности контракт T&M представляет собой практически fixed price контракт, но с ослабленными требованиями к составу релизов, стоимости и срокам. В такой контракт хорошо вписывается agile подход в той или иной его инкарнации. Например, жёсткий план проекта может быть заменён на беклог с уточнением состава релизов по ходу проекта. Впрочем, по сути, ничто не мешает делать то же самое и в проекте с фиксированной ценой. Другое дело, что в fix price проекте любая замена в составе функциональности проекта должна проходить жёсткую процедуру запроса на изменение (ЗИ, CR), а в T&M проекте схема согласования такого изменения может быть куда более расслабленной (в частности, не включать в себя точный подсчёт изменения сроков и стоимости проекта).
Аутстафф
В этом варианте контракта подрядчик вообще отвечает только за профессионализм сотрудников, которые от него работают на проекте. За требования, архитектуру, проектное управление и качество результата отвечает заказчик. Тем не менее, на таких проектах подрядчик может принимать очень глубокое участие в проектировании, постановке и проектном управлении - важно, что все эти функции он исполняет исключительно в режиме исполнения решений заказчика. Диапазон схем и здесь достаточно велик. В самом слабом случае подрядчик просто поставляет в команду разработки несколько линейных специалистов. В самом мощном случае фактическая экспертиза, проектные решения и иногда даже продуктовая/бизнес экспертиза находится на стороне подрядчика, а заказчик включает в команду лишь менеджера проекта, считая, что в этом случае он контролирует проект лучше.
Стороны и ресурсы
Необходимо отметить, что при любой схеме проекта практически любые ресурсы проекта - те или иные сотрудники, код, библиотеки, подсистемы, сервера - могут поставляться любой стороной проекта. Есть вещи незыблемые - например, при fixed price контракте исполнитель вряд ли допустит, чтобы менеджер проекта был не с его стороны - это выглядит как самоубийство. В остальном - вы вольны проектировать любой состав команды. Несколько примеров:
Два менеджера проекта - и подрядчик, и заказчик выставляют своего PM-а. Это - очень типовой и реально полезный вариант. Даже если со стороны заказчика нет полноценного проджекта, как минимум постоянный ответственный сотрудник должен быть аллоцирован.
Два архитектора - опять же, архитектор со стороны заказчика хорошо знает ландшафт и возможности команды заказчика и будет крайне полезен при принятии решений.
Аналитик со стороны заказчика - в дополнение к аналитику или группе аналитиков подрядчика сотрудник заказчика со знанием его бизнес-процессов и налаженной коммуникацией в среде сотрудников заказчика может сильно сократить затраты.
Дизайнер или проектировщик интерфейсов - иногда подключается исключительно из желания заказчика сократить затраты, иногда реально полезен как носитель знания о принятых глобальных правилах оформления или единообразного user experience на разных системах заказчика.
Очень важно в том или ином объёме подключать со стороны заказчика системного администратора или сотрудника группы devops. В противном случае все релизы и интеграции обойдутся команде в цистерны крови и километры измотанных нервов.
Ценность разработчиков со стороны заказчика, как правило, невелика, хотя, опять же, бывают варианты.
Консалтинг и точка принятия решений
Постулат: Решение принимает тот, кто за него платит. То есть - заказчик.
Постулат: Вы всегда консультируете заказчика. Вас потому и наняли.
Вас как подрядчика выбрали потому, что вы показали более высокие знания в той или иной области, нежели ваши конкуренты. Другое дело, в какой именно области вы показали знания.
- Умение управлять проектом и достичь результата в срок и деньги. (Вы продали проектное управление)
- Умение проектировать программные решения такого типа. (Вы продали архитектуру и технические решения)
- Умение работать с бизнес-кейзами такого типа. (Вы продали бизнес-консалтинг.)
Если вы не компания, которая внедрила десяток крупных проектов такого рода за последние пару лет, то вряд ли вас оценивают как бизнес-консультанта в этой тематике. При этом по факту, скорее всего, вы накопили достаточный опыт в более широком классе проектов и стремитесь поделиться им с заказчиком. Что, в силу вышесказанного, не находит в нём понимания. Он - профессионал в своей области, чему вы можете его научить?
В частности, конфликты такого рода возникают, когда ваш заказчик переводит бизнес из офлайна в онлайн. Он действительно хорошо знает сам бизнес, а вы действительно лучше него знаете специфику онлайн-решений. И видите, что клиент (при постановке бизнес-процессов, как правило) совершает дикую ошибку. И пытаетесь предотвратить. И - вас мягко, а иногда и жёстко, разворачивают со словами "Ты же программист? Иди, программируй. Не лезь в наши дела."
Повторю, вы рассматриваете проблему как смертельную, то есть - не верите в успешность проекта в случае, если ваше предложение будет проигнорировано.
В этом случае возможны несколько вариантов. В любом случае, начните с того, чтобы официально уведомить заказчика о своей позиции. Обозначить её нужно чётко и недвусмысленно, а уведомление произвести в рамках зафиксированного в договоре формата коммуникации, вплоть до заказного письма с уведомлением. Это само по себе наведёт получателя на мысль, что вы достаточно серьёзно относитесь к предмету.
Далее можно:
- Отработать собственную рекомендацию молча в формате ползучей революции. Это плохой путь. Заказчик выявит и будет на вас справедливо гневаться, денег за свою услугу вы не получите, а получите риск несдачи проекта по несоответствию требованиям.
- Провести цикл совещаний с неключевыми сотрудниками заказчика, убедить их (желательно, очень аргументированно), и потом снова выйти на ЛПР, уже широким фронтом.
- Молча продолжить работу, имплементируя неправильное решение заказчика (Вы же предупредили? Три раза? Он не внял? Это его решение.), но работая на снижение своих рисков - не допуская дебиторки, более чётко относясь к формальной стороне проекта (документам, актам и пр.)
- Заявить, что риск в силу принятого решения столь велик, что вы хотели бы сняться с проекта, или же получить твёрдые (желательно - в виде предоплаты за все оставшиеся работы) заверения заказчика, что он точно отвечает за этот риск сам.