polski
polski blog
salon24.pl
„- Dzień dobry.
- Dzień dobry.
- Chciałbym dodać do mojej aplikacji trzy nowe funkcjonalności, i sprawdzić, czy moi klienci mogą pracować z tym nowym systemem od Microsoftu.
- Nie ma problemu. Potrzebujemy tygodnia, kosztować to będzie trzy razy mniej niż u konkurencji.
- Dziękuję.
- Dziękuję”
Każdy z nas, przychodząc do specjalistów, oczekuje, że sami zajmą się wszystkimi ważnymi detalami (najlepiej, jak znajdą odpowiedzi, nie musząc nas o nic kłopotać), i dostarczą w jak najkrótszym czasie jak najlepszą jakość przy jak najlepszej cenie.
Jak to się w praktyce może skończyć, to chyba widać:
Ktoś się ostatnio oburzył, że napisałem „Agile, w którym często i gęsto nie liczy się jakość (tylko to, żeby cokolwiek dostarczyć, a potem się poprawi)”.
Ludzie od języków maszynowych przeszli na języki strukturalne trochę wyższego poziomu (np. C, gdzie dosyć sporo rzeczy należy robić w kodzie), potem języki obiektowe (m.in. C++), języki obiektowe próbujące wyeliminować typowe błędy (chociażby Java czy Rust) czy języki skryptowe. Wielki żal, że z rynku praktycznie zniknęły pewne rozwiązania typu Delphi (gdzie jednak można było osiągnąć wspaniałe rezultaty), ale to chyba zgodnie z zasadą, że gorszy pieniądz zawsze wypiera lepszy.
Oprogramowanie z czasem robiło się bardziej skomplikowane... i okazało się, że przetestowanie kombinacji wszystkich możliwych elementów jest właściwie niemożliwe. Dodatkowo przez lata wypracowano poprawny sposób wykonywania różnych elementów związanych z produkcją oprogramowania, ale te generalnie wymagały dużo czasu i zasobów.
Zaczęto sobie radzić z tym wszystkim w różny sposób. Jedną z opcji jest tworzenie w konwencji bazaru, a nie katedry (o co tu chodzi, pisałem co najmniej 2x), jednakże w większych firmach czy organizacjach nie zawsze jest to możliwe.
Właśnie tym ostatnim przypadkiem zajmę się dalej.
W najbardziej chyba klasycznym V modelu założono, że mamy ileś etapów, przygotowujemy wiele elementów, na wszystko jest odpowiedni czas, itp. Okazało się to o tyle nieefektywne, że elementy typu testowanie wykonywano dosyć późno i w praktyce często przy okrojonych zasobach (a to się odbijało na jakości).
Obecnie częściej używamy różnych metodyk, które, powiedziałbym, w dużej mierze opierają się na podziale zadań na małe elementy i dostarczanie tego, co możliwe, w kolejnych regularnych cyklach. Rozwiązanie na papierze ma dużo zalet, diabeł tkwi jednak w szczegółach.
I tak załóżmy, że mamy dosyć typową firmę z typowymi projektami (a więc nie takimi, od których zależy życie ludzkie, albo tymi, w których nie ma absolutnie żadnego marginesu na błędy). Ludzie tam przychodzą i odchodzą (jest to normalne, i mówię również o zwolnieniach macierzyńskich, itp.). Po jakimś czasie mamy pracowników z mniejszym doświadczeniem (którzy się uczą i chcą się nauczyć), tych, którym wszystko jest obojętne (zasada „czy się stoi czy się leży...” ewentualnie nuda, gdy ktoś się zasiedzi), i tych, którzy chcą się wykazać.
Załóżmy, że w takim zespole wszystko działa jak w zegarku, i wtedy...
- przychodzi ktoś nowy, kto szuka sposobu na wykazanie się (wtedy słyszymy najczęściej magiczne słowo optymalizacja) albo
- odchodzi ktoś, kto siedział tam długo, i wykonywał za innych pracę albo
- kadra kierownicza widząc dobre wyniki decyduje o przesunięciu sił na inny front robót (to mi przypomina sprawę Internet Explorera).
To tylko trzy przykłady - zabawnych możliwości jest znacznie więcej.
Pójdźmy dalej.
Co się składa na poprawnie wykonaną pracę? Ano spotkania, pisanie dokumentacji, wypełnianie zgłoszeń w systemach, i praca właściwa, czyli analityczna / techniczna (zależy od roli).
Im większa firma, tym więcej pojawia się w niej managerów... a oni też muszą się wykazać coraz lepszymi wynikami (więc zmieniają terminy, cele albo budżety).
Na co ludzie niżej mają coraz mniej czasu? Czy nie jest tak, że często i gęsto dostają coraz więcej zadań (skoro są takie małe jak metodyka mówi...), i muszą wykonywać coraz więcej rzeczy związanych z tzw. biurokracją (spotkania, zgłoszenia, itp.), a mają coraz mniej czasu na pracę właściwą?
Jeśli do tego dodać coraz mniejszą ogólną wiedzę techniczną (obecni inżynierowie to często bardziej klepacze kodu, którzy co najwyżej umieją z czegoś skorzystać, a jak zaczyna się sypać, to rozkładają ręce) czy problemy z infrastrukturą (szewc zazwyczaj chodzi bez butów), to robi się ciekawie…
Czy wiadomo już dlaczego tak wiele projektów wypuszczanych jest z błędami? Albo dlaczego w różnych firmach mamy do czynienia z żenującymi sytuacjami?
Celowo w tytule podałem tekst nawiązujący do suchara „Projekt manager to ktoś, kto uważa, że dziewięć kobiet może dostarczyć jednego bobasa w miesiąc”. Obecne metodyki (albo bardziej sposób ich wdrożenia) powodują często różne nonsensy, i to niestety też jest źródłem kolejnych konfliktów i problemów. Podam tylko kilka haseł:
- kurczowe trzymanie się wymagań (i nieuwzględnianie wszystkiego, co jest obok)
- przedkładanie elementów metodyki nad zdrowy rozsądek i np. ścisłe przestrzeganie zasad pisania różnych elementów (np. konieczność wypełniania zgłoszeń błędów zgodnie z templatką niezależnie od tego, czy ma to sens czy nie)
- przesuwanie elementów "mniej ważnych" na przyszłość (mogą być nieważne dla projekt managera, ale być kluczowe dla odbioru projektu)
A jeśli ktoś nie zauważył skrótów myślowych w słowach „Agile, w którym często i gęsto nie liczy się jakość (tylko to, żeby cokolwiek dostarczyć, a potem się poprawi)”, to chyba nigdy nie pracował przy większym projekcie.