Dziś nieco kontrowersyjny artykuł, krytyka najczęściej stosowanych metod analizy wymagań. Pojawią się tu cytaty ze stron dużych firm dostarczających oprogramowanie. Są to krytykowane przeze mnie opisy metod pracy. Jednak z mojej strony będzie tu: nie „moje widzimisię” jako „właściwa metoda”, a metody powszechnie uznane za skuteczne i opisane w sieci i w literaturze. Osobiście zresztą uważam, że wiele tak zwanych „autorskich metodyk” to albo udziwnione i nadmiernie komplikowane standardy (czytaj podniesione koszty analizy), albo ubrane w „procedury” metody tu krytykowane (czyli także podniesione koszty ale już dalszych etapów).
Bardzo często z ust dostawców oprogramowania, można usłyszeć o takim podziale wymagań, który co ciekawe, trudno znaleźć w opisach standardów metod analitycznych (np. OMG.org):
Wymaganie jest potrzebą klienta, która wpływa na powstanie nowego rozwiązania lub zmienia rozwiązanie już istniejące. Ze względu na poziom szczegółowości wymagania mogą być biznesowe lub systemowe.
Wymaganie biznesowe realizowane jest poprzez jedno lub zbiór wymagań systemowych. Przykładem może być Import plików z umowami. Wymaganie to można zrealizować poprzez dwa wymagania systemowe: import plików i obsługa zaimportowanych plików.
Wymagania systemowe dotyczą bezpośrednich funkcjonalności systemu. Złożone wymagania systemowe można przedstawić za pomocą bardziej szczegółowych, np. Import plików obejmuje wykonanie sprawdzeń i walidacji na zaimportowanych danych oraz proces zapisu umów z pliku importu w systemie.
Pojawia się pojęcie „Import pliku z umowami”. Jaki to ma związek z biznesem? Domyślać się można jedynie, że te umowy gdzieś są i w jakimś celu powinny być gdzieś dostępne, ale nie jestem przekonany by użytkownik od razu wyartykułował, że chce mieć ich „import”. To pojęcie techniczne.
Osobiście polemizuję z takim podejściem nie tylko dlatego, że trudno o wskazanie podstaw takiego a nie innego podziału wymagań. Także dlatego, że jest to proces z gruntu ryzykowny. Po trzecie, powyższe definicje nie spełniają podstawowego kryterium słownika pojęć: pojęcia danej przestrzeni nazw nie mogą być definiowane z pomocą innych pojęć tej samej przestrzeni. Takie błędy prowadzą do tak zwanego masła maślanego, co wyszło dość szybko, bo tekst w dalszej części treści cytowanej strony zaprzecza części wcześniejszej definicji wymagań:
Zgodnie z teorią specyfikacja powinna zawierać przede wszystkim wymagania zaprezentowane z punktu widzenia klienta i w terminach dla niego zrozumiałych. Powinna stwierdzać, co ma zostać zrealizowane, a nie jak należy to zrobić. Specyfikacja wymagań nie może być więc próbą projektowania systemu.
Po pierwsze kim tu jest Klient? Gdzie jest użytkownik? Dlaczego wymaganie określa sposób realizacji wymagania (Import plików obejmuje…)? Co to są „bezpośrednie funkcjonalności systemu”? Skoro są bezpośrednie to czym są „niebezpośrednie funkcjonalności” i gdzie je opisano?
Ogólnie pojęcie „wymagania systemowe”, będące próbą opisu „jak to ma być zrobione” nie mają żadnej racji bytu jako Wymaganie Klienta. W ogóle literatura (nie licząc masy miernej jakości poradników) nie zawiera pojęcia „wymaganie systemowe” w znaczeniu innym niż wymagania na platformę sprzętowo-systemową. Jednak te wymagania powinien określić wykonawca na etapie projektu implementacji a nie biznes.
W moich oczach dokumentacja wymagań powstała na bazie powyższych definicji, jest po prostu nieweryfikowalna (polecam wpis o szkodliwości dwuznaczności treści dokumentacji). Po drugie warto wiedzieć, że zamawiający nie jest w stanie (i nie powinien) precyzować wymagań innych niż biznesowe zaś wykonawca (programista, developer) oczekuje projektu a nie wymagań. Wymagania ma – określa – zamawiający, swoim językiem (więc raczej nie „import umów”), ktoś powinien umieć je zweryfikować (audyt) i zamienić na projekt tego co ma wykonać (dostarczyć) dostawca oprogramowania. Dokładnie tak jest w innych dziedzinach inżynierii, np. budowlanej.
Cytowany opis to mniej więcej taki prosty model ról w projekcie:
Mamy użytkownika, który ma wymagania co do oprogramowania, analityk wymagań je zbiera (sesje warsztatowe, ankiety, spotkania, wywiady, inne) i weryfikuje. Powstaje specyfikacja. Tak powstałe specyfikacje wymagań nie poddają się żadnej weryfikacji na kompletność i spójność, są deklaracją użytkowników bez gwarancji, że nie odkryjemy nowych wymagań lub nie uznamy wielu z nich za nadmiarowe.
Jak wygląda zalecany proces?
Bazuje na „prostej” kolejności działań opisanej na stronach OMG.org pod nazwą „proces MDA”, nie raz w moim blogu przywoływany. Proces ten ma na trzy kluczowe kroki:
- opracowanie modelu firmy: model biznesowy (procesy biznesowe, struktura org., reguły biznesowe), jest to tak zwany model CIM (Computing Independent Model), celem jego powstania jest zbudowanie narzędzia opisującego firmę Klienta, które posłuży dopiero do zdefiniowania i weryfikacji wymagań.
- opracowanie modelu PIM (Platform Independent Model), jest to opis usług systemu i ich logiki bez żadnych informacji o implementacji, to projekt oprogramowania.
- opracowanie modeli PSM (Platform Specyfic Model), jest to opis tego jak model PIM ma być implementowany (zrealizowany) i to dopiero robi developer.
Całość bazuje na klasycznej analizie systemowej (zwaną tez metoda naukową). Bazując na tym opisie powinno więc być tak:
Wygląda na dość skomplikowany proces ale to pozory. Sponsor projektu, kluczowa postać w analizie wymagań, określa cele biznesowe. One wyznaczają wszelkie priorytety w dalszej analizie np. priorytety wymagań. Sponsor stawia cele biznesowe np. podniesienie jakości obsługi reklamacji poprzez eliminację przypadków zagubień dokumentów. Powstaje model CIM, z jego pomocą wyszukujemy miejsca, w procesach biznesowych, w których te dokumenty giną lub jest ryzyko zaginięcia. I tak przechodzimy wszystkie wymagania biznesowe. Tu wymaganiem biznesowym jest cel sponsora, lista jego potrzeb i w konsekwencji dopiero użytkowników. Jednak to nie użytkownik deklaruje, że coś „chce”, takie oczekiwanie musi wynikać z celu sponsora. Wszystkie założenia, a są nimi np. oczekiwane funkcjonalności oprogramowania i teza, że zaspokajają one wymagania sponsora projektu, są weryfikowane z pomocą modeli. Modele sa tu narzędziem na etapie analizy CIM i projektem na etapie PIM.
Lista wymagań jako ankieta życzeń przyszłych użytkowników to najczęstsze źródło problemów w projektach.
Dalej cele biznesowe wyznaczają na modelu CIM jakie usługi przyszły system ma oferować jego użytkownikom, by cele biznesowe spełnić. Np. aby dokumenty nie ginęły, należ je skanować i archiwizować w sposób bezpieczny i łatwy do wyszukania zaraz po otrzymaniu. To znaczy, że System powinien udostępnić usługi: skanowanie i indeksowanie, wyszukiwanie i przeglądanie. Logika tych usług to sposób wzajemnego kojarzenia tych dokumentów i późniejszego wyszukiwania. Dokument, który to opisuje to model PIM. I to wszystko robi Analityk Biznesowy.
Koszty takiej analizy
Tu warto powiedzieć, że nie zawsze analiza w postaci kolekcjonowania np. ankiet czy wyników [[sesji JAD]] jest tańsza od projektu realizowanego opisaną metodą.
Jeżeli analizę wymagań robi jedna osoba, i jej kompetencje to tylko duże doświadczenie w takich wywiadach i tworzenie dokumentów (teksty, tabele itp.), to jej koszt może być relatywnie niski, jednak niestety tak opracowana lista wymagań to najczęściej listy cech zawierające także owe „próby implementacji” (np. „import plików umów”), bez żadnej gwarancji, że dla odmiany czegoś „oczywistego” a ważnego nie pominięto. Brak celu biznesowego sponsora nie daje zaś żadnego narzędzia do odsiewu „życzeń nadmiarowych”, zwanych potocznie w projektach „pobożnymi życzeniami użytkowników”.
Jeżeli analiza robiona jest siłą kilku konsultantów organizujących sesje warsztatowe z grupami pracowników, dokumentacja ma kilku recenzentów i trwa to np. kwartał, to jest to proces nie mniej ryzykowny, bo produktem także jest specyfikacja życzeniowa, za to bardzo kosztowna, znacznie kosztowniejsza niż praca jego doświadczonego analityka Biznesowego.
Tego typu życzeniowe dokumenty, generują bardzo duże koszty na etapie wdrażania i zarządzania zmianą (odkrywanie wymagań i ich zmiany).
Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy.
Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.
Tak więc najprościej: mamy sponsora projektu i ewentualnych innych zainteresowanych. Oni mają wymagania biznesowe – chcą coś w swoich organizacjach osiągnąć lub zmienić. Kolejny etap to analiza, której celem jest ocena czy to możliwe i jak. Jako „narzędzia pracy” powstają model tej organizacji: mapy procesów, struktura organizacyjna, system reguł i pojęć biznesowych. Produktem tej pracy są rekomendacje gdzie i jak można osiągnąć efekty wymagań biznesowych. Jeżeli zapadnie decyzja o tym, że wymagania biznesowe pomoże osiągnąć nowe oprogramowanie wspierające organizację, na bazie posiadanych modeli opracowuje się listę wymagań funkcjonalnych i poza-funkcjonalnych. Są to usługi systemu jakich od niego oczekujemy oraz ograniczenia jakościowe.
Ale to za mało, taki opis jest dopiero „wsadem” do projektowania. Nie wystarczy powiedzieć jakiej usługi oczekujemy, konieczne jest opisanie tego, jaką logikę ma każda usługa realizować i jakimi danymi zarządzać. Należy określić jaką wiedzą nadal będzie dysponował użytkownik (aktor systemu) a jaką „wiedzę” ma posiadać oprogramowanie świadczące wymaganą usługę (np. kto ma umieć policzyć podatek VAT na fakturze: użytkownik czy oprogramowanie do fakturowania). Dopiero taki opis stanowi jasne „zadanie” dla dostawcy oprogramowania, który powinien zostać wybrany dopiero po tym, jak będziemy dysponowali opisem tej logiki i jej ograniczeniami. Dlaczego? Dostawcy się zawsze w czymś specjalizują, ta specjalizacja jest czynnikiem wpływającym na to, który zrealizuje nasz projekt najlepiej. Jeżeli to przyszły wykonawca wykona analizę i projekt, jest prawie pewne, że będzie on optymalny z perspektywy specjalizacji wykonawcy a nie z perspektywy wymagań Zamawiającego.
Wszystko to dobre i daje szansę na dostarczenie oprogramowania, które rzeczywiście spełnia potrzeby klienta.
Tylko… Jak przekonać niewierzących w analizę, że to rzeczywiście jest taniej? Wielu widzi tylko to, że w fazie początkowej jest drożej. Musimy spędzić czas na poznawaniu celów i procesów klienta. Tu się też można spotkać z niezrozumieniem po co się na to traci czas, skoro mamy od klienta listę „pobożnych życzeń”.
Później „tracimy czas” na projektowanie. Przecież jest już „jakiś dokument”, niech go sobie programiści wezmą i programują (są specjalistami i sobie poradzą bez projektu, może nawet lepiej, jak im nikt nie będzie nic narzucał).
Łatwo jest zobaczyć w tych pierwszych fazach, że czas trwania się zwiększa, zwiększają się koszty. Trudno jest zobaczyć, a raczej powiązać późniejsze problemy jako bezpośrednia konsekwencja zaniechania tych polecanych czynności. Skąd wiadomo, że dokładnie temu problemowi byśmy zapobiegli?
Jeszcze dochodzi problem taki, że każdy projekt jest inny. Trudno porównać projekt, w którym działaliśmy odpowiednio z projektem, w którym zaniechaliśmy dobrych praktyk. One mają inny zakres, innego klienta, inne czynniki ryzyka, panujące warunki, itd.
Decydenci chcą dowodu, ale jak to udowodnić?
„Jak przekonać…”, nie znam sposobu innego niż … poparzenie się. 100% moich klientów to firmy po przejściach w rodzaju Agile i umowa czas i materiał albo analiza wymagań metodą ankiet i warsztatów JAD a potem masowe zarządzanie zmianą w projekcie itp. Moim zdaniem zawsze byli i będę ludzie, którzy ciężko chorują a nawet schodzą, tylko dlatego, że zamiast leczyć się u dobrych lekarzy chodzili do znachorów lub stosowali „leki” oferowane w reklamach TV.
Zawsze mówię klientom i na konferencjach: nie porównują treść analiz i specyfikacji wymagań z tym co maja po zakończeniu projektu (o ile się zakończy) im bardziej te dwa „byty” od siebie odbiegają tym gorszej jakości była analiza i wymagania.
Niestety to, że faktycznie nie da się wprost ze sobą porównywać różnych projektów powoduje tylko, że firmy niestosujące dobrych praktyk mają argumenty za tym, by ich nie stosować, ale jest miernik na który warto zwracać uwagę: najlepsze są firmy zawierające umowy o dzieło czyli deklarujące jakieś terminy i budżety i wywiązujące się z tych umów.… innymi słowy: firmy forsujące w projektach biznesowych umowy „czas i materiał” należy omijać.
Spotkałam się z jeszcze dokładniejszym podziałem wymagań 😉
Wymagania podstawowe
Wymagania biznesowe
Wymagania funkcjonalne
Wymagania techniczne
Ja też, i pytam wtedy co każde z nich oznacza i sprawdzam czy ich definicje się wzajemnie wykluczają, bo powinny… i nigdy nie zostały „obronione”.…
„Zawsze mówię klientom i na konferencjach: nie porównują treść analiz i specyfikacji wymagań z tym co maja po zakończeniu projektu (o ile się zakończy) im bardziej te dwa ?byty? od siebie odbiegają tym gorszej jakości była analiza i wymagania.”
Tak, to konkretnie możemy sprawdzić. I możemy się zdziwić jak projekt mutował do zupełnie innego kształtu:)
Ale to nadal nie udowadnia, że ta „gorsza droga” nie jest mimo wszystko tańsza.
Drążę temat, bo zachodzę w głowę jak to można udowodnić, jak przekonać do takiego sposobu pracy, jeśli głównym argumentem jest kasa, a nie obchodzi innych zgodność ze sztuką i zapobieganie ryzyku, które się nie opłaca.
Udowodnić można tylko w sferze ryzyka projektowego. Nie da się np. wykazać, że oprogramowanie wykonane na bazie krótkiego słownego opisu będzie złe lub bardzo kosztowne. Można jednak wskazać badanie ankietowe, które mówią, że (zależnie od konkretnego badania) 75 – 85% projektów ma przekroczony budżet średnio o 60% a terminy o 200% a jednym z powodów, który wskazało 100% ankietowanych była specyfikacja wymagań: braki i niespójności. Z tego wynika, że zaniedbując analizę wymagań, robiąc ją metodami nie dającymi żadnej pewności spójności i kompletności, z prawdopodobieństwem 80% przekroczymy budżet o 60% a termin o 200%. Problem w tym, że na początku wszyscy wierzą, że są w tych pozostałych 20%. :))), wiedzą to tylko Ci co mają doświadczenie …
Czyli pozostaje czekać na porażki i mieć nadzieję, że odpowiednie osoby wyciągną odpowiednie wnioski 🙂
chyba tak.… ale wyciągają bo mam, nie tylko ja, klientów 😉
Obawiam się, że nie da się udowodnić przydatności dokładnej analizy wymagań i rozdzielenia pracy analityka i dewelopera.
Wiele projektów na tym korzysta, ale jeżeli korzystają, to znaczy że to są i tak „spokojne” projekty, których szanse powodzenia są bardzo wysokie, jeżeli tylko przeprowadzane są przez profesjonalistów.
Jednak żyjemy w ciągłym postępie wyzwań. Od kilkunastu lat statystyki niepowodzeń projektów podają bardzo podobne rezultaty. Waha się tolerancja ryzyka, stare problemy są rozwiązywane tak szybko jak pojawiają się nowe.
Projekty będą nieudawać się zarówno przez niedostateczną analizę jak i przez zbyt długą analizę przedwykonawczą.
Agile jest tu przedstawiany tak, jakby powinien mieć swój kod ICD-10.
Ja ciągle słyszę, że kontrakty agile są bardzo rzadkie, stosowane są tylko w warunkach wysokiego zaufania do podwykonawcy, zwykle firmy powiązanej biznesowo. Skąd zatem biorą się kontrakty T&M w sytuacji sporego ryzyka niepowodzenia i braku przełożenia na podwykonawcę?
Jasne, że Agile to wygodny parasol dla braku pomysłu na organizację pracy i z tym trzeba walczyć. Duży kontrakt oparty o agile-by-the-book to też utopia. Z drugiej strony odrzucenie praktycznej wiedzy jaką agile przynosi jest nierozsądne.
Patrząc na kontrakty T&M to jest to w zasadzie najmowanie zasobów, problem pojawia się gdy „najęte zasoby” same się sterują (sam sobie daje robotę i sam sobie ją kontroluje).
Co do kłopotów z powodu zbyt długich analiz przedwykonawczych to zgadzam się w 100%: wiele firm generuje megapracochonne analizy przedwykonawcze i analizy wymagań jako uzasadnienie wysokich budżetów. To często patologiczna konsekwencja kontraktów T&M na te analizy. Znam kilka firm z tak rozbuchaną, niezrozumiałą i nadmiarową metodyką, że…
Nie odrzucam praktyki Agile, prawdopodobnie sam ją stosuję, rozpoczynając projekt od ustalenia jakie niezbędne dokumenty powinny postać by osiągnąć cele projektu minimalnych ryzykiem i minimalnym kosztem zarazem (kompromis). To co mi się „nie podoba” w projektach (z perspektywy kupujących) to rozpoczynanie ich na bazie jedynie wizji, czyli luźnego pomysłu…
Nie neguję prezentowanego na tym blogu podejścia. Zwracam tylko uwagę na isnienie obszarów wymagających bardziej elastycznych rozwiązań.
Paradygmaty pracy analityka jednak zwykle (tylko z ostrożności nie powiem „zawsze”) pozostają te same: dokumentacja operująca językiem klienta, zrozumienie potrzeb użytkowników (które niekoniecznie są torżsame z wyrażanymi oczekiwaniami), przejrzystość metod i weryfikowalność efektów pracy.
Około połowy projektów, w których brałem udział była w modelu t&m. I to były te, które najczęściej kończyły się dobrymi wynikami – chociażby dlatego, że tego typy kontrakty dowodzą spokojnej sytuacji, dużego poziomu zaufania i sporej tolerancji dla wyników. Były to też zlecenia typu „zróbcie coś, żeby rozwiązać problem i zadowolić klienta”.
Dużo sprowadziłbym do poziomu tolerowania ryzyka przez Sponsora (może być wewnątrz organizacji albo Klient). Jeżeli Sponsor akceptuje, że mając:
– pomysł
– trochę wiary we własne siły
– statystyczne dane o podobnych projektach (pochodzące z naszej organizacji)
– usystematyzowaną relację dostawca-klient, opierającą się na porozumieniu co do tego, że nikomu nie opłaca się kończyć kontraktu w sądzie, zamiast wdrożeniem;
to może zaakceptować krótką analizę, przyrostowe tworzenie systemu, tolerancję zmian podczas wykonania i mnóstwo małych ryzyk, które sprowadzają się do konieczności wykonania niezbędnych działań jak najszybciej.
Jeżeli chodzi o wskazane paradygmaty to jest z tym problem, bo zbierając wnioski z projektów mających problemy mogę powiedzieć, że w 100% przypadków można odhaczyć to, że źródłem wymagań byli przyszli użytkownicy, analitycy w zasadzie tylko „przetwarzali” ich „potrzeby” do postaci zgodnej ze stosowaną metodą pracy (najczęściej tabelki z zestawieniami lub przypadki użycia). Druga przyczyna problemów do odhaczenia: programiści budowali model dziedziny, w efekcie był zawsze zbyt uproszczony (bo mniej klapania w klawisze i łatwiejszy w implementacji, jak ja to często słyszę) co skutkowało blokadą przyszłych zmian i rozszerzeń. Osobiście uważam, że powyższe metody są najbardziej ryzykowne.
Projekty T&M nie są złe z zasady, one po protu z zasady wymagają bardzo dużych narzutów na niewiedze na etapie ich kontraktowania, rzecz w tym, że paradoksalnie projekty fixed price wychodzą taniej, są realizowane szybciej i dają nie gorsze produkty :). Od lat mam do czynienia ze składanymi ofertami na moje i wcześniejsze u klientów zapytania, zaryzykuje tezę, że regułą jest iż oferty T&M są kosztowniejsze a projekty w efekcie potem trwają dłużej.
Daleki jestem od tezy, że T&M tworzy złe (gorsze produkty), ale po 20 latach stawiam tezę, że są prawie zawsze kosztowniejsze i trwają dłużej. Kluczem jest tu stwierdzenie, że „projekty T&M wymagają dużej dozy tolerancji” z czym wypada mi się zgodzić. Ta tolerancja jednak to nic innego to akceptowanie faktu, że dostarczony produkt (nawet w terminie i budżecie) ma mniejszą lub wręcz inną funkcjonalność niż zakładano na początku projektu.
Piszę to generalnie z perspektywy klientów (prawie zawsze reprezentuję właśnie ich). Oni mówią często o programistach (firmach) jedno: fajna firma, fajni ludzie, można się z nimi dogadać i bez problemu im zapłaciliśmy. Więc z perspektywy dostawcy mamy sukces. Problem w tym, że moja tam obecność bierze się stąd, że oni nadal nie mają tego co było pierwotnie celem a chcą i potrzebują tego… W 100% przypadków moich projektów (bo prawie nikt nie zainwestuje w analityka za pierwszym razem, zresztą najczęściej odradzają to sami dostawcy oprogramowania) słyszę: teraz chcemy przed rozpoczęciem projektu mieć dokument, który opisuje co zamawiamy.
Wszystko ładnie działa zanim nie pojawi się wynik pracy dostawcy 🙂 Problem pojawia się podczas wdrożenia tego, co zostało zamówione, gdy okazuje się, że oczekiwania były inne.
Mamy dwie drogi – lepsza analiza, co w wielu wypadkach przekłada się na czas, albo szybsze wdrożenie umożliwiające szybkie uzyskanie informacji zwrotnej. Fixed price sprzyja pierwszej drodze, T&M drugiej.
Fixed price sprzyja większej koncentracji uwagi na początku projektu. Sprzyja też nadmiarowej specyfikacji wymagań.
Zgadzam się z tym, że „Fixed price sprzyja większej koncentracji uwagi na początku projektu. Sprzyja też nadmiarowej specyfikacji wymagań.”. Z tym drugim trzeba walczyć, bo nie raz jest to przejaw bezsensownie stosowanych tak zwanych „ciężkich” metodyk i braku kompetencji maskowanego ilością dokumentów. Nie lubię słowa Agile bo często rodzi wiele niepotrzebnych emocji, ale analizy też powinny być „zwinne”, rzecz w tym, by z pełnego arsenału narzędzi i diagramów wybrać tylko te, które prowadzą do celu a celem jest obniżenie ryzyka projektu a nie wytworzenie dokumentacji. Już pojawiły się Agile RUP itp… Ja cały czas traktuję (poza pracami badawczymi) T&M jako skuteczny sposób na braki kompetencji projektowych po obu stronach projektu (głównie projektowanie i planowanie), bo niestety często także Klient mocno przykłada rękę do porażki swojego projektu. Z mojej perspektywy szkodliwe jest to, że firmy programistyczne podejmują się projektu widząc już na początku „słabość klienta”. Rozumiem że „muszą” mieć przychody, ale czy aby na pewno „za wszelka cenę”?
Jak słyszę/czytam Agile, to mam dreszcze. Zwłaszcza to pisane z dużej litery czy wymawiane z emfazą. Zainteresowałem się tematem kilka lat temu i zdążyłem już się dowiedzieć, żę nie jest ważne czy sterta rzeczy do zrobienia to backlog, a nawet czy kontrakt jest T&M czy FP. A na pewno nie chcę brać udziału w dyskusji pod tytułem „czy to jest agile?”. To jest dla mnie przykład niewłaściwie postawionego pytania.
Problem z T&M mam taki, że pociąga za sobą kosztowne korowody z podchodami „kto tu się bardziej wystawia”. Lepszym rozwiązaniem wydaje mi się cost plus, czyli T&M z bonusem zapewniającym zysk dla dostawcy. Wtedy strategia przegrać wszystko albo wygrać wszystko zamienia się na nie stracić albo wygrać jeszcze więcej. Bo zamiast dostawcy wypełniającego dokładnie warunki zamówienia (i często nie mającego motywacji do zrobienia czegoś lepiej niż zamówiono) dostajemy dostawcę dążącego jak najszybciej do wspólnego celu.
Ta strategia, T&M i bonus wydaje się być sensowna bo obie strony mają motywację. Ryzyko jakie widzę czasami polega na tym, że Klient często nie ma kompetencji by merytorycznie nadzorować wykonawcę więc musi polegać na jakości pracy i etyce wykonawcy. Jak bumerang wraca temat nadzoru autorskiego, brzy braku pierwotnego projektu nadzór już nie jest „autorski” a jedynie merytoryczny… ale każda droga podniesienia jakości jest słuszna. Myślę, że generalnie problem ten dotyczy nieuczciwych firm… po obu stronach barykady zresztą.