14 najczęstszych powodów niepowodzenia projektów oprogramowania (i jak ich uniknąć)

Zdjęcie:

Getty

zespoły techniczne często pogrążają się w nowych projektach oprogramowania z dużymi nadziejami, Co tym bardziej frustruje, jeśli projekt zostanie wykolejony. Liderzy technologii muszą być świadomi potencjalnych pułapek projektowych z wyprzedzeniem, aby uniknąć marnowania czasu i pieniędzy budżetowych.

eksperci Rady technologicznej Forbesa nadzorowali wiele projektów w swojej zawodowej kadencji. Poniżej 14 z nich ma wspólne powody, dla których projekty programistyczne flunder i co zespoły techniczne mogą zrobić, aby uniknąć wpadnięcia w pułapkę.

1. Brak zrozumienia potrzeb firmy

jednym z powodów niepowodzenia projektów programistycznych jest brak zrozumienia potrzeb firmy. Firma musi jasno sprecyzować wymagania w szczegółach. Konieczne jest precyzyjne mapowanie funkcji i funkcji do potrzeb firmy. Przydzielenie doświadczonego lidera biznesowego do zespołu projektowego jest niezbędne do sukcesu. – Wesley Crook, FP Complete

2. Niezdolność do osiągnięcia konsensusu w sprawie priorytetów

istnieje wiele powodów, dla których projekty programistyczne zawodzą, ale częstym, który ma duży wpływ, jest sytuacja, gdy sponsorzy projektu i zespoły projektowe nie są wyraźnie dopasowane do najważniejszych priorytetów projektu. Rozłożenie tych priorytetów na „niezbędne”, „powinny” i „mogłyby” może zapewnić solidne ramy dla iteracji i realizacji poszczególnych funkcji. – Jahn Karsybaev, Prosource IT

3. Brak jasności i strategii realizacji

głównym celem projektu oprogramowania jest rozwiązanie problemów biznesowych. Wymaga to nie tylko skutecznego i wydajnego zarządzania projektami i zarządzania oczekiwaniami interesariuszy, ale także jasnego konsensusu całej grupy interesariuszy w sprawie definicji problemu biznesowego i solidnej strategii realizacji w celu dostarczenia Oprogramowania, które rozwiązuje cele biznesowe. Niezastosowanie się do któregokolwiek z powyższych aspektów skutkuje wykolejeniem projektu. – Kartik Agarwal, TechnoSIP Inc.

4. Nie zaczynając od klienta końcowego

czasami Projekty oprogramowania zaczynają się od świetnego pomysłu, który jest wdrażany (na czas lub późno) i dostarczany tylko dla programistów, aby odkryć, że problem, który rozwiązali, nie był tak naprawdę problemem, który ich klient musiał rozwiązać. Wykonywanie ciężkiej pracy polegającej na głębokim zrozumieniu klientów, ich potrzeb i kosztów, które są w stanie zapłacić, wyznacza pułap wydajności projektu i może pomóc w skupieniu zespołu, gdy sprawy się wykoleją. – Guy Yalif, Intellimize

5. Niejasne wymagania

jednym z najczęstszych powodów niepowodzenia projektów programistycznych są niejasne wymagania i brak szczegółowego wyjaśnienia. Bardzo często sami klienci nie są pewni, co dokładnie chcą zobaczyć, w wyniku czego projekt nie może iść do przodu. Komunikacja z klientami i proszenie ich o szczegółową wizję przyszłości produktu jest kluczem do zapewnienia, że projekt nie zawiedzie. – Daria Leshchenko, SupportYourApp Inc.

6. Zbyt często spodziewając się „srebrnej kuli”

, entuzjazm bierze się z fałszywego przekonania, że przysłowiowa „Srebrna kula” rozwiąże dany problem. Jednak właściwe rozwiązania rzadko są tak proste—są połączeniem metodologii, strategii i wsparcia zespołu, a nie efektem pojedynczego działania, technologii czy pomysłu. Liderzy technologii powinni zachęcać do otwartej komunikacji i wykorzystywać partycypacyjne podejmowanie decyzji w grupach w celu rozwiązywania problemów. – Christopher Yang, Corporate Travel Management

7. Praca w silosie

największym powodem niepowodzenia projektów programistycznych jest to, że zespoły wyruszają w podróż, aby zbudować coś, co albo nie jest potrzebą biznesową, albo nie rozwiązuje WŁAŚCIWEGO problemu. Obie przyczyny są wynikiem niewspółosiowości między biznesem a technologią. Aby tego uniknąć, ważne jest, aby zidentyfikować problem, który firma stara się rozwiązać, a następnie współpracować z firmą, a nie w silosie. – Tanvir Bhangoo, Freshii inc.

8. Myśląc, że Zakres można zdefiniować z góry

chociaż ważne jest zrozumienie problemu i zdefiniowanie przypadków użycia z góry, prawie żaden projekt nie może być uznany za udany, jeśli nie dostosuje się do zmieniających się wymagań biznesowych podczas rozwoju. Niestety, niektóre zespoły techniczne nadal nalegają na osiągnięcie pierwotnego celu, co czyni ich wysiłek nieskutecznym, a nawet porażką. – Song Bac Toh, Tata Communications

9. Brak koordynacji i szczegółowego planowania

wiele projektów oprogramowania spóźnia się lub zawodzi z powodu braku dobrej koordynacji i szczegółowego planowania. Zespoły muszą wdrożyć oddolny proces planowania, który identyfikuje zależności między rezultatami i obejmuje szacunki od samych inżynierów. Po ustaleniu planu wydania prowadzę codzienne 15-minutowe spotkania stand-up, na których pojawiają się problemy, a nowe zagrożenia są identyfikowane i zarządzane. – Dave Mariani, AtScale

10. Tarcie spowodowane niezdefiniowanymi rolami

niezdefiniowanymi rolami często powoduje tarcie na zespołach projektowych. Spróbuj użyć DACI framework od samego początku, aby jasno określić, kto ma władzę nad czym. W przypadku zablokowanych projektów ponowna kalibracja tego, kto jest kierowcą, zatwierdzającym, współtwórcą i poinformowanym w ramach projektu, może działać jako twardy reset, inspirując odnowioną współpracę i autonomię. – Leore Avidar, Lob.com Inc.

11. Oczekując nadmiernej customizacji oprogramowania

często wierzymy, że oprogramowanie można dostosować do poziomu, który będzie dostosowany do wszystkich potrzeb. To nieporozumienie. Bycie realistą jest ważne. Określ wymagania dotyczące możliwości oprogramowania. Składanie próśb o zmiany w trakcie gry wymaga poprawek, ale to jest kapelusz, który trzeba nosić, aby uniknąć frustracji. – Bhavna Juneja, Infinity, A Stamford Technology Company

12. Brak dyscypliny

gdybyśmy mieli zbudować dom i ciągle zmieniać plan, budżet projektu wymykałby się spod kontroli i termin po terminie byłby pomijany. Stwórz wizję tego, jak wygląda sukces projektu. Zamknąć i wykonać. Każdy inny świetny pomysł i objazd można rozważyć w późniejszej fazie projektu. – Sam Polakoff, Nexterus, Inc.

13. Zbyt wiele rąk w Puli deweloperów

ustala (i ogranicza), kto jest zaangażowany od pierwszego dnia, niezależnie od tego, czy budujesz w domu, czy nie. Może to być trudne dla większych firm technologicznych ze złożonymi procesami i kanałami komunikacji. Ale w świecie tworzenia aplikacji taka złożoność jest szkodliwa dla stworzenia w pełni zrealizowanego produktu, który pasuje do unikalnej wizji każdego bez padania ofiarą pełzania zakresu i niekończącej się osi czasu projektu. – Joshua Davidson, ChopDawg.com

14. Niewystarczający nacisk na umiejętności miękkie

wyraźne i znaczące skupienie się na zarządzaniu procesem zmian jest często niewystarczające lub niewystarczające. Widziałem wiele projektów programistycznych w różnych kategoriach i w szeregu różnych typów i rozmiarów organizacji napotykających wyzwania, ponieważ są one super skoncentrowane na pracy technicznej, ale nie zużywają wystarczająco dużo energii na szkolenia, coaching, budowanie zespołu i umiejętności miękkie. – Amith Nagarajan, rasa.io