Zarządzanie projektami IT | by Duncan Haughey | Czytaj minuty czasu
Zacznijmy od niepokojących statystyk. Według raportu Standish Group w 2015 r.tylko 29% projektów oprogramowania odniosło sukces, 52% zostało zakwestionowanych (przekroczenie kosztów, przekroczenie budżetu lub braki w treści), a 19% nie powiodło się. Chociaż te ustalenia pojawiły się kilka lat temu, wyniki są nie mniej prawdziwe dzisiaj.
ponadto odsetek projektów uznanych przez Klienta za wartościowe wynosi 59%, a projektów uznanych przez Klienta za zadowalające 56%.
niezadowalające wyniki projektu stały się normą branży IT, w której klient nie był zadowolony z rezultatu. Więc co możemy z tym zrobić?
dobrym punktem wyjścia jest zajęcie się niektórymi z krytycznych powodów niepowodzenia projektów oprogramowania.
powód 1: za mało czasu
często termin jest ustalany przed rozpoczęciem projektu i nie podlega negocjacjom. Ten termin skutkuje nagłym pośpiechem, aby rozpocząć pracę z założeniem, im szybciej zaczniesz kodować, tym szybciej skończysz projekt.
pośpiech do rozpoczęcia kodowania jest prawie zawsze złym podejściem. Ważne jest, aby poświęcić czas na stworzenie dobrego projektu. Brak dobrego projektu prowadzi do ciągłych zmian w fazie rozwoju. Kiedy tak się dzieje, czas i budżet są zużywane w szybkim tempie.
rozwiązanie:
- nie daj się skusić, aby przejść od razu i rozpocząć kodowanie.
- Przypisz wystarczająco dużo czasu, aby stworzyć dobry projekt, a reszta projektu będzie działać znacznie lepiej.
takie podejście poprawi twoją reputację, gdy dostarczysz coś, co spełni oczekiwania Twoich klientów i działa poprawnie po raz pierwszy.
powód 2: niewystarczający budżet
wiele projektów ma najniższą cenę, najbardziej udaną politykę dostawców lub nierealistycznie niski budżet, nie oparty na wymaganiach projektu. Kiedy tak się dzieje, wszystko zwalnia. Zasoby przybywają powoli lub nigdy nie docierają; narożniki są cięte, a jakość cierpi.
rozwiązanie:
- bądź realistą w kwestii budżetu i opieraj się na pełnych wymaganiach.
- unikaj opierania wyboru dostawcy wyłącznie na najniższej cenie.
- idź do dostawcy lub zespołu z udokumentowaną historią realizacji w ramach budżetu.
- Użyj listy kontrolnej wyboru dostawcy, takiej jak ta poniżej, aby znaleźć odpowiedniego dostawcę dla swojego projektu.
Powód 3: Słaba komunikacja
jest powiedzenie „nigdy niczego nie zakładaj”, co dotyczy szczególnie projektów programistycznych. Dobra komunikacja z klientem, użytkownikami i zespołem programistów ma kluczowe znaczenie dla sukcesu projektu. Zadaj sobie trzy pytania:
- czy wszyscy w zespole cię rozumieją?
- czy oni wiedzą, czego od nich oczekujesz, czy założyłeś, że wiedzą?
- czy dobrze komunikują się ze sobą, z użytkownikami i z innymi działami?
:
- Znajdź jakieś awarie komunikacji. Mogą one prowadzić do nieporozumień i komplikacji w późniejszym etapie projektu.
- nigdy nie zakładaj, że wszyscy rozumieją wszystko, co dzieje się w projekcie.
- poświęć trochę czasu na stworzenie środowiska, w którym komunikacja jest dostępna, otwarta i częsta.
powód 4: nigdy nie sprawdzaj postępu projektu
w miarę postępu projektu rzeczy zmieniają się, co znacząco wpływa na projekt. Ważne jest, aby stale analizować postępy w projekcie, aby wcześnie przezwyciężyć wyzwania i ostrzec zainteresowane strony o możliwych opóźnieniach i zmianach wyników.
rozwiązanie:
- zawsze ustalaj kamienie milowe, aby przeglądać postępy z zespołem i interesariuszami podczas projektu. Dostosuj się, aby utrzymać kurs.
- Bądź blisko swojego zespołu, aby zrozumieć, co się dzieje i jakie wyzwania stoją przed nimi.
powód 5: niewystarczające testy
kiedy presja dostarczenia jest włączona, testowanie często cierpi. Testowanie zostaje pozostawione do końca cyklu rozwojowego przy minimalnym wysiłku poświęconym testowaniu. Zazwyczaj rezultatem jest produkt pełen błędów i niezadowolony klient.
rozwiązanie:
- przeprowadzaj testy w całym cyklu życia oprogramowania, testując każdy moduł lub komponent w miarę jego rozwoju.
- pozostaw testy integracji tylko do końca cyklu rozwoju, co skutkuje mniejszym stresem i lepszym produktem.
powód 6: testowanie w środowisku produkcyjnym
zaskakujące jest, jak wiele organizacji testuje produkty w swoim środowisku produkcyjnym. Korzystanie ze środowiska produkcyjnego jest strategią wysokiego ryzyka, która może prowadzić do naruszenia bezpieczeństwa i przypadkowego uwolnienia bez testowania, zakłócając systemy produkcyjne.
rozwiązanie:
- opracowanie procesu zapewnienia jakości i wydania nowego oprogramowania.
- Zapewnij środowisko oddzielone od środowiska produkcyjnego do testowania i naprawiania błędów.
powód 7: Brak Zapewnienia Jakości
często w naszym pośpiechu dostarczania oprogramowania cierpi zapewnienie jakości. Dokumentacja jest niekompletna dla zmian w kodzie, projekt zawiera błędy, a implementacje mogą być niedokończone. Wszystko to prowadzi do przeróbek, straconego czasu i ostatecznie niezadowolonych klientów.
rozwiązanie:
- poświęć trochę czasu na sprawdzenie jakości i udokumentowanie oprogramowania przed wydaniem.
- Recenzja Michael L Young Artykuł 6 czynniki sukcesu w zarządzaniu jakością projektu
powód 8: Brak zgodności ze standardami branżowymi
zgodność ze standardami branżowymi w projektach oprogramowania może okazać się korzystna, zapewniając dobrą dostępność, przenośność, użyteczność, solidność oraz redukując obecne i przyszłe problemy. Organizacje takie jak World Wide Web Consortium (W3C) i International Organisation for Standardisation (ISO) opracowały otwarte standardy, które są trudne do zakwestionowania.
rozwiązanie:
- poświęć trochę czasu na wprowadzenie podejścia standardowego dla swoich projektów.
- znajdź to, co działa dobrze i rób to dalej.
- zmień wszystko, co nie działa.
- regularnie Przeglądaj i aktualizuj swoje standardy.
następnym razem, gdy zarządzasz projektem tworzenia oprogramowania, przejrzyj tę listę i Przypomnij sobie, co jest potrzebne do zapewnienia sukcesu. Będziesz zaskoczony, to robi różnicę.
polecam lekturę: Ciekawy przypadek raportu chaosu 2009 autorstwa Jorge Domingueza.