Как оформить услугу доработки готового программного продукта

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

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

Начните с задачи бизнеса и границ доработки

Опишите, какую рабочую задачу должна решить новая функция. Формулировка «сделать программу удобнее» оставляет слишком много вариантов. Более понятное задание: «Менеджер должен находить заказы по номеру телефона клиента, чтобы не просматривать весь список вручную».

Разделите описание на три части: как программа работает сейчас, что нужно изменить и какой результат ожидается. Например: сейчас сотрудник переносит сведения о заказе в учётную систему вручную; требуется передавать подтверждённые заказы автоматически; после передачи в обеих системах должны совпадать состав заказа и его номер.

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

Также перечислите, что не включено в доработку. Например, добавление фильтра в отчёт не предполагает изменения расчётов, переработки всех экранов или переноса старых данных. Это помогает отличать согласованную работу от пожеланий, которые появятся позже.

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

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

Название, версия и способ использования

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

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

Исходный код и технические материалы

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

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

• Исходный код с указанием версии, которая используется в рабочей программе.
• Инструкцию по запуску и установке продукта.
• Описание базы данных — структуры хранения заказов, клиентов и других сведений.
• Список внешних сервисов и подключений.
• Документацию по прежним доработкам.
• Перечень известных ошибок и ограничений.
• Контакты специалиста, который поддерживает программу.

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

Права и доступы

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

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

Как проверяется возможность изменений

Проверка возможности доработки — это обследование текущего продукта перед основной разработкой. Её можно оформить отдельным этапом с собственным результатом. Так проще согласовать, что именно проверяет исполнитель и на основании чего он затем оценивает сроки и стоимость.

Проверка запуска и соответствия версии

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

Проверять изменения желательно на отдельной копии программы. Тестовая среда — это место, где можно выполнять проверки без воздействия на текущую работу сотрудников. Для неё нужны подходящие настройки и данные. Если используются копии рабочих данных, заранее определите, какие сведения следует скрыть или заменить.

Проверка связей и ограничений

Исполнитель выясняет, какие части программы связаны с изменяемой функцией. Например, поле «статус заказа» может участвовать в списке заказов, отчётах, уведомлениях и обмене с другой системой. Изменение вариантов статуса требует проверки всех этих связей.

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

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

После проверки попросите заключение на понятном языке. В нём стоит отразить:

• Какие материалы и функции проверены.
• Какие сведения или доступы пока отсутствуют.
• Каким способом предлагается выполнить доработку.
• Какие существующие функции будут затронуты.
• Какие предварительные работы необходимы.
• Какие ограничения и неопределённости остаются.
• Что входит в последующую оценку работ.

Заключение должно различать подтверждённые выводы и предположения. Например: запуск программы проверен, но передача данных поставщику ещё не проверена, потому что нет тестового доступа. Такой пункт нельзя считать решённым только на основании общего обещания «интеграцию сделаем».

Как описать требования к новой функции

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

Вместо «добавить экспорт» укажите: «Менеджер выбирает период и выгружает список заказов в файл. В файл попадают номер заказа, дата, клиент, сумма и статус. Применённые на экране фильтры учитываются при выгрузке».

Опишите и ситуации, в которых обычный сценарий не срабатывает: данных нет, обязательное поле не заполнено, связь с внешним сервисом прервалась, пользователь не имеет нужных прав. Для каждой ситуации определите ожидаемое поведение. Например, при недоступности учётной системы заказ сохраняется, а сотрудник видит сообщение о том, что передача ещё не выполнена.

Для изменения интерфейса приложите описание экранов или простой набросок. Укажите названия полей, обязательность заполнения и место отображения результата. Набросок помогает согласовать расположение элементов, но не заменяет правила работы функции.

Как согласовать сохранение текущих функций

Требование «после доработки всё должно работать как раньше» трудно проверить. Его нужно превратить в перечень конкретных действий и ожидаемых результатов. Особенно подробно опишите операции, от которых зависит ежедневная работа бизнеса.

Зафиксируйте исходное поведение

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

Если в текущей версии есть известная ошибка, отметьте её отдельно. Сторонам нужно согласовать, входит ли исправление в работу или прежнее поведение временно сохраняется. Иначе при приёмке будет трудно определить, возникла проблема из-за доработки или существовала раньше.

Составьте таблицу проверок

Для условной доработки поиска заказов список может выглядеть так:

Текущая функция	Что требуется сохранить	Как проверить
Создание заказа	Состав товаров и расчёт итоговой суммы	Создать заказ с заранее выбранными данными
Поиск по номеру заказа	Действующий способ поиска	Найти известный заказ по его номеру
Права доступа	Ограничения для каждой роли	Проверить действия менеджера и администратора
Выгрузка отчёта	Поля и правила отбора данных	Сравнить выгрузки на одинаковом наборе заказов
Обмен с учётной системой	Состав передаваемых сведений	Проверить передачу тестового заказа

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

Отдельно обсудите сохранность данных, совместимость файлов и скорость важных операций. Если требуется измерить скорость, согласуйте действие, набор данных и условия проверки. Формулировка «программа не должна тормозить» не задаёт проверяемого требования.

Что зафиксировать в документах на доработку

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

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

Для этапов определите результат, который можно проверить: заключение обследования, согласованное задание, тестовая версия, проверенный выпуск, комплект передаваемых материалов. Условия оплаты и сроки стоит связывать с понятным объёмом работ, а не только с общим названием этапа.

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

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

Пример задания на доработку

Ниже — условный пример для программы учёта заказов. Он показывает структуру требований, а не описывает реальный проект.

Текущая работа: менеджер ищет заказы по номеру. Телефон клиента хранится в карточке заказа, но поиск по нему отсутствует.

Нужное изменение: добавить поиск по телефону в список заказов. Предусмотреть обработку пробелов, скобок и дефисов, чтобы согласованные варианты записи одного номера давали одинаковый результат.

Правила результата: показать все доступные пользователю заказы с соответствующим телефоном. Если совпадений нет, вывести понятное сообщение. Правила обработки неполного номера согласовать отдельно.

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

Приёмка: проверить поиск на подготовленных примерах с разным оформлением телефона, несколькими заказами одного клиента и отсутствующим номером. Повторить согласованные проверки прежних функций.

Не входит в работу: объединение карточек клиентов, исправление всех исторических телефонов и изменение формы оформления заказа.

Как принять результат и установить обновление

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

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

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

Частые вопросы

Можно ли заказать доработку без исходного кода?

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

Что делать, если документации нет?

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

Нужно ли исправлять все старые ошибки?

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

Как отличить ошибку от дополнительной работы?

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

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