Объектно-ориентированное программирование в WordPress: понимание ожиданий клиентов
Поскольку мы продолжаем продвигать обсуждение объектно-ориентированного программирования в WordPress, важно убедиться, что мы не забегаем вперед, когда дело доходит до создания продукта для кого-то другого.
Так часто легко:
- услышать, что говорит клиент,
- построить что-то на основе того, что мы услышали,
- передать его указанному клиенту.
Но есть гораздо больше, чем это. Я немного потанцевал вокруг этого в предыдущих постах этой серии; тем не менее, я хочу начать углубляться в то, что значит слышать:
- Что говорит клиент,
- Разработать набор требований,
- А затем создайте циклы обратной связи вокруг этого.
В конечном счете, мы хотим убедиться, что люди, для которых мы работаем, и решения, которые мы разрабатываем, действительно являются решениями, а не препятствиями или препятствиями, через которые им приходится перепрыгивать.
Кроме того, я не думаю, что клиенту достаточно просто получать удовольствие от своего конечного продукта, но и от работы с тем (или теми), кто создает решение.
С учетом сказанного давайте посмотрим, что значит слушать, что они говорят, и исходить из этого.
Понимание ожиданий клиентов
Всякий раз, когда вы читаете книги или другие материалы о таких вещах, это часто делает одну из двух сторон «плохим парнем». Не всегда, но иногда получается:
- клиент кажется невежественным относительно того, о чем он говорит,
- или это заставляет разработчика выглядеть придурком из-за того, что он ведет себя как человек, который больше разбирается в обсуждаемой теме.
Как насчет третьего варианта, когда у заказчика есть четкое представление о том, чего он хочет, а разработчики готовы слушать и работать вместе с заказчиком над созданием чего-либо?
Конечно, по ходу будут уточнения, и будут термины, которые необходимо определить, и некоторая «перекалибровка» календаря разработки может быть даже частью этого.
Но суть в следующем: ни одна из сторон не должна работать против другой. Вместо этого все дело в совместной работе над решением. Конечно, для этого требуется общение (в котором, по моему опыту, разработчики не всегда преуспели, но нет никаких причин, почему это не может быть лучше).
Что говорит клиент? (Что говорит разработчик?)
Всякий раз, когда вы двое встречаетесь, вы, вероятно, думаете об одном и том же, потому что каждый из вас говорит на разных языках, и каждый из вас думает, что другой говорит на жаргоне.
И это правильно.
У клиентов есть способ говорить о том, чего они хотят, а у разработчиков есть способ говорить о том, как они это сделают.
Используемые нами термины
Но может быть и общая цель.
Стремитесь к описанию проблемы, которую пытаются решить. Попробуйте сделать это с точки зрения непрофессионала, чтобы дизайн соответствовал цели и функциональности решения.
Я не думаю, что это сработает для всех, но это первое, что я рекомендую делать, когда вы сидите со своим клиентом.
Как вы увидите позже в этих сообщениях, это помогает разработать несколько предложений, которые вы можете использовать в начале вашего технического задания, к которым вы можете возвращаться каждый раз, когда вам нужно принять решение.
Другими словами, вы (и они) можете спросить:
Способствует ли то, над чем я работаю, достижению общей цели?
И именно здесь вы можете определить основной набор требований.
«Нужно…»
Когда дело доходит до покупки чего-либо, создания чего-либо, запроса чего-либо, желания чего-либо или чего-то еще, довольно легко начать предложение со слов «Я хочу, чтобы…».
Но есть большая разница между «Я хочу, чтобы это [сделало что-то]» и «Мне это нужно [что-то сделать]», и когда вы работаете с программным обеспечением, обычно можно с уверенностью сказать, что вещи, которые необходимы, являются основными. к приложению. И то, что нужно, — это то, что приходит после того, как основа приложения была построена.
То есть это разговор о «надо иметь» и «хотеть иметь». И важно вести беседы, чтобы вы могли прийти к окончательному утверждению общей цели приложения.
Как только это будет сделано, вы сможете приступить к планированию своего программного обеспечения с учетом проблемы клиента. И здесь в игру вступает сбор требований.
Разработка требований
Если у вас и у заказчика есть твердое понимание того, что нужно построить, то пора сводить воедино требования.
Эта часть может быть веселее, чем кажется. Я знаю, я знаю: это звучит как домашняя работа или какое-то задание, верно? Но это не так. Вместо этого он берет то, что они хотят, то, что вы поняли, переводит это на общий язык, а затем составляет документ, объясняющий, что будет делать программа.
Однако, в зависимости от вашего опыта, это может быть скучно. И под скучностью я подразумеваю одну из худших частей вашей работы. Кроме того, требования всегда меняются, верно?
Не всегда.
Если вы потратите время на то, чтобы с самого начала понять, чего они хотят, то требования не обязательно должны быть 50-страничным документом с описанием того, как должен работать каждый отдельный модуль.
Во многих книгах говорится, что так и должно быть. Но за почти десять лет работы у меня никогда не было чего-то такого длинного, и клиенты, как правило, были невероятно благодарны, увидев краткий список, который можно изменить по электронной почте или в Google Docs, подписать, а затем ссылаться на ход проекта. вперед.
Я расскажу об этом больше в будущем, но любой плохой опыт, который у вас есть, ваш страх или трепет, который у вас есть, не должен сидеть. И мы продолжим говорить об этом в этой серии.