Anders Hal Werner fra Peytz & Co. om Drupal-projektledelse

Mød Anders Hal Werner - partner og kontaktdirektør hos Peytz & Co., hvor han er ansvarlig for alle Drupal-aktiviteter.

Jeg har "talt" med ham (via email) om, hvordan Peytz & Co. griber styringen af Drupal-projekter an - og om der overhovedet er forskel på et Drupal-projekt og alle andre webprojekter.

Ole: Har I hos Peytz & Co. en særlig projektmodel, som I anbefaler kunder at bruge - og hvilken projektmodel arbejder i efter internt?

Anders: Vi er midt i en transition over til SCRUM. Nogle dele af virksomheden benytter det til fulde, andre er på vej mod det. 

Der, hvor vi mener at kunne tilbyde kunderne noget ekstra, er før det bliver til et egentlig udviklingsprojekt. Vi har stor erfaring inden for analyse, strategi og konceptualisering. Dette drives dog ikke af SCRUM-processen, men er mere baseret på undersøgelser og workshops og er forarbejde til det egentlige udviklingsprojekt. Med en god klar strategi, som hele udviklingsholdet efterfølgende sættes grundigt ind i, er vi alle klædt bedst muligt på, til at give kunden den løsning, som tjener deres formål og strategi optimalt.

Det er meget forskelligt, hvornår i projektet vi kommer ind, så vi arbejder også ofte med kundernes egenudviklede strategi og koncept. Dette er ikke noget problem, men vi mener stadig det er vigtigt, at hele udviklingsholdet forstår kundens behov.

Ole: Er der forskel på at planlægge et Drupal-projekt og et andet webprojekt - og hvad er i givet fald forskellene?

Anders: Ja, der er forskel på, hvor meget informationsarkitektur/sideskitser vi laver før udviklingsarbejdet.

På et traditionelt projekt vil det meste blive wireframet, men i et Drupal projekt er det en blanding af prototyping i Drupal og wireframing. Det er, fordi Drupal leverer en masse funktionalitet og flows "ud af boksen", som det sjældent giver mening at lave anderledes. Dog tager vi altid kundens strategi i betragtning, og de kerneområder sitet har, vil der evt. laves wireframing til - også selvom Drupal stiller en standard til rådighed.

Den traditionnelle "vandfalds"-approach:

1. Strategi og analyse.
2. Struktur/Design.
3. Udvikling.

Det kan give mange fejl og er svært at budgetstyre, fordi det ikke er de samme der slår brød op (1 & 2) og bager det (3)

Drupal approach:

1. Afklaringsfase.
2. Struktur/design/udvikling.

Det holder fokus på kundens vigtigste prioriteter og udnytter til fulde Drupals mange muligheder.

I afklaringsfasen fokuserer man på forretningsmål og brugerbehov, og hvilke koncepter der kan skabe værdi for begge parter. Man arbejder med tegnede skitser af mulige løsninger, og tegner hvordan KPI'er kan trackes, og vurderer hvilken indsats der skal til for at drifte.

Det primære fokus er at sikre, at de centrale prioriteringer i en balance mellem forretningslogik og brugerbehov, og klarhed om, hvordan man vil arbejde med sit site, når det er færdigt

Konceptvisualisering er et eksempel på en del af sådan en proces.

Under struktur/design/udvikling baserer vi arbejdet på resultaterne fra afklaringsfasen.

Ole: Hvis du skulle give en potentiel kunde tre gode råd i forhold til planlægningsfasen i et Drupal-projekt - hvad skulle det så være?

Anders: 

1. Lad være med at gå i detaljer, for de områder af sitet, der ikke er kerneforretning.
2. Tag udgangspunkt i hvad Drupal tilbyder, dog igen med respekt for kerneforretningen.
3. Mål og forventninger til sitet skal være klare fra start. Hvem er brugerne? Hvad vil vi med dem? Osv.

Ole: Mange udviklingshuse er gået over til SCRUM eller andre agile metoder. I princippet skulle det betyde at kunden kunne slippe for at lave lange kravspecifikationer - fungerer det også i praksis? Er der ting I som udviklingshus kan gøre for at lette arbejdet med at beskrive krav for kunden?

Anders: Der skal ikke laves traditionelle lange kravspecifikationer, men det er vigtigt at have defineret overordnede krav og behov, så vi i den agile proces kender det fulde scope.

Vi deltager gerne i workshops som tidligere beskrevet, og her har vi mulighed for at hjælpe kunden med at definere projektet og byde ind med vores viden og erfaring med Drupal. Kravspecifikation i form af user stories/use cases er en udemærket måde at definere krav uden at gå i detaljer.