Договор и документы для разработки проекта по методологии SCRUM?

Question

[Ivo Dimitrov]

Возник следующий вопрос: Каким должен быть договор на разработку проекта (а вернее на дизайн, проектирование и разработку), если мы решили применить скрам в заказной разработке?


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


Пытался найти на просторах интернета — пока ничего не вышло.


Заранее спасибо.

Answer 1

[creadone]

По большому счету нет разницы, какую вы методологию используете. В договоре нужно указывать: предмет разработки, этапы, сроки, стоимость разработки, права… Все остальное не имеет отношение к договору. То есть вам подойдет любой договор на разработку ПО.

Конечно, вам никто не запрещает указать что-то в духе «во время работы над вашим проектом мы обязуемся пить кофе арабика и носить зеленые тапочки», но зачем?

Посмотрите договор Студии Лебедева, например — www.tema.ru/jj/RIBBA-sait-2009.doc

Ну а вообще, лично мое мнение (совсем не обязательно верное), что в заказной разработке применять т.н. гибкие методологии не стоит — заказчик влетит на деньги и спрыгнет в середине проекта, т.к. такие методики не позволяют просчитать проект целиком (кто знает, что будет в следующей итерации: лента новостей или интеграция с сапой?). Я бы посоветовал в вашем случае сделать итерации (проектирование, дизайн, разработка, тестирование) — отдельными проектами (или этапами с приложениями к рамочному договору), чтобы в случае разрыва отношений никто не пострадал.

Comments

[xldsakamrhahn]

>> такие методики не позволяют просчитать проект целиком (кто знает, что будет в следующей итерации: лента новостей или интеграция с сапой?)

Проект просчитывает не методика, а люди. Кто сказал, что нельзя применять методы подсчета из PMBoK? Гибкие методологии — они потому гибки, потому что можно следовать рекомендациям, а можно не следовать или следовать рекомендациям из других методологий. Во всяком случае, есть беклог продукта, а есть беклог итерации. Даже в случае гибких методологий картина должна быть понятна до конца хотя бы на 80-90%. Если изначально возникает ситуация, когда в следующей итерации непонятны даже примерно задачи к выполнению, то брать за такой проект даже не стоит.

[xldsakamrhahn]

В договоре должно быть прописано то, как будут оцениваться результаты работы. Можно ориентироваться просто на контракт и выполнять то, что точно указано там. В итоге, как правило, заказчик получает все дословно, что не несет ему удовлетворения от полученной работы. Другой вариант — ориентироваться на приемочные тесты и процедуры, которые вы также должны прописать в договоре. Если нужно защитится от заказчика — ориентируйтесь на контракт. Если хотите удержать клиента — ориентируйтесь на результаты работы.