Obciążenie systemu

Ludzie instynktownie rozumieją, że jeżeli obciążymy serwer do 100% jego mocy spowoduje to nagły spadek wydajności, drastyczne zwiększenie czasu oczekiwania na odpowiedź oraz ogólnie rozumiany brak stabilności. Jednocześnie tak bardzo dziwią się jak Google może utrzymać krótki czas reakcji na zmiany na rynku, bardzo dużą wydajność pracy oraz stabilność, pozwalając swoim programistom na 20% pracy na rzecz zadań nie związanych z ich aktualnymi projektami.

Przecież to jest to samo. Tak jak serwer, aby utrzymać maksymalną wydajność i krótki czas odpowiedzi nie powinien być przeładowany pracą na więcej niż 80% tak samo pracownik, aby utrzymać maksymalną wydajność i krótki czas reakcji nie powinien być przeładowany powyżej 80% swojego czasu. Co ciekawe jeżeli obciążenie serwera zaczyna w zwykłej firmie oscylować w okolicach 80% to zwykle dyrektor działu IT natychmiast występuje z wnioskiem o zakup nowego serwera. Z drugiej strony jeżeli pracownik jest obciążony na 80% to w zwykłej firmie dyrektor (nawet ten sam) zwykle... dorzuci mu jeszcze jeden projekt. A potem bardzo się będzie dziwił, że czas oczekiwania na efekt gwałtownie rośnie a wydajność spada. Gdzie tu logika?

(temat zaczerpnięty z książki “Implementing Lean Software Development”)

Budowanie dla utrzymania

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

Bardzo, bardzo dobra książka...

Implementing Lean Software Development - czytam i muszę powiedzieć, że jestem zaskoczony tym jak dobra jest ta książka. Stanowi ona zestaw prawd na temat zasad rządzących światem tworzenia oprogramowania. Zestaw ten poparty jest wieloma, naprawdę wieloma przykładami z doświadczenia własnego autorów.

Od dziś jest to dla mnie lektura obowiązkowa dla każdego menedżera zajmującego się rozwojem oprogramowania. Pewne koncepcje w niej zawarte na pewno przemyślę, przedyskutuję i podzielę się nimi na tym blogu.