Przychodzi czasem taki moment w projekcie, kiedy to sprawy zaczynają schodzić na zły tor. Klient przestaje być zadowolony, ludzie nerwowi, atmosfera robi się gęsta. Czasem też dzieje się bardzo dobrze i wszyscy zastanawiaja się co można zrobić, żeby było jeszcze lepiej. Niestety ten pierwszy przypadek zdarza się dużo częściej. Ponieważ zgodnie z prawem Murphy’ego, że „Sprawy pozostawione samym sobie mają tendencję do przemiany ze złych w jeszcze gorsze”, trzymający rękę na pulsie project manager otwiera swój kalendarz, click, click i w skrzynkach pocztowych członków zespołu ląduje zaproszenie na spotkanie. Spotkanie ma na celu naprawienie sytuacji, zbawienie świata, sprawienie, że wszyscy nagle staną się szczęśliwi.
Na spotkaniu bardzo szybko pojawia się tyle stanowisk, na temat przyczyn problemu, ile ról jest w zespole projektowym. Developerzy krzyczą, że dokumentacja analityczna jest niejasna i zawiera wiele nieścisłości. Analitycy narzekają, że nie są w stanie dogadać się z developerami (w końcu nikt nie zna języka, którym trzeba mówić do tych Kosmitów). Architekt ma za złe developerom, że piszą „brzydki” kod. Project manager siedzi z oczami wlepionymi w swój MS Project i dalej nie może pojść, dlaczego wszystkie terminy są przekroczone o trzy tygodnie, a ogólny rozrachunek już dawno jest pod kreską. Ktoś spisuje minutki, które później roześle do wszystkich jako podsumowanie spotkania. Spotkanie często kończy się w losowym momencie, bo skończył się przewidziany na nie czas, a na zewnątrz stoi inny project manager i tupie nerwowo nóżką, bo ma rezerwację na salę konferencyjną. Każdy ze spotkania wychodzi z poczuciem swojego własnego małego zwycięstwa (w końcu im powiedziałem co myślę, niech się nieroby wezmą w końcu porzadnie do pracy).
Co się dzieje potem? Każdy liczy na to, że problem zostanie rozwiązany przez pozostałych.
W projekcie gdzie miałem zaszczyt być Team leadem było trochę inaczej. Ludzie nie obwiniali się nawzajem, atmosfera była rewelacyjna. Mimo to od samego początku bylićmy w ciemnej dupie. Wynikało to ze specyfiki projektu. Mieliśmy za zadanie przejąć w utrzymanie i rozwój ogromny system, rozwijany i utrzymywany przez około dziesięć lat przez poprzedniego dostawcę z Turcji. System napisany w egzotycznych frameworkach, z logiką biznesową tak zagmatwaną, że sam klient miał problemy z jej ogarnięciem. Miotaliśmy się jak ryby wyrzucone na brzeg, lista zadań w JIRA rosła z dnia na dzień, a do ogarnięcia było osiem produkcyjnych wdrożeń w różnych krajach Europy.
Nasze spotkanie (a raczej cykl spotkań) wyglądało zupełnie inaczej. Na tym cyklu spotkań po raz pierwszy spotkałem się z pojęciem cel S.M.A.R.T. Podczas spotkania zidentyfikowaliśmy słabe i mocne strony naszego zespołu i procesu. Każdy w spokoju musiał, na żółtych karteczkach, wypisać pięć pozytywów i pięć negatywów odnośnie sytuacji, w której się znaleźliśmy. Zebraliśmy to do kupy i powtarzające się uznaliśmy za obszary do dalszej analizy.
Wynikiem spotkania miały być owe cele S.M.A.R.T. Czyli konkretne, mierzalne, wykonalne w założonym czasie cele, przypisane do konkretnych osób.
Co ważne cele nie dotyczyły jedynie negatywów, ale również uwzględniały ulepszanie tego, co już uznaliśmy za dobre.
Co w tym odkrywczego może ktoś zapytać? Ano okazuje się, że mimo, że brzmi to banalnie, to dalej znaczna część odbywających się na świecie spotkań projektowych kończy się tylko na bezproduktywnym gadaniu. I myślę, że duża część osób, będąca w branży od dłuższego czasu, przyzna mi rację.
Aby zobrazować czym różni się cel S.M.A.R.T od nie S.M.A.R.T podam kilka przykładów.
SMART | Nie SMART |
Zorganizowanie przestrzeni na firmowym Confluence przeznaczonej na wymianę wiedzy między członkami zespołu. | Poprawienie wymiany wiedzy między członkami zespołu |
Przynajmniej raz w tygodniu opisanie na Confluence trzech przypadków, które ostatnio rozwiązałem. | Informowanie członów zespoły o ciekawych zgłoszeniach z jakimi miałem do czynienia |
Zmniejszenie średniego czasu odpowiedzi strony głównej aplikacji o 20%, a podstron z menu głównego o 15%. | Przyspieszenie działania aplikacji |
Czy widzicie tę subtelną różnicę? Aby cel by? S.M.A.R.T musi być skonkretyzowany i mierzalny. Oznacza to, że musi istnieć wyraźne kryterium jego ukończenia. Cel S.M.A.R.T musi być osiągalny i realny (i co za tym idzie wykonalny w założonym okresie czasu). Nie ma sensu stawiania zbyt ambitnych celów „zbawiajścych świat”. Chodzi raczej o realizację znanego stwierdzania „małymi krokami do celu”. Najlepiej również aby do realizacji celu S.M.A.R.T została przydzielona osoba, która bierze odpowiedzialność za jego realizację. Oczywiście może pracę delegować, ale musi tez postępować zgodnie z bardzo dobrą zasadą „można delegować pracę ale nie może delegować odpowiedzialności”.
Staram się, aby cele S.M.A.R.T towarzyszyły mi w trakcie rozwiązywania każdego problemu na jaki napotykam w pracy zawodowej. To naprawdę pomaga…
Dzi?ki za wpis 🙂 Og?lniki mog? by? pomocne w opisywaniu tzw. „big picture”. Natomiast komunikacja na p?aszczy?nie przydzielania zada? powinna by? „konkretna i mierzalna”, bo inaczej albo mo?na co? ?le zrozumie? albo co? pomin??.
Tak jak piszesz RAF. Zadania musz? by? zawsze sformu?owane w spos?b jednoznaczny nie zostawiaj?cy pola na interpretacj?.
Tomek, pierwszy z cel?w nie do ko?ca jest SMART. Trzeba by jeszcze zawiesi? go w okre?lonych ramach czasowych, by m?g? by? weryfikowalny 🙂 Podobnie trzeci.
W samej definicji tych cel?w faktycznie nie ma okre?lonych ram czasowych, ale cz?sto jest te? tak, ?e termin jest domy?lnie ustalony, jako data kolejnego spotkania. Ale faktycznie, najlepiej by?oby, ?eby te? jasno sprecyzowa? czas realizacji. Co do weryfikowalno?ci to wydaje mi si?, ?e w obu przypadkach, warunki jakie musz? by? spe?nione aby uzna? cel za wykonany s? jasno okre?lone.