Drive your career as React Developer with Symphony Solutions!
×Закрыть

Технологічні гільдії в ІТ компаніях: роль та обов’язки

Автори:
Олександр Черненко, Principal Front-end engineer та координатор Front-end гільдії в Intellias. У Front-end більше 6 років, 4 роки досвіду менеджменту Front-end гільдій та менторингу Front-end розробників.

Андрій Козін, Delivery Director в Intellias. Більше 10 років досвіду як QA Manager, Engineering Manager та Delivery Director. Створював технологічні гільдії та відповідні процеси у декількох компаніях, допоміг багатьом інженерам зрости технічно та професіонально.

Вступ

Привіт, читачі DOU! Технологічні гільдії — це популярний та все ще свіжий підхід до імплементації професійних спільнот (communities of practices) у компаніях, що займаються розробкою програмного забезпечення. Наразі є багато питань відносно гільдій, особливо з приводу їх організації та обов’язків. Разом з Андрієм Козіним ми підготували для вас огляд, який базується на нашому досвіді та розумінні ролі технологічних гільдій.

Професійні спільноти в ІТ компаніях

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

Що таке технологічні гільдії?

Технологічна гільдія — це спільнота, яка об’єднана певною компетенцією (гільдія Front-end, Back-end, QA, iOS, Android, UX, Scrum-master і так далі).

Гільдії відомі давно, зокрема у agile-орієнтованій компанії Spotify, вони існували вже у 2012 році. Вони дають змогу ефективно агрегувати досвід і знання та розподіляти їх між учасниками. Гільдії допомагають вирішувати повсякденні технологічні проблеми, архітектурні питання, best practices, приймати правильні рішення при проєктуванні або при виборі того чи іншого інструменту.

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

У гільдії є менеджер (Guild Master / Guild Coordinator / Technology Lead / Competence Lead), або декілька (Guild Core Team). Вони відповідають за виконання та дотримання обов’язків гільдії. Це спеціалісти найвищого ґатунку у своїй компетенції, які впроваджують та координують активності гільдії.

Погляньмо детальніше на кожен з цих обов’язків.

Тримати руку на пульсі світових професійних спільнот для відбору best practices

Для кожного технологічного стеку існує своя спільнота (ком’юніті), і інженер, який хоче розвиватися, намагається слідкувати за нею для того, щоб навчатися best practices.

Є класичні best practices, такі як ООП, шаблони ООП, ФРП, Clean Architecture, принципи SOLID і багато інших. Такий тип знань не так важко знайти, оскільки є багато ресурсів, наприклад, книжки таких авторів, як Роберт Мартін.

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

Гільдія має регулярно виокремлювати з нескінченного потоку професійної інформації ті best practices, які підходять проєктам та компанії.

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

Деякі успішні рішення гільдії можна висвітлити у статтях або проштовхнути і в Open Source (не порушуючи при цьому NDA). Це дозволяє внести учасникам гільдії свій вклад у розвиток загального ком’юніті і є однією з мотивацій перебування у гільдії. Прикладами такого підходу є відомі компанії: Google, Facebook, Airbnb, Wix, Grammarly та багато інших. Якщо компанія не лише стежить за розвитком професійних спільнот, але і робить свій внесок, це переводить її на інший рівень престижу.

Задавати стандарти для гільдії на основі відібраних best practices

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

Забезпечувати дотримання стандартів

Головним принципом тут є намагання автоматизувати все, що можливо.
Базовий code style можна автоматизувати за допомогою спеціальних інструментів з форматування коду. Використовувані фреймворки, бібліотеки та інструменти мають швидко встановлюватися на машини нових співробітників, інколи за допомогою готових гайдлайнів. Також можливо автоматично створювати нові модулі, компоненти або фрагменти коду для проєкту за допомогою шаблонізації. Конфігурації CI/CD та інші корисні рішення мають ретельно зберігатися у джерелах гільдії. Речі, які не можна валідувати автоматично, мають перевірятися під час code review.

Виявляти та вилучати технічний борг

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

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

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

Відсутність технічного боргу — це вклад у довгострокові відносини з клієнтом.

При виявленні технічного боргу у процесі code review, такий код має бути відправлений на доопрацювання, а при неможливості зробити це через обмеження часу — його потрібно зареєструвати.

Підтримувати ефективну комунікацію у рамках гільдії

Дуже важливим є стандарт комунікації між учасниками гільдії. Кожен розробник має почувати себе достойним учасником команди. Стосунки у колективі повинні будуватись на довірі.

Усі коментарі щодо технічного боргу та його опрацювання мають бути доречними та обґрунтованими. Гільдія повинна пам’ятати про дотримання best practices, тому менеджмент має пояснювати новим членам спільноти, чому їхні рішення можуть бути недоцільними чи вимагають доопрацювання.

Впроваджувати передові технології, коли це доречно

Гільдія має підтримувати розробку нових проєктів із застосуванням сучасного стеку технологій. При цьому необхідно поступово оновлювати стек на існуючих, якщо це можливо. Такі підходи є вагомою мотивацією як для розробників, так і для замовників продукту. Глобальна експертиза зростає, виникають гнучкіші, продуктивні та функціональні рішення. Гільдія має бути тренд-сеттером компанії у цьому плані. Вона має знаходити, впроваджувати та випробовувати нові рішення, фреймворки, мови програмування, інструменти. Однак цей вибір має бути побудований не на «хайпі», а на продуманих та раціональних засадах в плані стабільності та підтримки у майбутньому. Тому такий R&D рекомендується базувати на внутрішніх проєктах, ставлячі при цьому реальні практичні цілі та досягнення.

Розробляти оптимально збалансовані архітектурні рішення та надавати оцінки на розробку функціоналу

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

Всі учасники гільдії мають тренуватись у проведенні оцінок, чим більша кваліфікація, тим більші обсяги можуть бути оцінені (від мікро-завдань до цілих проєктів). При оцінюванні часу необхідно враховувати етапи розробки функціоналу. Здебільшого це такі стадії роботи:
— створити повну версію коду, що базується на визначеній архітектурі;
— перевірити роботу функціоналу за різних сценаріїв;
— перевірити роботу на підтримуваних платформах;
— покриття тестами (unit, e2e, інші...);
— проходження code review та запас часу, на випадок, якщо треба буде вносити — зміни по зауваженням з code review;
— збірка та deploy.

Нарощувати експертизу

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

Інколи компанії використовують гільдії у ролі технологічних інкубаторів. Тоді експертиза гільдії будується на плануванні та виконанні R&D. Така дослідницька діяльність може бути цілком обумовлена комерційними потребами. Компанія може випробовувати proof of concept для нових продуктів, або намагатися здобути першість у практиці застосування певних технологій. Наявність R&D напрямку у гільдії дозволяє також залучати резервний персонал, не задіяний на поточних комерційних продуктах.

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

Проводити менторинг та підвищувати кваліфікацію учасників

Вкрай важливо культивувати культуру комунікації та взаємодопомоги. У великих компаніях кількість учасників гільдії може бути істотна (в деяких продуктових компаніях у 1 гільдію може входити близько 100 людей). Тому менеджмент має не лише менторити команду, але й делегувати ці повноваження досвідченим колегам.

Навик менторства — один з обов’язковий для спеціаліста Senior рівня. Розробники кажуть, що неможливо почуватися Senior фахівцем, якщо у твоїй команді немає менш досвідчених колег, яким можна було б передавати певні знання.

Нарощувати компетенцію учасників гільдії

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

Проводити технічні співбесіди та правильно обирати кандидатів

Гільдія має відбирати серед учасників досвідчених спеціалістів, що можуть проводити якісні технічні співбесіди. Це можуть робити здебільшого інженери рівня senior командами по 2-3 людини. Такий підхід дає змогу отримати за декілька годин детальну картину досвіду та навиків кандидата.

Практичний досвід

Надалі розглянемо практичний приклад реалізації гільдії. Це технологічна гільдія, яка існує в Intellias. Кілька місяців тому ми разом з колегами ініціювали Front-end гільдію на бізнес-акаунті LEAN Services (зараз у нашій гільдії до 10 людей). Менеджмент нас підтримав, а інженери зустріли таку ідею доволі позитивно.

Проєкти на нашому акаунті об’єднані спільним доменом та схожим технічним стеком, тому в рамках гільдії у нас багато спільного для обговорення. Щодо перших результатів існування гільдії — інженери краще познайомилися одне з одним та запровадили власні meetups, на яких удосконалюють свої знання з використання фреймворків та бібліотек, інструментів для кодогенерації, вимірювання продуктивності аплікацій, юніт-тестування, end-to-end тестування та ін. Важливо, що ми значно краще познайомилися з проєктами колег з технічної точки зору та підхопили цікаві рішення для спільних проблем. Дуже допомагає чат, де тебе почують та дадуть професійну та неупереджену пораду. Крім того, ми збираємося раз на два тижні на регулярних meetups, де проводимо tech talks та обговорюємо плани гільдії. Свіжі tech talks, які викликали багато інтересу, дискусій та обговорень, — це React Concurrent Mode а також React Profiler.

Треба відмітити важливість активності учасників та автономність гільдії — її учасники мають брати активну участь у житті спільноти: домовлятися, проявляти себе, пропонувати активності, ставити задачі для гільдії.

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

Висновок

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

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Цей пост був би більш інформативний, якби автор написав, в яких відомих компаніях України та світу є такі гільдії, коли і де вони з’явилися в перший раз і т.д. У тексті згадується тільки Spotify, але при цьому створюється таке враження, ніби вони зустрічаються на кожному кроці.

давайте касты запилим, как у индусов

Так ведь уже — менеджеры и РО (брахманы), синьор девелоперы и скраммастера в некоторых случаях (кшатрии), джуниор девелоперы и куа (вайшьи), персонал самой галеры (шудры).
Осталось только в вакансии это дописать и всем сразу всё станет понятно и спокойно :) .

Буквицы сии зело многочисленны, при том тяжек труд разбирать

Скільки нових «мають» та «мусять» для тімлідів. А ви кажете: дзеркалки... У наступному житті!

Сколькодесят тыщ время-денег можно сэкономить, если вот этот весь булшит (и его жрецов) выкинуть на мороз?

> Це дозволяє внести учасникам гільдії свій вклад у розвиток загального ком’юніті і є однією з мотивацій перебування у гільдії. Прикладами такого підходу є відомі компанії: Google, Facebook, Airbnb, Wix, Grammarly та багато інших.

Из текста выглядит как будто все перечисленные компании имеют гильдии, но допустим в Facebook нет гильдий или чего-то подобного. Здесь если нужно решать инфраструктурные задачи то для этого собирают отдельную команду которая будет сфокусированна на проблеме. Продукт инженеры занимаются продуктом, specialists занимаются инфраструктурой и относятся к продакт разработчикам как к своим клиентам.

Тут скорее речь идет о том, что в Facebook и других компаниях существует много наработок, которые рождались в профессиональных кругах и изначально разрабатывались под ее нужды (например GraphQL, который был создан для улучшения News Feed API), но затем эти наработки в отшлифованном виде были расшарены с community

И условный Люксофт разрешит тимлиду выложить кусок проекта в открытый доступ?

Подписаться на комментарии