mboost-dp1
Programmør søges til spændende projekt
Windcape (49) skrev:Det plejer man altså at tage penge for.
Det er det folk griner af. At der forventes gratis forundersøgelse.
Da jeg var selvstændig gik det nu fint nok. Typisk tog jeg ikke penge, før projektgrundlaget var på plads, og jeg begyndte at arbejde på selve produktet.
Ja, nogle blev meget klogere men placerede aldrig en ordre. Nogle gange sagde jeg at det var en dårlig ide*, og så hørte jeg ikke mere fra dem.
Men generelt fik de et grundigt indtryk af mig inden de lagde sig fast på en leverandør, hvorefter de valgte at lade mig få opgaven.
Jeg tror jeg ville have tjent mindre, hvis jeg ikke gav gratis rådgivning.
*) Jeg sagde det naturligvis pænt, argumenterede, og kom typisk med forslag til ændringer eller alternativer. Nogle redefinerede konceptet til noget med langt større chance for success, gav mig opgaven, og fik success. Dem jeg ikke hørte fra igen har nok enten taget mit råd til sig, eller gået til en anden. Det er helt op til dem selv, jeg har gjort hvad jeg kunne for at hjælpe dem.
Hvis det er fordi du er færdig med tråden kan du jo reelt bare lade den være?Lightkeeper (55) skrev:#54
Vær rar at gøre det, så flamerne kan få noget andet at give sig til.
Umiddelbart synes jeg det er rimelig interessant hvad og hvordan folk foretrækker at få info om en opgave...
Lightkeeper (55) skrev:#54
Vær rar at gøre det, så flamerne kan få noget andet at give sig til.
Altså, bare fordi jeg kan er ikke ensbetydende med at må / vil gøre det.
Den eneste måde tråde bliver lukket på newz, er ved at de udløber, dvs at ingen skal skrive i dem i 14 dage.
Som Magten skriver vil jeg anbefale dig bare at ignorere tråden og lade det ligge, den skal nok løbe ud i sandet om et par dage, når folk giver op.
#48
Først, vil jeg byde dig velkommen som bruger af Newz.dk!
For det andet, når du ikke kan stave til 'kompetence', hvordan kan jeg så vide mig sikker på om du overhovedet aner hvad ordet dækker over?
Newz.dk indeholder en pæn skare dataloger og datamatikere, folk, der ikke finder sine udviklings-opgaver på forums, men arbejder professionelt med det til hverdag.
Hvis de ikke kan se hvis noget virker lusket, hvem kan så?
Tillykke med det, må jeg ikke nok få din autograf tilsendt som en animeret gif?
Undskyld mig meget, men hvis han ikke har lavet en decideret kravspecification, hvor helvede er idéen så henne?
Det er sådan projekter trækker ud i det virkelige liv: Inkompetent planlægning og self-fede idéer.
Hvis du har oprettet en bruger bare for at fortælle os det, så er det da rimeligt grinagtigt.
Det er lidt sørgeligt at projektet og Lightkeeper ikke kan tåle kritik, men græder som en baby og kalder det straks for at flame.
Det er tydeligt at gennemskue kompetance niveauet blandt brugere herinde. Bliv dog voksne.
Først, vil jeg byde dig velkommen som bruger af Newz.dk!
For det andet, når du ikke kan stave til 'kompetence', hvordan kan jeg så vide mig sikker på om du overhovedet aner hvad ordet dækker over?
Newz.dk indeholder en pæn skare dataloger og datamatikere, folk, der ikke finder sine udviklings-opgaver på forums, men arbejder professionelt med det til hverdag.
Hvis de ikke kan se hvis noget virker lusket, hvem kan så?
Jeg er den udvikler der har taget imod brugeren LightKeepers tilbud om at lave dette system.
Tillykke med det, må jeg ikke nok få din autograf tilsendt som en animeret gif?
Det er klart at manden ikke kan ligge alle kortene på bordet og udspecificere helt klart:
Hvilke teknologier der skal bruges: ASP/PHP/ASP.NET osv
Hvad systemet skal kunne
Hvilke krav der er til udvikleren
Undskyld mig meget, men hvis han ikke har lavet en decideret kravspecification, hvor helvede er idéen så henne?
Det er sådan projekter trækker ud i det virkelige liv: Inkompetent planlægning og self-fede idéer.
Så klap jeres små bitte hænder og være glade.
Hvis du har oprettet en bruger bare for at fortælle os det, så er det da rimeligt grinagtigt.
Det er lidt sørgeligt at projektet og Lightkeeper ikke kan tåle kritik, men græder som en baby og kalder det straks for at flame.
squad2nd (59) skrev:Først, vil jeg byde dig velkommen som bruger af Newz.dk!
For det andet, når du ikke kan stave til 'kompetence', hvordan kan jeg så vide mig sikker på om du overhovedet aner hvad ordet dækker over?
Newz.dk indeholder en pæn skare dataloger og datamatikere, folk, der ikke finder sine udviklings-opgaver på forums, men arbejder professionelt med det til hverdag.
Hvis de ikke kan se hvis noget virker lusket, hvem kan så?
Det hedder newz.dk ..
squad2nd (59) skrev:Undskyld mig meget, men hvis han ikke har lavet en decideret kravspecification, hvor helvede er idéen så henne?
Kravspecs er gammeldags. Jeg har været med til projekter med en pris på mindst 8 cifre, uden kravspec.
At arbejde ud fra en kravspec er i øvrigt kedeligt. Især hvis den ikke kan ændres som man har lyst, hvilket jo er modsat formålet.
#64
Et af Amandas største problemer var netop kravspec.
Som jeg har hørt det fejlede kravspec ikke noget. Problemet var at man fulgte den. Uden hensyn til at både teknologi og behov havde ændret sig, og at man kunne have lært mere om opgaven undervejs.
De to andre kender jeg ikke historien bag.
Et af Amandas største problemer var netop kravspec.
Som jeg har hørt det fejlede kravspec ikke noget. Problemet var at man fulgte den. Uden hensyn til at både teknologi og behov havde ændret sig, og at man kunne have lært mere om opgaven undervejs.
De to andre kender jeg ikke historien bag.
#65
Jeg skal nok lade være med at påstå, at kravspecs aldrig kan bruges. Men de to begrundelser alene synes jeg ikke er nok.
At man har et budget, og at man ikke gør det in-house, ændrer jo ikke på de problemer det giver, at arbejde ud fra kravspec.
Jeg kalder kravspec gammeldags, fordi man i dag har fundet ud af, at projekter typisk ændrer sig undervejs. Der er ingen grund til at bruge en masse krudt på at beslutte en masse detaljer, når det nok bliver lavet om alligevel, inden man overhovedet skal til at bruge dem.
Der er selvfølgelig nogle projekter hvor det er nødvendigt. Og nogle hvor krav ikke ændrer sig undervejs. Men hvor man engang næsten altid havde kravspec, har man det næsten aldrig i dag. Deraf gammeldags. :)
Jeg skal nok lade være med at påstå, at kravspecs aldrig kan bruges. Men de to begrundelser alene synes jeg ikke er nok.
At man har et budget, og at man ikke gør det in-house, ændrer jo ikke på de problemer det giver, at arbejde ud fra kravspec.
Jeg kalder kravspec gammeldags, fordi man i dag har fundet ud af, at projekter typisk ændrer sig undervejs. Der er ingen grund til at bruge en masse krudt på at beslutte en masse detaljer, når det nok bliver lavet om alligevel, inden man overhovedet skal til at bruge dem.
Der er selvfølgelig nogle projekter hvor det er nødvendigt. Og nogle hvor krav ikke ændrer sig undervejs. Men hvor man engang næsten altid havde kravspec, har man det næsten aldrig i dag. Deraf gammeldags. :)
#67 Nu skal vi ikke glemme at der er forskel på en kravspecifikation og så en udviklingsmodel.
Der er nødt til at være fremsat en kravspecifikation fra starten, så man har et udgangspunkt, som man så kan ændre eller helt droppe indenfor de perioder som er fastsat i henholdsvis XP, RUP, SCRUM m.v
Men man er da nødt til at have møder med kunden hvor de så udpeger hvilke features som de nu mener kan give mest værdi for virksomheden. Det ved programmørerne jo ikke.
Den gammeldags måde er jo netop at kunden dukker op én gang, fortæller hvad han vil have, og så går programmørerne igang med at hacke noget sammen, som de tror vil tilfredsstille kunden, og så ender det med at blive noget møg, fordi man egenligt laver hvad man 'tror' kunden vil have.
Der er nødt til at være fremsat en kravspecifikation fra starten, så man har et udgangspunkt, som man så kan ændre eller helt droppe indenfor de perioder som er fastsat i henholdsvis XP, RUP, SCRUM m.v
Men man er da nødt til at have møder med kunden hvor de så udpeger hvilke features som de nu mener kan give mest værdi for virksomheden. Det ved programmørerne jo ikke.
Den gammeldags måde er jo netop at kunden dukker op én gang, fortæller hvad han vil have, og så går programmørerne igang med at hacke noget sammen, som de tror vil tilfredsstille kunden, og så ender det med at blive noget møg, fordi man egenligt laver hvad man 'tror' kunden vil have.
Nej, man behøver ikke latterliggøre en person bare på grund af et uprofessionelt oplæg. Men man har vel lov at stille uddybende spørgsmål. Hvis en person besvarer de opfølgende spørgsmål lige så uprofessionelt, så er det sådanset tale om en person der latterliggør sig selv.myplacedk (43) skrev:Nåh jah, men derfor behøver man jo ikke at latterliggøre personer og projekter, bare fordi oplægget ikke virker helt professionelt.
Den her tråd ville have udviklet sig helt anderledes, hvis der var kommet nogle fornuftige svar på de spørgsmål der blev stillet.
Hvilke personlige angreb? Det er ikke et personligt angreb bare fordi der er nogen, der er uenige med dig.Lightkeeper (57) skrev:Når det kommer til personlige angreb imod mig, så mener jeg, at det går over gevind.
Jeg vil råde dig til at gøre et af følgende to:
1. Lad være med at bruge mere tid på tråden. Det vil sige lade være med at læse flere indlæg, og lad være med at skrive flere.
2. Læs tråden forfra igen. Find alle de seriøse indlæg og find alle de fornuftige spørgsmål der blev stillet. Skriv så et indlæg der besvarer alle spørgsmålene.
Hvis ikke du har tænkt dig at besvare de fornuftige spørgsmål som allerede er blevet stillet, så er det ikke værd at bruge mere tid på tråden.
Hvis man har tænkt sig at besvare et uhøfligt indlæg, så er et høfligt svar den bedste måde at gøre det på. Hvis man bliver svinet til, så skal man give den person et svar, der er langt mere høfligt end vedkommende fortjener. Hvis man selv begynder at svare igen på samme niveau som modparten, så kommer begge personer til at fremstå som nogle dumme svin. Men hvis man i stedet skriver et svar i en pæn tone, og bliver ved med det, så gør man det lysende klart hvem der i virkeligheden er et dumt svin. Det giver en virkelig stor tilfredsstillelse at skrive et høfligt svar på et flamebait indlæg.
Men før du skriver mere i den her tråd er du nødt til at forstå hvorfor der er mange der ser dig som useriøs, og hvad du kan gøre ved det. For hvis du ikke ændrer på det, så vil alle dine fremtidige indlæg blot forstærke den opfattelse.
Det er helt i orden hvis du vælger at ignorere tråden, og lader andre fortsætte debatten. Der bliver også debateret ting i den her tråd, som intet har med dit projekt at gøre.
Det kommer an på hvordan de bruges. Hvis man bruger kravsspecifikationen som et udgangspunkt og løbende får den uddybet på passende vis, så er det et fornuftigt redskab. Men en kravsspecifikation kan også misbruges. Hvis en leverandør følger specifikationen ordret, selvom det er oplagt, at den ikke er tilstrækkeligt udspecificeret, så ender man med et produkt der ikke virker tilfredsstillende, og så spildes der flere resourcer på at rette op på det. Det er endnu værre, hvis leverandøren bevidst spekulerer i at tjene ekstra penge på at rette op på alle uklarhederne i den oprindelige kravsspecifikation.arne_v (65) skrev:Kravspec er ikke gammeldags hvis det skal laves som fastpris projekt af en ekstern leverandør.
#67
Hvis en kunde og en leverandør aftaler en fast pris uden en krav spec, så er der lagt gift for samarbejdet.
Det indbygger modstridende interesser i projektet.
Det er rigtigt at behovet nemt kan ændre sig gennem et længere projekt forløb, men så har man en process for ændringer.
Men det kan netop lade sig gøre hvis man som udgangspunkt er enige om hvad der oprindeligt skulle leveres.
Og jeg tror helt bestemt at krav spec er det mest almindelige for fastpris projekter med ekstern leverandør.
Også i disse agile tider.
Hvis en kunde og en leverandør aftaler en fast pris uden en krav spec, så er der lagt gift for samarbejdet.
Det indbygger modstridende interesser i projektet.
Det er rigtigt at behovet nemt kan ændre sig gennem et længere projekt forløb, men så har man en process for ændringer.
Men det kan netop lade sig gøre hvis man som udgangspunkt er enige om hvad der oprindeligt skulle leveres.
Og jeg tror helt bestemt at krav spec er det mest almindelige for fastpris projekter med ekstern leverandør.
Også i disse agile tider.
squad2nd (68) skrev:Nu skal vi ikke glemme at der er forskel på en kravspecifikation og så en udviklingsmodel.
Og dog. Vandfaldsmodellen er baseret på kravspec. Den iterative model i sin reneste form er baseret på, at der ikke er kravspec. (I hvert fald ikke noget som minder om vandfaldsmodellens detaljerede kravspec.)
Eller sagt på en anden måde: Hvis du har en kravspec, som detaljeret fortæller præcist hvad systemet skal kunne, og alt uden for kravspec skal ikke laves - så kan du ikke arbejde iterativt.
squad2nd (68) skrev:Der er nødt til at være fremsat en kravspecifikation fra starten,
Jeg plejer at bruge et projektgrundlag i stedet. Det består (i denne sammenhæng) primært af en vision og en uddybelse af formålet med projektet. Altså en beskrivelse af hvad der skal være løst, for at projektet overhovedet giver mening.
Resten kommer hen ad vejen. Og det går rigtigt godt, fordi de yderligere detaljer ikke er noget man er fuldt ud i stand til at beslutte, før projektet er i gang.
Abesovs (69) skrev:Hvad er amanda ? :P
Wikipedia fortæller lidt. Her er historien set ud fra vores diskution om kravspec:
1) Man designer detaljeret et system, som man tror vil være godt.
2) Man bestiller det.
3) Da man modtager det dyre og forsinkede projekt opdager man:
- Verden har ændret sig. Fx. er systemet baseret på OS/2, som i mellemtiden er blevet droppet af leverandøren. Kundens arbejdsgang havde også ændret sig, så systemet skulle bruges til noget lidt andet, end det blev designet til.
- Man glemte at spørge slutbrugerne - dem som faktisk skulle bruge systemet. Dvs. selv hvis systemet kunne laves på én dag, ville det ikke matche behovet.
Ved at droppe kravspec (og lave et langt vagere formuleret projektgrundlag i stedet) ville man dels have nemmere ved at følge med "verden", go dels ville kunden (forhåbentlig slutbrugerne) være langt mere inddraget, og produktet ville dermed blive langt mere brugbart.
arne_v (72) skrev:Hvis en kunde og en leverandør aftaler en fast pris uden en krav spec, så er der lagt gift for samarbejdet.
Ja, det stiller lidt større krav til samarbejde og tillid. Og især til projekt-styringen.
Men hvis man kan finde ud af det, synes jeg nu det fungerer meget godt.
Vi plejer at lave en liste med ønsker, prioritere dem, grov-estimere de vigtigste, og så kommer det sjove. Ønskerne listes i prioriteret rækkefølge, og der sættes en streg. Det over stregen bliver lavet, det under streget gør ikke. Forudsat at estimaterne holder, og at der ikke sker ændringer.
På dette tidspunkt ændrer kunden prioriteringen, og der opstår muligvis snak om at projektet enten skal redefineres helt grundlæggende, eller om man skal prøve at ændre budgettet.
Hver gang kunden beder om en ændring, vises konsekvensen for hvad der er over eller under stregen. (Og hver gang estimaterne bliver opdateret bliver kunden også informeret.)
Det kræver en del debat og noget stram styring, men i sidste ende får man mere for pengene, sådan som jeg oplever det.
arne_v (72) skrev:Og jeg tror helt bestemt at krav spec er det mest almindelige for fastpris projekter med ekstern leverandør.
Det skal jeg ikke udelukke. :)
mandalae (62) skrev:
Men det er forkert, hvilket er lidt ironisk fordi du netop svinede manden fordi han ikke kunne stave til kompetence :p
http://en.wikipedia.org/wiki/Muphry%27s_law skrev:Muphry's Law is an adage that states that "if you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written".
#75
Jeg er tilbøjelig til at mene, at det du beskriver ikke er et fastpris projekt.
Reelt køber kunden X timer til et projekt og så bestemmer kunden hvordan timerne skal bruges.
Ganske behagelig model.
Men opgaver som skal i udbud, leverandøren skal give en fast pris på hele projektet og kunden vælger billigste leverandør (hvis forslag opfylder kravene og kan godtgøre at de kan klare leverancen) er en noget anden sag.
For slet ikke at tale om kontrakter der indeholde penalties ved mangelfuld og/eller for sen levering.
Den slags er dog ikke så almindelig i DK.
Jeg er tilbøjelig til at mene, at det du beskriver ikke er et fastpris projekt.
Reelt køber kunden X timer til et projekt og så bestemmer kunden hvordan timerne skal bruges.
Ganske behagelig model.
Men opgaver som skal i udbud, leverandøren skal give en fast pris på hele projektet og kunden vælger billigste leverandør (hvis forslag opfylder kravene og kan godtgøre at de kan klare leverancen) er en noget anden sag.
For slet ikke at tale om kontrakter der indeholde penalties ved mangelfuld og/eller for sen levering.
Den slags er dog ikke så almindelig i DK.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund