Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

  • bregweb
  • Registratie: juni 2005
  • Laatst online: 15:04
Ik denk dat de factor 1.4/1.6 een beetje natte vingerwerk is, of heb je daar een stevige onderbouwing voor? Is het niet gewoon een idee om die factor op te hogen? Gebruikers worden veeleisender, dus ook het maatwerk vereist meer werk.

Het is en blijft een inschatting en als je merkt dat je continue te laag zit, moet je dat wat ruimer inschatten.

Een tip is misschien om het maatwerk in meerdere kleinere stappen op te leveren, minder werk is beter in te schatten

[Voor 14% gewijzigd door bregweb op 18-12-2017 11:11]

Hattrick: Thorgal Eagles


  • Daan_
  • Registratie: augustus 2005
  • Laatst online: 14-02 18:01

Daan_

Alles op zijn tijd !!

Eerste vraag die bij mij opkomt, waarom kost het meer tijd?
* veranderd de vraag van de opdrachtgever gaande weg. (requirements)
* of heb je zelf gaande weg onderdelen niet voorzien?
* hoe is het contact gaande weg deze projecten/opdrachten. Laat je tussentijds resultaten zien (demo's etc etc...) Of ga je aan de slag en kom je bovenwater, zodra alles klaar is?
* etc etc

My plekje op het Web -_-


  • Ascension
  • Registratie: september 2008
  • Laatst online: 13:43
Het allerbelangrijkste is een hele duidelijke scope af te spreken en vast te leggen samen met je klant. Het komt namelijk heel vaak voor dat de scope gedurende een project af gaat wijken van wat is afgesproken, dat is niet zo erg natuurlijk maar als je duidelijke afspraken hebt gemaakt kan je daar ook naar verwijzen aan geven dat het meerwerk is tegen x-uurtarief.

  • BLACKfm
  • Registratie: maart 2004
  • Laatst online: 12:21
Een klant houdt natuurlijk wel van vaste prijzen, maar is op regiebasis werken niet een optie?

Als je zelf de uren niet goed inschat dan is dat mijn inziens het probleem van de opdrachtnemer (TS dus).
Dat je de 'meerwerk-factor' niet in je prijs vooraf wilt steken is dan je eigen risico. Als je stelselmatig te veel uren maakt in eigen tijd (je kunt ze niet doorberekenen omdat je zelf een lager inschatting hebt gemaakt), zou ik net zo hard zeggen dat je stelselmatig je uren wat op moet plussen.

Dat je dan duurder wordt is een nadeel voor je klanten en succes in het aannemen van klussen. Maar je bent óf te goedkoop óf te duur.

Mogelijk een hybride oplossing? De omschreven klus voor een maximumprijs insteken? Werkzaamheden binnen opdracht kosten maximaal 5000 euro (voor jezelf is de factor 1,4-1,6 hier al in berekend) en geeft aan de klant aan dat het bij meevallende uren ook 4000 euro kan worden.

Een klant weet dan in ieder geval waar die aan toe is en krijgt mogelijk nog een korting mee en jijzelf hebt sowieso de kosten gedekt.

Litebit.eu voorraad check :).


  • Basszje
  • Registratie: augustus 2000
  • Laatst online: 11:24

Basszje

Reisvaap!]

Bij een vorige werkgever deden we 'realitsche' schatting + 10% standaard. De 10% was voor klantgezeur, onderhandelen over niet-gemaakte afspraken etc ( een klant wil achteraf altijd iets anders :P )

- Naar mate ervaring weet je ongeveer hoe lang je bezig bent met een onderdeel. Neem gemiddelden van oude projecten en maak daar een excel van, zodat je makkelijk kan rekenen.

- Zorg voor optimale mogelijkheden voor codehergebruik en factuur dat in een project a 70% oid.

- Als je uit je uren loopt maar er zijn onderdelen afgesproken, kan je dat altijd nog compenseren met niet-afgesproken werk / meerwerk als de klant daarom vraagt.

- Werk met milestones. Lever een basis op voor de klant met een strakke inschatting. En na de basis extra opties voor X uur. Als er eenmaal wat staat is het ook veel simpeler de rest in te schatten.

- Bij het opstellen van offertes kijk naar de technische kwaliteit van een klant. Klant X weet veel over internet, en automatisering, Klant Y weet het verschil niet tussen browser of web. De ene klant heeft *veel* meer tijd nodig om te komen van business probleem -> technische oplossing en de kans op teleurstelling / 'dit is niet wat ik had verwacht', of ' ons factuursysteem werkt helemaal niet met primary keys' is veel groter.

Als het echt standaard niet lekker loopt, wellicht moet je dan ook eens kijken naar studie-opties. Er zijn wel wat boeken en studies te vinden over projectmanagent, management van verwachtingen en wat niet meer.

Leren van een klantprobleem een abstract model van programmeerbare modules te maken met realistische inschatting en dat terugcommuniceren als een product is op zich een vak apart :P

offtopic:
En je wil niet elke opdracht hebben. Als ik kijk naar freelance opdrachten ala ' bouw facebook voor 500 dollar en we worden samen rijk ' dan mjah

[Voor 26% gewijzigd door Basszje op 18-12-2017 12:49]

Beware of listening to the imposter; you are undone if you once forget that the fruits of the earth belong to us all, and the earth itself to nobody.


  • P_Tingen
  • Registratie: maart 2005
  • Laatst online: 10:40

P_Tingen

omdat het KAN

Bij een ruwe schatting ga ik meestal in redelijk tempo door de requirements heen, maak een globale schatting en doe die keer pi. Waarom pi? Omdat het net zo goed is als elk ander getal en het in de praktijk redelijk goed uitkomt.

Als dat niet acceptabel is, hak ik het werk net zo lang in deelblokjes op tot elk deelblokje concreet is gespecificeerd is en max 2 uur werk is. Waarom 2 uur? Omdat het dan voor mij beter in te schatten is of ik het echt in 2 uur af kan krijgen. Daarnaast is - als je eenmaal met de klus bezig gaat - al na 2 uur te zien of je voor of achter op schema loop. En vergis je niet, dat bedoel ik niet als grapje of zo. Als je het boek The Mythical Man Month van Fred Brooks hebt gelezen, dan herken je misschien de quote
quote:
"How does a project get to be a year late? … One day at a time.".
En als je het boek niet hebt gelezen kan ik het van harte aanraden, maar dat is een ander verhaal.

Als je direct weet of - en hoeveel - je uitloopt heeft dat als voordeel dat je voor jezelf leert waar je niet goed in kan schatten en naar je opdrachtgever dat hij mogelijk wat langer moet wachten op jouw output.

Als je je werk van te voren niet in blokjes van 2 uur is in te schatten, bijvoorbeeld omdat er veel onduidelijk is, is het project niet geschikt voor een fixed price. Je kunt dan beter technieken als Scrum gebruiken waarbij je opdrachtgever je op basis van je uren betaalt en na elke iteratie bepaalt of het goed genoeg is.

... en gaat over tot de orde van de dag


  • johnwoo
  • Registratie: oktober 1999
  • Laatst online: 01:05

johnwoo

3S-GTE

Ik ben ook zelfstandig ondernemer in de IT (iets meer dan 10 jaar) en ook in dezelfde hoek (maatwerk webapps). Ik heb hier ook mee geworsteld, hier mijn bevindingen:

1. Zoals gezegd, maak vooraf requirements duidelijk. Focus daarbij vooral op functionele requirements en stel een lijst met use-cases op van wat klant allemaal kan doen met zijn webapp. Ga niet al vooraf proberen elk scherm/detail uit te denken, want vooral met maatwerk is dat niet te doen: het kost enorm veel tijd en je vindt toch niet alle uitzonderingen (of soms valkuilen) die je pas tegenkomt bij het daadwerkelijk ontwerpen/maken van de software (tenzij je echt al een detailontwerp doet als onderdeel van een betaald offertetraject en je deze uren dus ook al kunt rekenen). Deze fout maakte ik vroeger teveel. Maak in je offerte duidelijk dat het om functionele zaken gaat en dat cosmetische details zoals kleurtjes, fonts, exacte positionering van elementen (waarover vooral MKB nog wel eens wil vallen) erbuiten vallen, of reken dat mee in je marge.

2. Pak vervolgens een factor/marge zoals je nu al doet, maar houd voor jezelf wel een urenregistratie bij! Na elk project stel je dan die factor bij zodat je mettertijd steeds nauwkeuriger wordt met je offertes. Uiteraard zal ervaring ook helpen met het überhaupt beter inschatten van de benodigde tijd, maar zo'n feedback loop in je factor beschermt je in elk geval enigszins tegen het geven van te lage (maar ook te hoge) offertes.

3. Probeer een groot project, of iets wat de klant wellicht niet ineens nodig heeft, op te splitsen in modules of subprojecten die apart (en liefst sequentieel, niet tegelijk) uitgevoerd kunnen worden. Je kunt dan op de aparte modules een wat gunstiger marge hanteren dan wat op het complete pakket als geheel mogelijk zou zijn.

Een voorbeeld van dit punt: stel je hebt een tweeledig product waarvoor je zelf op €15.000 uitkomt, maar het tweede deel kan best als uitbreiding gebouwd kunnen worden. Stel je factor is 1.5. In plaats van dit project als geheel voor €22.500 te offreren, kun je het beter als €10.000 + €5.000 splitsen en een iets hogere marge pakken (bv. 16.500 + € 8.000 offreren). Het totaal komt daarmee €2.000 hoger uit, maar omdat er lagere bedragen staan lijkt het voor "het gevoel" minder (of in elk geval behapbaarder). Klanten kunnen hier gevoelig voor zijn. Bovendien geeft het een mogelijkheid om het eerste (vaak grootste) deel sneller "af te kunnen sluiten".

4. In opvolging van punt 1 over de cosmetische details: overweeg om samen te werken met een ontwerper/ontwerpbureau of tekstschrijver, om jezelf op de techniek te kunnen focussen en het vele meer/nawerk over kleine details in het ontwerp te voorkomen. Of market jezelf nadrukkelijk als professional (behalve op technisch- ook op ontwerpgebied) en geef de klant hooguit 2 of 3 alternatieven en/of de mogelijkheid tot wat kleine variatie, maar geen ellenlang natraject. Market jezelf als professional en geef aan dat men vertrouwen kan hebben in de manier waarop je een webapp ontwerpt. Jij bent tenslotte degene met de ervaring die weet wat wel en niet werkt. Met name bij kleine bedrijfjes (ondernemers die gewend zijn zelf de regie over alle details van hun zaak te hebben) kun je wel eens onverwacht veel nawerk hebben op detailniveau.

5. Probeer waar mogelijk om werk uit een vaste-prijs offerte te halen en variabel facturabel te maken (uurtje factuurtje). Met name cosmetische details en support zijn hiervoor geschikt (met als argument dat het aantal van deze uren vooral van de klant afhangt), maar soms krijg je ook kleinere na-projecten (die achter het hoofdproject geplakt worden b.v. als men tijdens het hoofdtraject nieuwe requirements verzint) wel op uurbasis verkocht.

Afhankelijk van de complexiteit van de te bouwen software en het kennisniveau bij de klant calculeer ik wel tijd in om instructie te geven, maar er zijn mensen die het wel makkelijk vinden om vervolgens alsnog verzoeken tot wijzigingen (die ze zelf met het product ook kunnen doen) op de mail te blijven zetten. Dat soort dingen moet je dan ook gewoon rekenen; je bent developer, geen webmaster! Daarbij heb je minder kennis binnen het specifieke vakgebied van je klant. Uiteraard meld je dit soort dingen wel vooraf in je offerte.

Of, als het kan met het project in kwestie, gebruik überhaupt een facturering op basis van tijd (voor het hele project dus) ipv fixed price, zoals hierboven al werd opgemerkt. Zeker met wat grotere projecten in opdracht van c.q. in samenwerking met bedrijven die zelf ook wat IT-kennis in huis hebben, is dat wel doable, omdat zij het werk zelf al beter kunnen inschatten. Bij kleine klanten zonder IT-kennis gaat dat doorgaans wat moeilijker, die willen toch vooral vooraf weten waar ze aan toe zijn en zullen niet snel akkoord gaan met een factuur voor meerwerkuren. In dat geval moet je commercieel zijn, je verlies pakken en zo snel mogelijk de requirements afwerken zodat je in elk geval geen slechte mond-op-mondreclame krijgt. Met ZZP/kleinbedrijf klanten is netwerken en goede mond-op-mondreclame de beste manier om aan werk te komen.

Specs | Toyota MR2 Turbo


  • MagicTempest
  • Registratie: maart 2001
  • Laatst online: 15-05 11:11

MagicTempest

Fly pig!

Wat wij vaak doen is het design los verkopen van de daadwerkelijke realisatie. Het maken van een design is iets wat je (na een aantal keer) redelijk in kan schatten qua doorlooptijd. De klant krijgt er iets tastbaars voor terug en jij hebt een veel duidelijkere basis om een correcte ureninschatting te kunnen maken.

Er zullen klanten zijn die het vervelend vinden om op die manier te werken, maar dat is over het algemeen goed uit te leggen door te vertellen dat het ontwerp voor iedereen voordelen heeft. Beide partijen weten hoe het resultaat er uit komt te zien en krijgen een realistische prijs.

Mocht de klant het alsnog niet willen dan kan uurtje-factuurtje natuurlijk ook altijd :-)

With sufficient thrust pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. rfc 1925


  • pirke
  • Registratie: augustus 2001
  • Laatst online: 10:11
Als je structureel te laag zit moet je structureel hoger gaan schatten. Reken met een factor 2 ipv 1.4-1.6.

Dat klanten je dan te duur vinden, tja nu vind jij jezelf te goedkoop. Je zal altijd weerstand krijgen als je je effectieve uurtarief verhoogd. Dus als jij je huidige effectieve uurtarief niet toereikend vind zul je het linksom of rechtsom moeten verhogen.

En door meer uren te schatten is het makkelijker om de deadline te halen, wat weer minder stress oplevert.

  • iamcj
  • Registratie: april 2012
  • Laatst online: 17-04 14:00
Je kunt ook uitleggen waarom ict projecten vaak mislukken. Jij en de klant spreken af wat ze willen in de vorm van requirements, scope etc. Dit is gewoon een verkapte watervalmethode. De klant krijgt of niet wat hij wil, gaat lopen zeuren en jij gaat meerwerk vragen of jij gaat door je budget.

Met maatwerk weet de klant pas wat hij echt wil als hij op de knoppen heeft gedrukt. Biedt aan om eerst een design/prototype te maken en lever iedere 4 weken nieuwe functionaliteit op. Testen -> nieuwe requirements -> ontwerp -> sprint +1 bouwen. Als de klant het te duur vind worden, kan hij stoppen met een bruikbaar product. Een sprint kost x. Dan kun je een indicatie geven hoeveel sprints je denkt nodig te hebben. Dat dat niet uitkomt maakt toch niet uit en is altijd uit te leggen aan de hand van nieuwe requierements.

Uiteindelijk krijgt de klant wat hij nodig had, niet wat hij wilde en is nog goedkoper uit ook.

Haal technische uitdagingen met prototyping naar voren, communiceer.

Als die klant dit niet wil, moet jij de klant niet willen. Op die klanten verlies je altijd geld.
Pagina: 1


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True