Hov. Du er ikke logget ind.
DU SKAL VÆRE LOGGET IND, FOR AT INTERAGERE PÅ DENNE SIDE

Programmører vil ikke arbejde "gratis"...

Side 4 ud af 4 (33 indlæg)
Tilmeldt 7. Mar 11
Indlæg ialt: 110
Skrevet kl. 20:18
Hvor mange stjerner giver du? :

Set i bakspejlet: jeg søgte selv en programmør på et tidspunkt til en finansiel app. Ideen var min og programmøren skulle lave arbejdet med partnerskab. Ville jeg det hvis jeg selv var programmør og ikke kendte branchen og personen...nej nok ikke. Istedet må fremgangsmåden være for ide personen: lav en rigtig god, gennemarbejdet og seriøs forretningsplan. Find en investor partner og betal programmøren. Sikre alle rettigheder til selskabet. Er programmøren god så tilknyt vedkommende når projektet er skudt igang via ekstra bonus. Projektet vil allerede falde fra start hvis investor ikke tror på dig eller din ide. Det er rimeligt enkelt.

Fra København
Tilmeldt 25. Feb 09
Indlæg ialt: 175
canceldatePublished Fra  BitMasch Skrevet kl. 20:24
Hvor mange stjerner giver du? :
Gennemsnit 5.0 stjerner givet af 1 person

Brian Knudsen:
Hvor er selve processen dækket ind henne af ? Kender mange programører, både erfarne og uerfarne der bare kaster sig over projektet og siger det har vi klaret inden måneden er omme; 6 mdr senere sidder der en ide mand der ikke fatter hvad det skete og hvorfor koden ikke kan det han drømte om, på den anden side af bordet sidder der en irriteret programmør  der bare ikke gider flere tilføjelser / rettelser, men begge parter har ikke brugt tiden til at få lavet en opskrift på det produkt i vil have sat i søen, herefter ender resten af projektet oftest i den uendelige diskution om hvem der var amatør og hvem der havde sit på sit tørre. Resultat = alle taber

En ting man bør vide om programmører er at vi stort set allesammen er usandsynligt dårlige til at estimere, især store opgaver. En af de største grunde til dette er at bygge software ikke er som at bygge en bro, man møder ikke brobygnings-projekter, hvor det halvvejs gennem projektet bliver besluttet der skal bygges en tunnel i stedet for. Men det er slet ikke uset at selv de mest fundamentale requirements til et stykke software ændrer sig undervejs, fordi en stor del af de markeder som software benyttes til bevæger sig lynhurtigt. I teorien kan det i software verdenen sagtens lade sig gøre at "lave en bro om til en tunnel", det kræver dog en god udviklingsprocess og nogle meget dygtige folk i alle roller der er involveret i projektet.

Der findes et hav af softwareudviklingsprocesser og hvilken en der er bedst til et specifikt projekt afhænger af folkene, produktet, miljøet, tidsrammen, dokumentationskravet, m.m.

Brian Knudsen:
Så tag lige og få noget respekt for hinandens evner, og til programmørerne; i fejler lige så meget ved at gå ind i et projekt der ikke er dokumenteret inden i går igang! Hvor tit har i set et hus blive bygget op uden en arbejdstegning først ? Til idemagerne kan jeg kun sige, næste gang i sætter en programmør igang med et projekt for jer, så sørg for en dokumentation der svare til en bagevejledning eller guiden fra legoklodserne. Programmøren skal ikke være i tvivl om funktionaliteterne i jeres projekt.

Jeg har stor respekt for dygtige forretnings-, process- og idé-folk med evnerne i orden, som taler lige ud af posen, men ingen tålmodighed med det modsatte. Jeg er sikker på at der findes uduelige programmører og er selv stødt på nogle stykker i min tid som software udvikler, dem har jeg heller ingen tålmodighed med. Sagen i Nordeuropa, især i de store byer, er p.t. at udbuddet af talentfulde programmører er lille mens efterspørgslen er stor. Omvendt er der et utal af mennesker med en idé til et produkt, der kræver en eller flere programmører, de talentfulde programmører er der få af og de vælter i gode tilbud. Det er et spørgsmål om udbud og efterspørgsel.

Mht. til at have dokumentation af det ønskede produkt i samme detaljegrad som en "bagevejledning", så lyder det meget i retning af Vandfaldsmodellen, som af gode grunde har været i stærk tilbagegang i de seneste år. I et marked hvor kravene skifter lige så hurtigt som vejrudsigten, ender du med at være færdig med din "bageopskrift" på samme tidspunkt som din konkurrent er i færd med at lancere hans tiende version af sit konkurrerende produkt, som allerede har kunder og har været igennem 10 vigtige iterationer, med værdifuld kundefeedback, hvor uønskede features er skåret fra og ønskede features er forbedret eller tilføjet.

Valget af udviklingsprocess afhænger som nævnt tidligere af mange faktorer, men i en marked hvor tingene går hurtigt, vil jeg til enhver tid foretrække en iterativ udviklingsprocess.

Softwareudvikler med speciale indenfor skalerbare webløsninger. PHP, MySQL, Puppet, Python, Apache, nginx, HTML5, m.m.
http://bitmasch.com/

Fra København
Tilmeldt 25. Feb 09
Indlæg ialt: 175
canceldatePublished Fra  BitMasch Skrevet kl. 20:30
Hvor mange stjerner giver du? :

Og med hensyn til valg af programmør, så gælder det om at være kræsen som bare fanden, en talentfuld programmør kan være med til at gøre din idé til en millionforretning, en uduelig en af slagsen kan være med til at brænde alle pengene af og køre firmaet i sænk.

Det er svært at være kræsen når udbuddet af gode full-stack udviklere er så lille som det er, men det betaler sig ofte.

Softwareudvikler med speciale indenfor skalerbare webløsninger. PHP, MySQL, Puppet, Python, Apache, nginx, HTML5, m.m.
http://bitmasch.com/

Side 4 ud af 4 (33 indlæg)
Vi bruger cookies til at sikre, at du får den bedste oplevelse på Amino
Læs mere