Reading Time: 5 minutes
W tworzeniu oprogramowania, przesłanka dobra, szybka i tania jest trudna do osiągnięcia. Czy możemy uzyskać wszystkie trzy? Czy możliwe jest osiągnięcie równowagi? Opowiemy Ci o tym tutaj.
Wielu z nas, pracujących w branży oprogramowania, rozpoczynając pracę nad wycenami projektów, konsultacjami czy szacunkami, stanęło przed niemal nieuniknioną koniecznością ze strony rynku: tworzenie dobrego, szybkiego i taniego oprogramowania. Czy możliwe jest posiadanie tych trzech zmiennych w tym samym czasie? Czy ten pomysł jest utopijny?
Aby odpowiedzieć na to pytanie i zobaczyć wykonalność tego postulatu, ważne jest, abyśmy najpierw przejrzeli dwie kluczowe idee.
Jaką cenę można umieścić na niematerialnym podmiocie?
Oprogramowanie jest niematerialnym produktem; nie możemy go zobaczyć, ani poznać jego dobroci, dopóki nie zostanie ukończone. Ustalenie ceny na rozwój oprogramowania jest czymś złożonym (chyba, że kupujesz oprogramowanie w pakiecie, a nie na zamówienie), nie tylko ze względu na subiektywność, która istnieje w odniesieniu do jego wartości (w oparciu o wiele kryteriów), ale także ze względu na istniejące różnice dotyczące tego, czy projekt jest łatwiejszy czy bardziej złożony do wykonania.
Oszacowania, filar sukcesu
Zważywszy na moment, w którym mamy do czynienia z niematerialnością, dokonanie poprawnego oszacowania – i tak dokładnego, jak to tylko możliwe, biorąc pod uwagę, że jest to przybliżenie – jest bardzo ważne, aby uniknąć przekroczenia budżetu i straty czasu.
Powiązane z treścią: 10 przydatnych wskazówek dotyczących szacowania projektów programistycznych
Mając na uwadze, że dobre oszacowanie jest podstawą sukcesu projektu deweloperskiego, nie możemy pominąć faktu, że każde oszacowanie przekłada się na roboczogodziny. Profesjonalna jakość członków zespołu i ich doświadczenie są wprost proporcjonalne do kosztu rozwoju.
W skrócie, wiedząc, że szacowanie, planowanie i realizacja projektu są wykonywane przez ludzi, możemy wywnioskować, że jakość i doświadczenie profesjonalistów wpływa na koszt projektu.
Dobre, szybkie i tanie
Zrozumiawszy, że oprogramowanie jest niematerialnym bytem, którego cena jest trudna do zdefiniowania, szczególnie jeśli nie ma jasnego oszacowania, przejdźmy do wyjaśnienia atrybutów dobrego, szybkiego i taniego i jak można je połączyć, ale nie mieć wszystkich trzech jednocześnie.
Dobrze i szybko
Z szybkością można zrobić coś dobrego. Aby to osiągnąć, należy dobrze oszacować, a następnie mieć dobry plan wykonania projektu, tak aby szybkość nie wpłynęła na jakość rezultatu.
Klucz do osiągnięcia jakości i szybkości leży w ludziach pracujących nad projektem, którzy muszą być wystarczająco wykwalifikowani, aby poradzić sobie z projektem. Pamiętaj, że jakość specjalistów jest czynnikiem decydującym o kosztach.
Bierz pod uwagę, że szybkość może być przeciwna do produktywności: W teorii, zespół (i jego członkowie) osiąga szczyt produkcji w określonym czasie i utrzymuje go do końca projektu. Im większa prędkość, tym krótszy czas, w którym zespół będzie w szczytowej wydajności.
Podobnie, koordynacja będzie również czynnikiem do przeanalizowania: Im więcej osób pracujących równolegle, tym większa wymagana koordynacja (być może należy dodać więcej osób jako koordynatorów).
Dobrze i szybko ma zastosowanie zwłaszcza w przypadku projektów krytycznych lub kluczowych, gdzie jakość produktu musi być zagwarantowana za wszelką cenę. W takich przypadkach konieczne jest posiadanie zespołów z dużym doświadczeniem. W takim przypadku rozwiązanie będzie dobre i szybkie, ale i drogie.
Szybko i tanio
Jest to druga z naszych kombinacji trzech zmiennych: Najprostszym sposobem na zrobienie czegoś szybko i tanio jest zrobienie tego bez jakości lub przynajmniej ze świadomością, że może być ona gorsza od pożądanej. Możemy poświęcić jakość do punktu, tak długo, jak oprogramowanie nie obsługuje krytycznych informacji, lub nie zależy od jakiejś wrażliwej części organizacji.
Dla efektów szybkości – ponieważ w przyszłości jakość aplikacji może być poprawiona-, możliwe jest, aby przejść do produkcji z kluczowych funkcji dla produktu do pracy. W takich przypadkach można zrobić tak:
- Zminimalizować jakość kodu
- Uprościć jego użyteczność
- Opuścić przeglądy kodu
- Zmniejszyć kontrolę jakości i testowanie.
Postępując w ten sposób, najprawdopodobniej otrzymamy narzędzie o podstawowej funkcjonalności, ale nie otrzymamy w 100% zadowalającego produktu. Jego użyteczność może nie być najlepsza, podobnie jak jakość kodu, a jego rozszerzalność (możliwość zmiany lub rozbudowy) i reużywalność może być problematyczna.
Odnosi się to do aplikacji demonstracyjnych, testowania koncepcji, oprogramowania niekrytycznego lub każdej aplikacji, która jest skalowalna lub rozszerzalna w czasie.
Dobrze i tanio
Daję ostatnie z naszych równań: Jeśli klient chce dobrego i taniego rozwiązania, nie może oczekiwać szybkiej dostawy.
Coś dobrego i po akceptowalnych kosztach można zrobić, ale ze szkodą dla czasu. Zasadniczo, jeśli jest czas, łatwiej jest planować – ponieważ nie ma tak wielu zadań równolegle i nie jest wymagana tak duża koordynacja-, a szczyt produktywności zaangażowanych osób będzie na szczycie dłużej.
Uzyskanie czegoś dobrego i taniego jest odpowiednie dla projektów, w których czas nie jest krytyczną zmienną, a także dla projektów przyrostowych lub z zespołami z częściowym czasem (które mają wewnętrzne projekty lub inicjatywy).
Nie przegap tego: Jakość oprogramowania czy cena: Which one really matters?
To Sum Up
W tworzeniu oprogramowania postulat tworzenia oprogramowania dobrego, szybkiego i taniego jest bardzo trudny do osiągnięcia. Zawsze uda nam się uzyskać dwa z nich, ale z pozostałych będziemy musieli zrezygnować. W ten sposób można osiągnąć jakość w określonym czasie i za rozsądną cenę; trzeba tylko wiedzieć, jak znaleźć równowagę między tymi trzema zmiennymi, znać ich implikacje i sposób, w jaki się ze sobą łączą, aby tę równowagę osiągnąć.
Dochodzenie do tej równowagi będzie możliwe tak długo, jak długo szacunki, koordynacja, wybór zespołu, metodologia pracy oraz wykorzystanie narzędzi i technologii będą właściwe.
Czy osiągnąłeś równowagę pomiędzy tymi zmiennymi w jakimkolwiek projekcie? Jak to zrobiłeś?
.