До останнього року один із способів визначення основних етапів значною мірою ґрунтувався на перспективі того, як я або моя команда та я мали працювати над проектом.
Однак у цьому підході є проблема: для тих із нас, хто намагається включити відгуки клієнтів протягом усього процесу розробки, їм не так легко сприйняти жаргон, який ми використовуємо, і все одно змусити їх зрозуміти його.
З цією метою я почав трошки по-іншому охоплювати віхи проекту WordPress, щоб вони були трохи зручнішими для клієнтів, але все ще мали сенс для того, як команда розробників може виконати те, що необхідно для забезпечення функціональності.
Віхи проекту WordPress
Подумайте на мить про останній раз, коли ви були відповідальними за створення спеціального плагіна або інтеграцію спеціальної функціональності в проект WordPress. Можливо, він включав щось на зразок:
- Імпортувати дані в базу даних WordPress,
- Зробіть інформацію доступною для перегляду та редагування в області адміністрування WordPress,
- Відображати інформацію на інтерфейсі так, щоб її можна було сортувати, скажімо, за значеннями стовпців,
- Дані можна оновити за допомогою іншого імпорту або керувати з області адміністрування,
- І, можливо, деякі інші пов’язані функції.
Якщо ви хочете розбити це на мову розробника, ви будете багато говорити про певні речі щодо імпорту, аналізу даних, цілісності даних тощо. І все це на 100% правильно, і все так і повинно бути з точки зору розробника.
Але якщо ви користуєтеся програмним забезпеченням для керування проектами (яким нещодавно ми зупинилися на Asana ), ці типи етапів не допоможуть, коли ви залучаєте користувачів до проекту.
- Як вони можуть знати щось про деталі процесу імпорту?
- Як вони мають розуміти технічні нюанси створення чогось сортувального?
- Чи є спосіб легко описати їм алгоритм, який навіть має значення?
Я б сказав ні. Отже, як ми можемо зробити віхи проекту WordPress більш доступними? Я не знаю, чи моя відповідь є надійною, але це те, що ми пробували, і те, що, здається, працює відносно добре, але це просто:
- Клієнти часто думають про свої проекти щодо сторінок (або чогось пов’язаного),
- Оскільки ми, як розробники, можемо працювати в цьому контексті, ми можемо визначити загальнодоступний проект, щоб розбивати завдання по сторінках.
Таким чином, віхи проекту WordPress стають більше пов’язаними із завданнями на кожній сторінці, а решта завдань — у більш «загальній» вісі.
Кілька слів про технічні аспекти
Усе, що згадано вище, добре працює, коли клієнт бере участь у певних частинах проекту, але це все одно залишає запитання: «Що ми будемо робити з більш технічними аспектами?»
І це може бути що завгодно: від того, як ви збираєтеся організувати свої інтерфейси, класи, методи тощо, до того, як ви збираєтеся реалізувати певний алгоритм. Незважаючи на це, справа в тому, що необхідно провести глибшу технічну дискусію. Тож що ми з ними робимо, обговорюючи віхи проекту WordPress?
Є кілька варіантів:
- Налаштуйте окрему віху, групу завдань, проектів, обговорення, все, що дозволяє ваша система, і збережіть це між вами та вашою командою.
- Використовуйте проблеми GitHub, проекти GitHub, вікі, Trello чи іншу систему,
- Зберігайте інформацію в іншій програмі, яка доступна всім розробникам, але ізольована від клієнта.
Звичайно, це створює трохи більше накладних витрат, але я виявив, що чим більше інформації ви поширюєте між частинами свого проекту, тим успішнішим може бути проект.
Коли інформація пропущена, розкидана, не ділиться або не деталізована, тоді стає важче керувати нею, чим далі просувається проект, особливо під час майбутніх ітерацій.
Суть полягає в тому, що я вважаю, що важливо розбивати віхи проекту WordPress на частини, де клієнт легко розуміє, яка робота виконується, і щоб ви та ваша команда мали спосіб керувати тим, що виконується.
Як ви це зробите, очевидно, залежить від вас, але я вважаю, що це те, що варто витраченого часу на налаштування.