Когато започнах работа като разработчик в Хонконг, iOS все още беше във версия 4. Оттогава станах един от шестте партньора в една от водещите агенции за уеб и мобилно развитие в Хонконг. Освен че действам като технически лидер или PM за проекти, работя по инициативи като създаване на „Клъстер на Kubernetes за DevOps“ на компанията и наставлявам младши разработчици.

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

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

Как работим с новите членове на екипа

Без значение какъв е техният опит, ние очакваме всички наши разработчици да бъдат пълен стек. (Бен, съосновател, обясни „как наемаме разработчици въз основа на фундаментални познания“, ефективно внедряване и желание за изучаване на нови езици.) ​​За нашата компания един сървърен инженер трябва да има желание да работи в мрежата и на мобилни устройства проекти; един фронтенд инженер трябва да е готов да подсили своята бекенд логика. Всеки има различни силни страни, но разполагайки с пълен набор, разработчиците могат да обмислят функциите в тяхната цялост за приложения.

Когато наемем нов член на екипа, ние го включваме незабавно в нашите проекти. Ние възлагаме задачи в платформи, с които са запознати първо (напр. iOS, Android, JS), така че да могат да се съсредоточат върху обучението си как да работят с членовете на нашия екип.

По време на адаптирането можем да видим как работи един разработчик. Това включва:

  • техния стил на кодиране
  • тяхната логика
  • способността им да пишат четливи ангажименти

Какво означава съобщението за ангажиране за нас

Приспособяването към стилове на обвързване понякога може да бъде болезнено. Ангажиментите може да са непоследователни или да имат множество промени в една заявка за изтегляне. Работил съм с току-що завършили университет, които може би използват git за първи път (не се изисква във всички университети в Хонконг), които се адаптират след седмица. Също така имах опитен разработчик, който поставяше 30+ микрокомити в заявка за изтегляне и ме питаше дали правилото е „колкото повече ангажименти, толкова по-добре“, когато повдигнах въпроса за четливостта на неговите „заявки за изтегляне в работния процес на Github“.

Ангажиментът е повече от просто „начинът на нашата компания да прави нещата“. Нашите две основни съображения са 1) четливост и 2) логически фактор при бъдеща поддръжка (Wiki за „Atomic commits“).

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

Това, което ни казва ангажиментът е:

  • Как мисли някой за дадена функция? Как разделят задачите? Поставят ли всичко в един гигантски ангажимент? Или ги нарязват на тънки парчета, докато другите не могат да разберат логиката?
  • Каква е тяхната работна логика? Способни ли са да направят една логическа промяна на ангажимент, така че да можем да обединим или върнем обратно, ако е необходимо?
  • В състояние ли са да мислят за другите? Когато пишат съобщения, те ясни ли са, така че техническият ръководител или партньорската проверка да може да разбере и приеме или отхвърли заявка за изтегляне?
  • Желаят ли да приемат обратна връзка? Как реагират на съветите на своя технически приятел или технически ръководител? Способни ли са да приложат промени? Могат ли да обяснят логиката си, вместо да приемат последващите въпроси лично?

Намиране на сладкото място между свободата и работата в екип

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

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

Неща, които не трябва да се случват

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

Моят съвет към новите разработчици

Работата в Oursky означава непрекъснато учене като разработчик. Един от уроците, които често ни напомнят, дори и с колеги, с които сме работили от години, е, че винаги има пропуски в комуникацията. Използването на подхода Atomic commit е ангажимент за създаване на добре обмислени функции, които са разбираеми и следователно могат да се поддържат за хората в бъдеще (включително за вас!).

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

Също така управлявам „бекенда с отворен код“ на Oursky и ще се радвам да чуя вашите отзиви!

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