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 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. Néhány embert leül egy szobába, egyetért néhány specifikációval, majd engedi, hogy a helyiség okosabb emberei menjenek 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 hall előtti 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 hozzáadunk munkaerőt, később 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 mégis hogyan tűnt először. (És bármit is csinál, ne nevezze azt "hibának" - ez mindig egy "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 az, ami embereket tesz nekünk, nem gépek. É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, ne feledje ezeket a szempontokat. Lehet, hogy sok vért, verejtéket és könnyet takarít meg Önnek.

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.