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

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

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

За да стане ясно, всички тези механизми трябва не да се използва за контрол или микро-управление на служителя.

Не вярвайте в отдалечени митове и заблуди на екипа

Нека да разгледаме плюсовете и минусите на управлението на отдалечени екипи по един проект, като започнем с комуникация.

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

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

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

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

Не позволявайте на често срещаните заблуди и предразсъдъци да замъгляват вашата преценка. Tweet

Не забравяйте да възприемете и насърчите многообразието

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

Но не се притеснявайте; разнообразието е добро за бизнеса!

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

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

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

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

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

Не пренебрегвайте или пренебрегвайте културните и езикови различия. Те могат да направят или да разбият отбор. Tweet

Не приемайте с лека ръка набирането и обучението

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

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

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

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

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

Не забравяйте, че отдалечените разработчици трябва да бъдат равностойни членове на екипа. Tweet

Не използвайте сложна информационна система

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

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

Моето отдавна любимо приложение за управление на проекти е Redmine , система с отворен код, междуплатформена система и междусистемна база данни. Тази платформа е силно конфигурируема и можете да интегрирате свой собствен SCM, различни плъгини и куки за услуги.

Ако не искате да преживявате неприятностите да поддържате собствения си сървър с Ruby и да настройвате всичко сами (Redmine може да бъде сложен за неопитни системни администратори), друг добър избор е GitHub, който включва не само git CMS, но и GitHub Issues , който се интегрира добре с вашите съобщения за ангажиране, заявки за изтегляне и т.н.

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

Не използвайте сложна информационна система. В отдалечен екип може да причини повече вреда, отколкото полза. Tweet

Не използвайте Micromanage

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

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

Както всичко останало в живота, всичко е свързано с намирането на добър баланс.

Не управлявайте отдалечени екипи на микро. Ще задушите иновациите и инициативността. Tweet

Не се притеснявайте за часовите зони, използвайте ги в своя полза

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

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

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

Не се притеснявайте твърде много за различни часови зони. Вместо това ги използвайте във ваша полза. Tweet

Не налагайте ежедневни цели, фокусирайте се върху средносрочни или дългосрочни цели

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

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

Според мен Agile манифестът (методологии) е най-доброто нещо, което се е случило в управлението на проекти през последните няколко години.

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

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

Не претоварвайте отдалечения си екип с излишни цели и графици. Tweet

Не скривайте подробности за бизнеса

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

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

Процесът на развитие на Agile също е полезен тук. Той дава възможност за споделяне на знания между страните (заинтересовани страни, изпитатели, разработчици и др.) Чрез премахване на всякаква йерархия и като се разглеждат тези партии като равни членове на екипа, със същите отговорности, и по този начин ги насърчава да работят възможно най-прозрачно. Друго предимство на прозрачността е, че проблемите се „ескалират“ бързо и могат да бъдат отстранени от всяка част от екипа.

Не пазете нищо в тайна, освен ако не е абсолютно задължително. Tweet

Не игнорирайте отдалечените членове на екипа

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

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

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

Отново това ще изгради комуникативни умения и ще подобри доверието.

Не пренебрегвайте отдалечените членове на екипа, просто защото не ги виждате всеки ден. Tweet

Съвети за бързо дистанционно управление на екипа

Тъй като вече обобщих основните моменти в туитове и илюстрации, ето още няколко бързи съвета и мисли.

• Тези общи правила могат да бъдат приложени към отдалечени и на място разработчици.
• Ако управлявате микро, ще пропуснете възможността да научите и да оставите да се учи.
• Бъдете отворени и надеждни, тъй като това е единственият начин да изградите добър отдалечен екип.
• Имайте предвид, че приблизителната оценка е само приблизителна; ще срещнете под и над оценки.
• Всички, които работят, грешат и ако не простите грешките на другите, и вашите няма да бъдат простени.
• Най-важното е, че най-голямата мотивация за всеки разработчик (освен удовлетворението от изпълнението на трудна задача) са парите. Така че, не отлагайте плащанията и помислете и за въвеждане на бонусни политики.