Масштабування команди розробників за допомогою зовнішніх інженерів без втрати якості коду

Вступ

Ключові висновки

1. Використовуйте зовнішніх інженерів, коли ваш план роботи занадто насичений для основної команди.
2. Перед тим, як вони приєднаються, встановіть прості стандарти якості та базовий процес доставки.
3. Приймайте зовнішніх розробників на роботу з чітким контрольним списком і одним наставником.
4. Застосовуйте один спільний набір правил, оглядів та показників для всіх інженерів.
5. Покладайтеся на короткі письмові оновлення, щоб підтримувати злагодженість зростаючої змішаної команди.

Чому варто розширювати команду розробників за допомогою зовнішніх інженерів?

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

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

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

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

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

Як підготувати кодову базу та процеси перед додаванням зовнішньої команди розробників?

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

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

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

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

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

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

Як виглядає безпечний план адаптації зовнішніх розробників?

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

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

Ось один простий список, який часто добре працює як основа для такого контрольного списку:

1. Доступ до коду, трекера завдань та основних чатів.
2. Кроки для запуску продукту на ноутбуці або тестовому сервері.
3. Короткий посібник для користувачів, основні процеси та ключові бізнес-правила.
4. Імена людей, до яких можна звернутися з питаннями про продукт, код та інструменти.
5. Два або три невеликі, чіткі завдання, готові для перших реальних змін.

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

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

Як підтримувати якість коду в змішаній команді розробників, коли ви керуєте зовнішніми розробниками?

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

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

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

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

Моделі комунікації так само важливі, як правила і цифри. Багато змішаних команд розробників також вважаються розподіленими гнучкими командами, оскільки люди працюють з різних місць або часових поясів. Їм потрібна асинхронна комунікація для команд розробників, щоб прогрес не залежав від довгих дзвінків. Короткі письмові оновлення, чіткі нотатки про завдання та прості теги для статусу дуже допомагають. Хороші письмові оновлення полегшують всім інженерам приєднання, відстеження та вдосконалення продукту з часом. Живі розмови все ще мають значення, але вони більше не є єдиним місцем, де приймаються рішення.

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