Lepsza dokumentacja i komunikacja w zespole dzięki dokumentacji projektowej produktu

Typowy proces pracy projektanta produktu w firmie lub startupie może być ci znany: opracowywany jest nowy produkt, dla którego można dostarczyć rozwiązanie projektowe. Następnie pracujesz nad kilkoma propozycjami projektów i przedstawiasz je 1-3 osobom, aby zebrać opinie.

Czasami ten proces działa dobrze, ale czasami nie. Na przykład, niektórzy ludzie są zajęci zwracaniem uwagi na ukończenie własnych zadań i nie poświęcają wystarczająco dużo czasu, aby przekazać jasne i zwięzłe informacje zwrotne dotyczące propozycji projektu.

Może się również zdarzyć, że nawet jeśli Twój proces jest dobry, nadal chcesz go sformalizować, zapisując decyzje, śledząc iteracje i ogólnie proces projektowania, szczególnie w obecnych czasach, w których z powodu COVID19 pracujemy zdalnie.

Dokumentowanie procesu ma wiele zalet. Na przykład sprawia, że ​​Twoja praca jest bardziej widoczna, stwarza możliwości uzyskania informacji zwrotnych od wielu innych osób, poprawia ogólną komunikację i zapewnia jasny obraz tego, jak zaprojektowano funkcję z uwzględnieniem całego kontekstu i rozważań.

Upadek projektanta bohaterów

Około 2018 roku pracowałem jako zdalny projektant produktu z Madrytu w firmie działającej w Ameryce Łacińskiej, angażując w ten proces inne zespoły z Meksyku i Sao Paulo w Brazylii.

Zanim zacząłem pracować w tej firmie, miałem wiele różnych doświadczeń w mojej karierze, pracując w małych i dużych środowiskach z wielu różnych sektorów, takich jak media informacyjne, studia projektowe, sieć społecznościowa, mobilny system operacyjny, założyłem startup e-grocery , a nawet zagrali kilka niezależnych koncertów z innymi małymi start-upami.

Przez te wszystkie lata stosowałem to samo podejście, kilka osób siedziało w tym samym pomieszczeniu, przedstawiało swoje rozwiązanie, dostarczało ekrany, przepływy, zbierało informacje zwrotne i przedstawiało je ponownie. Po kilku iteracjach Twoja praca będzie gotowa do przejścia do fazy rozwoju.

Jednak to samo podejście przestało działać. Krótko po dołączeniu do zespołu zdałem sobie sprawę, że samo przedstawienie moich projektów podczas rozmowy wideo nie wystarczy. Tworzyłem wiele propozycji, ale nie mogłem uzyskać ostatecznej akceptacji moich interesariuszy i kolegów z zespołu. Byłem zdezorientowany i ciągle zadawałem sobie pytanie: co się dzieje? Czy nie zaprojektowałem najlepszego możliwego rozwiązania? Czy nie dostarczałem dobrej jakości pracy? Każde z tych pytań sprawiało, że traciłem wiarę w siebie. Problem polegał na tym, że musiałem dostosować swój proces do tego środowiska.

Jak tylko zdałem sobie sprawę, że mój proces nie działa, zacząłem czytać wiele artykułów o tym, jak pracować zdalnie jako projektant, o efekcie mewy (kiedy ktoś wchodzi do twojej pracy, surowo ją krytykuje, a potem odlatuje), jak inne firmy zbliżały się do współpracy zdalnej i jak sformalizowały swój proces, zapisując go. Po przeczytaniu całego tego materiału zastanawiałem się, jak programiści mieli do czynienia z tym samym problemem? Jak współpracują w środowiskach zdalnych w niemal asynchroniczny sposób? Jak dochodzą do ostatecznych porozumień? Odkryłem, że w rzeczywistości społeczność programistów ma już proces, który działa dla nich całkiem dobrze: nazywa się on pull requestami.

Żądania ściągnięcia pozwalają wprowadzać zmiany w większej bazie kodu, dokumentując je i weryfikując swoje decyzje na podstawie opinii innych osób. W ten sposób wprowadzane przez Ciebie zmiany idealnie łączą się ze wszystkimi standardami i połączeniami, które już ma kod. To jest dokładnie to, co chciałem osiągnąć, ale oczywiście w podejściu projektowo-modowym. Pozwól, że przedstawię Ci dokument dotyczący projektowania produktu.

Dokument projektu produktu

Dokument projektu produktu (PDD) to dokument, który przekształca problemy, które chcesz rozwiązać, kontekst i ostateczne rozwiązanie w podejście oparte na iteracji lub etapach.

Oznacza to, że możesz udokumentować cały proces projektowania w jednym dokumencie, który można udostępnić każdemu w Twojej firmie i który będzie stanowił bazę wiedzy dla podejmowanych decyzji dotyczących produktu. Brzmi fajnie, co? Zagłębmy się w szczegóły.

Ogólne koncepcje

PDD można opisać za pomocą 4 głównych pojęć: metadanych, kontekstu, etapów i informacji zwrotnej .

• Metadane to tylko przydatne informacje o dokumencie, takie jak tytuł, data, status i tak dalej.

  

• Kontekst jest tym, co inni ludzie muszą przeczytać, aby zrozumieć propozycje projektowe, które przedstawiasz, pomyśl o tym, jak opis, problem, streszczenie lub cele tego, co musisz osiągnąć.

• Etapy to różne iteracje Twojego projektu, zwykle zaczynające się od szerszego rozwiązania, a na każdym etapie skupiające się na bardziej szczegółowych szczegółach. Każdy etap opiera się na poprzednim i odnosi się do otrzymanej informacji zwrotnej. Jest to uporządkowany sposób dotarcia do końcowego punktu, w którym rozwiązane problemy nie mogą się ponownie pojawić.

• Informacja zwrotna odnosi się do wszystkich opinii, komentarzy, próśb i rekomendacji, które zbierasz od innych osób. Możesz zebrać informacje zwrotne od swoich interesariuszy lub członków zespołu.

Dzięki tym czterem koncepcjom możesz stworzyć różne warianty PDD, aby dopasować je do swoich potrzeb, każda firma/projekt jest inny i to, co zadziałało dla mnie, nie musi działać w ten sam sposób dla Ciebie. Ale jeśli omówisz te 4 główne koncepcje w swoim PDD, prawdopodobnie zadziała w prawie każdej sytuacji.

Przykładowa struktura

Po zrozumieniu głównych pojęć podzielę się z Wami strukturą, z której korzystałem w tej firmie. Posiada następujące sekcje:

• Tytuł powinien być zwięzły, jasny i łatwy do odróżnienia od innych tytułów PDD, które już posiadasz.
• Status wskazuje, na jakim etapie znajduje się obecnie Twój dokument:
• Wersja robocza
  Wciąż pracujemy nad zdefiniowaniem Kontekstu. Nie jesteś gotowy na opinie.
• S30, S60, S90
  Różne etapy (30%, 60%, 90%) Twojego rozwiązania (więcej szczegółów na temat etapów później).
• Kompletny
  Wszystkie opinie zostały uwzględnione i nie ma brakujących punktów. PDD jest zakończone.
• Streszczenie to opis problemu, dla którego musisz zaprojektować, zwykle połączony z innymi pomocnymi, powiązanymi lekturami, które możesz mieć.
• Cele są kluczowymi punktami, na których Twoje rozwiązanie musi się skoncentrować. Jest to lista kontrolna, którą będziesz stale sprawdzać, aby upewnić się, że jesteś na dobrej drodze.
• S30 (lub Stage 30% ) to pierwsza propozycja, którą przedstawiasz w oparciu o abstrakt i cele, skupiając się na szerszym rozwiązaniu zamiast na szczegółach, być może poprzez dostarczenie szkieletu o niskiej wierności lub podobnej techniki. Jest to etap, na którym proponowane rozwiązanie może przyjąć zupełnie inne podejście i oczekuje się, że pojawią się znaczące informacje zwrotne.
• S60 (lub Stage 60% ) to twoje rozwiązanie o 60% kompletności i stosuje informację zwrotną z S30. Ma mniej szczegółów niż S90, ale wyraźnie wskazuje intencję Twojego rozwiązania. Dostarczasz model szkieletowy o wysokiej wierności z większą liczbą zaangażowanych przypadków i kilkoma definicjami przepływu. Możesz otrzymać jakąś informację zwrotną skupiającą się głównie na pominiętych przypadkach i małych nieoczekiwanych scenariuszach.
• S90 (lub Stage 90% ) to etap, który ma rozwiązanie w 90% kompletności i stosuje informację zwrotną z S60. Ten etap koncentruje się na najdrobniejszych szczegółach Twojego projektu, w tym wszystkich różnych scenariuszach, narożnych przypadkach, projekcie wizualnym, a nawet prototypach. Oczekuje się, że będzie mieć jakąś drobną informację zwrotną.

Możesz zadać sobie pytanie, czy muszę przestrzegać tej samej kolejności i konwencji nazewnictwa etapów? Cóż, nie, nie. Możesz zmienić nazwę sceny z S30, S60 i S90 na: Eksploracja, Propozycja, Rozwiązanie.

Możesz także zmienić kolejność, aby najbardziej dopracowana praca (S90, Rozwiązanie) znalazła się na górze dokumentu, a przepływ czytania przeszedł z ostatniego etapu do wczesnego (S30, Exploration).

Szablony

Zacznij szybko od jednego z dostarczonych szablonów dla najpopularniejszych platform do pisania. Pamiętaj: konwencje nazewnictwa sekcji są całkowicie konfigurowalne. Jeśli nie lubisz Streszczenie , po prostu użyj Brief , About lub czegokolwiek, co odpowiada Twoim potrzebom. Główną koncepcją, którą musisz zachować, jest tworzenie różnych iteracji, aby skupić się na każdym etapie. Możesz po prostu zmienić nazwę S30 na eksplorację, S60 na propozycję, a S90 na rozwiązanie.

• Papier
• Pojęcie
• Dokumenty Google
• Przykład z życia

Kluczowe zalety korzystania z PDD

1. Każda decyzja jest dokumentowana.
   Oznacza to, że nawet gdy opuścisz firmę/projekt (a stanie się to prędzej czy później), cała wiedza generowana wokół pozostanie w firmie na zawsze, aby inni ludzie mogli na nią patrzeć i iterować od miejsca, w którym wyszedłeś.

2. Poprawia komunikację.
   Pozyskiwanie opinii różnych osób z Twojego zespołu w PDD pomaga wszystkim pozostać na tej samej stronie i być świadomym podejmowanych decyzji.

3. Ogranicza niekończące się zmiany ze strony interesariuszy.
   Każdy etap skupia się na innym kącie problemu, przechodząc od szerszych rozwiązań do wąskich. Pozwala to ludziom skoncentrować się na jednym problemie na raz, pomagając im na końcowych etapach.

4. Produkt jest tworzony wspólnie.
   Zamiast interesariuszy definiujących konkretne rozwiązania, pozwalamy zespołom inżynieryjnym, projektowym i innym zaangażować się w rozwiązanie, czyniąc je jego częścią.

Uwagi końcowe

Kończąc opowieść o tej zdalnej firmie, pracowałem tam przez kilka miesięcy i udało mi się zaimplementować Product Design Docs przynajmniej w 5 różnych projektach. Moja frustracja znacznie się zmniejszyła i udało mi się osiągnąć konsensus w sprawie moich propozycji projektowych, dzięki czemu produkt nadal ewoluował. Od tego czasu firma bardzo się rozwinęła i część pracy, którą wykonałem w swoim czasie, jest nadal wykorzystywana.

PS: Zacząłem pisać ten artykuł w 2019 roku, potem w 2021 zobaczyłem, że Abstract tworzy produkt do dokumentowania procesu projektowego, więc postanowiłem wrócić na właściwe tory i go dokończyć. Wygląda na to, że to wciąż całkiem aktualny temat.

Bibliografia

• Jak prowadzić ćwiczenia projektowe w zdalnym zespole autorstwa Hannah Hearth
• Unikaj efektu mewy: ramy opinii 30/60/90 autorstwa Lauren Moon
• Jak zaprojektować dokument projektowy? przez Johna Saito
• Moc dokumentu projektowego autorstwa Brendana Fagana
• Przedstawiamy notebooki autorstwa Matta Colyera