Как стать автором
Обновить

Рассуждения о проблемах технического задания

Время на прочтение 3 мин
Количество просмотров 2.9K
Ни для кого не секрет, что у компаний разработчиков сайтов есть проблемы в написании технических заданий. Этот топик — попытка взглянуть на основные проблемы, которые существуют в написании технических заданий.

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

Отсутствие стандартов


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

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

Человеческий фактор


Кто обычно пишет техническое задание? Обычно это менеджер проектов компании, иногда, но очень редко, это так называемый аналитик. Обычно все эти люди имеют крайне поверхностные знания о разработке сайтов, проблемы архитектуры будущего сайта для них — это что-то туманное. Они практически не способны проектировать, да и не должны, я думаю. Но именно такие люди пишут технические задания в большинстве компаний. Им очень не нравится процесс написания, он их обременяет, им постоянно требуется консультация с разработчиком по вопросам «а как это реализуется», «а мы это можем» и тому подобных.

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

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

Время


Техническое задание — краеугольный камень разработки… Все это знают, все понимают. Но почему же тогда технические задания пишутся в условиях жесткой нехватки времени? Буквально на коленке в перерыве между «более важными» делами. Да, можно сказать, что сроки ограничены, что увеличение сроков повлечет увеличение стоимости. Но если подсчитать временные затраты специалистов на исправление ошибок, допущенных при написании технического задания, это будут очень существенные цифры. Гораздо выше, чем увеличение сроков на составление документов на 20-30 процентов.

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

Содержание документа


Что должно содержаться в техническом задании? Какая информация? Мне доводилось видеть документы в которых не было описано даже структуры будущего сайта или же интеграция с внешней системой описывались в формате «сайт будет интегрирован с 1С». Как будет интегрирован и с какой 1С, неизвестно… Бывают и другие крайности, например блок схемы страниц внутри документа. Кому они там нужны? Программист и верстальщик будут работать уже с версткой и макетом соответственно. Дизайнеру? Клиенту? Возможно, но почему бы их тогда не вынести в отдельный документ приложение?

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

Формат и стиль документа


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

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

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

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

Буду рад любой конструктивной критике. Если данный материал будет интерес сообществу, я готов поделится своими наработками по составлению технических заданий в следующих постах.
Теги:
Хабы:
+3
Комментарии 19
Комментарии Комментарии 19

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн