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