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

Размещено на http://allbest.ru

ФОРМИРОВАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА ПРОЕКТИРОВАНИЕ ДЛЯ РАЗРАБОТЧИКОВ

Бурдяк Павел Станиславович

доцент, кафедра «Железнодорожные станции и узлы», Сибирский государственный университет путей сообщения, г. Новосибирск

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

Ключевые слова: техническое задание, инфраструктура, подход к проектированию, современные технологии, технические решения.

THE FORMATION OF TECHNICAL SPECIFICATIONS FOR DESIGN FOR DEVELOPERS

Pavel S. Burdyak

Associate Professor, Department "Railway stations andjunctions", Siberian State University of Railways, Novosibirsk

Abstract. The article considers the relevance of applying new approaches to drawing up technical tasks for developers of transport infrastructure objects. Modern approaches to design, the roles of project participants, and the impact of promising technologies and technical solutions on the process of developing a technical task are highlighted.

Keywords: terms of reference, infrastructure, design approach, modern technologies, technical solutions.

проект техническое задание разработчик

То, что пользователи и разработчики говорят на разных языках известно всем, кто хоть раз пытался поставить задачу для ее выполнения. Объяснения на «руках» и на «словах» не позволяют добиться необходимой точности описания требуемого объекта. Сложность описания, множество требований и ограничений привело к созданию документа, описывающего все требования к разработке. Этот документ назвали техническим заданием (ТЗ) и потребовали соответствия разработки ему.

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

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

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

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

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

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

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

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

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

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

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

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

Один из наиболее эффективных методов формирования онтологического подхода в описании материалов ТЗ является системно-инженерный подход, который подразумевает рассмотрение продукта (целевой системы) с трех сторон [2, с. 299] (рис. 1):

• система, над которой работаем;

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

• система в операционном окружении.

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

Рис. 1. Целевая система - объект разработки

Список использованной литературы

1. Руководство к своду знаний по управлению проектами (Руководство PMBOK). Шестое издание. Agile: практическое руководство. - М. Олимп-Бизнес, 2018. - 1170 с.

2. Системное мышление / А.И. Левенчук. - М. Издательские решения, 2019 -590 с.

3. Five Trends Drive the Gartner Hype Cycle for Emerging Technologies, - URL: https://bit.ly/3mJfozo (Дата обращения: 29.10.2020).

4. Постановление № 590. О порядке проведения проверки инвестиционных проектов на предмет эффективности использования средств федерального бюджета, направляемых на капитальные вложения. -- URL: https://www.normacs.info/documents/4325 (Дата обращения: 29.10.2020).

5. «Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений», принятыми и введёнными в действие постановлением Минстроя России от 30.06.95 № 18-64. - URL:

https://files.stroyinf.rU/Data2/1/4293782/4293782969.htm#i3137095 (Дата обращения: 29.10.2020).

Размещено на Allbest.ru