Die Gruppenprojekt Revision

Po dwóch dekadach prowadzeniach bloga można już polemizować z własnymi wpisami. Czasem nawet trzeba.

W czasie studiów na Wydziale ETI PG byłem pierwszym rocznikiem, na którym testowano nową formę zajęć – Projekt Grupowy. Odebrałem go źle i moje negatywne nastawienie utrzymało się długo. Dzisiaj – z bagażem doświadczeń – widzę w jak dużym błędzie byłem.

Z tego co pamiętam, Politechnika wprowadziła Projekt Grupowy (PG wprowadziła PG…) bo ktoś zorientował się, że brakuje przekazywania studentom umiejętności przydatnych w prawdziwym życiu/pracy:

• pracy w grupie z podziałem obowiązków

• tworzenia dokumentacji do rozwiązań

• prezentowania, co się osiągnęło („sprzedania się”)

Dzisiaj zgadzam się, że powyższe są istotnymi zdolnościami. Samo ogarnięcie w technologii nie wystarcza. Wtedy byłem może nie idealistą, ale fascynatem technologii, bawiącym się ciekawymi rozwiązaniami i robiącym nowe rzeczy bo mogłem i bo były intrygujące.

Ciekawe jest, że zżymałem się na stwierdzenie „głównym zadaniem sieci telekomunikacyjnej jest przynoszenie zysku operatorowi ”. Well, duh! Dzisiaj potrzeba business case wydaje się jasna jak Słońce. Owszem, fajnie jest wymyślać nowe rzeczy, bo tak. Ale świat jest tak skonstruowany, że poza środowiskiem naukowym wszystko musi przynosić €€€. Nie ma sensu wydawanie milionów na sieć, aby popatrzeć jak ładnie pakiety się trasują. Rozwiązanie musi rozwiązywać czyjś problem i ta na tyle skutecznie, żeby takie ktosie były skłonne płacić za utrzymanie tego rozwiązania.

Do czego prowadzi oderwanie od biznesu mam niestety przykład w obecnej firmie. Po zainwestowaniu kilku lat pracy i stworzeniu systemu wg założeń dopiero zaczyna się szukanie komu i po co miałby być potrzebny. Brak jasno określonego „jaki jest nasz cel, klient” powoduje, że ludzie nie wiedzą po co robią, nie czują sensu i odchodzą. Jak nie wiadomo do czego dążymy, jakie są warunki dostarczenia bądź zakończenia projektu, to nie można odpowiedzieć ile jeszcze. A niepewność rozwala każde poczucie bezpieczeństwa.

No, ale to dygresja. Przy Projekcie Grupowym jeżyłem się też z powodu słownictwa w instrukcji. Niesłusznie. Może sformułowania nie były najzgrabniejsze, ale nie pozostawiały niedopowiedzeń. Było po prostu zostanie dostarczony, a nie jakieś powinien, musi, itp. Bo co, jeśli nie? Zamiast szukać odpowiedzi na przypadek nie, lepiej go w ogóle nie dopuścić. Teraz zgadzam się z takim podejściem.

Doświadczenie pokazało mi też jak powyższy problem wypływa w przypadku kiepskiego prawa. Mamy np. w ustawie o wspólnotach stwierdzenia, że Zarząd na wniosek zwołuje zebranie, albo że powinien uzyskać absolutorium. A co jeśli nie zwoła lub nie uzyska? Absolutnie nic. Brak penalizacji za niewywiązanie się powoduje, że takie zapisy są martwe, nie mają konsekwencji.

Moje studenckie oburzenie porównałbym do dramy, gdy do szkół niższego stopnia wprowadzono egzaminy opierające się na zrobieniu prezentacji. Że to niby spłycanie i uczenie kolorowania slajdów zamiast twardych konkretów. Tak się jednak składa, że prezentacja osiągnięć to cholernie ważna umiejętność i element całości.

Można sobie siedzieć w piwnicy i robić cuda, ale bez wyjścia z nimi do ludzi umrą razem z autorem. Warto zauważyć, że za początek Linuksa przyjmujemy nie chwilę napisania pierwszej linijki kodu. Obchodzimy za to dzień, w którym 30 lat temu Torvalds wysłał posta, do ludzi, że ma taki hobbistyczny projekt, który nigdy nie będzie tak duży i profesjonalny jak GNU.