Miért éri meg a ,,quick winek” mentén haladni?

Észrevettük az Onbox 2017 októberi indulása után, hogy a specifikációinkban sok volt az alaptalan funkció, amikről igazából nem is tudtuk, hogy a felhasználó mit gondol, mennyire van rá szüksége.
Ezért kezdtünk el Sprintekben gondolkodni.
A Sprinteket User Story-k építik fel. Ezek olyan részfejlesztések, amelyek határideje napokban mérhető.
Ezek teszik ki az 1-2 hetes Sprinteket. Tehát egy fejlesztési ciklus elején tudjuk, hogy mit szeretnénk elérni, mi a célunk.

Az lesz a késztermék.

És vajon mit akar a felhasználó?

A Sprintek végén pár funkcióval mindig bővül a termék, halad a késztermék felé.
Az ilyen félkész terméket viszont már nyilvánossá, vagy legalább is korlátozottan nyilvánossá tehetünk.
Kiosztjuk különböző felhasználói csoportoknak, hogy teszteljék, és mondják el véleményüket.

A lényeg, hogy kis lépésekben haladunk a fejlesztésekkel, hogy elérjünk úgynevezett quick wineket.
Sokkal jobb érzés egy fejlesztőnek, ha foganatja van annak, amit csinál, és érzi, hogy gyakran le tud valamit tenni az asztalra.
Emellett előfordulhat, hogy másfél hónap után kiderül: a felhasználóknak igazából nincs már szükségük több funkcióra.
Megelégednének azzal, amit tesztelésre kaptak. Akkor a késztermék hirtelen előbbre ugrik, hiszen a felhasználói problémára megoldást nyújtottunk. Az igényeket kielégítjük, ráadásul a tervezett idő, energia és pénz megspórolásával.

A quick winekkel tehát motivációt tudunk teremteni a szervezeten belül, és nem mellesleg pénzt és energiát is megtakarítunk vele.
Nem vetjük bele magukat hatalmas projektekbe, és törekedünk egyből a legnagyobbra, mert fél úton elveszhet a motiváció, a pénz, és sok probléma lehet a késztermékkel, különösen ha a benne lévő funkciókat csak a végén teszteljük.
Hiszen minél több a funkció, annál több a hibalehetőség. Ezeket javítani sok plusz munka, ráadásul ez idő alatt a késztermék áll, hiszen hiányosan nem lehet piacra dobni, ha már sokat dolgoztak rajta és sokat várnak tőle.