“Tylko spokój nas uratuje”.
Wszystko musi być na wczoraj, wszystko jest ważne. Cały czas tłumaczysz sobie, czemu nie jest zrobione. Wciąż zadajesz sobie pytanie: Jak pracować przy trudnym projekcie? Nie zapominajmy również o codziennej eskalacji 🙂 Znasz to? Ja poznałam ostatnio bardziej niż kiedykolwiek. Czego mnie to nauczyło poza złotą myślą, którą Was uraczyłam we wstępie?
Checklisty i metodyczne podejście do pracy.
Ponieważ jestem megafanem checklist, będę przywoływać tę technikę za każdym razem, kiedy uważam, że ma sens. Każda aktywność, która w jakikolwiek sposób jest powtarzalna (choć niekoniecznie regularna), powinna być odzwierciedlona na checkliście. Po pierwsze dlatego, że pozwala się upewnić, że wszystko, co miało być zrobione, faktycznie jest wykonane. Po drugie dlatego, że uwalniacie dzięki temu swoją głowę od pamiętania o takich rzeczach.
Co dobrze jest umieścić na checkliście?
- Cykliczne zadania związane z zamykaniem / otwieraniem nowych etapów (sprintów)
- Cykliczne zadania związane z używanym narzędziem do zarządzania zadaniami i wymaganiami klienta (projektu, PMa) dotyczącymi jego utrzymania (odpowiednie tagi / labelki, komentarze, release versions itd.).
- Zadania związane ze specyfikacją wymagań (ja utrzymuję na projekcie przynajmniej elaboration checklist i specification checklist) i działaniami z tym związanymi – kiedy jakie akcje powinny być stworzone, kto kiedy akceptuje wymagania, jaka i kiedy tworzona jest dokumentacja, kiedy i kto estymuje zadanie, kto zatwierdza wymaganie jako gotowe do implementacji (DoR notki – Definition of Ready), a kiedy notkę można uznać za zaimplementowaną (DoD – Definition of Done)
Odpowiednia priorytetyzacja.
Gdy nie ma ustalonych priorytetów, to wszystko jest priorytetowe 🙂 I tu jest chyba największe wyzwanie ze strony klienta i PM’a – uzgodnić te priorytety. Ale, jeżeli nie jesteś w stanie wyegzekwować od klienta priorytetów, ustal, w porozumieniu z PM, Tech Leadem, Leadem testów, bądź każdą inną osobą, która może mieć wkład w tę aktywność, i ich się trzymajcie. Po eskalacjach (lub ich braku) poznacie, czy mieliście rację 😉
W praktyce warto kierować się zasadą – jak nie wiadomo o co chodzi, to chodzi o pieniądze. W pierwszej kolejności adresowane powinny być bugi, które wpływają na proces zakupowy u klienta. Ściślej rzecz biorąc te, które go utrudniają bądź uniemożliwiają. Możecie trafić na stakeholdera (bez władzy do podejmowania decyzji), który będzie mówił, że pasek, który jest zielony, a nie w kolorach marki, jest krytycznym bugiem. Nie jest. Brzydko wygląda – możliwe – ale najważniejsze jest to, że nie uniemożliwia zakupów.
W następnej kolejności polecam zająć się (w zależności od realnego problemu) wydajnością strony bądź nowymi funkcjonalnościami, które realnie wpłyną na zwiększenie dochodów (w tym wdrożenia na nowe rynki).
Natomiast priorytetyzowanie zadań całego zespołu to jedno – dobrze żebyście wiedzieli, jakie aktywności są najważniejsze dla Was. Jestem product ownerem. Zostałam zatrudniona do wsparcia zespołu w zakresie tworzenia wymagań. Wszystkie pytania i problemy zespołu dotyczące implementacji lub testów, wiedzy domenowej i innych tematów, które im utrudniają lub uniemożliwiają pracę, są absolutnie priorytetowe. W drugiej kolejności wszystko to, o co poprosi Cię PM – to też Twój zespół. Nawet jeżeli nie jesteście najbliższymi przyjaciółmi, ba, nawet jak się nie lubicie, to, jako product owner w projekcie, jestem najbliższym współpracownikiem Project Managera i beze mnie wielu tematów nie pociągnie. Będzie mu znacznie trudniej. Moim celem w pracy nie jest osiągnięcie spektakularnych osobistych rezultatów, ale przyłożenie się i pomoc zespołowi w osiągnięciu sukcesu. Więcej o temacie priorytetyzacji zadań w projekcie znajdziecie tutaj.
Delegowanie zadań i przejmowanie tych, które możemy.
W tak zwanych trudnych projektach bardzo często brakuje wszystkim czasu. Warto wtedy zastanowić się kto i jak może nam pomóc. Jak my możemy pomóc zespołowi w przypadku, gdy akurat mamy więcej przestrzeni, niż reszta zespołu.
Gdy brakuje nam czasu , warto zautomatyzować część zadań, w zależności od możliwości. Jeżeli do Ciebie należy dodanie odpowiednich labelek, a pracujesz z rozwiązaniem, które umożliwia tworzenie query, żeby wyłapać braki – lepiej spędzić pół godziny na napisaniu takiego query, niż ręcznie codziennie spędzać nad tym 5 minut. Jeśli w zakresie moich obowiązków jest m.in. weryfikowanie bugów, które przychodzą od klienta, to spokojnie można poprosić o pomoc testerów. Jeżeli te bugi są przypisywane od razu do developerów, a słyszysz że to strata czasu, bo większość jest niereprodukowana, a macie trochę czasu – weźcie to na siebie!
Jesteście częścią zespołu i celem nie jest zrobienie “swojego”, ale dowiezienie zadań jako zespół. Zdarzało mi się, że testerzy pisali za mnie kryteria akceptacji do notek. Nie wyrabiałam z czasem. Było też tak, że testowałam funkcjonalności, gdy oni walczyli z regresją przed releasem i mieli mniej czasu. Pisać kodu w .NET nie potrafię. Nie pomogę więc programistom i nie sądzę, żeby moje umiejętności HTML czy Pascala mogły się jeszcze gdziekolwiek przydać 😉
Jak pracować przy trudnym projekcie? Zachować spokój.
Stres nie jest dobrym doradcą. Gdy człowiek jest zdenerwowany, ma ograniczoną umiejętność podejmowania racjonalnych, przemyślanych i dobrych decyzji. Chcąc być skuteczną, to staram się odciąć od emocji związanych z nieprzyjemną rozmową, czy mailem. Zastanawiam się racjonalnie nad najlepszym rozwiązaniem. Wiem, że łatwiej powiedzieć niż zrobić, ale spróbujcie. Możecie iść na 5 minut (10? 15?) na spacer, żeby odetchnąć. Tylko nie chodźcie w kółko i nie mówcie do siebie, że to wszystko nie ma sensu, a klient jest głupi. Nie pomoże. Gwarantuję. Postarajcie się odciąć od emocji związanych z sytuacją, która wyprowadziła Was z równowagi i skupcie się na istocie problemu.
Klient nawrzeszczał, że zespół wypuścił krytycznego buga na produkcję, chociaż wiecie, że to nie wina waszego zespołu, tylko innego? Ok, co w takim razie możecie zaproponować z Waszej strony, aby pomóc klientowi uniknąć takiej sytuacji w przyszłości? Może brakuje testów regresji przed releasem na produkcję? A może wystarczy dodać tę funkcjonalność do już istniejących? A może można dodać testy automatyczne, które w przyszłości by to wychwyciły? Nie zrozumcie mnie źle – nie chodzi o to, żeby brać winę na siebie. Absolutnie nie! Chodzi o to, aby pomóc klientowi. Zapewne szybciej dojdziecie do właściwych rozwiązań danej sytuacji, gdy nauczycie się odrywać od emocji. Ludzie, z którymi będziecie pracować, są i będą różni – jedni mniej, inni bardziej emocjonalni. Ja również nie jestem Królową Lodu i mnie również czasem ponosi, ale chodzi o to, co z tym zrobicie później. Pamiętajcie – nikt nigdy nie doszedł do porozumienia w czasie kłótni.
Polecam również artykuł Hani z analizaIT “Test kamery, czyli fakty bez focha” który opisuje ciekawą technikę do zastosowania w stresowych sytuacjach.
Jak Wy radzicie sobie w takich projektach? Mieliście już taki? Uciekacie tak szybko, jak się da, czy lubicie tego typu wyzwania?
