Как написать техническое задание для сайта на Drupal так, чтобы заказчик был удовлетворен результатом разработки, а разработчик (как это обычно и случается) не оказался в дураках? Делимся универсальным решением, проверенным на практике и позволяющим быстро и легко разработать функциональную часть ТЗ для сайта на Drupal любого уровня сложности. Редакция от 10.05.2021.
Создан 21.02.2014 11:48:26
ТЗ для сайта вообще и на Drupal в частности - а зачем оно?
Действительно, зачем вообще нужна вся это писанина и бюрократия, какие-то там непонятные ТЗ, когда сайт можно и так сделать?
Можно, но почему тогда в великом и могучем Рунете то и дело тут и там раздаются вопли и стоны суперпродвинутых специалистов по информационным технологиям о том, что «меня кинули, меня тупо использовали, заказчик постоянно заставляет все заново переделывать, не хочет принимать у меня работу, не платит денег, то да се, да он такой гадкий, пра-а-ти-и-ивный - вааще!» И прочие слюни-сопли-слезы?
Да нормально все 😜 Первые неудачи - болезни роста, которые проходят сами собой в ходе накопления жизненного опыта. По мере выздоровления специалист становится менее продвинутым, но более организационно и технически грамотным и приходит к осознанию того факта, что взаимоотношения с заказчиком надо как-то формализовывать. И неожиданно для себя узнает, что существуют такие замечательные документы, как договор и техническое задание.
Те разработчики, кого заказчик хоть единожды хорошенько «выпорол на конюшне» при разработке, в ходе приемочных испытаний сайта или любой другой работы, вряд ли станут оспаривать то, что техническое задание - документ жизненно важный.
Правильно! Ведь в чем смысл чем-либо заниматься вообще:
- не в том, чтобы просто выиграть конкурс или заполучить работу напрямую;
- не только в том, чтобы провести разработку гладко, с минимальной нервотрепкой, если, конечно, вы не садомазохист;
- а в том, чтобы СДАТЬ эту работу и ПОЛУЧИТЬ ЗА НЕЕ ХОРОШИЕ ДЕНЬГИ!!!
Ничего не поделаешь - Страны Советов больше нет, взамен получили страну баранов. А баранов надо стричь, коль скоро нас, специалистов, эти же бараны вынудили жить в мире подлого чистогана 😎 Именно в интересах эффективной стрижки техническое задание должно быть разработано безукоризненно.
Теперь о советах. Все было бы прекрасно, но вышеупомянутые менее продвинутые айтишники - как только мягкое место позволяет им снова удобно расположиться в кресле - впадают в лирику и начинают «свое суждения иметь». Они делятся со всеми своим едва приобретенным глубоким жизненным опытом, публикуя на всяких хабрах пути избежания очередной порки - способы решения проблем взаимодействия заказчика и разработчика.
Пути явно сыроватые, напоминающие больше вредные советы. А вредные потому, что в материалах их все больше присутствует «я думаю, я знаю, я уверен», но о нормативных документах либо вовсе нет упоминания, либо документы эти полуграмотно трактуются. На ошибки им вежливо указывают совсем уж тупые и непродвинутые айтишники 😎
Автор разбираемой статьи усвоил, что неоднократно становился жертвой манипуляций со стороны заказчика. И даже сообразил, что инструментом манипуляций является безграмотно разработанное им самим техническое задание. Тем не менее, глубоко в суть вопроса не въехал, но тут же принялся, как водится, учить других.
Следует отметить, что на хабре полно как очень интересных и толковых, так и поверхностных материалов. За толковые авторов, как правило, тут же минусуют, за бестолковщину возводят в хабронациональные герои. Жаль, что безадресно - подленько так - непонятно, кому, образно выражаясь, по мордасам бить.
Техническое задание - это страшный и очень подлый документ. С его помощью можно не только выпороть исполнителя по полной программе, но и капитально прогнуть заказчика, а также во многом «перекрыть» предшествующий самому ТЗ договор. Многие в это не верят, а зря. Весь вопрос состоит в том, кто окажется умнее - заказчик или исполнитель. Тот, кто умнее, сможет использовать ТЗ в качестве инструмента для манипуляций ближним своим, см. Страшная правда о техническом задании.Итак:
- мало быть прекрасным специалистом и уметь просто так делать шикарные сайты;
- важнее уметь грамотно организовывать и проводить работы так, чтобы не было мучительно больно, а для этого одних инженерных знаний и навыков ох как недостаточно;
- а чтобы все грамотно организовывать и проводить, надо не только иметь навыки управления, но и заботиться о безопасности своей «задней полусферы» путем изучения и следования соответствующим стандартам на продукцию, на процессы, на методы испытаний и контроля.
Данный раздел статьи - не требование, не рекомендация и не свод правил, а всего лишь совет, который будет полезен тому, кому надоело оставаться в дураках и наматывать сопли на кулак. Тому, кто готов применять ТЗ как инструмент манипуляций в собственных интересах.
Но оставим в покое наших баранов и вернемся к главной теме - техническому заданию для сайта на Drupal, вернее, к функциональной его части. Все прочее детально расписано ранее, см. Как писать техническое задание на сайт?
Займемся решением второй задачи - как удовлетворить заказчика 😱
Особенности Drupal, позволяющие существенно упростить разработку технического задания на сайт
Особенности Drupal таковы (они известны многим и упоминаются автором исключительно ради «продолжения разговора»):
- программные (функциональные) модули Drupal - как модули ядра, так и дополнительные - по своей функциональности перекрывают, наверное, до 80-90 % всех мыслимых и немыслимых (подразумеваемых) потребностей пользователей сети Интернет;
- Drupal в целом неплохо задокументирован на официальном сайте: классификация модулей порой даже избыточна, текстовые описания модулей и их переводы имеются, налицо определенная системность;
- более того - имеется множество полезных неофициальных Drupal-ресурсов, на которых довольно детально разбирается установка, настройка и функциональные возможности различных дополнительных модулей. Среди множества таких ресурсов хочется отметить xandeadx.ru и content-management-systems.info - спасибо, очень помогли в свое время!
Что из этого следует? А то, что в наших руках имеются ПРАКТИЧЕСКИ ГОТОВЫЕ подразделы технического задания на сайт, такие как Требования к функциям (задачам), выполняемым системой и частично Требования к структуре и функционированию системы, если (что целесообразно) разрабатывать ТЗ по ГОСТ 34.602-89. Остается только отобрать модули по функционалу и сформировать из них иерархическую структуру подсистем.
Указанные подразделы можно назвать спецификацией на программу и даже брифом, как сейчас модно, но это не вполне корректно. Рассмотрим подразделы по отдельности, но для начала - случай из жизни.
Отбор функциональных модулей Drupal и формирование на их основе подсистем сайта
Итак, случай из жизни. Весной 2011 года в одном из неприметных серо-розовых зданий на Зубовском бульваре (как водится - с расстрельным двориком внутри) собрались заказчик, разработчик и субподрядчик (в лице автора).
- Хочу спортивную социальную сеть, - молвил заказчик и жестом дал понять, что все свободны. Пока...
- ТЗ надо писать. Какие соображения? - взволновался разработчик, - будем перелопачивать функционал всех существующих соцсетей, а потом реверснем?
- Есть более правильный путь, - успокоил субподрядчик, - через пару-тройку дней будет результат.
На том и порешили.
Дальше - дело техники. Автор сходил на content-management-systems.info, открыл алфавитный указатель дополнительных модулей и последовательно - от A до Z - «скопипастил» оттуда html-коды таблиц в LibreOffice Calc, получив тем самым широкий (но неполный, конечно) перечень модулей с кратким описанием их функциональных возможностей. Затем пометил галками модули, представляющие интерес в рамках решения поставленной задачи.
Оставалось всего лишь побить модули по категориям, то бишь по подсистемам. Частично это было выполнено вручную, с отбором по схожему функционалу, частично с заходом на drupal.org и просмотром категорий. Параллельно приходилось переводить кое-что из англоязычных описаний или искать русскоязычные описания в сети. Здорово помог ресурс xandeadx.ru.
Вот и все. Все просто. Теперь покажем, что получилось, но в обратном порядке - от подсистем к функционалу, а от функционала - к модулям.
Подраздел техзадания на сайт «Требования к структуре и функционированию системы»
На рисунке ниже изображен перечень подсистем так, как он выглядит в готовом ТЗ.
Стрелкой указано, как раскрываются задачи, решаемые самой первой подсистемой - frontend. Далее подобным образом раскрываются задачи всех остальных подсистем сайта.
Подраздел техзадания на сайт «Требования к функциям (задачам), выполняемым системой»
На рисунке ниже изображено, как задача организации пользовательского интерфейса сайта «бьется» на набор функций.
А на рисунке ниже показано, как та же задача организации пользовательского интерфейса сайта выглядит не в виде завершенного документа, а в виде исходного из библиотеки взаимоувязанных документов.
На рисунке отчетливо видно, как функционал, показанный в ТЗ, «перекликается» с соответствующим ему модулем Drupal. Следует отметить, что любой функционал можно отключить или включить простым снятием топика с публикации, т.е. если топик «+ (6) ТЗ Block функции (подсистема сайта, организация пользовательского интерфейса)» отключить, то после публикации в ворд в тексте техзадания содержимое топика будет отсутствовать, но в исходнике, разумеется, останется и будет просто отмечено как отключенное.
Следует отметить, что подобные манипуляции можно проводить прямо в присутствии заказчика. Если заказчик говорит, что «тут играем, тут не играем, здесь жирное пятно - рыбу заворачивали», то все его хотелки будут удовлетворены в течение минуты на его же глазах. Такую оперативность в работе он обязательно оценит. Т.е. БУДЕТ УДОВЛЕТВОРЕН!
Итак, решена задача удовлетворения заказчика, при этом разработчику и субподрядчику не было мучительно больно 😱
Спасибо Drupal'у за то, что он есть!
Drupal того стоит - подведем окончательные итоги:
- Заказчик счастлив - Спортивная социальная сеть успешно отработала Казанскую универсиаду и завершающуюся сегодня зимнюю Сочинскую олимпиаду;
- Смысл сайтостроительства и любой работы вообще раскрыт: разработка проведена гладко, «задняя полусфера» не пострадала, бараны пострижены - разработчик и субподрядчик УСПЕШНО СДАЛИ работу и ПОЛУЧИЛИ СВОИ ДЕНЕЖКИ;
- У автора-субподрядчика имеется шаблон ТЗ для сайта на Drupal чуть ли не на все случаи жизни и области деятельности.
Все счастливы, все улыбаются 
Вдогонку: летом 2013 года был заказ на разработку сайта-каталога вредных и опасных химвеществ. Автор просто передал заказчику слегка подправленный вариант ТЗ на соцсеть и предложил удалить лишний функционал. Вот и вся разработка...
И еще: в данной статье рассмотрена разработка только функциональных подразделов технического задания на сайт, все прочие, как и упоминалось выше, рассмотрены в статье Как писать техническое задание на сайт?
Удачи всем!
