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

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

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному6
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

Статью писал менеджер, а не инженер и статья больше о культуре кодеров, а не культуре инженеров:
— инженеры согласовуют действия, а кодеру вообще не нужно общаться — все и так согласовано.
— за 20лет не видел качественных инженерных решений за 1день и тем более протестировать продукт даже за день ( господа — это крайне наивно)
— А/Б тестирование больше о прототипах и проверке гипотезы, а не о создании качественного решения
— кодером может быть любой желающий войти в айти, а быть инженером- нет. (это из 7ми летнего опыта .net коучера)

Дякую за статтю. Вона варта уваги, адже мало хто пише таку конкретику про бізнес.

Але мені здається, що тут є червоні флаги для інженерів.

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

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

На мою думку, це перекладання відповідальності за куди довшу схему product delivery на розробника. Щоб зрозуміти, фігня чи ні, розробнику треба знати конкурентів, користувача, ринок, поточний UX. Разом з фулл-стеком розробки, це не третій квартиль ЗП, який вказаний в в статті. І точно не втамування продуктової команди: інженеру на неї простіше вплинути ногами, звільнившись.

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

Так само як і вище — щоб дійсно розуміти проблему, треба знати ринок, користувача та продукт в цілому.

Якщо ЦЕ впливає на компенсацію та оцінку роботи розробника, то чим займається продуктова команда?

===

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

Однак, якщо не намагатись пояснювати це за автора, зі статті здається що менеджемент оцінює розробника за показники продукту, на які розробник фундаментально не впливає. І перекладає на розробників свої промахи в стратегії та pre-production, які не є компетенцією інженера.

Якщо хтось піде до них на співбесіду, обговоріть такий кейс перед тим, як найматись:

Продакт дослідив опитуваннями що частина аудиторії це батьки, які хочуть прилаштувати в айті школярів. Запилили MVP онбордінгу для батьків, щоб вони могли реєструвати дитину, платити за неї та бачити прогрес. Релізнули, запустили трафік — ніхто не користується. Яка міра в цьому відповідальності розробника?

Дякую за статтю! Якщо не секрет, який у вас (приблизний звичайно) орієнтир по компенсації для інженерів: медіана, третій квартиль, 95%?

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

А чому фаундеричи продакт-менеджери не можуть побачити фічі, які необхідні. Вони що, не працюють в команді?

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

Моє улюблене — протиріччя самому собі :) при щоденних релізах функція manual QA не працює, тільки автотести, але великі фічі ми тестуємо ручками в тому числі. То ви просто не розумієте як у вас поставлене тестування. Зроби стільки тестів, щоб на прод не страшно було релізити. А коли на проді зламається, а розробник вам відповість, що йому не страшно було, то яка ваша реакція буде? А ще у вас на все є метрики, тож покриття автотестами теж мабуть регламентоване. Короче фігню якусь написали.

Хрещення онбордингом — переводячи на людську — онбордингу у нас нема і ми цим пишаємось. З першого дня комітиш в прод. Знайшли чим пишатись...

Про self-nominated performance. Так таки ревю робите по фічах чи по проектах? Трохи ж між цими словами різниця, чи не так? Чи все ж таки стандартні 6-12 місяців рев’ю як в усіх компаніях? І здається у вас менеджери ініціюють рев’ю, а не інженери? І про акції компанії забули написати.

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

Романе, дякую за чудово статтю!
Круто, що є такі продуктові команди, які дбають про інженерну культуру!

Дяка за статтю! Єдиний маленький фідбек:

«Також впровадьте on-call ротацію з найдосвідченіших інженерів.»

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

Цікава стаття, цікавий «продуктовий» підхід, але трохи незрозумілі 2 речі:
1) Ви пишете, що оцінуєте розробників за впливом їх фіч на продукт. Я вірно розумію, що інженери самі придумують фічі, самі їх імплеменують поодинці, та перевіряють метрики? Я не проти фулл-стек розробки, в якій немає дедікейтед фронт, бек, QA та девопсів, але бізнес аналітик та UI/UX-дизайнер — це взагалі не інженерні ролі й розробники з ними зазвичай справляються дуже погано. Можу собі це трохи уявити для продукту, призначеному суто для інженерів, тоб-то де розробники виступають й реальними його користувачами. Але і в цьому випадку буде суттєвий конфлікт інтересів між інженером-розробником і інженером-користувачем в одній особі.
Крім того, якщо фіча розробляється цим інженером самотужки, то є питання до швидкості та оперативності ії імплементації. І це також пов’язано з другим питанням...
2) Релізи кожного дня — це ж не мається на увазі, що кожен розробник повинен кожен день щось заделіверити на продакшен? Як на мене — це суттєво обмежує розмір і складність фіч, які можна пропонувати й імплементувати.
Чи апдейти проду просто робляться кожного дня з тим, що було заделіверено цього дня всією командою, але розробка кожної окремої фічі може займати і тиждень, і місяць, і більше?

І ще, мені здається, такий підхід може працювати у випадку вже готового продукту, який розширюється додатковими фічами. Але розробити систему/платформу таким чином навряд чи вдастся, адже на це треба витратити велику кількість саме скоординованих ресурсів — фічі потрібно «нарощувати» на правильно побудованому «скелеті». Тож, як я розумію, сама платформа розроблялась вами раніше трохи за іншим процесом, ніж описаний у статті?

1) є також дизайнери / продакти. великі фічі робляться декількома розробниками. але акцент на тому, що довгостроково ефективність розробника оцінюється по результатах роботи фічі, а не просто «запущено». тому відсидітись в режимі «скажіть мені який код писати» не вийде.
2) так, розробка фічі займай скільки потрібно часу: тиждень/місяць/більше. за допомогою feature flags коли фіча готова вона включається в продакшені.

Тож, як я розумію, сама платформа розроблялась вами раніше трохи за іншим процесом, ніж описаний у статті?

та ні, все по такому процесу працювало відколи в нас з’явився лендінг

ефективність розробника оцінюється по результатах роботи фічі

тоді ніхто не захоче робити потрібні, але «непопулярні» фічі. наприклад, необхідну для GDPR функцію видалення акаунту і приватних даних — вона взагалі для бізнесу невігідна.

все по такому процесу працювало відколи в нас з’явився лендінг

тоді, щось мені підказує, що ваша LMS виглядає як зоопарк з купою милиць, обмотаний ізоляційною стрічкою. Звичайно, на етапі MVP та запуску бізнесу — це нормально, але масштабувати і розвивати такий продукт виходить дорого і погано. Не плануєте випуск v.2.0, написаний «красиво» з нуля?

вона взагалі для бізнесу невігідна

ти ж бачив штрафи за недотримання gdpr? фіча 100% вигдіна :D

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

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

ми там user generatad **JAVA** код компілюємо на льоту і ранимо по ньому тести. там все добре працює :)

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

що і не кожного дня релізи

наклеп

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

а якщо жодної фічі не готово конкретного дня, то що — спеціально форсите щоб хоча б щось викотити на прод?

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

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

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

well, щоб це працювало не потрібно щоб розробники овертаймили. середній вік розробників 27.

А ще їх не треба підіймати о 2 годині ночі, щоб щось фіксити на проді

Так розробники самі і пишуть код, роблять рев’ю, пишуть тести. В їх силах зробити так, щоб о 2й годині не вставати, ні?(:

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

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

Так щоб ми не пішли в сторону чиїхось уподобань, то я вас перепитаю. Чи ви вважаєте онкол важливим атрибутом інженерної культури і що таким чином команда краще відчуває ownership продукту?

В цілому ні, якимсь особливо важливим він не є з моєї особистої точки зору. Але є бізнеси, яким потрібна робота 24/7, і відповідно до цього з’являється протреба в онколі.

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

Кілька коментарів/питань:

Також впровадьте on-call ротацію з найдосвідченіших інженерів.

На мою думку така ротація повинна в себе включати всіх інженерів окрім тих для кого це може негативно впливати на повсякденне життя (наприклад молоді батьки, сон яких і так не стабільний, їм цей on-call пейдж ну взагалі не потрібен посеред ночі коли може дитину розбудити).
Якщо Junior інженер не може виявити якій FeatureFlag вимкнути, чи який попередній реліз відновити щоб виправити помилку — значить це сигнал що треба щось виправити в процесі і зробити його простішим. У нескладних продуктів з постійними релізами в цьому можуть допомогти Sentry наприклад (для аналізу кількості помилок в певній версії релізу), ну і якийсь дашоборд який дає розуміння які FeatureFlags були змінені.

Автотестів треба писати стільки, поки не перестане бути страшно релізитись в production

👍
чи є у вас автотести які раняться не на PullRequests, a просто на production для моніторингу та сповіщення чи всі сервіси працюють як годиться? (щоб знаходити помилки раніше ніж кінцеві користувачі)

self-nominated performance review

Подобається такий підхід! Чи очікуєте ви щоб співробітник сам ініціював розмову про perofrmance review, чи Engineering Manager ініціюють її дивлячись на результати розробника?

Один із факторів, на який ми зважаємо при оцінці успішності — це результати наших щоквартальних OKR

Чи робите ви щомісячну оцінку OKR щоб зрозуміти чи все йде згодно планом?

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

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

Дякую за статтю! :)

Дякую за коментар. Багато хороших думок.

чи є у вас автотести які раняться не на PullRequests, a просто на production для моніторингу та сповіщення чи всі сервіси працюють як годиться?

Немає. Орієнтуємось на моніторинг ментрик / помилок.

Чи очікуєте ви щоб співробітник сам ініціював розмову про perofrmance review, чи Engineering Manager ініціюють її дивлячись на результати розробника?

Співробітник повинен сам ініціювати розмову. Якщо 9-12 місяців співробітник не ініційовує розмову — EM повинен ініціювати її.

Чи робите ви щомісячну оцінку OKR щоб зрозуміти чи все йде згодно планом?

Так.

А як порадите інженеру з 3+ досвідом не чіплятись за технології минулого а перевіряти чи нова технологія вирішить проблему краще чи ні?

Так, це хороше питання. Важливо витримувати баланс між тим щоб не приносити все підряд в продакшен і не отримати legacy stack. Infrastructure team допомагає приймати такі рішення.

у процес прийняття рішень, що робити (і головне — навіщо) залучено не 5 людей, а 70

Одному мені здається що це жахіття?

це залежить від культури в якій ти хочеш працювати.

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

Включеність, це,поза сумнівом, добре. Але як не перетворити процесс прийняття рішень на безкінечні мітинги і узгодження (у гіршому випадку — боротьбу амбіцій та срачі)? Проблема у тім, що, якщо займатися складними речами, а не писати умовний CRUD, то проблему можна вирішити багатьма різними способами. І спсоби ці можуть бути за великим рахунком рівноцінні, а різним людям подобається різне.
Мій досвід свідчить про те що, якщо у мітингу бере активну участь 5 або більше осіб одного фаху, то якогось зрушення у вирішенні питання очикувати не варто.

Але як не перетворити процесс прийняття рішень на безкінечні мітинги і узгодження

в кожної фічі повинен бути owner. Owner пише дизайн доки, як фіча буде працювати. Будь-хто може коментувати ці рішення і пропонувати альтернативи але рішення приймає овнер.

Мітинги взагалі не потрібні.

А owner — це ж кожен інженер, так? Я сподіваюсь, що у вас в компанії щонайменше 70 feature owners?

можно пробовать решать подобные вопросы путем голосования. получается что и все вовлечены и все принимают решение.

Ви так кажете, нібито просто виконувати, що тобі кажуть — це легко. А простий кейс, коли у вас на якусь банальну фігню серед 2 розробників 3 ідеї як це реалізувати? То що робите в такому випадку?

Одному мені здається що це жахіття?

менi -теж.
Це задрочка. Одноденнi спринти, LOL.

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

Клiєнту таке подобається, звiсно, але...

Мав досить негативний досвід з проєктом, де не було manual QC, і кожна фіча після імплементації деплоїлась на продакшен.

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

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

На тому проєкті воно якось так і вийшло — сильно просів рівень покриття тестами і в принципі їх якість. А QC не було, бо ж інженери «have to feel responsibility for their own code». Як результат — головним негласним правилом серед девелоперів стало «працює — не чіпай», бо на тести надія невелика, вручну ніхто перетестувати не зможе, плюс були сумні історії про девелоперів, котрі думали, що зможуть. ;)

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

Хороша стаття, я б з радістю прочитав список книжок які рекомендує автор.

цікаво яка мотивація інженерів робити стільки додаткової роботи в порівнянні з проектами де є гроші на людей нижче?

треба найняти product manager, project manger, business analyst, manual qa, automation qa, frontend dev, backend dev, верстальщик, dev ops, data analyst

Якщо гроші то з приходом ремоуту вільний час можна конвертнути в $.

список книжок

це в основному не інженерні книжки. З того що особисто мені було корисно:
* Predictably irrational: The hidden forces that shape our decisions
* Zero to one
* Don’t Make Me Think: A Common Sense Approach To Web Usability
* No Rules Rules: Netflix and the Culture of Reinvention
* The Hard Thing About Hard Things
* Start with No: The Negotiating Tools that the Pros Don’t Want You to Know
* Getting more

Остання ще класна тим що автор, Stuart Diamond, розказує про свій досвід переговорів з українським урядом. По цій кнжиці свого часу проходив тренінг в Гуглі.

робити стільки додаткової роботи

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

Роман здоров, цікаво би було послухати як ти робиш аналіз помилок і їх висновок? Чи дотримуєшся ти якихось методик і підходів, чи просто все на досвіді? Чи змінився підхід до аналізу помилок працюючи в гуглі і при менеджменті власної компанії?

Привіт Юрій,

помилки це ок, на помилках ми вчимось.

1.
є type 1 i type 2 decisions (Безос про це свого часу писав)
type 1 — irreversible і сильно впливають на майбутнє компанії. type 1 потребують щоб їх примали досвідчені люди, перед прийняттям рішення проводили свій ресьорч і слухали думки інших людей. RAPID від Bain чудовий фреймворк для type 1.

2.
для type 2 загальний підхід — швидко прийняте неправильне рішення це краще ніж повільно прийняте правильне рішення.

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

type 2 decision — чудові рішення які можна делегувати.

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

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

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

У вашого продукта вночі є користувачі? Щось дуже сумніваюсь :)

usage вчора з 12 до 12 ночі snipboard.io/KMFUYB.jpg

звичайно ж люди сплять вночі, але не всі :)

ну і prod падає не тільки від великої кількості користувачів

Инженерная статья и «щоденнi релiзи» — дальше даже не читал

Плюсую, все залежить від кейсу до кейсу, але така практика маєш більше плюсів, ніж мінусів

Андрій, послухай що розумні люди нижче пишуть ;)

щоденнi релiзи

а як ви будете менеджити це на рівні величезної компанії, при умові, що є залежності на інші команди?
в індустрії це називається просто release frequently, а як frequently — залежить від вашої компанії

в нас вже 40 розробників і все працює. Вова написав як це досягається.

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

в гуглі мігрували DB для сервісу із X00_000 QPS без downtime.

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

во-во, прям то же самое хотел отметить. Подгонять результаты дневной работы под «релиз» и тратить ещё и на это время, тот ещё брейнфак должно быть

Подгонять результаты дневной работы под «релиз»

раджу почитати як компанії будуть дейлі релізи

Мабуть у вас ДУЖЕ круті інженери. Інженера можуть розбудити о 2 ночі, він відразу сам зрозуміє яку фічу треба зробити, сам напише фронтенд, бекенд, автотести, обмаже аналітикою і вже наступного дня фіча буде на проді!
Але:

Ми оцінюємо розробника не по тому, що фіча запущена, а по тому, що це дало змогу автоматизувати, скільки часу це зекономило і скільки цим користуються щоденно.

Раптом виявиться що ця фіча була потрібна тільки одному бовдуру (який дзвонив о 2 ночі)? Отже якщо фіча непопулярна — то інженер не отримає підвищення! Бо надо було спочатку думати чи окупиться твоя робота — чи ні.
Звичайно, такі інженери набагато цінніші за звичайних кодерів. Тому мабуть отримують утричі більше звичайного девелопера (бо працюють за 3х: фронт, бек, QA) та ще за успішні фічі отримують акції, як СЕО та іньші топи.

інженер має серцем відчувати, яка фіча потрібна, а яка — ні. (сарказм)

дійсно! треба найняти product manager, project manger, business analyst, manual qa, automation qa, frontend dev, backend dev, верстальщик, dev ops, data analyst

і щоб вони всі нормально працювали hr + тернінги по комунікації :)

Ну і релізитись раз в квартал, тому що треба ж все перетестувати ручками!

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

Ні, перйджер це коли о 2 ночі дзвонить робот, бо щось впало на проді. Ідея гарна насправді, якщо зроблено грамотно

Якщо воно окремо оплачується*

Див. «зроблено грамотно»

За чотирьох — забули девопса.

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