Je werk begrijpen.
We beginnen bij de mensen die met de software gaan werken. Wat proberen ze te doen, welke informatie hebben ze nodig en waar lopen ze vast? Bestaande systemen en werkwijzen horen bij dat gesprek.
WERKWIJZE
Van eerste afspraak tot dagelijks gebruik.
Wij bouwen je software en beheren die ook. Dat begint met begrijpen wat je werk vraagt, vastleggen wat de software moet doen en bespreken wat er na oplevering nodig is.
Afspreken wat de software doet.
We maken het gewenste gedrag concreet, in gewone taal. Ook de uitzonderingen en grenzen van de opdracht horen erbij. Zo kun je meedenken over de oplossing zonder eerst een technisch ontwerp te hoeven schrijven.
Bouwen en beoordelen.
We bouwen de oplossing en bespreken met je hoe het resultaat wordt beoordeeld. De afgesproken situaties, de waarnemingen en de grenzen van de beoordeling maken duidelijk waar je naar kijkt.
Beheren en verder ontwikkelen.
Wij beheren de software die we bouwen. Gebruik, wijzigingen en verantwoordelijkheden horen daarom vanaf het begin bij het gesprek.
Eerst begrijpen
Achter een functie zit een werkelijke vraag.
‘We hebben een dashboard nodig’ klinkt als een duidelijke opdracht. Toch weten we dan nog niet welk besluit iemand ermee moet kunnen nemen.
Wie wacht nu op informatie? Wat doet die persoon als een gegeven ontbreekt? En wat gaat er mis als een besluit een dag later valt? Door dat gesprek te voeren, wordt duidelijk welk probleem de software moet oplossen en welke verandering ertoe doet.
Een bestaand formulier, een lege werkbon of een beschrijving van een lastige overdracht kan al genoeg zijn om te beginnen. De mensen die het werk doen, zien vaak andere uitzonderingen dan degenen die het proces op papier kennen. Beide perspectieven zijn nodig.
Wat we MSP+ noemen
De samenwerking stopt niet bij de eerste versie.
Wij bouwen alleen software die we daarna ook zelf beheren. Die combinatie noemen we MSP+: ontwikkeling en beheer bij één partner.
Je software wordt onderdeel van het dagelijkse werk. Mensen gaan ermee werken, vragen veranderen en nieuwe wensen ontstaan. Daarom kijken we tijdens de ontwikkeling ook naar gebruik en beheer. Het gesprek gaat over wat je nu nodig hebt en hoe je daarna verder kunt.
In de overeenkomst leggen we vooraf precies vast welke onderdelen we beheren, wanneer we bereikbaar zijn en wat er gebeurt als je stopt. Ook afhankelijkheden en documentatie horen daarbij.
Illustratieve werksituatie
Een werkbon is klaar. Maar is het werk ook afgerond?
Een medewerker meldt een opdracht als voltooid. De planning wil verder, maar de administratie mist nog informatie. De knop ‘Afronden’ blijkt meerdere afspraken te verbergen.
De gewone route
Welke informatie moet aanwezig zijn voordat de opdracht klaar is? Wie kan dat beoordelen en wie moet weten dat het werk afgerond is?
De uitzondering
Wat gebeurt er als materiaal ontbreekt of de opdrachtgever niet bereikbaar is? Benoem het verschil tussen ‘afgerond’, ‘tijdelijk onderbroken’ en ‘wacht op iemand anders’.
De afbakening
Moet deze eerste stap ook de facturatie veranderen, of blijft die voorlopig in het bestaande systeem? Een heldere grens voorkomt dat één vraag ongemerkt een heel project wordt.
Dit is een verzonnen werksituatie om de vragen concreet te maken, geen klantcase of softwaredemonstratie.
Van gesprek naar afspraak
Maak de keuzes zichtbaar voordat je verdergaat.
Een gedeeld beeld van het proces is het vertrekpunt. Daarna verdienen de grenzen en verantwoordelijkheden net zoveel aandacht als de gewenste functies.
Wat hoort bij de eerste stap?
Benoem het werk dat moet verbeteren, de mensen die ermee werken en de situaties die nog buiten de opdracht vallen. Zo blijft een eerste stap bespreekbaar.
Wie beslist over open vragen?
Sommige keuzes gaan over techniek, andere over beleid of dagelijkse afspraken. Leg vast bij wie een vraag thuishoort en welke beslissing nog ontbreekt.
Wat is nodig om iets te beoordelen?
Bespreek welke voorbeelden, uitkomsten en omstandigheden relevant zijn. Een scherm dat er goed uitziet, beantwoordt nog niet elke vraag over het werkproces.
Wat gebeurt er na de eerste versie?
Veranderingen, beheer, overdracht en verantwoordelijkheden horen in het gesprek. De concrete invulling moet bij de opdracht en de organisatie passen.
VRAGEN & ANTWOORDEN
Goed om vooraf te weten.
Moeten we al een programma van eisen hebben?
Een bestaand document helpt om keuzes terug te vinden, maar een concrete procesvraag is ook een bruikbaar vertrekpunt. Beschrijf wat nu gebeurt, wie erbij betrokken zijn en wat anders moet. Open vragen mogen nog open vragen zijn.
Wat als het proces tijdens het bouwen verandert?
Maak de verandering expliciet: welke regel wijzigt, voor welke situaties en vanaf wanneer? Bespreek ook de gevolgen voor werk dat al loopt. De impact op de opdracht, planning en kosten vraagt vervolgens om een afzonderlijke afspraak.
Moet alle bestaande software worden vervangen?
Dat volgt niet automatisch uit een maatwerkvraag. Soms ligt het knelpunt in één ontbrekende stap of overdracht. Eerst moet duidelijk worden wat bestaande systemen kunnen, welke koppelingen mogelijk zijn en waar de werkelijke beperking zit.
EEN GOED BEGIN
Waar loopt je werk vast?
Begin bij één situatie.Neem contact op