Done is better than perfect

Done is better than perfect

Done is better? Uważasz takie podejście 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?

Done is better. Dotrzymuj terminów

W mojej pracy w roli kierownika projektu dość często spotykałem się z sytuacją niedotrzymywania terminu: Z kim lubię pracować. Pilnowanie harmonogramu to jedno z podstawowych zadań kierownika projektu. Stąd dla mnie: done is better than perfect. Dlatego też 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ł więc 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 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ą. Warto też wziąć pod uwagę dynamikę zespołu. Praca nad udoskonaleniem produktu, skutkująca niedotrzymaniem terminu, będzie źle odebrana przynajmniej przez część zespołu.

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.

Done is better. 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 zacząłem uzupełniać ten element w starszych procedurach: zauważyłem, jak słabo dokumentowany był mój kod. Po kilku latach od napisania procedur 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 dokumentacja może mieć dla klienta niższą wartość. Trudniej się po takim rozbudowanym dokumencie poruszać.

Done is better? 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? Np. umawiamy się z klientem na współpracę w trakcie 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. Np. konsultant dostarcza swój dokument i mówi o pomysłach na jego poprawienie. Ale przegląda to architekt i zatwierdza dokument. Albo wskazuje, które z ulepszeń należy wprowadzić przed przekazaniem dokumentu klientowi.

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. Ale, po chwili, podnosi się, prostuje, przeciąga się i mówi:

– Szatan nie kogut!

Zostaw komentarz

*

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *