Защо софтуерните екипи трябва да наемат външни консултанти, докато приемат нови стекове.

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

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

След няколко месеца и постоянни рефактори, проектът се разгръща в производство - все пак нещо не е наред. Обещаното качество го няма, кодът е пълен с грешки и е труден за поддръжка или наблюдение. Няма консенсус как да продължим напред. Пазим ли го? Преработваме ли? Връщаме ли се към стария, но по-разбран стек?

Можеше ли това да бъде избегнато?

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

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

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

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

Синдром „Не е измислено тук“.

През последните няколко години организациите преминаха към стандартизирани решения от вътрешни решения. В наши дни е рядкост да видите персонализирани рамки или ORM (което беше норма преди десет години). Например, много организации започнаха да пускат кода си с отворен код и да споделят вътрешните си добри практики. Управляваните облачни решения също станаха широко използвани за разлика от хостването и поддържането на неща вътрешно.

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

Прекалена самоувереност

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

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

Пари

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

Ако не искате да харчите пари, за да го направите както трябва от първия път, имате ли пари и време да го направите два пъти?

Виждал съм множество провалени проекти, които можеха да бъдат спасени, ако се намеси консултант. Например:

  • Мигрирането към React отнема 3 пъти повече време от първоначално прогнозираното.
  • Преминаване към ориентирана към микроуслуги архитектура и затруднения с транзакции или управление на данни.
  • Въвеждане на нов език за програмиране без познаване на добри практики и библиотеки, причиняващи постоянен рефакторинг.

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

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

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

Запитайте се дали синдромът „не е измислен тук“ дебне вашия екип и дали сте готови да прегърнете опита на някой извън него или предпочитате да поемете разходите, свързани със забавен проект.