Jump to content
  • 0

Hoe bepaal je de kosten van het ontwikkelen ve database?


Cornelis

Question

Posted

De afgelopen tijd heb ik gewerkt aan een database met als doel hier enkele functionaliteiten toe te voegen. Ik ben tot de conclusie gekomen dat de database niet aan te passen is omdat er inconsequenties en onlogische relaties in zitten.

De database moet nu helemaal opnieuw ontworpen en gebouwd worden.

De opdrachtgever staat hier waarschijnlijk wel positief tegenover maar wil graag weten wat het hem ongeveer gaat kosten. Ik heb niet heel veel ontwikkel ervaring en zou me niet graag een tweede keer zo vergissen in het aantal uren.

Op basis waarvan maak je een realistische inschatting van de kosten?

Hoe regel je het financiele deel naar tevredenheid van beide partijen?

Hoe bepaal je bijvoorbeeld welk bedrag in welk stadium betaald wordt en op welke voorwaarden?

Recommended Posts

  • 0
Posted

Best wel moeilijk. Om een klant te behoeden voor een debaclê, adviseer ik je om het ontwerp eerst te maken en pas daarna met een kostenschatting te komen. En het ontwerp maak je pas als de klant zijn wensen (requirements) heeft vastgelegd.

 

Soms (lees: vaak) weet de klant niet wat hij wil. Je zult dan nooit een goed product krijgen.

 

In een ontwerp staan minimaal alle datavelden plus de manier waarop deze over de tabellen zijn verdeeld. Zelf werk ik met NIAM (Natuurlijke Taal Informatie Analyse methode) een methode die zinnen voorschrijft als: "Een order heeft 1 of meer orderregels", "Een order heeft precies één ordernummer", "elk ordernummer is gekoppeld aan precies één order" etc. Met deze zinnnen kan je communiceren met de klant en dwing je een eenduidig datamodel af. Omdat je niet veel ervaring hebt kan je de klant ook voorstellen om het ontwerp uit te besteden - op het forum zijn voldoende mensen die ervaring hebben en die je wellicht kunt inhuren.

  • 0
Posted

En niet onbelangrijk is om de afspraken goed vast te leggen. En met name dan of de urenbegroting bindend is of slechts een indicatie.

Ik ben het met Theo eens dat het allerbelangrijkste is om een goed technisch/functioneel ontwerp te maken. Als je op die fase bespaart dan kan je problemen verwachten later in het traject als blijkt dat de verwachtingen uiteenlopen. Het is niet ongebruikelijk dat een klant bereid is om te betalen voor een goed ontwerp.

  • 0
Posted
…..maar wil graag weten wat het hem ongeveer gaat kosten.

 

 

En willen we dat niet allemaal.

 

… zou me niet graag een tweede keer zo vergissen in het aantal uren.

 

Op basis waarvan maak je een realistische inschatting van de kosten?

 

Verdergaand op Theo’s uitstekend advies zou je kunnen beginnen met een inschatting van de nodige tijd.

Ieder heeft wel een eigen methode, maar de basis ligt in wat iedere ontwikkelaar ooit zal moeten doen; alles aanmaken en coderen.

 

Ieder project is uniek, alhoewel ze bijna allemaal enkele zaken gemeenschappelijk hebben.

Daarom vertekken wij altijd van de layouts. (doe een search voor ‘behangpapier’ om meer te weten).

 

Laat ons eenvoudig beginnen. De klant wil 5 layouts zien.

Klanten, Leveranciers, Voorraad, Facturen en Rapporten. Op ‘t eerste zicht niks bijzonders. Hoe moeilijk kan dat zijn.

 

Reken 8 uur voor iedere layout. Maakt 40 uur.

Doe maal 3 voor alle technieken, mechanieken (scripts, navigatie, kleuren, knoppen enz.) om het geheel werkend te krijgen. Samen met het begin maakt dat 160 uur.

 

Ja het gaat snel.

 

Hoeveel gebruikers ?. Voeg 4 uur toe per gebruiker. Stel dat er 5 zijn, brengt het totaal op 180 uur.

 

Moet het via internet, geen probleem, + 40 uur, maakt 220 uur.

 

Moet er een gemiddeld of een hoog niveau van beveiliging ?. Plus 8 uur voor elk niveau.

Stel je hebt Admin, Manager en user, dat maakt + 24 uur, totaal 244 uur.

 

Klinkt veel voor een ‘simpele’ toepassing met 5 schermen, web-enable en beveiliging ?

Hoe lang kan dat duren om het voor mekaar te krijgen ?

 

In werkelijkheid is het geheel waarschijnlijk nog complexer.

 

We houden géén rekening met de voorbereidende gesprekken, de tussentijdse gesprekken, de nodige verplaatsingen hiervoor, de tijd die je moet wachten om een goedkeuring te krijgen voor je aan iets verder werkt, het tussentijds testen, het uitvoeren van gevraagde aanpassingen, het aanmaken van eventuele help files/manual, de training van de gebruikers….

 

Zoals Theo al aangaf, het zijn processen die je gaat automatiseren. Geen proceskennis = geen automatisering. Ook dat vraagt tijd.

Het is beter op voorhand wat ruimer te rekenen.

Ben je sneller klaar, dan heb je een bonus. Duurt het langer, dan heb je wat speling, terwijl je toch nog ‘op tijd’ kunt afleveren.

Het klinkt altijd slecht indien je meer tijd moet vragen….

 

Hoe bepaal je bijvoorbeeld welk bedrag in welk stadium betaald wordt en op welke voorwaarden?

 

1/3 vooraf betaling, 1/3 met een tussentijdse spreiding voor iedere goed te keuren stap.

Daarna aflevering met ingebouwde beperkte functionaliteiten.

Die geef je volledig vrij bij de volledige betaling.

 

Dat laatste is open voor discussie, maar indien dit op voorhand afgesproken en op papier staat, weet iedereen war zich aan te houden en wat de mogelijke gevolgen kunnen zijn.

 

1 peso con cincuenta centavos

  • 0
Posted

Waarom niet simpelweg een uurtarief wat je waard bent/wilt zijn?

 

Voordeel voor jou: geen onbetaalde uren

Voordeel van de klant: geen betaling voor onzin

 

Wekelijks kun je kort overleggen over uitbreiding, inperking aantal uren/features.

 

Is dit een idee? Het is wel een heel simpel model en makkelijk communiceerbaar.

 

c9

  • 0
Posted

Simpel: omdat het dan letterlijk een project met een open einde wordt zonder enige garantie dat het ooit afkomt voor een redelijke prijs.

Voor een klant die over oneindige middelen en oneindig veel tijd beschikt maak ik dan een uitzondering. En misschien krijgt meneer Dunning dit soort deals ook voor elkaar, gelet op zijn bijzondere reputatie waarbij je al blij mag zijn als hij de telefoon opneemt voor je.

Iedere klant die verstandig onderneemt zal willen weten waar hij - in ieder geval ongeveer - aan toe is.

  • 0
Posted

Wat te denken van dit?

 

Je vertelt de klant dat hij zijn voorzien budget *niet* vertelt, maar je laat beginnen met bv "Zie wat je al kan doen met deze eerste schijf van €400" (ik denk even klein, ik weet het :wink:).

 

Dit verplicht jezelf dan om je niet te laten afleiden met layout-gepruts en je maakt puur het skelet van de toepassing al zoveel mogelijk in orde.

 

Vervolgens laat je de klant weer een schijf aanbieden voor aanpassingen, of indien OK, reeds voor de layout: "Zie wat je met de layout kan doen voor €200". Enz.

 

Als de functionaliteit er reeds is, kan hij bv verfijning van de layout nog even laten voor wat het is, tot ie weer bij kas is :P

 

Je hebt hiermee min of meer je uurprijs en klant kan voor zichzelf een beetje inschatten wat zijn schijven opbrengen (al kan dat natuurlijk evengoed zwaar tegenvallen soms :lol:).

 

Het doet me in elk geval een beetje denken aan "het spiraaltje" van Brian en ik zou het zo wel eens willen proberen, juist omdat ik mezelf wil verplichten eerst de basis ineen te steken en omdat ik het kotsbeu ben om verrevan de gepresteerde uren te kunnen rekenen.

  • 0
Posted

@Gido_

 

Ook dan zul je moeten aangeven wat je voor elke 'schijf' doet.

Los daarvan realiseert een klant zich heel snel (waarschijnlijk van tevoren) met een dergelijke insteek dat éénmaal begonnen 'halverwege' stoppen weggegooid geld zou zijn en ziet deze het als een traject met een open eind waar men waarschijnlijk niet aan wil beginnen...

  • 0
Posted

Als klant zou ik halverwege stoppen juist heel interessant vinden.

 

De opmerking dat dit niet interessant zou zijn begrijp ik niet, want in plaats van een totaal mislukt project, dan maar de helft.

  • 0
Posted

Een verscheidenheid aan methoden om tot een kostenberekening te komen.

 

Even de andere kant om te bepalen of kosten een beetje realistisch zijn:

 

Wat zijn nou gemiddelde budgetten voor een software 'oplossing op maat' (FM of andere)

Dit zal wel afhangen van de grootte van een bedrijf (en de omvang van de toepassing enz), maar ik kan me voorstellen dat hier wel iets over te zeggen is.

  • 0
Posted
Als klant zou ik halverwege stoppen juist heel interessant vinden.

:?::?::?:

Er vanuit gaande dat ik als klant geen ontwikkelaar ben:

Blijkbaar heel persoonlijk (maar uit ervaring toch ook weer niet): als klant wil ik geen halfbakken product.

  • 0
Posted

Als je de klant een prioriteitenlijst laat opstellen, dan kan je gewoon zien dat je steeds begint met het allerbelangrijkste en zien waar je geraakt of wat je wil doen voor die schijf geld.

 

Een hoop "coole" features zijn altijd mogelijk en maak je a/d klant al of niet bekend, maar deze zijn dikwijls niet noodzakelijk om reeds aangenaam te kunnen werken. Tenminste, zo had ik het bedoeld.

 

Klant kan dan beslissen: "Het heeft me reeds genoeg gekost, dus ik ga vrede nemen met slechts die ene belangrijkste rapportmogelijkheid, ipv van idealiter 4", enz. Dat is iets waar hij op voorbereid moet zijn.

 

Voor mij persoonlijk is de moeilijkheid wellicht om dat lijstje ook te volgen en met de kern van de zaak te starten ipv met de "coole features" of verfijnde layout :lol:

 

Maar het hoeft daarom niet "halfbakken" genoemd te worden, denk ik.

  • 0
Posted

Een mij bekende consultant van een heel groot Nederlands consulting bureau verklapte me eens:

Als ik een feitelijk juist artikel schrijf waar nergens een speld tussen te krijgen is, waar alle kanten belicht zijn, krijg ik bijna geen reacties. Maak ik hetzelfde stuk wat populairder, blijf nog steeds feitelijk juist maar vermeld niet alle "and buts & if's" ligt m'n mailbox daags na verschijning vol...

 

Kortom het artikel van Brian zal ongetwijfeld juist zijn maar ben heel benieuwd wanneer hij in zijn loopbaan met die insteek is gaan handelen. Waarschijnlijk pas toen hij: "wat gemakkelijker keuzes tussen klanten kon gaan maken".

  • 0
Posted
Dit zal wel afhangen van de grootte van een bedrijf (en de omvang van de toepassing enz), maar ik kan me voorstellen dat hier wel iets over te zeggen is.

Daar zit 'm nu juist de bottleneck: des te meer eisen en wensen des te meer tijd en uren erin gaan zitten enz.

 

M.i. is er niet een eensluidend antwoord op de vraag. Als je een klus wilt doen zul je soms een vaste prijs kunnen geven, soms een prijs met een bepaalde bandbreedte en soms zul je inderdaad tegen uurtarief kunnen/moeten werken.

 

Alles hangt dus sterk af van het type klus, de omvang en de wens van de klant en natuurlijk niet geheel onbelangrijk: of de de klus wilt hebben en kunt doen onder de condities die je kunt afspreken met de klant. Of nog gemakkelijker om keuzes te maken: de klanten staan bij je op de stoep te dringen of je alsjeblieft een klus voor hen wilt doen...

 

Dit kan dus ook betekenen dat je een klus wellicht ook wel eens beter 'voorbij' moet laten gaan...

  • 0
Posted

Het gaat niet om de reputatie van Mr Dunning (overigens best wel een aangename vent hoor) of om het feit of ie z'n klanten al dan niet kan kiezen. De kwestie is: een klant een vast bedrag voorspellen, is dat eigenlijk niet een klant bedotten ('lies, damn lies')? Als je een ernstige tijds- en kostenraming wil maken, dan moet je een gedetailleerde analyse maken. Een lijstje van alle velden en van alle onderlinge relaties is daarbij nog maar het begin. Dan komen de processen aan bod en vergeet ook niet de 'look and feel'. Dat is de 'waterfall' methode. Met zo'n analyse kan je in principe een developer in een kamertje opsluiten of je project uitbesteden aan een firma in India. :D

Exact na de door jou geschatte tijd komt die developer buitenwandelen met een oplossing die algemeen op gejuich wordt onthaald.

Niet dus.

 

Welke klant wil betalen voor zo'n analyse? In elk geval niet die kleine KMO. Maar het is wel die kleine KMO die het hardste schreeuwt voor exacte cijfers. Wat ga je dan doen zonder analyse? De 'super-duper' formule? Het aan je grootje vragen? Je zal je in elk geval indekken en ruim genoeg meten, nietwaar? Als jij voor je tijd klaar bent dan heeft die klant dus teveel betaalt. Als jij niet op tijd klaar bent dan raak je gefrustreerd en ongemotiveerd.

 

Volgens mij is het een kwestie van geven en nemen. Kleinere en onervaren klanten moet je daarbij een stuk begeleiden. Natuurlijk gaan zij je geen blanco cheque uitschrijven. Maar als je even voorrekent wat een analyse zou kosten, dan kiezen de meesten toch voor een meer flexibele aanpak (of voor dat standaardpakket uit de FNAC) :D

 

Ik sluit me ook aan bij Gido: de sleutel ligt in het opstellen van een prioriteitenlijst. Je kan perfect een aantal dingen laten zien aan de klant en erbij zeggen hoeveel die ongeveer hebben gekost. Op elke gevraagde feature of module kan je ruwweg een kostenplaatje plakken. Zo kan de klant zich zelf wel een beeld vormen. Hij moet dus niet zomaar in het diepe springen. De rest is een kwestie van vertrouwen. Ter plaatse bij de klant gaan werken, helpt zeker. Begin bij de grote lijnen en als er nog budget is, begin dan pas aan de gadgets. Dat vraagt natuurlijk ook enige discipline van de developer :?

 

Bovenstaande geldt natuurlijk alleen maar in een bepaalde context. De klant moet 'stop' kunnen zeggen wanneer hij wil en moet dan kunnen beschikken over de software.

  • 0
Posted

Hoeveel geeft kmo dan ruw weg uit voor een project, is dat 1000, 5000, 10.00 . 50.000 of >....?

Ik heb hier geen vergelijkbare projecten op de plank liggen.

Het ontwerpen en ontwikkelenn wil ik in dit geval voor een redelijke prijs doen (voor mij en voor de klant) omdat ik bij deze opdracht veel belang heb.

  • 0
Posted

Tsja, als uiteindelijk blijkt dat een project bij een reeele inschatting teveel tijd en dus geld gaat kosten voor de klant dan moet er iemand anders inschikken: de developer dus. Maar ook voor hem is het belangrijk van te voren te weten hoe groot de verliespost gaat worden. Of, hij rekent vast andere inkomsten mee die het project oplevert, bijvoorbeeld, het kan gebruikt worden als demo waarmee andere klanten binnen gehaald kunnen worden, of als basis voor verdere software. Helaas zie je dan vaak dat men verblind raakt door de wens om het project binnen te halen en aan die andere abstracte inkomsten astromische waarden gaat toekennen.

En, misschien, wil het niet te hard zeggen: maar als een goede berekening van de kosten uitkomt op een onhaalbaar bedrag, dan is misschien voor die klant de filemaker oplossing niet de juiste weg... When you pay peanuts, you get monkeys. Of anders gezegd: de klant die voor een dubbeltje op de eerste rang wil moet zijn wensen naar beneden bijstellen.

  • 0
Posted

Door mijn laatste financiele misser en de berichten die hier staan realiseer ik me terdege dat je vooraf niet precies kunt inschatten hoeveel tijd en geld er in een project gaat zitten.

Voor mijn eigen beeldvorming vind ik het wel prettig om op de een of andere manier tijd en kosten een beetje in te kunnen schatten (met een zeer ruime marge), ik zou zeker niet weer vooraf een vast bedrag bepalen voor de klant. Door zo'n ruwe berekening kan ik een beetje zien of iets haalbaar is of niet.

Voor de beeldvorming van de klant is het ook prettig als je ruw weg weet waar je het over hebt (onder de 10.000 of meer dan 50.000...)

Ik heb voor de nieuwe opbouw van de database waar ik nu aan werk een hele ruwe inschatting gemaakt op basis van de methode van Jean en een op basis van de waterfall.

Om nu zelf de haalbaarheid een beetje in te kunnen schatten vroeg ik mij af wat er door bedrijven voor dergelijke software op maat wordt uitgegeven. Misschien heeft een van jullie hier ervaring mee of is er een bedrijfskundige berekening die wordt gebruikt om de hoogte van een budget te bepalen (percentage van de omzet of zoiets) ?

  • 0
Posted
Door mijn laatste financiele misser en de berichten die hier staan realiseer ik me terdege dat je vooraf niet precies kunt inschatten hoeveel tijd en geld er in een project gaat zitten.

 

Tuurlijk kan dat wel. Doe zoals wij :

Maak een functionele analyse (betalend in regie)

Maak een offerte op basis van die functionele analyse.

 

De klant weet na de F.A. perfect wat ie gaat krijgen. En wel hetgeen ie gevraagd heeft. Plus hij weet precies wat hij zal moeten betalen.

 

Wijzigingen aan de functionele analyse zijn altijd meerwerken, aan een prijs die te bespreken is.

  • 0
Posted
De kwestie is: een klant een vast bedrag voorspellen, is dat eigenlijk niet een klant bedotten ('lies, damn lies')?

 

Niet helemaal.

 

Voor een beginnend iemand zal dit wat moeilijk zijn.

Op het einde van mijn ontwikkelaars loopbaan kon ik vrij precies zeggen hoe lang iets ging duren. Dus kon ik op bepalde gevraagde functionaliteiten exact een tijd- en kostenplaatje hangen.

 

In het begin maakte ik iedere layout afzonderlijk voor ieder project, iedere script enz.

 

Uiteindelijk heb ik nu een basistoepassing, met enkele vaste velden die in elke toepassing wel te gebruiken zijn, scripts die basisnavigatie doen, sorteringen, printlayouts, layouts die rapporten genereren, een layout met grafische elementen.

 

Dat scheelt enorm in tijd, terwijl ik zowat weet hoeveel tijd erin kan kruipen om het allemaal eerst aan te maken.

 

Als Groupo Sureste, een eenmanszaak, een offerte vraagt, gebruik ik de voorgeprogrammeerde toepassing voor een vast basisbedrag.

Bij het ontwikkelen snijden we weg wat niet te gebruiken is.

 

Vraagt Groupo Poniente, een multi-state c.v. de s.a., een offerte wordt ook de voorgeprogrammeerde toepassing waar mogelijk gebruikt, maar is de prijs koudweg x 10.

 

Indien je bij deze laatste aankomt met een op het eerste zicht 'goedkope' offerte, val je zoal uit de boot. Die gaan er vanuit dat als het niet veel geld kost, het waarschijnlijk niet goed is.

 

Ben je een gevestigde waarde op de markt dan kun je je een aantal zaken veroorloven die een beginnende ondernemer zeker niet kan.

Dezelfde methode toepassen voor een groot bedrijf bij een klein bedrijf is ook niet mogelijk.

 

Ieder project is dus uniek en moet op die manier aangepakt worden.

Iedereen kan wel raad geven steunend op opgedane ervaring, inzicht en mening, je kunt zelfs een opleiding volgen...

 

Uiteindelijk sta je alleen op het ogenblik dat je 'het moet doen'.

Daarom dat je 'zelfstandig' bent.

  • 0
Posted
Uiteindelijk sta je alleen op het ogenblik dat je 'het moet doen'.

Daarom dat je 'zelfstandig' bent.

 

Kijk, en daar doen we het voor. :-)

Ieder moet uiteindelijk zijn eigen rekening maken en proberen het meeste er uit te halen onder de meest economische omstandigheden en rekening houdend met de toekomst.

  • 0
Posted

 

Kijk, en daar doen we het voor. :-)

 

... en voor de bijtende onzekerheid...

... de slapeloze nachten...

... de herinneringen van een 8 uur werkdag...

...

 

en dat heerlijke gevoel van vrijheid in een jachtige wereld.

 

Maw. was ik maar bij moeder thuisgebleven :lol:

  • 0
Posted

Een ander basis theorie is die van "vraag en aanbod".

 

Dit betekend dat als je oplossing minder generiek maar juist uniek is en de klant ziet de waarde ervan. De kostprijs best hoger mag liggen.

 

De veiling eBay werkt volgens dit principe. Nu moet ik toegeven dat dit bij opdrachten iets moeilijker ligt. Maar als je heel populair zou zijn, zou het toch aardig zijn als men kon bieden op jouw tijd

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...