Введение

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

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

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

Итак, давайте разбираться.

Жизненный цикл продукта

Начать надо с описания общего жизненного цикла ИТ-продукта.

Есть разные подходы к описанию ЖЦ ИТ-продукта, а также разные методологии организации работ, но в общем можно выделить две большие фазы (собственно, именно на этих фазах основан современный подход к разработке DevOps):

• Создание продукта (Development);

• Эксплуатация продукта (Operations).

Фаза «Создание» включает, в общем случае, несколько этапов, среди которых в том или ином виде (с вариациями в зависимости от выбранной методологии организации процесса) присутствуют:

• обследование;

• сбор, анализ, формализация и согласование требований;

• проектирование;

• разработка;

• тестирование;

• внедрение.

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

При передаче готового продукта заказчику, КАК ПРАВИЛО, проводятся приёмочные испытания. Часто им, согласно логике, здравому смыслу и требованиям стандартов, предшествуют предварительные испытания и опытная эксплуатация. Для проведения каждого вида из этих испытаний обычно пишется специальный документ – «Программа и методика испытаний». В разделе «Программа» описывается подход к испытаниям, порядок проведения, документирования, анализа результатов и т.п., а в разделе «Методика» – набор тестов, обеспечивающих, прежде всего, проверку выполнения требований ТЗ.

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

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

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

2. Разработать продукт в соответствии с зафиксированными требованиями;

3. Провести приёмо-сдаточные испытания с целью определения соответствия продукта согласованным требованиями и возможности принять его в эксплуатацию.

Соответственно, результатами решения этих задач станут артефакты и статусы:

1. Техническое задание на продукт как спецификация требований;

2. Готовый продукт (включая необходимую документацию на него);

3. Признание готовности продукта к приёмке в эксплуатацию (фиксируется соответствующими актами и протоколами – акт проведения испытаний, акт принятия в эксплуатацию, акт сдачи-приёмки; бухгалтерские документы о закрытии сделки тоже могут являться «передаточными артефактами», но они не касаются непосредственно самого продукта, поэтому на них останавливаться не будем).

Кто такие (или что такое) Заказчик и Исполнитель

Теперь попробуем определить, что такое (или кто такой) ЗАКАЗЧИК, и что такое (или кто такой) ИСПОЛНИТЕЛЬ.

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

Заказчик, по отношению к исполнителю, может быть как внешним, так и внутренним. Внешний заказчик – это организация или, что реже, частное лицо, заказывающее разработку организации или специалисту (фрилансеру, оказывающему комплекс услуг по разработке ИТ-продукта «под ключ»). Внутренний заказчик – это структурное подразделение организации, которая либо сама по основной деятельности занимается разработкой ИТ-продуктов под заказ для внешних клиентов, либо в её составе есть специализированное подразделение (реже – отдельный сотрудник), чьей основной функцией является разработка и/или поддержка ИТ-продуктов для внутреннего пользователя.

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

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

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

Как поставить задачу исполнителю

Но тогда возникает логичный вопрос – а как эти требования должны быть переданы непосредственным исполнителям? Т.е. тем, кто будет заниматься разработкой продукта – системному архитектору, программистам/разработчикам, архитекторам баз данных, разработчикам интерфейсных решений (если это веб-продукт – то дизайнеру, верстальщику), тестировщикам, и т.д.

Конечно, самое простое – это просто отдать им это «большое» ТЗ. Однако это не самый правильный путь, и вот почему.  

Говоря о ЖЦ продукта, мы вспомнили последовательность работ. При любом подходе, при использовании любой методологии – водопад, спираль, V-модель, скрам и т.д. – всё равно будет соблюдаться определённая последовательность этапов работ. Хотя мы и не обозначили, какие результаты (прежде всего – артефакты) должны быть у каждого этапа, тем не менее, нужно понимать и помнить, что все эти этапы должны выполняться определёнными ролями и заканчиваться вполне чётко формализуемыми результатами. Даже если работу по всем этапам ведёт один человек, объединяя несколько ролей (эдакий «универсал-многостаночник»), с точки зрения методолога следует эти роли и этапы рассматривать отдельно, искусственно выделяя и изолируя их друг от друга.

Так как же должен получать задачу каждый из исполнителей конкретного этапа? Что должно включать «задание»? Если в общем ТЗ все требования перечислены «высокоуровнево» и извне, то, с одной стороны, у исполнителя этапа есть некоторая свобода, в т.ч. свобода выбора методов, способов и средств решения поставленной задачи, но с другой – возникает неизвестность, неопределённость, степень которой должна быть минимальной, иначе продукт может оказаться не совсем таким, каким он задумывался, и какой, в конечном итоге, ожидает заказчик.

Следовательно, есть смысл (и вот тут уместно вспомнить рекомендации ГОСТ 34.201 – который сейчас ГОСТ Р 59793) сделать ПРОМЕЖУТОЧНЫЕ или ЧАСТНЫЕ («парциальные») задания, которые, конечно, можно назвать и «техническими», чтобы сохранить общее красивое название «ТЗ». Т.е. появятся:

• ТЗ на системную архитектуру;

• ТЗ на программный код (не исключено, что отдельно на front-end и на back-end);

• ТЗ на структуру хранилища данных (с подразделением на хранение файлов, неструктурированных данных и СУБД);

• ТЗ на человеко-машинный интерфейс (дизайн и вёрстку, если речь о веб-продуктах);

• ТЗ на контент и SEO (это уже для веб-сайтов);

• ТЗ на интеграцию с внешними системами и информационными ресурсами;

• ТЗ на… в общем, на всё остальное.

Да, можно пойти по такому пути. И он будет оправдан для больших тяжеловесных систем, которые разрабатываются большими коллективами в рамках масштабных проектов. Для более мелких проектов (тут, правда, сложно назвать пограничные критерии – что такое «крупные», и что такое «мелкие» проекты) такая разбивка избыточна – но всё же написать какие-то «ТЗ для разработчиков» не мешало бы, некоторым образом «инкапсулировав» спецификацию требований заказчика ко всему продукту («большое» ТЗ) от «частного ТЗ» (в ГОСТ 34.201 оно так и называется – «ТЗ на часть системы»). И такая «инкапсуляция» позволит, кстати, декомпозировать требования из высокоуровневых в частные.

Но тут же сразу возникает следующий вопрос – КТО будет:

1. Разбивать «большое ТЗ» на части;

2. Проводить разработку «частных» требований (требования к дизайну, к ПО, к системной архитектуре);

3. Формализовывать и описывать требования в единый артефакт (документ);

4. Тестировать выполнение «частных» требований по «ЧТЗ»;

5. Принимать готовый результат;

6. Документировать процесс и результат.

Сразу же упомянем, что, во-первых, «частные» требования должны быть чётко привязаны к аспекту продукта (дизайн, ПО, системная архитектура, интеграции, контент…), а во-вторых, документировать нужно не только результат, но и процесс – в частности, фиксируя, какие были выдвинуты идеи/гипотезы, концептуальные решения, ВАРИАНТЫ концепций, и почему выбрано именно то решение, которое выбрано как окончательное – это будет важно в случае развития и модернизации продукта, а также в случае необходимости исправления ошибок, в т.ч. серьёзных, требующих ревизии архитектуры и иных технических решений по продукту.

Вот тут, конечно, очень большой соблазн взять то, что, казалось бы, лежит на поверхности – трассировку требований, бэклог, канбан-доску с карточками задач, критерии готовности (DoD и DoR) и прочее. Но…

• Кто и как сделает трассировку (ИИ не предлагать – по крайней мере, пока, ибо сыроват он ещё для такого) глубже, чем BR → UR → FR → QA? Учитывая, что разработчик «частных требований» должен не просто поверхностное представление иметь о сфере, в которой ставит задачу, но и вполне профессионально в ней разбираться, желательно – на уровне эксперта (в дизайне, вёрстке, системной архитектуре, архитектуре БД, программировании, интеграциях и т.д.);

• В каком виде и как должна быть поставлена задача исполнителю?

• Что делать с требованиями, которые не трассируются напрямую из бизнес-требований или пользовательских требований (это касается, прежде всего, решений по архитектуре системы, типу базы данных, информационной модели и т.п.)?

• Как оценить результат разработки? В частности, кто и как должен разработать тесты и провести тестирование результата разработки отдельной составляющей продукта?

Примечания:

Термины (аббревиатуры), вроде бы, всем известны в среде специалистов, но на всякий случай расшифрую:

• BR – Business Requirements, бизнес-требования;

• UR – User Requirements, пользовательские требования;

• FR – Functional Requirements, функциональные требования;

• QA – Quality Assurance, тестирование.

Сразу надо оговориться, что ни UseCase, ни, тем более, User Story, не покроют все потребности. Ключевое слово – ВСЕ. Связано это с тем, что архитектурные решения, решения по алгоритмам серверной части (back-end), решения по хранилищу данных (в т.ч. СУБД) не всегда напрямую связаны с пользовательскими требованиями и чётко завязаны на конкретный сценарий использования, поэтому чаще всего требуется многоходовка: сначала «индукция», т.е. проектирование продукта как системы в целом, а затем уже «дедукция», т.е. разработка отдельных элементов, компонентов и решений, удовлетворяющих, с одной стороны, исходным требованиям заказчика к продукту, и с другой – соответствующих общесистемным решениям по продукту (той самой «индукции»).

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

Так вот, есть некоторая ловушка терминов, которая может смущать участников процесса. Заключается она в том, что ТЗ, как спецификация требований, согласованных между заказчиком продукта и исполнителем, не является результатом проектирования. Т.е. проектирование происходит ПОСЛЕ выявления и фиксации ВНЕШНИХ требований к продукту, т.е. ПОСЛЕ написания и согласования ТЗ. Соответственно, для правильной постановки задачи конкретным специалистам, ответственным за разработку отдельных решений – дизайна интерфейса, модели данных, системной архитектуры, ПО и т.д. – нужно провести само проектирование.

Хотя правильнее будет сказать, что проектирование – это тоже не сплошной однородный этап. В нём тоже можно выделить две «фазы» – общее проектирование, в рамках которого создаётся виртуальная модель (на уровне идеи) будущего продукта, а затем – непосредственное проектирование отдельных решений по каждому компоненту: дизайну человеко-машинного интерфейса, алгоритмы для разработки ПО фронт-энда и бэк-энда, хранилище данных, СУБД, интеграция, отдельные виды обеспечения (если говорить в терминах АС по ГОСТ 34 серии) и т.д. Что как раз и даёт тот водораздел, на котором должны появиться задания на отдельные составляющие целевого продукта.

И вот упомянутая выше ловушка в том и состоит, что часто эти задания тоже называют ТЗ. Формально, конечно, большого нарушения в этом нет – но важно, чтобы это понимание разницы между «большим» ТЗ (как спецификацией высокоуровневых «внешних» требований между исполнителем и заказчиком) и ТЗ на разработку отдельных составляющих продукта у всех участников разработки было. И тут не менее важно, чтобы понятие «ЧТЗ», которым многие пользуются в качестве замены понятия «Дополнительное ТЗ» (как правило, отражающее изменения требований, возникшие и согласованные уже после утверждения исходного ТЗ), не превращалось в «задание на разработку … (дизайна интерфейса/ПО/БД/…)».

СтОит отметить, что в случае ИТ, особенно в части разработки ПО, есть некий бонус по сравнению с разработкой материальных объектов (машиностроение, приборостроение, строительство и т.д.), поскольку макетирование можно совместить с проектированием, а опытный образец готов уже практически сразу – что и позволяет для гибких методологий использовать подход MVP (Minimum Valuable Product, продукт с минимальной пользовательской ценностью), последовательно и итеративно приближая продукт к его целевому состоянию, которое необходимо заказчику для полноценной эксплуатации. Однако всё равно разработчик конкретного компонента целевого продукта должен сначала придумать, что должно быть реализовано, а потом только приступать к реализации задуманного.

Кто должен ставить задачу исполнителю

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

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

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

• Для водопада – лучше всего, если постановку задач будет делать ГИП – главный инженер проекта, если такая роль будет формально введена в команде, либо тот, кто де-факто функции ГИПа выполняет (да, пусть «строительный» акроним «ГИП» никого не пугает – в разработке АС/ИС). В другом варианте, скорее всего, его назовут «системный архитектор», что тоже будет правильно, поскольку функционально эти роли практически идентичны.

• Для scrum и прочих agile – скорее всего, владелец продукта (Product Owner). Возможно, его роль будет исполнять менеджер проекта (Project Manager), но тут есть один нюанс, что разработка по agile, в общем-то, не очень-то и не всегда проект (почему – тема отдельная).

• Для DevOps (если вообще его имеет смысл выделять из сонма agile-методологий) – скорее всего, это будет задача DevOps-инженера.

Как оформить задания

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

Что может быть таким документом/артефактом?

Прежде всего, конечно, непосредственно документ – бумажный или электронный (файл). Но этот подход сейчас используется редко, потому что всё большую популярность завоёвывает подход Docs as Code с размещением информационных материалов в репозитории аналогично программному коду. Поэтому таким заданием может быть запись в репозитории. Ну а раз репозиторий – то почему бы не воспользоваться таск-трекером (task tracker) типа Jira? Подойдут и Kanban-доски, и чек-листы, но стОит иметь в виду, что формулировки задач для них будут уж слишком компактные, а задание разработчику всё же исторически не зря называется «ТЗ», поскольку должно содержать достаточно информации, по которой можно не только провести проектирование и разработку, но и настроить тестирование и оценку готовности (DoD и DoR тоже придётся разрабатывать, кстати).

Нужна ли для оформления задания роль технического писателя? В принципе, да, это возможно. Хотя будет в этом случае некоторое дублирование функций постановщика задач (ГИП, ВП) и технического писателя. В больших тяжеловесных проектах это, скорее, даже хорошо – особенно, если разработка отдельных частей продукта может быть отдана на аутсорсинг в специализированные фирмы, либо внутри компании-исполнителя есть выделенные по специализации структурные подразделения (т.е. оргструктура не матричная и не проектная). В небольших компаниях, наверно, лучше, чтобы ГИП/ВП/системный архитектор (не аналитик!) сам чётко сформулировал постановку задачи, причём так, чтобы результат можно было протестировать – как автономно, так и на предмет соответствия общей спецификации требований к продукту (т.е. ТЗ).

Заключение

Итак, резюмируем.

1. ТЗ на продукт – это спецификация «внешних» требований заказчика (будущего пользователя) к продукту (и, опционально, к процессу его создания, внедрения и сопровождения).

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

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

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