Robić rzeczy właściwie (z Michaelem Luchenem z Crema)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Ben Aston:

To frustrujące, gdy rzeczy nie działają, a my spędzamy tygodnie lub miesiące na tworzeniu projektu, tylko po to, by na końcowym etapie testów akceptacyjnych użytkownika zawieść się z powodu podstępnego błędu. Dlaczego wydaje się, że prawie zawsze tak się dzieje i czy możemy coś z tym zrobić? Jeśli więc błędy dają ci się we znaki, słuchaj dalej, ponieważ w dzisiejszym podcaście porozmawiamy o tym, jak robić rzeczy właściwie dzięki udoskonalonemu produktowi i procesowi oraz magii planu zarządzania jakością.

Dziękuję, że nas słuchacie. Nazywam się Ben Aston i jestem założycielem Project Managers. Witajcie w podcaście DPM. Naszą misją jest pomaganie kierownikom projektów w osiąganiu sukcesów oraz osobom zarządzającym projektami w dostarczaniu lepszych rezultatów. Pomagamy przenieść zarządzanie projektami na wyższy poziom. Odwiedź stronę thedigitalprojectmanager.com, aby dowiedzieć się więcej o naszych szkoleniach i zasobach dostępnych w ramach członkostwa. Ten podcast powstał dzięki firmie Clarizen, liderowi w dziedzinie oprogramowania do zarządzania projektami i portfelami projektów w przedsiębiorstwach. Odwiedź stronę clarizen.com, aby dowiedzieć się więcej.

Dziś moim gościem jest Michael Luchen, jeden z naszych stałych ekspertów DPM. Jest trenerem produktów w firmie Crema, agencji produktów cyfrowych tworzącej aplikacje internetowe i mobilne dla innowacyjnych firm oraz liderów branży. Zwykle pracuje zdalnie z Waszyngtonu i pomaga zespołom usprawniać współpracę, analizować złożone problemy i je rozwiązywać. Pracował między innymi z firmami Adidas i Callaway Golf, a także jest trenerem w Crema. Porozmawiamy dziś o tworzeniu planu zarządzania jakością. Witaj w programie, Michael.

Michael Luchen:

Cześć, Ben. Jak leci?

Ben Aston:

Dobrze, dzięki. Jestem ciekaw, bo przez lata, podczas naszych rozmów i nagrywania podcastów, twoja rola ewoluowała. Interesuje mnie twoja obecna funkcja trenera, która jest chyba nowym stanowiskiem. Możesz opowiedzieć nam, czym jest trener? Kim jest trener produktu i co oznacza ta funkcja w firmie Crema?

Michael Luchen:

Jak wspomniałeś, jest to efekt około siedmiu lat praktycznego doświadczenia w zarządzaniu projektami i produktami. Szczerze mówiąc, ta rola dopiero się kształtuje. Próbujemy ustalić, czym dokładnie jest funkcja trenera w firmie Crema. Obecnie podchodzimy do niej jako do roli przywódcy służebnego, który pomaga klientom zrozumieć praktyki zwinne i stawać się lepszymi wersjami samych siebie. Zwykle pełnię funkcję moderatora, stratega produktu i projektanta myślącego, pomagając klientom na nowo zdefiniować problemy i identyfikować innowacyjne podejścia. Najciekawsze w tej nowej roli i przedsięwzięciu Crema jest to, że próbujemy wyróżnić się na zatłoczonym rynku, podchodząc do tematu z wyjątkowej, niepreskryptywnej perspektywy. Istnieje wiele nakazowych procesów coachingowych, a my chcemy działać inaczej.

Ben Aston:

Czyli w tej roli pracujesz z małym zespołem bezpośrednio z klientem. Czy jest to bardziej rola strategiczna niż wtedy, gdy próbujesz zdefiniować mapę drogową projektu lub produktu?

Michael Luchen:

Tak, jest podobnie do tego, o czym wspomniałeś. Zakres jest nieco szerszy, a nacisk kładziemy bardziej na ludzi. Jedną z rzeczy, które najbardziej lubię w zarządzaniu projektami, jest możliwość skupienia się na tworzeniu zdrowego środowiska dla zespołów, aby mogły wykonywać swoją najlepszą pracę. Ta rola polega na rozwijaniu tego podejścia i pomaganiu klientom w zdobyciu narzędzi oraz sposobu myślenia potrzebnych do stworzenia zdrowej, produktywnej kultury i środowiska pracy, które pozwolą zespołom osiągać naprawdę świetne rezultaty.

Ben Aston:

Z jakimi wyzwaniami spotykasz się, pomagając klientom zmienić sposób myślenia o dostarczaniu rezultatów?

Michael Luchen:

Pojawia się wiele wyzwań, ale sądzę, że najważniejsze jest to, iż rezultaty nie zawsze będą natychmiastowe. Nie mogę po prostu przyjść i powiedzieć: „Zróbcie to, a wszystko będzie lepiej”. Oczywiście istnieje wiele takich podejść: poznajcie określony model, a wasz zespół odniesie sukces. Ważne jest jednak uwzględnienie pełnego kontekstu kultury organizacji oraz zrozumienie, że wzmacnianie liderów, z którymi pracujesz, wymaga czasu na eksperymentowanie i ustalenie, jak zastosować zdobytą wiedzę.

Ben Aston:

Zdecydowanie. Nie ma jednego procesu, który można zastosować i który będzie idealnie pasował do każdej organizacji czy agencji. Samo wykonanie określonych kroków nie przyniesie nagle magicznych rezultatów. Nie istnieje magiczne rozwiązanie ani srebrna kula, która natychmiast naprawi wszystkie problemy. Czasem ludzie myślą: „Zwinność jest srebrną kulą”, a wtedy trzeba doprecyzować, co to właściwie oznacza. Brzmi to jak interesująca rola. Wykonujesz ją głównie zdalnie czy pracujesz z klientami na miejscu?

Michael Luchen:

Zdecydowanie łączę oba podejścia. W chwili, gdy to nagrywamy, pracuję w 100% zdalnie. Uważam jednak, że relacje można budować osobiście, dlatego jeśli jest taka możliwość, warto rozpocząć współpracę coachingową na miejscu. Odkryłem jednak, że można prowadzić bardzo produktywne i wartościowe rozmowy podczas spotkań na Zoomie albo korzystając z nagrań Loom i udostępniania ekranu, aby przekazywać wskazówki, odpowiadać na pytania lub współpracować na tablicach Mural. Można to skutecznie robić na oba sposoby.

Ben Aston:

Rozmawiamy o pracy zdalnej. Jesteśmy oczywiście w środku kwarantanny związanej z koronawirusem, a ty niedawno poprowadziłeś dla nas warsztat dotyczący pracy zdalnej. Dla osób, które go przegapiły, albo nawet teraz, gdy wszyscy są zmuszeni pracować zdalnie, jaka jest najbardziej skuteczna wskazówka lub technika, która pomaga ci nie zwariować podczas pracy samemu? Jak radzisz sobie z poczuciem izolacji?

Michael Luchen:

To bardzo dobre i aktualne pytanie. Staram się pamiętać, że współpracuję i pracuję z innymi ludźmi, dlatego rozmowy wideo na Zoomie, tak często jak to możliwe, są niezwykle cenne. Brzmi to prosto, szczególnie teraz, gdy Zoom jest jedną z najczęściej pobieranych bezpłatnych aplikacji, ale ważne jest świadome podejście do tych rozmów z perspektywy współpracy. Możemy po prostu połączyć się z zespołem na Zoomie i omówić sprawy. Możliwość obserwowania komunikacji niewerbalnej jest bardzo cenna, zwłaszcza dla kierownika projektu. Czasem korzystam nawet z drugiego monitora, gdy udostępniam ekran, aby nadal widzieć twarze wszystkich uczestników.

Ben Aston:

To dobra rada. Zoom jest świetnym narzędziem, ale gdy mamy też Slacka, łatwo ulec pokusie i zacząć wszystko wpisywać na czacie, zapominając, że tracimy dużą część komunikacji oraz możliwość budowania relacji. Rozmowa wygląda inaczej podczas spotkania na Zoomie, więc warto się ubrać i również porozmawiać przez Zoom. Zdecydowanie przynosi to korzyści.

Skoro mówisz o coachingu i pracy zarówno zdalnej, jak i osobistej, możesz opowiedzieć o projektach, nad którymi obecnie pracujesz?

Michael Luchen:

Obecnie całkowicie przechodzę z zarządzania produktem do roli trenera. Kończę duży, wieloletni projekt rozwojowy dla przedsiębiorstwa. Ciekawe jest podejście do niego z nastawieniem coachingowym, ponieważ istnieje wiele punktów styku, gdy coaching zostaje sprowadzony do poziomu praktyków. Poza tym skupiam się teraz na rozwinięciu usług coachingowych i określeniu kluczowego wyróżnika, dzięki któremu Crema może realnie pomóc klientom oraz służyć im z pokorną pewnością siebie.

Ben Aston:

Jakie problemy klientów identyfikujesz jako potencjalne obszary, w których twoja nowa rola może pomóc?

Michael Luchen:

Mam ciekawą metaforę, która opisuje nasze podejście: traktujemy coaching podobnie jak semestr na uczelni. Wynika to z mojego przekonania, że skuteczny coaching opiera się na eksperymentowaniu i na tym, aby osoby, które szkolę, same eksperymentowały i uczyły się. Moja rola polega głównie na byciu moderatorem, przewodnikiem i mentorem z doświadczeniem praktycznym.

Obejmuje to regularne spotkania kontrolne, retrospektywy, obserwacje i wspólne notatki, na przykład sugestie: „Może warto to sprawdzić” albo „Spróbuj tego na następnym spotkaniu”. Chodzi o stworzenie rytmu, dzięki któremu po kilku tygodniach lub miesiącach możemy spojrzeć wstecz i powiedzieć: „Rzeczywiście, nastąpiła wyraźna poprawa. Nasz zespół potrafi teraz wytwarzać więcej”.

Ben Aston:

Jak pomagasz organizacjom ustalać priorytety, gdy identyfikujesz obszary, które mogą stać się bardziej zwinne? W dużej organizacji istnieje wiele różnych procesów. Jak pomagasz klientom określić, które elementy procesu lub dostarczania rezultatów są dobrym punktem wyjścia do bardziej zwinnego podejścia?

Michael Luchen:

Myślę, że zaczyna się od ankiety i rozmowy. Ankieta nie musi dotyczyć tylko jednej osoby kontaktowej po stronie klienta. Można objąć nią kierowników projektów, programistów i inne osoby zaangażowane lub zainteresowane procesem. Najpierw ustalamy, jakie są ich wyobrażenia o tym, co najważniejsze do rozwiązania. Następnie mój zespół analizuje ankietę i porównuje ją z tym, co usłyszeliśmy między wierszami. Dzięki temu możemy zarekomendować: „Skupmy się teraz na tych dwóch lub trzech obszarach, ponieważ przyniosą bardzo dobre rezultaty”.

Ben Aston:

Brzmi rozsądnie. Powodzenia.

Michael Luchen:

Dziękuję.

Ben Aston:

Chcę wrócić do twojego artykułu i tematu, od którego zaczęliśmy — zarządzania jakością. Jeśli jeszcze go nie czytaliście, znajdziecie go na stronie thedigitalprojectmanager.com. Nosi tytuł „Jak opracować plan zarządzania jakością”. Michael przedstawia w nim bardzo dokładny, krok po kroku opis tworzenia planu jakości. Członkowie mogą również uzyskać dostęp do listy docelowych urządzeń i wymagań dotyczących jakości oraz szablonu planu zarządzania jakością, aby łatwo wdrożyć wszystko w praktyce.

Nie będziemy tutaj szczegółowo omawiać procesu tworzenia planu, ponieważ opisano go w artykule. W skrócie Michael wyjaśnia, jak stworzyć plan jakości dla projektu lub produktu. Chcę jednak zacząć od samego pojęcia jakości. W procesie tworzenia planu zaczynasz od zbudowania wspólnego rozumienia tego, czym jakość jest dla projektu. Dlaczego tak trudno ją jednoznacznie określić?

Michael Luchen:

Na początek warto rozdzielić jakość na dwa elementy: jakość produktu i jakość procesu. Jakość produktu to jakość rzeczywistego produktu fizycznego lub cyfrowego. Obejmuje wszystkie rezultaty pracy zespołu projektowego, programistycznego i innych zespołów. Jakość procesu to obszar, na który jako kierownicy projektów mamy duży wpływ. Dotyczy procesu, który tworzymy, a który z kolei wpływa na zdolność zespołu do osiągania rezultatów. Przykładowym wskaźnikiem, który wszyscy znamy, jest prędkość zespołu, pomagająca ocenić przebieg procesu.

Wspólne zrozumienie jakości jest trudne, ponieważ w grę wchodzi wiele subiektywnych ocen i emocji. Mamy różnych interesariuszy, w tym własny zespół programistów i projektantów, którzy podchodzą do tematu z odmiennych perspektyw i z różnych powodów. Klient może oczekiwać określonego poziomu jakości spełniającego wymagania, podczas gdy programista może przywiązywać szczególną wagę do jakości kodu i chcieć napisać kod idealny. Musimy więc pomagać zespołowi znaleźć równowagę.

Ben Aston:

Porozmawiajmy o tej równowadze. W podejściu zwinnym mamy kryteria akceptacji dla historyjki użytkownika, które definiują jej zakres i warunki ukończenia. Mamy też definicję ukończenia, czyli zestaw zasad obowiązujących wszystkie historyjki. Z jednej strony chcemy dostarczać wartość iteracyjnie, a z drugiej jakość może wydawać się sprzeczna z szybkim dostarczaniem. Co jest ważniejsze: spełnienie kryteriów akceptacji i definicji ukończenia, dostarczanie wartości czy jedno i drugie, nawet jeśli oznacza to wolniejsze tempo?

Michael Luchen:

To bardzo dobre pytanie. Uważam, że skupienie na jakości nie stoi w sprzeczności ze zwinnością. W rzeczywistości przyspiesza pracę zespołów i umożliwia stosowanie praktyk zwinnych. Jeśli na początku projektu zdefiniujemy wraz z zespołem, czym jakość jest, a czym nie jest, pomoże to skoncentrować uwagę podczas tworzenia i dostarczania pracy. Jasno określimy, co należy uznać, a czego nie należy uznawać za spełnione.

Kryteria akceptacji również wspierają zwinność, jeśli spojrzymy na nie z właściwej perspektywy. Załóżmy, że zespół pracuje nad historyjką użytkownika w ramach sprintu i ma już określone kryteria akceptacji. Podczas pracy programiści napotykają przeszkodę lub wyzwanie techniczne, które zmienia część kryteriów akceptacji. To otwiera świetną dyskusję. Nie musimy zwalniać i wracać do starego sposobu pracy. Możemy zatrzymać się jako zespół, szybko omówić sytuację i zaktualizować kryteria akceptacji. W tym przykładzie służą one zapewnieniu jakości.

Ben Aston:

Chodzi więc o zmianę sposobu myślenia o jakości. Jakość nie jest czymś sprzecznym z szybkim dostarczaniem wartości. Jest ważnym składnikiem wartości. Jeśli coś ma wartość, ale nie spełnia ustalonych kryteriów jakości, może dostarczać mniej wartości, niż powinno. Warto więc postrzegać jakość jako element wartości, którą tworzymy.

Michael Luchen:

Dokładnie.

Ben Aston:

W swoim podejściu mówisz o podziale odpowiedzialności za zarządzanie jakością. Większe agencje i organizacje często mają wyspecjalizowane zespoły kontroli jakości, ale czasem zadanie to trafia do kierownika projektu lub programistów. Wspominasz o potrzebie utworzenia stanowiska inżyniera testów. Dlaczego jest ono tak ważne?

Michael Luchen:

W początkowych latach pracy jako kierownik projektu sam zajmowałem się kontrolą jakości. Teraz, gdy współpracuję z inżynierami testów, widzę ogromną różnicę. Ta rola jest ważna, ponieważ wymaga wyćwiczonego, krytycznego spojrzenia na jakość. Inżynier testów może być najlepszym partnerem kierownika projektu, ponieważ analizuje szczegóły zarówno tego, co jest tworzone i dostarczane, jak i szerszy wpływ rozwiązania na użytkowników.

Skupia się na technicznych szczegółach, ale patrzy również na szerszy obraz: na rozwój produktu oraz sposób, w jaki trafia on do użytkowników. Gdy pozwolimy inżynierowi testów aktywnie uczestniczyć w tym procesie, staje się on kluczowym członkiem zespołu, który zwielokrotnia wartość pracy programistów, projektantów i kierownika projektu.

Ben Aston:

Z mojego doświadczenia wynika, że sposób myślenia inżyniera testów lub analityka kontroli jakości znacznie różni się od podejścia kierownika projektu. Kierownik projektu często myśli o optymalnej ścieżce i podczas testowania wykonuje dokładnie to, co zaplanowano. Inżynier testów ma natomiast doświadczenie w psuciu rzeczy i analizowaniu doświadczeń klienta poprzez testy eksploracyjne. Szuka sposobów, w jakie idealna ścieżka może zawieść. Zapewnia to większą rzetelność i dokładność oraz podnosi jakość produktu końcowego, ponieważ zawsze będą w nim błędy.

W artykule mówisz też o określeniu docelowych urządzeń. To bywa bardzo trudne, szczególnie gdy klient chce, aby produkt działał na wszystkich urządzeniach — obecnych, przeszłych i przyszłych. Jak pomagasz klientom zarządzać takimi oczekiwaniami?

Michael Luchen:

Określanie docelowych urządzeń to jedno z moich ulubionych ćwiczeń. Pomaga nie tylko zawęzić zakres jakości i ustalić, gdzie zespół powinien zainwestować wysiłek, ale także doprecyzować rezultaty, które chcemy stworzyć dla użytkowników. Gdy klient chce obsługiwać każde urządzenie i każdy system operacyjny, możemy zacząć zadawać pytania o użytkowników i ich rzeczywiste potrzeby.

Czasem rozmowy o obsłudze starych przeglądarek prowadzą do ważnych dyskusji o wartości dla użytkowników. Docelowe urządzenia pozwalają zespołowi i klientowi skoncentrować się na użytkowniku, ustalić priorytety oraz ocenić czas potrzebny do osiągnięcia tych priorytetów.

Ben Aston:

To dobra rada. Osoby tworzące opis zakresu prac lub definiujące kryteria akceptacji powinny bardzo uważać przy określaniu obsługiwanych urządzeń. Nie wystarczy napisać, że produkt będzie działał na wszystkich urządzeniach mobilnych i komputerach teraz i zawsze. Produkt może nie działać w starych przeglądarkach, a wraz z rozwojem przeglądarek mogą pojawić się nowe problemy. Dlatego należy z góry zdefiniować zakres odpowiedzialności i ustalić, kto ponosi koszty, gdy coś, co wcześniej działało, przestaje działać.

Warto dokładnie określić docelowe urządzenia, ponieważ ich brak może później bardzo boleśnie się zemścić.

Porozmawiajmy o przypadkach testowych. Wchodzimy teraz w szczegóły. Wiele osób zna programowanie sterowane testami, ale istnieje też testowanie na bieżąco i dokumentowanie wyników. Czy potrzebujemy planu testów? Jak zarządzać tym procesem? Jakie jest twoje zdanie na temat programowania sterowanego testami i jego wpływu na wartość? Czy inżynierowie testów testują na bieżąco i dokumentują pracę, czy stosujecie dokładny plan testów?

Michael Luchen:

W firmie Crema nasi inżynierowie testów pomogli zbudować przekonanie, że jakość jest obowiązkiem wszystkich. Programiści stosują programowanie sterowane testami i dbają o to, aby testy integracyjne były częścią kodu komponentów, które tego wymagają. Dzięki temu, gdy funkcja trafia do inżyniera testów, może on skupić się na testach manualnych z perspektywy użytkownika, pisaniu testów automatycznych, eksplorowaniu przypadków brzegowych i innych działaniach.

Ben Aston:

Mówisz o odpowiedzialności wszystkich, ale problem polega na tym, że gdy wszyscy są odpowiedzialni, czasem nie jest odpowiedzialny nikt. Jak zachęcacie do traktowania jakości jako wartości w organizacji? Jak wygląda to w praktyce?

Michael Luchen:

Zaczynamy od edukacji i tworzenia podstaw. Mamy kanały na Slacku, w których rozmawiamy o jakości, oraz stale dyskutujemy o tym, czym jakość jest dla naszych projektów. Z praktycznej perspektywy kierownicy projektów mogą pomóc, tworząc procesy umożliwiające przeprowadzanie kontroli jakości na kolejnych etapach. Jakość staje się wówczas częścią procesu. Korzystamy na przykład z JIRA, a jej przepływy pracy pozwalają ustawić kontrole przeglądu kodu. Gdy element przechodzi ze stanu „w trakcie” do środowiska testowego, przechodzi przez przegląd kodu. Następnie, gdy trafia ze środowiska testowego do kontroli jakości, uruchamiamy kolejny proces, aby zapewnić odpowiedni czas i zakres testów.

Ben Aston:

Czyli jakość jest zintegrowana z samym procesem, a nie traktowana jako coś, co pojawia się dopiero po ukończeniu komponentu. Częścią tworzenia komponentu jest jego przetestowanie. Wspomniałeś o testach jednostkowych pisanych podczas tworzenia kodu. Jak równoważycie testy manualne i automatyczne? Testy automatyczne wymagają dużo czasu na przygotowanie, więc kiedy warto je tworzyć?

Michael Luchen:

Testy manualne są bardzo wartościowe i stanowią łatwo dostępny punkt wyjścia. Są szczególnie przydatne, gdy doświadczenie użytkownika jest złożone lub gdy przygotowanie testów automatycznych wymagałoby zbyt dużego wysiłku. Przykładem może być interakcja typu przeciągnij i upuść w aplikacji.

Testy automatyczne są natomiast świetne w przypadku czynności wykonywanych wielokrotnie. Dobrym przykładem są długie, złożone formularze informacyjne. Dodatkowe uznanie należy się inżynierowi testów, który potrafi przygotować kryteria automatycznego wypełniania zawierające wszystkie dziwne znaki, które nasze aplikacje tak często muszą obsługiwać.

Ben Aston:

Twoje podejście do planu zarządzania jakością polega więc na tym, aby robić rzeczy właściwie jako część zintegrowanego procesu rozwoju, a jednocześnie unikać jednego uniwersalnego podejścia. Proces należy dopasować do projektu i komponentów. Jak nabierasz pewności, że wybraliście właściwą drogę w ramach organicznego procesu?

Michael Luchen:

Jestem wielkim zwolennikiem procesu organicznego. Tak jak określamy prędkość zespołu na podstawie kilku sprintów, aby zwiększyć szanse na sukces w dalszej części projektu, tak samo patrzę na jakość. Na początku projektu mamy pierwsze przybliżenie. Artykuł o tworzeniu planu zarządzania jakością przedstawia solidne ramy, które pozwalają rozpocząć pracę z dobrymi podstawami.

To jednak zawsze tylko założenie. Jeśli zespół nie pracował wcześniej razem, w pierwszych sprintach lub tygodniach pojawią się rzeczy, które będą się naturalnie zmieniać. Trzeba być otwartym na takie zmiany, ale nie powinny one być gwałtowne. Możemy na przykład odkryć, że jedno z docelowych urządzeń nie jest używane przez żadnego użytkownika. Wtedy musimy mieć możliwość zaktualizowania listy urządzeń, aby przeznaczyć więcej czasu i energii na inne obszary.

Warto wykorzystać to doświadczenie przy rozpoczynaniu kolejnego projektu, jednocześnie uwzględniając specyfikę nowego zespołu.

Ben Aston:

Zdrowy rozsądek odgrywa ogromną rolę w zarządzaniu jakością. Czasem można przesadzić i uznać, że jakość jest najważniejsza, a następnie stworzyć bardzo sztywny plan z licznymi kontrolami. Wtedy plan staje się podobny do dokumentacji tworzonej wyłącznie dla samej dokumentacji. Trzeba znaleźć równowagę: mieć kontrole i plan, ale jednocześnie stosować zdrowy rozsądek i dostosowywać się w trakcie pracy. To ponownie prowadzi nas do podejścia zwinnego. Nie należy podchodzić do planu zarządzania jakością dogmatycznie, lecz pozostawić miejsce na luźniejsze, eksploracyjne testowanie, aby zapewnić dostarczanie wartości w sposób przyrostowy.

Michael Luchen:

Dokładnie.

Ben Aston:

Niedawno uruchomiliśmy na naszej siostrzanej stronie podcast o nazwie QA Lead. Jeśli interesuje cię kontrola jakości i pracujesz z inżynierami testów, poleć im stronę QA Lead. Jako kierownik projektu zajrzyj też do artykułu, który zawiera szczegółowe informacje, przykład i szablony udostępniane członkom.

Jeśli nie korzystasz jeszcze z planu zarządzania jakością, sprawdź go. Pomoże ci przeanalizować proces, projekt lub produkty, nad którymi pracujesz, oraz zastanowić się, jak dostarczać większą wartość dzięki lepszej jakości produktu.

Wszystkie te wskazówki były bardzo cenne, ale szczególnie przemówiła do mnie idea, że podejście do jakości trzeba kształtować w całej organizacji. Niezależnie od tego, czy mamy inżynierów testów, każdy powinien myśleć o jakości nie tylko w kategoriach tego, czy coś jest zepsute, lecz także jako o odzwierciedleniu naszego procesu. Należy analizować całą organizację, sprawdzać, czy rzeczy działają, i szukać sposobów na ich ulepszanie w sposób iteracyjny. Michael, bardzo dziękuję za twoje spostrzeżenia.

Michael Luchen:

Dziękuję.

Ben Aston:

A jakie są wasze sposoby, wskazówki i triki na dostarczanie wysokiej jakości projektów lub produktów? Opowiedzcie nam, co działa, a co nie. Jeśli macie historie porażek lub sukcesów, którymi chcecie się podzielić, napiszcie o nich w komentarzach poniżej.

Jeśli chcecie dowiedzieć się więcej i rozwijać swoją karierę, dołączcie do naszej społeczności w ramach członkostwa DPM. Odwiedźcie stronę thedigitalprojectmanager.com/membership, aby uzyskać dostęp do naszego zespołu na Slacku, szablonów, warsztatów, konsultacji, e-booków i wielu innych materiałów. Jeśli podobało wam się to, czego dziś słuchaliście, zasubskrybujcie podcast i pozostańcie z nami na stronie thedigitalprojectmanager.com. Do usłyszenia następnym razem i dziękuję za uwagę.