Aanpak maken van website plan

[perry]

Goed,

 

Nou ik heb dus een prijs gewonnen waarbij en professionele website bouwer een website voor me gaat bouwen. Ik hoef niet naar budget te kijken maar moet nou ook weer te gek worden. Denk aan maximaal 10.000 euro.

 

Eerdaags heb ik eerste gesprekken om tot een plan te komen, maar wat ik eigenlijk zou willen is dat we tijd voor het denken en maken van een plan vooraf doe en de tijd in ga zetten voor het werkeleijk programmeer en design werk. Zou toch zonde zijn als ik alleen 4 5 dfagen kwijt teutebellen over het dan moet gaan worden.

 

Zou graag zelf tot een dokument willen komen die je feitelijk zo aan een groepje techneuten en designers geet en zegt, oké lees dit en maak wat moois.

 

Nou kan ik wel voorstellen welke onderwerpen allemaal in het dokument moeten komen, maar vroeg me af:

 

- Welke boeken ik misschien ook moeten lezen om tot zo''n plan te komen?

- Bestaan er misschien al wat checklists

- Misschien iemand voorbeeld van zo'n plan.

 

Is dat eigenlijk wel mogelijk om het allemaal van te voren uit te kauwen, of moet je gewoon gaan bouwen. Lijkt me niet.

 

Alle input is welkom. Hoe kom je tot een goed websiteplan?

 

Perry

[Erik Duindam]

ik zal nu praten uit eigen ervaring als programmeur.

 

soms komen klanten met "ik wil graag een webshop". voor de rest noemen ze een paar kleuren, en that's it. dan kost het mij heel veel tijd om er enigszins iets zinnigs uit te halen.

 

er zijn echter ook klanten die met een word document van 3 pagina's komen, met elk detail uitwerkt (vaak nog met screenshots en al). dit werkt voor mij heel goed.

 

ik denk niet dat er echt een goede opbouw is voor zoiets, je kunt het best alles netjes in een soort hoofdstukjes verdelen, bijvoorbeeld per 'systeem' of 'pagina' (voor zover je er verstand van hebt natuurlijk).

 

als je al echt iets in je hoofd heb en het op papier gaat zetten, let ook op de details. een programmeur heeft de grote lijnen al snel door, maar details moeten van de klant af komen. dit kan ook achteraf, maar dat kost meestal veel meer tijd.

 

voorbeeld van detail:

 

stel, je wil een webshop, met een mandje en een registreersysteem en dergelijke. wees dan specifiek over welke formulier-velden er ingevuld moeten worden. wil je Naam, Adres, Plaats, of wil je bijvoorbeeld nog veel meer? zo kan de programmeur van te voren een goede database in elkaar zetten, zonder dat het steeds helemaal gewijzigd dient te worden.

 

ik vind het zelf altijd naar als mensen niet weten wat ze precies willen.

zo moest ik een kunstgalerie systeem maken (behoorlijk uitgebreid). dus ik wilde graag weten wat ze per kunstwerk allemaal wilden invullen (naam kunstwerk, naam kunstenaar, datum?, grootte?, etc). het duurde heel lang voordat ze dit helemaal uitgestippeld hadden.

 

probeer dus zo specifiek mogelijk te zijn..

[Merkava]

Misschien een idee om een groei document te maken.

een document waar iedereen zinnige opmerkingen in kan plaatsen, uiteraard wel met een redacteur op de achtergrond.

 

Vanavond wil ik wel een aanvang maken met zo'n document, ik heb een jaar of twee geleden als office manager c.q. projectmanager bij een web bedrijfje gewerkt.

Ik was daar de schakel tussen klant en programmeurs.

 

Misschien is er een mogelijkheid om een dergelijk document te plaatsen zodat iedereen het makkelijk kan editten, ik stel voor dat het wel onder het copyright van HL valt, maar wel toegangkelijk voor iedereen.

 

[perry]

Misschien een idee om een groei document te maken.

een document waar iedereen zinnige opmerkingen in kan plaatsen, uiteraard wel met een redacteur op de achtergrond.

 

Vanavond wil ik wel een aanvang maken met zo'n document, ik heb een jaar of twee geleden als office manager c.q. projectmanager bij een web bedrijfje gewerkt.

Ik was daar de schakel tussen klant en programmeurs.

 

Misschien is er een mogelijkheid om een dergelijk document te plaatsen zodat iedereen het makkelijk kan editten, ik stel voor dat het wel onder het copyright van HL valt, maar wel toega

 

ngkelijk voor iedereen.

 

 

Wil niet blijven doorzagen over die online workshops, maar in zo'n workshop, kan ik ook een boek aanmaken die je gezamenlijk kunt vullen!

[Merkava]

Doen !

[Edo van Santen]

let op dat je niet teveel door elkaar heen gooit.

 

een globale aanpak die al decennia werkt, is de volgende:

 

fase1: commerciele doelstellingen (wat zou je vanuit de business of commercie allemaal willen);

fase 2: conceptueel ontwerp (gegeven fase 1, wat is daar dan op conceptueel niveau allemaal voor nodig);

fase 3: functioneel ontwerp (hier definieer je je proces en datastromen en de techniek erachter);

fase 4: technologiekeuze (welke technologie is nodig, welke database,m welke programmeertaal, etc.');

fase 5: technisch ontwerp (hoe gaan we het dan doen);

fase 6: bouw en systeemtest;

fase 7: eerste oplevering en pilottesten;

fase 8: acceptatietest;

fase 9: aanpassingen n.a.v. acceptatietest;

fase 10: implementatie

fase 11: live gaan!

fase 12: onderhoudsfase.

 

Uit ervaring sprekend, ik kom vaak tegen dat men stoer zegt, overdreven, we beginnen gewoon. doe dat niet, het is echt niet zo dat de eerste fasen weken hoeven te kosten, maar iedere euro die je in de eerste fasen spendeert, spaar je later in veelvoud uit.

 

succes.

 

 

[perry]

Doen !

 

Oké ik zal morgene eens structuur brengen in die online workshops:-)

 

Maken we er ook één waarin een websiteplan gemaakt kan worden.

 

Nog het een en ander uitproberen met die workshops, excuses ook voor de e-mails die opeens doorkwamen....

 

Perry

 

[willemj]

Ik sluit me aan bij VC z'n overzicht van stappen. Je krijgt het nooit in één keer goed maar goed nadenken vooraf levert wel besparing op. Er is wel overlap in fase 3 tot 5 dus begin met overleg als je start met fase 3.

 

Zou graag zelf tot een dokument willen komen die je feitelijk zo aan een groepje techneuten en designers geet en zegt, oké lees dit en maak wat moois.

 

Blijf dromen :) Je zult nooit in één keer, zeker zonder overleg met de techneut, tot zo'n document komen. Vier of vijf dagen bellen is weer het andere uiterste maar je zult zeker wijzigingen krijgen zowel in functioneel en technisch ontwerp.

 

Probeer je conceptioneel en functioneel ontwerp zo goed mogelijk te krijgen en laat de techniek even voor wat het is. Een beetje techneut kan daar prima mee overweg en een ontwerp maken met op en aanmerkingen. Internet als medium voor applicaties is niet ideaal (zeker shared hosting niet) dus verwacht in deze fase veel communicatie.

 

Probeer ook zoveel mogelijk uitzonderingsituaties en fout situaties op te nemen in je ontwerp. Een veldje meer of minder in je database heeft niet zoveel effect (@phperik: zolang de normaalvorm van je database niet wijzigt kan dat toch niet zoveel consequenties hebben??) maar achteraf bedenken dat een bezoeker later door moeten kunnen gaan met het invullen van een formulier kan best grote impact hebben als dat niet vanaf het begin duidelijk was.

 

Stappenplannen vind ik persoonlijk ook altijd wel lekker werken. In jouw geval zoiets als:

 

- klant komt op m'n site en wil bus. plan starten

- klant vult formulier in

- ik ontvang e-mail met het verzoek van klant

- ik bel klant

- als akkoord maak ik nieuwe workshop aan en mail klant

 

Je gaat zo verder met een plan voor het proces van het begeleiden en sluiten van een workshop etc. Daarna ga je alle plannen nog een keer doorlopen en kijk je per stap of die een relatie hebben met andere plannen of stappen daarvan. Zo kom je er bijvoorbeeld achter dat mensen al dan niet mailtjes willen ontvangen bij nieuwe reacties op het forum en bedenk je je dat je dat graag bij bovenstaande stap 'klant vult formulier in' wilt hebben om te voorkomen dat mensen ineens verrast worden door een berg e-mail. Wanneer je dit voor je hele site doet heb je een ontzettend mooi document voor een programmeur (en met een beetje mazzel lage prijzen :))

 

Je in de techniek verdiepen zou ik maar in beperkte mate doen. Daar is een programmeur voor. Een beetje weten hoe of wat is leuk maar een gesprek over 'multipart mime documenten om server push voor elkaar te krijgen' zal te hoog gegrepen blijven, hoewel het een interessante techniek is. Het kan zelfs negatief werken omdat je technische dingen voorstelt waar je de bij-effecten/beperkingen niet van kent en dus een discussie moet voeren om er op uit te komen dat je technische suggestie niet werkt. Technieken die je op een andere site hebt gezien noemen werkt wel weer. Ben al een aantal keer geïnspireerd door suggesties van klanten.

[Edo van Santen]

 

Probeer je conceptioneel en functioneel ontwerp zo goed mogelijk te krijgen en laat de techniek even voor wat het is. Een beetje techneut kan daar prima mee overweg en een ontwerp maken met op en aanmerkingen. Internet als medium voor applicaties is niet ideaal (zeker shared hosting niet) dus verwacht in deze fase veel communicatie.

. . .

 

Stappenplannen vind ik persoonlijk ook altijd wel lekker werken. In jouw geval zoiets als:

 

- klant komt op m'n site en wil bus. plan starten

- klant vult formulier in

- ik ontvang e-mail met het verzoek van klant

- ik bel klant

- als akkoord maak ik nieuwe workshop aan en mail klant

. . .

 

Eens. Dank.

 

je stappenplan (wellicht op hoog niveau) is iets dat je in 'mijn' fase 2 Conceptueel ontwerp opstelt.

[Anders Floor]

Goede opmerkingen bij elkaar.

 

Het is als opdrachtgever belangrijk om te beseffen dat je het laten ontwikkelen van een website, kunt vergelijken met het bouwen van een huis.

 

Als je zomaar begint met een huis, en er later achterkomt dat je, bijvoorbeeld,

 

- een toilet op de 2e verdieping wilt hebben

- een open doorgang wilt hebben tussen keuken en woonkamer

- een extra verdieping er boven op wilt hebben

 

.. dan is het enorm tijd- en kostenbesparend als daar bij de bouw rekening mee is gehouden. Dat hoeft bij die bouw nauwelijks meerwerk te betekenen (een paar heipalen extra, een leiding even langer doortrekken, een muurtje hier in plaats van daar), maar het levert je later enorm veel gemak op.

 

Ook bij een website is het zo. Bij de ontwikkeling wordt een technisch fundament gelegd, en als het meezit kunnen toekomstige wensen daar eenvoudig mee geïntegreerd worden. Als geen rekening is gehouden met eventuele wensen, zouden die el eens kunnen leiden tot zeer veel rompslomp en frustratie.

 

Zorg dus dat je rekening houdt met toekomstige wensen, ook al ben je nu bezig met een relatief eenvoudige site. Hiervoor heb je geen technische kennis nodig: geef gewoon aan dat eventueel, ooit, zus en zo wellicht ontwikkeld zou moeten worden. Een beetje programmeur kan daar al genoeg mee om je in de toekomst een stuk rustiger te laten slapen.

[Arnout Mostert]

Het is misschien wat beperkt maar een klein hulpje bij het nadenken over wat je zelf nou eigenlijk wil van de site zet ik hieronder neer. Ik geef o.a. les op een MBO opleiding en voordat leerlingen van me aan het ontwerpen gaan laat ik ze deze vragen beantwoorden:

 

Website ontwikkelingsfase hulp.

Om tot een effectieve website te komen moet in de eerste plaats vastgesteld worden wat de doelstelling is die je wilt bereiken. Tot welke doelgroep ga je je richten? Wat wordt de inhoud? Met behulp van onderstaande vragen kun je uiteindelijk komen tot de vormkeuze en uitwerking van een concept of uitvoering van een ontwerp.

 

Wat is de doelstelling van de website?   

 

Wie is de doelgroep? (Leeftijd, geslacht, sociale klasse, opleidingsniveau, beroepsgroep, persoonlijke levensstijl/visie, interesses, meningen?)   

Aan welke informatie heeft de doelgroep behoefte?   

 

Welke informatie moet de website bieden?   

 

Wat verwacht de doelgroep van zo’n website?   

 

Wanneer is de site een succes?   

 

Bestaan er soortgelijke sites en welke zijn dat?   

 

Welke goede punten kan je van die sites overnemen en welke minder goede punten weglaten of verbeteren?   

 

Hoe dient je site zich te onderscheiden van die andere?   

 

Welke vorm / stijl zou aansluiting kunnen vinden bij de gedefinieerde doelgroep? (modern, klassiek, speels, chaotisch, strak, zakelijk, warm, kleurrijk…?)   

 

Definieer zoektermen waarop de site gevonden zou moeten kunnen worden in een zoekmachine (meer dan 10)   

 

Omschrijf de inhoud van de site (in 2 tot 3 zinnen), zoals je die in een zoekmachine weergegeven wil hebben, waardoor de gebruiker een duidelijk beeld krijgt van de te verwachten inhoud van de site.   

 

Ik hoop dat je hier iets aan hebt.

 

Grtz Arnout

 

 

 

Website_ontwikkelingsfase_hulp.doc

[Wilbert Philippo]

let op dat je niet teveel door elkaar heen gooit.

 

een globale aanpak die al decennia werkt, is de volgende:

 

fase1: commerciele doelstellingen (wat zou je vanuit de business of commercie allemaal willen);

fase 2: conceptueel ontwerp (gegeven fase 1, wat is daar dan op conceptueel niveau allemaal voor nodig);

fase 3: functioneel ontwerp (hier definieer je je proces en datastromen en de techniek erachter);

fase 4: technologiekeuze (welke technologie is nodig, welke database,m welke programmeertaal, etc.');

fase 5: technisch ontwerp (hoe gaan we het dan doen);

fase 6: bouw en systeemtest;

fase 7: eerste oplevering en pilottesten;

fase 8: acceptatietest;

fase 9: aanpassingen n.a.v. acceptatietest;

fase 10: implementatie

fase 11: live gaan!

fase 12: onderhoudsfase.

 

Volgens mij gooi je nu zelf e.a. door elkaar VC ;D

 

Dit is wel de totale werkwijze, maar niet die van de opdrachtgeverskant. Daar zal het m.n. om het PVE gaan. Er zijn hier al een paar goede tips gegeven. Wat in mijn ervaring ontzettend belangrijk is, is dat de sitebouwer, of in elk geval je contacpersoon, zich kan inleven in wat je wil. Iemand die de goede vragen weet te stellen. Daarmee kun je geluk of pech hebben. Voor de zekerheid zou ik dan toch een gedetailleerd PVE hebben.

 

Zelf werk ik nu met een technisch georienteerde club. Ik vertel ze tot op de punt en komma wat ze moeten doen en wat ik wil en ze maken het. Niet duur omdat het hele bovenstaande proces niet doorlopen hoeft te worden in hun organisatie.

 

Echter, als je wat vergeet (omdat het zo voor de hand liggend is) moet het achteraf toch weer over. Uiteindelijk blijken ze ook commercieel te weinig mee te denken en zal ik voor een volgende fase toch naar een partij gaan die breder meedenkt.

 

Ik kies er bij een PVE voor om alle functies die ik wil uitgebreid te omschrijven. Daarin geef ik aan wat eis is (wat er nu in moet komen) wat wens is (wat ik er graag nu of later in wil hebben) en wat ik denk dat er in de toekomst nog aan functies bij moet komen als het een groot succes wordt. Met dat laatste beoog ik dat men er rekening mee houdt dat die functies later toe te voegen moeten zijn. Daarbij kan ik ook niet voorzien wat heel veel werk kost en wat niet, dus vraag ik per punt wat het kost, en kan ik a.d.h. van het budget nog bepalen welke zaken ik er nu wel en niet in wil hebben.

[perry]

Ik heb inmiddels denk ik een redelijk dokument gemaakt.

 

Wie mag ik het eens doen toekomen ter evaluatie?

 

Perry

[Edo van Santen]

@okidoki: ik leer graag en zeker van mijn fouten. maar wat haal ik door elkaar? laat me svp weten, dan kan ik mijn visie daarop geven.

 

@perry: ik wil met alle plezier kijken. je kent mijn email/pm inmiddels.

[Wilbert Philippo]

@okidoki: ik leer graag en zeker van mijn fouten. maar wat haal ik door elkaar? laat me svp weten, dan kan ik mijn visie daarop geven.

 

@perry: ik wil met alle plezier kijken. je kent mijn email/pm inmiddels.

 

Ik bedoelde het PVE waar Perry mee bezig was van opdrachtgeverszijde VS het totale aanpakplan van sitebouwer én opdrachtgever.

 

Ik ben het helemaal met je eens dat dit de juiste totaalaanpak is, maar het is m.i. wat anders als een goed PVE dat je eerst als opdrachtgever moet hebben staan.

 

@Perry: ik wil er best naar kijken en op schieten c.q. suggesties geven.

 

Pfff en ik moeteigenlijk allang aan het PVE van mijn volgende versie LeaseTrader beginnen.... ;D

[Edo van Santen]

kortom, Perry's PVE zit bij mij verweven in fase 1 en 2.

maar ook voor een PVE zou ik fase 1 (commerciele doelstellingen) en fase 2 (conceptueel ontwerp) uit elkaar halen.

 

OK?

[Wilbert Philippo]

Agree, maar dat gaat alleen op als je een bouwer hebt die commerciele doelstellingen kan vertalen naar de techniek, lay-out en usabillity. Zo niet dan moet je dat zelf doen en verwerken in je PVE.

[Edo van Santen]

volgens mij zijn we het gewoon eens.

's kijken waar Perry mee komt :)