Dev // Ops

Якщо ви DevOps, Tools Engineer або працюєте з Platform Team, вам знайомо, що команди можуть бути різними не тільки за накопиченим досвідом, а й за рівнем «інженерної зрілости». Наприклад, у компанії Big Tech виділяють такі рівні:
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮‍💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.

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

👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.

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

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

👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.

👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.

👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.

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

👍2💯1

www.tgoop.com/devops_zone3000/363

383 viewsSep 13, 2023 at 12:35

Якщо ви DevOps, Tools Engineer або працюєте з Platform Team, вам знайомо, що команди можуть бути різними не тільки за накопиченим досвідом, а й за рівнем «інженерної зрілости». Наприклад, у компанії Big Tech виділяють такі рівні:
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮‍💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.

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

👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.

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

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

👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.

👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.

👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.

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

BY Dev // Ops