Zdjęcie autora

Zarządzanie projektami #1 – dobra teoria po często nieefektywnej praktyce

Wakacyjna przerwa trwa w najlepsze – są pomysły, jest wola. Niestety ta ostatnia topnieje wobec gorącego żaru letniego czynnika „ZTP” (Zrobię-To-Później). Trzeba przełamać impas – ruszamy z pierwszym wpisem! Niniejszy  tekst będzie początkiem serii, obrazującej podstawowe błędy w działaniach, której dzisiaj modnie nazywamy zarządzaniem projektami. Do tego dodamy dobre praktyki oraz moje spostrzeżenia z „linii frontu”, które lepiej zapisać, aby w przyszłości nie stracić ciężko zdobytej wiedzy. Wartość dodana: dzielę się tym z Wami – Wy szczęściarze, Wy;). Projekty. Projekty, projekty projekty… W zasadzie teraz każdy ma projekt, fak-apy na projekcie i zarządza projektem. Ot, współczesne słowo-klucz do wizerunku nowoczesności personalnej. Ok , nie będę gorszy -mój projekt na dzisiaj: zrobić schabowe z piersi kurczaka: mam zasoby, deadline, opis produktu..;)

Oczywiście nie będę opisywał robienia kotletów. Przejdźmy do meritum: dzisiaj opiszemy sobie temat o nazwie: DOKUMENTACJA. Bardzo ciekawy (lubię tworzyć SOPZ lub OPZ-tki, wiem, że to chore, ale lubię, no! ), bardzo potrzebny i bardzo niebezpieczny – jeśli nie zadba się o właściwą jakość.

I tak źle, i tak niedobrze: diabeł tkwi w szczegółach a ogólność to pierwszy stopień do piekła(projektowego)

Z punktu widzenia Administracji publicznej/Klienta Opis Przedmiotu Zamówienia to sprawa kluczowa. Obok umowy dokument o pierwszorzędnym znaczeniu i…<niemal>niezmiennej formie. Tego aspektu nie rozumieją często Wykonawcy. Moi Drodzy, to pierwsza pułapka jaka czeka przedsiębiorcę, który wygrał przetarg.U nas, bardzo, bardzo ciężko jest zmienić zakres (są wyjątki) projektu. Oczywiście sam SIWZ i SOPZ mogą przewidywać zakres odstępstw, ale poza tym mamy bardzo małe szanse na modyfikacje po podpisaniu umowy.

Niestety nadal spotykam się z firmami, które przykładają wielką wagę do treści umowy, ignorując zapisy SOPZ, który przecież jest załącznikiem do wyżej wymienionej. To pierwszy typ zagrożenia dla projektu jeszcze zanim na dobre wystartował. Drugą pułapkę  – częściej nieświadomie, niż z premedytacją – zastawia sam Zamawiający (znaczy instytucja). Od treści SOPZ-u zależy wiele: jakość współpracy, jakość produktu, czas realizacji. Czy warto więc opisać wszystko bardzo szczegółowo, czy raczej wymienić kluczowe funkcjonalności z ich charakterystykami? Z jednej strony mamy wszystko na tacy: nic tylko siadać i projektować/programować, ale w przypadku błędu w dokumentacji (jesteśmy tylko ludźmi) rodzi się wielki problem a w skrajnych przypadkach otrzymamy coś, co trzeba od razu poprawiać (koszty!). W takiej sytuacji zaczyna się grillowanie biednego Wykonawcy – dużo zależy od  mniej formalnych relacji: zaufania, cierpliwości, zrozumienia….super płynne środowisko i nerwowa atmosfera.

Z drugiej strony możemy stworzyć kilku stronicowe podsumowanie naszych życzeń/wytycznych dot. produktu. Na końcu dodajemy formułkę: szczegóły zostaną opracowane na etapie spotkań przedprojektowych. W takim układzie należy zapewnić sobie dodatkowy czas na warsztaty z przedstawicielami firmy.  Jest fajnie. Tylko jak to wyceni firma/oferent? 100.000? 500.000? A może 25.000, bo na przykład nie zwróci uwagi na magiczna formułkę? Jeżeli znamy już firmę możemy pozwolić sobie na pewną dozę zaufania, ale Moi Drodzy – tutaj nie warto ufać nikomu. Efekt końcowy z reguły jest taki sam jak w pierwszej opcji: „W takiej sytuacji zaczyna się grillowanie biednego Wykonawcy – dużo zależy od  mniej formalnych relacji: zaufania, cierpliwości, zrozumienia….super płynne środowisko i nerwowa atmosfera”. Dla Zamawiającego ryzyko przedłużenia czasu projektu, dla Wykonawcy czas, ale też straty finansowe.

Jakie jeszcze ryzyko niesie za sobą ogólna dokumentacja, albo nawet jej brak (patrz: UM Wołomin i zamówienie aplikacji mobilnej – tak straszne, że aż śmieszne…) – obie strony nie mają 100% FORMALNEJ pewności, że produkt spełnia oczekiwania. Brak takowej to krótka ścieżka do sądu, z tym, że urzędnik sądzi się za publiczne, a biedny przedsiębiorca za swoje…

Czy jest trzecia droga? Tak: trzeba stworzyć dobrą dokumentację!

Dobra dokumentacja to… dobra dokumentacja!

Chcemy jak najmniej problemów na projekcie – jak to zrobić? Najprościej określić i wdrożyć cechy dobrej dokumentacji:

  1. odpowiedni poziom szczegółowości. Polecam zastosowanie następującej budowy tej części SOPZ, która odpowiada za opis produktu/funkcjonalności: – poziom I: ogólna cecha, nazwa funkcjonalności (np.: zostanie zaimplementowana wewnętrzna wyszukiwarka pełnotekstowa) – poziom II: doszczegółowienie: 1.1: dostępna na stronie głównej, 1.2 w wynikach pokazuje zarówno treści, jak i dokumenty etc. etc. – poziom III: najbardziej rozpisany: 1.1.1: przy wyświetlaniu dokumentów dodaje format pliku oraz jego rozmiar.

  2. ustalenie komunikacji z Wykonawcą, zakres, ilość warsztatów itp.  Należy zagwarantować sobie poprawną jakość komunikacji: dla części firm to standard, dla innych niepotrzebny nonsens – o, jak bardzo kosztowne będą ich pomyłki…

  3. koniecznie należy dodać zapisy o tzw. asyście technicznej na życzenie Zamawiającego (dodatkowo płatnej). Można, ale nie trzeba z niej korzystać. To jest nasze koło ratunkowe na wypadek błędów, zmian w środowisku zewnętrznym (np.: nowe przepisy prawa, nieoczekiwane sytuacje). Limit? Od 50 do nawet 200 godzin nie będzie przesadą.

  4. Ustalić opiekuna dokumentacji – osobę, która będzie czuwać nad „wersjonowaniem” dokumentacji, a także pilnować relacji późniejszych notatek, raportów etc. etc. do źródła opisu produktu. Nie ma nic gorszego, niż brak pamięci -średnio i -długookresowej. Im dłużej trwa projekt, tym gorzej dla nas w przypadku „rozjechania się” ustaleń. Nerwy, pretensje, sprzeczności, spowolnienie tempa prac, spadek jakości.

  5. Do użytku wewnętrznego: na spotkaniach roboczych, jeszcze przed opublikowaniem ogłoszenia o zamówieniu dobrze byłoby na podstawie końcowego projektu SOPZ ustalić: wagi dla poszczególnych funkcjonalności oraz orientacyjną złożoność prac (czasochłonność). W jaki sposób to robić? Najprościej za pomocą macierzy: funkcjonalności mogą mieć priorytet: A (krytyczne), B (ważne – dopuszczalne lekkie opóźnienia), C (drobne – akceptujemy średni okres opóźnień). Do tego dołóżmy naszą (subiektywną) ocenę złożoności: 1 (bardzo trudne zadanie, wymaga dużo zasobów oraz czasu), 2 (średnio -trudne), 3 (łatwe). Oczywiście to nie jest w pełni miarodajna ocena, ale bardzo ułatwi pracę w przypadku problemów (na 85-95% będą problemy). W ten sposób jesteśmy gotowi na wdrożenie szybkiego planu awaryjnego, razem z Wykonawcą. Ten punkt jest również swoistym audytem wewnętrznym: pokaże nam czy pisząc SOPZ nie skupiliśmy się za bardzo na mniej istotnych sprawach kosztem kluczowych funkcjonalności. Ponadto warto dokonać tej operacji z przyszłymi użytkownikami – niekoniecznie z naszego Wydziału/Departamentu – świeże spojrzenie na sprawę pomaga często wychwycić niezauważane przez twórców dokumentacji problemy/błędy.

  6. Nie bójmy się dialogu technicznego!Naprawdę warto rozmawiać z przedsiębioracmi. Ten dosyć nowy wynalazek pozwala spojrzeć na nasz przyszły produkt okiem potencjalnych Wykonawców (zakres, czas, rozwiązania stosowane obecnie na rynku). Nawet jeśli  na 5-6  zaproszonych firm tylko jedna okaże się źródłem wiedzy – skorzystaj z tego! Nawet jeśli masz zamówienie poniżej progu – skorzystaj z tego!Co można jeszcze dodać? A tak: skorzystaj z tego!!:)

 

 7 grzechów głównych

Podsumowując chciałbym wymienić te elementy, z którymi nie radzą sobie zarówno urzędnicy, jak i pracownicy firm prywatnych – w ramach opracowywania/analizowana/realizacji założeń dokumentacji projektowej:

  1. Nieodpowiedni poziom szczegółowości dokumentacji oficjalnej (SOPZ): brak koncentracji uwagi na kluczowych elementach.

  2. Złe przygotowanie dokumentacji: bez spotkań roboczych, bez konsultacji, bez wyobraźni.

  3. Brak wnikliwej analizy dokumentacji ze strony Wykonawcy (syndrom: byle zdobyć te zlecenia a potem jakoś będzie).

  4. Złudna wiara w elastyczne podejście Zamawiającego (urzędu) do zakresu i czasu realizacji opisanych w umowie oraz SOPZ.

  5. Zła komunikacja: albo unikanie spotkań roboczych, albo przesyt powyższych. Ustawiczne „ciąganie” programistów na debaty  tzw. menadżmentu to słaby pomysł. A może zamiast spotkania: Skype?

  6. Złe zarządzanie dokumentacją: nawet nie  wiecie jak wkurza mnie amnezja Wykonawcy, nieogarnianie notatek roboczych, ustaleń, priorytetów. Co 2-3 dni trzeba powtarzać to samo, bo okazuje się, że my korzystamy z wersji 1.9 a oni czytają wersję 1.2…. Jeden solidny kierownik projektu to + 30% do szybkości realizacji zadania. W innym wypadku witajcie w świecie niekończących się poprawek…

  7. Forma dokumentacji: po każdym spotkaniu notatka, przesyłana do obu stron.Uzgodnione ustalenia wędrują na wspólny dysk, gdzie w jednym miejscu mamy TE NAJWAŻNIEJSZE, ŚWIĘTE, AKTUALNE pliki z dokumentacją.

 

Dziękuję za uwagę. A teraz idę się pakować (urlop); potem – zgodnie z harmonogramem- schabowe;)

 

 

 

2 komentarze

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *