Home / Руководство по принятию решений по проектам / Модель предложения по аутсорсингу программного обеспечения
PROJECT DECISION GUIDE

Модель предложения аутсорсинга программного обеспечения: фиксированная общая цена, индивидуальные месяцы или вехи

Эти котировки определяют не только темпы платежей, но и то, как распределяются между двумя сторонами обязанности по изменению спроса, риска прогресса, вклада и принятия команды.

Отвечай на вопрос.

Модель котировки аутсорсинга программного обеспечения

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

SCOPE & BUDGET LEVELS

Во-первых, четкие входы в границу по фазе проекта.

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

Фаза 1

Фиксированная валовая цена

Пункты, пригодные для стабильного охвата, четкой периодичности и объективного принятия

Предварительное таргетирование базовых потребностей, общей цены, вех, принятия, изменения и расширения ответственности

Фаза 2

Замки с фазой

сцены, подходящие для сложных проектов, и сначала необходимо проверить ключевые риски;

Объем и бюджет по диагностическим, прототипным, MVP, пилотным и производственным этапам соответственно

Фаза 3

Сотрудничество в разбивке по месяцам или циклам

Подходит для постоянного изменения спроса, долгосрочного итеративного или внутреннего пополнения команды

Роли, время для участия, правила участия, отчеты о результатах, приоритеты и передача выхода

DECISION FACTORS

Ключевые элементы, подлежащие проверке для принятия решений

Сначала выявляются границы сдержанности и ответственности, затем сравниваются технические пути и условия сотрудничества.

01

Уровень стабильности спроса

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

02

Технологии и внешняя неопределенность

Старые коды, эффекты AI, сайты IOT, сторонние интерфейсы и качество данных должны быть сначала проверены и пригодны для индивидуальной диагностики или фазовых котировок.

03

Быстрое участие клиентов и принятие решений

Своевременное участие владельцев продуктов, интерфейсов и приемных сотрудников напрямую влияет на эффективность сотрудничества и циклическую ответственность.

04

Прозрачность ролей и вклада в работу команды

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

05

Доставка и контроль активов

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

06

Механизмы изменения, прекращения и изъятия

Необходимо договориться о том, как будут оцениваться изменения, как будут урегулированы этапы, как будут передаваться достигнутые результаты и что не было завершено на момент прекращения сотрудничества.

Подготовка рекомендаций до сообщения или оценки

Стабильна ли диапазон спроса?Проверка ключевых технологических рисковПотолок бюджета и темп выплатыРуководитель проекта и механизм проверкиРоль команды и потребности в ее вкладеДоставка на каждом этапеПринятие и принятие и изменение правил требованийПередача активов после прекращения сотрудничества

Предлагаемый путь к осуществлению

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

DECISION WORKSHEET

Перевод модели предложения аутсорсинга программного обеспечения в принудительное принятие решений

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

Что должно содержать сопоставимое резюме оценок?

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

Например, предприятие ожидает, что проект позволит сэкономить 160 часов труда в месяц, но этот показатель следует разбить на число задач, экономию времени, коэффициенты принятия и коэффициенты ручного обзора. Если только 40 процентов пользователей используют первый период, или если новый процесс увеличивает процесс обзора, фактические выгоды будут значительно ниже, чем кажущаяся оценка.

Четыре типа доказательств, рекомендуемых для допроса во время общения с продавцом

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

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

Принцип суждения

Эта страница предоставляет структуру принятия решений, которая не представляет собой фиксированное предложение или обязательство по производительности.

FAQ

FAQs

Наиболее распространенные вопросы перед сотрудничеством четко излагаются заранее.

Является ли фиксированная общая цена лучшей гарантией для клиента?+

Низкие фиксированные общие цены могут легко привести к упущениям, частым изменениям или сжатию качества, когда спрос нестабилен.

Как можно работать вместе каждый месяц, чтобы избежать неэффективности?+

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

Можем ли мы составить другую цитату?+

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

DECISION FAQ

Общие вопросы, связанные с текущими проектами

Проверить 265 вопросов.
Разработка программного обеспечения и аутсорсинг проектов

Каким должен быть выбор программных аутсорсинговых и самостроевых команд?

Аутсорсинг программного обеспечения обычно более эффективен, если бизнес требует долгосрочного континуума и предприятие имеет возможности управления продуктами и технологиями.Если цель четко определена, требуется быстрый запуск или существует временная нехватка выделенных мощностей, многие предприятия сохраняют владельцев продуктов и технологий, оставляя фазу НИОКР или выделенное строительство внешней команде.

Смотреть полный ответ
Разработка программного обеспечения и аутсорсинг проектов

Что выбрать Shanghai Software Outsourcing?

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

Смотреть полный ответ
Разработка программного обеспечения и аутсорсинг проектов

Является ли программное обеспечение аутсорсингом для выбора фиксированных валовых цен или для совместной работы на ежемесячной основе?

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

Смотреть полный ответ
Контракты, платежи, изменения и реализация проектов

Как вы устанавливаете платежные узлы и коэффициенты оплаты для программного проекта?

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

Смотреть полный ответ
RELATED

Сохраняйте свои знания об услугах

Представление оценки проекта