Технологическое задание в строительстве

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

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

Понятие и сущность технического проектирования

Грамотный проект частного дома и техническое задание. Как они связаны?

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

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

1. Детальная проработка решения. Поскольку потребности даже узкой целевой аудитории, как правило, разняться, проектировщик должен в своём выборе решений согласовать весь спектр мнений.
2. Оценка альтернативных решений. Альтернатива не может быть выбрана произвольно, поскольку она тоже возникает как сопоставимый по возможностям вариант удовлетворения требований.

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

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

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

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

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

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

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

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

Характер и назначение изделия, а также пожелания заказчика определяют для разработчика перечень предстоящих работ. Как правило, при подготовке технического проекта проектировщик:

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

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

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

Часть работ связана с номенклатурной деятельностью:

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

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

Требования к оформлению документации

ГОСТ 2.119-73 определяет, каким должен быть чертёж общего вида технических документов. В чертеже, при необходимости, приводят:

• технические требования к изделию (например, метод сварки, вид покрытия и др.),
• технические характеристики изделия, значимые при последующей работе над чертежами,
• указания о посадках деталей с размерами и максимальными отклонениями сопрягаемых поверхностей (согласно ГОСТу 2.307-68).

Ведомость технического проекта заполняется указаниями на конструкторские документы по разделам, согласно ГОСТу 2.106-96:

1. Введение. Указывается наименование, дата утверждения и номер технического задания (либо дата и номер протокола рассмотрения эскизного проекта или технического предложения).
2. Назначение и область применения. Здесь даётся краткая характеристика условий и сферы применения изделия, а также основные данные, обеспечивающие стабильность показателей при эксплуатации.
3. Техническая характеристика. Перечисляются основные технические характеристики (от мощности и расхода энергии до производительности и КПД), а также данные о соответствии-отклонениях в работе изделия от требований ТЗ и предыдущих стадий разработки.
4. Описание и обоснование конструкции. Обосновывается не только выбранная конструкция, но и схемы, упаковка, необходимость нового оборудования, дефицитных материалов, составляющих и другие технические решения. Сравниваются показатели изделия с показателями аналогов. Поверяется патентная чистота и конкурентоспособность и, если в изделии используются изобретения, то указываются номера их регистрационных свидетельств. Помимо этого, в разделе фиксируются:
5. результат макетных испытаний,
6. сведения о правилах транспортировки и хранения,
7. данные по соответствию технике безопасности и санитарным нормам.
8. Расчёты работоспособности и надёжности. В подтверждение работоспособности приводят электрические, гидравлические и пневматические, тепловые, кинематические результаты расчётов. А в подтверждение надёжности – результаты расчётов по ремонтопригодности и долговечности.
9. Организация работ с применением изделия. Даётся информация об организации работ по месту эксплуатации, которая включает:
10. данные об особенностях способов, приёмов, режимов работы с изделием,
11. анализ эксплуатационных характеристик,
12. сведения о персонале (его квалификации и численности),
13. описание способа и порядка хранения, транспортировки, монтажа и введения в эксплуатацию.
14. Технико-экономические показатели. Вносятся ориентировочные данные по цене опытного и серийного образцов и затраты на организацию производства. Экономические показатели также включают эффективность от внедрения изделия в народное хозяйство.
15. Уровень стандартизации и унификации. В разделе собираются сведения об унифицированных, стандартизированных, заимствованных элементах в изделии и показатели этих параметров. Также обосновывается возможность введения новых отраслевых и/или государственных стандартов под новую разработку.
16. Приложение к пояснительной записке. В приложение вносится:
17. копия технического задания,
18. материалы, не относящиеся к конструкторским документам, но связанные с художественно-конструкторской проработкой,
19. список документов, которые были использованы при разработке этой части проекта (в том числе – полученные от других организаций, патентных бюро и др.),
20. перечень работ, планируемых для следующей стадии,
21. сетевой график по последующей разработке и внедрению в производство изделия.

Пояснительная записка технического проекта тоже выполняется по ГОСТу 2.106-96.

Источник: finswin.com

Лекция 12 Разработка технического задания

Программный документ «Техническое задание» разрабатывается в соответствии с ГОСТ 19.201 — 78. Техническое задание содержит совокупность требований к программному средству и может использоваться как критерий проверки и приемки разработанной программы, поэтому достаточно полно составленное (с учетом возможности внесения дополнительных разделов) и принятое заказчиком и разработчиком техническое задание является одним из основополагающих документов проекта. Умение грамотно создавать техническое задание на разработку программного продукта определяет профессиональный уровень программиста и избавляет его от претензий со стороны заказчика.

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

Разработка технического задания выполняется в такой последовательности:

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

2) определяют перечень результатов, их характеристики и способы их представления,

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

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

Основные факторы, определяющие характеристики разрабатываемого программного обеспечения:

• исходные данные и требуемые результаты, которые определяют функции программы или системы;

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

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

В соответствии с ГОСТ 19.201 — 78 программный документ «Техническое задание» содержит следующие разделы.

1. Основание для разработки.

2. Назначение разработки.

3. Требования к программе или программному изделию.

4. Требования к программной документации.

5. Технико-экономическое обоснование.

6. Стадии и этапы разработки.

7. Порядок контроля и приемки.

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

1. В разделе «Основание для разработки» должны быть указаны:

• документы, на основании которых ведется разработка;

• организация, утвердившая этот документ, и дата его утверждения;

• наименование и (или) условное обозначение темы разработки.

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

3. В раздел «Требования к программе или программному изделию» входят следующие подразделы:

• требования к функциональным характеристикам;

• требования к надежности и безопасности;

• требования к составу и параметрам технических средств;

• требования к информационной и программной совместимости;

• требования к маркировке и упаковке;

• требования к хранению и транспортированию;

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Стадии и этапы разработки описаны в учебном пособии А.В.Рудакова «Технология разработки программных продуктов».

7. «Порядок контроля и приемки» предполагает указание на виды испытаний и общие требования к приему работы.

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

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

• перечень научно-исследовательских и других работ, обосновывающих разработку;

Источник: karpusheva.ru

Технологическое проектирование

Технологическое проектирование ставит своей целью решение задач промышленного производства.

В действующих нормативно-правовых документах подробно определяется порядок проектирования зданий и помещений.

Требования к проектированию технологического раздела проекта недостаточно детальны.

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

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

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

Cтадии разработки технологического проектирования:

Концепция проекта

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

В состав концепции входит:

• блок-схема технологического процесса
• состав основного технологического оборудования
• укрупненные планировочные решения по участкам

Концепция может служить основой для разработки задания на проектирование.

Раздел «Технологические решения» проектной документации

Раздел «Технологические решения» проектной документации разрабатывается на основании исходных данных и нормативных документов.
Раздел «Технологические решения» проектной документации разрабатывается в соответствии с Постановлением Правительства РФ от 16.02.2008 №87 (ред. 02.12.2020г) «О составе проектной документации и требованиях к их содержанию».

Состав раздела «Технологические решения»:

1. В технологический раздел проекта входят пояснительная записка и графические материалы.

2. В состав раздела «Технологические решения» входят:

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

Технологические схемы

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

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

Окончательно технологическая схема может быть принята после разработки объемно-планировочных решений производства и необходимых разделов энергообеспечения и согласования с заказчиком.

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

Полную технологическую схему разрабатывают на стадии рабочей документации.

Материальный баланс

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

Требования к оборудованию. Спецификация оборудования

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

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

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

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

Раздел «Технологические решения» рабочей документации

Состав и правила оформления рабочих чертежей марки ТХ выполняют в соответствии с требованиями ГОСТ 21.401 и других нормативных требований.

В состав рабочих чертежей технологии производства включают:

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

В состав основного комплекта рабочих чертежей марки ТХ включают:

Источник: proekttech.ru

Как сделать техническое задание на мобильное приложение

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

ТЗ по ГОСТу: поможет ли оно сделать классное приложение

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

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

Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:

1. Гостовский документ кажется нам слишком громоздким. В нём сложно ориентироваться. Если вы приходите за конкретной информацией и не знаете, где её искать, вам придётся изучить весь документ. На листание страниц уходит время, которое можно было потратить на завершение других задач.
2. ТЗ по ГОСТу не подходит для сотрудничества по Agile. Стандарт, написанный в конце , не знает, что проектная разработка может идти спринтами. Приложение разрабатывается поэтапно. У каждого спринта — своя документация, поэтому монументальное ТЗ будет не к месту.

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

Кто пишет техническое задание на мобильную разработку

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

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

Проблема любых больших документов, особенно аналитических, в том, что их сложно читать как клиентам, так и самим разработчикам, поэтому мы не пропагандируем ТЗ по определённым форматам, будь то ГОСТ или зарубежные стандарты. Я за то, чтобы делать ТЗ под конкретный проект. Более того, я сторонник подхода «меньше текста без ущерба смыслу — лучше». Если можно обойтись без документа и заменить его на изображения или схемы, тем самым сократив объём, то лучше сделать именно так.

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

Как понять, что вы попали к плохому аналитику

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

• Вы не понимаете, что написано в ТЗ. Несмотря на техническую направленность, текст должен быть читаемым. Аналитики жертвуют терминами и красивостью в пользу ясности. Иногда мы пишем одно и то же слово несколько раз подряд: «Пользователь может нажать на кнопку. После нажатия на кнопку, кнопка…» — смотрится не очень, но эта тавтология делает текст однозначным.

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

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

Сколько стоит техническое задание

В масштабах общей стоимости приложения цена, которую клиент платит за ТЗ, небольшая. Час работы техписателя оценивается в 1500–2000 рублей. На простое приложение без бэкенда уходит 60 часов, а на сложный eCommerce можно потратить больше двухсот. Но экономить на ТЗ нельзя.

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

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

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

— Иван Леонтьев, «Лайв Тайпинга»

Можно ли скачать готовый шаблон ТЗ

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

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

Техническое задание без ошибок, воды, повторов — наш подход к проектной документации

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

Из чего может состоять проектная документация в «Лайв Тайпинге»:

1. Функциональное задание

Функциональное задание (ФЗ) — самый мощный артефакт в нашей проектной документации. К нему обращаются на каждом этапе разработки от прототипирования до релиза. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование. И при этом у него нет ни одного магического свойства.

Сила ФЗ в том, что оно подробно описывает функции, которые доступны пользователю при работе с приложением. На интервью с клиентом мы узнаём, какие ролевые модели (администратор, модератор, простой пользователь) предусмотрены в приложении, и описываем набор функций для каждой роли: куда пользователь может пойти, что сделать и какой результат его ждёт. Пока мы с клиентом готовим этот артефакт, дизайнеры делают прототипы экранов, которые соответствуют возможностям приложения, прописанным в ФЗ. Готовый документ проверяют разработчики.

На этапе проектирования я полностью читаю готовое ФЗ на один раз — у меня складывается общая картина приложения. Затем я начинаю читать ФЗ на второй раз, это позволяет мне: 1) задать вопросы, которые меня интересуют, чтобы проверить документ на ошибки; 2) дополнить конкретные моменты в приложении исходя из своего опыта; 3) дать более точную оценку проекту.

— Павел Разуваев, «Лайв Тайпинга»

2. Функциональные схемы

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

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

3. Описание компонентов системы

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

4. Технические заметки

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

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

— Андрей Дёмин, «Лайв Тайпинга»

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

5. Спецификация API (application programming interface)

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

6. Карта рисков

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

7. Документация на фичу

Этот артефакт — референс к гостовскому ТЗ: он собирает технические и функциональные характеристики на одну фичу в одном месте. Нужен, когда к нам на поддержку приходит готовый проект и мы добавляем в него новые функции или исправляем баги.

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

Как «Лайв Тайпинг» сокращает затраты клиента на документацию

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

• Gym Record — лёгкий и удобный дневник для записи тренировок. Клиенту не нужна была сложная авторизация, поэтому мы сделали приложение без серверной части. Таким проектам не требуются документы, которые описывают работу с сервером — API, схемы и пояснения к ним. Основной упор в приложении сделан на дизайне, который отталкивается от функциональности. Поэтому для нашего клиента мы сделали только функциональное задание, в котором прописали особенности UX и UI. На создание документа мы потратили 20 часов — суммарно 2–2,5 рабочих дня.

• Justfood — сервис по доставке готовых блюд для тех, кто следит за фигурой. Проект пришёл к нам на поддержку со своей документацией. Она помогла нашим разработчикам понять принцип работы приложения. Но чтобы вносить изменения, нам потребовалось сделать документацию на фичи, которые мы добавляли. В артефакте мы прописали шесть новых фичей и к каждой указали функциональные, технические требования и ограничения. Например, «Автопродление подписки» выглядит так: 1) пользователь применят продление и получает скиду — это функциональное требование; 2) при применении промокода скидки не суммируются — это ограничение; 3) карта клиента сохраняется в приложении с помощью дополнительных параметров метода оплаты — это техническое требование. Разобраться в документах клиента и создать новый артефакт — 24 часа, или 3 дня.

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

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

Источник: livetyping.com