PMsoop: Глава №3: Договорённости

В ролях – Заказчик, Разработчик (representative person)

Артефакты – ПОЗП, предложение на разработку, Контракт

Суть – Заказчик и Разработчик заключают Контракт на выполнение работ по проекту

Предварительные договорённости достигнуты, теперь самое время закрепить их в виде некоторого Договора либо Контракта.

Что такое Контракт? Если кратко -  можно сказать, что это документ, описывающий ответственность сторон при выполнении некоторой работы, в нашем случае – разработке заказанного ПО.

В идеале Контракт должен четко формулировать поставленную задачу, предполагаемый процесс её решения и предполагаемые действия каждой стороны в процессе этого решения как в случае успешного развития событий так и в случае возможных неприятностей, задержек и форс-мажоров. Фактически Контракт должен являться руководством к действию и регламентов этих действий для всех участников процесса.

В реальности детальные контракты фактически не встречаются. Цель большинства реальных более-менее серьёзных контрактов – “прикрыть задницу в случае чего”, т.е. предусмотрительно подстраховаться от наиболее неприятных рисков. Это значит, что мало внимания уделяется стандартному регламенту (что делать когда все хорошо), и много внимания уделяется ситуациям форс-мажорам и плохому поведению сторон (“что делать когда все плохо”).

Более того, в как минимум 50% (на правах имхо) случаев заказной разработки Контракт как серьёзный документ с подписями и печатями вообще отсутствует. Что с моей точки зрения вполне логично для небольших проектов и случаев когда обе стороны кажутся друг другу достаточно адекватными для решения возможных споров в процессе работ без предварительных договорённостей и юридической отвественности. В таких случаях роль Контракта выполняют договорённости о порядке оплаты (например зафиксированные на сайте-аукционе типа elance.com) и документы написанные в ходе проекта.

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

Часть 1. Схемы работы

В первую очередь это порядок и условия оплаты выполненных работ. Т.е. за что, сколько и когда платит Заказчик. Рассмотрим две наиболее типичные схемы:

- fixed scope & fixed price. Эта схема взаимодействия предполагает фиксированную плату за выполение фиксированного объема работ. Объем работ оценивается разработчиком на основании представленного заказчиком ТЗ.  Оплата происходит по факту сдачи готового продукта целиком или по частям по мере сдачи продукта “частями”.

- time & material. Эта схема взаимодействия предполагает оплату времени и материалов, потраченных Разработчиком на реализацию проекта, на регулярной основе (раз в неделю, раз в месяц и т.п.) вплоть до полного окончания работ. Объем работ жестко не зафиксирован (хотя представлене об обхеме работ всегда есть) и может меняться в ходе проекта по взаимному согласию сторон.

Основное отличие описанных схем, как нетрудно заметить, заключается в фиксации объема работ. Рассмотрим их более детально.

Fixed scope & fixed price

Эта схема предполагает фиксацию определенного объема работ. Объем работ рассчитывается разработчиком на основании задачи сформулированной заказчиком. Задача обычно формулируется в виде одного или нескольких документов различной степени детализации.

Однако, учитывая сложности понимания между заказчиком и разработчиком (которые были описаны в предыдущих главах и будут раскрываться глубже в последующих) следует понимать что расчитать точный объем работ на этапе старта проекта можно только в случае наличия идеальноого и полного ТЗ и только в случае весьма высокой квалификации Разработчика. В реальности идеальное ТЗ не встречается, и квалификация людей которые работают с проектной документацией на этапе старта редко позволяет дать 100% точные оценки. Редкое ТЗ будет во всех случаях одинаково понято и Заказчиком и Разработчиком, а как известно разночтения и уточнения ведут в основном к увеличению объема работ и срыву сроков. Редкая оценка на этапе старта проекта  будет отличаться от финального результата меньше чем на 20%.

Для наглядности можно рассмотреть проекты в других областях – например ремонт квартиры. Кто-нибудь знает хоть одного человека который сделал ремонт 100% уложившись в первоначальную смету и выдержав поставленные сроки? При этом учтем что ремонты в своих жилищах люди делают уже не первую тысячу лет, а разработке ПО от силы лет 30.

Поэтому следует признать что что в случае такой схемы работы Разработчик вынужден обещать то, в чем не может быть уверен. Отсюда следует нелюбовь разработчиков к жестким фиксированным контрактам. Для компенсации рисков неточной оценки и разночтения документации при фиксированных схемах разработчик старается давать максимальные оценки трудозатрат и делать “закладки” в оценках, которые могут составлять от +10% до +50% к суммарно оцененным трудозатратам (в зависимости от опыта реализации подобных проектов и “жесткости” контракта). При чем как показывает опыт законченных проектов, и этого может оказаться мало. Также при фиксированной схеме работы Разработчик склонен завышать стоимость часа (или другой единицы) работ в сравнении с схемой time & material.

В то же время, заказчикам такая схема работы обычно нравится – так как она даёт (мнимую) гарантию “вписаться в бюджет” и наиболее похожа на привычную в обычной жизни схему “деньги – товар”.

При реализации проекта по фиксированной схеме оплаты Разработчик работает преимущественно с требованиями, и обращается непосредственно к Заказчику только в случае необходимости их уточнения. То есть, Заказчик мало вовлечен в процесс разработки, его участие предполагается в основном на этапах приёмки выполненного продукта. Замечу, что это даёт Разработчику в общем-то большую свободу действий по сравнению с time & material схемами.

Отдельную проблему для фиксированных схем представляют изменения которые вносит Заказчик в процессе разработки по мере ознакомления с готовыми частями продукта. Изменения к требованиям – вполне нормальное являение которое присутствует в подавляющем большинстве проектов. Проблемой они становятся тогда, когда Заказчик говорит что “это же написано в первоначальном ТЗ, просто вы не так поняли!”. В фиксированной схеме работы у Заказчика часто изначально присутствует уверенность что ВЕСЬ проект должен быть выполнен за оговоренную сумму, что вызывает внутренний дискомфорт в ответ на аргументированные просьбы Разработчика о дополнительной опрлате изменений. Этот внутренний дискомфорт является дополнительным мотивом для сентенций в духе “это же написано в первоначальном ТЗ, просто вы не так поняли!”. По моему опыту конифликтные ситуации связанные с изменениями требований (а значит и изменением бюджета) в проектах ведущихся по фиксированной схеме возникают фактически всегда.

После сделанного краткого обзора некоторых важных моментов попробуем просто перечислить плюсы и минусы схемы fixed price & fixed scope для Заказчика и Разработчика.

- плюсы для Заказчика: максимально точная оценка бюджета и сроков до начала работ, малая вовлеченность в проект (мало личной ответственности), чувство уверенности на этапе старта проекта

- минусы для Заказчика: бюджет со скрытыми “перезакладами” (шанс заплатить больше чем надо), малая вовлеченность в проект (меньше знаешь что происходит, меньше рычагов влияния), сложность согласования изменений

- плюсы для Разработчика: большая свобода в принятии решений (ограничена только требованиями, нет непосредственного контроля Заказчика), возможность “перезаложиться” в бюджете и “сыграть в плюс”, большая цена часа работ

- минусы для Разработчика: высокие риски “попасть” на неоплаченные трудозатраты вследствие неверной интерпретации требований и неточных оценок, необходимость “учесть все” на этапе предварительных договорённостей, до начала работ, которая ведет к большим трудозатратам на оценки и анализ

Исходя из данного понимания можно рекомендовать схему fixed price & fixed scope для следующих случаев и/или их совокупностей:

- Заказчик некомпетентен в сфере ИТ, формулирует требования со стороны бизнеса  и оставляет высокую свободу реализации интерфейса (дизайн, usability) Разработчику, а также мало вмешивается в проект во время разработки

- Заказчику крайне важно вложиться в заданный бюджет при этом он готов ограничить функционал следуя рекомендациям Разработчика

- Требования Заказчика сформулированы максимально чётко, Заказчик не заинтересован в каких-либо изменениях по ходу проекта

- Разработчик имеет большой опыт реализации аналогичных (функционал, технологии) проектов и уверен в точности оценок

- Разработчик привлекает к проекту исключительно высококлассных специалистов (что понятным образом отражается на цене проекта) и “прописывает” в контракте чёткую и детальную схему обработки запросов на измнения требований

Фиксированных схем работы следует категорически избегать в следующих случаях:

- Заказчик понимает что требования еще не до конца сформулированы и в процессе реализации проекта могут появляться многочисленные изменения

- Заказчик является специалистом в сфере разработки ПО и хочет иметь полный контроль над разработкой и участвовать в принятии технических решений

- Разработчик привлекает к проекту специалистов среднего и начального уровня (что может понизить цену проекта)

- Требования написаны откровенно плохо, и ни у Заказчика ни у Разработчика нет ресурсов для их “приведения в порядок”

При работе по фиксированной схеме максимум внимания на этапе подготовки к старту проекта надо уделить детальному анализу требований и проработке архитектуры проекта для уточнения оценок.

Time & Material

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

Одним из крайних вариантов работы по такой схеме является вариант “body-shop”, в котором Заказчик ареднует персонал у фирмы-Разработчика и самостоятельно управляет всем ходом рзработки, при этом фирма-Разработчик несет ответсвтенность за уровень квалификации персонала и организацию рабочих мест. Более типичным вариантом является разделение обязанностей таким образом, что Заказчик отвечает за функциональные и интерфейсные решения (что надо сделать и как оно должно быть организовано), а Разработчик фокусируется на технических аспектах (как именно мы это реализуем и какие компоненты будут использованы).

Типичными проблемами возникающими при такой схеме работы являются:

- “Размытие” зон ответственности – стороны увлекаются, забывают зоны своей ответственности, Разработчик начинает придумывать функционал а Заказчик даёт советы программистам как писать код – в результате обычно происходят странные и непонятные конфликты

- “Размытие” бюджета – Заказчик увлекается изменениями и “ударяется в перфекционизм”, в результате бюджет может значительно превысить первоначальную оценку, а в некоторых случаях даже “неожиданно закончиться”

- Постоянные личные контакты между Заказчиком и Разработчиком персонализуют конфликты – в рабочих моментах могут появляться элменты личных отношений которые мешают нормальной работе

Рассмотрим общие плюсы и минусы этой схемы для Заказчика и Разработчика:

- плюсы для Заказчика: возможность лично контролировать ход разработки, большая информированность о ходе работ и возможность увидеть промежуточные результаты, легкость в изменении требований и вводе дополнительного фукнционала, обычно стоимость часа ниже чем в fixed схеме

- минусы для Заказчика: слабая определенность общего бюджета и сроков проекта, личная отвественность за результаты (может рассматриваться как +), возможность “увлечься”

- плюсы  для Разработчика: часть ответственности за результат несёт Заказчик (в случае проблем “всё свалить на Разработчика” не получится), регулярность платежей, возможность привлечь к проекту специалистов среднего и начального уровня

- минусы для Разработчика: меньше свободы в принятии решений, часто необходимость обучать Заказчика в процессе разработки, слабый уровень документации – большая часть общения происходит в письмах и устно

Схема Time & Material рекомендуется в следующих случаях:

- Заказчик является специалистом в области разработки ПО и хочет контролировать разработку

- Заказчик  понимает “сырость” требований и возможность множества изменений и готов вовлекаться в процесс разработки для уточнения требований по мере необходимости

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

При подготовке старту проекта по схеме time & material особое внимание нужно уделить разделению ответственности между Заказчиком и Разработчиком.

Часть 2. Milestones, Deliverables или кто кому что когда должен

Вторым важным аспектом, о котором нужно договариваться до старта работ по проекту является последовательность, порядок и сроки передачи артефактов между Заказчиком и Разработчиком.

Во всех проектах в процессе или по окончании работ Разработчик передаёт Заказчику результаты своего труда. Также во всех проектах Заказчик отвечает за своевременное предоставление ТЗ и другой необходимой информации. Кроме того, в некоторых проектах Заказчик должен передать Разработчику важные для разработки артефакты, такие как например дизайн сайта, код предыдущего проекта, инструментарии разработки, спецификации доступа к рабочей среде проекта и т.п. О таких артефактах и пойдет речь.

Сразу замечу, что задержки в пердоставлении артефактов являются типичной причиной срыва установленных сроков. Собственно, сроки сдачи обычно привязаны к передаче определенных артефактов (результатов работ) от Разработчика к Заказчику. При этом не всегда и не все понимают что несвоевременное предоставление ТЗ и уточнений от Заказчика, а тем более таких вещей как дизайн, компоненты разработки и спецификации среды на этих самых сроках отражается самым непосредственным образом. Тут важно понимать, что изучение информации и артефактов, пердоставленных Заказчиком, обычно требует некоторого времени на стороне Разработчика. В процессе изучаения могут возникнуть вопросы, на выясненние которых требуется дополнительное время. Грамотные Разработчики при планировании сроков сдачи проекта выделяют на это определенные “закладки” времени. В случае срыва сроков передачи информации/артефактов Заказчиком времени на детальное изучение и выяснение вопросов может не хватить. Некоторые Разработчики ради сохранения общих сроков сдачи “урезают” это время. В результате информация изучается недостаточным образом, что ведет к росту количества дефектов на этапе сдачи проекта. Таким образом срыв сроков поставки Заказчиком на пару дней элементарно может привести к срыву сроков сдачи проекта на неделю.

Поэтому важно:

- ещё на этапе подготовки к старту проекта определить списков всех (важных) артефактов которые подлежат передаче между сторонами в процессе разработки

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

- чётко определить зависимости между артефактами и прописать в Контракте (либо заменяющих его документах) последствия сдвига сроков (например, задержка в предоставлении дизайна ведет к аналогичной задержке при сдаче проекта)

- при планировании сроков предусмотреть время необходимое на изучение представленной информации/артефактов и выяснение возможных вопросов

Все это вполне логично может быть увязано с планированием ключевых “вех” проекта или milestones.

Типичной частью Контракта (или заменяющих его документов) является сводный план проекта в виде списка ключевых “вех” проекта – milestones. Для схем типа fixed price & fixed scope в этом же плане к “вехам” “привязываются платжеи. Для схем типа time & material “вехи” проекта служат для определения сроков завершения всего проекта и расчета приблизительного бюджета проекта. Приведу примеры такого сводного плана:

Пример 1

Milestone	Milestone Description	Milestone Acceptance	Payment €
Development start	All the conditions are discussed, the set of functions is described, and Proposal for Development (PFD) is written and approved. Prepayment is completed.	Milestone is accepted as soon as payment is made. After this development is started
Stage1 Version End	Features from 4. Project Cost and Duration that are marked as Stage1 () are ready and work on Contractor’s side. Payment for this stage is completed.	Customer has 3 working days after the delivery to test Stage1 version. After this period payment has to be made
Stage2 Version End	Features from 4. Project Cost and Duration that are marked as Stage2 () are ready and work on Contractor’s side. Payment for this stage is completed.	Customer has 3 working days after the delivery to test Stage2 version. After this period payment has to be made
Stage3 Version End	Features from 4. Project Cost and Duration that are marked as Stage3 () are ready and work on Contractor’s side. Payment for this stage is completed.	Customer has 3 working days after the delivery to test Stage2 version. After this period payment has to be made
Acceptance finish	All functionality is deployed and tested on Customer’s side. Customer has approved and accepted functionality.	Customer has 5 working days to test Final version. Contractor fixed all the bugs which were found during 5 working days since Final version delivery. After this period payment has to be made.

Пример 2:

Milestone	Patch Delivery Date	Payment Ammount	Payment Date	Description
Kick-off		$3075 (20%)	Week 0	Prepayment
Cross-cutting functionality – logging	Week 3	$2306 (15%)	Week 4	Code review passed, QA passed with acceptable defect ratio
Single-Sign on (SSO) Login	Week 4	$2306 (15%)	Week 5	Code review passed, QA passed with acceptable defect ratio
Configuration Page	Week 7	$2306 (15%)	Week 8	Code review passed, QA passed with acceptable defect ratio
Just-in-time account creation and updates	Week 7	$2307 (15%)	Week 8	Code review passed, QA passed with acceptable defect ratio
Code Complete	Week 9	$3075 (20%)	Week 10	Overall project scope accepted, functional and QA passed, all revealed defects are either fixed or agreed as NTBF

Как можно заметить, в приведенных примерах присутствуют:

- название “вехи”/milestone

- краткое описание которое позволяет понять что собственно является критерием завершения “вехи”

- планируемый срок сдачи “вехи”

- сумма платежа по сдаче “вехи” (оба примера из проектов по fixed схемам)

- максимальный срок проведения платежа

Создание сводного плана “вех” проекта – milestones planning – и есть суть всего этапа подготовки к заключению Контракта (либо заменяющих его…) и подготовки к старту проекта.

Отдельно хочу остановиться на таком понятии как “критерии сдачи”. Чёткое и ясное определение критериев сдачи/приёмки для каждой “вехи” (milestone) проекта является одним из очень важных моментов для успешного завершения проекта. Пожалуй, даже не менее важным чем полнота, ясность и непротиворечивость требований.

В общем случае, критерии сдачи/приёмки обычно определяются как ссылки на соответствующие разделы ТЗ и указание что этот раздел должен быть выполен. Однако, сразу замечу, что этого не достаточно. Кроме определения “что должно быть сделано” большой важностью обладают определения “как это будет представлено” и “процедура проверки”. И еще один момент – типичной ситуацией является “забывчивость” сторон на момент подготвки к старту проекта про возможные дефекты. Разберем все четыре аспекта подробнее:

- “что должно быть сделано”. В общем случае может быть ссылкой на определенные разделы ТЗ. Однако вспомним простую истину – “ТЗ не бывает идеальным!”. Ошибки в интерпретации и неоднозначности ТЗ ведут “размытию” критериев приёмки, конфликтам при сдаче и срыву сроков. Кроме этого, в ТЗ в большинстве случаев описывают преимущественно функциональные требования,  а нефункциональные требования (напрмер, производительность) приводят отдельным пунктом на который критерий приёмки уже не ссылается.

- “как это будет представлено”. Предположим ситуацию когда на этапе подготовки к старту проекта вопрос “в какой среде будем показывать” вообще не обсуждается. В процессе работы выясняется что Заказчик хочет все проверять в своей среде. При этом среда Заказчика может весьма отличаться от среды разработки и “подгонка” приложения к среде Заказчика потребует дополнительных незапланированных трудозатрат. Другие типичные ситуации – Заказчику может быть не удобно проверять проект в среде представленной Разработчиком; предполагаемая среда показа не позволяет проверить некоторые требования (например нефукциональные); среда в которой происходит “показ” этапов проекта значительно отличается от production environment, т.е. среды в которой будет “жить” проект после выхода в live, поэтому то что все время работало вдруг перестаёт работать.

- “процедура проверки”. В некоторых случаях на этапе подготовки к старту проекта вообще не рассматриваются например такие вопросы как “сколько времени нужно заказчику на проверку полученной версии?” и “а как Заказчик будет представлять Разработчику свой feedback?”. В результате такой невнимательности Заказчик может всё еще принимать версию 1 когда уже будет готова версия 2, а свои замечания писать Разработчику в ICQ требуя срочно все исправить.

- “забыли про дефекты”. Часто бывает, что при приёмке определенного этапа проекта Заказчик требует устранить все, в том числе косметические дефекты. С точки зрения разработки это не всегда логично, иногда удобнее фиксить мелкие дефекты уже на следующем этапе разработки.

После такого печального обзора “типичных ляпов” сформулирую важные рекомендации касательно критериев сдачи/приёмки:

- всегда планируйте “вехи” с учетом реализации нефункциональных требований

- если ТЗ не позволяет чётко определить что именно должно быть готово – либо доработайте ТЗ, либо приводите списки готового функционала к каждой “вехе”, либо запланируёте уточнение требований и критериев приёмки в процессе разработки (и “пропишите” это в Контракте рядом с планированием “вех”!), либо, наконец, отдельно впишите в Контракт что “если интерпретация требований позволяет двусмысленное толкование – то соответсвтие любому из возможных толкований является достаточным условием для приёмки”

- обязательно соберите и зафиксируйте в Контракте либо заменяющих его документах планируемые среды разработки, показа и “жизни” (live) приложения, а также какая сторона (Заказчик или Разработчик) ответчает за готовность конкретной среды обеспечить сдачу/приёмку в нужный момент времени, и, соответственно, ответственность указанной стороны за возможный срыв сроков по причине неготовности среды.

- для каждой “вехи” проекта и версии приложения, которая подлежит сдаче/приёмке, определите сроки в течение которых должны быть завершены все приёмочные/сдаточные активности. Кроме того, желательно перечислить такие активности в явном виде.

- обязательно опеределите в какой форме принимаются замечания и пожелания по доработке/устранению дефектов. Рекомендуется использование специализированных issues tracking систем.

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

- в любом случае достигнутую договорённость про обработку замечаний Заказчика пр приёмке версии надо фиксировать в максимально чётком виде в Контракте либо заменяющих его документах.

Пока всё. Многие из описанных в этой части моментов будут раскрываться более подробно в следующих главах.

Часть 3. Наконец, Контракт!

Теперь попробую сделать то что обещал еще в начале главы – свести воедино основные рекомендации на тему “что должно быть  договорено и записано” вне зависимости от размера проекта и наличия собственно Конртакта как юридического документа, либо работы через сайт-аукцион. Итак:

- краткая суть проекта и ссылка на ТЗ

- контакты обеих сторон и желаемые сроки ответа на запрос с каждой стороны

- степень вовлеченности Заказчика в процесс разработки – если заказчик отвечает не только за ТЗ и приёмку то это лучше указать

- выбранная схема работы – fixed или time & material -  и условия оплаты (когда, каким образом)

- сводный план проекта в виде “вех”/milestones и сроков

- перечень артефактов передаваемых в процессе разработки с указанием кто за что и когда отвечает, желательно со сроками и привязкой к “вехам”

- перечень сред в проекте с указанием кто за что отвечает

- критерии приёмки для каждоей “вехи” и версии приложения, желательно также указать событие после которого версия считается приятной (хотя-бы email от заказчика где написано “версию принял”, для юридических контрактов – акты приёмки сдачи с подписями сторон)

- порядок обработки дефектов и запросов на изменения

- действия в случае форс-мажоров (как минимум предусмотреть порядок остановки проекта в случае екстренных событий)

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

Если вы ничего не забыли и все договорено и прописано – может быть в 500-страничном Контракте с подписями Президентов Компаний, а может быть и email’ах – главное чтобы обе стороны принимали действительность этих договорённостей – можно стартовать проект.

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

Также хочу обратить внимание на одинаковую важность описанных аспектов и моментов предварительных договорённостей как для Заказчика, так и для Разработчика. Если вы Заказчик, и рассчитываете “нагибать” Разработчика в процессе разработки благодаря неточностям в контракте и при этом получить то что заказываете – вряд ли у вас что-то выйдет…