Niedawno znalazłem bardzo przydatny i prosty do przeprowadzenia test, pozwalający ocenić jakość i warunki pracy programistów. Odpowiada on także na pytanie "czy moja agencja jest dobrze przygotowana do wszelkich prac programistycznych".
Autor testu - Joel Spolsky jest założycielem Fog Creek Software, małej firmy programistycznej w Nowym Jorku. Ukończył Uniwersytet Yale i pracował jako programista i menedżer w Microsofcie, Viacom i Juno. Joel w dość zabawny sposób opisuje swój test:
A jak wygląda ten test? Dosyć prosto - wystarczy odpowiedzieć tak lub nie na 11 pytań. W oryginalnym teście pytań jest co prawda 12, ale 2gie pytanie nie dotyczy agencji interaktywnych.
Pytanie 10 moim zdaniem dotyczy agencji interaktywnych jedynie w połowie. Testery są potrzebni, ale nie muszą być na etacie.
Do zalet Testu Joela należy to, że łatwo można uzyskać krótką odpowiedź tak lub nie na każde pytanie. Nie trzeba wyliczać liczby-linii-kodu-na-dzień, czy średniej-liczby-błędów-na-punkt-zwrotny. Przyznaj swojemu zespołowi jeden punkt za każdą odpowiedź "tak". Pewien niedostatek Testu Joela polega na tym, że naprawdę nie należy go stosować do oceny bezpieczeństwa oprogramowania dla elektrowni atomowej.
Wynik 12 jest doskonały, z 11-tką da się wytrzymać, lecz 10 lub mniej punktów znamionuje duże kłopoty. Prawda jest taka, że większość przedsiębiorstw programistycznych działa z wynikiem 2 lub 3. Potrzebują one poważnej pomocy, gdyż firmy takie jak Microsoft działają na okrągło na poziomie 12.
Oczywiście nie są to jedyne czynniki, które determinują sukces lub porażkę. Jeśli nawet masz wspaniały zespół, ale tworzy on nikomu niepotrzebny produkt, wtedy cóż, nikt go nie kupi. Można też sobie wyobrazić zespół "rewolwerowców", który nie stosuje się do żadnej reguły, lecz mimo to jest w stanie wytworzyć niezwykłe oprogramowanie, zdolne zmienić oblicze świata. Pomijając jednak wszystko inne, jeżeli tylko dopilnujesz tych dwunastu spraw, będziesz miał zdyscyplinowany zespół, zdolny do systematycznej produkcji oprogramowania.
Nie powiem ile punktów uzbierała moja agencja. Powiem jedynie, że nasz szef programistów dostał zadanie podniesienia wyniku o parę oczek:)
Autor testu - Joel Spolsky jest założycielem Fog Creek Software, małej firmy programistycznej w Nowym Jorku. Ukończył Uniwersytet Yale i pracował jako programista i menedżer w Microsofcie, Viacom i Juno. Joel w dość zabawny sposób opisuje swój test:
Czy kiedykolwiek słyszałeś o SEMA? Jest to dość ezoteryczny system pomiaru sprawności zespołu programistycznego. Stop, zaczekaj! Nie zaglądaj tam! Samo zrozumienie tego materiału zajmie ci ze sześć lat. Dlatego wypracowałem sobie mój własny, swobodny i wysoce nieodpowiedzialny test do oceny jakości zespołu. Jego wielką zaletą jest to, że zabiera około 3 minut. Czas, jaki zaoszczędzisz, wystarczy na studia medyczne.Mimo, iż Joel przygotowywał swój test z myślą o firmach wytwarzających oprogramowanie to doskonale sprawdza się on także w przypadku agencji interaktywnych (które działają na styku agencji reklamowej i firmy informatycznej).
A jak wygląda ten test? Dosyć prosto - wystarczy odpowiedzieć tak lub nie na 11 pytań. W oryginalnym teście pytań jest co prawda 12, ale 2gie pytanie nie dotyczy agencji interaktywnych.
Test Joela
- Czy stosujesz system kontroli wersji?
Czy możesz zbudować wersję w jednym kroku?- Czy stosujesz codzienne budowanie wersji?
- Czy używasz system zarządzania błędami?
- Czy usuwasz błędy zanim napiszesz nowy kod?
- Czy masz harmonogram aktualizowany na bieżąco?
- Czy masz specyfikację?
- Czy programiści mają komfortowe warunki pracy?
- Czy używasz najlepszych dostępnych narzędzi?
- Czy masz testerów?
- Czy kandydaci piszą programy podczas rozmowy kwalifikacyjnej?
- Czy praktykujesz korytarzowe testy wygody użytkowania?
Pytanie 10 moim zdaniem dotyczy agencji interaktywnych jedynie w połowie. Testery są potrzebni, ale nie muszą być na etacie.
Do zalet Testu Joela należy to, że łatwo można uzyskać krótką odpowiedź tak lub nie na każde pytanie. Nie trzeba wyliczać liczby-linii-kodu-na-dzień, czy średniej-liczby-błędów-na-punkt-zwrotny. Przyznaj swojemu zespołowi jeden punkt za każdą odpowiedź "tak". Pewien niedostatek Testu Joela polega na tym, że naprawdę nie należy go stosować do oceny bezpieczeństwa oprogramowania dla elektrowni atomowej.
Wynik 12 jest doskonały, z 11-tką da się wytrzymać, lecz 10 lub mniej punktów znamionuje duże kłopoty. Prawda jest taka, że większość przedsiębiorstw programistycznych działa z wynikiem 2 lub 3. Potrzebują one poważnej pomocy, gdyż firmy takie jak Microsoft działają na okrągło na poziomie 12.
Oczywiście nie są to jedyne czynniki, które determinują sukces lub porażkę. Jeśli nawet masz wspaniały zespół, ale tworzy on nikomu niepotrzebny produkt, wtedy cóż, nikt go nie kupi. Można też sobie wyobrazić zespół "rewolwerowców", który nie stosuje się do żadnej reguły, lecz mimo to jest w stanie wytworzyć niezwykłe oprogramowanie, zdolne zmienić oblicze świata. Pomijając jednak wszystko inne, jeżeli tylko dopilnujesz tych dwunastu spraw, będziesz miał zdyscyplinowany zespół, zdolny do systematycznej produkcji oprogramowania.
Nie powiem ile punktów uzbierała moja agencja. Powiem jedynie, że nasz szef programistów dostał zadanie podniesienia wyniku o parę oczek:)
Test Joela to zdecydowanie dobry punkt startowy dla wszystkich, którzy chcieliby poprawić proces tworzenia oprogramowania. Bagatelizowanie jego wyniku jest moim zdaniem groźnym obrażaniem się za to, że wytyka się komuś błędy i zaniedbania.
Swoją drogą, żeby zrozumieć kontekst Testu Joela warto zapoznać się z całą zawartością joelonsoftware.com i bezkompromisowym podejściem Joela do wielu spraw, np. rekrutacji, warunków pracy programistów czy obsługi klienta.
Nie zgodzę się przy tym, że punkt 2 nie dotyczy agencji interaktywnych. Jeśli agencja pracuje nad aplikacją webową, np. w j2ee to jak najbardziej powinna być w stanie postawić builda w jednym kroku. Zreszta... punkty 2 i 3 są dość mocno ze sobą powiązane. Jeśli trzeba wielu kroków, żeby postawić nowego builda, to w natłoku pracy w końcu pewnie przestanie się go stawiać codziennie.
Wszystkie wymienione punkty jak najbardziej przystają do agencji i pozwalają ocenić jej jakość w obszarze IT, no...może dodałbym jeszcze jedno, 13ste pytanie: czy Twoi project manager'owie potrafią zaplanować i zarządzać scopem projektu IT ;-)
Zarządzanie:
PhpCollab, Tutos (The Ultimate Team Organization Software)
Kontrola wersji:
TortoiseCVS - klient CVS zrozumiały dla każdego nawet najmniej rozgarniętego "wykształciucha"
z funkcją PM
Testy:
JMeter - narzędzie do tworzenia testów (mniej lub bardziej zaawansowanych)
I wiele, wiele innych.
Wniosek. Wystarczą tylko dobre chęci i test Joela spełniamy naprawdę niskim kosztem stosując wolne oprogramowanie. Oczywiście mogą się pojawić pewne koszty wdrożenia ( szkolenia, początkowe nieporozumienia, opóźnienia itp.), co zaznaczył wcześniej Łukasz Felsztukier.
Można tutaj dojść kolejny raz do pytania czy stosowanie takich narzędzi (lub komercyjnych) jest konieczne przy KAŻDYM projekcie w agencji interaktywnej. Otóż wg mnie nie. Dużo ważniejszy jest czynnik ludzki, cel i skala projektu, szczególnie dla tych projektów w których warstwa wizualna jest ważniejsza niż "spód" aplikacji. Dołączam kolejne pytania:
1. Czy czynnik zarządzający potrafi wynegocjować budżet adekwatny do skali projektu, oraz sensowny (realny) czas realizacji?
2. Czy w Twojej agencji czynnik zarządzający nadaje na tych samych falach co graficy i programiści, inaczej rzecz rozumiejąc czy miedzy tymi trzema filarami jest jakakolwiek komunikacja?
3. Czy Twojej agencji udaje się wyperswadować klientowi umieszczenie 10 logotypów na stronie głównej i parę innych "ciekawych" inaczej pomysłów, które z dużym prawdopodobieństwem "położą" i opóźnią projekt? Inaczej, czy istnieje dobra komunikacja klient-agencja.
4. Czy każda osoba w zespole ma swojego dublera zdolnego w krótkim czasie przejąć projekt w razie problemów?
I tutaj dodałbym 2 podpunkty z testu Joela:
5. Czy masz specyfikację? (niestety projekty "na gębę" często źle się kończą, jeżeli wogóle się zaczynają)
6. Czy praktykujesz korytarzowe testy wygody użytkowania? (bardzo ważny element, szczególnie w kwestii działania nawigacji) - wiele agencji ten podpunkt praktykuje niestety w momencie publikacji. Choć kto jest bez winy niech pierwszy rzuci kamieniem :)
Oczywiście w zależności od skali projektu można by dodać kilka innych punktów - usprawniających działanie agencji.
W przypadku dużej przewagi "dolnej" warstwy aplikacji test Joela znowu nabiera jak najbardziej sensu.
Jeszcze mała uwaga do stwierdzenia: "zespołowe tworzenie oprogramowania to zupełnie co innego niż pisanie stronek w PHP". Wbrew pozorom "pisanie stronek w PHP" staje się coraz bardziej zespołowe i zaczyna być wspierane przez "wielkich" tego świata swoimi narzędziami, patrz: Delphi for PHP
Dodaj komentarz
Wpisy tego samego autora