Listopadowy numer Software Develper Journal zawiera bardzo ciekawy artykuł: Czynniki sukcesu w projektach programistycznych.

Wnioski z ankiet:

Wymagania i ich odpowiednie przetwarzanie to kluczowe zagadnienie w projektach. Popełniane w tym obszarze błędy to główne źródło problemów w projektach. Dlaczego tak się dzieje? Oto główne przyczyny wskazane przez osoby badane:

1. nieznajomość metod i technik zbierania wymagań;
2. trudno dotrzeć do informacji;
3. osoby dostarczające wymagania są rzadko dostępne;
4. nieprecyzyjne wymagania.

Wydają się oczywiste, a że z faktami nie dyskutujemy uznajemy je.

Ad.1. To chyba powszechna bolączka wielu dostawców IT. Najczęściej obserwuję metodę polegająca na “zbieraniu wymagań” metodą pytania “czego Pan/Pani oczekuje od systemu” i ta forma jest gwoździem do trumny projektu. Dlaczego? Odpowiedź zawarta jest w pozostałych trzech punkach: wywiady cierpią bo trudno dotrzeć do danych i ich posiadaczy a ci ostatni najczęściej podają wymagania “z głowy” co daje w efekcie ładnie sformatowany ale nieprecyzyjny opis.

Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań – no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę.  Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego).

Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.  Jedynym sposobem jest upraszczanie i praca z abstrakcjami. Czym są owe abstrakcje? Modele! Już w 1984 roku zauważono, że:

I just read an idea by [[Stephen Hawking]] and [[Leonard Mlodinow]], called [[Model-Dependent Realism]][2]: ?the idea that a physical theory or world picture is a model (generally of a mathematical nature) and a set of rules that connect the elements of the model to observations.? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS).

I nie chodzi tu o to, że inżynieria oprogramowania, to jakiś złożony model matematyczny. Chodzi w ogóle o posługiwanie się modelami – abstrakcjami – na każdym etapie projektu. To jedyny sposób by “ogarnąć projekt” w całości. Tak samo jak nie da się myśleć o samochodzie w kontekście tysięcy jego podzespołów, tak nie da się tak myśleć o czymkolwiek podobnie złożonym.

ad.2. Docieranie do informacji paradoksalnie nie jest trudne, jest ich po protu mało w firmach. Bardzo często postępowanie poszczególnych wykonawców jest efektem ich doświadczenia, kompetencji oraz przyznanych uprawnień.  Problemem, a może raczej wyzwaniem jest zapisanie części tych “reguł”.

ad.3. To dla mnie kuriozalny powód. Jest raczej dowodem słabości kierownika projektu (bo nie analityka).

ad.4. Zacytuje dla przypomnienia: “nieprecyzyjne wymagania”. Od tego jest analityka by były precyzyjne. Problem ten pojawia się często w sytuacji gdy owym “analitykiem” jest dostawca oprogramowania, który “czeka na wymagania” mimo, że zawarł w ofercie i umowie pozycję “analiza wymagań”.