Praca z interesariuszami spoza branży inżynieryjnej:

Większość treści dotyczących zarządzania inżynierią traktuje interesariuszy jako wrogi zasób, którym należy zarządzać: odrzucaj ich żądania, zarządzaj ich oczekiwaniami, chroń przed nimi zespół. Takie sformułowanie jest błędne i to jest powód, dla którego wiele relacji z interesariuszami z rynków wschodzących w końcu ulega pogorszeniu.

Interesariusze nie są przeszkodą. Oni są powód zespół ma nad czym pracować. Zadaniem nie jest zarządzanie nimi; to tłumaczenie pomiędzy dwoma językami: rzeczywistością inżynierską i rzeczywistością biznesową. Większość EM robi to źle, ponieważ nikt ich nie nauczył, jak to zrobić.

To jest podręcznik zabaw. Praca tłumacza, pięć powtarzających się osobowości interesariuszy i sposób, w jaki każda z nich przerywa sprint zespołu, szablon cotygodniowej aktualizacji, który obsługuje 90% komunikacji z interesariuszami jeden na jednego oraz zasada, która chroni zespół bez spalania relacji.

Problem z tłumaczeniem

Inżynierowie i interesariusze używają tych samych słów, mając na myśli różne rzeczy.

„To zajmie tydzień”. Inżynier oznacza „w idealnym świecie, w którym nie ma żadnych przerw, jest to tydzień skupionej pracy”. Interesariusz słyszy: „Będziemy mieli to na moim biurku za siedem dni”.
„Gotowe”. Inżynier oznacza „kod przechodzi testy i jest głównym”. Interesariusz oznacza „użytkownicy mogą z niego korzystać, a my zmierzyliśmy wpływ”.
„Proste.” Inżynier oznacza „żadnych nowatorskich koncepcji”. Interesariusz oznacza „powinniśmy być w stanie to zrobić dziś po południu”.
„Musimy dokonać refaktoryzacji X.” Inżynier oznacza, że „kod powoduje prawdziwe problemy, za które zapłacimy, jeśli się nimi nie zajmiemy”. Interesariusz słyszy, że „inżynierowie chcą bawić się kodem, zamiast dostarczać funkcje”.

Tłumaczenie nie jest opcjonalne. Albo EM robi to celowo, albo dzieje się to przypadkowo i źle. Pierwszy nawyk:

Ilekroć zdanie może oznaczać dwie różne rzeczy dla zespołu i interesariusza, przed uzgodnieniem czegokolwiek przeformułuj je wyraźnie w obu językach.

Pięć osobowości interesariuszy i sposób, w jaki każda z nich przerywa sprint

Wzory się powtarzają. Większość EM ostatecznie spotyka wszystkie pięć. Zachowanie i poprawka:

1. Chętny premier

Zachowanie: Ciągle odkrywa nowe pomysły. Każdy DM na Slacku pyta: „Czy moglibyśmy też…?” Traktuje zaległości jako powierzchnia burzy mózgów. Nie zdaje sobie sprawy, że każde nowe zapytanie kosztuje wydajność sprintu.

Co idzie nie tak: Zespół gromadzi 30 częściowo określonych zadań. Planowanie sprintu zamiast zaangażowania staje się selekcją. Inżynierowie tracą kontekst za każdym razem, gdy zmieniają się priorytety.

Poprawka: Dwa kanały; jeden na pomysły, drugi na zobowiązania. Pomysły trafiają do udostępnionego dokumentu lub zaległości ze statusem „koncepcja”. Zobowiązania przechodzą przez planowanie sprintu. To nie jest biurokracja; oddziela „czy moglibyśmy” od „czy będziemy”, aby zespół mógł się skupić.

Scenariusz: "Dodanie do dokumentu pomysłów; omówmy przy planowaniu następnego sprintu, czy nadać mu priorytet. Bieżący sprint został zatwierdzony. "

2. Niespokojny założyciel/dyrektor generalny

Zachowanie: Codziennie wysyła pingi dotyczące jednej funkcji. Pyta o status, czasami kilka razy dziennie. Czyta liście herbaty. Martwi się, że inżynieria postępuje „zbyt wolno”.

Co idzie nie tak: Inżynierowie są wciągani w doraźne aktualizacje statusu, które nie wnoszą wartości dodanej. Zespół czuje się obserwowany, a nie ufany. Założyciel odbiera sygnały, których nie powinien (pojedynczy błąd zmienia się w „inżynieria nie może wysłać”).

Poprawka: Przewidywalny kanał aktualizacji. Cotygodniowa pisemna aktualizacja (wzór poniżej). W przypadku większych inicjatyw pojedynczy pulpit nawigacyjny lub dokument, który założyciel może obsługiwać samodzielnie. Większość sygnałów od niespokojnych założycieli zatrzymuje się w momencie, gdy mają gdzie szukać.

Scenariusz: "Będę wysyłał pisemne aktualizacje w każdy piątek. W przypadku [dużej inicjatywy] tutaj jest pulpit nawigacyjny; na bieżąco go aktualizuję. Jeśli potrzebujesz czegoś pomiędzy piątkami, napisz do mnie bezpośrednio, a odpowiem tego samego dnia."

3. Sceptyczny lider finansowy

Zachowanie: Pytanie: „Co inżynieria wysłała w tym kwartale?” z ukrytym sformułowaniem „za wydane pieniądze”. Chce przekonwertować wyniki inżynieryjne na jednostki policzalne. Traktuje inżynierię jako centrum kosztów.

Co idzie nie tak: Zespół czuje się ograniczony do liczenia zadań. Prace wewnętrzne (refactoring, infra, on-call) są niewidoczne. Projekty strategiczne są karane za powolność.

Poprawka: Kieruj wynikami, a nie wynikami. Nie mów „wysłaliśmy 47 zadań”. Powiedzmy: „zmniejszyliśmy wskaźnik błędów przy kasie z 4,2% do 0,8%, co pozwala odzyskać utracone zamówienia w przybliżeniu X GBP miesięcznie”. Przekładaj prace inżynieryjne na wpływ na biznes w każdym kwartalnym przeglądzie.

Scenariusz: "Podsumowanie kwartalne; wyniki i praca stojąca za każdym z nich. Trzy duże wyniki, dwie trwające inwestycje, jedno ryzyko, którym zarządzamy."

4. Interesariusz będący ekspertem dziedzinowym

Zachowanie: Doskonale zna swój zakątek firmy. Ma zdecydowane opinie na temat tego, jak powinny działać funkcje, często oparte na długim doświadczeniu. Frustracja, gdy inżynieria wdraża coś inaczej.

Co idzie nie tak: Zespół programistyczny wdraża zmiany, interesariusz ich nie akceptuje i trzeba je przerobić. Albo zespół odmawia, interesariusz czuje się ignorowany, a relacje się pogarszają.

Poprawka: Wciągnij ich do wymagań wcześniej zaczyna się inżynieria. 30-minutowy przegląd historii użytkownika i kryteriów akceptacji z interesariuszem jest wart tygodnia przeróbek. Nie rób z tego „demona na koniec”; niech będzie „przejrzyj specyfikację na początku”.

Scenariusz: "Zanim zaczniemy, omówimy z tobą specyfikację; 30 minut. Lepiej wychwycić brakujące niuanse teraz, niż potem, gdy zbudowaliśmy coś niewłaściwego. "

5. Niezaangażowany interesariusz

Zachowanie: Mówi „ty decydujesz”. Nie pojawia się na demonstracjach. Nie odpowiada na pytania wyjaśniające. Następnie narzeka, gdy wynik nie jest taki, jakiego oczekiwali.

Co idzie nie tak: Zespół programistyczny przyjmuje założenia, wdraża zmiany i jest obwiniany za te założenia. Albo wstrzymuje pracę, czekając na informacje, cel sprintu poślizgi.

Poprawka: Wymuszanie decyzji na timerze. "Potrzebujemy decyzji w sprawie X do środy; jeśli jej nie mamy, zastosujemy opcję [domyślną]. Wartość domyślna jest rozsądna, ale nie jest to coś, co byś wybrał, gdybyś się zważył. "

Scenariusz: „Potrzebna decyzja: A lub B. Domyślnie wybierzemy A w środę, jeśli się nie zważysz. A jest w porządku; jeśli wolisz B z powodów, których nie widzimy, powiedz nam do tego czasu”.

Szablon cotygodniowej aktualizacji dla interesariuszy

90% komunikacji z interesariuszami można obsłużyć za pomocą pisemnej, cotygodniowej aktualizacji. Trzy akapity:

Co zostało wysłane w tym tygodniu: Wyniki widoczne dla użytkownika, nazwane zgodnie z ich wpływem na biznes. Nie „scalono refaktora uwierzytelniania”; „zalogowani użytkownicy widzą o 30% szybsze ładowanie strony.”

Co jest w locie: Aktywna praca sprintu, wyrażona jako wynik, do którego dąży sprint. Jeśli istnieje ryzyko (ktoś odpada, utrata zależności), wymień je tutaj bez dramatyzowania.

Co dalej: Jedno zdanie na temat celu następnego sprintu, sformułowane jako wynik.

Poniżej jeszcze dwie linijki:

Gdzie szukać: link do pulpitu nawigacyjnego / tablicy sprintu / wykresu metryk, który mogą obsługiwać samodzielnie.
Czego potrzebuję od ciebie: wyraźne pytania, jeśli takie istnieją. „Do wtorku potrzebuję decyzji w sprawie poziomów cenowych, abyśmy mogli uwzględnić ją w następnym sprincie”.

Ten format działa, ponieważ odpowiada na trzy pytania, które faktycznie zadają interesariusze: co się zmieniło, co dzieje się teraz, co nadchodzi. Bez aktualizacji wymyślają odpowiedzi.

Zasada eskalacji: chroń zespół, nie niszcząc relacji

Inżynierowie zazwyczaj:

Absorbuj presję interesariuszy po cichu, nie osiągaj celu i żywij do niego urazę. Lub
Odeprzyj bezpośrednio interesariuszy, zniszcz relacje i strać wsparcie polityczne dla inżynierii.

Żadne nie działa. Środkowa ścieżka jest widoczne rozmowy o wymianie:

„Tak, możemy zrobić X. Aby to zrobić w tym sprincie, odetniemy A lub B. Jeśli A i B mają wyższy priorytet, odłożymy X. Twoja decyzja.”

To działa, ponieważ:

To nie oznacza nie; jest napisane: „oto kompromisy”.
Sprawia, że decyzja należy do zainteresowanej strony.
Dokumentuje taki kompromis retrospektywa rozmowy zawierają dane.
Nie udaje, że zespół ma nieskończone możliwości.

Zespół kończy z tym samym wynikiem; chroniona zdolność sprintu, odroczona nowa praca; ale interesariusz czuje się wysłuchany, a nie odrzucony. Większość interesariuszy wybiera opcję domyślną („OK, odłóż do następnego sprintu”), gdy zobaczą kompromis.

Trzy rzeczy, których należy robić mniej

Typowe błędy w zarządzaniu interesariuszami, które szkodzą relacjom:

Nie tłumacz złożoności inżynieryjnej jako heroizmu wysiłku. „To było naprawdę trudne” oznacza, że należy podziękować inżynierowi. Interesariuszy nie obchodzi, jak trudne to było; dbają o to, co dostali. Mów o wynikach, a nie o pocie.
Nie bądź jedynym kontaktem z interesariuszami zespołu. Jeśli tylko EM rozmawia z interesariuszami, inżynierowie nie mogą rozwinąć tych umiejętności, EM staje się wąskim gardłem, a interesariusze czują się odcięci od zespołu. Wybierz kilku starszych inżynierów, którzy będą współdzielić interfejs, nawet jeśli będą tylko na potrzeby konkretnych projektów.
Nie karm interesariuszy niejasnymi zapewnieniami. „Robimy postępy” bez szczegółów jest mniej pocieszające niż „ukończyliśmy już w 60% i jesteśmy na dobrej drodze do piątku”. Niejasność można odczytać jako „oni nie wiedzą”, nawet jeśli ty wiesz.

Trzy rzeczy, których warto robić więcej

Przedstaw swoje rozumowanie, a nie tylko wnioski. „Wybraliśmy B, ponieważ A oznaczałoby 3 tygodnie zależności od zespołu zajmującego się platformą; oto matematyka”. Interesariusze ufają EM, za którymi mogą podążać, nawet jeśli się z nimi nie zgadzają.
Uprzedzaj ich przewidywalne obawy. Finanse zawsze pytają o koszty. Sprzedaż zawsze pyta o harmonogram. Założyciele zawsze pytają o ryzyko konkurencyjne. Zwróć się do tych osób, zanim będą musiały o to zapytać.
Zapoznaj zespół z opiniami interesariuszy. Kiedy interesariusz jest zachwycony wdrożoną zmianą, podziel się tą reakcją z programistą, który ją przygotował. Kiedy interesariusz jest niezadowolony, przekaż jego uwagi konstruktywnie. Programiści, którzy nigdy nie poznają reakcji interesariuszy, przestają widzieć swój związek z biznesem.

Podsumowanie

Interesariusze nie są wrogami. To oni są źródłem pracy i potrzebują kompetentnego tłumacza między swoim językiem a językiem zespołu. Praca tłumacza jest pracą EM. Zrób to celowo:

Przed wyrażeniem zgody przeformułuj niejednoznaczne stwierdzenia w obu językach.
Rozpoznaj pięć osobowości i zastosuj poprawkę strukturalną dla każdej z nich.
Wysyłaj cotygodniowe pisemne aktualizacje, aby niepokój nie zmienił się w sygnały doraźne.
Spraw, aby kompromisy były widoczne; chronić potencjał zespołu, ujawniając, co należy wyciąć, a nie mówiąc „nie”.

Jeśli zrobisz to dobrze, zarządzanie interesariuszami nie będzie obciążeniem dla czasu EM. Jest to czynność o największym wpływie, jaką wykonują przez cały tydzień, ponieważ przepływa przez nią co drugi produkt inżynieryjny.

Cele sprintu, zmiany zakresu i aktualizacje interesariuszy – wszystko w jednym miejscu? SprintFlint śledzi cel, rejestruje każdą zmianę zakresu w stosunku do niego i automatycznie tworzy pisemne podsumowanie sprintu na końcu. Wypróbuj za darmo: 50 bezpłatnych zadań miesięcznie, bez karty.

Praca z interesariuszami spoza branży inżynieryjnej: podręcznik tłumacza menedżera inżynierii