[alg] Gebruiker vragen of inleven in gebruiker?

[Verwijderd]

Het is een algemeen software design principe dat het eigenlijk niet goed is als je je als programmeur gaat inleven in de gebruiker om tot een programma te komen voor een gebruiker, in plaats van dat je de gebruiker vraagt wat ie wil.

Maar is dit algemene principe wel zo waar in de praktijk? Weet de gebruiker wel altijd zelf wat ie wil, en is het niet veels te rottig en moeilijk om de gebruiker te gaan ondervragen? Kun je niet beter als designer/programmeur gewoon iets maken, en dan alleen de scherpe kantjes aan de hand van feedback er af schaven?

Ikzelf zou wel geneigd zijn om eerder de gebruiker te gaan vragen. Stel dat ik een vliegtuignavigatie systeem moet bouwen. Ik heb zelf 0.0% ervaring met vliegen. Alleen een echte piloot (algemeen domain expert) zal mij kunnen vertellen wat in zo'n systeem belangrijk is. Aan de andere kant merk ik toch dat er onder mensen veel scepsis is over het ondervragen van users.

Natuurlijk is de beste methode vaak een middenweg, maar toch ben ik benieuwd hoe er over dit topic zoals gedacht wordt door de collega's devvers hier.

[Verwijderd]

Negen van de tien contactpersonen waar ik mee in aanraking kom weten niet, zoals je zelf zegt, wat ze willen en het is daarom ook bijna een kunst geworden om de gebruiker uit te leggen wat er mogelijk is en hoe je dit het beste aan kunt pakken.

Ofwel, als ik mijn applicaties precies zo zou maken als de klanten mij vertellen, dan had ik nu een aardig hokkie-tokkie portfolio gehad. En dat, in tegenstelling tot de werkelijkheid. Nee, mijn mening is dat de klant toch echt niet weet wat hij of zij wil, en dat het aan de ontwerper/dev'er is om zich in te leven in het gebruik van zijn applicaties. Constant, bij elke regel code.

[NMe]

Zelfs het slimste programma kan nog niet fatsoenlijk bedenken wat het is wat een gebruiker nu precies wil, aangezien gebruikers gewoon niet logisch nadenken. Een programma dat niet doet wat een gebruiker wil, wordt al snel als slecht bestempeld. Dan mag je programma naar jouw mening nog zo goed zijn, het is voor de gebruiker onwerkbaar, en dus niet bruikbaar. Je graaft je eigen graf op die manier.

Ik herinner me een topic van een paar dagen geleden waar een programma de overeenkomt tussen twee woorden (voetbalclubs) moest kunnen zien. Een gebruiker kon Manchester United invullen, of Manheter Uniited, en dan zou het programma kunnen zien dat die bij elkaar hoorden. Voor zo'n kleine afstand: prima. Echter, de TS van dat topic wilde ook dat Man. Utd. herkend werd als Manchester United, en als je op zo'n manier gaat programmeren vind ik dat je teveel denkwerk bij de gebruiker uit handen neemt. Vult een gebruiker NEC in, dan denkt het programma dat het wel heel veel op NAC lijkt, en daarom maakt ie er maar NAC van.

Geef een gebruiker keuzes, dan voelt die zich tenminste ook nog een beetje belangrijk.

[Orphix]

Je moet de gebruikers van het systeem ook niet vragen het systeem voor jou te ontwerpen. Maar te vragen hoe ze ermee werken. Hoe ze ermee willen werken. Wat ze verwachten van het systeem, etc.

Zo heb ik weinig verstand van auto's, maar ik kan de ontwerpers bij Volkswagen wel vertellen dat ik op dit moment (als student) liever een goedkope en zuinige auto wil, dan een hele dure en snelle. Maar hoe ze dan dat moeten maken, bijvoorbeeld met welke materialen, wat voor soort motor, etc. Daar kan ik ze geen raad over geven, dat is ook hun domein. Uit veel onderzoeken is wel gebleken dat programmeurs over het algemeen slecht zijn in het raden wat de gebruiker verwacht. In dit voorbeeld zou VW dus slecht zijn in het raden wat studenten nu echt willen.

Hetzelfde is met software, vraag niet aan de gebruiker 'Moet ik de applicatie in twee of in drie lagen op bouwen'. Maar vraag 'Werkt het snel genoeg, en verwacht je veel groei de komende tijd?'.

Mijn ervaring is trouwens wel dat het veel 'efficienter' is om eerst een goede opzet te maken, dat praat en communiceert een stuk makkelijker. Je kan ze verschillende opties en alternatieven voorleggen. Dat brengt meer nuances met zich mee dan simpelweg een 'ja' of 'nee' op harde requirements, en is voor de gebruiker makkelijker in te schatten.

[leuk_he]

wel eens van DSDMgehoord? dat is een project methode waar je materie deskundigen op neemt in een project team, en via prototyping schaven die mee tijdens de bouw.

[Orphix]

Verwijderd schreef op dinsdag 14 juni 2005 @ 18:05:
Negen van de tien contactpersonen waar ik mee in aanraking kom weten niet, zoals je zelf zegt, wat ze willen en het is daarom ook bijna een kunst geworden om de gebruiker uit te leggen wat er mogelijk is en hoe je dit het beste aan kunt pakken.

Toch merk ik bij mezelf dat ik heel vaak vanuit het technische perspectief naar problemen kijk. Ik ga uit van wat ik kan, wat ik weet, wat op dit moment technisch mogelijk is. En redeneer dan naar een ontwerp toe.

Terwijl vaak de juist interessantere applicaties redeneren precies andersom. Wat wil ik, hoe moet het eruitzien, wat moet het kunnen. En dan kijken hoe je dat gaat realiseren, met welke technieken, frameworks, etc.

Ik denk dat voor een goed project je beide mensen nodig hebt. Iemand die continu nieuwe mogelijkheden en nieuwe ideeen oppert. En de programmeur die zegt dat zus en zo niet mogelijk is (na goed te hebben gekeken of dat ook echt zo is!)

[Soultaker]

Het hangt er een beetje vanaf hoe de expertise verdeeld is, denk ik. In jouw voorbeeld is het logisch dat de klant voor een groot deel bepaalt hoe de boel moet werken, maar als een willekeurig bedrijf bv. een webdesigner inhuurt, dan kan 'ie zich beter niet teveel met de lay-out of structuur bezighouden. Net zoals de piloot beter niet kan vertellen hoe het navigatiesysteem geprogrammeerd moet worden.

Het probleem ontstaat omdat klanten vinden dat ze koning zijn, wat op zich een mooi principe is, maar wat er ook wel toe leidt dat de klant beslissingen wil nemen over zaken waarin hijzelf niet voldoende expertise heeft. Het dilemma is dat je als ontwikkelaar dan zijn suggesties naast je neer kunt leggen wat achteraf misschien gezeik geeft omdat je niet naar de wensen van de klant hebt gewerkt, óf je kunt erin meegaan maar dat kan net zo goed gezeik geven als het eindproduct allerlei dingen blijkt te mankeren.

Vandaar dat overleg met klanten niet echt populair is bij ontwikkelaars; of je de klant nu wel of niet bij de ontwikkeling betrekt, kunt altijd de schuld krijgen aan het eind. De truc is dus om duidelijk af te spreken waar de klant precies om vraagt en wat je gaat doen, zodat je niet de schuld krijgt van fouten die je niet zelf gemaakt hebt, maar dat lost het dilemma niet helemaal op omdat een klant nog steeds ontevreden is als het eindproduct niet aan zijn verwachtingen voldoet, ook al is het naar zijn eigen specificaties gebouwd.

[alienfruit]

Je kan ook samen met je gebruiker het ISGVO model invullen, heb je al heel snel een duidelijk papier staan wat de gebruiker wil en hoe.

[Orphix]

alienfruit schreef op dinsdag 14 juni 2005 @ 19:15:
Je kan ook samen met je gebruiker het ISGVO model invullen, heb je al heel snel een duidelijk papier staan wat de gebruiker wil en hoe.

Wat is ISGVO ? Google vindt er bar weinig van.

[Verwijderd]

Je kijkt naar wat voor een data er in gaat, wat voor een data er uit komt en wat er met de data moet gebeuren. Je kijkt of het samenhangt met andere systemen. Vlieger gaat natuurlijk niet altijd op.

De klant weet als enige wat hij moet hebben, maar alles wat voor hem logisch is ziet ie makkelijk over het hoofd, terwijl dat wat voor hem logisch is meestal juist geautomatiseerd moet worden.

Je kunt eerst een prototype bouwen, al dan niet iets wat werkt, en dan op basis van de ontvangen feedback een final version bouwen.

Een Use Case diagram wat de functionele eisen in kaart brengt is gemaakt misschien ook nog wel aardig duidelijk voor een klant als er bij zit om te zeggen wat je bedoeld. Het is alleen de vraag of je de klant ook heel vaak kan spreken of niet. Als de klant er als het ware bij zit en veel tijd voor jou beschikbaar hebt, kun je ook extreme programing toepassen.

ISGVO zegt mij ook niets overigens. Als Orphix zegt dat google niks vindt, geloof ik em op z'n woord en bedel ik hierbij mee naar meer info . Ik heb verder overigens nog nauwelijks praktijkervaring, kben student .

[alienfruit]

Ja, ISGVO model/schema is iets van de opleiding die ik volg aan de HKU. Ik zal eens kijken of ik wat digitale informatie erover heb. ISGVO staat in ieder geval voor: inhoud, structuur, gedrag, verschijning , en omgeving. Het is te vergelijken met terminologie van Don Norman namelijk: visceral, behavioural, en reflective.

[ Voor 20% gewijzigd door alienfruit op 14-06-2005 20:52 ]

[D4Skunk]

Er bestaan tig methodes, maar ik werk als volgt :

• Definiëer eerst ALLE relevante begrippen/workflows/usergroepen die in voege zijn voor de implementatie. Dit is eigenlijk meer werk voor de klant dan voor de analist/programmeur. Zo blijkt het bv soms niet zo evident te zijn wat men precies verstaat onder bv een klant (is een persoon met meerdere contracten dezelfde klant ?). Dit is imho de lastigste fase qua gebruikersmotivatie etc...
• Brainstorm over de huidige tekortkomingen/toekomstige wensen & dromen...
• Bepaal adhv een prioriteitenmatrix met Implementatieduur/-kost/-nood/-... en het budget welke zaken geïmplementeerd zullen worden
• stel een gedetailleerde functiebeschrijving en planning op, waarbij je zaken die je moeilijk kan inschatten toch probeert in te schatten door ze verder op te delen. Vermeld evt. onzekerheden. Bouw milestones in.
• Maak een overeenkomst op met betalingsgaranties en laat je klant dit ondertekenen voor akkoord
• Begin a/d implementatie, handel volgens eer en geweten, en zorg dat je klant regelmatig op de hoogte gehouden wordt v/d evolutie. RFC's (request for change) moeten op een geijkte manier gebeuren, en dit met akkoord van het voltallige team.
• RC1 -> RC3 : geef de klant nog 3 kansen om de release candidates aan te laten passen. Zorg er wel voor dat de klant de financiële implicaties v/d aanpassingen begrijpt.
• bugfix/support : gebruik v/e online bugtracker is zeer aan te raden, zodat de klant kan zien of zijn probleem opgelost wordt.

Dit is in een notedop de methode die ik toepas. Elke stap die hier vermeld wordt is voor mij persoonlijk noodzakelijk gebleken om misverstanden/fincancïele gevolgen/teleurstellingen te vermijden. Zo heb ik al eens enkele duizenden euro's verloren bij een conversie van een MSAccess-applicatie, omdat ik het varkentje wel vlug even zou wassen : Geen duidelijk contract, onduidelijke terminologie & slechte gegevensstructuur , onduidelijkheid binnen het bedrijf wat er nu wel allemaal wel & niet moest => compleet verkeerde planning => Constant brielen, aanpassen en herbeginnen => Frustratie bij klant en mij => weigering volledige betaling wegens 'onvolledig programma' => Gratis & voor nix werken om toch de volledige som te ontvangen => lesje geleerd
Ik zeg nu niet dat je deze methode moet toepassen wanneer je bv iets maakt voor een vriend, maar wanneer er geld mee gemoeid is, hou ik me aan deze stappen...

Misschien interessant om weten : de voorbereiding duurt meestal evenlang als de implementatie.

Het voordeel van een geijkte en door iedereen goedgekeurde RFC, is dat een user moeite moet doen om wijzigingen aan te vragen, en er ook over moet nadenken, waardoor je het risico niet loopt dat je zaken moet implementeren die achteraf dan toch weer verdwijnen.

[Verwijderd]

D4Skunk schreef op woensdag 15 juni 2005 @ 00:22:
Er bestaan tig methodes, maar ik werk als volgt :
[handige lijst]

Ik merk dat er ook hier inderdaad wat twijfel over bestaat of je nou wel of niet dingen aan de user moet vragen. Wat ik ook veel als argument hoor is dat als je alles wat de user wil allemaal moet gaan opschrijven en uitwerken dat je dan wel x aantal jaar bezig bent voor je uberhaupt kunt beginnen. (programmeurs willen liefts meteen met programeren beginnen).

Als je dan toch kiest voor overleg met de gebruikers, hoe delen jullie deze wensen/requirements dan op?

Stel dat ik een systeem wil gaan maken die meerdere soorten totaal verschillende gebruikers heeft. Mijn eerste ingeving is dan om de requirements op te delen naar soort user. (bijvoorbeeld een bank systeem waar je klanten en bali medewerkers hebt, of een online banner systeem waar je adverteerders, webmasters en admins hebt, etc).

Daarnaast heb je dan weer een aantal sub-indelingen. Alleen, deze komen vaak meerdere keren terug bij de hoofd-indeling. In het geval van een banner systeem heb je natuurlijk de banner, maar die komt bij zowel de adverteerder als de webmaster voor. Het zou dan mischien handig zijn om de requirements in een DB of eventueel Excel sheet te zetten, zodat je makkelijk kunt sorteren op hoofd-indeling of sub-indeling.

Hoe houden jullie de requirements (wensen van de klant/gebruikers) bij?

[Soultaker]

Ik zet het vaak op papier voor mezelf, maar als referentie zorg ik ervoor dat ik van alles bevestiging per e-mail heb (dat is handig omdat dan beide partijen de info hebben en later niet kunnen ontkennen wat er afgesproken is; ik zorg iig dat ik geen mail kwijtraak.)

Bij overleg maak ik dus notities, luister ik wat de klant wil en doe ik zelf suggesties. Zo komen we dan uit op een omschrijving van wat de bedoeling is waar beide partijen zich in kunnen vinden. Naderhand stuur ik dan een mailtje met wat we precies hebben afgesproken en als de klant dat bevestigt ga ik aan de slag.

[H!GHGuY]

als iemand je vraagt een applicatie te bouwen, dan heeft ie meestal toch iets voor ogen...
je hebt op z'n minst een huidig programma of een huidige situatie waar zij vanaf willen.

als je ofwel de huidige applicatie eens ziet werken/de huidige situatie analyseert, dan kom je zeker met de gebruiker tot een to-do/prioriteiten/wensen-lijst waar je alvast iets mee kan.
bvb een piloot zal je mss zeggen: in het huidig navigatiesysteem zit de mogelijkheid om de route in te stellen te ver weg, is de display onoverzichtelijk, kan ik niet meer dan 5 waypoints instellen en zou ik graag ook interessante monumenten op zien.
of in een fabriek:
order komt binnen, iemand maakt manueel berekening welke goederen nodig zijn. die worden besteld en wanneer die binnen zijn zal diezelfde persoon binnen het bedrijf een fabricage-order uitschrijven. als dat order afgewerkt is, wordt de klant opgezocht in de fichebak, en wordt hem getelefoneerd dat zijn order klaar is. en ze willen ook altijd een minimumstock hebben die automatisch aangevuld wordt.

in beide gevallen kun je al tot een redelijke structuur komen van hoe je programma eruit ziet. in het eerste geval bekijk je het huidig navigatiesysteem en maak je een beter naar de wensen van de klant, in het 2de heb je alvast de structuur van werken die je kan automatiseren.

de klant moet 'wat'-vragen krijgen geen 'hoe'-vragen.

[Verwijderd]

HIGHGuY schreef op woensdag 15 juni 2005 @ 17:38:
de klant moet 'wat'-vragen krijgen geen 'hoe'-vragen.

Dat spreekt natuurlijk voorzich. "hoe" dingen zij zowieso voor de developper/designer.

Waar het mij voornamelijk opgaat is de vraag of je wel of niet de gebruiks (dus niet perse -de- klant) moet gaan ondervragen wat ze willen of niet. Ik merkte namelijk in de praktijk dat veel programmeurs daar toch erg sceptish tegenover staan. Ik doel dan met klem niet op de opdrachtgever zelf (die hoeft niet eens te bestaan in elke situatie), maar over de feitelijke mensen die jouw programma gaan gebruiken.

In het geval van een online banner systeem, heb je daar adverteerders en webmasters die gebruik maken van de applicatie. Ga je deze gebruikers daadwerkelijk opsporen en ondervragen/interviews afnemen of bouw je het systeem (je inlevend in deze gebruiker) en hoop dat ze daar tevreden mee zullen zijn / dat het aanslaat?

Ik zulke situatie heb je niet direct 1 opdrachtgever: je bouwt software en je hoopt dat je met die software klanten gaat krijgen.

[Antediluvian]

De gouden regel is toch: Don't give the client what he wants give him what he needs.

Wat ik merk is dat de klant meestal wel ongeveer weet wij hij allemaal wil maar meestal is dit een zeer ongestructureerde geheel. Meestal ga ik zoals soultaker te werk. Eerst een constructieve vergadering met de klant waarbij ik zo veel mogelijk de wensen en noden van de klant noteer. Daarna alles mooi in een gestructureerd geheel gieten en de klant dit laten bevestigen.

Wat ik ook belangerijk vind is dat de requirement duidelijk op voorhand vast staan. Er is niet zo frustreered als een klant die iedere 10 stappen met nieuwe informatie komt afdraven en nieuwe requirements opstelt. (En dan nog gaat klagen dat het project vertraging oploopt )

Extra features kunnen maar daarvoor moet er eerst een duidelijke omschijving van geformuleerd worden en de kant moet dan ook accoord gaan met een nieuw tijd schema.

Belangerijk is om de klant actief op de hoogte houden van de ontwikkelingen. Zo had ik een klant waarbij ik wekelijks een vergadering mee had. Zo'n (gevoel van) betrokkenheid kunnen de meeste klanten echt wel preciëren. Je komt er dan ook vrij stel achter als er iets fout gaat. Ook eventuele problemen waardoor het project vertragingen oploopt weet de klant onmiddelijk (ook het waarom wordt hem meegedeeld). Hierdoor hebben ze meestal wel wat meer begrip voor vertragingen of uitgestelde features.

[ Voor 32% gewijzigd door Antediluvian op 15-06-2005 18:35 ]

[imp4ct]

Zeer leuke discussie lijkt me dit. Wat ik meestal doe is ook eerst gaan vragen aan een klant of gebruiker wat hij precies wilt, hoe hij het ziet. Daarna ga ik met mijn kennis even er wat structuur in gooien en mijn klant uitleggen of dit allemaal kan en zo niet stel ik andere oplossingen voor.

'k Vond de zin hierboven zeer goed, 't grootste doel van je applicatie is toch dat de klant het kan gaan gebruiken voor wat hij het nodig heeft en dat het programma werkt voor wat hij het nodig heeft. Als een klant geen printfunctie nodig heeft in heel zijn programma, dan moet je als programmeur hier ook geen toepassing op maken. 't Is wel een lauter voorbeeld, maar dit werd dus vaak gezegd bij ons op school toen ik nog Informatica deed, vele software huizen luisteren gewoonweg niet naar hun gebruikers en maken gewoon leuk een programma met enorm veel mogelijkheden, allemaal goed en wel, maar als je gebruiker ze niet nodig heeft vind ik dit persoonlijk geen goed programma.

Ook zoals hierboven gezegd, overleg met je gebruiker, in tussentijd al wat laten zien wat er afgewerkt is, is volgens mij een zeer goed methode om latere fouten al uit het programma te hebben, soms heeft dit wel als nadeel dat je tijdens je ontwikkeling ineens nog dingen moet gaan veranderen, maar het vraagt denk ik nog meer werk als je dingen moet gaan veranderen als je een volledig afgewerkt programma presenteert en dan ineens de klachten te horen krijgt.

Wat ik persoonlijk ook nog vaak doe is voor ik een website - programma release laat ik er altijd wat test-users op los, zodat buggs hier en daar nog gevonden worden, op die manier bespaar je, je ook waarschijnlijk nog tijd en hoe minder bugss of fouten hoe meer tevreden je klant is eh.
Om fouten te vermijden ben ik wel altijd van het princiepe, probeer je gebruiker altijd 1 stap voor te blijven, zodat hij de mogelijkheid niet krijgt om fouten te maken of errors uit te lokken.

vb. Je hebt bijvoorbeeld een scrollsysteem op een website van foto's. Nu wat soms vele doen is een
"next" - "previous" gebruiken, allemaal goed maar kom je aan de laatste foto dan zou de "next" button moeten wegvallen vind ik. Nu merk je toch vaak dat dit niet gebeurd en de next knop er nog wel staat maar geen functie heeft, oki hij werkt niet, maar eigenlijk staat hij daar uitermate overbodig.

Ziezo, een beetje mijn commentaar op deze topic.

[gvdh81]

Ik heb niet het hele draadje gelezen maar wij krijgen op de Fontys in Eindhoven les in DSDM en moeten ons toevallig (bij een vandaag afgerond project) ook inleven in de gebruiker. Je krijgt dan iets van;
- Huidige situatie
- Gewenste situatie
- Systeemconcept

En in je PVA is het misschien wel belangrijker om aan te geven wat je NIET maakt dan datgene wat je wel maakt. Maar goed, zo is het ons dus verteld.

[Verwijderd]

Ik zit een beetje in een afwijkende positie dan de meeste ontwikkelaars: ik ontwikkel software voor een branche waar ik zelf 12 jaar in heb gewerkt.
Inleven in de gebruiker gaat dan vrijwel automatisch, en wanneer ik in gesprek ga met de gebruiker kan ik meestal goede praktijk-argumenten geven waarom iets op een andere manier beter kan. Zeg maar materie-deskundige en ontwikkelaar in 1.

Het enige nadeel is, dat ik in brainstorm sessies nog wel 's enthousiast kan worden over bepaalde ideeen, omdat ik weet dat die in de praktijk erg handig kunnen zijn. En dan let ik niet altijd op het tijds- en kostenplaatje... Al word je daarin door schade en schande wel een stuk wijzer.

[mdcroon]

Naar mijn idee moet je onderscheid maken tussen de analist/ontwerper en de programmeur. De analist/ontwerper fungeert als een soort intermediair tussen klant en programmeur.

De analist is er verantwoordelijk voor om uiteindelijk tot een ontwerp te komen met daarin de beschrijving van de behoeften van een klant. Om die behoeften boven tafel te krijgen is het zeer wenselijk dat de analist kennis heeft van de materie waarin het probleem gebied van de klant ligt. Hoe weet je anders of je begrijpt wat de klant wil en hoe koppel je terug aan de klant of de klant wel begrijpt wat hij wil? Het komt maar al te vaak voor dat de klant zelf eigenlijk ook het niet precies weet. Alleen door overleg kom je hier achter. Het is dan ook zeer belangrijk om duidelijk te maken aan de klant wat er uiteindelijk opgeleverd gaat worden om achteraf geen gedoe te krijgen als: "Maar zo had ik het niet bedoeld." of "Had ik hier wel om gevraagd?".

Nadat de analist het ontwerp heeft gemaakt gaat de programmeur aan de slag. Als het ontwerp goed beschreven is, is het voor de programmeur niet nodig om kennis van de materie te hebben. Indien nodig kan de analist nog inspringen.

Om nog even terug te komen op de vraag van de starter van deze topic. Uiteindelijk moet de gebruiker aangeven wat die wil. Dit kun jij als programmeur niet voor de gebruiker bepalen. Wat je wel kunt en volgens mij ook moet doen is een adviserende rol hierin spelen. Is het wel mogelijk wat de gebruiker wil (technische oplossing)? Zijn de verwachtingen bij de gebruiker wel correct (interactief verwerken van grote volumes waarbij de gebruiker direct verder wil werken)?

[H!GHGuY]

blijkbaar was m'n vorige antwoord beetje te off-topic, dus dat gaan we even veranderen:
ik denk dat als je de mogelijkheid krijgt, je dit zeker moet doen als de gebruiker "bereikbaar" is. dus bij een banner-systeem gaat dit niet zo, maar dan maak je enkele previews (niet geimplementeerd) en die leg je dan even voor aan familie-vrienden-collega's.
bovendien denk ik dat een gezonde mix van beide wel handig is: als jij met een lumineus ID komt, is er geen reden om dit niet te implementeren, of op z'n minst voor te stellen aan de klant.

ik denk dat waar het op neer komt gezond overleg is, met creatieve inspiratie van beide zijden.

[Verwijderd]

Soultaker schreef op woensdag 15 juni 2005 @ 15:34:
Ik zet het vaak op papier voor mezelf, maar als referentie zorg ik ervoor dat ik van alles bevestiging per e-mail heb (dat is handig omdat dan beide partijen de info hebben en later niet kunnen ontkennen wat er afgesproken is; ik zorg iig dat ik geen mail kwijtraak.)

Je weet dat je juridisch geen poot hebt om op te staan?

Sometimes you can't beat good old fashioned paper..

[mdcroon]

HIGHGuY schreef op donderdag 16 juni 2005 @ 10:00:
bovendien denk ik dat een gezonde mix van beide wel handig is: als jij met een lumineus ID komt, is er geen reden om dit niet te implementeren, of op z'n minst voor te stellen aan de klant.

Geen reden om te implementeren? Er zijn een boel redenen om een eigen idee niet te implementeren. Zit de klant hier wel op te wachten? Tijd? Geld? Als wij bij ons op het werk software ontwikkelen voor een klant dan wordt er alleen gebouwd wat met de klant is afgesproken. Daar betaalt de klant uiteindelijk ook voor. Je kunt inderdaad bij een nieuw idee wel de klant raadplegen maar zeker niet direct implementeren. Dit nieuwe idee moet dan als een change request worden behandeld en de nodige stappen doorlopen voordat het daadwerkelijk geimplementeerd gaat worden.

Maar misschien zie ik het verkeerd en bedoel je gewoon iets anders.

[farlane]

mdcroon schreef op donderdag 16 juni 2005 @ 08:12:
Naar mijn idee moet je onderscheid maken tussen de analist/ontwerper en de programmeur. De analist/ontwerper fungeert als een soort intermediair tussen klant en programmeur.

Bij ons (kleine) bedrijf wordt daar echt geen verschil in gemaakt. De analyst is programmeur is debugger is zijn eigen projectmanager.

[mdcroon]

farlane schreef op donderdag 16 juni 2005 @ 11:28:
[...]


Bij ons (kleine) bedrijf wordt daar echt geen verschil in gemaakt. De analyst is programmeur is debugger is zijn eigen projectmanager.

Is bij ons (ook kleine) bedrijf ook zo. In dit geval is dus de programmeur ook analist en heeft rechtstreeks contact met de klant. Neemt niet weg dat nog steeds geldt dat het wenselijk is dat in dit geval de programmeur materie kennis heeft en in samenspraak met de klant bepaald wat er gebouwd gaat worden.

[farlane]

mdcroon schreef op donderdag 16 juni 2005 @ 11:44:
Neemt niet weg dat nog steeds geldt dat het wenselijk is dat in dit geval de programmeur materie kennis heeft en in samenspraak met de klant bepaald wat er gebouwd gaat worden.

'Tuurlijk, dat is denk ik een van de charmes van het werken in een klein bedrijf: je bent van voor tot achter bezig met het project. Maar het heeft dan geen zin om te praten over 'de analist' of 'de programmeur' want die opdeling is er gewoonweg niet.

[D4Skunk]

Verwijderd schreef op woensdag 15 juni 2005 @ 14:32:
[...]


Hoe houden jullie de requirements (wensen van de klant/gebruikers) bij?

Op deze manier
gelieve niet aan te melden, want ik geef geen toegangsrechten

Antediluvian schreef op woensdag 15 juni 2005 @ 18:28:
De gouden regel is toch: Don't give the client what he wants give him what he needs.
[...]

Iemand met ervaring blijkbaar Voor zover ik kan zien volg je in grote lijnen dezelfde methode als mij.

Als je voor eigen rekening werkt, zorg dan altijd dat je een duidelijke overeenkomst hebt, waarin vermeld staat wat wel en niet in de prijs inbegrepen is.
En vooral het KISS-principe gebruiken (één v/d punten waarop ik zelf nog wel eens zondig)
kiss = Keep It Simple and Stupid

[Orphix]

D4Skunk schreef op donderdag 16 juni 2005 @ 13:13:
kiss = Keep It Simple and Stupid

Volgens mij is het "Keep It Simple, Stupid!" of maak je echt stomme software

[imp4ct]

Orphix schreef op donderdag 16 juni 2005 @ 16:52:
[...]

Volgens mij is het "Keep It Simple, Stupid!" of maak je echt stomme software

Die lijkt mij ook meer logisch héhé.

[Verwijderd]

D4Skunk schreef op donderdag 16 juni 2005 @ 13:13:
[...]
Op deze manier
gelieve niet aan te melden, want ik geef geen toegangsrechten

Ik krijg alleen een inlog scherm te zien. Doel je nu alleen op het feit dat je je requirements via een wiki bijhoudt?

Wat ik eigenlijk bedoelde is hoe je je requirements opdeeld. Ik kan wel een lijst van 200 of meer requirements in een lange lijst gaan zetten, maar dan wordt het er ook niet duidelijker op. Je zou mischien aan elke requirement een labeltje kunnen hangen, met dingen als "viewpoint (rol van de gebruiker die baat heeft bij de requirement)". "onderdeel", en "prioriteit".

Heb jij een DB achter je requirements hangen zodat je dingen kunt vragen als "alle requirements die met onderdeel A te maken hebben" ? Hoe doen de andere dit? Gewoon in een latex document neerzetten, gespecialiseerd requirements management systeem, of wat anders?

En vooral het KISS-principe gebruiken (één v/d punten waarop ik zelf nog wel eens zondig)
kiss = Keep It Simple and Stupid

Beetje offtopic:

Let wel op dat KISS geen excuus wordt voor "quick and dirty". Maar al te vaak hoor je mensen zich verschuilen achter KISS omdat ze eigenlijk te weinig verstand hebben om het beter te doen. In de design wereld past Apple ook KISS op zijn designs toe en dat werkt super, heel eenvoudig allemaal maar toch super mooi. Trust doet ook aan KISS maar dan uit overwegingen van goedkoopheid. Het resultaat is er niet echt naar.

KISS goed toegepast kost juist meer moeite. Zie het als een wiskundige formule die je moet herleiden. De originele formule is lang en romelig. Om hem mooi en simpel te krijgen ben je erg lang bezig.

Einstein zij het ook al: "Dingen moeten zo simpel mogelijk zijn, MAAR NIET SIMPELDER". Zie ook http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment

[joint_me]

Vergeet MOSCOW niet

Must Haves
O
Should Haves
Could Haves
O
Wanne Haves (ook wel als gezien als Won't haves)

Deze lijst kun je op meerdere manieren gebruiken:

1. Bekijken van welke functionaliteit je echt nodig heb en welke functionaliteit je over droomt, maar waarschijnlijk niet logisch is om te implementeren.
2. Je kunt ook zeggen deze functies maak ik makkelijk toegangkelijk en hoe lager ze op de lijst voorkomen hoe verder weg je ze stopt in een aplicatie (expert features)

Maar user onderzoek is natuurlijk nooit weg, je kunt jezelf nog zo goed in anderen verplaatsen, maar uiteindelijk is het de User die het moet gebruiken. Ideaal heb je meerdere user onderzoeken:

1. Bij de ontwerpfase, useronderzoek kan plaatsvinden door het gebruik van papier methode, geschetste/ photoshop schermen
2. Stukje verder, de demo de user kan dingen aangeven naar de hand van een smerige demo, functionaliteit hoeft niet aanwezig te zijn, faken mag ook.
3. Eindfase, het echte product testen, veranderen testen, etc. tot op zekere hoogte.

Uit te breiden of in te korten naar gelang, tijd, geld, belang, etc.

FF snel een visie van mijn kant

[SPee]

Een van de simpelste en makkelijkste manier om je te houden aan de wensen van de klant is doro middel van een Use Case.
Soms lijkt het een stom iets dat alleen maar logische dingen heeft, maar veelal is het toch bruikbaar.
1. Je weet wat de gebruiker wil
2. De gebruiker weet wat hij krijgt
3. Je kunt hiermee je applicatie controleren of het nog daaraan voldoet

En als een gebruiker iets anders wil => change request! => wijziging met impact op het project.

Je moet de gebruiker inspraak geven op de dingen waar hij op mag/moet inspreken. Op andere dingen moet je hem er gewoon buiten laten. Ook moet je niet elke gebruikers input laten geven, maar een vaste panel van personen in diversiteit die er gebruik van gaan maken.

[D4Skunk]

Orphix schreef op donderdag 16 juni 2005 @ 16:52:
[...]
Volgens mij is het "Keep It Simple, Stupid!" of maak je echt stomme software

Oops !!!

Verwijderd schreef op donderdag 16 juni 2005 @ 17:45:
[...]
Ik krijg alleen een inlog scherm te zien. Doel je nu alleen op het feit dat je je requirements via een wiki bijhoudt?

Ja

Wat ik eigenlijk bedoelde is hoe je je requirements opdeeld. Ik kan wel een lijst van 200 of meer requirements in een lange lijst gaan zetten, maar dan wordt het er ook niet duidelijker op. Je zou mischien aan elke requirement een labeltje kunnen hangen, met dingen als "viewpoint (rol van de gebruiker die baat heeft bij de requirement)". "onderdeel", en "prioriteit".

Dat is net het voordeel aan een wiki : de flexibiliteit. Je begint dus vanuit een ongestructureerde gedachtengang, en langzaam maar zeker moet je evolueren naar een gestructureerde beschrijving.
Naast een volledig model van je app, heb je dan ook een syllabus waarin de werking van het bedrijf beschreven wordt.

Heb jij een DB achter je requirements hangen zodat je dingen kunt vragen als "alle requirements die met onderdeel A te maken hebben" ? Hoe doen de andere dit? Gewoon in een latex document neerzetten, gespecialiseerd requirements management systeem, of wat anders?

Hoe anderen dit doen weet ik niet, maar ikzelf gebruik een heel eenvoudige, op text-files gebaseerde wiki. Het is dan ook supereenvoudig om er gegevens uit te halen voor mij; ik baseer mij daarvoor op een bepaalde standaard die we afspreken :
- Alle requirements worden gelinkt vanuit de pagina AppRequirements
- Alle requirements hebben X secties met vaste titels
- ...

[...]
Beetje offtopic:

Let wel op dat KISS geen excuus wordt voor "quick and dirty". Maar al te vaak hoor je mensen zich verschuilen achter KISS omdat ze eigenlijk te weinig verstand hebben om het beter te doen. In de design wereld past Apple ook KISS op zijn designs toe en dat werkt super, heel eenvoudig allemaal maar toch super mooi. Trust doet ook aan KISS maar dan uit overwegingen van goedkoopheid. Het resultaat is er niet echt naar.
KISS goed toegepast kost juist meer moeite. Zie het als een wiskundige formule die je moet herleiden. De originele formule is lang en romelig. Om hem mooi en simpel te krijgen ben je erg lang bezig.
Einstein zij het ook al: "Dingen moeten zo simpel mogelijk zijn, MAAR NIET SIMPELDER". Zie ook http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment

Wat ik hiermee bedoelde wordt dus anders geïnterpreteerd imho.
Met KISS bedoelde ik dat het niet nodig is om tig lagen te schrijven voor een appje dat enkel wat contactgegevens bijhoudt. Kies voor de beste aanpak ipv de mooiste, want voor de klant maakt het uiteindelijk toch geen verschil.

joint_me schreef op donderdag 16 juni 2005 @ 18:00:
Vergeet MOSCOW niet

Deze lijst is misschien eenvoudig te implementeren voor kleine projecten, maar voor grote projecten heb je hiervoor een extra stap nodig. Zoals bij alle problemen : als het te groot wordt, deel het dan op in kleinere delen.
De aanpak die ik hiervoor met success gebruik, is een soort van matrix : aan elke wens worden punten gegeven op criteria :
- Tijdsduur
- Budget
- Moeilijkheidsgraad
- Kan het project slagen zonder dit punt
- ...
Vervolgens worden gewichten toegekend aan de criteria.
De prioriteit van een wens is dan de som van de punten* hun respectievelijke criteria.
Et voila, MOSCOW est la !!!

offtopic:
En als je dan nog niet tot een voorstel komt, dan heb ik nog maar één antwoord voor je : 42

[Gé Brander]

farlane schreef op donderdag 16 juni 2005 @ 12:20:
[...]
'Tuurlijk, dat is denk ik een van de charmes van het werken in een klein bedrijf: je bent van voor tot achter bezig met het project. Maar het heeft dan geen zin om te praten over 'de analist' of 'de programmeur' want die opdeling is er gewoonweg niet.

Die opdeling is er niet in mensen nee, maar wel in rollen 'gespeeld' door mensen.

Dan heb je als ontwikkelaar die rol ook. Dan moet je ook wel kennis van zaken hebben en dus de juiste vragen en methoden gebruiken om tot een ontwerp te komen.

Helaas zie je vaak dat die rol niet alleen in mens er niet is, maar gewoon helemaal overgeslagen wordt. Daar gaat het juist zo vaak fout door.

offtopic:
Hoeveel ontwikkelaars/analisten/ontwerpers houden in hun ontwerp standaard rekening met security? Ik merk dat de meeste programmeurs er bar weinig aan doen. De meeste gekochte applicaties die ik tegenkom en een database nodig hebben, daar is over het algemeen 1 user voor nodig met alle rechten. Dat hoeft niet, en dat zou je ook niet moeten willen. Waar komt deze rare eigenschap nou toch vandaan? Of moet ik hier een nieuw topic voor openen?

[Antediluvian]

c70070540 schreef op donderdag 16 juni 2005 @ 23:24:
[...]

offtopic:
Hoeveel ontwikkelaars/analisten/ontwerpers houden in hun ontwerp standaard rekening met security? Ik merk dat de meeste programmeurs er bar weinig aan doen. De meeste gekochte applicaties die ik tegenkom en een database nodig hebben, daar is over het algemeen 1 user voor nodig met alle rechten. Dat hoeft niet, en dat zou je ook niet moeten willen. Waar komt deze rare eigenschap nou toch vandaan? Of moet ik hier een nieuw topic voor openen?

Misschien geen slecht idee om hierover een nieuwe thread te starten. Het komt er eigelijk op neer dat er tussen de app en de database een soort van vertrouwen relatie bestaad waarbij de app dus volledige rechten heeft tot de database maar er ook zelf de nodige security implementeerd om er voor te zorgen dat users geen ongeauthoriseerde toegang hebben tot die gegevens.

Dit model word voornamelijk gebruikt wegens zijn eenvoud. Je hoeft namelijk geen user rechten te beheren op database niveau. Het systeem (de app) heeft meestal meer rechten nodig dan de user, enz enz.

[H!GHGuY]

mdcroon schreef op donderdag 16 juni 2005 @ 10:25:
[...]


Geen reden om te implementeren? Er zijn een boel redenen om een eigen idee niet te implementeren. Zit de klant hier wel op te wachten? Tijd? Geld? Als wij bij ons op het werk software ontwikkelen voor een klant dan wordt er alleen gebouwd wat met de klant is afgesproken. Daar betaalt de klant uiteindelijk ook voor. Je kunt inderdaad bij een nieuw idee wel de klant raadplegen maar zeker niet direct implementeren. Dit nieuwe idee moet dan als een change request worden behandeld en de nodige stappen doorlopen voordat het daadwerkelijk geimplementeerd gaat worden.

Maar misschien zie ik het verkeerd en bedoel je gewoon iets anders.

wat ik bedoel is mss niet genuanceerd genoeg, en jouw reactie legt de eigenlijk nuance (waarmee je mij het typwerk spaart ): kostenplaatje, change request, etc...
maar sommige dingen zijn zowat gratis, geen change request waard, lumineus dat je geen 2 keer moet twijfelen...