blog.testowka.pl

Jakość to tylko efekt motywacji

opublikowany przez 11, Lip, 2012, w kategoriach Agile, Praca, Programowanie, Testowanie, Zarządzanie

Po raz kolejny zadaje sobie (i wszystkim na około) pytanie: czym tak na prawdę jest jakość? Jakość w oprogramowaniu ma wiele wymiarów, pisałem już o tym kilka razy. Bez względu jaką definicję jakości wybierzemy to problem z tym jak tą jakość zapewniać pozostaje niemal niezmienny.

Próby wprowadzania tzw. „metryk jakości” dają jakieś efekty – ale czy to jest zapewnianie jakości? Prędzej to „zapewnianie” ogranicza się do reagowania w sytuacjach, gdy jest już na prawdę źle – za późno na zapewnianie jakości. Może spróbujmy zadać sobie pytanie skąd w takim razie bierze się jakość?

Wielokrotnie zastanawiając się nad kluczowymi czynnikami wpływającymi na jakość produktu dochodziłem do jednego wniosku – podstawą w procesie zapewniania jakości są ludzie. Nie mówię tutaj o specjalistach QA czy testerach, bo szczerze powiedziawszy oni akurat mają wbrew pozorom stosunkowo niewielki wpływ na jakość. Jakość jest implementowana od samego początku projektu i jest implementowana przez wszystkich ludzi, którzy w tym projekcie biorą udział. Idąc tym tropem można by wyciągnąć wniosek, że kluczowym elementem zapewniania jakości w oprogramowaniu jest zatrudnienie odpowiednich osób, które będą o jakość dbać na każdym kroku oraz danie tym osobom możliwości zapewniania jakości. Proste!

Nie do końca… Bob Marshall wysunął ostatnio teorię, że pierwotną przyczyną implementowania błędów w oprogramowaniu jest brak motywacji ludzi to oprogramowanie wytwarzających. Jeśli się temu bliżej przyjrzymy to bez problemu możemy przyznać mu rację.

Poniżej kilka standardowych powodów występowania błędów:

  • brak wiedzy programistów – tak technologicznej jak i domenowej,
  • niekompletne wymagania,
  • problemy komunikacyjne,
  • zbyt mało czasu,
  • inne problemy.

Spróbujmy przyjrzeć się każdemu z powyższych i zastanowić się jaki wpływ na uniknięcie takich błędów ma motywacja.

Brak wiedzy programistów (i innych osób zaangażowanych w projekt) – w rezultacie powstaje sporo błędów na poziomie implementacji. Dlaczego programiści nie posiadają wystarczającej (wystarczającej do zminimalizowania ilości implementowanych błędów, a nie do zaimplementowania funkcjonalności) wiedzy? Ja nie mam z tym większego problemu – jeśli czegoś nie wiem, albo nie jestem pewien to sprawdzam tak, by mieć pewność, że to co robię będzie najwyższej jakości. Spowodowane jest to wysoką motywacją do tego czym się zajmuje. Jeśli człowiek przychodzi do pracy po to by odsiedzieć swoje 8h i w tym czasie tylko zakodować to co od niego wymagają, a później najlepiej o tym zapomnieć, to ciężko tutaj mówić o zmotywowanym pracowniku. Znam co najmniej kilku programistów, w których kodzie na prawdę rzadko zdarzało nam się znajdywać błędy. Spowodowane było to pewnym perfekcjonizmem i motywacją do ciągłego rozwijania się i robienia rzeczy coraz lepiej. Nawet jeśli już udało nam się znaleźć błąd to szanse na to by podobny błąd został przez tą osobę w przyszłości zaimplementowany były wręcz zerowe. Niestety znam też „programistów”, którym 10 prawie identycznych błędów zdarzało mi się zgłosić w ciągu miesiąca pracując z nimi równolegle. To właśnie brak motywacji do nauki, zdobywania wiedzy, czy nawet uczenia się na własnych błędach jest główną przyczyną powstawania błędów i tworzenia bylejakości.

Niekompletne wymagania – to lubię, nie pamiętam ile razy już słyszałem: „to nie nasza wina, dali nam takie wymagania, od początku wiedzieliśmy, że to się nie uda, ale teraz mają to co chcą, więc w czym problem”. Pierwsze podstawowe pytanie: skoro wiedzieliście, że wymagania są złe, niekompletne, albo nie byliście pewnie o co tak na prawdę w nich chodzi to dlaczego nie poszliście do osób, które te wymagania tworzyły, albo tych dla których ten produkt tworzycie i nie zapytaliście ich o co tak na prawdę chodzi, lub nie przekonaliście ich do tego, że to nie ma sensu? Brak motywacji i wiążącego się z nią poczucia odpowiedzialności za produkt jest przyczyną tego, że tworzymy rzeczy źle, albo nawet złe rzeczy.

Problemy komunikacyjne – jak często zdarza się Wam wysłać maila z pytaniem do kogoś w tym samym pomieszczeniu (tudzież w zasięgu 50 metrów od Was)? Dlaczego tak jest? Dlaczego nie wstaniecie i nie podejdziecie do tej osoby by przedyskutować problem, zadać pytanie, wspólnie coś stworzyć – bez błędów, niedomówień, oraz czasu straconego na oczekiwanie na odpowiedź. Prosta zasada – nie po to mamy dwie nogi by 8h dziennie siedzieć przykutym do biurka! Znowu kwestia motywacji do tego by jak najlepiej i najszybciej wykonać zadanie – no bo po co skoro, można wysłać maila i czekać 2h na odpowiedź – w tym czasie można zrobić przecież tyle ciekawych rzeczy, jak przeglądanie facebooka, zakupy przez internet, czatowanie z sekretarką, i co tam jeszcze wymyślicie – ważne, że takie oczekiwanie przybliża nas do [tu wstaw „godzina przyjścia do pracy” + 8h]. To najprostszy przykład problemów komunikacyjnych. Oczywiście można by znaleźć ich znacznie więcej, ale każdy z nich można rozwiązać łatwiej bądź trudniej – pozostaje jedynie kwestia motywacji do tego by to zrobić. Kolejny problem to przekładanie relacji osobistych ponad relacje zawodowe – mi też się to wiele razy zdarzało i dopiero z perspektywy czasu mogę stwierdzić, jak bardzo wpływało to negatywnie na projekty, nad którymi pracowaliśmy. Będąc (stając się) profesjonalistą, dobrze zmotywowanym profesjonalistą uczymy się radzić sobie także z takimi problemami.

Zbyt mało czasu – w zasadzie powinienem pozostawić to bez komentarza, bo mamy już rok 2012 i powszechnie wiadomo na całym świecie, że nie robienie rzeczy szybciej oznacza robienie ich gorzej co w efekcie skutkuje poświęceniem większej ilości czasu na poprawki i ostatecznie okazuje się być znacznie dłużej niż początkowo planowano. A gdzie tu motywacja? Przede wszystkim to od nas zależy czy będziemy wystarczająco zmotywowani do tego by powiedzieć „NIE!”, gdy ktoś wymaga od nas implementowania bylejakości na wczoraj. Pisałem już o tym kilka razy – rynek pracy w branży IT jest teraz tak szeroki, że nie ma najmniejszego problemu ze zmienieniem pracodawcy, gdy obecny nam nie odpowiada. Umiejętność mówienia nie staje się coraz bardziej pożądaną cechą dobrego pracownika IT.

Inne problemy – jakiekolwiek przyczyny powstawania błędów w oprogramowaniu znajdziecie i wymienicie, powinniście zadać sobie pytanie dlaczego jeszcze tych przyczyn nie usunęliście i nie rozwiązaliście problemów? Wiem, fajnie jest narzekać i czekać, aż może ktoś coś zrobi ale dużo trudniej jest samemu wstać z miejsca i rozwiązać problem. Zawsze znajdzie się milion powodów przez które „nie da się”, pytanie tylko czy na prawdę się nie da i czy chociaż próbowaliście?

Zatem pozostaje temat jak motywować pracowników (pytanie, które słyszę prawie na każdej konferencji i szkoleniu) – prosta odpowiedź: Nie da się! Jedyne co możemy zrobić to stworzyć odpowiednie środowisko, w którym ludzie będą mogli być zmotywowani i czuć, że to co robią ma sens oraz jest częścią czegoś większego. Najważniejsze to nie przeszkadzać i nie niszczyć motywacji (co jest bardzo trudne). Kolejne wymaganie to zatrudnienie odpowiednich – zmotywowanych ludzi (tutaj też uwaga, bo de-motywacja jest  dużo bardziej zaraźliwa niż motywacja).

Powyższy post został zainspirowany rozmową z Bobem Marshallem oraz artykułem: „Bugs are a signal„, który wszystkim polecam!


1 Comment for this entry

  • Programista

    „to dlaczego nie poszliście do osób, które te wymagania tworzyły, albo tych dla których ten produkt tworzycie i nie zapytaliście ich o co tak na prawdę chodzi, lub nie przekonaliście ich do tego, że to nie ma sensu?”
    – ponieważ nie mamy możlwiości kontaktu z klientem, robi to tylko handlowiec, to co mu przeleci przez palce i zostanie zapisane, jest naszym pseudo wymaganiem. I nie mamy możliwości przekonać ich że to rozwiązanie jest złe, wypada to zrobić inaczej, bo handlowiec tak uzgodnił z klientem i tak ma być. Jako programista nie mamy prawa głosu.

    To się łatwo pisze na blogu, ale rzeczywistość wygląda inaczej. Handlowiec jedzie obiecuje gruszki na wierzbie na za 2 miesiące, coś tam lakonicznego spisze i dział aplikacji ma to wytworzyć w skrajnie krótkim czasie, bez dokładnej specyfikacji – „zróbcie coś co wdrożymy, bo klient zapłaci, a potem bedziemy poprawiać” i bez możliwości wpływania na propozycje rozwiązań funkcjonalności.

Skomentuj