{"id":55846,"date":"2018-05-03T07:32:04","date_gmt":"2018-05-03T07:32:04","guid":{"rendered":"https:\/\/blog.salesflare.com\/?p=55846"},"modified":"2026-02-23T16:13:28","modified_gmt":"2026-02-23T15:13:28","slug":"how-to-organize-development-in-a-lean-software-startup-108bf51ab123","status":"publish","type":"post","link":"https:\/\/blog.salesflare.com\/nl\/hoe-de-ontwikkeling-te-organiseren-in-een-lean-software-startup-108bf51ab123-2","title":{"rendered":"Hoe je ontwikkeling organiseert in een lean software startup"},"content":{"rendered":"
\n
<\/header>\n

Hoe je ontwikkeling organiseert in een lean software startup<\/h1>\n

Binnen Salesflare<\/h2>\n
\n
\n
\n
\n

Het opstarten van een technologiebedrijf kan een chaotisch, stressvol en lonend proces zijn.<\/p>\n

Maar een van de dingen die in een vroeg stadium echt kunnen helpen, is om structuren te hebben die je team in staat stellen om effectief en effici\u00ebnt te werken - vooral aan de ontwikkelingskant. Het laatste wat je bedrijf nodig heeft is chaos bij het bouwen van je product. \ud83d\ude31<\/p>\n

Dus, hoe begin je? En uitbesteden of inhuren<\/a>?<\/p>\n

Hieronder volgt een korte handleiding voor het samenstellen en structureren van je SaaS-ontwikkelteam<\/a> - en als je besluit om uit te besteden, kun je deze handleiding ook als raamwerk gebruiken. \ud83e\udd29<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Ontwikkeling binnen je bedrijf categoriseren<\/strong><\/h4>\n

Een van de dingen die kunnen helpen bij de ontwikkelingsstructuur is om de verschillende soorten ontwikkelingstaken in het bedrijf op te splitsen in categorie\u00ebn, zodat je een beter idee krijgt van de prioritering, delegatie en organisatie binnen het team. \ud83e\udd1d<\/p>\n

Hieronder staan de drie ontwikkelingscategorie\u00ebn die we bij Salesflare hebben:<\/p>\n

Problemen <\/strong>zijn dingen die kapot zijn en moeten worden opgelost in het product.<\/p>\n

Maar wat heeft prioriteit? En hoe organiseer je ze? Daarom hebben we kwesties onderverdeeld in drie extra categorie\u00ebn: directe kwesties, instant staging<\/a> en niet-instant kwesties.<\/p>\n

Directe problemen zijn de problemen die - je raadt het al - onmiddellijk moeten worden aangepakt. Dit kunnen dingen zijn die echt<\/em> kapot zijn, dingen die de gebruikers opmerken, dingen in de app die gerepareerd moeten worden, enz. \ud83d\udea8<\/p>\n

<\/figure>\n

\"man<\/p>\n

Instant staging is niet zo \"instant\" als instant issues, maar dit zijn dingen die moeten worden opgelost voordat de nieuwste softwareversie wordt vrijgegeven in de productieomgeving. Dit zijn meestal problemen die we opmerken op onze staging-omgeving door intern te testen.<\/p>\n

Niet-instant problemen hebben een lagere prioriteit en worden besproken in de sprintvoorbereidingsvergadering (waarover later meer).<\/p>\n

UX-verbeteringen <\/strong>krijgen een hogere prioriteit dan niet-instant problemen en omvatten alles in ontwikkeling dat betrekking heeft op de ervaring en bruikbaarheid van het product. In wezen zijn dit dingen die de ervaring voor klanten verbeteren.<\/p>\n

Kenmerken <\/strong>zijn nieuwe functionaliteiten die we aan het product willen toevoegen, zoals bulkacties, geavanceerd filteren, enz. Deze hebben de laagste prioriteit van de geplande taken tijdens een sprint.<\/p>\n

Hoewel het opsplitsen van de soorten ontwikkeling je kan helpen om je team beter te organiseren, hoe bepaal je dan wie wat aanpakt?<\/p>\n

\n
\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Support Hero is hier om de dag te redden!<\/strong><\/h4>\n

Als SaaS-bedrijf begrijpen we hoe belangrijk het is om problemen snel op te lossen om klanten de best mogelijke ervaring te geven. Dat betekent echter niet dat het hele team zijn dagen moet besteden aan het oplossen van problemen - dan krijgen we geen ander werk gedaan! \ud83d\udc68\u200d\ud83d\udcbb\ud83d\udc69\u200d\ud83d\udcbb<\/p>\n

Daarom gebruiken we een systeem dat zowel afleiding wegneemt als de productiviteit binnen het ontwikkelteam verhoogt. We noemen het de Support Hero.<\/p>\n

\n
<\/div>\n<\/figure>\n

\"superman\"<\/p>\n

De Support Hero is \u00e9\u00e9n persoon in het ontwikkelteam, die dagelijks wordt gerouleerd en die zich richt op problemen die direct moeten worden aangepakt (en meer diepgaande en technische vragen van gebruikers beantwoordt), zodat het team zich op zijn taken kan blijven concentreren. \ud83d\udcaa<\/p>\n

Alle problemen die niet op dat exacte moment door de Support Hero kunnen worden opgelost, worden geregistreerd in GitHub, de software die we gebruiken voor code- en probleembeheer, en worden vervolgens zo snel mogelijk aangepakt.<\/p>\n

Het mooie van een Support Hero is dat je zelfs met een klein team hoogwaardige ondersteuning kunt bieden aan je klanten - alle diepgaande technische problemen kunnen ter plekke worden opgelost, waardoor het frustrerende proces van het moeten doorgeven van problemen aan de \"juiste\" persoon wordt vermeden.<\/p>\n

Het beste deel: Het hebben van een Support Hero brengt uw ontwikkelaars dichter bij uw klanten. \ud83d\udc9b<\/strong><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Het draait allemaal om structuur<\/strong><\/h4>\n

Nu we de soorten ontwikkeling en het delegeren van taken hebben besproken, gaan we het hebben over organisatie<\/em> van je structuur. Alle verschillende onderdelen hieronder komen samen om aan te geven hoe het team verder gaat.<\/p>\n

Een productvisie en stappenplan <\/strong>kan je helpen om te weten waar je met het product naartoe wilt, zodat je functies in gedachten hebt die je daar kunnen brengen - dit overlapt idealiter met wat je oppikt van je ondersteuning. \ud83d\udc53<\/p>\n

Ondersteuning<\/strong> is alles over het krijgen van feedback van klanten<\/a>. Dit omvat functieverzoeken, problemen en UX-verbeteringen die de eerder genoemde productvisie en roadmap volgen. Log deze in en neem ze mee naar de sprintvoorbereidingsvergadering.<\/p>\n

Een probleemtracker<\/strong> rapporteert fouten zowel aan de back-end als aan de front-end. Het stelt je ook in staat om te zien welke problemen er verschijnen, zelfs zonder dat mensen het je vertellen. Een suggestie is Elastic APM - maar er zijn vele opties.<\/p>\n

Intern testen<\/strong> stelt je hele team in staat om nieuwe functies te testen voordat ze live gaan. We testen actief voordat updates van staging naar productie worden vrijgegeven. En omdat we Salesflare intern gebruiken, kunnen we zelf ook mogelijke problemen en verbeteringen in het product ontdekken. Het is altijd goed om je team zoveel mogelijk gebruik te laten maken van je product, zodat je eventuele problemen uit de eerste hand kunt zien en een goed inzicht krijgt in je eigen product.<\/p>\n

Hotjar <\/strong>Opnamesessies kunnen je team helpen om te zien hoe mensen met het product omgaan en waar dingen fout (of goed) gaan. Opnames van gebruikers, hoewel niet dagelijks nodig, kunnen je extra inzicht geven in hoe mensen je product gebruiken, omdat je kunt zien wat ze meemaken zonder dat ze het aan je hoeven uit te leggen.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Tijd om te sprinten!<\/strong><\/h4>\n

Structureer het werk van je ontwikkelteam in sprints - een agile methodologie. Als algemene richtlijn zijn sprints van twee weken het meest gebruikelijk voor IT en software productontwikkeling.<\/a> \ud83c\udfc3\u200d<\/p>\n

Het is echter wel aan te raden om je sprintmeetings voor te bereiden - anders kan het een beetje chaotisch en on-topic worden.<\/p>\n

Dit kan worden aangepakt door sprintvoorbereidingsvergaderingen te houden. De CTO, producteigenaar en productmanager (lees meer over het verschil tussen producteigenaar vs productmanager<\/a>) wonen deze vergadering bij en gebruiken deze tijd om te kijken naar dringende problemen die overblijven, UX-verbeteringen, niet dringende problemen en functies. Dit helpt bij het bepalen van de agenda en prioriteiten voor de komende sprint zonder dat er tijd hoeft te worden vrijgemaakt voor de sprintvergadering zelf. \u2705<\/p>\n

Dan is het natuurlijk tijd voor de sprintmeeting! De sprintvergadering zoomt technisch in op wat er tijdens de sprintvoorbereidingsvergadering is besproken, zodat het ontwikkelteam precies weet hoe het te werk zal gaan. Het geeft ook een platform om onmiddellijke problemen samen als een team te bekijken. Bij deze vergadering moeten ook de CTO en het ontwikkelteam<\/a> aanwezig zijn. De producteigenaar en het ondersteuningsteam kunnen ook deelnemen, maar zijn in dit stadium minder nodig.<\/p>\n

Aan het begin van deze vergadering is het een goed idee om na te denken over de vorige sprint - wat ging goed, wat ging fout, enz.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Wat zit er in je gereedschapskist?<\/strong><\/h4>\n

De tools die je binnen je bedrijf gebruikt, kunnen je ontwikkelteam voorbereiden op succes. We hebben Hotjar en Elastic APM al genoemd, maar er zijn ook andere tools die je kunt gebruiken voor gestroomlijnde communicatie en taakbeheer<\/a>:<\/p>\n

Slack - <\/strong>voor interne discussies, updates\/meldingen, het delen van bestanden en af en toe een grappige gif<\/p>\n

Trello - <\/strong>voor taak\/projectbeheer en -tracering<\/a> wie wat doet in een bepaalde sprint<\/p>\n

GitHub - <\/strong>waar we problemen, functieverzoeken, enz. bijhouden.<\/p>\n

Intercom - <\/strong>voor communicatie met klanten<\/p>\n

Een geweldig aspect van het gebruik van deze tools is dat ze met elkaar kunnen communiceren. We krijgen bijvoorbeeld updates van Trello en Github in Slack. En in Trello gebruiken we een GitHub power-up die GitHub-info in Trello integreert. \ud83c\udf10<\/p>\n

Bovendien kunnen we GitHub koppelen aan Intercom conversaties, zodat we altijd de context bij de hand hebben; en wanneer we functies verzenden of problemen oplossen, kunnen we daar foutloos over communiceren.<\/p>\n

\n
\n
<\/div>\n

<\/p>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Ongeacht hoe je de ontwikkeling in je bedrijf wilt structureren, het is altijd belangrijk om ervoor te zorgen dat je team - hoe groot of klein ook - kan werken binnen de processen die je besluit te gebruiken. \ud83d\ude80<\/p>\n

Wees niet bang om dingen te veranderen als ze niet werken! De sleutel is om te vinden wat werkt voor jou en je bedrijf en daar mee verder te gaan.<\/p>\n

We hopen dat deze korte handleiding je wat inspiratie heeft gegeven over hoe je je ontwikkelteam kunt opbouwen en structureren!<\/p>\n

Heb je nog meer leuke idee\u00ebn? Vertel het ons in de comments! \u2728<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Genoten van deze post? Bekijk de rest van onze <\/em>Binnen Salesflare<\/em><\/a> serie.<\/em><\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

Voor meer nieuws over startups, groeimarketing en verkoop<\/em><\/p>\n

\ud83d\udc49<\/em><\/strong>abonneer hier<\/em><\/strong><\/a><\/p>\n

\ud83d\udc49follow @salesflare on <\/em><\/strong>Twitter<\/em><\/strong><\/a> of <\/em><\/strong>Facebook<\/em><\/strong><\/a><\/p>\n<\/div>\n<\/div>\n<\/section>\n<\/section>\n