Beskriv hur du dokumenterar

I vårt nyhetsbrev delar vi med oss av vår vardag som kretsar kring skräddarsydda webblösningar och vårt medarbetardrivna arbetssätt. Exempelvis att en sida delas till Facebook när man publicerar den. Vi brukar också bjuda hit våra kunder i några timmar för att introducera dem till det system vi byggt och för att svara på frågor som kan dyka upp.

5 tips på hur du som förskollärare kan dokumentera bättre · Prion

Det brukar oftast komma med en användarmanual vilket det gjorde och ju längre tid vi spenderade med att försöka följa den desto mer frustrerade blev vi. Att skapa nya screencasts i samband med att man släpper nya funktioner anser jag skulle vara riktigt bra. Förra veckan ringde en vän mig och frågade om hjälp att sätta ihop några nya möbler i sin nyköpta lägenhet.

För många av våra kunder sätter vi ihop screencasts filmklipp där vi förklarar och framför allt visar hur olika funktioner fungerar och används på våra kunders webbplatser.

Dokumentation

Artikel Hur man skriver bra dokumentation 21 februari Dokumentation för kunden På vilket sätt kan vi bäst lära våra klienter hur systemet fungerar och hur man arbetar med det? De tre frågorna listade ovan anser jag vara det mest centrala att besvara och det är mycket sannolikt att man redan har besvarat dessa under diskussionens gång. Det är rätt oundvikligt att introducera detta på grund av flera olika faktorer som att systemet och dess syfte förändras, tid, budget och liknande.

Även om vi idag har ett bra arbetsflöde för dokumentering så strävar vi alltid efter att bli bättre så jag började också fundera på hur vi kan förbättra befintlig dokumentation och hur man kan skriva den ännu bättre i framtiden. Ett första steg är att ha en användarmanual som introducerar systemet och de funktioner som en klient arbetar med på en daglig basis. Något som känns tydligt och självklart för oss som byggt webbplatsen kan kanske kännas som en omöjlighet för kunden.

Kan det vara så att våra kunder känner samma sak som vi gjorde när de använder webbplatsen vi byggt åt dem? Det är en typ av dokumentation som är mycket uppskattad. Är det något man behöver tänka på när man sätter upp en lokal miljö? Vad är det som skiljer sig i detta system från ett annat? Det är mycket uppskattat och jag tror att detta är nog ett av de bästa sätten att lära sina kunder hur man arbetar med deras beställda webbplats.

Tyvärr är det inte alltid ett alternativ även om det skulle behövas. Genom korrekt och utförlig dokumentation kan man inte bara ge bättre och snabbare information till kunden och sina kollegor, det är också ett sätt att följa ett projekts utveckling över tid och på ett överskådligt sätt. Det finns ett koncept inom programmering som kallas technical debt vilket innebär att något man skapat tidigare kan påverka tid och kostnad på grund av komplexitet i systemet.

En klar fördel är att kunden kan följa flödet från start till slut och hoppa fram och tillbaka vilket är svårare att få till bra i text. Det finns två olika dokumentationer som jag anser att man bör skriva, en för kunden och en för utvecklaren. Då och då behöver man gå tillbaka och arbeta med ett gammalt system som har byggts för många år sedan.

Det kan vara en åtgärd som upptäcks eller ny funktion som behöver utvecklas. En av de viktigaste av dessa punkter är Saker som man verkligen bör känna till om systemet. Vi har en mall som vi använder som grund på de frågor vi behöver ha koll på. Det finns dock inte alltid en budget eller intresse från kunden att att göra så.

Med denna analogi i åtanke insåg jag hur viktigt det är att skriva bra dokumentation. Dokumentation kan ibland kännas onödigt, och kanske rentav tråkigt när man sitter och utvecklar och bygger en webbplats, men det är ett nödvändigt ont. Man kan även se på möjligheten att spela in dessa sessioner så att man kan titta tillbaka vid behov.

Pedagogisk dokumentation

På Kodamera använder vi främst Drupal ett CMS som har en grundläggande manual som vi översatt och som vi använder som grund för att lära våra kunder systemet. I och med detta kan dessa system vara svåra att arbeta med och det finns kanske inga tester att verifiera att de ändringar man gjort inte producerat något annat fel i system. Då varje webbplats som byggs anpassas efter kundens behov behöver även detta dokumenteras.

Det här är dokumentation kommer in i bilden, saker som man gör idag kommer inte vara lika enkelt att förstå om ett halvår eller längre fram. Har man inte möjlighet att träffas kan man fortfarande anordna detta via Skype eller Google Hangout. De är till exempel. Vi försöker se till att dessa saker är, per automatik avstängt när man jobbar lokalt, men i äldre projekt eller projekt som vi tagit över kan man inte ta det för givet.

På vilket sätt kan vi bäst lära våra klienter hur systemet fungerar och hur man arbetar med det? Den bör besvara enkla frågor som hur man loggar in, skriver innehåll, men också hur systemet fungerar och hur man bäst använder det. Hur saker och ting ska fungera kommer man oftast fram till i sprintplaneringar och tidiga diskussioner med kunden, och om man använder det som grund för sin dokumentation kommer man underlätta för sig själv inför framtiden.