Створюємо веб-проект разом

14.12.2017

Стаття Рейчел Скотт (Rachel Scott)
Зображення видалено.Мета Рейчел – простота й зручність

Хоча Рейчел й отримала ступінь бакалавра з реклами в Техаському університеті, вона швидко зрозуміла, що закохана в світ Інтернет. Вона розпочала свою кар’єру в якості координатора проекту, потрапивши під суцільну лаву практичних завдань проектного менеджменту, а потім отримала допуст до роботи «на фронті». Їй подобається реалістичність – така, яка змінюється, та графіки й доповнення, які необхідно встановлювати. Вона була представлена співтовариству Друпал на SXSW 2008, зрозуміла, що це було чудово, і відтоді для неї все перевернулося.

Рейчел – сертифікований ScrumMaster, - вона була ScrumMaster на попередній роботі, - та менеджер проектів у Lullabot. Вона проводить дні командного розвитку та координації з клієнтами. Хоча вона й не розробник, Рейчел подобається конструювати функціональні модулі за допомогою Друпал.

Рейчел народилася й виросла в Далласі, штат Техас, і, коли вона вільна від менеджерських завдань, її можна віднайти під час гри з її кошенятком Monkey або занять медитацією чи йогою.

Чому веб-проекти краще робити, коли клієнти й розробники будують їх разом; необхідні інгредієнти для спільних проектів, і як виявити проблеми ще до того, як вони дадуть про себе знати.
Зображення видалено.
Мене зацікавила підставка для пластикового посуду, яка оберталася. Я була в гостях у приятеля, який нещодавно відремонтував своє житло, і показував мені всі подробиці ремонту. І тут ми натрапили на вбудовану шухляду з цією підставкою. Мені вона здалася особливо цікавою, тому що, вочевидь, була побудована за спеціальним замовленням, аби задовольнити неврастенічні схильності мого приятеля до порядку в пластиковому посуді.

«Ця шухляда була в плануванні на початку?» - запитала я.

«Ні, - відповів приятель. – Я просто якось зайшов, коли тут працювали будівники, описав їм те, що хотів, і вони це зробили».

Я була в шоці; я вважала, що ви даєте будівникам проект, називаєте їм кольори й текстури, які вам хочеться, і вони будують це. У цьому сенсі я завжди думала, що, врешті-решт, отримуєш те, що отримуєш.

В інтернет-світі це, зазвичай, проекти. Клієнту потрібен сайт, і клієнт наймає розробника допомагати. Шаблон і дизайн створені, розробник будує сайт, клієнт навчається, і відтоді вони несуть відповідальність за підтримку одне одного і за самовдосконалення. Це може бути ідеальним сценарієм для певних проектів, але може виявитися надто ризикованим у роботі над комплексними проектами з багатьма невідомими, де використовується програмне забезпечення з відкритим кодом, або в живих проектах, що потребують частого корегування. Я вважаю, що корпоративні проекти – найбільш успішні, коли обидві сторони – і клієнт, і розробник – однаково задіяні в процесі розвитку. В ідеалі – це коли у клієнта є команда розробників проекту, ніби то це - внутрішній проект, і команда розробника, яка виступає в якості розширення команди клієнта.

Навіщо будувати сайт разом?

Налаштування клієнта на успіх

Вдалий запуск – це не єдине, що робить проект успішним; зручна для клієнта підтримка сайту після запуску також має велике значення. Тісне співробітництво команд майстрів клієнта та розробника забезпечує клієнтській команді випробування системи після запуску; вони вже працювали у зв’язці, і тому в ідеалі не виникне необхідності в якомусь «тренувальному періоді». Такий підхід – величезний плюс і для розробників також. Чим раніше клієнт розпочинає власний проект, і рішення ухвалюються, тим менша вірогідність, що вони будуть висмоктуватися з пальця в останні хвилини.

Вимоги та цикл зворотного зв’язку

На двох останніх проектах, у яких я працювала, найбільші скарги клієнтів на колишніх розробників полягали в тому, що ті не змогли зрозуміти їхні запити. Цей класичний комікс добре ілюструє проблему:
Зображення видалено.
У клієнта є ідея, вірогідно, зафіксована, схоплена на папері – уявляєте, може бути навіть зразок, що працює! Його бачення, можливо, неясне; коли наступає час створювати кінцевий продукт, наявна маса перспектив, і кінцевий результат не відповідає вимогам клієнта.

Іноді, аби уникнути такої долі, це - лише питання до клієнта: бути більше задіяним у швидкому огляді або конструктивних зустрічах. Проте, я з’ясувала, що чим краще команда клієнта розуміє, що і як будується, тим кращий зворотний зв’язок може давати клієнт на шляху успішної реалізації його бачення.

Ухвалення рішень/конфлікти

Клієнти, які на значному рівні задіяні в процесі будування, здатні ухвалювати досить інформативні рішення. Це може запобігти «неясним висновкам», - у ситуаціях, коли клієнт погоджується з чимось, не усвідомлюючи наслідків і результатів у повній мірі. До того ж, за виникнення конфліктів, обидві сторони – і розробник, і клієнт – розмовляють однією мовою й можуть ефективніше обговорювати проблеми й рішення. Все це будується, базуючись на припущеннях та виконанні також; оскільки вони співробітничають, клієнти стають більш обізнаними щодо тих речей, простих для реалізації, і тих, для вивчення яких потрібен час або замовна програма. Успіх проекту стає спільною відповідальністю, і обидві команди в цьому разом, а не навпаки, коли перекидаються вимогами й звітами про помилки на віртуальній стінці.

Аналіз з обох боків

Обидві сторони – і розробник, і клієнт – протягом усього проекту можуть пропонувати цінні ідеї. Команда розробника має досвід з розробки структур із відкритим вихідним кодом, досвід роботи з різноманітними компаніями, та розуміння більшості складних завдань, із якими доводиться зіткатися. Команда клієнта володіє досвідом в аналізі продукту й знаннями про історію компанії, а також глибинним розумінням особистостей у команді гравців, політики, а також реальних потреб учасників підприємства. Через різні точки зору, обидві команди можуть вибухати ідеями й допомагати одна одній знаходити рішення складних питань, що неминучі.

Складові успішного співробітництва

Вірна команда

Я з’ясувала, що є чотири вирішальних ролі, коли обидві сторони – і розробник, і клієнт – будують проект разом.

1. Розробники: дуже важливо, щоб обидві команди доповнювали одна одну. Часом це означає наявність відповідних ролей у кожної зі сторін (1 – 1 адміністратор баз даних, і т.п.), тоді як інші проекти можуть отримати зиск від розподілу різноманітних типів задач між командами розробника й клієнта. У будь-якому випадку, переконайтеся, що зберігається чіткий зв’язок.

2. Проектувальники: зазвичай це головний конструктор з боку розробника, що несе відповідальність за нагляд за тим, як будується система, з висоти пташиного польоту. Їм необхідні технічні знання як інструментарію, що використовується, так і систем, які будуються, аби відповідати на складні запитання, що неминуче виникають: вони отримуватимуть їх персонально для аналізу змін чи доповнень та їхнього впливу на систему.

3. Менеджери проекту: і з боку клієнта, і з боку розробника функції менеджерів проекту – як комунікативна зв’язка для решти команди. Це надзвичайно важливо, оскільки обидва «племені» можуть легко «дрейфувати» одне в бік іншого.

4. Представники клієнта: це можуть бути дуже поважні люди, що беруть активну участь. Для них немає необхідності день у день дізнаватися про буденні подробиці, але вони повинні мати гарантії, що команда вибудовує систему, яка відповідає їхнім потребам. Це суттєво для побудови декількох контрольних пунктів у графіку робіт, пунктів, де представники клієнта можуть виконати огляд системи й пересвідчитися: вони розуміють, що саме конструює команда, і що вона рухається у вірному напрямку.

Навчання

Аби клієнтська команда розробників була задіяна, відкрите навчання – не тільки по роботі із системою, яка буде використовуватися, але й у процесах розробника, у налаштуваннях і т.д., - це, як правило, необхідно. Дуже важливо влаштовувати навчання на ранній стадії, щоб проект міг початися рівно. Зазвичай розробники отримують багато уваги, коли наступає час навчання, але будь-хто, хто виконуватиме технічні рішення для проекту, отримає користь від тієї ж самої інформації.

Конфіденційність і довіра

Укріплення довірливих стосунків допомагає зберегти зацікавленість команд у проекті й задіяність в ухваленні рішень. На мій погляд, довіра вибудовується, коли команда розробника чітко повідомляє про те, що будується, як це реалізується, і чому рішення ухвалюються протягом усього процесу. Розробники, які виконують це, обмінюються актуальним досвідом розвитку й пересвідчуються, що можливий пас (hand-off) команді клієнта буде рівним. Це ще один чудовий шлях до того, щоб побудувати довірливі стосунки відносно особистісної взаємодії. На одному з наших останніх проектів розробники використовували великі білі дошки в офісі клієнта, аби визначати різні групування функцій Друпал, які ми могли створити. Команда клієнта брала участь у мозкових штурмах, займаючись аналізом і рішеннями, які випливали.

Дотримуйтеся плану

Як тільки клієнтська команда розробників усе краще ознайомлюється зі структурою сайту, і з тим, як найліпше її використовувати, вони можуть захотіти змінити щось у плані, або щось у нього додати. Важливо додержуватися бачення представників клієнта, повідомляючи, що «позолота» (наддостатні доповнення, нескінченне або надлишкове вдосконалення) ітерацій може відбуватися після того як проект буде завершено. Це не означає, що шухляда на підставці, що обертається, не може засуватися, але цю особливість потрібно врахувати в загальному плані.

Реєстрація змін у проекті

Виділить час, аби подивитися разом на проект, як на ціле, і зробіть часті ретроспективи, щоб побачити, як команди можуть покращити робочі взаємовідносини. Оцініть такі речі як комунікативні процеси, укладання завдань, документація, проектний графік/процес і ресурси. На недавньому проекті ми виконали оцінку в його середині, і зрозуміли, що в нас – надто багато людей, залучених до купи щоденних дзвінків. Ми обмежили дзвінки для членів нашої внутрішньої команди, і перейшли на щотижневі дзвінки команді клієнта.

Червоні прапорці для спостережень

Червоні сигнальні прапорці

Незважаючи на те, що співробітництво двох команд може дати багато корисного, бувають моменти, коли процес стопориться й потребує повторного калібрування (структуризації). Під час багатьох проектів я навчилася розпізнавати деякі моменти, які мають підкорити серце клієнта. Нашим клієнтам: не турбуйтеся! Усі клієнти, що згадуються в цій роботі, є вигаданими. Будь-який збіг з іменами реальних клієнтів, живих чи мертвих, цілком випадковий!

Брак ресурсів у команді клієнта

Якщо в клієнта немає команди для підтримки проекту, або можливості приділяти цьому час, спільна робота просто не може проводитися. Вочевидь, у них може бути відмінна командна структура, але якщо вони надто розпорошуються на інші проекти й «гасять пожежі», команда розробника буде витрачати свій час на очікування доступу чи періоду затишшя. Іноді вивільнення клієнтської команди – це знак, що попереджує, що в них немає повної зацікавленості у проекті. Більше сенсу може бути в тому, аби переключитися на традиційніший підхід, із розвитком командою розробників реалізації специфіки, окресленої клієнтом.

Немає спеціаліста

З боку клієнта це добра ідея: якщо буде такий спеціаліст, який уже має довіру до розробника, і який уже знайомий із розвитком структури, володіє чіткими показниками щодо проекту, що будується. За відсутності такого спеціаліста на місці проект може піддатися ризику через те, що немає «вболівальника», який підтримує клієнтську команду в ефективному співробітництві з розробником. Наявність спеціаліста обмежує також можливості стосунків «свій-чужий», що розвиваються, коли виникають конфлікти.

Обмеження в термінах

Обмеження по строках

Розширення команди клієнта в підготовці до реального розвитку вимагає часу, і виникнення двох різних команд для ефективної спільної роботи не відбудеться в одну мить. Оцініть готовність клієнта попередньо інвестувати в навчання, координацію та планування, аби пересвідчитися, що проект піде рівно. Якщо строки надто тиснуть, традиційній підхід «конструювання в шаблонах» може здаватися більш безпечним.

Неофіційний канал підкупу

Дарма що це й здається очевидним, але один з найзначущих червоних прапорців – це клієнт, який намагається замкнути процес співробітництва на переконуванні окремих розробників повідомляти про зміни або додавати функції. Хоча це завжди манливо задля того, аби обійти якісь процеси, коли зміни мають бути виконані, підхід «розділяй і володарюй» може підірвати ефективність усього процесу ухвалення плідних групових рішень, і загрожує всьому проекту, якщо дозволити цьому вийти з-під контролю. Так легко можуть вибухнути політичні баталії, а енергія – перенапрямуватися від важливої праці із завершення проекту.

Висновок

Врешті-решт, і клієнти, і розробники хочуть створити сайт, що відображає потреби бізнесу клієнта. Чим краще розробник розуміє ці потреби й бачення клієнта, тим кращий результат. Я думаю, найголовніша користь від створення сайту разом – це стосунки, у яких він створюється; у здоровому співробітництві замовник сприймається як партнер, а не як хтось «зі сторони», із іншими пріоритетами. З моєї точки зору - із «барикад» замовника, працювати з командою клієнта також і дуже приємно! Є певні речі, які – немов винагорода за спільну працю над створенням чудового проекту.