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