Joel Test na polskim podwórku
Organizacja projektu 21/09/2006 · Link Słyszeliście o Joel Test? Dla tych co nie słyszeli, szybki skrót: test Joela, to krótka ankieta, która pozwala ocenić sposób wytwarzania oprogramowania w danej firmie. Choć niektóre z jej założeń mogą być dyskusyjne, to zaletą w porównaniu do innych technik (np. modelu CMM) jest to, że wynik można mieć w ciągu trzech minut (np. już podczas rozmowy o pracę :) ). Z ciekawości rozesłałem tę ankietkę do kilku niereprezentatywnie wybranych firm w których pracują moi znajomi. Są wśród nich małe, są średnie, jest jeden kolos. Większość koncentrujące się na produkcji oprogramowania na zamówienie (dla klientów biznesowych). Część z nich odpowiedziała i oto rezultaty.
- Żadna z firm nie wypadła rewelacyjne dobrze, a większość z nich dobrze sobie radzi na rynku. Ciekawe jaka byłaby jakość ich produktów i sukcesy rynkowe, gdyby się podciągnęły? Wdrożenie większości z tych punktów nie wymaga ani dużego nakładu finansowego ani wielkich zmian organizacyjnych.
- Zdziwiło mnie, że niewiele z firm prosi o napisanie kodu podczas rozmowy kwalifikacyjnej. Jak wobec tego oceniają one kandydatów do pracy? Tylko na podstawie deklaracji? Opinii z poprzedniej pracy bądź innych osób? Jak wiele osób nie sprawdza się w trakcie okresu próbnego?
- Mało firm robi cokolwiek, by przetestować interfejs użytkownika. Dlaczego? Czy to jest uważane za mało ważne? Nawiasem w USA są kierunki studiów/specjalizacje poświęcone usability; czy gdzieś tego uczą w Polsce?
- Oszczędność na narzędziach sugeruje, że koszty pracy informatyków w Polsce są jednak wciąż znacznie niższe niż na zachodzie.
Zobacz inne wpisy
co do testów interface'u: w Polsce znam jeden kierunek, który tego uczy (i który mnie nauczył :) Społeczna Psychologia Informatyki i Komunikacji - http://www.spik.swps.edu.pl. Ale można czasem spotkać elementy takiego testowania w programach informatyki.
Mam też takie pytanie - jaka jest u Was praktyka testów, jeśli takie robicie, tzn. zlecacie je na zewnątrz, czy sami organizujecie?
PS. - tabelka źle się renderuje w Operze, pojawia się czarne tło
Mam też takie pytanie - jaka jest u Was praktyka testów, jeśli takie robicie, tzn. zlecacie je na zewnątrz, czy sami organizujecie?
PS. - tabelka źle się renderuje w Operze, pojawia się czarne tło
23/09/2006,
Wojciech Kuśmierek
Witaj Marku,
Szkoda, ze nie ponumerowales swoich refleksji -- latwiej byloby sie odnosic.
1.
Wydaje mi sie, ze jednak wymaga wysilku organizacyjnego, i *decyzji* przelozonych -- o wiele latwiej pisze sie kod i goni terminy -- to zupelnie jak z politykami i reformami, ktorych skutkow nie bedzie mozna odczuc przed najblizszymi wyborami -- sa inne wazniejsze :) sprawy.
2.
Wiekszosc z nas napisala pewnie, kiedys na studiach, kawalek kodu na kartce i nie byla z niego zadowolona (a co gorsza oceniajacy tez).
Teraz mamy uraz i nie wymagamy tego od innych.
Co gorsze, wydaje mi sie, ze czas spedzony na rozmowie kwalifikacyjnej wielu z nas uwaza za czas zmarnowany (choc moze to nie najlepsze slowo) -- a poproszenie kandydata o napisanie kodu i pozniejsza jego analiza jeszcze by ta rozmowe przedluzylo.
3.
a) Interfejs jest standardowy (a przynajmniej tak sie autorom wydaje) i wtedy nie ma czego testowac -- o czym sam kiedys pisales.
b) Klient i tak nie wie czego chce i nie warto marnowac czas na interfejs uzytkownika i jego uzytecznosc (bo i tak sie jeszcze zmieni).
A pozniej oprogramowanie juz dziala i rozpoczyna sie nastepny projekt...
4.
Pytanie na ile odpowiedzi na to pytanie sa obiektywne :).
Kazdy jakies narzedzia ma i sobie musi radzic... :(.
Fajnie jest uzywac ,,najlepszych'' narzedzi, tylko, czy pozwola one szybciej osiagac cele?
Czy przepisywanie wszystkiego z Perl-a na PHP,a pozniej na Ruby on Rails, a teraz na Wasabi on Wails (http://secretgeek.net/wasabi_rewrite.asp)?
Czy ktos, poza programistami, czerpie z tego pozytek?
Na koniec cos pozytywnego -- Joel pisal, ze wiekszosc firm dziala majac 2 lub 3 punkty -- tutaj najnizszy wynik to 4.
A srednia ponad 6.
Szesc lat temu (gdy Joel Test powstal) to bylby niezly wynik.
Dzis pewnie nie odstaje od reszty swiata.
Szkoda, ze nie ponumerowales swoich refleksji -- latwiej byloby sie odnosic.
1.
Wydaje mi sie, ze jednak wymaga wysilku organizacyjnego, i *decyzji* przelozonych -- o wiele latwiej pisze sie kod i goni terminy -- to zupelnie jak z politykami i reformami, ktorych skutkow nie bedzie mozna odczuc przed najblizszymi wyborami -- sa inne wazniejsze :) sprawy.
2.
Wiekszosc z nas napisala pewnie, kiedys na studiach, kawalek kodu na kartce i nie byla z niego zadowolona (a co gorsza oceniajacy tez).
Teraz mamy uraz i nie wymagamy tego od innych.
Co gorsze, wydaje mi sie, ze czas spedzony na rozmowie kwalifikacyjnej wielu z nas uwaza za czas zmarnowany (choc moze to nie najlepsze slowo) -- a poproszenie kandydata o napisanie kodu i pozniejsza jego analiza jeszcze by ta rozmowe przedluzylo.
3.
a) Interfejs jest standardowy (a przynajmniej tak sie autorom wydaje) i wtedy nie ma czego testowac -- o czym sam kiedys pisales.
b) Klient i tak nie wie czego chce i nie warto marnowac czas na interfejs uzytkownika i jego uzytecznosc (bo i tak sie jeszcze zmieni).
A pozniej oprogramowanie juz dziala i rozpoczyna sie nastepny projekt...
4.
Pytanie na ile odpowiedzi na to pytanie sa obiektywne :).
Kazdy jakies narzedzia ma i sobie musi radzic... :(.
Fajnie jest uzywac ,,najlepszych'' narzedzi, tylko, czy pozwola one szybciej osiagac cele?
Czy przepisywanie wszystkiego z Perl-a na PHP,a pozniej na Ruby on Rails, a teraz na Wasabi on Wails (http://secretgeek.net/wasabi_rewrite.asp)?
Czy ktos, poza programistami, czerpie z tego pozytek?
Na koniec cos pozytywnego -- Joel pisal, ze wiekszosc firm dziala majac 2 lub 3 punkty -- tutaj najnizszy wynik to 4.
A srednia ponad 6.
Szesc lat temu (gdy Joel Test powstal) to bylby niezly wynik.
Dzis pewnie nie odstaje od reszty swiata.
23/09/2006,
Grzegorz
Wojciech,
Dziękuję za link i informacje. Myślę, że dla czytelników tego blogu mogłaby być interesująca Twoja opinia o tych studiach. Zwłaszcza wartościowe mogą być te informacje, których nie da się zdobyć przeglądając stronę internetową: na co jest położony nacisk w programie nauczania? Jakie praktyczne projekty wykonują studenci? Jakie doświadczenie praktyczne mają wykładowcy etc.?
Pozdrawiam,
Marek
Dziękuję za link i informacje. Myślę, że dla czytelników tego blogu mogłaby być interesująca Twoja opinia o tych studiach. Zwłaszcza wartościowe mogą być te informacje, których nie da się zdobyć przeglądając stronę internetową: na co jest położony nacisk w programie nauczania? Jakie praktyczne projekty wykonują studenci? Jakie doświadczenie praktyczne mają wykładowcy etc.?
Pozdrawiam,
Marek
27/09/2006,
Marek Rafałowicz
Grzegorz,
Wydaje mi się, że spełnienie większości punktów (poza 8, 9 i 10) jest w zasięgu możliwości kierownika projektu, lidera programistów a nawet programisty. Wobec tego wynik w okolicach szóstki jest nierewelacyjny, nieprawdaż?
Pozdrawiam,
Marek
Wydaje mi się, że spełnienie większości punktów (poza 8, 9 i 10) jest w zasięgu możliwości kierownika projektu, lidera programistów a nawet programisty. Wobec tego wynik w okolicach szóstki jest nierewelacyjny, nieprawdaż?
Pozdrawiam,
Marek
27/09/2006,
Marek Rafałowicz
Marku,
To zalezy, czy patrzymy na to z teoretycznego, czy praktycznego punktu widzenia :).
Skoro tak latwo, to dlaczego zadna z badanych firm nie ma wiecej niz 8/12?
To zalezy, czy patrzymy na to z teoretycznego, czy praktycznego punktu widzenia :).
Skoro tak latwo, to dlaczego zadna z badanych firm nie ma wiecej niz 8/12?
27/09/2006,
Grzegorz
Grzegorz,
Codzienne ćwiczenia nie są trudne ani z praktycznego ani z teoretycznego punktu widzenia, a niewielu ludzi je praktykuje: dlaczego?
Dlaczego wiele firm ma nierewelacyjny wynik w teście Joela? Niektóre możliwe powody, które mi przychodzą do głowy:
1. Nie słyszeli o niektórych z tych praktyk
2. Nie uważają, by były one przydatne w ich sytuacji
3. Nikt bez przykazu kierownictwa nie chce się wychylić i podjąć się ich wdrożenia
4. Wychylenie się jest traktowane jako sabotaż bieżących prac i nieprzestrzeganie dyscypliny - po co ryzykować?
5. Kierownictwo brakuje asertywności, by odsunąć choć o parę dni termin bieżących prac, by wygospodarować czas na wdrożenie tych praktyk (nawet jeśli mają wiarę, że odzyskają ten czas z nawiązką)
6. Osobom, którym się chce brakuje umiejętności lub pomysłu jak wdrożyć te praktyki (jakie zadania prezentować kandydatom? Jak zorganizować nightly-build?)
7. Nikogo nie interesuje proces tworzenia oprogramowania - wszyscy biegają z taczkami
8. Próby wprowadzania zmian nie powodzą się - po lokalnym sukcesie praktyki nie zostają utrwalone i rozszerzone na cały zespół (brak wsparcia ze strony kierownictwa? brak umiejętności przekonującego pokazania rezultatów? brak jednolitych standardów postępowania?)
Niektóre z tych punktów (3,4,5,7,8) świadczyłyby o istotnych zaniedbaniach bądź błędach "liniowego" kierownictwa. To może być cenna wskazówka dla młodych menedżerów :)
Inne sugestie?
Pozdrawiam,
Marek
Codzienne ćwiczenia nie są trudne ani z praktycznego ani z teoretycznego punktu widzenia, a niewielu ludzi je praktykuje: dlaczego?
Dlaczego wiele firm ma nierewelacyjny wynik w teście Joela? Niektóre możliwe powody, które mi przychodzą do głowy:
1. Nie słyszeli o niektórych z tych praktyk
2. Nie uważają, by były one przydatne w ich sytuacji
3. Nikt bez przykazu kierownictwa nie chce się wychylić i podjąć się ich wdrożenia
4. Wychylenie się jest traktowane jako sabotaż bieżących prac i nieprzestrzeganie dyscypliny - po co ryzykować?
5. Kierownictwo brakuje asertywności, by odsunąć choć o parę dni termin bieżących prac, by wygospodarować czas na wdrożenie tych praktyk (nawet jeśli mają wiarę, że odzyskają ten czas z nawiązką)
6. Osobom, którym się chce brakuje umiejętności lub pomysłu jak wdrożyć te praktyki (jakie zadania prezentować kandydatom? Jak zorganizować nightly-build?)
7. Nikogo nie interesuje proces tworzenia oprogramowania - wszyscy biegają z taczkami
8. Próby wprowadzania zmian nie powodzą się - po lokalnym sukcesie praktyki nie zostają utrwalone i rozszerzone na cały zespół (brak wsparcia ze strony kierownictwa? brak umiejętności przekonującego pokazania rezultatów? brak jednolitych standardów postępowania?)
Niektóre z tych punktów (3,4,5,7,8) świadczyłyby o istotnych zaniedbaniach bądź błędach "liniowego" kierownictwa. To może być cenna wskazówka dla młodych menedżerów :)
Inne sugestie?
Pozdrawiam,
Marek
28/09/2006,
Marek Rafalowicz
Marku,
Ja to widze tak:
* brak czasu,
* lenistwo,
* niechec do zmian.
Moze niekoniecznie w tej kolejnosci.
Wiem, ze mozna to znacznie lepiej ujac w slowa i zdania, aby nie brzmialo tak banalnie, ale *prawda jest banalna*.
Mysle, ze nie ma co rak zalamywac nad zastanym stanem.
W koncu nie chodzi o to, aby miec wynik 12/12, ale zeby:
* ukonczyc projekt w terminie i budzecie,
* nie obciac za bardzo pierwotnej funkcjonalnosci,
* klient byl zadowolony,
* zespol byl w stanie zrealizowac, w tym samym gronie, nastepny projekt (i zrobic to tak samo dobrze, jesli nie lepiej).
Ja to widze tak:
* brak czasu,
* lenistwo,
* niechec do zmian.
Moze niekoniecznie w tej kolejnosci.
Wiem, ze mozna to znacznie lepiej ujac w slowa i zdania, aby nie brzmialo tak banalnie, ale *prawda jest banalna*.
Mysle, ze nie ma co rak zalamywac nad zastanym stanem.
W koncu nie chodzi o to, aby miec wynik 12/12, ale zeby:
* ukonczyc projekt w terminie i budzecie,
* nie obciac za bardzo pierwotnej funkcjonalnosci,
* klient byl zadowolony,
* zespol byl w stanie zrealizowac, w tym samym gronie, nastepny projekt (i zrobic to tak samo dobrze, jesli nie lepiej).
02/10/2006,
Grzegorz
@Marek
Co do studiów SPIK - są to studia psychologiczne (taki otrzymuje się dyplom). Program jest rozszerzony o elementy informatyki i rzeczy z pogranicza - np. użyteczność i projektowanie interakcji.
Doświadczenie wykładowców jest spore - w części informatycznej są to zwykle informatycy posiadający doświadczenie w wielu projektach, dzięki czemu są w stanie wskazać, które elementy psychologii mogą realnie takie projekty wspomóc.
Do tego dochodzą powiązane kursy z psychologii powiązane tematycznie z kwestiami użyteczności iu projektowania - tu szczególnie cenna jest psychologia poznawcza, wykład był prowadzony przez jednego z lepszych profesorów w tej dziedzinie - prof. Maruszewskiego.
Co do praktycznych działań to mi zdarzyło się poznać chociażby metodę Card Sorting na badaniach strony MultiBanku, projektować troszkę dla akcji "szkolenie z internetem tp" (TP/Borland) i pewnie coś jeszcze. Pamiętam też, że inny zespół robił coś dla Microsoft, jeszcze inny dla Gadu-Gadu. Robiliśmy też dużo praktycznych ćwiczeń, np. pełny projekt softu do raportowania na PDA, własne audyty Usability itd. Nie zawsze to były jakieś wielkie rzeczy, ale trochę kontaktu z realnymi problemami mozna było odczuć :)
Faktem jest, że wydział jest stosunkowo młody i jeszcze sporo rzeczy się kształtuje i pewne rzeczy chciałoby się poprawić, ale generalnie jestem bardzo zadowolony z faktu ukończenia tego kierunku - mnóstwo wiedzy i umiejętności tam nabytych przydaje mi się w trakcie mojej obecnej działalności.
Co do studiów SPIK - są to studia psychologiczne (taki otrzymuje się dyplom). Program jest rozszerzony o elementy informatyki i rzeczy z pogranicza - np. użyteczność i projektowanie interakcji.
Doświadczenie wykładowców jest spore - w części informatycznej są to zwykle informatycy posiadający doświadczenie w wielu projektach, dzięki czemu są w stanie wskazać, które elementy psychologii mogą realnie takie projekty wspomóc.
Do tego dochodzą powiązane kursy z psychologii powiązane tematycznie z kwestiami użyteczności iu projektowania - tu szczególnie cenna jest psychologia poznawcza, wykład był prowadzony przez jednego z lepszych profesorów w tej dziedzinie - prof. Maruszewskiego.
Co do praktycznych działań to mi zdarzyło się poznać chociażby metodę Card Sorting na badaniach strony MultiBanku, projektować troszkę dla akcji "szkolenie z internetem tp" (TP/Borland) i pewnie coś jeszcze. Pamiętam też, że inny zespół robił coś dla Microsoft, jeszcze inny dla Gadu-Gadu. Robiliśmy też dużo praktycznych ćwiczeń, np. pełny projekt softu do raportowania na PDA, własne audyty Usability itd. Nie zawsze to były jakieś wielkie rzeczy, ale trochę kontaktu z realnymi problemami mozna było odczuć :)
Faktem jest, że wydział jest stosunkowo młody i jeszcze sporo rzeczy się kształtuje i pewne rzeczy chciałoby się poprawić, ale generalnie jestem bardzo zadowolony z faktu ukończenia tego kierunku - mnóstwo wiedzy i umiejętności tam nabytych przydaje mi się w trakcie mojej obecnej działalności.
08/10/2006,
Wojciech Kuśmierek
To niesamowite, ale w maju 2007 roku wykonałem bardzo podobne badanie na mniejszą skalę. Moją motywacją była głównie weryfikacja stwierdzenia Joela, że wynik 10 i poniżej powoduje konieczność wprowadzenia natychmiastowych działań naprawczych. Dopiero kiedy zweryfikowałem, że ja i moi koledzy pracujemy w firmach, w których wyniki testu oscylują wokół wartości 4 - 8 stwierdziłem, że widocznie amerykański rynek IT jesto nieco bardziej specyficzny. Z drugiej strony firmy na poziomie 4 różniły się znacznie od tych na poziomie 8 i cyferki "werbalizują" to uczucie namacalnie pokazując słabe punkty.
Pierwszy wykres spodobał mi się do tego stopnia, że "odkopałem" swojego archiwalnego Excela. W moim przypadku po dyskusjach zamiast prostego tak/nie dopuszczałem odpowiedzi "rozmyte". 5 zupełnie różnych firm uzyskało wyniki 5, 8.5, 8, 7.5, 4. Wykonałem właśnie krótkie podsumowanie na wzór pierwszego wykresu:
1. 4/5
2. 3/5
3. 0,5/5
4. 4/5
5. 3/5
6. 3/5
7. 3/5
8. 2.5/5
9. 3/5
10. 1/5
11. 2/5
12. 0/5
Z jednej strony mamy dość podobne wnioski - najlepiej widać to przy pytaniu 12. Co ciekawe... Istnieje wiele materiałów, które mówią o tym, że należy się komunikować, ale chyba nigdzie nikt nie pisze jak doprowadzić do tego, żeby ludzie się "wartościowo" komunikowali. Pamiętam, że gdzieś kiedyś czytałem o technice podobnej do "hallway usability test", ale mimo starań nie odnalazłem "na gorąco" tego fragmentu. Stawiam piwo na "The Art of Project Management" Berkuna. Reczywiście w polskich realiach "gadanie" programistów jest zbyt często traktowane jako "marnowanie czasu" szczególnie gdy przynależą do zespołów podlegających dwóm, różnym "supervisorom"/"strefom wpływów", a terminy częściej gonią czy są gonione. Niestety recepta nie jest prosta i czasami TRZEBA ukrucać akademickie dyskusje. Obopólny wynik 0 nie nastraja zbyt optymistycznie, ale... jest światełko w tunelu i zdarzają się firmy (szczególnie małe), które mają osiągnięcia na tym polu.
Z drugiej strony jednak miewałem nieco odmienne wyniki testu Joel'a. Przy pytaniu 11 częściej przydarzało mi się, że programiście pisali programy na rozmowach kwalifikacyjnych i wiem o tym, że ten współczynnik wyraźnie się zwiększył w przeciągu ostatniego 1-2 lat (pewnie m.in. dzięki Joelowi, którego przeklinają teraz wszyscy programiści chodzący na spotkania rekrutacyjne).
Suma sumarum jednak zgadzam się z Grzegorzem, że 12/12 nie powinno być celem samym w sobie i priorytetem zawsze powinno być wykonanie projektu w budżecie, na czas i przy w miarę zadowolonym kliencie (niektórych zadowolić się nie da :) ). Jeśli jednak jest czas i możliwość na ulepszenie procesu wytwórczego to test Joel'a jest świetnym sposobem na wytyczenie kierunku zmian. Ja właśnie odgrzewam tego kotleta i jestem zaskoczony tym jak bardzo jest on aktualny mimo upływu lat (a dokładniej dwóch) ;)
BTW, Gratuluje świetnego bloga!
Pierwszy wykres spodobał mi się do tego stopnia, że "odkopałem" swojego archiwalnego Excela. W moim przypadku po dyskusjach zamiast prostego tak/nie dopuszczałem odpowiedzi "rozmyte". 5 zupełnie różnych firm uzyskało wyniki 5, 8.5, 8, 7.5, 4. Wykonałem właśnie krótkie podsumowanie na wzór pierwszego wykresu:
1. 4/5
2. 3/5
3. 0,5/5
4. 4/5
5. 3/5
6. 3/5
7. 3/5
8. 2.5/5
9. 3/5
10. 1/5
11. 2/5
12. 0/5
Z jednej strony mamy dość podobne wnioski - najlepiej widać to przy pytaniu 12. Co ciekawe... Istnieje wiele materiałów, które mówią o tym, że należy się komunikować, ale chyba nigdzie nikt nie pisze jak doprowadzić do tego, żeby ludzie się "wartościowo" komunikowali. Pamiętam, że gdzieś kiedyś czytałem o technice podobnej do "hallway usability test", ale mimo starań nie odnalazłem "na gorąco" tego fragmentu. Stawiam piwo na "The Art of Project Management" Berkuna. Reczywiście w polskich realiach "gadanie" programistów jest zbyt często traktowane jako "marnowanie czasu" szczególnie gdy przynależą do zespołów podlegających dwóm, różnym "supervisorom"/"strefom wpływów", a terminy częściej gonią czy są gonione. Niestety recepta nie jest prosta i czasami TRZEBA ukrucać akademickie dyskusje. Obopólny wynik 0 nie nastraja zbyt optymistycznie, ale... jest światełko w tunelu i zdarzają się firmy (szczególnie małe), które mają osiągnięcia na tym polu.
Z drugiej strony jednak miewałem nieco odmienne wyniki testu Joel'a. Przy pytaniu 11 częściej przydarzało mi się, że programiście pisali programy na rozmowach kwalifikacyjnych i wiem o tym, że ten współczynnik wyraźnie się zwiększył w przeciągu ostatniego 1-2 lat (pewnie m.in. dzięki Joelowi, którego przeklinają teraz wszyscy programiści chodzący na spotkania rekrutacyjne).
Suma sumarum jednak zgadzam się z Grzegorzem, że 12/12 nie powinno być celem samym w sobie i priorytetem zawsze powinno być wykonanie projektu w budżecie, na czas i przy w miarę zadowolonym kliencie (niektórych zadowolić się nie da :) ). Jeśli jednak jest czas i możliwość na ulepszenie procesu wytwórczego to test Joel'a jest świetnym sposobem na wytyczenie kierunku zmian. Ja właśnie odgrzewam tego kotleta i jestem zaskoczony tym jak bardzo jest on aktualny mimo upływu lat (a dokładniej dwóch) ;)
BTW, Gratuluje świetnego bloga!
15/09/2008,
Adam Koszlajda
