„Az alkalmazás kedden készül el.” - melyik kedden?!

10 ok, amiért a szoftverfejlesztési projektek kudarcot vallnak

Ha online keres a szoftverfejlesztés trendjeiről, akkor végtelen információs forrásokat talál a virágzó technológiákról és arról, hogy a technológia miként fogja befolyásolni minden ágazatot 2020-ig. Hallunk minden csodálatos változásról, amelyet az új technológia ad nauseam készít, de én ' Itt szeretném megkérdezni az előző mondat utolsó részét.

„2020-ig”. Azoknak közületek, akik nem beszélnek „szoftvermérnökről”, az azt jelenti, hogy 2040.

Mivel az egyetlen srác a Crane.ai-nál, aki nem ír kódot, a leghosszabb ideig engem szenved ez a probléma. Természetesen a nem kódolók is a probléma részét képezik; ez a bejegyzés eredetileg körülbelül öt okból állt, amelyek miatt a szoftverfejlesztési projektek kudarcot valltak, de teljes ügyfélként megváltoztattam a specifikációt a projekt felénél, és így körülbelül 10 ok lesz a szoftverfejlesztési projektek kudarcára.

1. Rosszul meghatározott (vagy, Isten akarata szerint, nem definiált!) Eredmény

"Mobil alkalmazás? Hidat építettünk, működik ez?

A szoftverfejlesztési projekteket sújtó egyik legnagyobb probléma a rosszul meghatározott eredmény. A „végtermék” megfelelő meghatározásának nélkül garantálható, hogy egy projekt kudarcot vall.

Ez annyira létfontosságú, hogy valószínűleg megváltoztathatja maga a projekt irányát (ezért a listám első számú!). Nagyon javaslom, hogy készítsen egy specifikációs lapot, hogy jobban meg lehessen határozni, hogy a termék hogyan fog kinézni, mit fog csinálni, és hogyan fogja megcsinálni. Bővebben erről a kommunikáció és az elvárások alatt!

2. Rossz probléma megoldása.

„Új fahídot építettünk, amely sokkal szebbnek tűnik, mint a régi. Autók? Ó, nem, nem támogatja az autókat. Nagyon bármi, ami nehezebb, mint egy madár, megtöri. ”

Egy másik általános probléma a rossz probléma megoldása. Ez ugyanazon a vonalon fekszik, mint egy rosszul meghatározott eredmény, ugyanakkor sokkal szélesebb körű. Noha jól meg tudja határozni a végterméket és megoldhatja az itt tárgyalt egyéb kérdéseket, ha megoldása nem oldja meg megfelelően a problémát, akkor a projekthez sehova nem került.

Ennek egyik módja a fokozatos ötletek kialakítása. Határozza meg alapvető problémáját, milyen lépéseket lehet tenni annak megoldására, és egy lehetséges megoldást. Ezután folyamatosan iterálja a terméket a végfelhasználóval - tartson folyamatos felülvizsgálati folyamatot annak biztosítása érdekében, hogy a projekt megfelelően reagáljon a felhasználó igényeire, és továbbra is megoldja az alapvető problémát.

3. Nincs elég kommunikáció.

"Felépítettünk egy hídot, fél alagutat építettek."

A 3. helyen való érkezés a fő probléma, amely szinte minden projektet, ipart és üzleti kommunikációt érint. A kommunikáció elengedhetetlen egy szoftverfejlesztési projekt minden szintjén.

Belső szinten a fejlesztőknek hatékonyan kell kommunikálniuk annak biztosítása érdekében, hogy összehangolt és kompatibilis eszközöket és csővezetékeket építsenek ki. Általános megoldás itt a tervezés, az API-k és a projektben előírt egyéb mérnöki tervezetek előzetes kidolgozása. Ez elengedhetetlen ahhoz, hogy több száz órányi időt takarítson meg, amely egyébként pazarolható lenne a refakturálás és a szerkezetátalakítás során.

Magasabb szinten is fontos, hogy megfelelően kommunikáljunk más csapatokkal. Például a marketing csapatnak tudnia kell, mi a technológiai szempontból megvalósítható, mielőtt a koncepciót eladná.

Ezen a szinten történő kommunikáció elmulasztása problémákat okozhat projektben; a termék súlyosan leválhat attól, amit eladtak, megígértek, építettek és szükségesek voltak.

4. Nincs terv vagy ütemterv.

„Igen ... körülbelül úgy történik, mint… talán egy pár hét? Nem biztos benne, mit fogunk csinálni utána ... ”

Függetlenül attól, hogy betartják-e az ütemterveket és a terveket, fontos, hogy legyen. Biztosítja a projekt felépítését és becslést ad arra vonatkozóan, hogy mikor és hogyan kell végrehajtani a feladatokat.

A jó terv természetesen sokkal tovább halad. Egy jó terv vagy ütemterv közös határként szolgálhat a nagy csapatok számára is, lehetővé téve számukra gyors és hatékony sprintben történő működést. Ha egy szolgáltatás leesik, vagy több időre van szüksége, akkor a tervet / az ütemtervet gyorsan beállíthatja, és a költségvetést ennek megfelelően módosíthatja.

5. Az elszámoltathatóság hiánya.

„A bak megáll ... ott, viszlát!” - valószínűleg Harry Truman

Amikor a szar eltalálja a ventilátort, valakinek készen kell állnia egy rongykoronggal. Ha egy funkció átbukik, egyértelműnek kell lennie, ki felelős és milyen lépéseket kell tenni annak megakadályozása érdekében a jövőben.

Gyerekesnek tűnik, de a szoftverfejlesztési iparban a „mutató ujjak” egy gyakori előfordulása. A hátlapmérnökök az előlapi mérnököket fogják hibáztatni, az értékesítési csapatot hibáztatni, a marketing csapatot hibáztatni, a marketing iroda hibáztatja a törvényi irodát, a menedzsment hibáztatja… Ez a folyamat nem csak időigényes és a morál számára katasztrofális, hanem az alapkérdést - „mi ment a bajba?” - nyitva hagyja és megválaszolatlanul hagyja.

6. Túl gyakran mozgatja a kapuplatokat.

- Rendben, de most a hídnak kifutópályának is kell lennie, még 10 sávval kell rendelkeznie, és mi lenne egy közepén álló parkkal?

Fontos, hogy nyomon kövessük a projekt céljait, és ügyeljünk arra, hogy azokat időben teljesítsék. Noha lehetséges, hogy egy projektet kibővíteni kell, vagy a követelményeket meg kell változtatni, a „végcél” gyakori módosítása nem csak pusztítja a morált, hanem egyenesen lehetetlenné teszi a projektet. Gyakran előfordul, hogy a változások nem tervezettek, és alapos refaktorozást igényelnek; az idő múlásával ez sok időveszteget és végül kudarcot valósít meg.

Ami elsőként kis változásnak tűnik, az hosszú távú fejlesztési projektré válhat.

7. Nem megfelelő dokumentáció és nyomon követés.

„A bomba megsemmisítésére vonatkozó utasítások azt mondják, hogy húzza ki a piros vezetéket, miután az áramkimaradás megtörtént, de az összes vezeték piros és a készüléket tíz perccel ezelőtt kellett levonni!” - James Bond, mi lesz a vége az ő karrierje

Nagyon jó egy agilis módszertant követni és gyorsan mozogni, de a dokumentáció mindig fontos. A nem dokumentált kód évekig tartó technikai adóssághoz vezethet, és óriási problémákat okozhat az úton - „mit jelent ez a funkció?”

Ugyanilyen fontos a termék dokumentálása. A folyamat minden lépését, az ötletektől a tervezéstől a kivitelezésig, jól dokumentálni kell annak biztosítása érdekében, hogy a projekt mások számára könnyen navigálható és a pályán maradjon. A jó dokumentáció lehetővé teszi a projekt könnyebb követését - egy agilis rendszerben próbáljon ki egy kanban táblát vagy hasonlót a feladatok nyomon követése érdekében!

8. Rosszul meghatározott rendszerkövetelmények.

"WTF: érted, hogy mindössze 5 000 emberre csak 5 kenyér és 2 hal van ?!"

A projekt technikai követelményeit nehéz felmérni, ám rendkívül fontos, hogy ezt megtegye. A kis extra kiegészítésnek tűnik a kérdés fordulása, amely magában foglalja a kiegészítő infrastruktúra kiosztását és a teljes rendszer újradefiniálását a támogatás bevezetése érdekében.

9. Gyenge felkészülés.

"Még mindig fél hajóval repülünk."

Gyakran egy projekt izgalmas és könnyen beindítható; azonban a sikerhez elengedhetetlen a megfelelő felkészülés. Specifikációkat kell kidolgozni, a terveket el kell készíteni, meg kell állapodni az ütemtervről és el kell osztani az erőforrásokat.

Ennek technikai szintű kezelésének népszerű módszere a Test Driven Development. Mielőtt egyetlen sornyi kódot írna a projekthez, tervezze meg az architektúrát és az egyes részek elvégzését. Ezután írjon teszteket annak megállapítására, hogy minden egyes darab valóban a kívánt célokat szolgálja-e. Ilyen módon elkészítheti a meghatározott célokkal ellátott keretet, és számszerűsítheti termékének fejlesztésében elért haladást.

10. Reális elvárások.

"Rendben, az alkalmazás jól néz ki, de miért nem változik automatikusan a színséma, hogy megfeleljen a felhasználó telefonjának esetéhez?"

Fontos az elvárások kezelése. Gyakran az ügyfél olyan funkciót kér, amely ésszerűtlen, nem gyakorlatias vagy lehetetlen. Általános gyakorlat az, hogy korlátozza a változtatásokat, amelyek egy specifikációra végrehajthatók, és hogy egy mérnök jelen legyen a megbeszélések során annak megállapítása érdekében, hogy a javasolt szolgáltatás technológiailag megvalósítható-e.

Remélhetőleg, ha elkerüljük ezeket a 10 hibát, a következő szoftverfejlesztési projekt meghökkentő sikert fog elérni! Milyen problémákkal ütközött a szoftverprojektekbe?

Hé! Tomer vagyok, vállalkozó és gyártó. Talán ismeri a Mevee-ből, a Crane-ről, a Shots-ról, a Dia-ból és most a investintelligence.io-ból, többek között az indított termékek közül! Ez a cikk egy szélesebb körű sorozat részét képezi, amelyet elsősorban a tapasztalataim alapján írok, és elsősorban én és a csapatom véleménye alapján készült.

Remélem, ez segít elkerülni ugyanazok hibáinak elkerülését, mint én, és ne feledje, hogy továbbra is szállít!

Kérjük, tapsoljon , ha ezt értékesnek találja, és kövessen engem , ha így szeretne többet írni, mivel megosztom azokat a történeteket, amelyek a szoftverfejlesztésről és a vállalkozói készségről néznek ki a való életben.