Wstęp Temat licencjonowania i wyceny wartości oprogramowania przewija się często w moich projektach. Bywam nie raz proszony o wycenę posiadanego oprogramowania co, jak nie trudno się domyśleć, nie jest proste. Powszechnym zjawiskiem jest zawyżanie lub zaniżanie tej wartości, zależnie od tego do czego wynik wyceny zostanie użyty. Tam gdzie przedmiotem wyceny są posiadane aktywa, wyceny są często zawyżane przez sprzedającego udziały a zaniżane przez ich nabywcę. Bardzo często podejmowane są próby bazowania na cenach transakcyjnych, jednak są to wyceny obarczone przypadkowością, gdyż są to tak naprawdę wyceny spekulacyjne, obarczone wpływem…
Tytułowe User Story i Story Mapping miały (mają) być remedium na problemy z wymaganiami. Czy są nim? Słownik Języka polskiego: rozwiązanie: ?projekt i realizacja założeń architektonicznych, konstrukcyjnych, plastycznych itp.? Innymi słowy rozwiązanie to określone narzędzia pracy. W tym przypadku narzędziem jest aplikacja (oprogramowanie). Nadal popularne wśród developerów user story, jako narzędzie opisu wymagań pokazało swoje wady, lekarstwem na nie ma (miało) być story mapping. Kluczową wadą tego (użytkownik opisuje aplikację) podejścia jest założenie, że użytkownik ma racje (wie czego chce). Problem w tym, że nawet jeżeli użytkownika wie co robi,…
Krzywy Dom zaprojektowany przez Szczepana i Małgorzatę Szotyńskich
Jak widać próba wyceny całego projektu już na samym jego początku to wróżenie z fusów, wykonawca przyjmie wartość bezpieczna dla siebie, a tak określony budżet i tak zostanie skonsumowany (co pokazuje praktyka, tak się składa oferty w przetargach publicznych, taka jest jakość większości zapytań przetargowych!).
Wystarczy wydzielić etap projektowania (analiza i projektowanie to ok. 20% kosztu developmentu) i zawrzeć umowę na etapie co najmniej wstępnego projektu, wtedy "zawyżanie" (narzucanie zapasu na niewiedzę) spada dwukrotnie. Opracowanie kompletnego projektu przed wyceną prac developmentu to obszar bliski prawej części: estymacja kosztu z bardzo małym błędem.
