Programma op maat verkopen. Hoeveel te vragen.

[Twazerty]

Ik zit met een klein dilemma. Een vriend van mij vroeg of ik voor iemand een programmatje kon maken. Het is voor een boekhoudster van een tapijtzaak. Wat ik tot nu toe begrepen heb moet het het volgende kunnen:
aantal m² invullen en de juiste tapijtsoort kiezen. Prijzen komen eruitgerold zoals prijs met en zonder btw. Plaatjes toevoegen. Overzicht maken en deze exporteren naar pdf en/of uitprinten. Uiteraard kan ik het hier niet mee doen en heb ik meer info nodig. Maar dit waren een beetje de basiseisen. Ik wil dit gaan programmeren in java. Is naast beetje php nog het enigste wat ik ken. In java kom ik aardig uit de voeten maar na 1,5 jaar de Informatica opleiding ben je nog geen volwaardige ontwikkelaar. Mijn eerste schatting heb ik op 75 uur gegokt. Mede omdat ik exporten naar PDF nog niet ken. Heb wel al een library gevonden. Dus dat mag het probleem niet zijn. Ga eerst voordat ik de opdracht aanneem kijken hoever ik kom met 1 uurtje met die lirary spelen. Daarna nieuwe schatting maken. Maar het probleem nu is dat ik geen idee heb hoe de prijs te bepalen. Wat mag ik vragen. Een uurpijs wat me niet echt slim lijkt omdat ik veel tijd verknoei met uitzoeken hoe alles werkt. Of de betere totaalprijs. Kost het me niet zo veel uur dan heb ik geluk. Hoe de prijs te bepalen. Ik heb al vernomen dat ze te weinig tijd heeft eigenlijk om telkens alles handmatig uit te rekenen/ overzichten maken. Wie kan me helpen een juiste prijs te bedenken. Niet te veel en niet te weinig. Ik denk dat ik mijn prijs gedeeltelijk moet baseren over hoeveel tijd ze kunnen besparen hiermee. Maarja hoe.

[djluc]

Welke onderdelen moet je maken? Per onderdeel vervolgens alle acties opschrijven. Daarna hang je achter elke actie een aantal uren.

Zo kom je op je minimale kostprijs terecht. Op basis daarvan kan je op diverse manieren je verkoopprijs bepalen. Begin echter eens met de minimale kosten en post dat overzicht eens. Zelf gebruik ik hiervoor vaak Excel, werkt prima en kan optellen

[Twazerty]

djluc schreef op maandag 05 januari 2009 @ 22:37:
Welke onderdelen moet je maken? Per onderdeel vervolgens alle acties opschrijven. Daarna hang je achter elke actie een aantal uren.

Zo kom je op je minimale kostprijs terecht. Op basis daarvan kan je op diverse manieren je verkoopprijs bepalen. Begin echter eens met de minimale kosten en post dat overzicht eens. Zelf gebruik ik hiervoor vaak Excel, werkt prima en kan optellen

Wat voorbeelden ga ik nog ontvangen en zal deze lijst nog moeten maken. Ik ga wel uitpluizen wat het programma moet kunnen en wat niet.

Onderdelen begrijp ik wel. Bv rekenunit, pdf exporter enz. Wat word verstaan onder acties? Hoe bepaal ik de minimale kostprijs. aantal uren * uurloon van x euro. Maar wat mag x zijn.

[ Voor 5% gewijzigd door Twazerty op 05-01-2009 22:43 ]

[AtleX]

Tijd * uurloon + buffer doe ik altijd, hoef je alleen je uurloon in euros en je buffer in procenten maar te bepalen. Let wel op eventuele licentiekosten die er nog bijkomen (licentie voor de lib, misschien een iconset die aangekocht moet worden, etc.)

[djluc]

Onderdeel: Rekenunit
Acties:
-> Aanmaken controller class en basis documentatie
-> Opslag van calculaties opzetten
-> Opzetten van berekening algoritme
-> Klikbare interface maken bestaande uit acties:
-> Nummerieke knoppen
-> Selectie van stoffen (met voorbeeld afbeelding)

Hoeveel details hangt af van je voorkeuren.

[Alain]

Zonder specificatie kun je geen prijs maken. Je schatting vind ik dan ook uit de lucht gegrepen, zelf ben ik hier in het verleden ook mee de mist in gegaan. Probeer eerst een specificatie te krijgen, voordat je een prijs maakt.

Bij grote projecten die ik moet calculeren, waarbij vaak onduidelijkheden in de specificatie zijn, doe ik de regel: Als ik het niet zeker weet doe ik het ruim en als ik het weet doe ik het scherp.

[pedorus]

Programming FAQ - Hoeveel kan ik vragen voor ...?
Bedenk ook wat je verkoopt. Verkoop je een licentie of de copyright?

Aangezien het een vriend betreft zou ik eerst nog wat meer aandacht besteden aan de design-fase voor je een factuur maakt. Kijk bijvoorbeeld eens naar de koppeling met andere systemen.

[Twazerty]

AlainS schreef op maandag 05 januari 2009 @ 22:58:
Zonder specificatie kun je geen prijs maken. Je schatting vind ik dan ook uit de lucht gegrepen, zelf ben ik hier in het verleden ook mee de mist in gegaan. Probeer eerst een specificatie te krijgen, voordat je een prijs maakt.

Bij grote projecten die ik moet calculeren, waarbij vaak onduidelijkheden in de specificatie zijn, doe ik de regel: Als ik het niet zeker weet doe ik het ruim en als ik het weet doe ik het scherp.

Daar heb je helemaal gelijk in. De schatting heb ik voor mezelf even snel gemaakt. Specificaties/lijst minimale eisen zal ik ook opstellen en doorspelen aan de klant. Indien er nog wat mist dan hoor ik wel. Maar een eerste schatting zou mooi zijn. Nadat ik heb uitgevogeld wat er ongeveer gemaakt moet worden alleen dan wat preciezer .

pedorus schreef op maandag 05 januari 2009 @ 23:08:
Programming FAQ - Hoeveel kan ik vragen voor ...?
Bedenk ook wat je verkoopt. Verkoop je een licentie of de copyright?

Aangezien het een vriend betreft zou ik eerst nog wat meer aandacht besteden aan de design-fase voor je een factuur maakt. Kijk bijvoorbeeld eens naar de koppeling met andere systemen.

Denk gewoon de copyright. Maar dat moet ik nog even bekijken. Volgens mij is er geen koppeling met andere systemen maar dat ga ik nog uitzoeken. Design-fase waar moet ik dan aan denken. Puur het design van de GUI?

BTW dat topic helemaal over het hoofd gezien. Even aandachtig doorlezen.

[ Voor 29% gewijzigd door Twazerty op 05-01-2009 23:20 ]

[pedorus]

Twazerty schreef op maandag 05 januari 2009 @ 23:10:
Denk gewoon de copyright.

Ik zou liever een licentie verkopen, maar dat hangt er nogal vanaf of je het programma later ook aan anderen wil kunnen verkopen..

Volgens mij is er geen koppeling met andere systemen maar dat ga ik nog uitzoeken. Design-fase waar moet ik dan aan denken. Puur het design van de GUI?

Nee, ik bedoel meer het uitzoeken van wat er precies moet gebeuren, en hoe dit handig kan gebeuren (welke technologie, functionaliteiten, datamodel, etc.).

[HawVer]

Ik zou kiezen om de prijs te baseren op nacalculatie. Als je zelf niet het overzicht hebt over hoeveel tijd je er aan kwijt bent is de kans groot dat je er bij inschiet.

[scorpie]

Twazerty schreef op maandag 05 januari 2009 @ 22:33:
...

Ik denk dat ik mijn prijs gedeeltelijk moet baseren over hoeveel tijd ze kunnen besparen hiermee. Maarja hoe.

Zo moet je niet redeneren. Stel het scheelt hun 5 minuten werk, wilde je het dan ineens gratis doen? Jij houdt je bezig met jouw dingen, jij bepaalt wat het jou (qua moeite) kost om te maken. Vinden ze het de moeite (geld voor hun) niet waard? Dan niet.

[Gomez12]

Denk ook goed na over wat de klant misschien kan willen dat het programma kan.

Zoals ik het nu zie is het een vriendschappelijk klusje waarvoor geen duidelijke grenzen gezet kunnen / gaan worden.

Zorg ervoor dat je echt keihard alle wensen op papier hebt staan, bedenk zelf ook wat handige toevoegingen. Want ik heb dit soort te dingen te vaak in een drama zien uitlopen omdat de klant opeens functie x / y toch iets veranderd wil hebben en daarna nog een kleine aanpassing hier of daar.

Zoals ik het nu lees beschrijft de klant een soort van kassasysteem, maar ik gok dat een boekhoudster toch wel wat meer wil dan dat. Gaat ze straks bijv niet komen met de wens dat de voorraad er ook in bijgehouden moet worden en de inkopen.
Houd er ook rekening mee als ze zeggen hoeft nu niet. Wanneer schatten ze dit dan wel te willen en heb jij dan ook tijd om dat erbij te bouwen? Oftewel is het een one-off project of verwacht de klant dat jij er over een jaar nog steeds functionaliteit bij gaat programmeren?

[leuk_he]

Eerst aanbieden een analyse te maken wat er precies nodig is. Daar een vaste prijs voor bedenken. Je kunt wel een schatting doen wat de uiteindelijke prijs zal zijn, maar ze snappen ook wel dat dat uit de lucht gegrepen is. 75 uur is echt zo om.

Vervolgens zou je ook nog kunnen kijken of er kant en klare producten op de markt zijn NADAT je bepaald heb wat ze willen.

[Gomez12]

HawVer schreef op maandag 05 januari 2009 @ 23:30:
Ik zou kiezen om de prijs te baseren op nacalculatie. Als je zelf niet het overzicht hebt over hoeveel tijd je er aan kwijt bent is de kans groot dat je er bij inschiet.

Tsja, lijkt me een redelijke uitnodiging voor een ramp. Klant zal ten allen tijde een redelijke schatting willen horen.
Kan je die schatting niet maken en ga je op nacalculatie basis werken dan gok ik dat je een heel ontevreden klant krijgt omdat het dan uiteindelijk toch gigantisch over budget is gegaan.
Klant vraagt voor haar gevoel een kleine wijziging, jij bent hier 2 dagen mee bezig. Dat werkt niet als je het niet van te voren kan aangeven.

[Alain]

Nacalculatie zou ik bij zo'n klein project nooit doen. Gewoon goed specificeren wat je gaat maken en regelmatig overleggen. Dan kun je meerwerken met begrip betaald krijgen.

[Twazerty]

ik ben wel van plan om het op papier te zetten. Het op de juiste manier aan te pakken. Ik het het bedrijf ook helemaal niet verder dus het word zeker geen vriendschappelijk klusje. Ik zorg er wel voor dat de klant weet wat ik wel en niet ga doen. Met de gegeven informatie ga ik zeker aan de slag. Aan mijn vriend die het me vroeg geef ook wel aan dat ik dit op de juiste manier aan wil pakken. Hij maakt zelf ook een en ander voor klanten. Alleen dan grafisch ontwerper dus hij kent een vergelijkbaar probleem ook wel.

Ben van plan dit ook alleen maar als eenmalige tool neer te zetten. Kwa moeilijkheidsgraad zal het wel meevallen voor mij. Alleen dat exporten kan nog een probleem vormen. Maar eerst nog maar eens een goede beschrijving gaan vragen voor ik ook maar een prijs los ga laten.

[SchizoDuckie]

Twazerty schreef op dinsdag 06 januari 2009 @ 00:06:
ik ben wel van plan om het op papier te zetten. Het op de juiste manier aan te pakken. Ik het het bedrijf ook helemaal niet verder dus het word zeker geen vriendschappelijk klusje. Ik zorg er wel voor dat de klant weet wat ik wel en niet ga doen. Met de gegeven informatie ga ik zeker aan de slag. Aan mijn vriend die het me vroeg geef ook wel aan dat ik dit op de juiste manier aan wil pakken. Hij maakt zelf ook een en ander voor klanten. Alleen dan grafisch ontwerper dus hij kent een vergelijkbaar probleem ook wel.

Ben van plan dit ook alleen maar als eenmalige tool neer te zetten. Kwa moeilijkheidsgraad zal het wel meevallen voor mij. Alleen dat exporten kan nog een probleem vormen. Maar eerst nog maar eens een goede beschrijving gaan vragen voor ik ook maar een prijs los ga laten.

Ik heb ook wel vaker met dit bijltje gehakt en ben ook in dezelfde valkuil gelopen als de mensen hierboven: "ja maar dit zou makkelijker werken zo en zo", dat werkt niet in browser X of computer Y. Zorg dat je 100% van je specs hebt voor je ook maar 1 regel gaat programmeren! (en zorg dat je ook betaald krijgt voor het opzetten hiervan. (das herl notmaal voor het maken van een functioneel/technisch ontwerp)
Zo krijg je zelf een veel beter beeld van wat je allemaal moet gaan maken en kun je je uren inschatting hier op aanpast.

Verder: Als je nog niet zoveel ervaring hebt met het inschatten van het aantal uur wat het je gaat kosten én je eerste 'grote' project is : Doe de inschatting die je nu hebt * 2 + 20% en dan zul je ongeveer in de richting komen van een beta vrees ik

[mijn mening] :

Skip de Java en bouw gewoon plain PHP + HTML met wat leuk javascript eroverheen. Daar heb je meer aan in de toekomst, en het is *zo* veel makkelijker om op te zetten, configureren en (laten) hosten voordat je echt aan de slag kunt. (dát is dan weer ervaring )
Performance zal tig keren beter zijn voor zo'n simpele applicatie omdat je geen java hoeft te initialiseren maar gewon een browser kan opstarten en je kunt je applicatie simpel deploy'en en fixen op afstand.
[/mijn-mening]

Super simpele PHP PDF libraries zijn er trouwens ook genoeg (html to pdf is erg makkelijk in zo'n geval)

En lees je in op versioning!!

[ Voor 29% gewijzigd door SchizoDuckie op 06-01-2009 02:26 ]

[roy-t]

SchizoDuckie schreef op dinsdag 06 januari 2009 @ 02:14:
[...]


Ik heb ook wel vaker met dit bijltje gehakt en ben ook in dezelfde valkuil gelopen als de mensen hierboven: "ja maar dit zou makkelijker werken zo en zo", dat werkt niet in browser X of computer Y. Zorg dat je 100% van je specs hebt voor je ook maar 1 regel gaat programmeren! (en zorg dat je ook betaald krijgt voor het opzetten hiervan. (das herl notmaal voor het maken van een functioneel/technisch ontwerp)
Zo krijg je zelf een veel beter beeld van wat je allemaal moet gaan maken en kun je je uren inschatting hier op aanpast.

Verder: Als je nog niet zoveel ervaring hebt met het inschatten van het aantal uur wat het je gaat kosten én je eerste 'grote' project is : Doe de inschatting die je nu hebt * 2 + 20% en dan zul je ongeveer in de richting komen van een beta vrees ik

[mijn mening] :

Skip de Java en bouw gewoon plain PHP + HTML met wat leuk javascript eroverheen. Daar heb je meer aan in de toekomst, en het is *zo* veel makkelijker om op te zetten, configureren en (laten) hosten voordat je echt aan de slag kunt. (dát is dan weer ervaring )
Performance zal tig keren beter zijn voor zo'n simpele applicatie omdat je geen java hoeft te initialiseren maar gewon een browser kan opstarten en je kunt je applicatie simpel deploy'en en fixen op afstand.
[/mijn-mening]

Super simpele PHP PDF libraries zijn er trouwens ook genoeg (html to pdf is erg makkelijk in zo'n geval)

En lees je in op versioning!!

Mijn mening: stop met het gebruiken van PHP voor applicaties die gewoon offline gebruikt gaan worden en gebruik lekker java, nog steeds super makkelijk te onderhouden (e-mail nieuwe versie met simpele installer of desnoods winzip) en je hoeft er niet meteen een apache server voor op te zetten. Over performance wil ik het absoluut niet gaan hebben (sjees php sneller dan de java runtime?????) en is trouwens voor dit soort applicaties absoluut niet belangrijk, beide talen zullen snel genoeg zijn.

Edit: qua exporteren, er zijn veel goede PDF printers, heb je al eens gestoeid met het printen van data naar een printer inclusief plaatjes e.d. (ik weet niet precies hoe dit in java geregeld is, maar het zal niet al te veel verschillen van C# in opzet) ga even na hoe strak de eis is van het pdf, misschien kom je er mee weg om gewoon een printopdracht te doen en dat zei dan de pdf printer selecteren mochten ze een pdfje willen) Als dat niet de wens van de klant is zul je je even moeten inlezen, maar ik verwacht niet dat je daar veel problemen mee zult hebben.

[ Voor 11% gewijzigd door roy-t op 06-01-2009 08:49 ]

[EfBe]

(heb geen reacties gelezen in de thread)
Het is voor een bedrijf, dus ze zullen je OF zwart moeten betalen, OF je zult als een bedrijf hen de software moeten leveren. Anders komt er BTW overheen en is het duurder voor hen en dat willen ze niet denk ik.

Je moet gewoon uurprijs rekenen, want de applicatie is niet verkoopbaar aan andere partijen, het is niet een product. Als zij hun zaak laten verbouwen door een bedrijf gaat die ook eerst het aantal uren inschatten, materiaal inschatten, marge erop en dan een prijs bepalen. Jij hebt geen kosten maar je spendeert er wel tijd aan.

Hoe hoog de prijs dan wordt voor ze is afhankelijk van je uurprijs. Ik weet niet hoe goed je bent, en hoelang je ermee bezig bent. Stel je bent er 40 uur mee bezig (en declareer alleen uren die je echt hebt besteed), en je vraagt 40 euro per uur dan zit het programma op 1600 euro. Dat is wellicht een hoop geld, maar ze hebben dan ook een maatwerkpakket. Ze kunnen ook iets in Excel in elkaar prutsen en dan zijn ze goedkoper uit, maar dat is aan hen. Dus doe een offerte. Als ze roepen "Whoa, ik dacht zelf meer aan 200 euro", dan zou ik de hele handel lekker laten liggen. Tapijtzaken gaan ook niet gratis dingen weggeven.

Pdf's maken is makkelijk: printen naar een printerdriver die pdfs maakt. Deze drivers zijn universeel en open source.

[epic007]

Ga er ook vanuit dat mensen heel creatief worden zodra je versie 1.0 van je software laat zien. Er zullen al snel nieuwe wensen komen voor uitbreidingen. Bedenk van te voren goed of je deze dingen gaat doen binnen de afgesproken prijs, of dat je voor versie 2.0 weer een nieuwe offerte gaat maken.

Ook ben je waarschijnlijk na je 75 uur niet klaar. Er zullen eventueel bugs naar boven komen, ga je deze gratis oplossen ?

[bat266]

Dus alle info samengevat baken het project gigantisch goed af. Vertel wat je wel en niet doet.

[farlane]

Skip de Java en bouw gewoon plain PHP + HTML ... blah blah ...

"When all you have is hammer, everything looks like a nail."

[ Voor 65% gewijzigd door farlane op 06-01-2009 11:20 ]

[Woy]

Ik zou eerst eens goed vragen of ze er echt wel geld aan uit willen geven ( Of of jij er echt wel geld aan wilt verdienen ). Ik heb wel vaker gehad dat iemand vroeg of ik niet "even" een programma wou maken. Het hoefde niet veel te kunnen en dergelijke. Heb toen aangegeven dat ik daar best wel bereid toe was, maar dat ze niet moesten denken dat het goedkoop was, en dat ze per dag werk aan minstens 500 euro moesten denken. En dat een programma meestal niet in een dag geschreven is. Zeker niet als je rekening houd met specificatie van de wensen/bugs/wensen die veranderen.

Meestal hoor je er daarna al niks over terug omdat ze zich dan ook realiseren dat ze niet voor de prijs dat ze een windows cd kopen ook maatwerk software kunnen krijgen. Mensen denken dat het allemaal heel eenvoudig is en daarom denken ze ook in lage bedragen. Ze realiseren zich echter niet dat b.v. windows alleen zo goedkoop kan zijn omdat het miljoenen keer per jaar verkocht word.

Verder zou ik zelf wel op urenbasis werken, aangezien er geheid dingen gaan veranderen aan de wensen van de klant. Je moet natuurlijk wel van te voren een goede uren-inschatting maken, en als er dan wijzigingen komen kan je daar een nieuwe schatting voor maken.

Wat EfBe zegt over zwart betalen is natuurlijk niet helemaal waar. Je kunt als particulier ook gewoon een factuur zonder BTW maken, en die daarna opgeven bij overige inkomsten. De opdrachtgever zal dan echter ook geen BTW kunnen verekenen. Jij betaald er dan wel gewoon inkomstenbelasting over. Dit is echter alleen toegestaan als het incidenteel is. En dus niet als je elk jaar 5 van die opdrachten doet.

[MSalters]

EfBe schreef op dinsdag 06 januari 2009 @ 08:56:
(heb geen reacties gelezen in de thread)
Het is voor een bedrijf, dus ze zullen je OF zwart moeten betalen, OF je zult als een bedrijf hen de software moeten leveren. Anders komt er BTW overheen en is het duurder voor hen en dat willen ze niet denk ik.

Nee, zo werkt het absoluut niet. Er staan meer threads hierovr in W&I. Jij factureert als freelancer zonder BTW nummer nooit BTW. Zelfs als je bedrijf zou zijn en BTW zou factureren, dan maakt dat het niet duurder. De koper is een bedrijf en kan betaalde BTW aftrekken van ontvangen BTW.

Je moet gewoon uurprijs rekenen, want de applicatie is niet verkoopbaar aan andere partijen, het is niet een product. Als zij hun zaak laten verbouwen door een bedrijf gaat die ook eerst het aantal uren inschatten, materiaal inschatten, marge erop en dan een prijs bepalen. Jij hebt geen kosten maar je spendeert er wel tijd aan.

Hoe hoog de prijs dan wordt voor ze is afhankelijk van je uurprijs. Ik weet niet hoe goed je bent, en hoelang je ermee bezig bent. Stel je bent er 40 uur mee bezig (en declareer alleen uren die je echt hebt besteed), en je vraagt 40 euro per uur dan zit het programma op 1600 euro. Dat is wellicht een hoop geld, maar ze hebben dan ook een maatwerkpakket. Ze kunnen ook iets in Excel in elkaar prutsen en dan zijn ze goedkoper uit, maar dat is aan hen. Dus doe een offerte. Als ze roepen "Whoa, ik dacht zelf meer aan 200 euro", dan zou ik de hele handel lekker laten liggen. Tapijtzaken gaan ook niet gratis dingen weggeven.

Bedoel je nu geschatte of daadwerkelijk gewerkte uren? De klant hier heeft vermoed ik geen zin om het risico te lopen, zeker gezien de onervarenheid van de ontwikkelaar. Dat betekent dus offerteprijs. Extra kosten zal de TS niet hoeven maken (geen onverwachte stijging van inkoopsprijzen oid)

[Woy]

MSalters schreef op dinsdag 06 januari 2009 @ 12:39:
[...]
Bedoel je nu geschatte of daadwerkelijk gewerkte uren? De klant hier heeft vermoed ik geen zin om het risico te lopen, zeker gezien de onervarenheid van de ontwikkelaar. Dat betekent dus offerteprijs. Extra kosten zal de TS niet hoeven maken (geen onverwachte stijging van inkoopsprijzen oid)

Als je een offerteprijs maakt zul je extra goed moeten opletten dat er later geen requirements wijzigen, anders snij je jezelf erg in je vingers.

Op zich zit de TS nog op school, en dus is het niet zo'n ramp als je er iets meer tijd in steekt dan dat hij gepland had ( Als het maar enigsinds binnen de perken blijft natuurlijk ) aangezien het ook als leertraject gezien kan worden.

Ik zou ook van te voren goed afspreken waneer wat betaald word. Bijvoorbeeld bij een eerst beta versie de helft betalen en bij oplevering de volgende helft. Anders heb je natuurlijk kans dat de klant later probeert nog extra dingen gedaan te krijgen door niet te betalen. Als je dan alles betaald hebt gekregen ( en de klant het dus goedgekeurd heeft ) draag je de source-code/documentatie etc over.

[Twazerty]

Dit is tevens als leertraject. Dat leertraject vind ik nu even belangrijk als wat het op gaat leveren. Ik hoef er niet enorm rijk van te worden. Ik ga me eerst nog wat verdiepen en ga dan het een en ander bepalen zoals de prijs per uur en dergelijke afhankelijk van wat mijn schatting in uren gaat worden *2. Zei dat het een tapijtbedrijf was maar is een tegelbedrijf. Subtiel verschil.

Ben ook nog bezig met mijn hobbyproject waar al zo'n 500 uur in is gaan zitten. Maar heb er veel van geleerd. Project is nog niet af maar het resultaat mag er wezen. Daar ben ik trotsop ook al is het nog niet zo uitgebreid maar wel uniek over de hele wereld voor zover ik weet.

[ Voor 35% gewijzigd door Twazerty op 06-01-2009 13:45 ]

[TheRookie]

Vergeet dan geen rekening te houden met snijverlies

[edit]
Idd, wat asfaloth_arwen zegt, maar dan voor tegels ...

[ Voor 37% gewijzigd door TheRookie op 06-01-2009 14:17 ]

[Twazerty]

TheRookie schreef op dinsdag 06 januari 2009 @ 14:07:
Vergeet dan geen rekening te houden met snijverlies

Enigste waar ik mij ik kan snijden is het uurloon. Verder heb ik geen investeringen en andere kosten. Ben hoogstens mijn tijd kwijt maar heb er wel weer een programmeerervaring bij. Maar ga uiteraard proberen mezelf niet in de vingers te snijden.

[asfaloth_arwen]

Ik denk dat TheRookie het heeft over snijverlies met het snijden van het tapijt en invloed op de kosten, hoe dit het efficiëntste te doen etc.

[ Voor 9% gewijzigd door asfaloth_arwen op 06-01-2009 14:12 ]

[Twazerty]

asfaloth_arwen schreef op dinsdag 06 januari 2009 @ 14:12:
Ik denk dat TheRookie het heeft over snijverlies met het snijden van het tapijt en invloed op de kosten, hoe dit het efficiëntste te doen etc.

Gaat als het goed is niet in het programma komen maar alleen een aantal m2

[asfaloth_arwen]

Too bad, dat zou goed zijn voor je programmeer ervaring

Anyway, schat een aantal uren in, leuk bedrag per uur en rond dit naar boven af op een leuke aanbieding. Voor klanten is dit niet snel te duur, aangezien iemand inhuren al snel 1200€/dag kost (consultant). Stel 65 uur werk, 10€ per uur, rond af op 750 €. (Houd wel rekening met belasting etc indien van toepassing voor je) Voor een student mooi meegenomen! Let wel op dat je de eisen goed vastlegt wat afgeleverd wordt. Verder meerwerk kun je eventueel ook al een prijs per uur (nacalculatie). En vooraf aanbetaling, bij aflevering rest oid.

[unclero]

Twazerty schreef op dinsdag 06 januari 2009 @ 14:13:
[...]

Gaat als het goed is niet in het programma komen maar alleen een aantal m2

En dan zeker een optie om 1/3 extra marge erbij te rekenen. Ofzo.

(mooier zou natuurlijk een soort tekendingetje zijn met 0,5mtr rasters waarop je een globaal plattegrondje kan tekenen en dat netjes uitrekent )

asfaloth_arwen schreef op dinsdag 06 januari 2009 @ 14:18:
Anyway, schat een aantal uren in, leuk bedrag per uur en rond dit naar boven af op een leuke aanbieding. Voor klanten is dit niet snel te duur, aangezien iemand inhuren al snel 1200€/dag kost (consultant). Stel 65 uur werk, 10€ per uur, rond af op 750 €. (Houd wel rekening met belasting etc indien van toepassing voor je) Voor een student mooi meegenomen! Let wel op dat je de eisen goed vastlegt wat afgeleverd wordt. Verder meerwerk kun je eventueel ook al een prijs per uur (nacalculatie). En vooraf aanbetaling, bij aflevering rest oid.

Ik zou voor zoiets zelfs lager gaan zitten. 500 euro ofzo. Klinkt nou niet echt als erg veel werk. Sleur en pleur iets leuks in VB in elkaar. Eventueel beetje modulair opgebouwd zodat je later nog extraatjes toe kan voegen.
Offertes zou ik in templates van .rtf doen. En dan via een commandline rtf2pdf tooltje ofzo of via een pdfprinter uitspugen.
Database hoef je niet complex te maken, als het read-only moet zijn, en hooguit appenden, dan kun je zelfs met platte txt files nog een heel eind komen.

Ga goedkoop zitten. Ik laat iemand liever te weinig betalen in de aanschaf, maar smeer 'm wel een onderhoudscontractje, supportcontractje en remote-backup-contractje aan. Als iemand mijn pakket dan 3 jaar gebruikt heb ik al meer dan 2 keer de werkelijke kosten eruitgehaalt.

[rewind.]

10 euro per uur Bij de AH op de hoek verdien je nog meer man.. min 40 euro.. moet je kijken wat je bv. bij de garage betaald per uur..

[Sebazzz]

unclero schreef op dinsdag 06 januari 2009 @ 16:33:
Eventueel beetje modulair opgebouwd zodat je later nog extraatjes toe kan voegen.
Offertes zou ik in templates van .rtf doen. En dan via een commandline rtf2pdf tooltje ofzo of via een pdfprinter uitspugen.

Waarom rich-text en geen OpenDocument, Word, Open-maar-gesloten-XML of ander textueel bestandstype?

[Twazerty]

Sebazzz schreef op dinsdag 06 januari 2009 @ 21:11:
[...]

Waarom rich-text en geen OpenDocument, Word, Open-maar-gesloten-XML of ander textueel bestandstype?

Dit zijn dingen waar ik pas uit kan kiezen zodra ik de eisen ken. Het eerste wat ik tegenkwam na 2 seconden zoeken was iText. Heb het nog niet echt bekeken maar is volgens mij textueel pdf. Lijkt me een mooie uitdaging omdat daar toch wel 2D tekenen bij komt kijken. Voor zover ik heb gezien dan.


Maare 40 euro per uur. Ben je gek ofzo? Dit heeft meerdere doelen. Goede naam maken. (Gratis reclame) Leerproject om ervaring op te doen. En een leuk bedragje erbij. Zoals unclero als zei kun je beter niet te veel vragen. Tevens hoef ik er niet van te leven. En natuurlijk vind ik het leuk om een klein projectje te doen.

[Gerco]

Twazerty schreef op dinsdag 06 januari 2009 @ 22:26:
Maare 40 euro per uur. Ben je gek ofzo? Dit heeft meerdere doelen. Goede naam maken. (Gratis reclame)

Waar je reclame voor maakt is programmas op maat on the cheap. Als je later wel een fatsoenlijk uurtarief gaat rekenen (en 40 euro is nog steeds erg laag) gaat reclame waarin je voor 10 euro per uur werkt je echt niet helpen, eerder tegenwerken.

Bovendien verpest je natuurlijk de markt voor de rest van de wereld, maar dat heet dan weer (gezonde) concurrentie.

[Twazerty]

Gerco schreef op dinsdag 06 januari 2009 @ 23:35:
[...]

Waar je reclame voor maakt is programmas op maat on the cheap. Als je later wel een fatsoenlijk uurtarief gaat rekenen (en 40 euro is nog steeds erg laag) gaat reclame waarin je voor 10 euro per uur werkt je echt niet helpen, eerder tegenwerken.

Bovendien verpest je natuurlijk de markt voor de rest van de wereld, maar dat heet dan weer (gezonde) concurrentie.

Ik heb nog meer diensten/kwaliteiten naast dit project. Maarja opzich zit er wel wat in, alleen denk niet dat het een slimme strategie is voor nu. Ik kan nu zowieso niet op tegen professionele bedrijven kijkend naar kwaliteit van support en mogelijkheden met betrekking tot programmeren. Technisch gezien maakt het niet uit. 4x zo lang werken voor 1/4e van de uurprijs. Ik ga de klant niet vertellen hoeveel uur er in gaat zitten alleen de totaalprijs. Hoe ik het exact ga doen is me nog niet helemaal duidelijk maar dat komt wel.

[soulrider]

en anders is het 4x zoveel poen.

de laatste keer dat iemand naar me kwam van: kan je me eens snel helpen met een programmatje?
moest een kassa-systeem worden, heb ik hem gevraagd: stuur gewenste eigenschappen eens via mail (omdat ik al bekend was met 'maar rap effe' en 'is toch makkelijk voor jou eh')
adhv die mail merkte ik dat ie wederom er nog niet hard over nagedacht had, en heb ik hem terug gemaild dat ie toch zekers eens zeer goed moet nadenken over wat ie allemaal wenste en hoe enzo. en dat ie toch zekers mocht gaan rekenen op een prijs van een 2 a 3k. zekers omdat het af moest voordat zijn zoon zijn winkel open deed of toch niet veel later...

niets meer van gehoord achteraf. (hij had wellicht iets van <500 euro verwacht en af op een week of 2 en hem kennende duurde een goede analyse van wat ie eigenlijk wou al minstens 1 week vergaderen - ook al omdat ik niet op de hoogte ben van boekhoudige - jeps moest er ook in - programma's en zekers niet van het Nederlands belastingsstelsel als belg)
en eenmaal af ging er toch maar bijkomen 'omdat het toch handig lijkt dat ie dit of dat ook nog wel kan ingeven, afprinten of beheren...

wat je ook kan doen is samen die analyse doen en dan een afspraak maken van kijk we gaan samen aan tafel zitten van wat je allemaal wenst, als je achteraf alsnog wenst dat ik het doe, dan spreken we dan een prijs af voor alhetgeen dat dan op papier staat, en stap je ermee naar iemand anders dan wil ik x euro voor die analyse... (of x euro per uur, maar wrs beter vast bedrag hier op zetten)

bv 150 of 250 voor die analyse, krijg/doe je de opdracht kan het (of een deel ervan) een eerste aanbetaling voor je werk worden - zo voorkom je mogelijk ook al dat jij het onderzoek werk doet en hij achteraf naar een andere partij loopt bv je analyse op rentacoder.com zwiert en het voor een paar honderd dollar door een indier laat maken.
(jij analyse + werk: 750, jij enkel analyse: 250, jij enkel dev'en: 600 euro of dergelijken)

[ Voor 26% gewijzigd door soulrider op 07-01-2009 03:11 ]

[unclero]

rewind. schreef op dinsdag 06 januari 2009 @ 20:17:
10 euro per uur Bij de AH op de hoek verdien je nog meer man.. min 40 euro.. moet je kijken wat je bv. bij de garage betaald per uur..

Tsja, maar bij beiden zit je niet onderuitgezakt in je luie stoel al zakkrabbend een appje in elkaar te sleur-en-pleuren.
En imho moet je niet kijken over wat je in het hier en nu kan verdienen, maar of je ook wat over de lange termijn kan verdienen.
Smeer ze een remote-backup-contractje aan. Ga met optionele modules lopen zwaaien.
Zo'n remote-backup-contractje is een paar minuutjes werk per week, over een jaar bekeken een paar uur. (externe hdd die via ftp backupbestanden binnenhaalt die daar klaargezet worden dmv een batchscripje, en die hdd berg je op in de kluis ofzo)
Maar als je al 3 van die abonnementjes hebt (a 120 euro per jaar) cash je lekker door.

Sebazzz schreef op dinsdag 06 januari 2009 @ 21:11:
Waarom rich-text en geen OpenDocument, Word, Open-maar-gesloten-XML of ander textueel bestandstype?

"Keep it simple"
Je wilt het snel in elkaar hebben zitten. Ik heb dit soort componentjes al jaren geleden gemaakt, en kan het aan mijn project toevoegen met een "Add component" knopje. Zolang het maar keurige PDF-jes uitspuugt zal het de klant een biet wezen hoe die PDF-jes totstand zijn gekomen.

Gerco schreef op dinsdag 06 januari 2009 @ 23:35:
Bovendien verpest je natuurlijk de markt voor de rest van de wereld, maar dat heet dan weer (gezonde) concurrentie.

"Verpest de markt", bij dat soort zinnen moet ik altijd aan taxi-chauffeurs denken .

En ik denk zelf liever in lange termijn. Liever veel kleine bedragen over een langere periode bij die ene klant. Dan die ene klant in een keer een arm, been en eerstgeborene uitdraaien.

soulrider schreef op woensdag 07 januari 2009 @ 00:05:
en anders is het 4x zoveel poen.

de laatste keer dat iemand naar me kwam van: kan je me eens snel helpen met een programmatje?
moest een kassa-systeem worden, heb ik hem gevraagd: stuur gewenste eigenschappen eens via mail (omdat ik al bekend was met 'maar rap effe' en 'is toch makkelijk voor jou eh')

Klinkt bekend. Ik begin dan meestal met de hoofdprijs te noemen en op te sommen wat het volgens mij allemaal is en wat er in mijn hoofd allemaal bij moet.
Daarna begint de potentiele klant vaak te onderhandelen wat er allemaal niet bij hoeft en wat er vanaf kan.

"Ik kan de adressen van leveranciers niet wijzigen"
"Nee, dat klopt, dat wilde u er ook niet in, weet u nog?"

adhv die mail merkte ik dat ie wederom er nog niet hard over nagedacht had, en heb ik hem terug gemaild dat ie toch zekers eens zeer goed moet nadenken over wat ie allemaal wenste en hoe enzo. en dat ie toch zekers mocht gaan rekenen op een prijs van een 2 a 3k. zekers omdat het af moest voordat zijn zoon zijn winkel open deed of toch niet veel later...

niets meer van gehoord achteraf. (hij had wellicht iets van <500 euro verwacht en af op een week of 2 en hem kennende duurde een goede analyse van wat ie eigenlijk wou al minstens 1 week vergaderen - ook al omdat ik niet op de hoogte ben van boekhoudige - jeps moest er ook in - programma's en zekers niet van het Nederlands belastingsstelsel als belg)
en eenmaal af ging er toch maar bijkomen 'omdat het toch handig lijkt dat ie dit of dat ook nog wel kan ingeven, afprinten of beheren...

Hehe.. Zodra ze bij mij iets boekhoud-achtigs vragen komt er een speciaal tarief bij (ondanks dat ik een apart sales component op de plank heb liggen ). Dat zijn zaken die vaak iets ingewikkelder in elkaar zitten en je goed alle regels moet definieren. Zorg ook dat je het een beetje modulair opbouwt, want geheid willen ze later vaak nog wat regels extra en nog wat meer functionaliteit. (denk maar aan een klant die wil dat er speciale facturen voor Belgen (waarbij ze genaait worden met hun btw verlegd) worden afgedrukt ofzo)
Modulair opbouwen helpt ook voor als je later nog eens wat nodig hebt enzo.

[Gerco]

unclero schreef op woensdag 07 januari 2009 @ 11:12:
"Verpest de markt", bij dat soort zinnen moet ik altijd aan taxi-chauffeurs denken .

Het gaat er niet om dat hij goedkoop is, dat moet hij zelf weten. Het gaat erom dat het onmogelijk is om voor 10 euro per uur wit te werken als zelfstandige. Daarmee schep je een precedent waar je later zelf last van gaat krijgen.

Als je ervan moet leven is zo'n uurtarief gewoon niet mogelijk, zelfs niet als je genoegen neemt met minimumloon-equivalent.

Verpest de markt dus ja.

[asfaloth_arwen]

@Gerco, het gaat hier niet om een (volleerde) zelfstandige, maar om een student die iets erbij wilt klussen. In de consultancy ben ik in de zomer na 3 HBO (Software engineering, na een stage bij dat bedrijf) als student consultant naar bedrijven gestuurd voor X €/dag, waar een senior 3 x zoveel kost.

Waarschijnlijk zal deze software niet worden gemaakt indien de opdrachtgever de volle prijs moet betalen, anders vroeg hij geen studenten.

[ Voor 2% gewijzigd door asfaloth_arwen op 07-01-2009 11:55 . Reden: bedragen zijn niet relevant voor de discussie ]

[Woy]

asfaloth_arwen schreef op woensdag 07 januari 2009 @ 11:52:
@Gerco, het gaat hier niet om een (volleerde) zelfstandige, maar om een student die iets erbij wilt klussen. In de consultancy ben ik in de zomer na 3 HBO (Software engineering, na een stage bij dat bedrijf) als student consultant naar bedrijven gestuurd voor X €/dag, waar een senior 3 x zoveel kost.

Waarschijnlijk zal deze software niet worden gemaakt indien de opdrachtgever de volle prijs moet betalen, anders vroeg hij geen studenten.

Deels heb je gelijk, maar dat moet je dan wel heel heel erg duidelijk maken bij de opdrachtgever. Meestal willen die mensen wel gewoon een compleet functioneel product wat aan alle eisen voldoet die ze ook zouden hebben als een proffesional het gedaan zou hebben.

Als ze er tevreden mee zijn dat het net niet helemaal is wat ze voor ogen hadden, en er nog een paar losse eindjes aan zitten, of dat het toch opeens 2 maanden langer duurt voordat het af is omdat de TS een tentamen periode heeft dan kan je inderdaad een wat lager tarief hanteren.

In alle andere gevallen zou ik gewoon een "normaal" tarief hanteren. Dan bedoel ik niet meteen het tarief wat een ander bedrijf zou rekenen, maar zeker wel in die orde van grote. Je kunt er natuurlijk best een beetje onder gaan zitten, of een x aantal uur "leertijd" niet meerekenen in je berekening.

[asfaloth_arwen]

rwb je hebt een punt, maar waarschijnlijk is de TS ook langer bezig in verhouding tot een echte professional. Hoeveel is moeilijk in te schatten. Verder zou ik (als opdrachtgever) geen opdracht uitbesteden aan eenmansbedrijven/losse personen ivm support.

Dus de conclusie richting de TS, maak heel duidelijke afspraken over hoe en wat, nazorg en alles wat er bij komt kijken. Indien je een marktconform tarief wilt tellen, dan ook alleen de markt conforme uren, en niet je leer uren.

[ Voor 3% gewijzigd door asfaloth_arwen op 07-01-2009 12:15 ]

[Woy]

asfaloth_arwen schreef op woensdag 07 januari 2009 @ 12:14:
rwb je hebt een punt, maar waarschijnlijk is de TS ook langer bezig in verhouding tot een echte professional. Hoeveel is moeilijk in te schatten.

Idd daarom zeg ik ook dat je best wat uren "weg" kunt laten. Hoeveel dat is natuurlijk lastig te zeggen.

Verder zou ik (als opdrachtgever) geen opdracht uitbesteden aan eenmansbedrijven/losse personen ivm support.

De opdrachtgever doet het op het moment blijkbaar met de hand. Dus het zal geen Mission Critical systeem zijn. Mocht het niet functioneren kan de opdrachtgever altijd nog weer met de hand gaan werken. Dus wat dat betreft hoeft het vanuit de opdrachtgever nog niet zo'n slecht idee te zijn. Maar de fout is snel gemaakt om meteen op een volwaardig product te rekenen.

Dus de conclusie richting de TS, maak heel duidelijke afspraken over hoe en wat, nazorg en alles wat er bij komt kijken. Indien je een marktconform tarief wilt tellen, dan ook alleen de markt conforme uren, en niet je leer uren.

Dat is denk het belangrijkste. Maak duidelijke afspraken en zet die ook op papier ( of mail ) zodat je elkaar er later op aan kunt spreken. Mondelinge afspraken zijn leuk, maar vaak ontstaan er wel onduidelijkheden over, aangezien mensen zich wel eens wat anders willen herineren dan de ander. Let ook goed op met vage omschrijvingen. Dingen als: "Het moet snel werken", kunnen heel anders opgevat worden door andere mensen. Afspraken moeten dus wel meetbaar/controleerbaar zijn.

[ Voor 5% gewijzigd door Woy op 07-01-2009 12:59 ]

[EfBe]

asfaloth_arwen schreef op woensdag 07 januari 2009 @ 11:52:
@Gerco, het gaat hier niet om een (volleerde) zelfstandige, maar om een student die iets erbij wilt klussen. In de consultancy ben ik in de zomer na 3 HBO (Software engineering, na een stage bij dat bedrijf) als student consultant naar bedrijven gestuurd voor X €/dag, waar een senior 3 x zoveel kost.

Waarschijnlijk zal deze software niet worden gemaakt indien de opdrachtgever de volle prijs moet betalen, anders vroeg hij geen studenten.

No offence, maar een student is geen professional. Als de student zich profileert als een leerling, dan is de prijs er ook naar, en ook de kwaliteit.

De klant in deze wil kennelijk voor goedkoop, want studenten hebben kennelijk de voorkeur. Tja, als het eindresultaat niet telt, dan is eigenlijk deze hele discussie overbodig.

Of studenten die voor een appel en een ei wat prutswerk in elkaar knoeien de markt verpesten... lijkt me niet, want het zijn geen professionals. Tenzij de student beweert een professional te zijn, maar dat is een andere discussie.

[Verwijderd]

Ik vind dat er nogal lage prijzen worden afgegeven in dit topic. Als ik bedragen lees van 500,- dan denk ik "dat zou ik vragen voor 1 dag werk". Zo'n tool bouwen en uitrollen zou toch eerder een paar duizen euro kosten.

Bedenk ook dat de specs vanuit de gebruiker zijn geschreven:

1) aantal m2 invullen en de juiste tapijtsoort kiezen => bereken prijs incl. en excl. btw
Er moet dus een scherm komen om m2 in te vullen en tapijtsoort te kiezen. Maar er moet ook een mogelijkheid zijn om tapijtsoorten in te voeren inclusief prijzen, om de btw aan te passen als die weer eens verandert

2) toon plaatjes
Wil je kunnen browsen door alle plaatjes? Of alleen een plaatje tonen na het kiezen van een tapijtsoort? De plaatjes moeten ook toegevoegd kunnen worden aan het systeem. Moet de klant meekijken in het systeem, of ziet de klant alleen een printje? Wat betekent dat voor de user interface, moet die er gelikt uitzien of zijn grijze schermen goed genoeg?

En dan wat zaken die je er zo bij kan verzinnen:
1) moet er direct een bestelling gemaakt kunnen worden na het invoeren van m2 en tapijtsoort?
2) Is er een systeem waar de tool op moet draaien, of moet jij dat ook allemaal regelen?
3) Is er tijd om het systeem te testen voordat het in gebruik genomen wordt, of krijg je een testperiode in de winkel? Is het acceptabel dat het systeem wel eens een error geeft of moet het 99,9% uitgesloten zijn dat er iets misgaat als de verkoopster met de klant bezig is in de tool?
4) moeten klanten van de winkel ook online met de tool aan de slag kunnen?
5) Als er iets misgaat, binnen hoeveel tijd moet jij dan klaarstaan om het probleem op te lossen? Binnen hoeveel tijd moet het probleem opgelost zijn?
6) Als jij dit in 80 uur gaat doen en de boekhoudster van de zaak heeft werkweken van 40 uur, verwacht zij dan dat de tool eind januari af is? Of heb jij werkdagen van 2 uur naast je schoolwerk en lever je het dus begin maart op?

[asfaloth_arwen]

EfBe schreef op woensdag 07 januari 2009 @ 13:21:
[...]

No offence, maar een student is geen professional. Als de student zich profileert als een leerling, dan is de prijs er ook naar, en ook de kwaliteit.

De klant in deze wil kennelijk voor goedkoop, want studenten hebben kennelijk de voorkeur. Tja, als het eindresultaat niet telt, dan is eigenlijk deze hele discussie overbodig.

Of studenten die voor een appel en een ei wat prutswerk in elkaar knoeien de markt verpesten... lijkt me niet, want het zijn geen professionals. Tenzij de student beweert een professional te zijn, maar dat is een andere discussie.

Ik heb nergens gezegd dat een student een professional is. Ik raad dan ook ten zeerste aan om de prijs aan te passen. Vaak komen studenten wel tot het gewenste resultaat, alleen kost het meer tijd en investering in aansturing. Zolang de afspraken helder zijn moet en de TS duidelijk maakt aan zijn klant hoe en wat kan dit voor twee partijen iets opleveren.

[Data-base]

Zoals eerder gezegd is het verstandig om een concreet lijstje te maken met de requirements. Het is ook vooral belangrijk dat deze requirements eenduidig zijn en maar op 1 manier geinterpreteerd kunnen worden. Aangezien het een vriend is zou ik dit gratis doen, maar je kan ook besluiten om dit te factureren.

Wees vooral niet zuinig in de tijd met requirements en maak ze goed, liefst met screenshots die gephotoshoped zijn of UI's die gemocked zijn.

Ten eerste schept dit voor de klant vertrouwen dat jij er ook echt mee bezig bent en niet gaat aanhobbyen, en ten tweede kan dit potentieel later een hoop problemen voorkomen.

ALs je eenmaal uit bent over de requirements, ga voor jezelf na hoeveel werk dit ongeveer is. Dit moet je dan vooral top-down doen. Dus iedere requirement opbreken in zo klein mogelijke stukken en dan alle kleine stukken bij elkaar optellen. Daarbij moet je het testen (en oplossen van bugs) niet vergeten. Als zij een vaste prijs willen, zou ik je uurloon vermenigvuldigen met het aantal uur dat je geschat hebt, plus zoveel procent risico. Als zij je per uur willen betalen is dat ook prima, maar dan meoten ze ook daadwerkelijk elk gedeclareerd uur betalen (google op Klok (Adobe Air) voor urendeclaratie).

Vervolgens zou ik de offerte samen met de reuiqrements laten ondertekenen, en dan pas aan de slag gaan.

[Twazerty]

Het analyseren, ontwerpen, requirements SMART opstellen ed zijn dingen die ik allemaal al gehad heb op school en zijn verder ook geen probleem. Topic is meer bedoelt hoe ik de prijs kon bepalen. Daar heb ik nu wel meerdere visies in gezien. Vooral de requirements zijn nu erg belangrijk om misinterpetatie te voorkomen. Mijn vriend speelt nu als tussenpersoon. Hopelijk tijdelijk want kan beter direct met de klant in contact komen. Aangezien hij geen ICTer is. Anders zou het niet uitmaken. Ik denk niet dat ik de markt verziek. Als een bedrijf het te duur vind komt het er gewoon niet. Dus de markt heeft niet veel te verliezen. Ik kan ook opdrachten afwijzen. Zal ik ook zeker doen als ik geen goede hoop zie.

[Gomez12]

Twazerty schreef op woensdag 07 januari 2009 @ 17:26:
Mijn vriend speelt nu als tussenpersoon. Hopelijk tijdelijk want kan beter direct met de klant in contact komen.

Stap 1 is echt gewoon die tussenpersoon ertussenuit halen, als die de requirements vanuit de klant gaat doorcommuniceren dan krijg je gegarandeerd miscommunicatie.

Persoonlijk zou ik gewoon geen stap zetten zolang die tussenpersoon ertussen zit. Elke communicatie fout betekent een ontevredener klant en waarschijnlijk voor jou onbetaald bijprogrammeren ( klant heeft specifiek om iets gevraagd, tussenpersoon heeft dit niet doorgegeven ( was logisch/standaard voor hem ) en wie mag het er aan het einde bijprogrammeren? )

Helemaal als dit je eerste echte klus is dan wil je geen chinese whispers hebben.

[Twazerty]

Gomez12 schreef op woensdag 07 januari 2009 @ 21:17:
[...]

Stap 1 is echt gewoon die tussenpersoon ertussenuit halen, als die de requirements vanuit de klant gaat doorcommuniceren dan krijg je gegarandeerd miscommunicatie.

Persoonlijk zou ik gewoon geen stap zetten zolang die tussenpersoon ertussen zit. Elke communicatie fout betekent een ontevredener klant en waarschijnlijk voor jou onbetaald bijprogrammeren ( klant heeft specifiek om iets gevraagd, tussenpersoon heeft dit niet doorgegeven ( was logisch/standaard voor hem ) en wie mag het er aan het einde bijprogrammeren? )

Helemaal als dit je eerste echte klus is dan wil je geen chinese whispers hebben.

I know. Heb wel geluk dat hij enige kennis heeft van programma's. Soort tweaker, klooit ook met hard/software. Hij kan een en ander wel goed uitleggen. Is nog wel handig nu. Zodra ik een eerste docu heb ga ik hem ertussenuithalen. Maar voor nu zit hij daar nog wel mooi tussenin. Even de start aanzwengelen. Daarna requirements opstellen.

[ Voor 3% gewijzigd door Twazerty op 07-01-2009 21:55 ]

[EfBe]

Twazerty schreef op woensdag 07 januari 2009 @ 21:54:
[...]
I know. Heb wel geluk dat hij enige kennis heeft van programma's. Soort tweaker, klooit ook met hard/software. Hij kan een en ander wel goed uitleggen. Is nog wel handig nu. Zodra ik een eerste docu heb ga ik hem ertussenuithalen. Maar voor nu zit hij daar nog wel mooi tussenin. Even de start aanzwengelen. Daarna requirements opstellen.

Iemand die klooit met hardware is iemand die klooit met hardware en niet een software engineer. Als je dus goede requirements engineering wilt doen, welke belangen voor welke stakeholders gelden, welke dingen ze willen, dan moet je dat zelf doen of iemand die daarin bedreven is moet dat doen.

Uit eigen ervaring weet ik dat als je niet vanaf het begin betrokken bent bij het project, je alleen maar ellende krijgt, want de 'tussenpersoon' heeft altijd verwachtingen gewekt die jij maar waar moet maken, of vertelt de helft maar aan je door etc.

Je ziet dit als een leertraject, doe het dan ook zo dat je er iets van leert, en niet dat je head-first het diepe in springt en 'wel ziet waar we uitkomen', want ik geef je op een briefje dat het zoals je het nu schetst een grote kans van falen heeft. (komt niet alleen door jou, die klant wil kennelijk ook voor duppie op de eerste rang)

[ione]

Er werd in dit topic al eerder gesproken over service-contracten. Wat bieden jullie zoal aan in dergelijke contracten?
Ik maak nu maatwerk-paketten (die eventueel met kleine aanpassingen ook bij een ander bedrijf in dezelfde branche kan draaien). Ik bereken dan een vast bedrag voor een applicatie. Elke latere aanpassing die ze willen hebben wordt weer een nieuwe offerte. Uiteraard zijn bugs ed voor mijn rekening. Ik doe nu echter niiks met servicecontracten. Ik wil dit wel gaan doen, omdat je dan ook wat meer binding houdt met de klant. Maar wat zou er in zo'n contract kunnen zitten.
- remote back-up (database-file FTP-en naar mijn server)
- support bij vragen over de werking
- oplossen van bugs
- ....??

[leuk_he]

ione schreef op donderdag 08 januari 2009 @ 10:53:
an ook wat meer binding houdt met de klant. Maar wat zou er in zo'n contract kunnen zitten.
- remote back-up (database-file FTP-en naar mijn server)
- support bij vragen over de werking
- oplossen van bugs
- ....??

Repsonse gegarandeerd. Als zij een probleem hebben dat je gegearanderd binnen x uur eraan begint. Als ze geen service contract hebben ga jij lekker betaald uitbreidingen lopen bouwen ipv van direct trouble shooten. En uiteraard moet er ook dekking zijn als jij op vakantie bent.

Dat wil neit zeggen dat je de telefoon niet beantwoord als ze geen service contract hebben, maar langs komen om een probleem op te lossen is uiteraard een andere zaak.

Het heet ook niet oplossen van bugs, maar abonnement op nieuwe releases... (de discussie of iets een bug is of niet gespecificeerd wil je zover mogelijk voor je uitschuiven.

[ Voor 5% gewijzigd door leuk_he op 08-01-2009 11:10 ]

[ione]

leuk_he schreef op donderdag 08 januari 2009 @ 11:09:
[...]


Het heet ook niet oplossen van bugs, maar abonnement op nieuwe releases... (de discussie of iets een bug is of niet gespecificeerd wil je zover mogelijk voor je uitschuiven.

Dit is waar ik dan ook een beetje mee zit. Voor nieuwe wensen (uitbreidingen) wil ik het liefst met een nieuwe offerte met prijs werken. Het gaat om maatwerk-applicaties. Als ik uitbreidingen via een service-contract ga doe, moet ik er zelf op inleveren (of prijs van service-contract wordt onaantrekkeijk hoog).

Wat ik eigenlijk wil is dat nieuwe verzoeken via een nieuw offertetraject gaan (dat doe ik nu ook). En dat de service (backup, support, etc) via een contractje (dat heb ik nu nog niet).

[EfBe]

ione schreef op donderdag 08 januari 2009 @ 11:43:
[...]


Dit is waar ik dan ook een beetje mee zit. Voor nieuwe wensen (uitbreidingen) wil ik het liefst met een nieuwe offerte met prijs werken. Het gaat om maatwerk-applicaties. Als ik uitbreidingen via een service-contract ga doe, moet ik er zelf op inleveren (of prijs van service-contract wordt onaantrekkeijk hoog).

Wat ik eigenlijk wil is dat nieuwe verzoeken via een nieuw offertetraject gaan (dat doe ik nu ook). En dat de service (backup, support, etc) via een contractje (dat heb ik nu nog niet).

Regel het goed want je komt vroeg of laat in de problemen.
Het punt is: wat lever je: een dienst of een product. Indien je een dienst levert, dan maak je software tegen een uurtarief en de resultaten zijn voor de klant. Willen ze daarop support, dan is dat een dienst, willen ze aanpassingen, gewoon weer een dienst. Een fout in de resultaten is dus niet voor jouw rekening tenzij je dat zo hebt afgesproken. Dit kan verregaande consequenties hebben: als de geleverde software nl. een bug bevat die dermate grote schade oplevert dat de klant veel geld verliest of erger, ben jij dan verantwoordelijk? Bij een SLA garandeer je een zekere kwaliteit. Wees ervan bewust dat dat wel eens moeilijkheden kan opleveren in de praktijk. Dus 'bugs zijn voor mijn rekening' is makkelijk gezegd, maar dat kan erg nadelig voor je uitpakken.

Lever je een product, dan is de zaak heel anders: je levert de gebruikerslicentie met een EULA. In die EULA staat altijd dat je je niet verantwoordelijk acht voor nadelige gevolgen door gebruik van de software. Het is dan aan jou om te bepalen hoeveel en of een klant uberhaupt support krijgt.

Bij de eerste situatie, de dienst levering, is het verstandig een acceptatietest te laten doen door de klant alvorens de spullen worden opgeleverd. Dit houdt in dat de klant de spullen test en aan een serie acceptatiecriteria onderwerpt, die samen met jou zijn opgesteld. Wees er alert op dat die acceptatietests de gehele applicatie dekken. Het punt is nl. dat wanneer de klant nadat alles is accepteert komt klagen, je de acceptatietest resultaten hebt om de klager te wijzen op het feit dat ze het zelf hebben getest en geaccepteerd.

Een EULA + koop is in feite hetzelfde voor de product situatie.

[leuk_he]

ione schreef op donderdag 08 januari 2009 @ 11:43:
[...]
Dit is waar ik dan ook een beetje mee zit. Voor nieuwe wensen (uitbreidingen) wil ik het liefst met een nieuwe offerte met prijs werken. Het gaat om maatwerk-applicaties. Als ik uitbreidingen via een service-contract ga doe, moet ik er zelf op inleveren (of prijs van service-contract wordt onaantrekkeijk hoog).

Nieuwe releases bevatten dan gewoon je basis fucntionaliteit. Zolas bugs die je bij klant 1 gevonden hebt. Nieuwe functionalteit zijn extra modules. (ik neem aan dat je programmatuur een vorm van modules kan hebben) die je uit wilt rollen vial een acceptatie test zoals hierboven beschreven. Andere klanten wil je niet automatisch nieuwe modules geven, die zou je namelijk via een acceptatie test daar ook weer moeten testen.

Met neiwue release bedoel ik de minor releases, ofwel de verkapte bug-fixes. (maar dan nogmaals, software heeft geen bugs, enkel features, of tekort aan features.)

[ione]

Mijn huidige werkwijze:

- ik maak een offerte voor een klant voor een maatwerkapplicatie
- ik ga na akkoord aan de slag en als het af is installeer ik het bij de klant
- na een week of twee vraag ik de klant een acceptatieformulier te tekenen waarbij zij aangeven de programmatuur te hebben getest. In mijn alg. voorwaarden heb ik mijzelf ook gevrijwaard voor eventuele financiele consequenties van een fout. Met zo'n formulier dek ik het dus af.

Als de klant weer aanpassingen wil hebben begint het procesje weer vanaf het begin.

Nu wil ik dus eigenlijk hierbij een (vrijwillig?) support-contract aanbieden.