Договор на разработку сайта/мобильного приложения при работе по scrum
10 Августа 2017
Людям, не искушенным в документообороте, этот текст может показаться довольно запутанным. А тем, для кого оформление контрактов — рутина, наоборот, слишком простым. Но нас часто спрашивают, как у нас организована работа по scrum с точки зрения документооборота, и как выглядят наши договоры.
Даже если вам покажется, что получается слишком много бумаг, или всё слишком сложно — это не так. Мы используем простые и понятные контракты, в которых проработаны интересы как клиента, так и студии. Адекватно. Без перегибов. На уровне здравого смысла. Моя политика простая — либо win-win, либо не связываться.
Наши шаблоны договоров рассчитаны в первую очередь на работу по scrum. То есть на итеративную разработку, когда проект запускается поэтапно. Сначала — самые важные с точки зрения бизнеса функции. С которыми уже можно жить и обеспечивать продажи. Затем системно выпускаются новые версии. Состав работ можно менять на ходу — что-то убирать, добавлять или заменять на равноценные функции. Это позволяет заказчику проверить свою бизнес-идею и запустить самое важное как можно быстрее. Поэтому мы подписываем с заказчиком рамочный договор, где фиксируем общие условия сотрудничества. Принципы. То, на чем пожали руки. На отдельные этапы работ мы подписываем приложения к договору.
Мы сделали документы максимально простыми для работы (в смысле, с ними менеджерам становится сложно сделать грубую ошибку при подготовке документов). Все, что касается общих условий сотрудничества, вынесли в рамочный договор. Убрали дублирование положений. В приложениях остались только моменты, касающиеся непосредственно этапов работ. Спринтов. В конце статьи мы поделимся ссылками на шаблоны рамочного договора и некоторых приложений.
Если вы пользуетесь нашими шаблонами образца 2015 года — обратите внимание, что новые шаблоны приложений совсем не совместимы с ними. Чтобы начать пользоваться новыми шаблонами, обязательно перезаключите рамочный договор с заказчиком.
Подготовка договоров и приложений
В начале работы над проектом вместе с рамочным договором мы подписываем приложение на агрегацию требований.
Мы исходим из предпосылки, что ни клиент, ни мы сами точно не знаем, как и в каком виде лучше всего сделать проект. И нужно выполнить предпроектную работу:
— выделить стейкхолдеров, составить цели проекта, если возможно — оцифровать в виде KPI;
— изучить пути пользователей по сайту;
— поработать с семантикой или, используя метод персон, определиться с наиболее важными функциями.
Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах 24-60 часов. К тому же только после этапа агрегации требований у нас появляется согласованная структура, верхнеуровневый roadmap будущего проекта: мы можем уточнить список страниц, которые необходимо прототипировать.
Вторым этапом мы подписываем приложение на разработку прототипов страниц, и, если этого просит клиент, — технического задания. В классическом scrum-е технического задания не предполагается, вместо него используется бэклог — список всех хотелок, которые клиент хочет когда-нибудь реализовать. Однако многие по старинке хотели бы иметь такой документ. Проблем нет, мы его готовим, причем именно с той целью, чтобы затем раздербанить на бэклог. Наличие технического задания на проекте не заставляет нас строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.
Далее нам нужно собрать первую версию программного продукта. От которой будем дальше плясать и итеративно развивать во что-то более глобальное. Замечу, что первая версия должна быть функциональной. Она должна быть «клёвенькая», а не полуфабрикат, на который жалко смотреть. Тут — работает, тут — не работает, тут — рыбу заворачивали. Такая версия может быть разработана за несколько спринтов. То есть не факт, что итог первого же спринта пойдет реальным пользователям на боевой сервер. Это несколько противоречит концепции scrum образца 2000-го года, но лучше вписывается в современные подходы и адекватнее воспринимается разработчиками и заказчиками.
Итак, у нас последовательно подписываются приложения на дизайн, верстку и разработку для первой инкарнации проекта. Для небольших версий проектов мы можем объединить их в одно приложение. Для больших — приложения подписываем по отдельности. При этом у нас есть бэклог, в котором содержатся хотелки на следующие этапы, и, в отличие от договора, это документ живой.
Совершенно логично, что у нас есть шаблон приложения на отдельные спринты. Набрали из бэклога задач на спринт — зафиксировали список и состав работ, предварительные оценки. Побежали делать. Бывает, что для старта программирования по спринту (по очередной версии) нужно проделать и аналитику (например, порисовать прототипы), и дизайн порисовать, и ресерч какой-то провести, и интеграционный протокол составить. Проблем нет, структура наших приложений и договора это позволяет. Замечу, что в большей своей массе работа по спринтам идет по четким оценкам срока и бюджета. Если есть сомнения — аналитику выносим в отдельный этап.
В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.
Поэтому есть разумная альтернатива. После того, как мы с клиентом притерлись, знаем, что друг от друга ожидать — вполне логично перейти с итераций в режим канбана с оплатой работ по факту затраченных работ. Клиенту создается канбан-доска, куда он может накидывать задачи и ставить приоритеты. Крупные задачи будут обработаны спринтами. Мелко-срочные — в порядке очереди, но по более высокому рейту. Для работы в таком формате мы подписываем приложение на техническую поддержку. Оно рассчитано на работу по отдельным задачам или небольшими спринтами.
Не забываем, что мы говорим про разработку по scrum. Поэтому в ходе работ у нас может поменяться список задач на следующий этап, по которому приложение уже подписано. В этом случае мы заключаем с заказчиком дополнительное соглашение к приложению, в котором фиксируем только те пункты, которые изменились. Наши шаблоны приложений построены так, что по сути мы переподписываем только смету.
Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:
— Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
— Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам.
— Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.
— Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.
Подробный кейс читайте в блоге scrum-студии «Сибирикс» — blog.sibirix.ru/2017/07/12/contract-2017/.
В приложении к статье — джентльменский набор документов. Рамочный договор. Приложение на аналитику (агрегацию требований). И комплексное приложение на одну итерацию разработки. Остальные приложения (кроме, пожалуй, техподдержки и работы по канбану) логично вытекают из этих документов (да и нам просто жадно). Шутка.
Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами (tagline.ru/agile-digital-management-school/). Присоединяйтесь!
Даже если вам покажется, что получается слишком много бумаг, или всё слишком сложно — это не так. Мы используем простые и понятные контракты, в которых проработаны интересы как клиента, так и студии. Адекватно. Без перегибов. На уровне здравого смысла. Моя политика простая — либо win-win, либо не связываться.
Наши шаблоны договоров рассчитаны в первую очередь на работу по scrum. То есть на итеративную разработку, когда проект запускается поэтапно. Сначала — самые важные с точки зрения бизнеса функции. С которыми уже можно жить и обеспечивать продажи. Затем системно выпускаются новые версии. Состав работ можно менять на ходу — что-то убирать, добавлять или заменять на равноценные функции. Это позволяет заказчику проверить свою бизнес-идею и запустить самое важное как можно быстрее. Поэтому мы подписываем с заказчиком рамочный договор, где фиксируем общие условия сотрудничества. Принципы. То, на чем пожали руки. На отдельные этапы работ мы подписываем приложения к договору.
Мы сделали документы максимально простыми для работы (в смысле, с ними менеджерам становится сложно сделать грубую ошибку при подготовке документов). Все, что касается общих условий сотрудничества, вынесли в рамочный договор. Убрали дублирование положений. В приложениях остались только моменты, касающиеся непосредственно этапов работ. Спринтов. В конце статьи мы поделимся ссылками на шаблоны рамочного договора и некоторых приложений.
Если вы пользуетесь нашими шаблонами образца 2015 года — обратите внимание, что новые шаблоны приложений совсем не совместимы с ними. Чтобы начать пользоваться новыми шаблонами, обязательно перезаключите рамочный договор с заказчиком.
Подготовка договоров и приложений
В начале работы над проектом вместе с рамочным договором мы подписываем приложение на агрегацию требований.
Мы исходим из предпосылки, что ни клиент, ни мы сами точно не знаем, как и в каком виде лучше всего сделать проект. И нужно выполнить предпроектную работу:
— выделить стейкхолдеров, составить цели проекта, если возможно — оцифровать в виде KPI;
— изучить пути пользователей по сайту;
— поработать с семантикой или, используя метод персон, определиться с наиболее важными функциями.
Эта работа стоит денег, но она — относительно дешевая. Заказчику психологически проще оплатить первый счет, когда он в пределах 24-60 часов. К тому же только после этапа агрегации требований у нас появляется согласованная структура, верхнеуровневый roadmap будущего проекта: мы можем уточнить список страниц, которые необходимо прототипировать.
Вторым этапом мы подписываем приложение на разработку прототипов страниц, и, если этого просит клиент, — технического задания. В классическом scrum-е технического задания не предполагается, вместо него используется бэклог — список всех хотелок, которые клиент хочет когда-нибудь реализовать. Однако многие по старинке хотели бы иметь такой документ. Проблем нет, мы его готовим, причем именно с той целью, чтобы затем раздербанить на бэклог. Наличие технического задания на проекте не заставляет нас строго следовать его букве. Конечный состав работ определяется СМЕТАМИ в приложениях на каждый отдельный спринт.
Далее нам нужно собрать первую версию программного продукта. От которой будем дальше плясать и итеративно развивать во что-то более глобальное. Замечу, что первая версия должна быть функциональной. Она должна быть «клёвенькая», а не полуфабрикат, на который жалко смотреть. Тут — работает, тут — не работает, тут — рыбу заворачивали. Такая версия может быть разработана за несколько спринтов. То есть не факт, что итог первого же спринта пойдет реальным пользователям на боевой сервер. Это несколько противоречит концепции scrum образца 2000-го года, но лучше вписывается в современные подходы и адекватнее воспринимается разработчиками и заказчиками.
Итак, у нас последовательно подписываются приложения на дизайн, верстку и разработку для первой инкарнации проекта. Для небольших версий проектов мы можем объединить их в одно приложение. Для больших — приложения подписываем по отдельности. При этом у нас есть бэклог, в котором содержатся хотелки на следующие этапы, и, в отличие от договора, это документ живой.
Совершенно логично, что у нас есть шаблон приложения на отдельные спринты. Набрали из бэклога задач на спринт — зафиксировали список и состав работ, предварительные оценки. Побежали делать. Бывает, что для старта программирования по спринту (по очередной версии) нужно проделать и аналитику (например, порисовать прототипы), и дизайн порисовать, и ресерч какой-то провести, и интеграционный протокол составить. Проблем нет, структура наших приложений и договора это позволяет. Замечу, что в большей своей массе работа по спринтам идет по четким оценкам срока и бюджета. Если есть сомнения — аналитику выносим в отдельный этап.
В общем случае аналитика может на два спринта идти быстрее разработки. На один спринт вперед — дизайн. Программирование — догоняет. А за программированием идет опять аналитика (сбор обратной связи от пользователей и генерация новых функций). Это позволяет добиться высокой утилизации, но довольно сложно управляется. Нагрузка высокая, причем на менеджера и со стороны студии, и со стороны заказчика. Много бумаг, много потоков, много нужно держать в голове. Но это цена за точные оценки сроков и бюджетов, их фиксацию в договоре и высокую скорость работ.
Поэтому есть разумная альтернатива. После того, как мы с клиентом притерлись, знаем, что друг от друга ожидать — вполне логично перейти с итераций в режим канбана с оплатой работ по факту затраченных работ. Клиенту создается канбан-доска, куда он может накидывать задачи и ставить приоритеты. Крупные задачи будут обработаны спринтами. Мелко-срочные — в порядке очереди, но по более высокому рейту. Для работы в таком формате мы подписываем приложение на техническую поддержку. Оно рассчитано на работу по отдельным задачам или небольшими спринтами.
Не забываем, что мы говорим про разработку по scrum. Поэтому в ходе работ у нас может поменяться список задач на следующий этап, по которому приложение уже подписано. В этом случае мы заключаем с заказчиком дополнительное соглашение к приложению, в котором фиксируем только те пункты, которые изменились. Наши шаблоны приложений построены так, что по сути мы переподписываем только смету.
Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:
— Использовать единые шаблоны договоров. Каждый новый договор мы обязательно делаем из шаблона, а не из договора от предыдущего заказчика. Чтобы руководителям проектов было проще при подготовке документов, места, которые могут меняться, выделены в цветом.
— Править шаблон сразу, если обнаружили в договоре какую-то нестыковку или неожиданный нюанс (которым, естественно, больно прилетело по лбу). Так важные изменения в договорах гарантированно будут тиражироваться по всем последующим документам.
— Периодически проводить ревизию шаблонов и актуализировать их. Мы обычно делаем это один-два раза в год.
— Не отправлять договоры заказчикам без дополнительной проверки. При проверке приложений дополнительно надо обращать внимание на сроки, сверять все строки сметы, пересчитывать итоговые суммы.
Подробный кейс читайте в блоге scrum-студии «Сибирикс» — blog.sibirix.ru/2017/07/12/contract-2017/.
В приложении к статье — джентльменский набор документов. Рамочный договор. Приложение на аналитику (агрегацию требований). И комплексное приложение на одну итерацию разработки. Остальные приложения (кроме, пожалуй, техподдержки и работы по канбану) логично вытекают из этих документов (да и нам просто жадно). Шутка.
Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами (tagline.ru/agile-digital-management-school/). Присоединяйтесь!
Последние новости раздела
18 апреля 2024