Hoe maak je een feature request aan?

Soms hebben hotels verzoeken die in de PMS niet mogelijk zijn. Dit zijn dan nieuwe functionaliteiten die door protel ontwikkeld zouden moeten worden. Aan ons is het dan de taak om eerst na te gaan of het voor protel de moeite zou zijn. Heeft het hotel bijvoorbeeld een verzoek wat (waarschijnlijk) erg veel ontwikkeling gaat kosten en wat voor andere hotels niet belangrijk (of misschien zelfs juist onhandig) gaat zijn? Dan delen we het hotel mede dat de gevraagde functie gewoon niet bestaat in protel Air. Maar als het een functie is waarvan wij het idee hebben dat het voor veel hotels handig zal zijn, kunnen we bij protel een feature request indienen.

Zo'n feature request (FR) dient altijd in een bepaald format aangeleverd te worden. protel heeft hiervoor een pdf-formulier gemaakt wat door ons (samen met het hotel) ingevuld dient te worden. Dit formulier is te downloaden via Confluence.

Het is het handigst om alle informatie door het hotel in het Engels aan te laten leveren. Uiteraard is het wel erg belangrijk om alles goed te controleren, omdat wij uiteindelijk verantwoordelijk zijn voor het indienen van het FR en wij worden er dus op aangekeken als het niet correct is. Ben dus ook niet bang om de info 2, 3 of meer keren terug naar het hotel te sturen als dit nog niet volledig is. Het heeft 3 grote voordelen om de informatie door het hotel aan te laten leveren:

Het bespaart ons tijd en kopzorgen, wij hoeven het alleen na te kijken;
Het werpt een brug op: als het hotel zelf een half uur moet investeren om alles netjes op papier te krijgen, vragen ze ons niet zomaar overal meer voor een FR in te dienen;
Je haalt een hoop ruis weg: stel dat je de functie nét anders hebt begrepen dan het hotel het bedoelde, dien je anders een verkeerd FR in. Door het hotel de info in het Engels aan te laten leveren, haal je deze kans op misinterpretatie weg.

Het is vervolgens erg belangrijk dat het formulier correct en volledig wordt ingevuld. Je moet je voorstellen dat dit gelezen wordt door een developer; die ziet heel de dag alleen maar eentjes en nulletjes en heeft waarschijnlijk nog nooit een hotel van de binnenkant gezien (althans, dat moet je uitgangspunt zijn). Jip-en-Janneke-taal is dus belangrijk. Misschien overbodig om te melden, maar belangrijk om te weten: een FR wordt altijd in het Engels ingevuld.

Het eerste veld wat we invullen is "Requested feature" ofwel het verzoek, samengevat in één zin. Dit moet eigenlijk al direct duidelijk genoeg zijn. Goede voorbeelden hiervan zijn bijvoorbeeld:

Checkout | Invoice generation | New replacement code required for Number of Cots
Reservation | Statistic Codes | Ability to define and highlight mandatory statistic codes for use by the user Slechte voorbeelden zijn:
Replacement code needed
Protel error
New Screen

Vervolgens kom de naam van het hotel, deze vind je terug in protel. In onderstaand voorbeeld zou de naam "FLOW Training 3" zijn: Het Cloud-Center-ID vind je naast de naam, in bovenstaand voorbeeld "46114".

Vervolgens vullen we de contactpersonen in van het hotel. Hierbij kunnen we een naam, e-mailadres, telefoonnummer en mobiel nummer invullen. Hoe meer informatie, hoe beter. Daarbij kunnen we ook een alternatieve contactpersoon toevoegen, dit is meestal niet nodig maar kan handig zijn als je één FR aanmaakt voor 2 hotels, ieder hotel met een eigen contactpersoon.

Bij de volgende optie moeten we het kritieke karakter invullen. Met andere woorden: hoe belangrijk is deze functionaliteit voor het hotel. Hierbij hebben we 4 opties, zie hieronder ook de officiële beschrijving vanuit protel:

Critical: Wettelijk voorschrift of financieel van belang
Required for Roll-Out: Een afgesproken/gecontracteerde ontwikkeling om een implementatie van een nieuwe klant te voltooien
Major: Operationeel van invloed, maar niet kritiek en er is een tijdelijke oplossing voorhanden
Moderate: Ontevredenheid van de gebruiker of geringe operationele gevolgen, maar er is een tijdelijke oplossing voorhanden We proberen hier altijd een zo kritiek mogelijk karakter aan te geven, om zo de prioriteit op te voeren bij protel. Echter moet de keuze nog wel te verantwoorden zijn, dus het is niet de bedoeling dat je zomaar "Critical" invult terwijl de impact niet zo groot is. De optie "Required for Roll-out" gebruiken we eigenlijk niet; dit is meer vanuit sales-perspectief als het FR voorwaarde is voor een hotel om voor protel te tekenen.

In het veld "Products affected" geef je aan op welke producten dit FR van toepassing is. Dit kan bijvoorbeeld zij "protel Air PMS", maar bijvoorbeeld ook "protel Air MICE", "airWBE", "WBE5", "IDS interfaces", "POS interfaces" of "I/O interfaces".

De "Overall description" is één van de belangrijkste velden. Hier geef je simpel, duidelijk en compleet aan welke nieuwe functionaliteit we aanvragen. Dit moet een algemene beschrijving zijn van wat we met de ontwikkeling willen bereiken. Onthoud dat het moet gaan over wat we proberen te bereiken, niet hoe het moet worden bereikt. Enkele vragen die beantwoord moeten worden zijn:

Wat zijn de voordelen?
Voor wie is de ontwikkeling bedoeld? (Front office, Accounts, Verkoop)
Wat zijn de bedrijfsregels?
Als het een wettelijke vereiste is, wat en waar zijn de wettelijke compliance stappen gedefinieerd?
Is er interactie tussen deze vereiste en andere vereisten?
Welke gebruikersrechten moeten worden opgenomen?
Welke audit mogelijkheden moeten er zijn?

Het volgende veld is ook erg belangrijk: de "Business case". Ofwel, waarom is deze functie van toegevoegde waarde. Ontwikkeling is een kostbaar proces en wat als een eenvoudige verbetering kan worden beschouwd, kan soms in duizenden euro's aan ontwikkelingsuren resulteren. De vraag die hier moet worden beantwoord is, is er een goede business case om die tijd te investeren in het bouwen van deze functie? Beantwoord de volgende vragen:

Is dit een feature voor één klant of voor alle klanten?
Als de feature zou worden geïntroduceerd, zou het extra business en inkomsten genereren voor de klant, alle klanten, alle partners en protel?
Zal het de producten gemakkelijker te verkopen maken?
Zal het overeenkomen met de functionaliteit aangeboden door onze concurrenten? Als de functie voor een specifieke klant is, stel dan de vraag: Is de klant bereid om voor de ontwikkeling te betalen? Als het antwoord "nee" is, is het zeer waarschijnlijk dat de ontwikkeling zal worden afgewezen. De prioriteit blijkt in dat geval misschien toch niet hoog genoeg te zijn.

Ook het volgende veld ("UI-Design/Look and Feel/Prototype") is erg belangrijk, omdat we hier de vormgeving voor de nieuwe functie bespreken. Stel dat protel besluit om je FR te ontwikkelen en de klant is alsnog niet tevreden met het resultaat, is dat hoogstwaarschijnlijk hier misgegaan. Dit deel is van cruciaal belang om de look & feel van de vereiste functionaliteit te begrijpen. Als het bijvoorbeeld nodig is om een nieuw scherm toe te voegen, dan kun je met behulp van een excel, powerpoint of bewerkte screenshot de lay-out maken of knoppen, beschrijvingen en berekeningen toevoegen. Als het scherm meerdere functies heeft, kopieer deze dan zo vaak als nodig is om de workflow of het proces duidelijk uitgelegd te krijgen. In deze sectie kunnen ook workflow diagrammen worden opgenomen die het proces doorlopen, zodat de interactie tussen de gebruiker, het systeem en externe systemen duidelijk te zien is.

In het deel "Assumptions" moeten eventuele veronderstellingen worden gedefinieerd, zoals:

Welke gegevensinformatie verwacht men te bewaren?
Beschrijf de tijdschema's waarnaar wordt gewerkt
Onderhoudbaarheid/toekomstige uitbreiding. Geef aan wie het systeem in de toekomst zal onderhouden (bv. intern), eventuele plannen voor toekomstige ontwikkelingen, enz.
Welke hardware-/omgevingsbeperkingen zijn er? Het systeem moet bijvoorbeeld worden uitgevoerd op Windows 7-machines met elk minimaal 2 GB RAM.

In het veld "User stories" wordt alles nog eens samengevat. Dit heeft altijd het volgende format (in het Engels): As the I would like to to achieve <object/benefit>

"As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max
“Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.
“So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving? Enkele voorbeelden:
As Max, I want to invite my friends, so we can enjoy this service together.
As Sascha, I want to organise my work, so I can feel more in control.
As a manager, I want to be able to understand my colleague's progress, so I can better report our success and failures.
As an Editor, I want to review content before it is published so that I can assure it is optimized with correct grammar and tone.

Hierbij geldt voor de "Product area" het volgende:

Product Area Short Code

Product Areas Description

RES

Reservations

INV

Invoicing/Cashiering

PRO

Profiles

A/R

Account Receivable

REP

Reporting / Genius

FIBU

Financial Accounting Export / Back Office Export

OTH

Other

CON

System Data / Configuration

Na opslaan upload je het ingevulde en ondertekende FR-formulier in het betreffende Jira-ticket.

PreviousMatch & Merge Profiles NextDezelfde lijst in de groepsreservering geeft bij verschillende users verschillende resultaten

Last updated 3 years ago