*Текстът е предоставен от Devexperts
Здравейте! Аз съм Антония Атанасова – Team Lead в Devexperts, технически лектор на курсове по програмиране и участник в редица IT събития, YouTube-ър, Instagram-ър, LinkedIn-ър, TikTok-ър и всичко останало. Преминаването от техническа към лидерска позиция беше голяма стъпка за мен, защото ми даде свободата да разрешавам не само технически проблеми, но и проблеми, свързани с екипите, процесите и организацията и на екип от програмисти. Откакто преминах на тази позиция виждам в изцяло нова светлина неща, които някога са ми изглеждали прости и лесни. Retrospection срещите (или както ще ги наричам ретроспективи) са едно от тях.
Тази статия е за всички хора, които някога са участвали и намират стойност в ретроспективите – без значение от позицията, която заемат.
Преди всичко реших да дам малко повече контекст на това защо реших да пиша по темата. Проектът, в който работя, имаше дълъг период на стабилизация (само bug fixing, без нови функционалности) и също така имахме преструктуриране на екипите. Тъй като аз бях нов лидер на нов екип имах нужда от няколко месеца, за да свикна с процесите и начина на работа. След няколко месеца работа в екипа реших да организирам и водя първия ни retrospective. И Voilà. Срещата беше пълен провал.
Важно е да уточня, че преди това съм участвала в десетки ретроспективи, водени от други хора и винаги съм била много активна в тях. Просто не бях усвоила занаята на воденето. Тогава един колега ми препоръча книгата Agile Retrospectives: Making Good Teams Great и там разбрах за много от грешките, които бях допуснала. А ето кои са и те:
Грешка 1: Срещите не са редовни
Първата и най-голяма грешка на ретроспективите е да не се правят редовно. Правило, което в едно от видеата си в YouTube съм споделяла, че важи и за срещите 1 в 1. Това е грешка на лидера (организаторът на срещата), която показва нищо повече от липса на интерес за промяна и слаба активност. Много често тази грешка се крие зад думите „Има ли какво да говорим днес? Ако не, нека отменим срещата.“ Когато този въпрос бъде зададен пред много хора, често никой не споделя нищо, дори да е имал какво да каже, и срещата се отменя.
Наскоро имах ситуация, в която момиче, на което съм директен мениджър, ми сподели доста проблеми, свързани с процесите в проекта, в който работи. Когато обаче въпросът беше зададен по време на една от срещите с целият екип последва само мълчание и ретроспективата на проекта беше отменена за пореден път. Причините са съвсем ясни и нормални – психология на тълпите. Човек се притеснява да споделя и говори пръв за проблеми, защото може би другите ги нямат.
Решението е също толкова просто – никога, никога не задаваме въпроса “Има ли нужда от среща днес?”, а просто я правим. За щастие или не, практиката показва, че винаги има място за подобрение и досега лично аз не съм присъствала в ретроспектива, в която просто да няма какво да се дискутира.
Грешка 2: Няма план за срещата
Грешка номер две, която направих аз, беше да нямам план. Знаех, разбира се, каква ще е структурата на срещата – стандартни Glad, Mad & Sad колони като активност, гласуване и дискусия. Проблемът беше основно, че графикът на срещата ми не беше разграфен във времето. Голяма грешка. Когато дадете безкрайно много време на хората да говорят по болна тема, познайте – те ще го направят. Решението на този проблем беше да имам ясен и точен график на срещата, който в моят случай изглеждаше така:
- Представяне, споделяне на цел на срещата, изчакване всички да се съберат – 5 мин
- Попълване на Glad, Mad, Sad колоните от всички (пускам таймер за всяка една) – по 5 мин на колона (15 мин общо)
- Прочитане, ревизиране и групиране на повтарящите се елементи – 10-15 мин (тук идеята е всеки да се запознае с написаното от другите и да няма преповтарящи се казуси)
- Гласуване за топ три проблема в колоните Mad & Sad – 5 min (Това може би е необходимо за по-големите екипи, защото там проблемите са много на брой, от различно естество и е хубаво да се види, кое е „най-наболялото“ за всички. Ако проблемите са малък брой и има време да се обсъди всичко, може би няма нужда от гласуване)
- Дискусия как може да се разреши всеки един от шестте ТОП проблема. Записва се действие, което да се предприеме след срещата. Назначава се отговорен човек. 20 – 30 мин
- Закриване, благодарности на всички участвали, искане на обратна връзка дали трябва да подобрим нещо във формата – 5-10 мин.
Този план в според-зависи ситуацията и хората отнема между час и половина, два часа и поне в нашият екип дава СТРАХОТЕН резултат.
Грешка 3: Няма ясен лидер на срещата
Грешка номер три беше, че аз водех и същевременно активно участвах в ретроспективите. Тъй като това беше проект, в който работя и самата аз, аз също имах нуждата да споделям мнение и да говоря за проблемите ни. Усетих, че е грешка, защото докато другите хора попълваха, аз попълвах заедно с тях и не отделях нужното внимание и разбиране на отговорите им.
Като цяло не смятам, че има нещо лошо човекът, който води срещата, да участва, но смятам, че най-оптималният вариант би бил той да подготви предварително нещата, които има да сподели, за да не губи време докато тече самата среща. Ключово умение за лидера на срещата е да бъде добър слушател и да се старае да разбере всеки един участник.
Грешка 4: Не всеки участва активно
Понякога (особено при по-големи екипи) е голямо предизвикателство за лидера да поддържа еднаква активност от всички. Защото е съвсем нормално да има хора, които по принцип говорят малко повече от останалите, или пък такива, които не обичат да говорят като цяло. Лидерът на срещата има отговорността всеки да е успял да сподели мнение по отделните казуси.
Ако има хора, които говорят прекалено много и вземат цялото време, лидерът трябва да е човекът, който спокойно и с уважение да заяви, че е важно за екипа и успеха на срещата всеки да е имал възможността да вземе думата. Участвала съм в ретроспективи с по-големи екипи (от около двадесет човека) и там дискусиите се правеха в групи от по трима, четирима и лидерът минаваше през всяка група, за да е сигурен, че има продуктивни дискусии. Когато се дискутира даден проблем и лично аз забележа, че някой стои в ъгъла и не говори много винаги питам лично човека какво мисли по даден казус. Всеки е различен и е напълно нормално някои хора да се притесняват да вземат думата – задача на организатора обаче е да им даде поле за изява.
Грешка 5: Няма ясно дефинирани проблеми
Когато дълго време не е имало ретроспектива, но проблеми в екипа и в процесите на работа ИМА, е съвсем нормално да има емоция. Понякога човек не успява да овладее тази емоция и казва неща, които са му „натежали“. Тези неща обаче могат да имат негативно влияние върху екипа. Когато споделяме и дискутираме подобни казуси винаги трябва да си задаваме въпроса „Но какъв всъщност е проблемът?“. Защото разбивайки емоцията и задавайки си този въпрос, всъщност проблемът може да е доста елементарен.
Например “QA екипът е некомпетентен“ -> „Задачите, които се създават от QA екипа не са добре дефинирани“ -> „Липсва шаблон, по който да се създават задачи, за да има всичко необходимо като информация за програмистите“.
Или „Занимаваме се само с глупости, оправяме неща, които не са важни за задачите ни, еди кой си ми губи времето и не искам да се занимавам с неговите прищевки.“ -> „Трябва да оправям неща, които не са упоменати никъде в описанието на задачата ми, но се считат за подобрения.“ -> „Нямаме ясни изисквания какви неща считаме за стандарт в нашия проект“.
Ако успеем да минем през този филтър преди да споделим и изразим негативна емоция по време на ретроспективата, то тогава се справяме отлично. Ако ни е трудно да го направим лидерът на срещата е този, който трябва да ни помогне да дефинираме проблема, задавайки правилните въпроси.
Грешка 6: Завършване на срещата без ясен план за действие
Една от най-големите грешки, които направих водейки първата си ретроспектива, беше да я приключа след дискусията на проблемите, защото не беше останало време. Така всъщност прекратих срещата в най-важния момент – тогава, когато трябваше да се направи план за действие. Не се колебайте, ако попаднете в подобна ситуация и не остане време за най-важното, да организирате follow up среща, но със сигурност не си позволявайте да пропускате последната част.
Когато екипът заедно гласува и избере най-наболелите проблеми, то тогава започва дискусията по тях и планирането как да се решат. До всеки съществуващ проблем трябва да стои и ясно дефинирано решение и план за действие. В ситуации, в които няма време да се обсъдят в детайли всички проблеми, е по-добре да се направи план поне за първите няколко, а другите да се оставят за следващата среща, отколкото нещата да се претупват и накрая да не се предприеме нищо.
Грешка 7: Няма отговорно лице за действие
След като всички са наясно, какви са проблемите и как могат да бъдат разрешени, остава някой само да се заеме с тях, нали?
При по-големите екипи и при по-динамичната работа, ако няма „назначен“ човек, тези проблеми просто летят в пространството и след известно време биват забравени. Например, в екипа, в който работя аз, имаше техническа дискусионна среща, в която обсъдихме един наболял tech dept проблем. Всеки даде някакви предложения, разгледахме кода, имаше идеи и с това срещата приключи. Половин година по-късно същият проблем беше отново повдигнат на ретроспектива и аз осъзнах, че тогава просто си поговорихме за него и така и никой не се зае с разрешаването му. Нямаше отговорно лице, което да поеме инициативата, за да го разреши и проблемът потъна в забрава.
Затова е важно по време на дискусията за всеки ясно дефиниран проблем да бъде назначено и отговорно лице за разрешаването му. Аз обикновено питам кой иска да се заеме и разчитам на добра воля и проактивност и винаги има някой, който иска да го направи.
Като процес това изглежда така от гледна точка на лидера:
- Лидерът прочита какъв е проблемът.
- Пита хората как този проблем може да бъде разрешен – дискусия и предложения.
- След като се стигне до взаимно съгласие, какви действия трябва да бъдат предприети, лидерът пита кой иска да се заеме със задачата.
- В плана за действия се добавя името на задачата и човекът, отговорен за нея.
Това бяха седемте най-големи грешки, които аз допуснах, организирайки първата си ретроспектива и мога да кажа, че резултатът беше коренно различен, когато ги разреших. Надявам се всеки, който присъства на подобни срещи или ги организира, да е успял да вземе нещо за себе си, за да подобри работата на екипа си.
Със сигурност не казвам, че тази статия е само за технически лидери, проектни мениджъри или лица в мениджмънт позиция, които ще бъдат в позицията да организират ретроспективи. Напротив, и водещите, и участващите трябва да знаят, че това е идеалното място за споделяне на обратна връзка. Инак казано, ако нямате ретроспективи или имате, но не са ефективни, бъдете двигател на промяната, независимо от позицията, в която се намирате.