Коучинг за Developers вместо раздаване на нареждания
Научете защо даването на директни указания на софтуерните инженери намалява тяхната отговорност. Открийте практични коучинг техники, които помагат на Scrum Developers да поемат пълна отговорност за техническите си решения.
Повечето лидери биват повишавани, защото са били добри в решаването на технически проблеми. Когато преминат към ръководене на Scrum екип или когато се включи опитен Scrum Master, инстинктът им подсказва веднага да раздават готови отговори. В момента това изглежда ефикасно. Виждате архитектурно тясно място, казвате на екипа как да преструктурира базата данни и всички продължават напред. Но всеки път, когато дадете нареждане или решите проблема сами, вие отслабвате екипа. Scrum Guide изрично посочва, че Developers са самоуправляващи се: те решават кой какво прави, кога и как. Ако им спускате директиви, самоуправлението се изпарява.
Скритата цена на раздаването на инструкции
Когато наставлявате инженерите с преки нареждания, вие им отнемате чувството за отговорност върху крайния резултат. Ако някой програмист приложи точно вашето предложение и внедряването се провали в полунощ, грешката не е негова. Тя е ваша. Хората спират да мислят задълбочено за архитектурата на системата, за граничните случаи и качеството, защото разчитат някой друг да им каже какво да правят. С течение на времето най-добрите кадри напускат, а останалите се превръщат в пасивни изпълнители на заповеди.
В Scrum именно Developers носят отговорност за създаването на план за съответния Sprint, за Sprint Backlog и за гарантирането на качество чрез спазване на Definition of Done. Не можете да търсите отговорност от някого за резултата, ако сте му продиктували всяка стъпка за постигането му.
Силни въпроси вместо готови отговори
Коучингът е умението да помагате на хората сами да обмислят и решат проблемите си. Вместо да казвате на някой разработчик как точно да рефакторира дадено API, вие му задавате въпроси, които да насочат неговия анализ. Това променя нагласата от сляпо изпълнение към истинско любопитство.
- Какъв риск се опитвате да намалите с тази схема на базата данни?
- Как този избор на имплементация влияе върху нашата Definition of Done?
- Ако тази услуга спре да работи при голямо натоварване, къде ще се прояви проблемът най-напред?
- Коя е най-малката стъпка, която можем да предприемем, за да тестваме тази хипотеза преди Sprint Review?
Забележете, че нито един от тези въпроси не съдържа скрито нареждане. Капан, в който падат много коучове, е задаването на насочващи въпроси като "Не мислиш ли, че тук трябва да използваме кеширане?". Това всъщност е директно нареждане, маскирано като коучинг. Истинските коучинг въпроси са отворени и предразполагат към задълбочен анализ.
Осигуряване на пространство за самостоятелно справяне с трудностите
Доброто инженерство изисква продуктивно преодоляване на трудности. Ако някой програмист прекара два часа в търсене на причината за нестабилен тест или се бори с труден бъг при паралелни процеси, първият ви импулс може да бъде да се намесите. Устойте на това. Намесете се само когато усилието прерасне във фрустрация или когато екипът изрично поиска помощ.
Scrum Guide ясно посочва, че Scrum Master служи на екипа, като го напътства чрез коучинг в самоуправление и мултифункционалност. Коучингът изисква търпение. Трябва да позволите на хората да правят малки, поправими грешки по време на съответния Sprint, за да могат да извлекат поука от тях по време на Sprint Retrospective.
Промяна на баланса в ежедневната практика
Преминаването от раздаване на инструкции към коучинг не означава да се откажете от техническите стандарти или да скриете своята експертиза. То просто означава да промените последователността на разговорите си. Когато член на екипа дойде при вас с дилема, изслушайте го докрай, преди да вземете думата. Попитайте го какви възможности вече е обмислил.
Често колегите вече знаят правилния отговор. Те просто имат нужда от събеседник, пред когото да проверят своите разсъждения. Когато им предлагате въпроси вместо готови решения, вие изграждате автономен инженерен екип, способен да доставя стойностен Increment, без да зависи от вас.