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

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

Ha online keressen 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-ra. 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”, ez azt jelenti, hogy 2040-et jelent.

Mivel az egyetlen srác a Crane.ai-nál, aki nem ír kódot, a leghosszabb ideig engem sújt 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 most körülbelül 10 ok lesz a szoftverfejlesztési projektek kudarcára.

1. Rosszul meghatározott (vagy, Isten akarata szerint, meghatározatlan!) 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ása 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 miként fog kinézni a termék, 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.

„Építettünk egy új fahídot, amely sokkal szebbnek tűnik, mint a régi. Autók? Ó, nem, nem támogatja az autókat. Nagyon sok minden, 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ű. Annak ellenére, hogy helyesen azonosítja 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 megoldása az, hogy fokozatosan ötletezzünk. 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 harmadik helyen való érkezés a fő probléma, amely gyakorlatilag minden projektet, ipart és üzleti kommunikációt érint. A kommunikáció létfontosságú a szoftverfejlesztési projektek 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ökök előzetes kidolgozása. Ez elengedhetetlen ahhoz, hogy több száz órát takarítson meg, amelyeket egyébként pazarolhatnánk a refakturálás és a szerkezetátalakítás során.

Magasabb szinten szintén 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á.

A kommunikáció elmulasztása a projektet összetörő problémákat okozhat; 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 dollár megáll ... ott, viszlát! - Harry Truman valószínűleg

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ására a jövőben.

Gyerekesnek tűnik, de a szoftverfejlesztési iparban a „ujjak mutatása” egy gyakori esemény. A háttérmérnökök hibáztatják az előlapi mérnököket, az értékesítési csoportot pedig a marketingcsapatot hibáztatják, a marketingcsapatot hibáztatja a törvényi iroda, a vezetés hibáztatja. Ez a folyamat nem csak időigényes és morális katasztrófa, hanem az alapkérdést is hagyja - „mi rosszul ment?" - nyitott és megválaszolatlan.

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övesse a projekt céljait, és győződjön meg arról, hogy időben teljesülnek-e. 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 kezdetben kismértékűnek 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 hatalmat tíz perccel ezelőtt kellett levágni!" - James Bond, mikor lesz a 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 kiegészítő 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ót repülünk.

Gyakran egy projekt izgalmas és könnyen beindítható; a sikerhez azonban alapvető fontosságú 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ül a meghatározott célokkal ellátott keret, és mennyiségileg meghatározhatja a termék fejlesztésének előrehaladását.

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, hogy korlátozza a változtatásokat, amelyek egy specifikációra végrehajthatók, és hogy a 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 elképesztő sikert fog elérni! Milyen problémákkal ütközött a szoftverprojektekbe?

Hé! Tomer vagyok, vállalkozó és alkotó. 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 nekem és a csapatom véleményére épül.

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 a történeteket arról, hogy a szoftverfejlesztés és a vállalkozói szellem hogyan néz ki a való életben.