Nazwa ma znaczenie. Dziś pastwię się nad niedbałymi nazwami statusów.

Zamówienia, zgłoszenia, dokumenty w obiegu. Nowe, do zatwierdzenia, zatwierdzone, anulowane, wycofane. Łatwo się pogubić, kiedy nie uporządkujesz stanów, w jakich może być dany obiekt. Przydałoby się też wiedzieć, które przejścia między stanami są dozwolone. Czy można ponownie otwierać anulowany dokument? Czy można cofnąć zamówienie zatwierdzone do realizacji?

Z pewnością diagram stanów uporządkuje Twoją wiedzę, zrozumienie złożonego zachowania obiektu i przedstawi aktualne ustalenia całemu zespołowi – każdemu tak samo.

Kiedy siadasz do tworzenia diagramu, w Twójej głowie rozpoczyna się burza ☺ Przypominasz sobie wszystkie możliwe stany, szukasz informacji w dostępnych źródłach, sprawdzasz w systemie. Chodzi o to, żeby zebrać je wszystkie. Nie myślisz wtedy za bardzo nad nazwami. Piszesz pewnie pierwszą, która wpadnie Ci do głowy. Niestety zdarza się, że już nigdy nie wrócisz do tego, by zadać sobie pytanie „jak najlepiej nazwać ten stan?”.

W czym problem?

Pomyśl o przepływach, z którymi spotykasz się na co dzień. Zadania, incydenty, delegacje, wnioski, zamówienia. Czy w momencie, kiedy patrzysz na status, wiesz dokładnie co się dzieje i co wydarzy się w następnym kroku? A może potrzebujesz ściągi? Niektóre obiegi są skomplikowane a nazwy stanów dodatkowo utrudniają sprawę. Za każdym razem musisz otworzyć swoją ściągę, odnaleźć właściwe miejsce, zastanowić się czy teraz to Ty coś musisz zrobić czy czekasz na reakcję innych? 

Mam jeden taki proces, który przechodzę często, ale ciągle nie mogę się nauczyć co dalej i kto co powinien dalej zrobić.

Może w końcu zapamiętasz co znaczy każda nazwa. Jednak ile zajmie Ci to czasu? Ile czasu na podobne sprawdzanie stracą Twoi koledzy? A, co gorsza, ile czasu będą tracić Twoi klienci, użytkownicy systemu, który zaprojektowałeś?

I znowu dochodzimy do efektu skali – jeśli 100 pracowników poświęci na to sprawdzenie 3 minuty w tygodniu, to firma jest w plecy 5 osobo-godzin tygodniowo. 20 godzin w miesiącu. 24 dni w roku!

Jakie nazwy stanów dręczą ludzi? Takie, które nie odpowiadają na pytanie co się teraz dzieje z tym obiektem i co ma się z nim stać w następnej kolejności. Przykład: zatwierdzone, zgłoszone. I co teraz? I co dalej? Mam coś zrobić? Ktoś inny ma coś zrobić?

Jakie nazwy są dobre? Takie, które odpowiadają na pytanie, co się z danym obiektem dzieje lub jaki jest następny krok. Przykład: do weryfikacji klienta, do rozliczenia księgowego, towar wysłany. Patrząc na takie nazwy statusów od razu wiesz co się dzieje i co będzie dalej.

Łatwiej też wyobrazić sobie co znaczy dany stan, jeśli jest związany z fizycznym działaniem powszechnie znanym, który każdy może sobie wyobrazić, jak zamówienie pakowane, zamówienie wysyłane. Uważaj w szczególności na abstrakcyjne czynności jak akceptacja, zatwierdzanie, wstępna weryfikacja. Świetnie, gdybyś przetestował te nazwy zadając kontrolne pytania kolegom z zespołu, klientom, użytkownikom. Np. co się dzieje, kiedy jesteś w stanie X? Co zrobisz dalej? Kto następny powinien się zająć zgłoszeniem?

Do opisu stanów koniecznie dołączaj ściągę w postaci diagramu stanów najlepiej z wyjaśnieniem co dany stan oznacza i jaka czynność, warunek, jaka osoba może spowodować zmianę stanu. Takie wyjaśnienia dodawaj do wymagań, instrukcji użytkownika, może nawet do dymka z podpowiedzią w interfejsie dla użytkownika obok pola ze statusem. Byłoby bosko! Posłuży jako ściąga, jeśli pojawi się wątpliwość. W szczególności w złożonych procesach, obiegach w korporacjach, urzędach, itp. Zastanów się też czy każdy użytkownik musi widzieć wszystkie stany czy może dla realizujących zamówienie pokazywać szczegółowo kolejny etap np. „pobierany z magazynu” albo „szlifowany” a dla klienta tylko „zamówienie w przygotowaniu”.

A jak Twoje diagramy stanów? Przydałyby się jakieś udoskonalenia? Jak użytkownicy Twoich rozwiązań radzą sobie obsługiwaniem przepływów? A może sam zmagasz się z tragicznie dobraną nazwą statusu? Pochwal się wiele mówiącą nazwą :)

Cześć! 7 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Analizuję, prowadzę bloga, piszę artykuły, kursy, prezentuję, uczę na uczelniach i robię szkolenia. Przygotowuję także procesy analizy w firmach. Badając rynek szukam odpowiedzi na pytania: jak zostać dobrym analitykiem? Co to oznacza dla różnych odbiorców - kolegów z zespołu, managerów i klientów? Jak analitycy powinni się rozwijać? Po godzinach uczę się czegoś nowego i biegam do morza i z powrotem. Jestem ciekawa Twoich doświadczeń, wyzwań i problemów. Zostaw komentarz o sobie :)

5 KOMENTARZE

  1. Bardzo dobry wpis, skłania do podniesienia wewnętrznej rangi dla diagramu stanów :)
    Mam jednak pytanie do fragmentu:
    „…jeśli 100 pracowników poświęci na to sprawdzenie 3 minuty w tygodniu, to firma jest w plecy 5 osobo-godzin tygodniowo. 20 godzin w miesiącu. 24 dni w roku!”
    Jak z 20 godzin w miesiącu robi się 24 dni w roku? :)
    Jeśli miesięcznie 20 godzin, to 20 godzin x 12 miesięcy = 240 godzin
    240 godzin / 8 godzin pracy dziennie (bez narzutu na absencję) daje 30 dni w roku

    Pozdrawiam,
    Piotr Gibke

    P.S. To mój pierwszy komentarz na blogu i sygnalizuję, że w zakłopotanie wprawia pole „Nazwa” pośród pól do uzupełnienia przez Komentującego. Domyślam się, ze chodzi o nazwę dla wpisu… chociaż może o nazwę pod jaką chcę, aby widniał mój komentarz…(?)

    • Słuszna uwaga :)
      Używam standardowej wtyczki do komentarzy i nie przyglądałam się temu z perspektywy niezalogowanego użytkownika. Może faktycznie warto zmienić. Dzięki za uwagę.

  2. Trochę się nie zgadzam.
    Ok, nazwa stanu musi odpowiadać na pytanie o obecny stan obiektu, ale zdecydowanie nie musi, a wręcz nie powinna, nawiązywać do tego co się ma wydarzyć w następnym kroku.

    Albo może inaczej: w sytuacjach potocznych można sobie takie nazwy robić, ale jeśli wchodzimy na poziom formalny – diagramy stanów, maszyny stanowe, etc. – to mieszanie nazwy stanu z nazwami możliwych przejść i akcji spowoduje chaos.

    Reasumując: warto żeby analityk znał i rozumiał czym jest stan, czym różni się od przejść i akcji oraz jak tego wszystkiego używać, a osobną umiejętnością powinno być dopasowanie sposobu komunikacji do poziomu odbiorcy.
    Dzięki temu i rozwiązanie będzie przyjazne i zrozumiałe dla użytkownika, i dokumentacja systemu będzie logiczna i czytelna.

    • Masz na myśli, że niedobrze jest nazywać stany w stylu „do rozliczenia księgowego”, „do przetestowania”, „do odebrania w urzędzie”, co jest związane z tym, co się stanie za chwilę?
      Jak Twoim zdaniem jest bardziej czytelnie? Możesz jakieś przykłady podać?

      • Tak, o to mi chodzi.
        Nazwa stanu opisuje w jakim stanie obiekt znajduje się w danej chwili. To co można z nim zrobić, gdy znajduje się w danym stanie, to akcje. Akcje zaś mogą być różne dla różnych użytkowników.

        Załóżmy list, który został właśnie napisany.
        Można powiedzieć, że jest „DO WYSŁANIA”, ale co gdy po ponownym przeczytaniu uznamy, że nie chcemy go jednak wysłać tylko wyrzucić do kosza albo odłożyć na półkę i może nigdy nie wysłać? Czy zatem stan napisanego listu powinien się nazywać: „DO WYRZUCENIA” lub „DO ODŁOŻENIA NA PÓŁKĘ”? A może pójdziemy o krok dalej i nazwiemy go „DO WYSŁANIA lub WRZUCENIA lub ODŁOŻENIA NA PÓŁKĘ”?
        Można by też argumentować, że nazwa stanu pochodzi od czynności domyślnej, najczęściej występującej, a listy zwykle piszemy aby je wysłać, a więc „DO WYSŁANIA”. Ok, dziś to prawda, ale co gdy za jakiś czas proces się zmieni i list po napisaniu będzie trafiał do korektora w celu sprawdzenia? Zmiana na „DO SPRAWDZENIA”?

        A można prościej.
        List napisany jest w stanie NAPISANY. Można go (akcja)WYSŁAĆ lub (akcja)WYRZUCIĆ lub (akcja)ODŁOŻYĆ, co spowoduje zmianę stanu na WYSŁANY lub WYRZUCONY lub ODŁOŻONY.

        Ważne uzupełnienie – nie chodzi o to by nazwa stanu była odzwierciedleniem poprzedniej akcji, tylko faktycznego stanu w jakim znajduje się obiekt.
        Weźmy jeszcze raz ten list, tylko teraz taki, który po napisaniu trafił do sprawdzenia. Czy jest „SPRAWDZONY”? Tak, ale lepiej gdyby był „BEZBŁĘDNY” lub „ZAWIERAJĄCY BŁĘDY”.
        I właśnie „ZAWIERAJĄCY BŁĘDY”, a nie „DO POPRAWY”, bo może i dziś listy z błędami się poprawia, ale kto wie czy za rok, w ramach „optymalizacji kosztowej” nie będzie się ich poprawić tylko pisać na nowo?

        Oczywiście to wszystko na poziomie diagramu stanów i analizy procesów.
        Dla użytkownika piszącego list, na poziomie GUI, dostępne akcje mogą być „Wyślij”, „Zapisz” i „Anuluj”, i nawet po dodaniu w procesie korekty wcale nie musi się to zmienić.

ZOSTAW ODPOWIEDŹ