Blog naukowy z Warszawy. Zdobądź wiedzę z języka francuskiego, nauki gry na perkusji...

Konferencje i sesje sądowe

Decyzje podjęte w wyniku cotygodniowych narad szybko przynoszą wyniki i umożliwiają kontynuowanie prac. Jeśli ktoś jest naprawdę bardzo niezadowolony, może się odwołać do szefa przedsięwzięcia, ale to zdarza się bardzo rzadko. Takie narady są bardzo owocne, a to z kilku powodów.

– 1. Miesiącami spotyka się ta sama grupa – architekci, użytkownicy i wdrożeniowcy. Nie traci się czasu na aktualizację informacji, którymi dysponują poszczególne osoby.

– 2. Członkowie grupy są bystrzy, pomysłowi, dobrze znają zagadnienia i interesuje ich tylko wynik. Nikt nie występuje w roli doradcy. Każdy ma prawo podjąć wiążące zobowiązania.

– 3. Gdy podnosi się jakieś kwestie, szuka się rozwiązań zarówno w obrębie oczywistych granic, jak i poza nimi.

– 4. Formalny charakter pisemnych propozycji przyciąga uwagę, wymusza podejmowanie decyzji i umożliwia uniknięcie niekonsekwencji wynikających z zespołowego redagowania tekstu.

– 5. Dzięki jawnemu powierzeniu władzy decyzyjnej naczelnemu architektowi, unika się kompromisów i zwłoki w działaniu.

Niektóre decyzje nie wytrzymują próby czasu. Zdarza się, że pewne drobne sprawy nie są w pełni akceptowane przez wszystkich uczestników spotkania czy wynikają nieprzewidziane problemy, których nie rozpatrzono na cotygodniowej naradzie. Zbierają się więc zaległości w postaci nie załatwionych drobnych odwołań, nie rozstrzygniętych spraw lub utyskiwań. Aby sobie z tym poradzić, organizowaliśmy co roku sesje sądu najwyższego, trwające zazwyczaj dwa tygodnie. (Gdybym to robił dzisiaj, organizowałbym je co pół roku).

Sesje te odbywały się tuż przed ważniejszymi terminami ostatecznego zatwierdzania podręcznika. Obecni byli nie tylko architekci oraz związani z architekturą przedstawiciele programistów i wdrożeniow- ców, ale także kierownicy zespołów programowania, marketingowych i wdrożeniowych. Sesjom przewodniczył szef projektu System 360. Porządek dzienny obejmował na ogół około 200 pozycji – zazwyczaj drobnych, wyszczególnionych na planszach rozwieszonych w sali. Wysłuchiwano argumentów wszystkich stron i podejmowano decyzje. Dzięki cudowi, jakim jest komputerowe redagowanie tekstu (i wspaniała praca personelu), każdy z uczestników sesji znajdował przed sobą co rano zaktualizowany podręcznik, uwzględniający decyzje z poprzedniego dnia.

Te „jesienne festiwale” ułatwiły nie tylko podejmowanie decyzji, ale także ich akceptację. Każdy został wysłuchany, każdy brał udział w dyskusji, każdy lepiej rozumiał skomplikowane ograniczenia i współzależność poszczególnych decyzji.

Architekci Systemu 360 mieli przewagę nad innymi pod dwoma względami: mieli dostatecznie dużo czasu, aby pracować starannie, i dysponowali siłą równą tej, jaką mieli wdrożeniowcy. Dostateczna ilość czasu wynikała z terminarza prac nad nową techniką: równorzęd- ność sił była wynikiem jednoczesnego konstruowania wielokrotnych implementacji. Konieczność utrzymania ich ścisłej zgodności była najlepszym czynnikiem wymuszającym przestrzeganie specyfikacji.

W większości projektów komputerowych nadchodzi dzień, w którym się okazuje, że maszyna i podręcznik mają ze sobą niewiele wspólnego. Kiedy dochodzi do konfrontacji, zazwyczaj przegrywa podręcznik, bo łatwiej i taniej można go zmienić niż maszynę. Tak jednak nie jest w wypadku wielokrotnych implementacji. Opóźnienia i koszty związane z modyfikacją maszyny według ustaleń podręcznikowych mogą być wówczas większe niż opóźnienia i koszty związane z naprawianiem błędnie działającej maszyny.

Tę koncepcję można z powodzeniem stosować przy definiowaniu języka programowania. Można bowiem być pewnym, że wcześniej czy później trzeba będzie stworzyć do rozmaitych celów kilka interpreterów lub kompilatorów. Definicja będzie precyzyjniejsza, a dyscyplina ściślejsza, jeżeli na początku zbuduje się co najmniej dwie implementaqe.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.