Objektorienterad programmering i WordPress: Statement of Work

Innan vi går in på ämnet objektorienterad analys och design (vilket är då de flesta av oss får ut det roligaste av det vi gör förutom att faktiskt skriva kod), är det viktigt att följa upp några fler saker angående förståelse av kundernas krav .

I förra inlägget nämnde jag:

Om du tar dig tid att förstå vad de vill från början, så behöver inte kraven vara ett 50-sidigt dokument som beskriver hur varje enskild modul måste fungera.

Till exempel, när jag sätter ihop krav (eller ett Statement of Work) som jag brukar kalla dem när jag skickar dem till kunder, överstiger jag sällan tio sidor, och det är ofta färre.

Och även om det finns tillfällen då det är längre, tror jag att en del av anledningen till att utveckla en kort uppsättning krav kommer med de preliminära diskussionerna för att se till att du och kunden/kunderna har utvecklat ett gemensamt språk som ni kan arbeta med.

När du gör det behöver kraven och arbetsbeskrivningen – vad du än väljer att kalla dem – inte vara lika långa.

Att skriva en arbetsförklaring

Först skulle jag vilja skilja mellan ett arbetsutlåtande och krav i samband med detta inlägg.

• Krav är vad kunden vill ha byggt.
• Arbetsförklaringen beskriver vad du ska göra, hur du kommer att göra och för hur mycket.

Jag kommer att täcka det senare mer i detalj i det här inlägget. Men det räcker med att säga att krav kan komma i form av diskussioner, dokumentation eller både och för kunden.

Innan jag hoppar in på de olika delarna av det jag tar med i en arbetsförklaring, finns det några saker som jag tycker är värda att nämna:

1. Skriv inte en arbetsbeskrivning förrän du har fått alla krav från kunden.
2. Se till att kunden vet vad han kan förvänta sig av en arbetsbeskrivning.
3. Om du ska ta dig tid att skriva en arbetsbeskrivning, bestäm om du ska ta betalt för tiden eller inte och se till att kunden är medveten om att de kommer att behöva betala för det eller inte

Detta är en av de saker som är frilansare för frilansare eller byrå för byrå. Med det sagt, här är de delar av en arbetsförklaring som jag brukar ta med.

Förbereda en arbetsbeskrivning

När jag förbereder en arbetsbeskrivning har jag en mall som jag använder. Jag kommer att ge en uppdelning som täcker mycket av det här.

Så här fungerar varje avsnitt:

1 Arbetsbeskrivning

Syftet med detta dokument är att [definiera ett förslag till lösning för PROJEKTET].

Kraven för projektet har tillhandahållits av [KUNDENS NAMN], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. Villkoren i avtalet är en kombination av de som överenskommits av [KUNDNAMN] och [DITT NAMN på AGENTENS NAMN].

2 Översikt över krav

Syftet med detta dokument är att [definiera ett förslag till lösning för PROJEKTET].

Kraven för projektet har tillhandahållits av [KUNDENS NAMN], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. Villkoren i avtalet är en kombination av de som överenskommits av [KUNDNAMN] och [DITT NAMN på AGENTENS NAMN].

3 Språk och teknik

Webbservern, mjukvaran, verktygen och tillvägagångssättet som kommer att användas för att bygga lösningen.

4 webbläsare som stöds

Om detta är ett webbaserat projekt, täck sedan de webbläsare som stöds, om det kommer att finnas responsiv funktionalitet eller inte, och hur de tidigare punkterna kommer att testas.

5 Språk och teknik

Webbservern, mjukvaran, verktygen och tillvägagångssättet som kommer att användas för att bygga lösningen.

6 Projektkrav och milstolpar

Vanligtvis den längsta delen av dokumentet. Den sammanfattar:

• Kraven,
• Hur varje krav kommer att byggas och levereras,
• Eventuella ytterligare anteckningar som kunden bör vara medveten om.

7 Föreslagen tidslinje

Detta är baserat på de milstolpar som beskrivs i föregående avsnitt och feedback från kunden.

8 Andra faktorer

Diverse saker som du väljer att inkludera såsom vad du eller din byrå väljer att ta med till projektet, hur försenad feedback kan påverka projektet, och så vidare.

9 Beräknad kostnad

Detta inkluderar den totala kostnaden för projektet och en valfri uppdelning av betalningsplanen.

Det är nödvändigt

Jag vet: Jag har sagt detta förut i tidigare inlägg i den här serien. Det här är inte den mest glamorösa delen av det vi gör. Istället skulle vi istället hoppa direkt in i programmering.

Men hur vet du vad du ska bygga (och bygga det bra) om vi inte har tagit itu med problemet vi försöker lösa?

Och det är vad allt som leder fram till objektorienterad analys och design ger oss.

Objektorienterad analys

Nu när vi har fått pappersarbetet (eller till och med "affärsgrejer" som vissa kanske hänvisar till det) ur vägen, är det dags att börja arbeta oss in i programmering.

Innan du gör det är det dock viktigt att analysera kraven och bestämma vilka delar av projektet som kommer att tjäna vilket syfte. Till exempel:

• Behöver vi någon redan existerande programvara?
• Behöver vi skriva några adaptrar eller datalagerkod?
• Hur kommer vi att bygga applikationslagret och enheterna inom det?
• Vad sägs om front-end

Och för många är det här det roliga börjar. Så jag är sugen på att börja prata igenom detta också. Vi börjar i nästa inlägg.