Procesy kojarzyły, i w sumie nadal kojarzą mi się, z korporacją. Pewnie dlatego, że tam nabyły złą sławę, a przecież każda firma w mniejszym lub większym stopniu korzysta z procesów.
Skąd wzięła się zła sława procesów? Mam wrażenie, że przede wszystkim przez trzymanie się ich zawsze i w każdej sytuacji, bez żadnej refleksji. Z brakiem bieżącego dostosowania procesów do potrzeb organizacji – im większa organizacja, tym więcej czasu potrzebuje na zmianę i dostosowanie procesów.
Co można zyskać dzięki procesom? Powtarzalność wykonania. Pewność wykonania wszystkich kroków. Automatyzację pewnych czynności, dzięki czemu zyskujemy czas na inne, kreatywne działania. Podchodząc zwinnie do wdrażania procesów potrafimy je szybko modyfikować i dostosowywać do potrzeb organizacji.
Zasady tworzenia procesów
Nie ma większego znaczenia, czy chcesz wprowadzić proces dla swojego pięcioosobowego zespołu, czy wielkiej organizacji. Zasady są trzy:
- powtarzaj to, co się sprawdza
- wycinaj lub modyfikuj to, co się nie sprawdza
- automatyzuj, co się da
Jak zacząć?
Po pierwsze, nie twórz procesu sam. Chyba, że dla siebie 😉 Ale proces dla zespołu / organizacji twórz z osobami zainteresowanymi. Wypracowany wspólnie ma większą szansę się przyjąć.
Poza tym, wspólna burza mózgów nad tym, co można zmienić, może być bardziej efektywna, bo skorzystacie z doświadczeń więcej niż jednej osoby.
Co dalej?
Gdy już masz pierwotny zarys procesu, który jesteś skłonny wdrożyć, opisz go w miejscu dostępnym dla każdego zainteresowanego i poproś o feedback.
Możesz pokusić się o stworzenie wizualnej reprezentacji, ale pamiętaj, żeby nie przesadzić. Lepsze będą “bloczki i strzałki”, niż przepiękny proces narysowany w notacji BPMN, którego nikt w Twoim zespole nie zna*.
Kierowanie się tymi samymi zasadami co przy opisie wymagań będzie dobrym pomysłem. To oznacza, że poszczególne kroki procesu muszą być:
- możliwe do wykonania (feasible),
- atomowe (atomic),
- kompletne (complete),
- spójne w swoim opisie (consistent),
- jednoznaczne (unambiguous),
- zwięzłe (concise),
- zrozumiałe (understandable)
Następnie poproś o feedback – czy to co zostało przez Ciebie przygotowane jest zrozumiałe i czy to jest to na co się umówiliście?
Jeżeli będą pojawiały się trudności z potwierdzeniem, możesz podejrzewać, że nie są one zrozumiałe, albo są zbyt obszernie opisane.
Egzekwowanie
W idealnym świecie, tyle by wystarczyło. Tyle, że ludzie są przyzwyczajeni do sposobu w jaki działali do tej pory i bez złej woli będą podążać starymi ścieżkami.
Musisz im pomóc.
Stwórz mechanizmy kontroli, które pozwolą Ci jak najszybciej wyłapać te działania, które nie są zgodne z nowym podejściem.
Na początku może to być manualne sprawdzanie: codzienne zadanie na Twojej liście TODO z linkiem do sprawdzenia konkretnej rzeczy.
Możesz się pokusić o jakiś rodzaj automatyzacji, jeżeli jest to możliwe.
Przykład
Uzgodnione z zespołem zostało, że każdy będzie dodawał konkretną tabelkę w Jira.
Manualne podejście: link do Jira na Twojej codziennie liście, a konkretnie do wyfiltrowanych rezultatów wyszukiwania (projekt, sprint, labelki).
Automatyzacja: na każde wyszukiwanie w Jira możesz stworzyć “subskrypcję” – zostaniesz poinformowany mailem, jeżeli pojawią się jakieś wyniki wyszukiwania.
Gdy natrafisz na odstępstwo od nowej reguły, poinformuj osobę, której to dotyczy. Ale pamiętaj – raczej niska jest szansa, że osoba ta nie dostosowała się celowo, więc po prostu przekaż informację.
Ułatwianie
Możesz pokusić się, żeby ułatwić swoim współpracownikom zmianę.
Zastanów się, jak możesz to najlepiej zrobić.
Może trzeba skonfigurować Jirę odpowiednio?
Albo stworzyć odpowiednie templatki, które ułatwią zadanie?
Wszystko co ułatwi zadanie w pierwszych dniach spowoduje, że proces zostanie przyjęty szybciej i sprawniej.
Powodzenia!
__________
*akurat notacja BPMN w podstawowym zakresie to właśnie “bloczki i strzałki” 😉
