Done is better than perfect

  Uważasz je za słuszne? Czy za pochwałę bylejakości? Sądzisz, że jest skierowane tylko do niezdrowych perfekcjonistów? Jak możesz to powiedzenie odnieść do siebie? Do jakich sytuacji w Twojej pracy? Do jakich w Twoim życiu? Co możesz z niego wziąć dla siebie?

Dowcip o perfekcji

Kura przebiega przez ulicę. Nagle znikąd pojawia się samochód. Kura nie ma szans, aby uskoczyć. Samochód przejeżdża po kurze. Najpierw przednimi, potem tylnymi kołami. Zaraz potem auto znika w oddali. Kura leży bez ruchu na asfalcie. Po chwili podnosi się, wstaje, prostuje, przeciąga się i mówi z podziwem:

– Szatan nie kogut!

Dotrzymywanie terminów

W mojej pracy w  roli kierownika projektu  dość często spotykałem się z sytuacją niedotrzymywania terminu. Pilnowanie harmonogramu to jedno z podstawowych zadań kierownika projektu. Dlatego zawsze starałem się dociec: co spowodowało, że zadanie nie zostało wykonane na czas?

Najczęściej nie chodziło o niedoszacowanie liczby roboczogodzin potrzebnych na wykonanie zadania. Przyczyną było podniesienie jakości produktu końcowego. Konsultant, wyceniając pracochłonność, zakładał pewien poziom jakości. W trakcie wykonywania zadania stwierdzał, że taka jakość go nie zadowala. Zaczynał np. rozbudowywać dokument o dodatkowe szczegóły.

Głównie do takich sytuacji – moim zdaniem – odnosi się nasze tytułowe stwierdzenie. W mojej wersji brzmi ono…

Kończ pracę na czas  – ulepszenia (ewentualnie) wprowadzisz później

Jaką wartość wnosi takie podejście? Przede wszystkim: praca jest wykonana na czas. Mamy też dodatkowy element: listę proponowanych ulepszeń. I teraz zespół (a nie sam wykonawca) może ocenić, które z proponowanych ulepszeń warto wdrożyć. Biorąc pod uwagę koszty tego wdrożenia (pracochłonność), oczekiwania klienta i korzyści jakie te ulepszenia wniosą.

Dość często okazuje się, że wszystkie te ulepszenia mają swoje uzasadnienie. Jednak na obecnym etapie pozostają opcjami, które być może zostaną wdrożone  w wersji 2.0.

Nauczka

Pracowałem kiedyś jako programista. Kładłem nacisk na dobry algorytm i optymalizację czasu wykonania moich procedur. Byłem w tym dobry.

Potem stwierdziłem, że moje procedury powinny być też odporne na błędne dane wejściowe. Dorabiałem więc zawsze moduł sprawdzający poprawność danych wejściowych i generujący odpowiedni komunikat w przypadku niepoprawnych danych. To był mój nowy standard. Moje procedury już nie były tak szybkie.

Gdy wziąłem się za uzupelnienie tego elementu w starszych procedurach – zauważyłem jak słabo dokumentowany był mój kod. Po kilku latach od napisania procedury często nie rozumiałem już jak ona działa. Dokumentacja, np. krótki komunikat procedury co ona robi i jakich danych oczekuje bardzo pomaga. Zacząłem to robić. Dodawałem też znacznie więcej komentarzy w samym kodzie. Moje procedury stały się jeszcze wolniejsze. A czas ich przygotowania znacznie się wydłużył.

Podnosząc jakość w jednym obszarze obniżałem ją w innym. I to jest moja nauczka. Zapytaj tego dla kogo coś robisz, na czym mu zależy. Bardziej szczegółowa w dokumentacja może mieć dla klienta niższą jakość. Trudniej się po takim rozbudowanym dokumencie poruszać.

Niebezpieczeństwo

A jeśli moje propozycje poprawienia jakości są słuszne? Czy można pokazać klientowi dokument niskiej jakości? Przecież możemy w ten sposób stracić wiarygodność.

Po pierwsze: najczęściej sporo o kliencie wiemy. A jeśli to jest nasz pierwszy projekt dla tego klienta? Umawiamy się z nim na współpracę w trackie tworzenia produktu. Pokazujemy klientowi wczesne wersje: 0.1, 0.2, itp. W ten sposób zdobywamy wiedzę o oczekiwaniach klienta.

Po drugie: nie pokazujemy klientowi produktów w wersji końcowej, jeśli nie przeszły wewnętrznej weryfikacji. Konsultant dostarcza np. swój dokument i mówi o pomysłach na jego poprawienie. Przegląda to architekt i zatwierdza dokument. Albo wskazuje, które z ulepszeń należy wprowadzić przed przekazaniem dokumentu klientowi.

Zostaw komentarz

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