Об’єктно-орієнтоване програмування в WordPress: розуміння очікувань клієнтів
Оскільки ми продовжуємо розвивати об’єктно-орієнтоване програмування в WordPress, важливо переконатися, що ми не забігаємо наперед, коли йдеться про створення продукту для когось іншого.
Так часто легко:
- почути, що говорить клієнт,
- створити щось на основі того, що ми почули,
- передайте його вказаному клієнту.
Але це набагато більше, ніж це. Я трохи танцював навколо цього в попередніх публікаціях цієї серії; однак я хочу почати докладніше, що означає чути:
- Що говорить клієнт,
- Розробити набір вимог,
- А потім створіть навколо цього петлі зворотного зв’язку.
Зрештою, ми хочемо переконатися, що люди, для яких ми працюємо, і рішення, які ми створюємо, справді є рішеннями, а не перешкодами чи перешкодами, через які їм доводиться долати.
Крім того, я вважаю, що клієнту недостатньо просто насолоджуватися враженнями від кінцевого продукту, а також працювати з тим (чи тими), хто створює рішення.
З огляду на це, давайте подивимося, що означає слухати те, що вони говорять, і йти далі.
Розуміння очікувань клієнтів
Щоразу, коли ви читаєте книжки чи інші матеріали про такі речі, це часто робить одну зі сторін «поганим хлопцем». Не завжди, але іноді це робить:
- здається, що клієнт не знає, про що йдеться,
- або це змушує розробника виглядати дурнем за те, що він поводиться як людина, яка знає більше про дану тему.
А як щодо третього варіанту, коли замовник має чітке уявлення про те, чого він хоче, розробник(и) готові вислухати та працювати разом із замовником, щоб створити щось?
Звичайно, на цьому шляху будуть уточнення, і будуть терміни, які потрібно буде визначити, і деяка «перекалібрування» календаря розробки може бути навіть частиною цього.
Але суть така: жодна сторона не повинна працювати проти іншої. Замість цього все залежить від спільної роботи над вирішенням. Звичайно, це вимагає спілкування (з моїм досвідом розробники не завжди вміють це робити, але немає причин, чому це не може бути кращим).
Що говорить клієнт? (Що каже розробник?)
Щоразу, коли ви двоє зустрічаєтеся, ви, швидше за все, думаєте про те саме, тому що ви говорите різними мовами, і кожен з вас вважає те, що говорить інший, жаргоном.
І це не так.
Клієнти мають спосіб говорити про те, чого вони хочуть, а розробники мають спосіб говорити про те, як вони забезпечать це.
Умови, які ми використовуємо
Але може бути спільна мета.
Прагніть до опису проблеми, яку намагаєтеся вирішити. Спробуйте зробити це простою мовою, щоб дизайн відповідав меті та функціональності рішення.
Я не думаю, що це спрацює для всіх, але це перше, що я рекомендую робити, коли ви сидите зі своїм клієнтом.
Як ви побачите далі в цих публікаціях, це допомагає розробити кілька речень, які ви можете використовувати на початку свого опису роботи, до яких ви можете повертатися щоразу, коли вам потрібно прийняти рішення.
Іншими словами, ви (і вони) можете запитати:
Чи те, над чим я працюю, сприяє спільній меті?
І саме тут можна визначити основний набір вимог.
«Потрібно…»
Коли мова заходить про те, щоб щось купити, побудувати, попросити щось, побажати чогось або щось інше, досить легко почати речення зі слів «Я хочу, щоб це…»
Але є велика різниця між «я хочу, щоб він [зробив щось]» і «мені це потрібно [щось зробити]», і коли ви працюєте з програмним забезпеченням, загалом можна з упевненістю сказати, що речі, які потрібні, є основними до програми. І речі, які потрібні, це те, що з’являється після створення основи програми.
Тобто це розмова про «треба мати» і «хотіти мати». І важливо вести розмови, щоб ви могли дійти до остаточного формулювання спільної мети програми.
Коли це буде встановлено, ви зможете почати планувати програмне забезпечення з урахуванням проблеми клієнта. І тут вступає в дію збір вимог.
Розробка вимог
Якщо у вас і клієнта є чітке розуміння того, що потрібно побудувати, настав час скласти вимоги.
Ця частина може бути веселішою, ніж здається. Я знаю, я знаю: це звучить як домашнє завдання чи якесь завдання, чи не так? Але це не так. Замість цього він бере те, що вони хочуть, те, що ви зрозуміли, перекладає загальноприйнятою мовою, а потім пише документ, який пояснює, що робитиме програмне забезпечення.
Однак, залежно від вашого досвіду, це може бути нудно. А під нудою я маю на увазі одну з найгірших частин вашої роботи. Крім того, вимоги завжди змінюються, чи не так?
Не завжди.
Якщо вам знадобиться час, щоб зрозуміти, чого вони хочуть із самого початку, тоді вимоги не обов’язково мають бути 50-сторінковим документом із описом роботи кожного окремого модуля.
У багатьох книгах це документовано, як про те, що так воно і повинно бути. Але за майже десятиліття роботи над цим у мене ніколи не було нічого такого тривалого, і клієнти, як правило, були неймовірно вдячні, коли побачили короткий список, який можна було змінити електронною поштою чи Google Docs, підписати, а потім згадати про рух проекту вперед.
Я розповім про це більше в майбутньому, але незалежно від того, який у вас був поганий досвід, ваш страх або тривога, не варто сидіти. І ми продовжимо говорити про це в цій серії.