Pisanie oprogramowania na zasadzie konsultacji może często być przegraną propozycją dla programistów lub klientów lub obu. Jest zbyt wiele rzeczy, które mogą pójść nie tak, a to ostatecznie przekłada się na stratę czasu i pieniędzy. Zasada 15%, którą wymyśliliśmy, ma na celu stworzenie sytuacji, w której obie strony wygrywają.
Klienci generalnie dostają to, czego chcą, a sklepy deweloperskie osiągają uczciwy zysk. Idealne rozwiązanie, ale jak dotąd wydaje się, że działa dla nas.
Dla niektórych może się to dziwić, ale zarabiamy bardzo mało na sprzedaży licencji na oprogramowanie. Zdecydowana większość naszych przychodów pochodzi z usług doradczych, którzy piszą kod do wynajęcia. Robiąc to już od kilku lat, nauczyliśmy się kilku trudnych lekcji. W przypadku kilku projektów lekcje były tak trudne, że faktycznie straciliśmy pieniądze. Kilka miesięcy temu przygotowałem dokument typu manifest, który ma na celu rozwiązanie problemów, z jakimi mieliśmy do czynienia przy tworzeniu oprogramowania dla klientów. Z przyjemnością stwierdzam, że zauważyłem znaczącą różnicę. Mam nadzieję, że to wejście na bagna zostanie odczytane przez innych, którzy opracowują oprogramowanie w oparciu o konsultacje, aby mogli nauczyć się tych lekcji w łatwy sposób, a nie w sposób, w jaki się ich nauczyliśmy. W tym artykule znajduje się podsumowanie jednej z głównych zasad, które stosujemy obecnie przy opracowywaniu oprogramowania z zasadą 15%. Jeśli masz ochotę, zapoznaj się z pełnym dokumentem Nasze podejście do tworzenia oprogramowania. Dla niecierpliwych, reguła 15% przebiega w ten sposób, przed podjęciem projektu rozwojowego tworzymy deklarację pracy (która działa jak umowa i specyfikacja), która określa, co należy zrobić, ile godzin będzie wymagać i ile będzie kosztować klienta. W ramach umowy zobowiązujemy się inwestować do czasu określonego w dokumencie plus 15%. Oznacza to, że jeśli oświadczenie o pracy mówi, że wykonanie projektu zajmie nam 100 godzin, wydamy do 115 godzin (ale nie więcej). Co do tego, gdzie - las i dlaczego - rzucaj na to, jak to działa, czytaj dalej. Ci, którzy opracowali oprogramowanie do wynajęcia wiedzą, że produkt końcowy prawie nigdy nie kończy się dokładnie tak, jak klient sobie wyobrażał. Nieustannie trzeba dokonywać poprawek (które mogą lub nie były dyskutowane z góry), aby uzyskać to co najmniej przypominające to, co klient ma na myśli. I tak, może się tak zdarzyć, nawet jeśli spędzasz godziny na drobnym dostrajaniu specyfikacji, aby odzwierciedlić życzenia klienta. Ponadto mogą pojawić się problemy techniczne, których zespół programujący nie przewidział. Teoretycznie im lepszy zespół programistyczny, tym mniej prawdopodobne, że tak powinno być, ale nie zawsze tak kończy się (system operacyjny Microsoft Vista to niezły przykład). Te dwa czynniki to m.in. ryzyko związane z projektem. Coś nie pójdzie dobrze, a to prawie zawsze oznacza, że ktoś płaci lub traci więcej pieniędzy, niż początkowo przewidywano. Pytanie brzmi, kto powinien być odpowiedzialny za rozliczenie tych dodatkowych dolarów? Aż do niedawna braliśmy na siebie prawie całe ryzyko w naszych projektach. Jeśli aplikacja nie robi tego, co klient miał na myśli, lub jeśli pojawiły się nieprzewidziane problemy techniczne, to zwykle wychodzi z naszych kieszeni. W przeważającej części nie może stanowić większego problemu, ale zawsze wydawało się, że ma przynajmniej pewien efekt ( skrajne przypadki są oczywiście wtedy, gdy straciliśmy pieniądze na projekt). To wydaje się niesprawiedliwe, prawda? Ryzyko związane z projektem nie musi być winą żadnej ze stron. Właśnie tam jest. Nie umieściliśmy go tam, ani klient. W związku z tym nie powinno być tak, aby jedna ze stron brała to wszystko pod uwagę.
Jak powstaje oprogramowanie