Образец Технического Решения: Примеры, Образцы и Рекомендации для Успешных Проектов

ИТ-консультант.рф | Антон Холодков

аналитик, архитектор, команда разработки для воплощения ваших идей

Важно отметить, что под термином «Технический проект» может пониматься как единый документ (чаще для небольших и средних программных систем), так и комплекс документации (для крупных систем).

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

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

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

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

Для обозначения «Технического проекта» в различных системах и методологиях могут использоваться разные термины. Так, в отечественных ГОСТах 34.201-89, 34.601-90 и РД 50-34.698.90 под «Технический проект» подпадает несколько десятков документов, создаваемых на стадиях «Эскизный проект», «Технический проект» и частично «Рабочая документация». В рамках MSF выделяются понятия концептуального, логического и физического дизайна, которые в совокупности также эквивалентны понятию «Технический проект». В современных «шаблонах процессов разработки» (например, для Microsoft Team Foundation Server) также встречаются различные проектные сущности, которые можно отнести к понятию «Технический проект», так как они отражают те же принципы и специфику разработки программных продуктов.

Примеры технических проектов из моих работ:

Почему мы создаем архитектурное решение

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

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

Почему не стоит самовыражаться в формате документа

Еще раз о «велосипедах»

Архитектурное решение — это стандартный документ. Не стоит начинать его создание с попытки придумать свой шаблон. Творческим людям, такими как программисты и аналитики, свойственно изобретать что-то уникальное, что кажется наиболее подходящим в текущий момент. Однако с опытом приходит понимание, что лучше использовать проверенные решения. Предложенный шаблон АР — это многолетний опыт департамента архитектуры приложений компании БКС. Шаблон оттачивался годами и готов к использованию. Комментарии помогут понять назначение каждого раздела и как его заполнять. Постарайтесь заполнить все, что требует шаблон. Во-первых, это поможет вам структурировать собственное понимание задачи и задать себе необходимые вопросы. Во-вторых, это облегчит чтение документа и его согласование, поскольку тем, кто читает много подобных документов, важно найти все на своих местах, а не искать в очередном «творческом произведении».

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

Далее идет шаблон. Точнее, текст инструкции по его заполнению. Сам шаблон оформляется в виде шаблона Confluence. Пояснения в нем короткие и представлены в виде «инструкций», которые исчезают в сохраненном документе. Шаблон в виде файла можно найти здесь.

Советуем прочитать: Отпуск по уходу за ребенком с временной должности: возможности и условия. Выплата пособий и особенности срочного трудового договора

Шапка документа

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

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

Кросс-проектная активность, длительная активность, Эпик

12.04.2019 — дата последней правки документа

Ссылка на задачу или эпик в Jira

Варианты статусов:

ПЛАН — разработка документа запланирована в рамках проектной деятельности;
ТРЕБУЕТ ДОРАБОТКИ — есть открытые вопросы, требующие доработки документа;

СОГЛАСОВАНИЕ — идет согласование текущей версии документа;
СОГЛАСОВАН — версия документа согласована;
РЕАЛИЗОВАН — реализован и включен в спецификацию релиза;
ЧЕРНОВИК — документ в работе; НЕ АКТУАЛЕН — документ потерял актуальность и может быть удален.

История изменений

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

Техническое задание и техническое решение: шаблон

Часто возникают сложности в понимании задач между Заказчиками и Разработчиками.

Как задать вопрос или описать задачу? Методы WWH и 5W1H в WordPress
Техническое задание и ГОСТ
Техническое задание и Бритва Оккама
Техническое решение (ТР)
Зачем важно ТР?
Когда можно обойтись без ТР?
Шаблон
Проще – через спецификацию
Итоги

Для решения этой проблемы разработчики обычно просят заказчика составить ТЗ (техническое задание), чтобы понять его потребности.

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

Почему это происходит? Вероятно, потому что стороны не до конца понимают, что такое ТЗ, в чем его суть, как оно должно выглядеть и что должно последовать после него

ТЗ и ГОСТ

Люди часто ищут информацию о ТЗ в интернете, натыкаются на ГОСТ и пытаются следовать ему Но они не учитывают, что ТЗ по ГОСТ рассчитано на проекты с участием 1000 человек, и только его подготовка может стоить миллионы рублей, не говоря уже о реализации. Это неприменимо для проектов с участием 1-3 человек Без понимания особенностей такого документа, получается бессмысленный и беспощадный набор сочинений.

Советуем прочитать: Заявление судебному приставу исполнителю

ТЗ и Бритва Оккама

Бритва Оккама в данном случае гласит: наиболее простое решение – наиболее верное, если нет веских причин для усложнения.

Какую самую простую форму ТЗ можно предложить? Ответ – простой список задач (требований, пожеланий). Чаще всего эта форма наиболее адекватна.

Иногда можно добавить некоторые полезные разделы:

Цели – описать не только то, что нужно сделать, но и зачем это делается. Это помогает повысить качество результатов.
Снимки, фото, звуки, примеры – полезно добавить в задание снимок ошибки или пример/фото, как это сделано у других.

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

Зачем важно ТР?

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

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

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

Когда можно обойтись без ТР?

Есть случаи, когда ТР не требуется. Могу назвать два таких условия:

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

Исключение из второго пункта: даже в Agile, если задача крупная (Epic-project) и предполагает участие 3-4 стейкхолдеров, а также работу 2-3 разработчиков в течение 5-6 месяцев, целесообразно сформулировать ТЗ и согласовать ТР. Это необходимо, чтобы Стейкхолдеры (Заказчики) и Разработчики (Исполнители) точно понимали друг друга.

Проще — через спецификацию

Все это можно упростить до одного документа — спецификации.

Для написания этого документа используйте метод WWH.

Создаем документ и называем его Спецификация.
Далее добавляем три ключевых раздела: Что нужно? Почему это нужно? Как это будем делать?
После описания трех ключевых вопросов можно добавить другие разделы по необходимости.

Дополнительные разделы могут включать дизайн макеты, детали реализации и другую аналитику.

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

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

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

— план полов (с указанием типов покрытий и площадей);

— план потолков (с архитектурой потолков, разрезами и сечениями);

— план освещения и размещения электрооборудования (с размерами и привязками);

— план сантехники (с указанием привязок выпусков);

— план демонтажа/монтажа перегородок и стен (с видами и разрезами);

Советуем прочитать: Военный билет: описание и преимущества получения

— развертки всех помещений (с указанием площадей и типов отделки);

— развертки стен (с привязками монтажа декоративных элементов);

— ведомости материалов и оборудования;

— план электрики и осветительных приборов;

— план напольных покрытий (с указанием количества и типа укладки материала).

Отличия технического проекта от эскизного

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

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

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

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

— внесение рекомендаций и предложений при разработке дизайнерских решений;

— участие в переговорах с подрядной организацией для обсуждения календарного плана, проектно-дизайнерской документации, последовательности технологий производства работ и взаимодействия;

— контроль качества выполняемых работ на соответствие требованиям СНиП и дизайн-проекта;

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

— контроль за соответствием применяемых подрядчиком строительных материалов утвержденной сметной документации;

— проверка фактически выполненных объемов работ на их соответствие проектно-сметной документации;

— освидетельствование и подписание Актов скрытых работ.

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

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

Наименование услуги из расчета 4 выходов в месяц на объект	Кол-во м²	Стоимость, руб.
Городская квартира
Технический надзор за ремонтом/отделкой квартиры площадью до	100 м²	от 30 000 руб./мес.
Технический надзор за ремонтом/отделкой квартиры площадью до	150 м²	от 40 000 руб./мес.
Технический надзор за ремонтом/отделкой квартиры площадью до	200 м²	от 50 000 руб./мес.
Загородный дом
Технический надзор за ремонтом/отделкой дома площадью до	200 м²	от 40 000 руб./мес.
Технический надзор за ремонтом/отделкой дома площадью до	300 м²	от 50 000 руб./мес.
Технический надзор за ремонтом/отделкой дома площадью до	500 м²	от 60 000 руб./мес.

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