Grupowa komunikacja przy pomocy INN

Dygresja czyli o podstawowym zastosowaniu INN

Podstawowym zastosowaniem INN jest - na co wskazuje choćby sama nazwa (InterNet News) - obsługa grup dyskusyjnych Usenetu. Program ten jest wykorzystywany przez wiele poważnych serwerów news (także znaczną część polskich, z news.icm.edu.pl na czele).

Równolegle, popularne jest wykorzystywanie INN do lokalnego replikowania zbioru wybranych grup Usenetowych na potrzeby jednej osoby czy jakiejś grupy (np. w firmie, w której pracuję, replikujemy na INN kilkadziesiat czytanych przez nas grup dyskusyjnych i kilka list mailowych).

O zastosowaniach tego typu nie będę tu pisał zbyt wiele z dwóch powodów:

• nie mam doświadczeń w zarządzaniu dużym serwerem news otrzymującym pełny feed;
• na temat konfiguracji INN+suck (lokalny cache zbioru wybranych grup dyskusyjnych) niezłe HOWTO po polsku przygotował Rafał Czeczótka.

Miałoby chyba pewną wartość dopisanie paru słów o replikowaniu na grupie INNowej listy mailowej. W przyszłości może napiszę kilka słów na ten temat - jeśli kogoś szczególnie to interesuje, proszę o informację. Służę też informacją, jak uszczęśliwić subskrybentów tru64unix-managers zawartością pl.biznes.banki ;-)

W dalszej części tego artykułu zajmuję się jednak innym zastosowaniem INN - wykorzystaniem go w ramach firmy do organizacji komunikacji w ramach zespołu.

Motywacja

Każda poważniejsza praca wymaga intensywnej wymiany informacji i współdziałania w gronie kilku, nieraz kilkunastu osób. Organizowane są rozliczne spotkania, prowadzi się debaty telefoniczne, wreszcie wymienia stosy emaili.

Z mojego doświadczenia wynika, że w powyższym zestawie bardzo brakuje mechanizmu komunikacyjnego, który:

• zapewniałby, że wszystkie informacje są widoczne dla wszystkich;
• pozwoliłby na śledzenie, kto kiedy i o co pytał oraz czy, kiedy i jaką dostał odpowiedź;
• prezentowałby jedną spójną historię dyskusji na dany temat;
• umożliwiałby każdemu z uczestników indywidualne uczestnictwo w dyskusji, choćby łatwe odróżnianie "co już czytałem/oglądałem a czego jeszcze nie?";
• byłby bardzo łatwy w użyciu;
• dawałbym możliwość kontroli, kto ma prawo uczestniczyć w dyskusji a kto nie.

Każdy, kto po paru miesiącach jakiegoś projektu próbował uporządkować informacje rozsiane po posyłanych do kilku różnych osób emailach, notowane na kartkach po rozmowach telefonicznych itp, zna chyba doskonale te potrzeby.

Narzędzie zapewniające wszystkie powyższe możliwości istnieje. W opisanych sytuacjach bardzo dobrze się sprawuje serwer grup dyskusyjnych (oczywiście w parze z czytnikami).

Oczywiście można użyć dowolnego serwera grup dyskusyjnych (nawet tego wbudowanego w Exchange, choć słyszałem o nim wiele złych opinii). Piszę o INNie bo go znam, używam i cenię. Można też korzystać z jakiegoś innego mechanizmu komunikacji grupowej, choćby publicznych folderów Exchange albo dyskusji LotusNotes czy GroupWise. Główny problem w ich wypadku to konieczność instalacji specyficznego (i to często wymagającego płatnej licencji) oprogramowania u każdego użytkownika.

Istnieje jeszcze drugie ważne zastosowanie, z którym miałem do czynienia u mojego pierwszego pracodawcy. W dużej, rozproszonej geograficznie firmie, w trakcie wdrażania i eksploatacji dużego systemu, warto mieć wygodną platformę do komunikacji z użytkownikami. Nie dość, że na wiele pytań można odpowiedzieć raz a nie siedemdziesiąt razy, to często w rozwiązywaniu problemów jednych użytkowników wyręczają nas inni, bardziej doświadczeni - którzy nieraz chętnie dzielą się swoimi pomysłami i doświadczeniami.

Kilka informacji technicznych

Chyba najprościej zacząć używać INN po prostu instalując go wraz z jakąś dystrybucją Linuksa (INN należy zarówno do Debiana jak do RedHata). Choć sam zaczynałem od ręcznego kompilowania na Digital Uniksie, wzięcie gotowca uważam za łatwiejsze (a serwerek Linuksowy przydać się może też na wiele innych rzeczy - np. aktualnie używam taką maszynkę jako serwer grup dyskusyjnych, repozytorium CVS, wewnątrzfirmowy serwer WWW, serwer plików dla maszyn Windows oparty o Sambę, serwer czasu i parę innych).

W najprostszej sytuacji (instalacja pakietu pod Linuksem), trzeba po prostu po zainstalowaniu przejrzeć kolejno pliki znajdujące się w katalogu /etc/news z szczególnym uwzględnieniem:

• expire.ctl - tutaj definiujemy, po jakim czasie posty będą kasowane (w serwerze wewnątrzfirmowym może być rozsądne wyłączenie kasowania w ogóle - z ewentualnym wyjątkiem dla grup nietechnicznych);
• inn.conf - stąd usuwamy napis Poorly administered INN site ;-);
• nnrp.access - tu definiujemy, komu wolno korzystać z danego serwera (bądź na poziomie adresów IP czy domen DNS, bądź dokładniej, z wykorzystaniem kont i haseł).

Dokładna zawartość plików zależy od wersji INN, może więcej napiszę na ten temat później.

Same grupy zakładamy (z konta root lub news) poleceniem

       ctlinnd newgroup moja.nowa.grupa y

Główną stroną autorów INN (notabene to ta sama grupa, która tworzy BIND) jest www.isc.org. Tamże znajduje się trochę wartościowych odsyłaczy.

Wartościowych rad na temat konfiguracji INN udzielają zazwyczaj czytelnicy grup dyskusyjnych pl.news.admin (po polsku) oraz news.software.nntp (po angielsku).

Sensowna struktura grup

Aby uniknąć kłopotów w przyszłości, warto od razu dobrze rozplanować strukturę grup dyskusyjnych i zasady ich nazewnictwa.

Tworzone grupy dyskusyjne będą się rozpadać prawdopodobnie na następujące grupy:

Ogólnofirmowe grupy tematyczne

Są to otwarte dla każdego pracownika, który tylko chce w nich uczestniczyć, grupy tematyczne poświęcone konkretnym narzędziom, technologiom itp (np. tak w firmie w której pracowałem poprzednio jak obecnej używamy grup o C++, Oracle, intensywnie wykorzystywanych produktach middleware, poszczególnych systemach operacyjnych itp - stosując nazewnictwo typu firma.wspolne.narzedzia.tuxedo). Tego typu grupy służą zarówno do zadawania pytań "czy ktoś w firmie wie jak ..." (możliwość zadania takiego pytania na grupę zmniejsza trochę liczbę osób chodzących po kolejnych pokojach albo obdzwaniających wszystkich kolegów), jak po prostu są wspólnym notatnikiem w którym spisywane są wartościowe sztuczki, ostrzeżenia przed błędami, informacje o specyficznych cecach narzędzi itp. Z mojego (dwie różne firmy) doświadczenia wynika, że ruch na tego typu grupach nie jest zazwyczaj bardzo duży ale gromadzona wiedza jest bardzo cenna i wielokrotnie się do niej sięga.

Grupy projektowe

Tworzone na potrzeby poszczególnych projektów i dostępne dla uczestniczących w nich osób grupy stanowiące podstawową platformę komunikacji zespołów projektowych (nazewnictwo typu firma.projekty.nazwa_projektu). Tutaj toczą się dyskusje na temat tworzonego projektu, kodu i dokumentów, tu pojawiają się ogłoszenia dotyczące danego zespołu, tu wrzucamy wstępne wersje dokumentów czy podsumowań spotkań. Ogólnie: jeśli ktoś ma jakieś pytanie albo wiadomość związaną z danym projektem, umieszcza ją na takiej grupie. Z mojego doświadczenia wynika, że dużo łatwiej zachęcić programistów do wrzucenia postu na newsy niż przygotowania "pełnego" dokumentu na jakiś temat - a taka grupa stanowi zarówno cenne medium komunikacyjne jak cenną dokumentację historii projektu.
Przy sporych projektach można pomyśleć o dalszym podziale - zamiast jednej grupy zrobić kilka, np. osobno na:

• dyskusje związane z wymaganą funkcjonalnością a także pomysłami "do zrealizowania kiedyś";
• sprawy bezpośrednio związane z tworzeniem i testowaniem kodu;
• informacje o kontaktach z klientem/użytkownikiem.

Grupy supportowe

Grupy służące wsparciu technicznemu użytkowników (nazewnictwo typu firma.support.nazwa_systemu). Idealnie, jeśli czytają je i piszą na nie faktyczni użytkownicy wdrażanego systemu (zwłaszcza, gdy działamy w dużej firmie o wielu oddziałach) - całkiem szybko możemy osiągnąć stan, w którym użytkownicy pomagają sobie nawzajem a nawet jeśli jakieś problemy wymagają naszej interwencji, odpowiednie informacje publikujemy raz (a nie dla każdego użytkownika po kolei). Bardzo pozytywne doświadczenia związane z wykorzystywaniem takich grup mam z okresu pracy u poprzedniego pracodawcy.
Jeśli klient jest firmą zewnętrzną, można próbować tworzyć analogiczne grupy w internecie - ale tu już zachęcenie użytkowników do ich wykorzystywania jest dużo trudniejsze (choćby dlatego, że często nie mają dostępu do internetu albo jest on dla nich kłopotliwy). Nawet jednak w takim wypadku warto rozważyć stworzenie takich grup wewnątrz firmy - tym razem służących notowaniu przez osoby kontaktujące się z klientami informacji "komu, co i kiedy powiedziano", "kto i z jakim problemem się zgłaszał" itp.
Ważna uwaga końcowa: grupy supportowe nie zastępują ani nie są zastępowane przez mechanizmy zgłaszania i monitorowania błędów (typu bugzilla). Główną rolą grup supportowych jest umożliwienie płynnej komunikacji pomiędzy różnymi użytkownikami i autorami systemu, czego system rejestracji błędów nie umożliwi.

Pewne grupy specyficzne

Z mojego doświadczenia, poza wszystkimi wymienionymi, przydatne są jeszcze dwie grupy dyskusyjne:

• poświęcona sprawom organizacyjnym firmy (nazwa np. firma.organizacyjne) - gdzie pojawiają się dotyczące wszystkich pracowników ogłoszenia (a z drugiej strony np. propozycje zakupów) - szczegółowa zawartość zależy od specyfiki firmy ale tego typu kanał informacyjny jest przydatny;
• grupa "pogawędkowa" (ja zwyczajowo stosuję nazwę firma.pogaduchy), gdzie można wrzucić kolejny fantastyczny dowcip, umówić się na mecz albo film, szukać czwartego do brydża itp itd - oprócz kanalizowania tego typu aktywności (istnienie takiej grupy redukuje choćby liczbę wędrówek po pokojach z tego typu sprawami), grupa ta ma bardzo cenną cechę: zachęca ludzi do subskrybowania grup z danego serwisu (bardzo często pogaduchy są pierwszą subskrybowaną grupą - ale gdy już ktoś czyta jedną, łatwo nakłonić go by czytał także grupy techniczne czy projektowe).

Narzędzia uzupełniające

Jeszcze o dwóch ważnych narzędziach pomocniczych:

• Mhonarc jest bardzo przyjemnym programem generującym HTMLowe archiwa zawartości grup;
• MarcSearch dodaje do powyższych archiwów możliwość wyszukiwania (oczywiście jest to tylko jedna z opcji, można też wykorzystać jakąś generyczną wyszukiwarkę typu UdmSearch).

Podsumowanie

Powyższy artykuł skupia się nie tyle na kwestiach technicznych, co na wskazówkach dotyczących tworzenia użytecznych kanałów komunikacyjnych. Jak sądzę, można podobne grupy dyskusyjne zbudować np. przy pomocy Exchange czy Lotus Notes. Kluczową kwestią na którą chcę zwrócić uwagę jest, że tego typu mechanizmy powinny istnieć, być dostępne dla wszystkich pracowników firmy i być przez nich używane.

Jeszcze słowo ostrzeżenia: grupa dyskusyjna oczywiście nie zastępuje dokumentacji technicznej czy administracyjnej (zastępuje natomiast sporą część maili i telefonów oraz pewną część spotkań). Sensowniej jednak jest najpierw przedyskutować kluczowe kwestie a dopiero potem je formalnie dokumentować, niż wkładać wysiłek w formalną dokumentację przed uzgodnieniem co dokładnie robimy (ubocznym efektem takiego podejścia jest często desperacka obrona projektu przez autora - nie dlatego, że jest przekonany o jego dobrej jakości - ale dlatego, że nie chce już zmieniać dokumentu).

komentarze obsługiwane przez Disqus