Piotr Kałuski

Przez hotline\service desk rozumiem telefoniczne wsparcie użytkownika, jakie oferuje wiele firm.
Muszę od razu zaznaczyć, że nie chcę tu krytykować osób pracujących w service deskach. Wiem, że często są to młodzi ludzie, inteligentni i pełni dobrych chęci, ale niedoświadczeni.
Z drugiej strony nie ulega wątpliwości, że dość często dzwoniąc po pomoc otrzymujemy ją tylko dla najprostszych problemów. Przy problemach bardziej złożonych, konsultanci są często bezsilni. Z czego to wynika? Otóż w przypadku wielu patologii, powodem ich występowania jest lekceważenie przez organizację jakiejś głębszej wiedzy. Ale w temacie o którym mówię, jest odwrotnie – jest jak jest ponieważ firmy stosują się do wskazań powszechnie znanej metodologii. Chodzi o ITIL. ITIL definiuje Service Desk jako punkt komunikacji z użytkownikiem przy zakłóceniach w działaniu usługi, wnioskach o usługę i niektórych wnioskach o zmianę. Otóż ITIL rekomenduje (jest nawet pytanie egzaminacyjne na ten temat), aby Service Desk był pierwszym miejscem pracy (entry level) dla nowych pracowników w organizacji.
Czy ktoś ma jeszcze jakieś pytania?
Kiedy następnym razem zirytuje nas mała wiedzy biedaka z service desku, nie pomstujmy, że mają tam bałagan i praca jest niezorganizowana. Wręcz przeciwnie – tam jest wdrożony ITIL .

W moim poprzednim wpisie, w ramach dyskusji jak otwarte na nowości jest IT, mówiłem o tym, że często IT bawi się nowoczesnymi zabawkami nie do końca je rozumiejąc. Teraz będę chciał trochę powiedzieć na temat otwartości na zmiany w metodach i organizacji pracy. Mam wrażenie, że w tym obszarze jest jeszcze gorzej.

To, że nie ma uniwersalnych metod, które na wszystko są dobre, to już wydaje się wiedzieć każdy. Każdy (lub prawie każdy) wie, że żeby efektywnie pracować, trzeba dobrać właściwą metodę dopasowaną do konkretnych warunków i kontekstu. Jednak dużo mniej osób zauważa, że te warunki i ten kontekst ciągle się zmieniają. To co dla nas działało bardzo dobrze rok temu, dzisiaj może być kulą u nogi, upośledzającą naszą wydajność. Cykl życia rozwoju oprogramowania założony na początku, kiedy mamy 50 tys klientów i operujemy na powoli rozwijającym się rynku, może się przestać sprawdzać kiedy liczba klientów urośnie do 5 mln i rynek zacznie się rozwijać 10 razy szybciej.

Zjawisko zmiany kontekstu jest w firmach i działach IT powszechne. I nie jest niczym złym, że ono występuje – jest to naturalną konsekwencją faktu, że rynek i jego potrzeby ewoluują. Nie jest też dowodem nieefektywności danej organizacji, że ją ta zmiana kontekstu nie raz zaskakuje. Czasami zmiany są trudne do przewidzenia i lepiej jest poczekać, aż problem wystąpi, żeby go zrozumieć i wtedy sobie z nim dobrze poradzić, zamiast gubić się w domysłach (co nie znaczy, że nie należy planować i zarządzać ryzykiem).

To co jest problemem i moim zdaniem błędem popełnianym w organizacjach to kurczowe trzymanie się raz ustalonych w przeszłości metod pracy. Kiedy jakiś problem narasta na tyle, że nie można udawać, że go nie ma i trzeba coś zmienić, dość często, zamiast zmienić metody pracy, problemy organizacyjne próbuje się naprawić kupując nowe narzędzia i technologie. Dewelopment nowych funkcjonalności w istniejącym systemie finansowo-księgowym zajmuje coraz więcej czasu? Kupujemy sobie nowocześniejszy system finansowo-księgowy. Nie jesteśmy w stanie dojść do ładu z interfejsami między aplikacjami, których mamy u siebie całą hordę? Kupujemy sobie ESB. Testy się wloką i kosztują coraz więcej? Kupujemy narzędzie to automatyzacji testów.

A tymczasem większość z tych problemów bierze się z tego, że mamy źle zorganizowaną pracę. Często powtarzam (z całą świadomością, że jest w tym odrobina przesady), że już od co najmniej 8 lat istnieją stabilne, dojrzałe narzędzia informatyczne pozwalające zaspokoić większość potrzeb. A więc problem nie leży w niedoskonałości technologii tylko w umiejętnym jej wykorzystaniu. Warto tu jeszcze nadmienić, że aby zaspokoić swoje potrzeby za pomocą danej technologii, trzeba spełnić jeden bardzo ważny warunek – trzeba te narzędzia DOBRZE poznać. A że tego nie robimy to pisałem w poprzednim wpisie.

Skąd się bierze ta chęć rozwiązywania problemów za pomocą narzędzi i jednoczesna niechęć do zmian metod pracy? U podstaw niechęci do zmian metod pracy leży konformizm, lęk przed odpowiedzialnością i przed zmianą jako taką. A skąd chęć do zakupu narzędzi? Jeżeli kupujemy nowe narzędzie renomowanej firmy, handlowcy dołożą wszelkich starań, żeby nas i naszych przełożonych przekonać, że jest to najmądrzejsza decyzja w naszym życiu. Nie ulega wątpliwości, że po zakupie narzędzia, które w trakcie prezentacji samo rozwiązuje nasze problemy i prawie że wyprzedza nasze zachcianki, wszystkie nasze problemy znikną i będziemy mieli wokół siebie samych przyjaciół. Dodatkowo mamy, dającą poczucie bezpieczeństwa, świadomość, że jak się okaże, że nic nam prezentowane narzędzie nie pomogło to przynajmniej mamy na kogo zwalić (“Nobody ever got fired for buying IBM equipment” jak mówił legendarny już dziś slogan Big Blue). Problem był tak duży, że nawet dobre narzędzie renowanej firmy nie pomogło. My zrobiliśmy wszystko co w naszej mocy. Ale czy na pewno nie pomogło? Może jak się sporządzi odpowiednie statystyki i wykresy (z pomocą konsultanta z firmy produkującej narzędzie) to się okaże, że jest lepiej i że narzędzie pomogło (pomimo, iż nam i otoczeniu, wydaje się, że zamiast być lepiej jest jeszcze gorzej). Poza tym po zakupie narzędzia i wydaniu ciężkich pieniędzy, cały łańcuszek osób odpowiedzialnych za zakup jest spragniony wiadomości, że narzędzie pomogło. I zapytani przez dostawcę, przełożonego, lub następnego potencjalnego klienta, czy są zadowoleni i czy pomogło odpowiedzą skwapliwie “TAK”. A zrobią tak dlatego, że “TAK” może oznaczać – dobrze zainwestowaliśmy kupę kasy i teraz czerpiemy z tego korzyści które dają nam przewagę nad konkurencją – a może też oznaczać – bo ja wiem, nie mam zdania – lub coś jeszcze innego.  W przeciwieństwie do poetyckiej wieloznaczności słowa “TAK”, “NIE” oznacza niezawodnie – daliśmy się zrobić w balona i wyrzuciliśmy w błoto kupę kasy. Ze zrozumiałych względów, odpowiedź “NIE” wymaga dużo więcej odwagi i jest dużo mniej prawdopodobna.

Jeżeli chcemy zmienić metody pracy a dokładniej organizację pracy, to bierzemy odpowiedzialność na siebie. Skoro my zaczęliśmy ten cały zamęt i zaczęliśmy zmieniać uświęcony tradycją proces, to jeżeli wyniki będą złe, wszyscy z radością obwinią za to nas. Mało kto będzie nam kibicował i dobrze życzył, bo z każdym skostniałym procesem związane jest jakieś status quo, które jest korzystne dla wielu uczestników. Zmiany mogą ten stan dla poszczególnych jednostek zmienić na gorszy. W skrajnych przypadkach może się nagle okazać, że jakaś grupa osób lub jakiś dostawca zewnętrzny nie są już potrzebni. Bardzo łatwo jest ich potępić za kosztowne dla organizacji sabotowanie zmian, ale stracić pracę 5 lat przed emeryturą to naprawdę nie są żarty. Ale nawet Ci, którzy nie będę się bali utraty pracy, mogą nie chcieć zmian ot tak po prostu, bo po co coś zmieniać, skoro tak jak jest, jest DLA NICH dobrze. Oj, tak. Zaprawdę, zaprawdę powiadam Wam, że ten kto chce zmienić metody i organizację pracy, mało będzie miał przyjaciół. Więc albo nie rozwiązuje się problemu w ogóle, albo kupuje się narzędzie. Po zakupie okazuje się, że żeby narzędzie wdrożyć i efektywnie je wykorzystywać musimy: po pierwsze dobrze je zrozumieć, po drugie zmienić metody pracy. No ale przecież, nie chcemy zmieniać metod pracy i po to kupiliśmy narzędzie, aby nie musieć tego robić. Więc tworzymy w narzędziu jakieś koślawe adaptacje, aby przystosować je do naszych metod pracy, de facto negując metodologię, która leży u podstaw narzędzia (jeżeli takowa w ogóle jest). Efekt jest taki, że do naszego i tak już skomplikowanego środowiska, które mało kto ogarnia, dodaliśmy jeszcze jeden skomplikowany klocek, który też trzeba ogarniać. Więc koniec końców jest gorzej zamiast lepiej.

Jeżeli moje obserwacje są prawidłowe, to coraz sprawniejsza może być tylko organizacja, w której systematycznie aktualizuje się metody pracy. Aby to się działo, w organizacji musi być kultywowana świadomość konieczności takich zmian i ich dobroczynnych skutków, albo musi się znaleźć charyzmatyczny przywódca wizjoner, który zapłodni umysły innych i pociągnie ich za sobą. Bardzo jestem ciekaw, jakie są obserwacje w tym względzie moich czytelników. Chętnie bym przeczytał, jak to jest zorganizowane w firmie, w której metody pracy są rzeczywiście systematycznie ulepszane.

Niniejszym chciałbym zainicjować cykl wpisów dotyczących naszego (IT) stosunku do zmian, nowości, nowoczesności, wiedzy i metod pracy.

Gdyby się kogoś zapytać w jakiej branży ludzie są najbardziej otwarci, najbardziej elastyczni i nowocześni to IT na pewno byłaby jedną z najczęściej wymienianych.Ale czy my naprawdę jesteśmy tacy otwarci? I czy my w IT naprawdę tak dużo ŚWIADOMIE inwestujemy w nowoczesność? A może po prostu reagujemy na zmieniające się warunki zewnętrzne? Może pakujemy się w nowe technologie aby zagłuszyć wyrzuty sumienia wynikłe z braku własnej wizji jak chcemy pracować i co chcemy osiągnąć? Może wiele z wdrożeń nowoczesnych technologii to po prostu instynkt stadny i lenistwo umysłowe a nie otwartość?

Więc może to całe wrażenie, że IT jest takie nowoczesne bierze się z zabawek jakimi się ono bawi. Zabawek, których istoty działania IT tak na prawdę do końca nie rozumie. Przesadzam oczywiście, ale czy aż tak bardzo? Nie ulega wątpliwości, że IT się rozwija, staje się coraz bardziej bogate i fascynujące. Ale spójrzmy na IT jako całość, weźmy pod uwagę co i JAK robimy, co i jak robią inni wokół nas i odpowiedzmy sobie uczciwie na pytanie: Czy błyskotliwe, dobrze przemyślane koncepcje, bazujące na dogłębnym zrozumieniu zagadnienia i technologii są w IT codziennością czy rzadkimi incydentami, które ze względu na swą doniosłość są w stanie popchnąć IT mocno do przodu. Moim zdaniem niestety to drugie. I dotyczy to zarówno części wytwórczej IT (firmy tworzące narzędzia IT, software houses) jak i części wdrożeniowej (działy IT w bankach, firmach telekomunikacyjnych itd). I zapewniam, że wdrażanie oprogramowania pod względem wyzwań nie ustępuje jego wytwarzaniu. Mądre wykorzystanie dzisiejszych narzędzi jest wyzwaniem intelektualno-organizacyjnym porównywalnym z tworzeniem czegoś od zera. Mądre wykorzystanie nowoczesnego narzędzia wymaga cierpliwej nauki, wielu miesięcy prób i błędów. Bardzo często mądre i efektywne wykorzystanie danego narzędzia wymaga też zmiany metod pracy.

Zacznijmy od zagadnień związanych z tym jak się uczymy, jak poznajemy nowe rzeczy. Są firmy, które mają swoje centra badawczo rozwojowe i które zrozumieniu nowych technologii starają się poświęcić odpowiedni czas. Jednak nie zmienia to faktu, że jednym z podstawowych problemów branży IT jest to, że przeważnie nie ma czasu na dogłębne zrozumienie technologii z którą się pracuje. I od razu zilustruję to przykładem z własnego życia. Nie wiem ilu z moich czytelników zna się na programowaniu w Windowsach, dlatego w skrócie wyjaśnię problem, którego historia dotyczy (mam nadzieję, że nie zanudzę). Większość programów windowsowych składa się z modułu głównego i bibliotek, tak zwanych dll-i (dynamic link libraries). Otóż kiedy system operacyjny uruchamia dany program, ładuje go do pamięci po czym ładuje do pamięci wszystkie dll-e, z których on korzysta. System próbuje każdego dll-a załadować pod ten sam adres. To powoduje, że już przy ładowaniu drugiego dll-a system zauważa konflikt. Musi więc wyliczyć nowy adres, pod który można załadować nowego dll-a. Abstrahując od dodatkowego czasu potrzebnego na przeliczenie nowego adresu, system z pewnych powodów trzyma takiego relokowanego dll-a w pamięci w dwóch kopiach. Czyli de facto program po załadowaniu zajmuje 2 razy więcej miejsca w pamięci, niż powinien. Jakie jest na to lekarstwo? Banalnie proste. Otóż jest program, który nazywa się rebase. Program ten zapisuje w odpowiednich miejscach aplikacji, którą chcemy uruchamiać, pod jaki adres powinny być ładowane kolejne dll-e, aby uniknąć konfliktów. Informację o rebase wyczytałem w książce Richtera o programowaniu w Windowsach. Sprawdziłem. Było dokładnie tak jak pisał. Program zajmował 2 razy mniej pamięci niż przed użyciem rebase. Zacząłem więc rozmawiać na ten temat z deweloperami. Okazało, się żaden z moich rozmówców (nawet ten oznaczony jako senior windows developer) o rebase nie słyszał.

Myślę, że wielu specjalistów (nie tylko programistów) widziało w swoim życiu podobne przykłady. Na każdym kroku zachowujemy się jak daleki krewny Masztalskiego, który po wykąpaniu się po raz pierwszy w życiu w wannie, wyrwał ją z podłogi, wziął pełną na plecy i zaczął szukać miejsca gdzie mógłby wylać brudną wodę. Tworzymy w bólach koślawe, zasobożerne rozwiązania bo nie mamy czasu aby poznać naszą przysłowiową wannę na tyle, aby się dowiedzieć, że jest w niej odpływ zatkany korkiem, przez który minimalnym wysiłkiem możemy spuścić całą brudną wodę.

Wróćmy do historii z dll-ami. Co jest przyczyną takich sytuacji? Wszyscy programiści byli ignorantami, nie byli wystarczająco inteligentni czy też im się nie chciało? Nic podobnego. Wielu z nich było naprawdę zaangażowanych w to co robią. Ale większość z nich uczyła się programowania w Windowsach (sztuki bardzo trudnej) w następujący sposób – wysłano ich na 5 dni szkolenia (albo i to nie) po czym rzucono na projekt, aby pod okiem bardziej doświadczonych programistów wykonywali coraz bardziej odpowiedzialne zadania. Przeciętny absolwent informatyki jakoś się w tym odnajdzie. Bądź co bądź coś już w swoim życiu zaprogramował więc wie na czym to polega. Tworzy więc przeciętny kod – nie dlatego, że jest za mało inteligentny. Nie ma czasu, aby zgłębić zagadnienie na tyle aby pisać kod dobry. A poza tym, widzi gołym okiem, że jego kod nie jest dużo gorszy od tego, co napisali inni. A poza tym jest chwalony za to, że nie zawraca głowy i wykonuje powierzone mu zadania. Z upływem czasu zadania są coraz bardziej złożone i odpowiedzialne, aż pewnego dnia, nasz programista dostaje pod opiekę żółtodzioba, którego musi wdrożyć. Dzieli się więc z nim swoją fragmentaryczną wiedzą na tyle na ile ma czas a nie ma go dużo, bo ma status doświadczonego dewelopera, więc zajmuje się naprawdę ważnymi rzeczami. Więc żółtodziób uczy się programowania i technologii sam, patrząc na kod pisany przez takich jak on żółtodziobów. I tak to się ciągnie z pokolenia na pokolenie. A management jest zadowolony, że ma w zespołach takich bystrzaków, co to potrafią nauczyć się nowej technologii od innych, “on the fly” i nie potrzebują do tego specjalnych szkoleń. Trochę się dziwią, dlaczego dodawanie coraz to nowych funkcjonalności zajmuje coraz więcej czasu i dlaczego nad niektórymi błędami siedzi się tygodniami a na końcu okazuje się, że poprawka była bardzo prosta. Ale nie potrafią tych problemów powiązać z metodami transferu wiedzy.

Narzędzia i technologie, z których korzystamy są coraz bardziej wyrafinowane i skomplikowane. Często jednak posiadają dużo ułatwień, które dramatycznie usprawniają ich wykorzystanie (np. ułatwienia w diagnostyce problemów). Problem polega na tym, że żeby z tych ułatwień skorzystać, trzeba najpierw poświęcić czas, żeby się o nich dowiedzieć. I trzeba poświęcić czas na zrozumienie istoty działania danego narzędzia i technologii, na której narzędzie bazuje. I tego w żaden sposób nie da się przeskoczyć. A jakie są koszty niewiedzy, to już każdy musi ocenić sam.

Mam wrażenie, że w tym temacie opinia publiczna otrzymuje 2 sprzeczne sygnały. Z jednej strony środowiska akademickie biją na alarm, że spada poziom wyższych uczelni i w ogóle szkolnictwa wyższego. Z drugiej strony raz na jakiś czas dowiadujemy się o sukcesach młodych polskich informatyków i wtedy słyszymy komentarz, że nauczanie informatyki jest w Polsce na najwyższym światowym poziomie. Jak jest naprawdę? Nie wiem.

Chciałem się jednak podzielić pewnymi spostrzeżeniami będącymi wynikiem obserwacji, dyskusji i własnych doświadczeń (jako student, świeżo upieczony absolwent i osoba współpracująca z takowymi).

Od razu chciałem zaznaczyć, że nie jest moim celem atak na środowiska akademickie. Piszę o pewnych zjawiskach, na które być może uczelnie nie mają wpływu.

Mniej więcej na 3 roku studiów, młody adept informatyki zaczyna się orientować, że ma umiejętności, które całkiem nieźle może sprzedać na rynku pracy. Poza tym, czyta w różnych gazetach specjalizujących się w rynku pracy, że powinien jak najszybciej zaistnieć na tym rynku bo pracodawcy bardzo sobie cenią kandydatów, którzy wcześnie zaczęli pracować, bo to dowodzi ich dynamizmu. Jakkolwiek, jest logika w takim rozumowaniu, warto sobie uświadomić pewne efekty uboczne.

Student 3 roku ma jeszcze całkiem sporo zajęć na uczelni, nie mówiąc o ilości materiału, który musi sobie przyswoić. Są oczywiście jednostki nieprzeciętne, które mają czas na uczelnię, pracę, dziewczynę, podróże i ciągle plasują się w czołówce studentów na swoim wydziale. To są jednak wyjątki. Dla większości studentów praca na pół etatu nieuchronnie prowadzi to zaniedbywania obowiązków na uczelni. Ale w pracy też nie są pełnowartościowymi zaangażowanymi pracownikami. Przy całym zaniedbywaniu tematu nauki, większość ma świadomość, że dyplom jest dla nich bardzo, bardzo ważny. Dlatego, kiedy w ich sprawach uczelnianych wybuchnie pożar, bez wahania porzucą pracę etatową, choćby mieli postawić swojego pracodawcę w bardzo trudnej sytuacji. W efekcie, ani porządnie się nie uczą, ani porządnie nie pracują.

A jakąż to pracę wykonują Ci młodzi, dynamiczni ludzie? Mało który znajduje sobie pozycję, która w wystarczającym stopniu stymuluje jego młody, chłonny umysł. Z zasady znajdują pracę mało twórczą, na pozycji, która wymaga po prostu kogoś, kto nie jest ignorantem w sprawach komputerowych. Po pierwsze dlatego, że mało kto powierzy odpowiedzialną wymagającą pracę studentowi, niepracującemu na pełen etat. Po drugie w większości firm nawet stricte informatycznych, rzeczy dzieją się powoli i wątek badawczy jest bardzo rzadki. Na uczelni poznawanie rzeczy nowych jest imieniem gry, jest codziennością. W większości firm nacisk jest położony na zagospodarowywanie istniejącej rzeczywistości, istniejących technologii i narzędzi. Bez wątpienia wiedza jak korporacje wyglądają od wewnątrz, jak wygląda praca w „realu” może być cenna dla studenta. Nasuwa się tylko pytanie czy wartość tej wiedzy usprawiedliwia koszt jej zdobycia.

Cóż jeszcze wyczytują w gazetach o pracy studenci? Że trzeba się umieć sprzedać, że brak jest takich jak oni specjalistów. Że już sam fakt, że skończyli uczelnię techniczną czyni ich na rynku pracy elitą elit i wszyscy będą się o nich zabijać. Czytają historie jakież to benefity dostał w korporacji taki to a taki zaraz po studiach. I tak naładowani idą do pracodawców. Potrafią niewiele praktycznych rzeczy, ale wiedzą, że muszą grać ostro i dobrze się sprzedać. I większość z nich zaczyna się przekonywać, że ich rzeczywistość jest inna od tej opisywanej w gazetach.

Czas już wreszcie powiedzieć naszej informatycznej dziatwie – młodzieży. To bardzo dobrze o was świadczy, że studiujecie na wyższej uczelni technicznej. Ale musicie się jeszcze bardzo, bardzo dużo nauczyć. Więc skupcie się na nauce. Na każdej uczelni zdarzają się ludzie, którzy się tam nie powinni znaleźć jako pracownicy naukowi. Ale nie zmienia to faktu, że jesteście tam otoczeni ludźmi światłymi, od których możecie się bardzo dużo nauczyć. I bardzo często Ci ludzie z radością podzieliliby się z Wami swoim doświadczeniem, swoją bezcenną wiedzą. Trafiają jednak z waszej strony na mur olewactwa i minimalizmu. Kiedyż to mają się z wami podzielić swoją cenną wiedzą, skoro zaraz po obowiązkowych zajęciach gnacie do swojej pracy, przeklepywać faktury do komputera, lub uczyć jakiegoś gderliwego tłumoka, jak się pogrubia tekst w Wordzie? W żadnej z firm, nawet tych co omdlewają z samozachwytu nad swoim programem szkoleniowym, nie będziecie mieli takich warunków do rozwoju, takiego inteligentnego otoczenia jak na uczelni. Więc na litość boską, wykorzystajcie tą szansę! Większość z was drugi raz już takiej szansy mieć nie będzie.

Każdy musi umieć siebie sprzedać, ale w pierwszej kolejności musi zadbać o to, żeby mieć co sprzedać. Jeżeli nie weźmiecie się do nauki to chociaż nie wiem jak ćwiczylibyście techniki autoprezentacji, w trakcie rozmowy kwalifikacyjnej kadrowiec ze średnim doświadczeniem lub wasz potencjalny bezpośredni przełożony, wypunktuje i ośmieszy was w ciągu 10 minut. A potem opowie o tym na lunchu swoim kolegom. Nawet nie wiecie, moi młodzi reprezentanci elity intelektualnej, jak często wasze oderwane od rzeczywistości i poziomu waszych kompetencji zachcianki są obiektem naszych kpin i jak bardzo nas one bawią.

Koniec kazania.

Wiem, wiem – wielu studentów musi pracować, żeby się utrzymać. Ale czy rzeczywiście muszą pracować aż tyle, aby odbywało się to kosztem nauki? Ilu studentów pracuje dużo dlatego, że musi a ilu dlatego, że chce samemu zarabiać pieniądze? Chęć finansowego uniezależnienia się jest bardzo ważnym pozytywnym czynnikiem popychającym młodych ludzi w kierunki dojrzałości i dorosłego życia. Jednak moim zdaniem, zbyt wielu młodych informatyków próbuje po tą pełną niezależność finansową sięgnąć zbyt wcześnie i płaci za to w przyszłości wysoką cenę.

Witam Szanownych Czytelników,

Computerworld zaproponował mi prowadzenie bloga. Renoma tego czasopisma wielce połechtała moją dumę. Z drugiej strony zdawałem sobie sprawę z odpowiedzielności jaką na siebie biorę. “Człowieku, czy ty na pewno będziesz w stanie mniej więcej raz na tydzień powiedzieć coś mądrego?” pytałem sam siebie. Ale próżność zwyciężyła . 

Przystępując do pisania tego blogu mam na uwadze słowa Manueli Gretkowskiej w „Polce”, które traktują o pisaniu cyklicznych felietonów:

“Nie da się regularnie produkować cacuszek, uprawiać błyskotliwie pańszczyzny. Najczęściej etat felietonisty kończy się przynudzaniem, grzebaniem we własnym pępku albo spisywaniem z zagranicznych gazet czyli komentowaniem komentarzy.”

Tego chyba boję się najbardziej. Spodziewam się więc, że być może pewnego dnia zamknę ten blog z komentarzem „nie mam już więcej nic mądrego i odkrywczego do powiedzenia”. I kto wie, może to będzie szybciej niż przypuszczałem. I mam nadzieję, że moi czytelnicy (jeżeli się takowych dorobię) nie potraktują tego jako dowodu, że jestem niepoważny i szybko się zniechęcam.

I chciałbym spróbować jeszcze jednego. Chciałbym aby pewne tematy, poruszane przeze mnie stawały się początkiem RZECZOWEJ, kulturalnej dyskusji. Do tego będzie służyła możliwość komentowania moich wpisów na blogu. Ale uwaga! W tej dyskusji spróbuję narzucić pewne reguły. Nie na każdy komentarz odpowiem i będę zachęcał innych, aby również byli selektywni. Internet oferuje swoim użytkownikom anonimowość. Pozwala to wygłaszać niepopularne, odważne i bezkompromisowe tezy bez obawy poniesienia społecznych konsekwencji, które czasami mogą być całkiem poważne. Z przykrością jednak stwierdzam (i wiem, że nie odkrywam tu Ameryki), że większość anonimowych użytkowników manifestuje swoją bezkompromisowość wypowiadając się w sposób obraźliwy i niegrzeczny a jednocześnie nie wnosząc nic do dyskusji.

Chcąc temu zaradzić będę się starał moderować komentarze do mojego blogu. Będzie to na pewno niedemokratyczne, ale czy demokracja zawsze, w każdym kontekście jest rozwiązaniem idealnym? Zachęcam też innych, aby nie rozpoczynali dyskusji z niegrzecznymi, nic nie wnoszącymi postami. Żadna krytyka nie boli tak jak zignorowanie.

To tyle mojego chciejstwa . A teraz, czas brać się do pracy…