Archiwa blogu

Jeszcze o USOSie (i nie tylko) – uniwersytet jako code/space

punkt_log copyPoprzedni wpis zakończyłam P.S., który zaczął się na tyle rozrastać, że dostarczył materiału na kontynuację. Niniejszym przenoszę więc P.S.:

P.S. W wyniku małej dyskusji pod niniejszym wpisem (za którą bardzo dziękuję!) oraz szybkiej akcji na FB (dziękuję!) dowiedziałam, się, że USOS był (jest?) przedmiotem zainteresowania Krzysztofa Abriszewskiego. Opublikował poświęcony mu tekst Jak nowe media tworzą nowe środowisko. Przypadek USOSa w książce Nowe media w systemie komunikowania: edukacja i cyfryzacja, red. Marek Jeziński, Toruń: Wydawnictwo Adam Marszałek, 2011, s. 76-94. Tekst jest dostępny w repozytorium UMK, tutaj.

Abriszewski bardzo interesująco analizuje moment wprowadzenia USOSa – patrząc na datę publikacji domyślam się jednak, że była to faza pionierska (zważywszy, ile czasu mija od napisania tekstu do jego publikacji w formie książkowej lub czasopiśmienniczej). Tekst jednak się nie zdezaktualizował przynajmniej z paru powodów. Jednym z nich jest demonstracja, jak złożonym procesem jest w gruncie rzeczy „wdrażanie” rozwiązań o charakterze pozornie czysto technicznym. W tym sensie mój poprzedni wpis cechuje się oczywiście nieuniknionymi uproszczeniami – dotyczy jednak nieco innego aspektu sprawy. Jak już wspomniałam, mała dyskusja pod poprzednim postem oraz na FB (za które bardzo dziękuję Andrzejowi W. Nowakowi, Karolowi Krzyżosiakowi i Janowi Argasińskiemu) przyniosła kilka innych tropów i mam nadzieję, że temat doczeka się rozwinięcia – może ktoś skorzysta z inspiracji, bo moja kolejka pisarska jest na razie za długa 🙂 W tekście Abriszewskiego najbardziej zainteresowały mnie kwestie związane z niestabilnością technologii, w tym również informatycznych (tzn. zazwyczaj postrzegamy je jako gotowy produkt, który nie ma swojej historii, zwłaszcza zaś historii negocjacji z użytkownikami. Jest to także oczywiście pochodna pewnego typu projektowania (to znacznie większy temat) – artykuł pokazuje zresztą, jak ciekawe rzeczy można dostrzec traktując technologię jako „wiązkę procesów”. W przypadku oprogramowania takiego, jak USOS, mówimy o groupware, czyli oprogramowaniu do pracy grupowej. Abriszewski przywołuje nienowy już dzisiaj artykuł Martina Lea oraz Richarda Giordano dotyczący groupware’ów (kiedyś, w zamierzchłych czasach początku pierwszej dekady XXI wieku nieustanie czytało się o innowacyjnych rozwiązań, które w efekcie miały dać właśnie wirtualne grupowe środowiska pracy – tak, jak dzisiaj czyta się o internecie rzeczy). Dzisiaj groupware’y stały się jednak naszym chlebem powszednim (bo nie tylko USOS, ale w przypadku mojego uniwersytetu oparta na Moodle e-learningowa platforma Pegaz oraz system CMSu, w którym tworzone są strony internetowe). Zresztą, nic tak wyraźnie nie pokazuje wiatru zmian w tym zakresie, jak fakt, że wszystkie rozwiązania e-learningowe oraz samo hasło e-learning (tak „gorące” jeszcze kilka lat temu) dzisiaj stały się ywposażeniem lamusa. Nawet MOOC straciły jakby swoją moc, choć moduły interaktywne to może być pewne zagrożenie (ech, tematy, którymi warto się zająć, leżą na ulicy; aż się nie chce wierzyć, że wszyscy w kółko chcą tylko krytykować Facebooka).

Słowem, nie tylko USOS domaga się pogłębionej refleksji, ale cały szereg systemów informatycznych, na których opiera się dzisiaj academia – i upieram się przy tym, że jakkolwiek strefa negocjacji istnieje, to jednak coraz mniej jest to wspomaganie, a coraz bardziej uniwersytet zamienia się w formę code/space, o której pisali Kitchin i Dodge wspomniani przez mnie w poprzednim wpisie. To zaś oznacza, że przestrzeń i kod wzajemnie się konstytuują, ale funkcjonowanie przestrzeni w dużej mierze zależy od kodu (stopień tej zależności może być zróżnicowany; wszyscy jednak zgodzimy się, że większość polskich uniwersytetów bez USOSa nie jest w stanie wypełniać najistotniejszych funkcji) – co nie oznacza jednak, że powstający amalgamat nie jest podatny na nieciągłości, negocjacje i pękniecia. Nie jest to więc determinizm (i, na marginesie, odruchowe przywoływanie w tym kontekście McLuhana domagałoby się na tyle pogłębionego uzasadnienia, że traci na sensowności). Jak piszą Kitchin i Dodge:

” (…) code/space [proponuję kod/przestrzeń zupełnie roboczo] jest ciągle w stanie wyłaniania się, wytwarzany w indywidualnych aktach performatywnych oraz interakcjach społecznych, które są mediowane (świadomie lub nieświadomie) w relacji do wzajemnego konstytuowania się kodu/przestrzeni. W tym sensie, kod/przestrzenie mogą być rozumiane i konceptualizowane jako relacyjne i emergentne obszary, w ktorych oprogramowanie dostarcza ramy dla tego, co się odsłania, ale go nie determinuje.” (s. 74)

I dlatego właśnie interesuje mnie kwestia historii, i to ona domagałaby się poważniejszego opisu. O USOSie wiadomo, że powstał w 2000 roku (!) na Uniwersytecie WArszawskim i że od tamtej pory rozwija się w ramach konsorcjum. Dokumentacja jest oczywiście dostępna. Prawdziwa kopalnia wiedzy kryje się jednak w dokumentacji wdrożeniowej, co wymagałoby pogłębionej, uważnej lektury, do której warto byłoby dodać badania o charakterze etnograficznym z wdrożenia USOSa na poszczególnych uczelniach. Co być może dałoby odpowiedź na pytanie, jak przebiegają procesy negocjacji, gdzie zachodzą nieciągłości, w jakim stopniu system jest otwarty na emergencję i czy istotnie jest tak sztywny, jak się wydaje, czy też jest to tylko taktyka poszczególnych pionów i poziomów administracyjnych.

Przepis na ciekawy artykuł (a może książkę?) gotowy, uprzejmie proszę choćby o podziękowania za inspirację w przypadku realizacji 🙂

W tym wszystkim, co często czytamy o kryzysie akademii ten obszar – kwestia przemiany uniwersytetu w kod/przestrzeń jest zupełnie nieobecna, choć groupware’y ramują nasze codzienne doświadczenie w stopniu znacznie większym, niż nam się wydaje.

Poza cyfrową humanistykę, albo zautomatyzowane zarządzanie w korpouni

usos copyPiątkowe biuletyny z zarządzeniami administracji trafiające do skrzynek mailowych pracowników nie są zazwyczaj „gorącą” lekturą – podejrzewam, że większość z nas kasuje je bez namysłu (a to błąd; bardzo często sprytnie ukryte w ogłoszeniach zamieszczonych na BIPie są rzeczy Bardzo Ważne i Fundamentalne). Przyznaję, czasem zadaję sobie trud otwarcia kilku plików pdf, w których – jak podejrzewam – mogą być ukryte miny, na których mój reżim czasowy wywraca się później do góry nogami. Tym razem to nie mina, tym razem oficjalnie weszliśmy w epokę zautomatyzowanego zarządzania. W jednym z „pism okólnych” czytamy: „Ze względu na zautomatyzowanie przebiegu procesu planowania i rozliczania zajęć dydaktycznych przy wsparciu systemów USOS oraz SAP, zobowiązuje się wszystkie jednostki do terminowego i poprawnego wprowadzania danych do USOS, a w szczególności (…)” Tu oczywiście następuje wyliczenie owych szczególności. I, zaiste, zautomatyzowany ten przebieg jest w pełni, ech. To jedna z cech korpouni, którą określiłabym jako zasadniczą – skrajny brak elastyczności. W przypadku „zarządzania przebiegiem” polega to choćby na tym, że nie mam uprawnień administracyjnych pozwalających mi na przykład na dodawanie studentów do grupy. Wszystko – wbrew pozorom – w USOSie jest bowiem skrajnie scentralizowane, włącznie z funkcjonalnościami na poziomie globalnym (co staje się upiorne dla wszystkich, którzy próbowali kiedykolwiek modułowego programu studiów). Nie nad USOSem jednak chciałabym się rozwodzić, który jest jedną z większych porażek informatycznych, z jakimi miałam w życiu do czynienia (przynajmniej w zakresie projektowania user experience :-).

Chodzi – jak zwykle – o kwestię ogólniejszej natury. W książce Code/Space. Software and Everyday Life Roba Kitchina i i Martina Dodge’a znalazłam fragmenty, które doskonale opisują rzeczywistość uniwersytetu zmierzającego w stronę korpouni, opartego przezde wszystkim na automatyzacji zarządzania. Przytoczę dłuższe fragmenty z książki, która jest zresztą świetnym wprowadzeniem do tego, jak oprogramowania przenika i organizuje nasze życie codzienne (często na poziomie, który znika z pola widzenia i z naszej świadomości, bo jest tak błahy, banalny i zwyczajny, że natychmiast się doń przyzwyczajamy). Otóż otwierając zdaniem mówiącym o tym, że „oprogramowanie jest kluczowym aktorem w tworzeniu społeczeństwa kontroli”, Kitchin i Dodge kontynuują, powołując się na artykuł Philipa E. Agre „Surveillance and capture: two models of privacy” (z – bagatela! – 1994 roku):

„(…) mechanizmy, za pomocą których dane są produkowane

[Kitchin i Dodge konsekwentnie posługują się terminem capta w miejsce data – co Kitchin uzasadnia w swojej książce z ubiegłego roku, The Data Revolution. Big Data, Open Data, Data Infrastructures and Their Consequences, lekturze równie ważnej dla cyfrowych humanistow, jak Code/Space],

w coraz większym stopniu stają się integralną częścią systemu, który mają monitorować i regulować – te mechanizmy zaś w efekcie redefiniują i rekonfigurują ów system, często w czasie realnym.” (s. 86).

Przykłady przytaczane przez autorów dotyczą raczej zupełnie innej domeny: tak jest na przykład w przypadku skanowania produktów przez pracowniczki kas w hipermarkecie (to wciąż sfeminizowana, nisko opłacana praca z gatunku tych najbardziej „śmieciowych” i podatnych na wyzysk). To coś więcej niż tylko akt sprzedaży – z danych można odczytać częstotliwość i przebiegi czasowych poszczególnych operacji każdej pracownicy. System służy oczywiście do zautomatyzowanej sprzedaży, ale jednocześnie pozwala monitorować pracowników i ustalać ramy ich „efektywności”. Kitchin i Dodge podsumowują:

„Innymi słowy, zamiast monitorować pracownika za pomocą zewnętrznego systemu nadzoru, który wzmacnia samodyscyplinę, sprawdza się pracownika stosując proces całkowicie zinternalizowany, który w aktywny sposób kształtuje jego efektywność.”(s. 87).

Wszystkie procedury, które mamy do wykonania w USOSie (ocenianie, wypełnianie protokołów, ich zatwierdzanie, drukowanie i dostarczanie) można opisać za pomocą „gramatyki działania” (określenie Philipe’a Agre), czyli

„sformalizowanego zestawu zasad, które zapewniają, że poszczególne zadania są wypełniane w określony sposób, biorąc pod uwagę pewne kryteria i dane na wejściu.” (s. 87).

Zatrzymam się, póki co, w tym miejscu (pozostawiając na boku bardzo interesujące terminy „cyfrowego cienia” i „cyfrowego śladu” – u Kitchina i Dodge’a odpowiednio „capta shadow” i „capta trail” (s. 90). Czy wiemy, co się z nimi w związku z naszymi operacjami w USOSie dzieje? Nie. Nie w dobie masywnego handlu danymi na wielu różnych poziomach – i to może być niepokojące.

Być moze jest więc tak, że biurokratyzacja, na którą wszyscy narzekamy i która, jak czujemy podskórnie, jest absolutnie przytłaczająca – jest pochodną właśnie owych „gramatyk działania”, bez których oparty na oprogramowaniu, zarządzany automatycznie uniwersytet już nie moze się obejść. „Oparty”, nie zaś zaledwie „wspomagany”, jak łudzi nazwa „Zintegrowanego Informatycznego Systemu Wspomagania Zarządzania Uczelnią”. (Tak, tak się to nazywa).

Bo tego uczy kulturoznawcze myślenie o mediach – nie są „tylko” narzędziami, nie są przezroczytse ani niewinne (i w tym kontekscie historia korporacyjnego SAPa jawi się szczególnie interesująco). Cyfrowa humanistyka? Zaczyna się od refleksyjnego logowania do USOSa.