⌘223. Основи роботи командиВ команді розробників компанії
Saldo Apps (що входить до Netpeak Group) є дуже чітко та круто (на мою думку) описана культура розробки – продакт майндсет розробників (product engineer).
Такий документ, як "біблія" команди, дозволяє фільтрувати людей ще на етапі пошуку, прозоро показуючи потенційні обовʼязки та вимоги до них, а також в процесі роботи памʼятати, чого від тебе очікують колеги.
1. Чітке розуміння цілей задачі
Перед тим, як братися до виконання завдання або планування його етапів, я чітко розумію, чому виконую цю роботу і як вона впливає на користувача, систему тощо.
Це допомагає уникнути непорозумінь і забезпечує правильний підхід до виконання.
2. Верифікація виконаної роботи
Перед передачею результатів на тестування або реліз, я перевіряю, чи все працює відповідно до того, як я це розумію (див. пункт 1), а також чи немає інтеграційних проблем з іншими частинами системи.
Перевірка і тестування – це різні речі. Тестування на різних пристроях, регресійне тестування, крайні випадки – це відповідальність QA. Виконання перевірки з реальними даними та перевірка того, чи працює те, що я зробив – відповідальність розробника і я повинен перевірити це перед тим, як передати QA або будь-кому іншому.
3. Проактивність
Якщо в мене є ідеї, думки чи занепокоєння щодо поточної реалізації, я ділюсь ними з командою.
Проактивність також включає участь у процесах ретроспективи та планування, ініціативу в обговоренні потенційних проблем або покращень та передбачення можливих впливів поточних рішень на інші компоненти системи.
4. Чесність і прозорість
Я чесно повідомляю про особисті або командні проблеми, а також про те, якщо не розумію завдання, процес або документацію. Якщо я не встигаю за графіком, я інформую про це заздалегідь.
Крім того, я документую виявлені проблеми, щоб можна було повернутися до них пізніше і вдосконалити процеси.
5. Підтримка та дублювання відповідальності
Я знаю, що кожен член команди виконує свою роботу добре, але я памʼятаю, що всі ми люди та робимо помилки. Тож коли я берусь за чиєсь завдання, я знаю, що воно виконане правильно на 90%, тобто перевіряю та підтримую колег.
Це стосується як підстрахування під час виконання задач колегами, так і перевірки взаємодії компонентів, створених різними командами, що дозволяє уникнути проблем при інтеграції та забезпечує якість кінцевого продукту.
6. Системний підхід і безперервне вдосконалення процесів
Будь-яка проблема або помилка повинна призводити до двох кроків: виправлення та аналізу причин її виникнення.
Це дозволяє виявити глибші проблеми в команді та вдосконалити організаційні процеси, знижуючи ймовірність повторення подібних ситуацій у майбутньому.
Пропозиції щодо покращення процесів – це відповідальність кожного, незалежно від ролі.
7. Чиста архітектура та відсутність костурів
В архітектурі та коді не повинно бути "чорних ящиків". Усе має бути прозорим і зрозумілим будь-якому члену команди.
Будь-які винятки повинні бути добре обґрунтовані та затверджені на найвищому рівні. Це також означає, що код повинен бути задокументований і легко підтримуваний, а не лише зрозумілий.
8. Активна участь
Мене хвилює життя продукту – збої, відгуки користувачів тощо.
Незалежно від ролі, я не тільки аналізую, як можна покращити ситуацію, але й активно ділюся своїми спостереженнями з командою, надаючи зворотний зв’язок і пропозиції щодо поліпшення продукту.
Як ти розумієш, така культура може (і повинна) бути описаною не тільки для розробників, а для кожної важливої команди в IT-компанії.
Деякі пункти, наприклад "активна участь", "системний підхід" або "чесність і прозорість" можна застосувати до всіх без змін, інші пункти варто переробити або замінити залежно від того, чим займається твоя команда.
#менеджмент
@chumandriy