Är det någon som kan tipsa om en bra metod att ta fram och jobba med ett webbprojekt. Olika projekt metoder/system för projektledare är också välkommet.

Ett projekt, oavsett om det är ett webbprojekt eller inte, har några viktiga grundstenar tycker jag. Sen om man följer dessa i projekten beror lite på hur stora projekten är och om man är själv eller om flera personer är involverade. Viktiga delar som jag sällan brukar kunna vara utan är att kund (eller jag själv) tar fram en kravspecifikation över vad som ska göras och hur resultatet ska vara i slutändan. Utifrån denna kravspecifikation kan man sedan sätta upp en tidsplan och bryta ut delmål. Sedan tycker jag också att det under projektets gång är viktigt att ha någon form av referensgrupp som kan lämna feedback och kontrollera så att allt fortlöper i rätt riktning. Är man flera personer i projektet är det ett måste med en specifikation över vem som gör vad. Att också hitta en bra metod för löpande möten och hur frågor ska hanteras inom projektgruppen känns också viktigt innan man kör igång. Det finns hur mycket som helst egentligen. Jag vet inte riktigt vad du är ute efter men för just webbprojekt kan jag tipsa om Google Groups som kommunikationskanal mellan projektmedlemmarna - http://groups.google.com

Håller med Elofsson om att det är viktigt att sätta upp vissa grundstenar för genomförandet ex.

1.Efter flera möten med kunden, ta fram en kravspecifikation samt en funktionslista så att teknikerna/programmerarna har något att gå efter och naturligtvis ett kontrakt om vad ni förväntas leverera, det är väldigt viktigt att upprätta dessa dokument även om det kan ta lite tid.
2. Se till att hålla frekventa avstämninsmöten med kunden samt internt.

Övrigt: Se till att aktivera kunden samt att de bistår med input till ALLA inblandade, av erfarenhet så skall tekniker prata med tekniker etc.
Sedan så tycker jag som gammal tidplanerare att man skall lägga upp en ram för hela projektet i ett verktyg ex. MS Project eller Primavera, det är mycket lättare att kunna följa upp projektet och se kritiska linjer samt att det är bra att ha som grund för kommande projekt.

Utöver detta så är det viktigt att man är pedagogisk och att även lära Agda 60 år att hantera systemet, hemsidan eller vad nu projektet kan avse, tekniker tenderar av egen erfarenhet vara nöjda med att systemet, hemsidan fungerar och tar för givet att alla kan hantera detta eftersom de själva kan.
Tycker att MS är ett bra exempel på detta, nästa alla kan hantera Windows oavsett förkunskaper.

Bra svarat gabbar.

Då blir följdfrågan, hur skriver man en bra kravspecifikation? Jag menar en kravspecifikation kan egentligen se hur som helst men det borde endå finnas ett par riktlinjer så som bakgrund, slutmål, tidplanering, budget mm.

Agile brukar funka bra på mindre webbprojekt.

Fundera på att jobba agilt istället. I det projekt jag jobbar i jobbar vi enligt Scrum och det fungerar även i större projekt på stora företag.

Ok, Scrum är http://pps.vmi.se/public/c5scrum/scrum.html :)

Givetvis kan man baka in alla de punkter du nämner i en (1) kravspecifikation men jag själv brukar föredra separata dokument för de olika delarna. Kravspecifikationen ska således enbart vara inriktad på de funktioner som ska finnas, hur själva slutprodukten ska vara utformad rent tekniskt. Om vi nu fortfarande är inne på ett webbprojekt alltså. Sedan låter man tid, budget och övriga delar/planer vara separata dokument även om de är kravbaserade. Det jag vill säga är alltså att det kan vara klokt att låta kravspecifikationen enbart vara tekniskt inriktad. Alla som jobbar efter kravspecifikationen behöver till exempel inte vara involverade i budgeten och det kan därför vara bra att spearera delarna åt.

Om man pratar om ett projekt med en tydlig kund som kanske inte är alltför teknisk brukar det vara en god idé att ha både en funktionsspec och en tekniskspec. Båda beskriver vad som ska göras i projektet med med olika målgrupper. En funktionsspec beskriver hur slutprodukten ska se ut, hur man jobbar i systemet osv. och ska inte kräva någon teknisk kunskap att förstå. Beskriv gärna helheten så man får en bra uppfattning om hur man faktiskt jobbar i den färdiga produkten. Har man bara en alltför teknisk spec finns det risk att alla inblandade från kundens sida inte förstår och risken för missförstånd ökar.

Det finns en del inarbetade och testade arbetsmetoder som innehåller olika steg, krav på dokument osv. som du kanske skulle titta på. Man kan titta över några exempel och plocka ut godbitarna för att hitta sitt eget sätt att arbeta.

Daniel har du sådana exempel? Några namn på metoder du kan nämna? Någon dokument att dela med dig? :)

Det finns ju massa bra böcker i ämnet, en sökning på "projekt" hos en e-bokhandel ger en massvis med träffar. Jag har läst "Arbeta i projekt" av Sven Eklund och den tar upp det mesta på ett bra sätt.

Agile är definitivt vägen att gå, men se till at vara påläst så du verkligen förstår vad det handlar om. Många gör dumma nybörjarmisstag och tycker "agile funkar inte" men egentligen har de inte förstått utan kör på som vanligt, men med nya namn.

Ang. kravspecar är det "enkelt". Beskriv ur ett användarperspektiv och avsluta varje krav med ett "därför att". Exempel:
Systemet skall klara av 100 samtidiga användare och ingen användare skall behöva vänta mer än två sekunder på svar från servern därför att användarna inte skall uppleva systemet som segt

Det är ett bättre krav än "inga databasfrågor får ta mer än 50ms".

Sedan om du kör agile så är ju en kravspec en kanske inte en kravspec utan en samling user stories...

Tackar Elofsson och eg0master.

Det känns som att jag måste läsa ett par böcker innan jag kan säga något om ämnet. Så jag börjar med "Arbeta i projekt" och sedan Agile sedan får vi se vad som händer näst. Jag har ett stort webb projekt som jag vill starta men vill att allting ska vara rätt och professionellt gjort.

Eftersom att jag mest jobbar med Ms produkter använder jag/vi Microsoft Solutions Framework. Men som andra sagt finns det massor av olika metoder.

En sak som är värd att tänka på som projektledare när man skriver en specifikation är den så kallade åtagandetriangeln. Tid, funktion och kostnad. Låser man alla dessa mot kund innan start har man inget att "norpa" av ifall något inte skulle hålla. Uppstår tidsbrist kan man inte minska på funktionaliteten eller kostnaden eftersom dessa är låsta i specen. Uppstår problem med budgeten kan man inte minska på tidsåtgång eller funktionalitet eftersom de är låsta, osv. Att lämna ett av dessa tre åtaganden öppna lämnar utrymme för justeringar under projektets gång och en liten försäkring för de som jobbar med projektet ifall att något skulle fela.

Bra sagt Elofsson, det känns som jag har en del att lära mig ur den traditionella projektledningen :)

Du rekommenderar dock fortfarande "Arbeta i projekt" och inga fler bra böcker? :)

Helt sant. Men det är inte alltid helt enkelt att få igenom detta, speciellt om det handlar om ett fastprisprojekt. Kunden vill oftast ha alla dessa tre faktorer i offerten och sen i avtalet.

Den boken är den enda jag läst i ämnet så det finns helt säkert andra som är bra. Rekommenderar i alla fall denna.

Sant. Kund/beställaren vill ju gärna låsa de tre delarna så klart. :) Tidsåtgång, funktion och pris ska ju helst vara och bli som beställt. Det som återstår då är väl att överdriva i rimlig mån så att man har mariginaler att ta av ifall något skulle fela. Var inte länge sedan jag gick en kurs i just projekt och där sa läraren med ett inslag av ironi att han själv brukade uppskatta tidsåtgången och sedan multiplicera den med pi (3,14). :)