Объектно-ориентированное программирование в WordPress: техническое задание
Прежде чем мы перейдем к теме объектно-ориентированного анализа и проектирования (когда большинство из нас получает больше всего удовольствия от того, что мы делаем, помимо написания кода), важно проследить еще несколько вещей, касающихся понимания требований клиентов. .
В предыдущем посте я упомянул:
Если вы потратите время на то, чтобы с самого начала понять, чего они хотят, то требования не обязательно должны быть 50-страничным документом с описанием того, как должен работать каждый отдельный модуль.
Например, всякий раз, когда я составляю требования (или техническое задание), как я обычно называю их при отправке клиентам, я редко превышаю десять страниц, а часто и меньше.
И хотя бывают случаи, когда это дольше, я думаю, что отчасти причина того, что разработка короткого набора требований связана с предварительными обсуждениями, чтобы убедиться, что вы и клиент (ы) разработали общий язык, с которым вы можете работать.
Когда вы делаете это, требования и техническое задание — как бы вы их ни называли — не должны быть такими длинными.
Написание технического задания
Во-первых, я хотел бы провести различие между Техническим заданием и Требованиями в контексте этого поста.
- Требования — это то, что клиент хочет построить.
- В Техническом задании подробно описывается, что вы собираетесь делать, как вы будете делать и за сколько.
О последнем я расскажу более подробно в этом посте. Но достаточно сказать, что требования могут быть представлены в форме обсуждений, документации или и того, и другого, если это касается клиента.
Прежде чем перейти к различным частям того, что я включаю в техническое задание, есть несколько моментов, о которых, как мне кажется, стоит упомянуть:
- Не пишите техническое задание, пока не получите все требования от клиента.
- Убедитесь, что клиент знает, чего ожидать от технического задания.
- Если вы собираетесь потратить время на написание технического задания, решите, будете ли вы взимать плату за это время или нет, и убедитесь, что клиент знает, что ему придется платить за это или нет.
Это одна из тех вещей, которые зависят от фрилансера или от агентства к агентству. С учетом сказанного, вот части технического задания, которые я обычно включаю.
Подготовка технического задания
Всякий раз, когда я готовлю техническое задание, у меня есть шаблон, который я использую. Я собираюсь предоставить разбивку, которая охватывает большую часть этого здесь.
Вот как работает каждый раздел:
1 техническое задание
Цель этого документа состоит в том, чтобы [определить предлагаемое решение для ПРОЕКТА].
Требования проекта были предоставлены [ИМЯ ЗАКАЗЧИКА], [РОЛЬ ИМЯ ЗАКАЗЧИКА В НАИМЕНОВАНИИ ИХ КОМПАНИИ]. Условия соглашения представляют собой комбинацию условий, согласованных [ИМЯ ЗАКАЗЧИКА] и [ВАШЕ ИМЯ НАЗВАНИЯ АГЕНТСТВА].
2 Обзор требований
Цель этого документа состоит в том, чтобы [определить предлагаемое решение для ПРОЕКТА].
Требования проекта были предоставлены [ИМЯ ЗАКАЗЧИКА], [РОЛЬ ИМЯ ЗАКАЗЧИКА В НАИМЕНОВАНИИ ИХ КОМПАНИИ]. Условия соглашения представляют собой комбинацию условий, согласованных [ИМЯ ЗАКАЗЧИКА] и [ВАШЕ ИМЯ НАЗВАНИЯ АГЕНТСТВА].
3 языка и технология
Веб-сервер, программное обеспечение, инструменты и подход, которые будут использоваться для создания решения.
4 поддерживаемых браузера
Если это веб-проект, укажите поддерживаемые браузеры, будет ли адаптивная функциональность и как будут тестироваться предыдущие пункты.
5 языков и технологий
Веб-сервер, программное обеспечение, инструменты и подход, которые будут использоваться для создания решения.
6 требований и этапов проекта
Обычно самый длинный раздел документа. Он резюмирует:
- Требования,
- Как каждое требование будет построено и реализовано,
- Любые дополнительные примечания, о которых должен знать клиент.
7 Предлагаемый график
Это основано на вехах, изложенных в предыдущем разделе, и на отзывах клиентов.
8 Другие факторы
Разные вещи, которые вы решите включить, например, что вы или ваше агентство решите привнести в проект, как отсроченная обратная связь может повлиять на проект и так далее.
9 Ориентировочная стоимость
Это включает в себя общую стоимость проекта и необязательную разбивку графика платежей.
Необходимо
Я знаю: я уже говорил об этом в предыдущих постах этой серии. Это не самая гламурная часть того, что мы делаем. Вместо этого мы сразу приступим к программированию.
Но откуда вы знаете, что строить (и строить хорошо), если мы не справились должным образом с проблемой, которую пытаемся решить?
И это то, что дает нам все, что ведет к объектно-ориентированному анализу и проектированию.
Объектно-ориентированный анализ
Теперь, когда мы разобрались с бумажной работой (или даже с «деловой ерундой», как некоторые могут ее называть), пришло время приступить к программированию.
Однако перед этим важно проанализировать требования и определить, какие части проекта будут служить какой цели. Например:
- Нужно ли нам какое-либо уже существующее программное обеспечение?
- Нужно ли нам писать какие-либо адаптеры или код уровня данных?
- Как мы будем строить прикладной уровень и сущности внутри него?
- Что с фронтендом
И для многих именно здесь начинается самое интересное. Так что я тоже очень хочу начать говорить об этом. Начнем в следующем посте.