A legfontosabb pontok Senki sem mondta Önnek, mielőtt elkezdené az alkalmazás felépítését

Közel 50 évig - mióta Frederick Brooks kiadta a klasszikus „A mitikus ember-hónapot” - a szoftverfejlesztő csapatok küzdenek azzal, hogyan tudnak időben és a specifikációk szerint építeni egy projektet. Ez nem könnyű feladat. Íme, amit elfelejtenek mondani, mielőtt elkezdték volna az új alkalmazás létrehozását ...

A végtermék nem hasonlít az eredeti specifikációkhoz

Az alkalmazás létrehozásának elég egyszerűnek kell lennie. Ül le néhány embert egy szobában, egyetért néhány specifikációval, majd hagyja, hogy a helyiség okosabb emberei elmenjenek dolgozni olyan kódoláshoz, amit éppen befejeztek. Elég könnyű, igaz? Rossz. Nagyon nagy a valószínűsége, hogy a végtermék nem hasonlít az eredeti előírásokhoz. Számos nagyon jó oka van ennek, és ennek semmi köze nincs a szoftverfejlesztő csapat „inkompetenciájához”. A határidők megváltoznak. A tervek megváltoznak. Egyes esetekben még az eredeti probléma, amellyel megpróbálta megoldani a változásokat. Valójában nagyon csoda, hogy a végén valami épül fel.

Minél több érdekelt van a projekten, annál zavarosabb a végeredmény

A felszínen ez ésszerűnek tűnik korlátozni a konyhai szakácsok számát, mégis meglepődne, hogy hány tökéletesen értelmes ember figyelmen kívül hagyja ezt. Ehelyett rohanás nemcsak a fejlesztőcsapat, hanem az értékesítési csapat, a marketingcsapat, és talán még a hallban levő srác bevonására is, akinek funky, kitalált címe van névjegykártyáján. És ami ezután történik, olyan, mint a régimódi telefonos játék, ahol mindenki, aki beszélgetést hall, kissé másként ismétli azt, mint a lánc következő személye. A most ismert Brooks-törvény szerint (Frederick Brooks tiszteletére): „ha késői szoftverprojektekhez adunk munkaerőt, későbbi lesz.”

A készterméknek mindig lesz egy része, amelyet senki sem tud pontosan

A legjobb esetben a szoftverfejlesztő csapat által eredetileg összeállított összes szolgáltatás és az alkalmazásban vagy a szoftverben megjelenő végső funkciók között mindig közvetlen egy-egy leképezés lesz. De itt van a probléma - a legtöbb szoftverfejlesztő csapat annyira nagy nyomás alatt van, hogy a projektet kihozza az ajtón, hogy átugorják a dokumentációt arról, hogy az egyes kódsorok mit tényleg elvégeznek. Ezt ismételje meg elég sokszor, és elkerülhetetlenül olyan „tulajdonsághoz” vezet, hogy senki sem tudja igazán, mit csinál, vagy hogy elsősorban hogyan jelenik meg. (És bármit is csinál, ne nevezze azt „hibának” - ez mindig „szolgáltatás”!)

A csapat egyik tagja felel a kapusok áthelyezéséért

Annak ellenére, hogy az emberek szeretnének beszélni a „összehangolódásról” (vagy bármi legyen is a legújabb MBA 101 zsargon), az emberek ritkán vannak egymáshoz igazításban. Ez teszi az embereket, nem a gépeket. És az egyik ember (természetesen nem hivatalosan) kinevezi magát a kapusok mozgatásáért felelős személynek. Tudod, az a személy, aki megjelent a hétfői reggeli ülésen, és a semmiből bejelenti, hogy a projekt határideje néhány héttel feljebb került, vagy hogy egy rég elfeledett szolgáltatás most „missziókritikus”, és azonnal hozzá kell adni .

**

Következtetés

Tehát amikor legközelebb leül a csapatával és elkezdi a következő szoftverprojekt határidejét és előírásainak kidolgozását, tartsa szem előtt ezeket. Lehet, hogy sok vért, verejtéket és könnyet takarít meg Önnek.

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.