Як працювати з інженерами, а не кодерами: досвід інженерної культури у продуктовій команді

Привіт, я Роман Апостол, CEO та співзасновник Mate academy. Ми edtech-стартап з власним LMS-продуктом, який допомагає увійти в ІТ. У нас працює бізнес-орієнтована команда інженерів, які НЕ пишуть код для написання коду. І я вважаю, це має величезний вплив на те, як ми, як компанія, продовжуємо рости та виходити на нові ринки.

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

Задачі не від фаундерів

Задача, що впровадити, йде не від фаундерів, а від бізнес-цілей. Основна ідея в тому, що роботу люди роблять руками. Тобто коли люди знають, де і які проблеми — вони пропонують вирішення цих проблем.

Не повинно бути так, що прийшов CEO та 3-4 product-менеджери і написали requirement, що зробити, розробники реалізували це, а потім виявляється, що все це фігня і вона не працює. Коли у процес прийняття рішень, що робити (і головне — навіщо) залучено не 5 людей, а 70, які розуміють, як ефективно це позначиться на продукті з точки зору зони своєї відповідальності — це мінімізує витрати для бізнесу, а інженери отримають змогу розвиватись, як фахівці.

Проте компанія повинна мати прозору культуру, щоб кожна людина в команді розуміла бізнес та його цілі. Як результат — люди приймають рішення більш свідомо, виважено і правильно.

Кросфункціональні команди, свобода дій та лояльність до помилок

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

Гарно організована робота кросфункціональних команд — коли кожна команда самодостатня. Їм не дуже потрібно спілкуватись між собою. Ціль таких команд — мінімізувати кількість зайвої комунікації.

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

Свобода дій також має на увазі лояльність до помилок, якщо з них зроблені висновки.

Щоденні релізи та автотести

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

Коли ж у компанії релізи раз на 2 тижні, то навіть якщо маленька фіча займає півдня — побачити, як вона працює, вдасться лише через 2 тижні. Через це у інженера буде тенденція ускладнювати, чи робити щось більше, ніж потрібно. Буде повільний feedback loop. А чим коротше він — тим швидше інженер вчиться і бачить, чи його рішення були хороші, чи погані.

Наш основний продукт — навчальна LMS-платформа, завдяки якій ми менеджеримо всі навчальні процеси у Mate academy. Безпосередньо всі наші девелопери є менторами. І те, що ми є основними користувачами свого продукту — впливає на швидкість його реалізації та на зворотний зв’язок. Наші кросфункціональні команди задевелопили фічу, наші студенти нею користуються і ми, безпосередньо, бачимо фідбек. Тому ми постійно її оновлюємо, покращуємо та, за потреби, можемо все максимально швидко видозмінювати, погоджувати і т.д. До речі, у нас немає Frontend/ Backend розробників. Кожен розробник може вирішити практично будь-яку проблему, і коли він впроваджує фічу, він робить все, включно з побудовою аналітичної панелі для цієї фічі.

З технічної точки зору ми забезпечили максимум, щоб зміни деплоїлись якнайшвидше. Розробники з перших тижнів в компанії знають про feature flags, метрики, та a/b тести. Такий підхід дозволяє суттєво збільшити швидкість ітерацій, а люди одразу бачать результат своєї роботи і можуть та знають, як його виміряти.

Є один момент: при щоденних релізах не працює функція manual QA, бо їх робити просто нереально. Відповідно в інженера має бути багато автотестів, що раняться дуже часто: кожен пул-реквест та 100% перед релізом. Крім того, вони повинні їх писати.

Тобто має бути культура, що інженери не тільки написали код, а і написали автотести до цього і тільки тоді це йде в репозиторій. Автотестів треба писати стільки, поки не перестане бути страшно релізитись в production.

** Manual QA, як функція теж може бути, але перед запуском великої фічі, щоб протестувати ручками, чи все окей і працює добре.

On-call інженер

Коли в тебе daily релізи, повинна бути on-call людина. Потрібно обов’язково налаштувати моніторинг, щоб в PagerDuty прилітали сповіщення, якщо щось ламається. Також впровадьте on-call ротацію з найдосвідченіших інженерів.

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

Культурне «хрещення» онбордингом

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

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

Акції компанії та self-nominated performance review

Ми віримо не у вислугу років. Для нас має значення вплив, який працівник зробив на бізнес через реалізовані ним проєкти. Якщо впроваджена фіча ефективна для компанії, працівник має отримати свою можливість на performance та salary review. Чекати на певний день X на перегляд зп не треба.

Ми побудували performance review за системою: leadership, складність та бізнес-імпакт. Проявивши всі три якості, людина заслуговує на перегляд грейду або зарплати не раз на рік, а за результатами.

Якщо працівник суттєво впливає на бізнес-метрики, то через 6-12 місяців його менеджер це відзначає і запропонує акції компанії.

Системно перевіряємо, чи все працює

— Результати OKR

Один із факторів, на який ми зважаємо при оцінці успішності — це результати наших щоквартальних OKR. У нас немає KPI та цілей, які ставлю я, як CEO, в односторонньому порядку. Команда, навпаки, сама визначає scope своєї відповідальності на квартал. І сама керує своїм беклогом, що їй потрібно реалізувати за цей проміжок часу.

— Аналітика на все

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

Для аналітики ми використовуємо Amplitude. Крім того, маємо свій data warehouse (DWH), де ми зводимо маркетинг і продуктові показники, рахуємо customer acquisition cost і даємо маркетингу значно цінніші дані. Зараз тестуємо Looker, як наступна ітерація нашої маркетингової і продуктової аналітики.

Прикладом тому може бути наш мобільний додаток. Ми розробили його не тому, що це прикольно мати іконку на телефоні. За статистикою девайсів, багато наших користувачів намагались проходити навчання зі смартфона. Проте раніше платформа не була адаптована під мобільну версію, тому юзерам було складно, а ми втрачали ліди. Задетективши проблему, розробили мобільну апку і конверсія виросла на 15%.

Однак, ми не одразу почали робити DWH і зводити маркетинг та продуктову аналітику. Перші 2 роки нам з головою вистачало саме амплітуди. А якийсь customer acquisition cost ми рахували ручками в Google Spreadsheets. Але на певному етапі ми переросли момент, коли цього вистачало, тоді і завели DWH та tableau і почали цим користуватись.

Тобто якщо ви знаходитесь на етапі, коли все ще можна міряти ручками, то не ведіться на фрази типу «всьо, нам треба customer acquisition cost рахувати, нам треба DWH». Це складні дорогі рішення і ними можна вбивати свої компанії. Бо їх важко почати і досить дорого підтримувати. Це витрачання часу замість того, щоб зробити швидке рішення і перейти до якихось наступних проблем.

— Вплив на бізнес

Відсоток виконаного OKR не єдиний маркер успішності. Ми оцінюємо розробника не по тому, що фіча запущена, а по тому, що це дало змогу автоматизувати, скільки часу це зекономило і скільки цим користуються щоденно. Інженери мають думати категоріями, що ТРЕБА вирішити проблему, а НЕ мені цікаво поекспериментувати з технологіями. Саме так приймаються правильні бізнес-рішення.

Дисклеймер: це окей спробувати багато різних речей/ технологій поки у вас 1-3 роки досвіду. Але через три роки потрібно перейти до етапу, де ви розумієте, навіщо пишете цей код і який результат для бізнесу він приносить.

Наприклад, у нас є bottleneck щодо тестових співбесід. Це енергетично складно для людини проводити більше ніж 2-3 співбесід на день, бо ти дуже втомлюєшся. Тому ми хотіли мати технічне рішення, водночас просте і легко масштабоване. А потім ми знайшли GPT-3 і зрозуміли, що ця штука працює краще, ніж якісь наші домашні home-grown ML рішення. Це дасть змогу нашим студентам потренуватись з GPT-3 перед співбесідою з ментором. Як результат — ми це впроваджуємо зараз.

І фінальний абзац

Інженерна культура є всюди. І вона різна у кожної компанії. Якщо ви працюєте в команді, де інженери створюють продукт та усвідомлюють вплив від написаного ними коду — вітаю, ви потрапили в компанію з ефективною інженерною культурою.

Але якщо ваш колега — інженер вже з 7-річним досвідом, що не бачила/в продакшн — точно не рівняйтесь на неї/ нього. Якщо інженери не знають, яку проблему вирішують, то вони не інженери, а кодери.