Blog naukowy. Zdobądź wiedzę z języków obcych, jazdy na łyżwach...

Zaplanuj odrzucenie jednego projektu

Inżynierowie chemicy dawno zrozumieli, że nie należy od razu przenosić procesów z laboratorium do fabryki. Trzeba najpierw zbudować i?istalację pilotową, żeby zdobyć doświadczenie w zwiększaniu skali produkcji i w prowadzeniu działań w środowisku nie chronionym.

Etap pośredni jest również potrzebny w wypadku tworzenia produktów programowych, ale budowniczowie oprogramowania nadal unikają przeprowadzania prób eksploatacyjnych z systemem pilotowym przed przystąpieniem do dostarczenia gotowego produktu. [Dziś jest to już rzeczą normalną w wypad- ku wersji beta. Nie jest jednak praktykowane, jeśli chodzi o prototyp o ograniczonych funkcjach, czyli wersję alfa, a – moim zdaniem – powinno być].

W większości wypadków pierwszy zbudowany system z trudem nadaje się do wykorzystania: jest za wolny, za duży, nieporęczny w użytkowaniu – albo wszystko razem. Odrzucenie pierwszego systemu i całkowite przeprojektowanie go lub zmienianie go kawałek po kawałku jest nieuchronne.

Dostarczenie klientowi pierwszego systemu, nadającego się do odrzucenia, pozwoli zyskać odrobinę czasu, ale jedynie kosztem użytkownika, programisty, którego odrywa się od innych zajęć do prac nad zmianą projektu, i złej opinii o produkcie, którą trudno będzie naprawić.

Lepiej zaplanować, że odrzuci się jeden projekt, bo i tak to się zrobi. „Programista raczej zaspokaja określoną potrzebę użytkownika niż dostarcza mu jakiś materialny wyrób”. (Cosgrove)

Zarówno rzeczywista potrzeba, jak i postrzeganie jej przez użytkownika ulegają zmianie podczas tworzenia programów, testowania ich i używania. Podatność produktu programowego na obróbkę i jego niewi- doczność sprawiają, że jego budowniczy jest w wyjątkowym zupełnie stopniu narażony na nieustanne uwzględnianie zmian wymagań użytkownika.

Pewne uzasadnione zmiany celów (i strategii rozwojowych) są nieuniknione i lepiej się na nie przygotować niż zakładać, że się nie pojawią. Metody projektowania produktu programowego do uwzględnienia w nim zmian, a zwłaszcza programowanie strukturalne ze starannym definiowaniem interfejsów międzymoduło- wych, są dobrze znane, ale nie znajdują powszechnego zastosowania. Przydatne są też techniki tablicowe. [Dzisiejsze ceny i rozmiary pamięci sprawiają, że techniki takie stają się coraz lepsze].

Należy korzystać z języka wysokiego poziomu, operacji związanych z kompilacją, włączania deklaracji przez odwołanie i technik samodokumentowania, aby ograniczyć błędy spowodowane zmianami. Zmiany należy kwantować. Każda wersja produktu powinna być numerowana. [Dziś jest to standardowa praktyka].

Niechęć programisty do dokumentowania swojego wyrobu wynika nie tyle z lenistwa, ile z odrzucania od siebie angażowania się w obronę decyzji, o której wie, że jest nieobowiązująca. (Cosgrove). Przygotowanie struktury organizacyjnej do ewentualnych zmian jest znacznie trudniejsze niż zaprojektowanie systemu pod tym kątem.

Szef przedsięwzięcia musi poświęcać wiele uwagi na zapewnienie wymienności podległych mu kierowników i programistów w zależności od ich umiejętności: w szczególności chciałoby się móc łatwo przenosić ludzi ze stanowisk technicznych na kierownicze i odwrotnie.

Przeszkody na drodze do skutecznej dwuszczeblowej hierarchii organizacyjnej mają charakter socjologiczny i trzeba je zwalczać, cały czas wykazując czujność i energię. Łatwo można ustalić jednakowe stawki płac dla poszczególnych szczebli w dwuszczeblowej hierarchii, ale trzeba robić wszystko, żeby zapewnić im podobny prestiż: takie same biura, analogiczne usługi pomocnicze, unikanie wyższego wynagradzania kierowników.

Wprowadzenie w życie koncepcji zorganizowania zespołu tworzącego oprogramowanie na wzór zespołu chirurgicznego jest radykalnym sposobem podejścia do tej kwestii. Jest to naprawdę długofalowe rozwiązanie problemu elastyczności schematu organizacyjnego.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.