1. Общие положения

1.1. Назначение документа

Настоящий документ представляет собой техническое задание на разработку функциональности (далее — ТЗ) и является основным правовым и техническим актом, определяющим требования к созданию, модернизации или внедрению программного обеспечения в деятельности Организации. Документ устанавливает единый порядок взаимодействия между Заказчиком и Разработчиком в части постановки задач, контроля качества и приемки результатов работ. ТЗ обязательно для исполнения всеми сторонами, участвующими в процессе разработки, включая внутренние ИТ-подразделения и привлеченных подрядчиков.

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

1.2. Правовая основа и нормативные ссылки

Техническое задание разработано в соответствии с гражданским законодательством Российской Федерации, регулирующим отношения в сфере интеллектуальной собственности и договоров подряда на выполнение проектных и опытно-конструкторских работ. Документ также учитывает требования государственных стандартов серии ГОСТ 34 по автоматизированным системам и ГОСТ 19 по программной документации. В части информационной безопасности применяются положения Федерального закона № 149-ФЗ «Об информации, информационных технологиях и о защите информации» и Приказа ФСТЭК России об утверждении состава организационных и технических мер по обеспечению безопасности.

При составлении ТЗ учитываются внутренние политики Организации в области управления ИТ-проектами, регламенты документооборота и корпоративные стандарты кодирования и документирования. В случае противоречий с корпоративными документами применяются нормы настоящего ТЗ, согласованные сторонами в установленном порядке.

1.3. Термины и определения

В настоящем документе применяются следующие термины и их определения: «Разработчик ПО» — юридическое или физическое лицо, ответственное за создание, тестирование и документирование программного продукта; «Заказчик» — уполномоченное лицо Организации, инициирующее разработку и принимающее результаты работы; «Функциональные требования» — описание поведения и функций системы с точки зрения конечного пользователя; «Нефункциональные требования» — критерии качества работы системы, такие как производительность, масштабируемость, безопасность и надежность.

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

2. Цель и область применения разработки

2.1. Цель создания системы

Целью разработки является создание программного обеспечения (модуля/сервиса), обеспечивающего автоматизацию бизнес-процессов Организации в соответствии с утвержденными регламентами. Система призвана повысить эффективность операционной деятельности за счет сокращения времени выполнения рутинных операций, снижения влияния человеческого фактора и обеспечения прозрачности управленческого учета. Ключевым ожидаемым результатом является достижение измеримых улучшений по показателям KPI, закрепленным за подразделениями и ответственными сотрудниками.

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

3. Подчиненность и организационная структура

3.1. Подчиненность ответственных лиц

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

Заказчик — владелец бизнес-процесса — участвует в управлении требованиями и приемке результатов, взаимодействуя через назначенного представителя (бизнес-аналитика). Все спорные вопросы иерархического подчинения решаются на согласительных совещаниях с участием руководителя проекта и куратора со стороны Заказчика.

3.2. Отчетные линии и взаимодействие

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

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

4. Должностные обязанности Разработчика ПО

4.4. Участие в интеграционных работах

Разработчик участвует в проектировании и реализации интеграций с внешними информационными системами, используя согласованные протоколы и форматы обмена (REST API, SOAP, Kafka, файловый обмен). Он обязан настроить и документировать точки интеграции, согласовать схемы данных и протоколы безопасности. В рамках работ проводится тестирование интеграционных цепочек, включая проверку обработки ошибок, таймаутов и повторных запросов.

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

4.5. Контроль версий и управление конфигурацией

Разработчик обязан использовать корпоративную систему контроля версий (Git) для хранения исходного кода и всей сопутствующей документации. Работа ведется по модели GitFlow с обязательным созданием pull request и проведением code review. Структура репозитория, именование веток и политика коммитов должны строго соблюдаться.

Ответственность за управление конфигурацией включает регулярное создание тегов релизов, управление зависимостями через пакетные менеджеры (Maven, NuGet, Go Modules) и поддержание актуального файла сборки (Dockerfile, скриптов CI/CD). Разработчик обеспечивает, чтобы каждый релиз был воспроизводим и имел уникальный идентификатор версии.

5. Права Разработчика ПО

5.1. Право доступа к информации

Разработчик ПО имеет право запрашивать и получать у Заказчика и смежных подразделений всю необходимую для выполнения работ информацию, включая описание бизнес-процессов, макеты экранных форм, действующие нормативные и регламентирующие документы. Доступ к конфиденциальной информации и персональным данным предоставляется согласно подписанному соглашению о неразглашении (NDA) в объеме, необходимом для выполнения должностных обязанностей.

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

5.2. Право принятия технических решений

В рамках утвержденного ТЗ Разработчик имеет право самостоятельно принимать технические решения по выбору алгоритмов, структур данных, способов реализации и оптимизации производительности в пределах выделенных ресурсов и оговоренных сроков. Принятые технические решения подлежат обоснованию в проектной документации и соответствуют выбранному архитектурному подходу (монолит, микросервисы, event-driven).

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

5.3. Право на ресурсы и инструментарий

Разработчик имеет право на использование современных средств разработки, включая интегрированные среды (IDE), системы непрерывной интеграции (Jenkins, GitLab CI), системы мониторинга и логирования (ELK, Grafana) и иной лицензионный инструментарий, утвержденный в ИТ-инфраструктуре Организации. Также предоставляется право на использование облачных вычислительных ресурсов и контейнерных сред (Kubernetes, Docker) для сборки и тестирования.

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

6. Ответственность и обязательства

6.1. Ответственность за качество и сроки

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

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

6.2. Ответственность за безопасность и конфиденциальность

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

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

6.3. Ответственность за соблюдение стандартов и регламентов

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

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

7. Квалификационные требования

7.1. Требования к образованию и опыту

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

Наличие дополнительного профессионального образования (сертификатов по Java, .Net, облачным платформам) приветствуется и рассматривается как преимущество при отборе. Опыт работы со стеком, указанным в проекте (Java, Go, .Net, 1С), должен быть документально подтвержден через ссылки на реализованные проекты и предоставленные резюме.

7.3. Надпрофессиональные навыки (Soft Skills)

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

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

8. Условия работы

8.1. Режим рабочего времени и график

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

Работа в выходные и праздничные дни производится только с согласия Разработчика и оформляется как сверхурочная с соответствующей оплатой или предоставлением отгулов согласно ТК РФ. Удаленная работа допускается по отдельному регламенту с использованием корпоративных средств защиты и постоянным контролем исполнения задач в системах трекинга.

8.2. Условия труда и рабочее место

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

Доступ к ресурсам разработки (репозиторий, CI/CD, тестовые среды) предоставляется через выделенные защищенные каналы. Организация обеспечивает охрану труда, создание безопасной среды и регулярный инструктаж по технике безопасности, включая пожарную и электробезопасность.

8.3. Материально-техническое обеспечение

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

При необходимости использования дополнительных вычислительных мощностей, облачных сервисов или специализированных устройств Разработчик оформляет заявку в установленном порядке, которая рассматривается руководителем проекта в течение 48 часов. Расходы на МТО включаются в смету проекта и не покрываются за счет личных средств работника.

9. KPI и показатели эффективности

9.2. Методика оценки и пересмотра KPI

Оценка KPI производится руководителем проекта совместно с бизнес-заказчиком на основе данных систем управления проектами (Jira, Redmine), систем контроля версий (Git) и результатов автоматизированного тестирования. Каждый показатель должен иметь объективный числовой метод измерения, исключающий субъективную интерпретацию.

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

10. Бизнес-процессы, чек-листы и сценарии рабочего процесса