Проект огороджень: проектування комітетом
Коли вас за контрактом створюють рішення для інших – переважно в Інтернеті, оскільки це сфера, в якій я працюю, – я вважаю, що є низка факторів, які важливі для проекту :
- Не повинно бути «проекту комітету».
- Ніхто, крім основної команди розробників, не зможе забезпечити розробку, постановку та виробництво.
- Ніхто не повинен мати можливість писати у виробництво, крім команди розробників (і навіть тоді має бути процес розгортання).
Я завжди вагаюся робити подібні заяви, оскільки вони виглядають як догматичні, але я вважаю, що чим довше я працюю в цій галузі, тим важливішими я вважаю ці три правила.
Або, можливо, це лише орієнтири. Зрештою, є моменти, перш ніж ми справді закінчимо справу.
Незалежно від того, є вони більше пропозиціями чи правилами, це не має значення. Є причини, через які ми всі робимо висновки, чи не так? Тому в наступних кількох публікаціях (а не в одній довгій публікації) я поділюся причинами, чому я вважаю ці три правила важливими.
Дизайн Комітетом
Вживаючи цей термін, я не маю на увазі, що одна людина повинна відповідати за розробку сайту. Я просто маю на увазі, що за це має відповідати агентство чи група тих, хто займається дизайном.
Розробка комітетом — це зневажливий термін для проекту, у якому задіяно багато дизайнерів, але немає об’єднавчого плану чи бачення.
Отже, «комітет» у цьому випадку — це коли група людей, або замовники, або ті, хто певною мірою пов’язаний із замовниками, приходять, щоб переглянути результати реалізації (чи навіть лише дизайн), надсилають електронною поштою пропозиції щодо того, що вони б хочеться бачити і очікувати, що це станеться.
Тобто експертиза, якщо певний дизайнер приноситься в жертву думкам іншої групи.
Принцеса Лея не була комітетом.
І, можливо, в крайніх випадках (хоча я ніколи особисто з цим не стикався) використовувати оплату як важіль, щоб досягти свого.
Справа в тому, що люди, з якими укладено контракт на розробку рішення для замовника, мають бути, як зазначено, експертами в цій галузі. Вони розуміються на типографіці, кольорах, роздільній здатності екрану, доступності тощо.
Залишити їх у їхній сфері знань – це завжди гарна ідея.
Піклування про проект
Усе це не пов’язано з тим, що хтось має більше контролю над проектом, ніж будь-хто інший.
Йдеться про те, щоб переконатися, що всі зацікавлені сторони проекту працюють разом один з одним і не перетинають сфери відповідальності. (Уявіть, скажімо, GIF-файли, які використовувалися б для реклами, якби розробники відповідали за рекламу. 😏)
Суть полягає в тому, що успішний проект – це коли кожен залишається в своєму кутку та працює разом у своїй власній сфері знань.
Інакше ви закінчуєте тим, що речі не синхронізуються і фактично створюють додаткові проблеми, коли їх не було (принаймні в певній області), з яких можна було б почати.
Що далі?
У наступній публікації я розповім про ідею створення середовищ, що це означає та як це відіграє загальну роль в управлінні проектом. Але я детальніше розповім про це в публікації.
Зрештою, йдеться про те, щоб переконатися, що хто має доступ для читання та запису до різних областей, у яких можна розгорнути програму чи проект. Звичайно, для деяких, хто читає це, це може здатися трохи схожим на вміст для «початківців» або зовсім не схожий на вміст, пов’язаний з «розробкою».
Але якщо ви працюєте з іншими над розробкою рішення, ви, швидше за все, зіткнетеся з цими речами, і легше мати план, заснований на помилках інших (а саме мене 🙂), ніж вчитися чомусь важкий шлях.