Що таке civic tech, або, в перекладі на українську, суспільно зорієнтовані технології? У чому їх специфіка під час управління проектами? Для чого потрібен Github і як ним користуватись у civic tech проектах? 

Відповіді на ці та інші питання читайте у перекладі авторської колонки Кшиштофа Мадейського, яку він опублікував на сайті Medium.

Чим відрізняються civic tech проекти від інших? У  підсумку ми ж так само маємо дедлайни, окремі бюджети (зазвичай), фрілансерів (іноді) та широкі аудиторії, які ми хочемо охопити — то в чому ж різниця?

Головна відмінність – в ідеї відкритості. Якщо ми працюємо з  civic tech, то створюємо опенсорс-проекти. Робимо їх у відкритий, прозорий спосіб. Мова іде про програмування з відкритим кодом.  Погодьтеся, було б трохи лицемірно створювати соціально зорієнтовані проекти, але приховувати, у який спосіб їх було розроблено. Хтось скаже, що опен сорс -  це всього лише компроміс з огляду на обмежені ресурси, але я переконаний, що структуроване та прозоре управління проектами, доступне для інших  — це ключ до використання ресурсів найкращим з усіх можливих способів.

Благі наміри – це добре. Але тоді питання: як ефективно управляти civic tech  проектом, спрямованим на створення технологічного продукту? Адже цей процес включає збір вимог, планування роботи, розробку функціоналу, створення та тестування прототипу, конфігурування виробничого (цільового) серверу, написання документації для користувачів та технічної документації. Як керувати всіма цими процесами, до яких долучається багато людей з вашої команди та фрілансерів ззовні?

Моя коротка відповідь є такою: робіть це на Github. Це загальний майданчик для всіх опенсорс-проектів (з відкритим кодом), що їх різні люди пропонують для розробки.  Github - це сховище проектів та сервісів, але він сфокусований на відкритій співпраці, що робить його чудовим рішенням для civic tech  проектів. Ця стаття призначена для людей, які раніше управляли проектами, але при цьому ще не пробували Github.

Першою рефлекторною реакцією може бути запитання: чому  Github, а не, скажімо, Trello чи Asana? Тому що ми створюємо продукти у сфері “громадянських технологій”, а це передбачає розробку та поширення коду, і саме  Github — місце для збереження коду. Навіть якщо вам потрібен звичайний простий сайт зі статичним контентом, розміщення його на  Github дозволить вам легко співпрацювати над контентом з іншими людьми. Ви навіть можете використувати  Github Pages, щоби створювати сайти і не мати необхідності при цьому вчити HTML. Координуючи Code for Poland (польська ініціатива щодо роботи з відкритими даними, створення міських сервісів із використанням опен сорс, - ред.), я бачив проекти, які використовували багато різних інструментів, але наприкінці більшість команд зупинялися на парі інструментів: сховище коду + управління завданнями (Github) та додаток з чатом (Slack або Gitter). Почніть використання  Github для технічних проектів, і незабаром ви почнете користуватися ним навіть для управління нетехнічними.

В цій статті я поясню основи  Github та продемонструю вам його використання для управління створенням продукту у галузі громадянських технологій (civic tech). Це не важко!

P.S. До речі, чи знаєте ви, що сам по собі  Github - це не опенсорсовий продукт? Можете швидко переконатися самі на нещодавно створеній сторінці Gitlab, якщо вам вже набридло про це читати тут.

Основи  Github

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

«Завдання» це форумоподібні дискусії, що використовуються для управління різними аспектами вашого продукту та обміну думками з навколишнім світом.

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

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

Набагато більш допоміжними, на мою думку, є ярлики. Вони доволі гнучкі — ви можете зробити їх скільки хочете та присвоїти декілька одному завданню. Що важливіше, присвоюючи їм різні кольори, ви можете чітко відрізняти різні завдання на тлі звичайного сірого фону Github.

Які категорії ярликів ви маєте створити? Це повністю на ваш розсуд. Я маю звичку створювати завдання для:

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

«Завдання» — це ядро управління продуктом на Github. Якщо вам зручно з ними, цього достатньо.

"Швидкі" концепти для досвідчених користувачів

Для тих, хто не знає, швидкісна розробка програмного забезпечення (Agile software development) — це підхід, сфокусований на тому, щоби якомога менше часу витратити на те, аби отримати працюючий продукт. Його перевага в тому, що можна показати клієнтові, як виглядатимуть компоненти продукту до завершення в цілому роботи над цим продуктом. Також так дешевше вносити зміни, якщо зміняться вимоги (а вони завжди змінюються в процесі роботи). Наприклад, замість «Інструменту візуалізації національного та міських бюджетів зі зворотним зв’язком з громадянами» давайте спочатку створимо тільки візуалізацію національного бюджету в найпростішій формі та отримаємо коментарі щодо працюючого прототипу за два тижні.

Досвід говорить мені, що немає потреби (чи, скоріше, ресурсів) для запровадження “швидкісних” концептів у більшості civic tech  проектів. В будь-якому випадку, якщо вам не вистачає прогресивних швидкісних концептів, встановіть ZenHub.io. Він безкоштовно інтегрується з  Github зі зебереженням усіх переваг та спеціальних можливостей.

Як почати використання Github у вашому проекті?

Отже, ви ніколи не користувалися  Github для управління своїм продуктом, але хотіли б почати?  Зробіть ці чотири кроки для управління проектом на  Github.

1.Зберіть всіх на  Github

Якщо ви будете координуватися з дизайнерами через Trello, менеджерами з комунікацій на Hangouts, зі своїм босом на щотижневих зустрічах, з фінансовим менеджером телефоном і з командою кодерів на  Github – проект виглядатиме як безлад. Намагайтеся звести якомога більше людей на спільній платформі.

2. Проводьте воркшопи з Github

Всередині Github та Gitlab використовують Git, програмне забезпечення з варіативним кодом, в якому простежуються зміни, зроблені різними людьми. У той час, коли прогресивні IT-компанії приєдналися до Git (та Github для публічних продуктів) вже доволі давно, я досі зустрічаю девелоперів, котрі не використовують варіативного коду і ще не пробували Github. Якщо це досі проблема навіть для девелоперів, що ж говорити про інші професії? Ось чому принципово проводити для всіх, хто залучений у проект, воркшопи з основ Github, зокрема, задля кращого розуміння таких концептів як сховища, завдання та (опціонально) розгалуження.

Чи є кращий шлях навчитися, ніж спробувати зробити це наживо? Для тренування я би рекомендував роботу над загальною та простою темою, наприклад: співробітництво для створення книги кулінарних рецептів. Шаблон продукту (т.зв. Octo-recipes) та структура тренінгу (варіант надається нижче) допоможуть вам ефективно організуати навчання.

Пропонована структура воркшопу:

  • Створення контенту

-розподіліть оновлення між собою та додайте власні рецепти;

-вступ до формату markdown format.

  • Зворотній зв’язок

-ознайомтеся з рецептами/гілками інших людей;

-поставте питання до рецептів, залучайте інших людей до обговорення;

-обговоріть та об’єднайте учасників, використавши весь набір інструментів для зворотнього зв’язку (питання, відповіді, коментарі).

  • Співпраця

-поверніться до сховища із переліком запропонованих змін — сформуйте запити;

-приєднайте всіх до оновленої та розширеної кулінарної книги.

3. Розбийте проект на завдання

У вільний час ви маєте розбити весь проект на менші завдання (“Github-завдання”), які можуть бути спрямовані конкретним людям. Жодне з цих завдань не повинно для свого завершення потребувати більше тижня. Якщо ви не впевнені в якихось деталях, залиште це завдання позначеним ярликом у вигляді знаку питання, щоби повернутися до нього пізніше.

Після того, як ви структурували всі проектні завдання, ви повинні зустрітися з командою та обговорити результати. Чи все зрозуміло на цьому етапі? Хто яке завдання бере на себе? Чи не є завдання надто складним (тобто, чи не вимагає більше тижня на виконання), і чи не треба розподілити його на менші завдання? Які завдання треба виконати в першу чергу, а які можна залишити на пізніший час (останні не треба поки що обговорювати детально)?

4. Виконуйте

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

Ви також можете запровадити щотижневі зустрічі у форматі stand-up («…зустрічі, під час яких всі учасники стоять на ногах. Дискомфорт від довгого стояння змушує робити ці зустрічі короткими», - Вікіпедія), щоби стисло обмінятися новинами про роботу за останній тиждень та обговорити нові виклики. P.S. Це майже те саме, якби ви використовували «швидкісну розробку програмного забезпечення».

5. Діліться

Іноді люди кажуть «наш код надто сирий, щоб його розповсюджувати» або «нам нема чого надати»”. Боязнь відкритості присутня не тільки у державних управлінців, але й у третьому секторі. Олексій Сидоренко у своєму виступу на форумі PDF UA  під назвою “Розповсюдження - це турбота: діліться своїми даними та кодами” ілюструє цей бар’єр чудовими гіфками і каже “Будете сміливими!”. Вартість такого продукту якраз і полягає у відкритості даних та коду, до того ж ви багато чому навчитеся таким шляхом. P.S. Промотуйте відео на 3:44.

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

Що далі?

Якщо вам потрібно більше допомоги у використанні  Github, перейдіть на Github Help -> Managing your work on Github

Удачі вам з вашим проектом!