Убиват ли срещите продуктивността на софтуерните инженери?

Мартин Марков, CEO на Appolica. Снимка: Личен архив

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

Полезни уроци от своя опит и практични насоки за по-добра организация на работата на софтуерните инженери споделя Мартин Марков - Главен Изпълнителен Директор на Appolica.

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

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

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

Как да овладеем претоварването със срещи

Когато сте част от малък екип – до 10 души – е лесно да сте в крак с всичко, което се случва в компанията. Знаете по какви проекти се работи, какви функционалности се изискват от клиентите, дали има оплаквания от настоящи такива и дори какво мислят основателите. Комуникацията протича естествено и всеки е наясно какво се случва.

Но когато екипът нарасне до 20, 30 или 50 души, става много по-трудно да следите всичко. Потокът от информация, който преди е вървял гладко и без усилия, започва да се разпада и обикновено се стига до един от тези два сценария:

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

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

Първият сценарий води до два основни проблема:

● С разрастването на екипа хората започват да участват в срещи, които не са ценни за тях и им дават малко информация, която има стойност за тях.

● С увеличаването на броя на хората в компанията нараства и броят на срещите, тъй като всеки иска да получи мнение или одобрение от останалите.

Резултатът от това е комуникационен хаос. Продуктивността рязко спада, защото всички в компанията се намират в безкраен кръг от срещи, което оставя малко време за „истинска“ работа. За да се справите с този хаос, е необходимо да въведете ясна структура:

● Основатели/мениджъри на високо ниво: определят визията и стратегията на компанията.

● Ръководители на екипи: привеждат визията и стратегията в конкретни цели и планове.

● Разработчици и delivery екипи: вършат оперативната работа и изграждат продукта.

Тази тристепенна структура изглежда логична, но идва с предизвикателство – загуба на информация. Проучвания показват, че около 30% от информацията се губи, докато преминава през всяко ниво. Това означава, че докато визията на основателите достигне до delivery екипите, над половината от първоначалното послание вече е изгубено.

Парадоксът на комуникацията

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

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

Перфектният сценарий

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

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

Промени на персонално ниво

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

● Питайте защо сте нужни. Преди да приемете покана, уточнете каква роля ще играете в срещата и с какво можете да допринесете. Ако няма да сте активен участник, не се включвайте.

● Определете най-продуктивното си време. Независимо дали сте най-фокусирани рано сутрин, късно следобед или вечер, блокирайте тези часове в календара си. Те са вашето време за фокусирана работа без разсейвания.

● Поискайте запис, вместо да присъствате. Ако срещата не изисква активно участие от ваша страна и сте там само за да слушате, поискайте тя да бъде записана. Използвайте инструменти като Loom, за да получите ключовата информация – решенията, които са взети, и следващите стъпки за действие. Така можете да наваксате с информацията асинхронно.

Промени на екипно ниво

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

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

● Комбинирайте ретроспективни срещи и такива за планиране в последователни сесии без прекъсвания. Дръжте всяка сесия фокусирана – максимум 30 – 45 минути.

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

Забелязал съм, че повечето продуктови екипи смятат, че ако пропуснат създаването на документация, ще ускорят работата си. На практика обаче това често води до забавяния. Без ясни насоки инженерите не знаят точно какво трябва да направят и се сблъскват с два възможни сценария:

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

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

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

Промени на ниво компания

Това е най-голямото предизвикателство. Основателите и ръководителите на високо ниво (C-level) традиционно се фокусират върху това дали всички са в синхрон с целите на компанията, напредъка в изпълнението им, визията и общото удовлетворение на екипа. Поради значението им е лесно всяка от тези теми да се превърне в повод за среща. Преди да се усетите, всеки ъпдейт заема слот в календара. Ето как подхождам, за да избегна това:

● Месечна среща (all-hands meeting): единствената среща, която според мен не трябва да се пропуска. Това е единственият момент в месеца, в който основателите и мениджмънтът могат директно да комуникират с всички, а служителите могат да задават въпроси. Държа ъпдейтите възможно най-кратки – максимум 20 – 30 минути – и се фокусирам върху предоставянето на контекст, а не просто върху повтаряне на статистика, до която хората вече имат достъп. Отделям около 30 минути за въпроси и ако е необходимо повече време, го осигурявам. 

● Дни без срещи: дори при най-добрите практики на лично и екипно ниво срещите все пак успяват да прекъснат продуктивния ритъм на инженерите. Именно затова е полезно да се определят цели (или половин) дни без никакви срещи. Това осигурява на всички фокусирано време за задълбочена работа без разсейвания.

● Споделяне на информация асинхронно: подобно на практиките на екипно ниво, повечето актуализации трябва да се споделят асинхронно чрез инструменти като Notion или Loom. Така всеки, който се интересува или има нужда от повече контекст, може да получи информацията в удобно за него време, без да се налага да участва в ненужни срещи.

Заключение

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

Вижте по какви проекти работи Appolica

Вижте профила и актуалните позиции за работа на Appolica Ltd. в JOBS.bg