App ontwikkeling kosten

[JJ93]

Hoi!

Ik ben een informatica student en in m'n vrije tijd geregeld bezig met het maken van Android apps. Ik kreeg vandaag een mailtje van een verzekeringsbedrijf die interesse had in een app.

Ondertussen een aantal mailtjes verder en nu is het duidelijk dat het gaat om een app waar je schade kunt melden, wijzigingen kan doorgeven of een nieuwe verzekering kunt afsluiten.

Dus volgens mij is de bedoeling dan een home screen waar je één van de opties kunt selecteren en vervolgens ga je door naar een nieuw scherm met een formulier die je kunt invullen en verzenden.

Mijn vraag is dus vooral wat ik kan vragen voor het ontwikkelen van zo'n app. Ik vraag me ook af wat jullie de handigste manier van ontwikkelen lijkt en hoe je zoiets verder het beste kan regelen. Om alles via mail te doen en elkaar blindelings vertrouwen lijkt mij ook niet al te handig.

Wat mij vooral belangrijk lijkt is dat ik ook echt ontwikkel wat de klant wilt. Dus ik kan mijn kennis nu in de praktijk brengen op dat vlak maar het blijft lastig met minder technische mensen.

Iemand met enkele ideeën en/of tips?

Mvg,

JJ

[Kurkentrekker]

Spreek een scope af, goed afbakenen, en begroot voor ze hoeveel uur je dat kost. Daarbij kun je afhankelijk van wie je klant is een uurtarief vragen waarvan jij denkt dat ze het willen betalen succes!

[P.O. Box]

Ten eerste moet je minimaal een keer langsgaan om hun wensen te bespreken en te noteren... zeg als afsluiting van dat gesprek dat je binnen x dagen hen een offerte zal doen toekomen op basis van wat jullie besproken hebben... doe geen uitspraken over hoeveel uur je denkt nodig te hebben tijdens zo'n gesprek... je uurtarief mag je eventueel wel al noemen uiteraard...
in de offerte een uurtarief stellen en dan een schatting maken van het aantal uren dat het je gaat kosten... goed specificeren wat onder dat aantal uren valt en dan als laatste zin opnemen "meerwerk of werk dat buiten deze specificatie valt wordt berekend op basis van nacalculatie"... en vervolgens vragen ze je nog een paar jaar lang allemaal aanpassingen en updates waar je gewoon strak je uurtarief voor kunt vragen...
(hou bij het bepalen van je uurtarief rekening met de belastingafdracht.... 50 euro staat niet gelijk aan 50 euro overhouden)

de offerte kan uiteraard aangepast worden totdat er een ondertekende versie in jouw bezit is...

praktisch moet je zorgen dat je goede contactpersonen hebt voor vragen e.d.... (ook telefonisch)

[ Voor 6% gewijzigd door P.O. Box op 10-04-2014 22:29 ]

[CyBeRSPiN]

Willen ze niet ook een iOS app? Hoe ga je daar dan mee om?

[JJ93]

Kurkentrekker schreef op donderdag 10 april 2014 @ 21:58:
Spreek een scope af, goed afbakenen, en begroot voor ze hoeveel uur je dat kost. Daarbij kun je afhankelijk van wie je klant is een uurtarief vragen waarvan jij denkt dat ze het willen betalen succes!

Lijkt me inderdaad erg belangrijk om de scope goed af te bakenen. Om echt goed in te schatten hoeveel uur het gaat kosten is best lastig. Maar zoiets zou inderdaad kunnen, bedankt!

P.O. Box schreef op donderdag 10 april 2014 @ 22:28:
Ten eerste moet je minimaal een keer langsgaan om hun wensen te bespreken en te noteren... zeg als afsluiting van dat gesprek dat je binnen x dagen hen een offerte zal doen toekomen op basis van wat jullie besproken hebben... doe geen uitspraken over hoeveel uur je denkt nodig te hebben tijdens zo'n gesprek... je uurtarief mag je eventueel wel al noemen uiteraard...
in de offerte een uurtarief stellen en dan een schatting maken van het aantal uren dat het je gaat kosten... goed specificeren wat onder dat aantal uren valt en dan als laatste zin opnemen "meerwerk of werk dat buiten deze specificatie valt wordt berekend op basis van nacalculatie"... en vervolgens vragen ze je nog een paar jaar lang allemaal aanpassingen en updates waar je gewoon strak je uurtarief voor kunt vragen...
(hou bij het bepalen van je uurtarief rekening met de belastingafdracht.... 50 euro staat niet gelijk aan 50 euro overhouden)

de offerte kan uiteraard aangepast worden totdat er een ondertekende versie in jouw bezit is...

praktisch moet je zorgen dat je goede contactpersonen hebt voor vragen e.d.... (ook telefonisch)

Thx. Leek mij inderdaad ook handig om minimaal één keer langs te komen. Zo'n type offerte lijkt me inderdaad wel goed passen. Belastingafdracht is inderdaad ook belangrijk. Ik denk al langere tijd na om officieel een eenmanszaak op te zetten. Met de nieuwe regelingen is het ook aantrekkelijker geloof ik. Maar dan moet ik wel een aantal opdrachten hebben per jaar.

CyBeRSPiN schreef op donderdag 10 april 2014 @ 22:46:
Willen ze niet ook een iOS app? Hoe ga je daar dan mee om?

Dat heb ik inderdaad gevraagd maar daar was verder niet op gereageerd. Een app puur om formulieren in te vullen lijkt mij persoonlijk ook niet erg handig. Dan zou ik eerder de website responsive laten maken. De website zelf zou vrij simpel responsive gemaakt kunnen worden heb ik het idee.

[EiT]

Of gebruik gewoon Phonegap.

[t_captain]

Een belangrijk aspect dat je niet moet vergeten is dat je inspanningen niet voorbij zijn wanneer de app eenmaal werkt. Eerst ga je het traject van oplevering in. Mijn ervaring is dat er in die fase (waarin je voor het eerst een tastbaar product hebt) twee dingen naar voren komen:

1. afwijkingen tussen de verwachtingen van de klant en datgene wat de ontwikkelaar heeft gemaakt
2. goede ideeen voor nieuwe features

Wat betreft punt 1, dat kun je deels (maar niet helemaal) afdichten door een goede spec en ook door tijdens het project met de klant in gesprek te blijven. Alleen de factor "voortschrijdend inzicht" kun je nooit helemaal uitbannen.

Punt 2 is commercieel best interessant, maar je moet voorkomen dat je allemaal meerwerk in je oorspronkelijke budget krijgt geduwd.

Mijn advies is om in je offerte een zeker aantal uren te reserveren voor communicatie tijdens de ontwikkeling en kleine aanpassingen rondom de oplevering. Verder zou je een budget voor meerwerk kunnen opnemen; binnen dat budget is het immers makkelijker voor je klant om die ene extra feature te laten bouwen. Anders moet hij weer budget loskrijgen voor meerwerk, wat naar de managementlaag daarboven weer klinkt als een budgetoverschrijding, wat je opdrachtgever niet wil, en dan ervaar je als leverancier een druk om het meerwerk voor niets te leveren. Voor het meerwerk voorbij die ene feature spreek je het best een uurtarief af.

[Haan]

Ik zou ook even goed nadenken over de complexiteit van de app. Het klinkt simpel, maar er komt wel e.e.a. bij kijken.
Het gaat om een verzekeringsmaatschappij, je hebt te maken met vertrouwelijke gegevens van klanten. Hoe gaan ze inloggen in je app? Hoe ga je de gegevens secure versturen? Er moet sowieso iets van een API zijn waar jij tegenaan moet programmeren, heb je daar al documentatie van ontvangen? Etc. etc.
Je moet eerst al die vragen op een rij hebben en een antwoord op die vragen voor je een betrouwbare ureninschatting kan maken

[418O2]

Ga even serieus praten over platforms en versieondersteuning. Je moet voor elk platform een fysiek device hebben om te testen, emulators dekken alles niet 100% af.

Heb je hier ervaring mee? Want het is wat lastiger dan je denkt. Hoe werkt de backend bijvoorbeeld? En beveiliging?

[ongewoongewoon]

EiT schreef op vrijdag 11 april 2014 @ 09:57:
Of gebruik gewoon Phonegap.

Of http://www.appcelerator.com/ , best simpel in gebruik. Wel even over inlezen, elk voordeel heeft z'n nadeel.

Wat betreft de kostenberekening kan ik alleen maar als tip geven om dingen goed op papier te zetten. een functioneel ontwerp kan daar absoluut bij helpen.Grote projecten hebben meer dan eens de neiging om "uit de klauwen" te lopen kwa uren. Maak daarom goede afspraken over de urenbegroting en een eventuele overschrijding daarvan

[ Voor 52% gewijzigd door ongewoongewoon op 11-04-2014 11:07 ]

[ATS]

Er zijn, heel grof weg, twee modellen: een vaste projectprijs, of op uurbasis. Beiden hebben voor en nadelen. Op projectbasis moet je voor je begint echt een heel goed beeld hebben van wat het moet worden, en dat ook vastleggen in afspraken. Voordeel voor de klant is dat hij weet wat hij koopt voor hoeveel, maar dan kan eigenlijk alleen als hij ook weet wat hij eigenlijk wil hebben, en dat lijkt lang niet altijd het geval. Er zitten risico's aan een project zoals anderen hierboven al schetsen.

Op uurbasis ben je flexibeler. Het laat een meer agile benadering toe, waarbij je steeds delen oplevert, daarvoor betaald krijgt, en gedurende het proces kan bijsturen, gebruik maken van voorstschreidend inzicht en eventueel juist dingen kan schrappen cq. herprioriteren omdat het tijdsschema dat vereist. Je moet dan wel afspreken dat je per sprint factureert en betaald krijgt. Merk op dat je hier nog steeds een begroting kan maken van hoeveel tijd je denkt dat het project gaat duren, gebaseerd op je huidige begrip van het project en op basis van een serie aannames (die je dus expliciet maakt).

Ik reken zelf voor projecten een hogere uurprijs dan voor losse uren, gewoon omdat het risico van de planning bij mij ligt. Als ik er naast zit, al dan niet omdat ik een ander beeld heb van wat de klant wil dan de klant (of zijn baas) wil, dan ligt het risico van het meerwerk bij mij. Daar bouw ik een marge voor in. Aan de andere kant biedt een groter project meer zekerheid op inkomsten, en dat verantwoord een lager uurtarief dan een kort projectje op urenbasis. Het goedkoopste (voor de klant) is een lang project op uurbasis

Je uurtarief is natuurlijk voor een heel groot gedeelte afhankelijk van je ervaring. Minder ervaring is een lager tarief. Maar inderdaad: verkijk je niet op dingen als belastingafdracht, of ook, als het project groot dreigt te worden, het in gevaar komen van je stufi. Houdt dus tenminste zo'n 50% van je verdiensten apart hiervoor, totdat je je aangifte gedaan hebt en je weet waar je echt staat. Wellicht is dat te veel, maar beter een meevaller dan een tegenvaller volgend jaar.

[merauder]

Bij een dergelijke opdracht zou een uitzendovereenkomst ook erg interessant zijn. Hiermee werk je in principe meteen op basis van uurtje-factuurtje, waarbij je alleen een inschatting van het aantal uren moet maken, maar het belangrijkste, je werkt veel met financiële gegevens, waarbij je een aanzienlijk afbreukrisico hebt.

Door voor een uitzendbureau te werken verleg je dus deze verantwoordelijkheid.

[sschalkwijk]

Hou er ook rekening mee dat je waarschijnlijk jezelf wilt verzekeren. Bij een grotere klus, zeker voor een verzekeringsmaatschapij, kan het zijn dat er schade komt door een programmeer foutje vanuit jouw kant. Bedrijven kunnen die op jou verhalen en indien je niet goed verzekerd bent, moet je dat zelf betalen. Zoek goed uit wat je aan verzekeringen nodig hebt en hoeveel dit kost. Deze kosten moet je namelijk ook doorberekenen aan de klant.

Betreffende kosten. Ik heb van een ontwikkel bureau voor apps wel eens gehoord dat deze een startprijs hebben vanaf € 10.000 euro per platform. Afhankelijk van de wensen dan dit dan meer worden. Dan ben je nu nog student en hoef je vermoedelijk geen pand kosten en alles ervan te betalen.

[Iblies]

Vind het zelf een beetje frappant dat een "verzekeringsmaatschappij" bij een relatief klein bedrijf een dergelijke applicatie wil laten bouwen.

Je moet met een aantal aspecten rekening houden en indien die van tevoren niet besproken zijn loop je daarbij het risico dat achteraf er een discussie ontstaan waarbij partijen elkaar de vingers nawijzen.

Belangrijk aspect van ondernemerschap is dat je soms nee moet verkopen. Als je hier niet echt in thuis bent en je hebt het gevoel dat de tegenpartij niet echt realistisch is, dan zou ik er niet aan beginnen.

[ATS]

Iblies schreef op vrijdag 11 april 2014 @ 11:21:
Vind het zelf een beetje frappant dat een "verzekeringsmaatschappij" bij een relatief klein bedrijf een dergelijke applicatie wil laten bouwen.

Mwah, dat valt wel mee. Ik heb in het verleden ook wel eens iets voor een zorgverzekeraar gemaakt (een applicatie voor gebruik in hun callcenter) als student.

[418O2]

Oja niet geheel onbelangrijk; dek support af en toekomstige ondersteuning af, of regel daar wat voor. Anders wordt dat later een erg lastig verhaal.

[mobstaa]

Leuk, maar lastig project. Er is echt een ontzettend groot aantal zaken waar rekening mee moet worden gehouden, of dit als alleenstaande programmeur makkelijk te realiseren is een ander verhaal.

Er moet niet alleen kennis zijn op vlak van programmeren, maar ook op het vlak van jezelf kunnen indekken tegen eventuele schade.

Zorg ervoor dat je met de klant aan tafel gaat zitten en echt duidelijk op papier hebt wat de wensen en eisen zijn. Nu moet je wat de klant verteld zelf ook ontzettend goed kunnen begijpen en zonder deze klant aan een ander kunnen uitleggen hoe de applicatie moet werken en wat (om zo maar iets te noemen) elke button doet.

Je werkt alleen en het lijkt mij slim om de klant er nauw betrokken te houden bij je ontwikkel proces. Apps kunnen via .apk bestanden gestuurd worden, alvorens deze in de Play store staan. Zo kun je bijvoorbeeld de lay-out al laten zien + basis functionaliteiten. Succes!

[Ahrnuld]

Het hangt ervan af, ben je bekend met hoe de backend van de verzekeringsmaatschappij in elkaar zit? Hoe je App klantgegevens gaat opvragen, meldingen verwerken etc?

Als het gaat om het verpakken van aanvragen in e-mails met een vast formaat is het al een heel ander verhaal, en veel beter van tevoren in te schatten, dan wanneer je moet communiceren met specifieke (web)services en er gevoelige(?) klantgegevens worden verstuurd (SSL certificaat?). In dat laatste geval zou ik een fixed price niet aanraden.

In het eerste geval zou je een ontwerp, misschien zelfs incl. niet-werkend prototype, bij de offerte kunnen voegen en aangeven dat dit is wat men krijgt, en dat wijzigingen vallen onder per uur betaald onderhoud. Je zou evt. ook een bedrag af kunnen spreken voor het opstellen van ontwerp en offerte, als men daarvoor openstaat.

[ Voor 7% gewijzigd door Ahrnuld op 11-04-2014 12:35 ]

[MrMonkE]

Open deuren zal ik ook even intrappen.

Goede afspraken over:

- functionaliteit, wat gaat het doen. Waar moet het op werken. Functioneel ontwerp.

- technisch ontwerp, hoe gaat het allemaal werken.

- scope bepalen en vastleggen op papier.

- oplevering, wanneer moet het af zijn

- meerwerk lopende het project uit aanvullende eisen die afwijken van de scope berekenen en vastleggen.
vooraf uurtarief afspreken voor extra uren.
nee durven zeggen.

En verder:
- contactpersonen bij bedrijf hebben die je kunt benaderen als je vragen hebt.
als je via een manager alles moet vragen en doen wordt je helemaal gek, dat zijn meer een soort stoorzenders.

- zorg dat het veilig is, er zijn talloze mensen die apps afpluizen op zoek naar zaken die ze kunnen misbruiken.
embedded login/passwords, 'geheime' urls, business logic in de frontend en niet in de backend en die dus omzeilt kan worden door een kwaadwillende.

- gebruik professionele ontwikkel omgeving, dus met een sourcecontrol omgeving (SVN of GIT bijvoorbeeld) en hou ergens back-ups.
dus niet alles op 1 laptop.

- als je dingen signaleert die misgaan onmiddellijk communiceren.
niet als je 3 weken voor de deadline denkt dat je die niet haalt gaan wachten tot een dag voor
de oplevering en zeggen dat het niet op tijd af zal zijn.

Verder ken ik een ZZP'r die al meer 4 jaar op 1 plek zit. mazzelaar.
Dus dat kun je gewoon doen.

Success!

[ObAt]

@MrMonkE Dit is allemaal juist, je vergeet alleen enkele zaken.

Planning, wanneer moet welk deel zijn opgeleverd. In welke tijdsperiode gaat het project starten.
Kosten, kosten voor het maken van de op VOLGENS de afgesproken requirements. Moet er een aanbetaling worden gedaan? Zijn er tussen opleveringen?
Change management, hoe moet er een wijziging aan de app worden aangevraagd
Out of scope, wat ga ik niet doen. App onderhouden, marketing materiaal maken, updates doorvoeren
Interface, hoe moet ik deze applicatie in de het huidig systeem integreren?

Dus: Eerst een Project plan (Project Initation Document -> PID) met een omschrijving van hoe je te werk gaat (inclusief een planning). Daarna een Software Requirement Specification maken (SRS) en dit bij de offerte meeleveren. De sponsor (degene die je gaat betalen) moet dit ondertekenen. De requirements moet je verzamelen via een interview, het is niet handig om dit alleen via mail te doen. Hierdoor kunnen veel communicatie fouten ontstaan.

Nu begint het daadwerkelijke werk: Maak een prototype (mockup oid) en laat de sponsor dit goedkeuren. Daarna kun je beginnen met programmeren. Vergeet niet de juiste personen up-to-date te houden zo dat ze niet afvragen wat je aan het doen bent!

Klinkt allemaal zeer omslachtig en veel te veel werk, maar geloof me maar, als niet alles op papier staat krijg je op het einde de grootste problemen. Ik heb de meest gekke dingen meegemaakt in mijn eerste grote project, en zo doe ik het nooit meer.

'Ik dacht dat functie X ook in de applicatie zat!'
'Dit is niet wat ik verwachtte'
'Je brengt toch wel gratis al deze wijzigingen aan die haaks op je ontwerp staan?'

[ Voor 9% gewijzigd door ObAt op 11-04-2014 15:00 ]

[JJ93]

@EiT
Ik zit inderdaad wel te kijken naar programma’s waarmee je de app kunt exporteren voor iOS, Android en WP als het kan.

@t_captain
Klopt inderdaad. Er werd al gesproken om in de toekomst inzage te kunnen krijgen in facturen via de app. Dus er komt nog aardig wat bij kijken na de initiële oplevering. Bedankt voor de tips.

@Haan
Dat vroeg ik mij inderdaad ook af. Volgens mij gaat het gewoon om een formulier invullen die vervolgens wordt opgestuurd (naar een emailadres gok ik). Ik weet verder niet hoe het allemaal geregeld is.

@Catch22
Yup dat is zeker belangrijk. Ik heb het al aangekaart maar er is verder nog niet op gereageerd. Ik weet nog niet wat nou precies de bedoeling is. Als het gaat om alleen formulieren invullen en opsturen is er niet een backend nodig. De beveiliging is wel belangrijk natuurlijk. Dus in ieder geval versturen via HTTPS oid.

@ongewoongewoon
Ziet er inderdaad goed uit.

@ATS
Thx, erg informatief. Met m’n stufi moet ik wel een beetje oppassen ja. En ook met zorgtoeslag. Ik krijg overal het minimum maar alsnog een flink bedrag op jaarbasis.

@merauder
Ja dat zou inderdaad ook kunnen. Op zich wel mooi.

@sschalkwijk
Klopt lijkt me inderdaad ook handig. Ik weet niet om hoeveel persoonlijke gegevens het nou echt gaat.

@iblies
Mwah de grootte van de applicatie valt volgens mij wel mee. De reden dat hij mij mailt weet ik natuurlijk ook niet precies. Stuk goedkoper dan de grote jongens natuurlijk. Goed punt wat betreft realistisch te ontwikkelen valt. Ik heb hier het idee dat er waarschijnlijk steeds meer bijkomt en dat ze niet goed realiseren dat je niet zomaar een app in elkaar kan klikken.

@mobstaa
Daar heb je een goed punt. Ik weet nog niet al te veel af met betrekking tot kosten in rekening brengen, indekken tegen schade, etc. Van daar dat ik ook dit topic heb gemaakt. De klant nauw betrokken houden bij het ontwikkelproces lijkt me in ieder geval een goed idee. Dat wordt ook vaak gezegd door een leraar die ook bij een software-ontwikkelingsbedrijf werkt. Indien de klant het niet eens is kan het aangepast worden. Als de klant het ergens wel mee eens is: noteren zodat je jezelf kan indekken.

@BerendBoon
Voor zover ik tot nu toe weet wordt er in eerste instantie niet gewerkt met de backend en klantgegevens. Ik heb inderdaad meer het idee dat er emails verstuurd moeten kunnen worden en formulieren ingevuld moeten kunnen worden.
Een niet werkend prototype lijkt me inderdaad een goed idee. Er werd wel benoemd dat het mooi zal zijn als er in een latere versie ook inzage gegeven kan worden in facturen. Maar daarvoor ging hij eerst contact opnemen met de huidige leverancier.

@MrMonkE & ObAt
Bedankt, een aantal goede punten! Er komt nog meer bij kijken dan ik al van uitging. Erg leerzaam in ieder geval.

—-

In ieder geval bedankt iedereen voor de reacties. Een aantal erg interessante punten zijn genoemd. Ik ga in ieder geval proberen om er achter te komen wat er nou precies gemaakt moet worden. Als er ook functies in moeten zitten die communiceren met hun huidige backend dan lijkt mij dat niet een goed idee.

Ten eerste weet ik niet hoe de backend in elkaar zit, en ten tweede heb ik niet genoeg ervaring met de gehele financiële en juridische afhandeling. Er werd dus al wel genoemd dat het mooi zou zijn als er via de app inzage gegeven kon worden in de facturen. Ik heb geen idee hoe dat nu is geregeld maar er is in ieder geval nog geen API.

Als het dus inderdaad om een app gaat waarbij een aantal formulieren kunnen worden ingevuld en opgestuurd kunnen worden dan kan ik dat wel realiseren. Maar zoals meerdere keren benoemd is blijft het daar niet bij. Er moet vaak nog nieuwe functionaliteit toegevoegd worden. Inzage in de facturen bijvoorbeeld: dat valt eigenlijk niet te realiseren door mij.

In mijn mailtje ga ik in ieder geval proberen duidelijk te maken wat ik kan leveren, en ga ik er proberen achter te komen wat de klant zelf graag geleverd ziet. Ik zal de toekomst ook aankaarten i.v.m. nieuwe functionaliteit.

Als het niet duidelijk wordt dan moet ik ‘nee’ verkopen. Als het gaat om een formulier app dan lijkt het mij persoonlijk alsnog handiger voor het bedrijf om de ontwikkelaar van de website te contacteren. Ik denk dat je namelijk beter af bent met een responsive site.

[Ribo89]

Denk ook na over de wijze waarop je omgaat met je intellectuele eigendomsrechten. Op de programmeercode van de app heb jij in principe auteursrecht. Wanneer de verzekeringsmaatschappij een andere ontwikkelaar wil laten werken aan de app, dan is dit alleen mogelijk wanneer zij het auteursrecht op de programmeercode hebben of wanneer zij van jou een licentie hebben gekregen om wijzigingen of aanvullingen op jouw programmeercode te maken. Wanneer je het auteursrecht niet hebt overgedragen of geen licentie heb gegeven die onder andere strekt tot het wijzigen en aanpassen van de programmeercode, dan kun jij dit verbieden wanneer zij dit wel doen.

Wanneer jij het auteursrecht overdraagt aan de verzekeringsmaatschappij, dan betekent dit dat jij delen van je programmeercode, strikt gezien, niet meer mag (her)gebruiken voor andere apps.

[Woy]

JJ93 schreef op vrijdag 11 april 2014 @ 15:49:
.... een hoop onzekerheden ...

Ik lees in deze post dat je vooral een hele hoop niet weet. Ik zou dan ook niet snel een fixed price afspreken met de klant.

Is het niet een beter idee om een x aantal uur af te spreken, waarin jij een prototype maakt. Die bespreek je dan met de klant, en dan bespreek je wat er nog moet veranderen/bijgemaakt moet worden. Als je dat zo een aantal iteraties doet kom je uiteindelijk tot een mooie applicatie. Doordat je telkens na x uur werk met de klant om tafel gaat zitten heeft die ook invloed op hoe de applicatie ontwikkeld. Vaak veranderen de inzichten toch erg als ze uiteindelijk wat resultaat voor hun neus hebben.

Ik zou op deze manier dus een soort SCRUM methode gebruiken, en in sprints werken. Jij hebt minder risico, aangezien je gewoon voor je uren betaald wordt. En de klant heeft minder risico op een product dat uiteindelijk niet aansluit op hun wensen. ( + ze hebben beter inzicht in de vorderingen, waardoor ze eerder bij kunnen sturen mocht het project uit de band vliegen ).

[Hydra]

Ik ben het met Woy eens: ik heb tot eind Maart gewerkt bij een bedrijf dat apps maakt (als projectleider, zelf geen app-bouw ervaring, ben zelf backend programmeur) en zelfs voor een 'professioneel' bedrijf zijn zaken als scoping lastig: er is altijd vanuit de klant "voortschrijdend inzicht".

Als je fixed price werkt, doe je daar altijd een 'risicotoeslag' op omdat het uiteindelijk nooit helemaal naar wens is, en die tijd moet je op kunnen vangen. Even als voorbeeld van een app die we toen voor een klant gemaakt hebben:
- App voor een specifieke doelgroep om contacten en teksten op te halen (vanuit de backend, een zelfgemaakt CMS dat via een JSON API data laat downloaden)
- Naast de statische data konden gebruikers ook nog eens zelf gegevens aan contacten (zoals secundaire telefoonnummers) toevoegen
- Developmentinschatting kwam uit op 300 uur, maal 1.44 voor testen en projectmanagement kwamen we uit op 432 uur. Fixed price factuur gemaakt voor 30000 euro, dus 70 euro per uur grofweg intern. Extern alleen de 300 uur opgegeven, dit omdat die klant binnengehaald 'moest' worden, die 70E/uur is dan ongeveer kostprijs.
- Heel duidelijk afgestemd dat alles buiten de offerte meerwerk a 100 euro / uur was.

Ik denk dat je in jouw geval ook het beste af kunt spreken in korte incrementen te werken. Dus op korte termijn een prototype (voor 1 platform), en dit dan later uitbreiden in korte 'sprints'. Ga je ajb wel verdiepen in frameworks zoals Phonecap / Sencha e.d.: je kunt voor een dergelijke app niet voor elk platform een nieuwe gaan bouwen. En als een dergelijke klant voor een "App" komt, bedoelden ze HOE DAN OOK dat dat ding op iOS moet werken! Stem HEEL duidelijk af op welke devices dat ding moet werken, zelfs met alleen iOS heb je al een hoop werk aan zowel de 3, 4S en Ipads te gaan ondersteunen, laat staan als je een hoop android devices moet gaan ondersteunen. Die hebben allemaal net iets andere resoluties.

Daarnaast: zorg dat je precies weet hoe data precies heen en weer moet. Als jij zegt "dat lukt me wel" gaat de klant er vanuit dat jij het regelt; jij bent namelijk de expert. Je kunt hoe dan ook later niet terugkomen met "ja maar ik dacht dat het gemaild moest worden, ik wist niet dat ik die formulieren naar een webservice moest pushen": dat is jouw verantwoordelijkheid. Dat je een beginner bent doet er niet aan af; die verzekeringsmaatschappij wil gewoon voor een dubbeltje op de eerste rang zitten.

[ Voor 11% gewijzigd door Hydra op 23-04-2014 13:32 ]

[ReallyStupidGuy]

Ook al is het maar een kleine app die je gaat opleveren, houdt er rekening mee dat je niet voor de lokale damvereniging aan het werk bent.
Even een kleine stel: Stel, je levert de app op en doordat deze niet goed werkt wanneer de datum 29 februari is kunnen de opgestuurde schademeldingen niet worden verwerk. Directie van de verzekeringsmaatschappij moet opdraven bij die blonde doos van Radar en natuurlijk wordt de juridische afdeling ingeschakeld om de schade te verhalen.
Ben je hiervoor aansprakelijk? En ben je hiervoor verzekerd? (bij dezelfde maatschappij natuurlijk )

Je moet dus echt zorgen dat je een aantal zaken goed hebt afgedekt voordat je hieraan begint. Het klinkt als een hele mooie kans om iets neer te zetten waarvoor je in de toekomst ook nog support en uitbreidingen kunt realiseren. Veel bedrijven zijn om zo'n soort manier begonnen, maar nu moet je in je eentje de rol van accountmanager, juridisch specialist, projectleider, analist, FO-er, ontwikkelaar en tester gaan realiseren. En dan maak ik me voor jou nog het meeste zorgen om de juridisch specialis, misschien omdat ik daar zelf geen kaas van heb gegeten.

Zou het geen optie zijn om deze opdracht als freelancer, dus op uurbasis ingehuurd door de verzekeraar, uit te voeren?

[Anders]

Aanvullende tip: Vraag de helft vooraf en lever niet op voordat je het binnen hebt. Al maak je nog zulke goede afspraken, er zijn genoeg grote bedrijven die op het laatst toevoegingen eisen en anders domweg niet betalen, wetende dat eenmanszaakjes praktisch gezien weinig andere mogelijkheden hebben dan te gehoorzamen.

Spreek daarom ook een heel duidelijk eindpunt af - zeker bij fixed price - en geef aan dat bugs die binnen x weken na oplevering gemeld kosteloos worden verholpen, en dat ze daarna tegen uurtarief worden opgelost. Voorkom, kortom, dat je een speelbal wordt

[JJ93]

@RikBouman
Het auteursrecht is inderdaad ook een belangrijk punt. Hier moet ik inderdaad goed op letten. Dit kwartiel het vak project organisatie & recht afgerond dus ik heb al een beter beeld van de software rechten etc.

@Woy
Fixed price lijkt mij ook niet een goed idee inderdaad. Een prototype maken zou inderdaad kunnen. Maar ik zit dan nog steeds met de verschillende platformen. Met een prototype kom je er wel beter achter wat de klant wel en niet wilt.

@Hydra
Thx, interessante post. iOS hoort er inderdaad zeker bij en Android ook. De rest van de platformen zijn nog niet genoemd. Android kan ik prima werkend krijgen maar mijn iOS kennis loopt een enorm stuk achter. Ik heb morgen vakantie en dan ga ik weer aan de slag met Objective C en iOS development.

@ReallyStupidGuy
Juridisch komt er een hoop bij kijken ja.. nog meer dan ik origineel dacht. Zeker bij een verzekeringsmaatschappij. Inderdaad in m’n eentje alles regelen. Juridisch heb ik wel wat kennis omdat we wel een aantal vakken hebben gehad.

Ik moet eerlijk zeggen dat het niet mijn favoriete vakken zijn maar met dit topic merk ik ook weer hoe belangrijk die vakken toch zijn.

Ik weet niet precies hoe het zit om als freelancer te werken. Een ander nadeel is dat de maatschappij aan de andere kant van het land zit. Als het hier in de buurt was dan was het een stuk makkelijker voor mij geweest.

Ik zit namelijk ook nog gewoon met een 40-urige schoolweek. Om om de paar weken daar heen te reizen (2,5u) een praatje te maken en weer terug te reizen kost me dan gewoon een hele dag.

@Anders
Bedankt voor de tips. De kosten moeten inderdaad 100% duidelijk zijn.

—-

Een hele hoop reacties in ieder geval. Door de combinatie van (te) weinig ervaring en de lange reisafstand begin ik hier toch een beetje van af te zien. Ik heb niet tientallen uren de tijd per week omdat ik ook nog voltijd studeer.

Er komt enorm veel bij kijken en op dit moment heb ik eigenlijk niet de tijd om alles uit te zoeken en te regelen en te ontwikkelen denk ik.

Volgend kwartiel gaan we 32 uur per week, 8-10 weken lang met een groep van 6-7 studenten met een officieel project aan de slag. Een aantal projecten van bedrijven maar ook van mijn studievereniging en een afstudeerder. Ik ben benieuwd in welke groep en bij welk project ik word ingedeeld. Dit lijkt mij in ieder geval een mooie leerervaring.

Ik heb morgen vakantie en ik ben ook van plan om mijn eigen website verder te updaten. Dankzij dit topic heb ik in ieder geval een stuk beter idee waar ik allemaal op moet letten bij toekomstige projecten.

Ik zal er nog even een nachtje over slapen en morgen een emailtje sturen.

[418O2]

Niet doen. Ik heb iets vergelijkbaars gemaakt voor android en ios en dat was ongeveer 80-100 uur werk en dat was nog maar een proof of concept voor de klant (ook verzekeringsbranche) en opgezet door mensen met heel veel meer ervaring dan jij. Als we dit echt gaan bouwen, gok ik dat de teller zeker op 300+ uur staat.

[Woy]

JJ93 schreef op donderdag 24 april 2014 @ 23:41:
@Woy
Fixed price lijkt mij ook niet een goed idee inderdaad. Een prototype maken zou inderdaad kunnen. Maar ik zit dan nog steeds met de verschillende platformen. Met een prototype kom je er wel beter achter wat de klant wel en niet wilt.

Ik zou een prototype wel in je uiteindelijke taal maken, anders is het weggegooide moeite/geld. Kijk dus inderdaad naar frameworks als Phonegap, Xamarin en andere vergelijkbare frameworks.

@Hydra
Thx, interessante post. iOS hoort er inderdaad zeker bij en Android ook. De rest van de platformen zijn nog niet genoemd. Android kan ik prima werkend krijgen maar mijn iOS kennis loopt een enorm stuk achter. Ik heb morgen vakantie en dan ga ik weer aan de slag met Objective C en iOS development.

Ik zou persoonlijk geen tijd verspillen aan Objective C, voor een overgroot gedeelte van de apps wil je geen native app ontwikkelen, want dan ben je meedere keren hetzelfde aan het maken. Cross platform frameworks zijn een stuk efficiënter ontwikkelen.

Ik zal er nog even een nachtje over slapen en morgen een emailtje sturen.

Op zich is er niks mis mee dat je op deze manier een keer ervaring opdoet, maar zorg er in ieder geval voor dat de opdrachtgever dat ook beseft, en dat de verwachtingen dus in lijn liggen met wat jij op kunt leveren ( Dat is waarschijnlijk iets minder (snel) dan je nu in gedachten hebt ).

418O2 schreef op vrijdag 25 april 2014 @ 00:27:
Niet doen. Ik heb iets vergelijkbaars gemaakt voor android en ios en dat was ongeveer 80-100 uur werk en dat was nog maar een proof of concept voor de klant (ook verzekeringsbranche) en opgezet door mensen met heel veel meer ervaring dan jij. Als we dit echt gaan bouwen, gok ik dat de teller zeker op 300+ uur staat.

Op zich hoeft het natuurlijk geen probleem zijn dat er een hoop tijd in gaat zitten, het belangrijkste is dat je geen verwachtingen, of erger nog verplichtingen, wekt die je niet waar kunt maken.