- Выполняются работы по запуску или поддержке сайтов с оценкой каждой заявки.
- Оценки согласовываются.
- И документально включать описание задачи, её оценку в деньгах и сроках в тот или иной этап.
- Состав, цена и сроки каждого этапа определяются по итогам предыдущего, исходя из приоритетов открытых на данный момент задач.
- Подписывается договор подряда на весь проект с открытой ценой и сроками.
- Частные технические задания на каждый этап подписываются в виде приложений к договору.
- Сроки и цены на каждый этап определяются в частных технических заданиях (ЧТЗ).
- Оплата работ осуществляется по мере приемки этапов.
- Цена формируется, исходя из почасовой ставки (указана в договоре) и оценки трудозатрат по каждому ЧТЗ.
- Цена относительно высока в силу разового характера заказа (чаще всего не применяются объемные скидки).
- Цена всего проекта на старте проекта не известна. Риск недооценки отсутствует. Но зато есть риск недобюджетирования у Заказчика.
- Приемка проходит быстро по небольшим этапным частным техническим заданиям.
- Изменения и рефакторинг кода учитываются и включаются в следующее частное техническое задание.
- Сроки сокращаются за счёт распараллеливания исполнения этапа и написания задания на следующий этап. Нет большого срока на написание всеобъемлющего технического задания перед началом разработки.
- Методология привлекательна для Заказчика в силу изменчивости хода работ по проекту и предсказуемости цены за конкретный этап.
- Методология вынуждает Заказчика больше времени тратить на согласование документов (частные технические задания) и более тщательно контролировать, как изменения и новые частные технические задания влияют на скорость запуска сайта.
Веб-студия DST Global (dstglobal.ru) в течение 15 лет занимается разработкой и поддержкой. Штат нашей команды состоит из опытных разработчиков, программистов, дизайнеров, специалистов в области продвижения. Обращайтесь! Поможем полноценно реализовать бизнес в сети.
Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.
Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.
бизнес хочет зарабатывать деньги, желательно вкладывая меньше ресурсов.
при этом у бизнеса уже есть опыт, который фиксируют в методологиях.
в зависимости от типа проекта подбирают те практики, которые ему подходят и позволяют сэкономить ценный ресурс.