Как да интегрирате специализиран екип от разработчици за 30 дни

Въведение

Повечето договори за аутсорсинг се провалят още през първия месец, а не през първата година. Инженерите са квалифицирани, а цената е справедлива, но екипът прекарва седмици без достъп, контекст или ясни приоритети. До момента, в който работата започне, клиентът вече е загубил доверие в модела.

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

Преди първия ден: какво да подготвите

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

Подготовката отнема няколко часа работа от страна на клиента. По-голямата част от нея е административна и един човек може да се заеме с целия списък.

• Достъп и акаунти. Създайте акаунти за хранилището на код, системата за проследяване на задачи, облачната конзола и каналите за комуникация. Тествайте всеки акаунт преди датата на стартиране.
• Техническа документация. Съберете архитектурни диаграми, описания на API и ръководства за настройка на едно място. Остарелите документи са приемливи, ако някой отбележи какво се е променило.
• Лице за контакт. Определете едно лице от страна на клиента, което да отговаря на въпроси в рамките на един работен ден. Това лице обикновено е технически ръководител или продуктов собственик.
• Начален списък със задачи. Подгответе 10 до 15 задачи с ниска и средна сложност. Екипът се нуждае от работа, която да го запознае с кода, без да се рискува производствената среда.

Седмица 1: Достъп, контекст и първи задачи

Първата седмица е посветена на ориентацията. Екипът научава какво прави продуктът, кой го използва и как е организиран кодът.

Резултатът през тази седмица е по замисъл малък. Целта е да се създаде работна среда и да се направи първото сливане на промени, а не да се пусне нова функционалност.

Дни 1–2: Настройка на средата

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

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

Дни 3–5: Първи малки задачи

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

Всяка задача преминава през пълния цикъл на преглед на кода, тестване и внедряване. Това показва на екипа как работи клиентът и разкрива пропуските в процеса на ранен етап.

Седмица 2: Процеси и ритъм на комуникация

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

Разпределените екипи се нуждаят от повече структура, отколкото тези, които работят на едно място. Часовите зони и културните различия затрудняват неформалната комуникация, затова ритъмът трябва да бъде ясно определен.

• Ежедневни събрания. Провеждайте кратка видеоконференция в час, който се припокрива и в двете часови зони. Петнадесет минути са достатъчни за обсъждане на статуса и препятствията.
• Планиране на спринтове. Планирайте работата в спринтове от една или две седмици. Продуктовият собственик от страна на клиента определя приоритетите, а екипът оценява необходимите усилия.
• Правила за преглед на кода. Договорете се кой какво преглежда и колко бързо. Забавяне на прегледа с повече от един ден забавя целия екип.
• Писмени актуализации. Поискайте кратко седмично обобщение в общия канал. Това осигурява прозрачност за заинтересованите страни без допълнителни срещи.
• Път за ескалация. Определете кой разрешава препятствията от всяка страна. Акаунт мениджърът на доставчика се занимава с проблемите на екипа, а контактното лице от страна на клиента – с въпросите, свързани с продукта.

Седмици 3–4: Отговорност и измерване

Последните две седмици проверяват дали въвеждането е било успешно. Екипът поема реална отговорност и двете страни преразглеждат резултатите спрямо ясни критерии.

Този етап също така показва къде процесът все още се нуждае от корекции. Малките проблеми се решават по-лесно на 25-ия ден, отколкото на 90-ия.

Предаване на реална функционалност

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

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

Показатели, които да следите на 30-ия ден

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

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

Чести грешки при въвеждането

Повечето закъснения при внедряването се дължат на едни и същи причини. Компаниите ги повтарят, защото всяка от тях изглежда незначителна в началото.

• Закъснял достъп. Акаунтите, които пристигат на третия ден, струват на екипа три дни. Одобренията за сигурност често отнемат повече време от очакваното, затова започнете с тях рано.
• Липса на контекст за продукта. Инженерите, които не разбират потребителите, вземат технически правилни, но безполезни решения. Един час обяснение за продукта спестява седмици преработка.
• Твърде много контакти. Когато пет души дават инструкции, приоритетите влизат в конфликт. Един човек, който взема решенията, поддържа ясна посока.
• Третиране на екипа като външен. Отделните канали за комуникация и ограничените срещи създават двустепенна структура. Екипите, които се включват в рутината на клиента, се интегрират по-бързо.

Заключителни мисли

Тридесет дни са достатъчни, за да се постигне пълна продуктивност на специализирания екип. Резултатът зависи по-малко от доставчика и повече от това колко добре клиентът подготвя достъпа, контекста и ясните приоритети.

Разглеждайте въвеждането като проект с отговорни лица, крайни срокове и окончателен преглед. Структурираният първи месец изгражда доверието, от което се нуждае едно дългосрочно сътрудничество.