Programmering af større løsning

Hej Kim.

Som jeg skrev er vi jo en mellemstor virksomhed, så vi har jo allerede den dag i dag en egen bemandet IT afdeling, så helt alene bliver de jo ikke

Det jeg tænker på er det der er mest økonomisk for os i det lange løb

Hvis i allerede har kompetencerne til at nedbryde opgaven og finde ud af omfanget internt - så gør det. Jeres egne folk har helt sikkert også mere forretningsforståelse end en ny eller ekstern har, og derfor en bedre ide om omfanget fa en beregningsmodel eller kompleksiteten af en integration.

Tak for dit indlæg.

Det var dejligt at få kastet lidt lys over outsourcing-delen.

Jeg bryder mig personligt heller ikke selv om at outsource da man hurtigt mister overblikket og ikke samme kontrol har.

Vores egne IT stab må ikke blandes ind i det her, da deres ansættelseskontrakt ikke indeholder fortroelighedserklæring om forskning og udvikling.

Desuden er de nogle dovne hunde som jeg helst ikke sætter min lid til (de evner ikke at holde sig objektive)

En start ville være at få et par eksterne konsulenter til i samarbejde med jer at udarbejde en så præcis kravspecifikation som muligt, der beskriver hver af jeres ønskede funktioner ned i detaljer. Det ville være oplagt at anvende UML til dette og det ville nok kunne gøres for 75-150.000 kr.

Uden en ordentlig kravspecifikation vil det være umuligt for jer at få succes med så stort et projekt og endnu mere umuligt for et konsulenthus at kunne give en pris på det. Det er ikke dig der skal finde ud af om opgaven skal outsources til udlandet, det er konsulenthuset der skal stå inde for den kvalitet de kan levere til jer - om det så bliver kodet i Ukraine, Indien eller Herlev er jer underordnet. Jeg kan erfaringsmæssigt ikke anbefale jer at ansætte egne udvikler til denne opgave eller samarbejde med en for lille virksomhed, det vil sætte jer i en alt for sårbar situation.

/Arco

Jeg er enig i de profiler der tidligere er beskrevet, specielt omkring det med at de ikke må blive for nørdede. Det skader nok mere end det gavner. Jeg vil også sige en 3-4 stykker. Her er det vigtigt at det er nogle mennesker med stort overblik der kan gennemskue hvad der skal laves, således man kan starte med at bygge det rigtige fundament - og få det minimum 60% rigtigt første gang (det kan aldrig blive 100% rigtigt i så store systemer).

Omkring hvorfor sådanne projekter aldrig bliver færdige: De bliver færdige til at sælge, men der bliver vedligehold og videreudvikling, specielt da investeringen skal kunne hives hjem over flere år. Der sker også ændringer, kommer nyt hardware osv. dette skal kunne integreres. Det er klart at udvikler man webshops, så bliver det færdigt og man skubber det og videre til næste projekt. Dette projekt er så meget større og mere komplekst at det ikke bliver færdiggjort. Og det er ikke noget man bare lige sætter sig ind i, hvis man er ny udvikler i huset. Eks. har Adobe ikke fyret alle deres udviklere, bare fordi de har lanceret photoshop - de bliver ved med at leve og skal vedligeholdes.

Problemet med at skyde på prisen er at det bliver kun et skud, så er det ligemeget om jeg siger 10 kroner eller en milliard - de er begge lige gode. Det er heller ikke kroner og øre værdien du skal se på , men den værdi det kan tilføre dem der skal aftage det.

Det svære er at lave en udviklingsplan der fokuserer på time-to-market, således der kan høstes erfaringer og der kan komme penge i kassen mens man udvikler næste generation af softwaren. Typisk i softwareprojekter er selve udviklingen af funktionaliteten omkring 20% af den tid der bruges, resten er projektstyring, design, arkitektur, sparring, afklaring osv. 

Jeg vil sige at i kan være rigtig langt på et halvt år, måske endda ved version 1 af systemet.

Man skal passe på med en kravsspecifikation. Problemet med dem er at de er præcise - og folk tror de skal følges! Det skal forstås på den måde at det er utroligt nemt at tage den og banke i hovedet på andre når de ikke følger den, og så slipper man helt for at tænke selv. Det er et stort problem, hvis man tager en kravsspecifikation for alvorligt. Mange store offentlige projekter er gået under på grund af kravsspecifikationen, for når udbuddet er overstået og vinderen er fundet er der gået 1 år, og så er verden anderledes.

Kig i stedet på en agil proces, hvor i lærer undervejs og kun fastlægger en overordnet plan for hvad der skal implementeres. Lav det der er behov for og træf nye beslutninger undervejs. Det er nemt at udvikle således dette understøttes - og billigere i det lange løb. Her laver i ikke en big-bang løsning som med en kravsspecifikation, men mere en inkremental proces, hvor i måske hvert 14 dag eller hver måned har en ny version af programmet der kan mere og mere, i kan hurtigt få noget i kan vise og se på om systemet har den rigtige struktur, den rigtige funktionalitet. Dette er utroligt meget værd - ikke blot overfor sig selv, men også overfor organisationen der skal retfærdiggøre investeringen.

Jeg har læst for mange kravsspecifikationer (også offentlige) til at jeg kan anbefale den vej. Hvis dit produkt tager 1 år at udvikle for version 1, hvad skal du så med en kravsspecifikation på 400 sider der beskriver dit produkt, version 5 - det er ikke kun prisen på at få den udarbejdet der er spildt, men også den tid der er brugt på at få den lavet. Og hvor langt kunne i være nået på den tid? Hor mange erfaringer kunne i have fået. Og er i helt sikre på at med de erfaringer i bagagen at systemet stadig skal være det samme som dengang i lavede kravsspecifikationen? (hvor lang tid tager det at sætte et konsulenthus ind i systemet og kravene til det, og så skal de have den skrevet - og i skal have den læst og kommenteret, omskrives, læst, redigeret, omskrives....der går hurtigt et par måneder) 

Det første step for mig vil vel være at finde en projektleder til projektet?

Hvor skal man finde ham?

Hvad skal han kunne?

Hvordan skal han være? (kunne forstå han ikke skulle være nørd)

Hvor gammel er en projektleder i IT branchen?

I vores branche er ledere (som mig selv) for det meste nogle meget hårde personligheder, som let kan virke arrogante - Dels fordi vores tekniske indsigt er større end de medarbejdere der arbejder under os, men også fordi vores medarbejdere ikke skal tro at deres arbejde er en sovepude hvor man bare dovner den af.