Увеличаване на екипа за разработка с външни инженери без загуба на качеството на кода

Въведение

Ключови изводи

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

Защо изобщо трябва да разширявате екипа си за разработка с външни инженери?

Трябва да разширите екипа си за разработка с външни инженери, когато пътната ви карта е пълна и вашите собствени хора не могат да се справят по здравословен начин. Основната идея е проста: външните инженери трябва да добавят скорост и умения, без да понижават стандартите ви за качество. Ако ви помагат да доставяте стабилна работа, която се поддържа лесно, тази организация има смисъл. Ако само добавят стрес и произволни промени, моментът не е подходящ.

Много лидери в продуктови компании изпитват същия натиск. Натрупаната работа нараства, крайните срокове се пропускат, а наемането на силни инженери във вашия град отнема много време. В този момент започвате да мислите за разширяване на инженерния екип с помощ отвън. Можете да потърсите аутсорсинг екип за разработка в друг регион или по-малка група, по-близо до вашата часова зона. Истинският въпрос не е дали можете да привлечете външна помощ, а кога тя ще подкрепи вашия план, вместо да скрие по-дълбоки проблеми.

Една от причините да поканите външни инженери е достъпът до умения, които в момента не притежавате. Може да се нуждаете от краткосрочна подкрепа в области като данни, мобилни приложения или нови облачни настройки. Може да не искате да създавате изцяло нов екип за всяка нова тема. В такъв случай разширяването на екипа за разработка на софтуер може да ви даде гъвкава подкрепа около основната ви група. Вие запазвате основните знания и посоката в компанията си и използвате външна помощ за ясни и фокусирани части от работата. В ежедневието това се усеща по-скоро като добавяне на един спокоен експерт към натоварен екип, отколкото като създаване на втора компания.

Има и един много основен аспект, свързан с времето и разходите. Наемането на силни хора може да отнеме много седмици или дори месеци, а през това време вашите забавени задачи не спират. Тук можете да видите ясните предимства на увеличаването на персонала. Можете да привлечете допълнителни ръце за определен период от време и обхват, докато продължавате да мислите за дългосрочно наемане. За някои екипи тази опция изглажда пиковете в търсенето, вместо да налага голямо увеличение на фиксирания брой на служителите. Този вид организация ви позволява да тествате какво прави допълнителният капацитет за вашия продукт, преди да промените цялата си структура завинаги.

Можете също да изберете различни модели за това как тези хора да се присъединят към вашия свят. В модела за увеличаване на персонала вие добавяте външни инженери към вашия екип и вашите лидери ръководят тяхната работа всеки ден. При настройката на екип за разработка в близкия бряг хората се намират в близка часова зона и могат да се включват в разговорите и чатовете ви в нормални часове. Много компании работят с опитен партньор за разработка на софтуер, който вече знае как да прави разработка на софтуер в близкия бряг и да се интегрира с вътрешните екипи. Колкото по-близки са културата, часовата зона и инструментите, толкова по-лесно е да накарате много хора да се чувстват като един екип, дори ако договорите са различни. Тази обща основа е това, което прави външната работа да изглежда естествена, а не нестабилна.

Как подготвяте кода и процесите си, преди да добавите външен екип за разработка?

Подготвяте се за външен екип за разработка, като създадете ясна и проста основа за това как създавате и доставяте продукта си. Необходими са общи правила, основни инструменти и видим начин на работа, преди да дойдат новите хора. Без тази основа всяка промяна зависи от личния стил и паметта, а новите хора нямат начин да отгатнат правилния път. С тази основа дори и новодошлите могат да се движат в сигурен и стабилен ритъм.

Можете да мислите за тази основа като за предпазни бариери за качеството на кода. Тези предпазни бариери са прости проверки, които всяка промяна трябва да премине, независимо от това кой я е написал. Те могат да обхващат начина, по който наименувате нещата, форматирането на файловете и какво означава „завършено“ за всяка малка част от работата. Когато предпазните бариери са еднакви за всички, продуктът ви се усеща стабилен, дори когато екипът расте и се променя. Това улеснява доверието в целия поток, а не само в хората, които вече познавате.

Също така се нуждаете от основна непрекъсната интеграция и доставка. Тази дълга фраза описва една проста идея. Всеки път, когато някой променя кода, системата извършва проверки и помага за прехвърлянето на промяната към потребителите с малки, безопасни стъпки. Този процес може да се изпълнява на общи платформи и да се стартира при всяко добавяне към основния ви код. Един работещ процес превръща многото малки редакции в чиста линия на напредък, вместо в купчина големи, плашещи версии. Новите хора могат да научат този път веднъж и след това да го следват без допълнителни догадки.

Тестовете са ключова част от този път. Автоматизираното тестване в CI/CD означава, че тестовете ви се изпълняват самостоятелно всеки път, когато някой сподели нов код. Можете да започнете с прости проверки, които обхващат най-използваните пътища във вашия продукт. С течение на времето можете да добавите още тестове, като видите къде се появяват бъгове. Дори малък набор от стабилни тестове ви дава повече сигурност, отколкото огромен списък с ръчни проверки, които никой не изпълнява навреме. Този подход поддържа нещата реални и подпомага както вътрешните, така и външните инженери.

Той също така помага да разгледате по-старите части на вашата система, преди да помолите другите да се занимават с тях. Тук влиза в действие основното управление на техническия дълг. Техническият дълг е начин да се опише код, който работи, но е труден за промяна без риск. Можете да маркирате зони, които са безопасни за нови хора, и зони, които все още се нуждаят от грижата на най-опитния ви персонал. Когато знаете къде се намират рисковите части, можете да насочите външния екип за разработка първо към по-безопасните области. Това защитава вашия продукт и предпазва новите хора от скрити капани.

Последната част от основата е простата безопасност и достъп. Сигурният цикъл на разработка на софтуер звучи тежко, но се основава на ясни стъпки. Давате на хората само достъпа, от който се нуждаят, пазите реалните данни на потребителите и се отнасяте внимателно към тайните ключове. Записвате и какво да правите, когато нещо се обърка, дори и в малък мащаб. Когато безопасността е част от нормалната работа, външните инженери могат да се включат в процеса ви, без да предизвикват нови опасения. Вашите правни и сигурностни екипи също виждат, че този растеж следва план, а не е бързо решение.

Как изглежда един безопасен план за въвеждане на външни разработчици?

Един безопасен план за въвеждане на външни разработчици им дава контекст, инструменти и ясни първи стъпки, без да ги хвърля в дълбоки води. Трябва да се усеща като пътека с водач, където всеки ден има проста и реална цел. Когато планът е ясен, новите хора могат да добавят стойност за седмици, а не за месеци, а вашият екип не се чувства изтощен от постоянни въпроси.

Въвеждането на външни разработчици започва с общо виждане за това, което трябва да научат първо. Това включва вашия продукт, вашите потребители и вашия обичаен начин на работа. Чеклистът за въвеждане на разработчици може да събере всички тези елементи на едно място. Той може да бъде в прост документ, който и двете страни могат да отварят и коригират. Видимият чеклист превръща „Мисля, че вече им казахме това“ в „Знаем точно какво е направено и какво следва“. Тази малка промяна премахва много скрит стрес за всички.

Ето един прост списък, който често работи добре като основа за такъв списък:

1. Достъп до код, тракер за работа и основни чат стаи.
2. Стъпки за стартиране на продукта на лаптоп или тестов сървър.
3. Кратко ръководство за потребителите, основните потоци и ключовите бизнес правила.
4. Имена на хора, които да попитате за продукта, кода и инструментите.
5. Две или три малки, ясни задачи, готови за първата реална промяна.

Помага също да се посочи ясно лице за контакт. Технически ръководител или старши инженер може да действа като наставник за първите седмици. Този човек може да преглежда всички ранни промени, да отговаря на въпроси и да обяснява защо миналите решения изглеждат така, както изглеждат. Кратки ежедневни проверки, дори и пет минути в чата, могат да поддържат нещата в правилната посока. Спокоен наставник и постоянни точки за контакт допринасят повече за безопасното въвеждане в работата, отколкото голяма реч на първия ден. С течение на времето можете да преместите повече актуализации в асинхронна комуникация за екипите за разработка, като например кратки писмени бележки.

От това, което съм наблюдавал, най-големият риск по време на въвеждането е тихото объркване. Новите хора се страхуват да задават твърде много въпроси, а старите членове на екипа се надяват, че нещата ще „се наредят“ от само себе си. Ясен план за въвеждане на външни разработчици и един единствен отговорник за този план променят тази картина. Когато един човек отговаря за процеса, можете да забележите модели, да поправите слабите места и да направите всеки следващ цикъл на въвеждане по-гладък. След няколко месеца планът се превръща в повторяем актив, вместо в нова борба всеки път, когато добавяте някого.

Как поддържате качеството на кода в смесен екип за разработка, когато управлявате външни разработчици?

Поддържате качеството на кода в смесен екип за разработка, като използвате едни и същи прости правила, проверки и числа за всички. Вашите стандарти трябва да важат за всички инженери, ако искате продуктът да изглежда като една чиста и сигурна система. Щом разделите правилата по тип договор, разделите и доверието и яснотата в екипа си.

Смесеният екип за разработка е група, в която вътрешни и външни инженери работят по един и същ продукт. Те може да седят на различни места, но споделят едно и също забавяне и едно и също хранилище за код. Тази комбинация може да бъде много силна, защото съчетава дълбоки познания в областта с нови гледни точки. Тя може да бъде и крехка, ако всяка група следва собствените си навици. Без ясни указания тази комбинация се превръща в групи от код, които се усещат по различен начин и между които е трудно да се преминава. Това е моментът, в който качеството и скоростта започват да се разминават.

Тук помагат простите най-добри практики за преглед на кода. Всяка промяна трябва да бъде прегледана от поне още едно лице, независимо от това кой я е направил. Прегледите трябва да се фокусират върху яснотата, безопасността и съвместимостта с останалата част от системата, а не само върху стила. Можете да подпомогнете това с леки инструменти, които сканират кода за често срещани проблеми. Тези рутинни действия поддържат качеството на кода на външните разработчици в синхрон с останалата част от екипа ви по спокоен и повтаряем начин. Хората се учат един от друг и изграждат общо усещане за това какво е „добро“.

Можете също да проследявате малък набор от показатели за екипа за разработка на софтуер. Те могат да покажат колко време отнема завършването на дадена работа, колко проблеми достигат до потребителите и колко често доставяте. Не се нуждаете от десетки числа. Нужни са ви само няколко, които можете да прочетете и обсъдите с лекота. Когато тези показатели остават стабилни или се подобряват, докато управлявате външни разработчици и разширявате екипа, знаете, че вашата структура поддържа качеството. Ако те се влошат, имате ранен сигнал да преразгледате вашите правила, обхват или комбинация от задачи.

Моделите на комуникация са също толкова важни, колкото правилата и числата. Много смесени екипи за разработка също се считат за разпределени гъвкави екипи, защото хората работят от различни места или часови зони. Те се нуждаят от асинхронна комуникация за екипите за разработка, така че напредъкът да не зависи от дълги разговори. Кратките писмени актуализации, ясните бележки за задачите и простите етикети за състоянието помагат много. Добрите писмени актуализации улесняват всички инженери да се включат, да следят и да подобряват продукта с течение на времето. Живите разговори все още са важни, но вече не са единственото място, където се взимат решения.

Начинът, по който привличате външни хора, също определя качеството. Ако ги третирате като отделен поток с неясни цели, те няма да се чувстват напълно отговорни за продукта. Ако ги добавите към съществуващи екипи по един и същ набор от правила, те могат да действат като всеки друг член на екипа. Някои компании използват за това структура за разширяване на екипа, при която съчетават вътрешни и външни хора под едно ръководство. Споделените цели, споделените инструменти и споделените прегледи допринасят повече за качеството на кода в разработката на софтуер, отколкото всеки строг контролен документ. С течение на времето можете да коригирате състава на хората и работата, но общата рамка остава същата.