[LNO]

Jag har ett problem som jag tror att jag inte är ensam om, och det är hur man beräknar tidsåtgången på ett projekt? ex.vis php-programmering. Jag förstår ju att projektets omfattning och komplexitet är två variabler som är väldigt viktiga i detta samt naturligtvis programmerarens erfarenhet. Men hur jag än beräknar tidsåtgången på ett projekt så är det nästan omöjligt för mig att hålla mig inom ramarna! Är det någon som har några bra tips i ämnet så mottages dessa med största tacksamhet

[Ara]

allt tar längre tid än man tror=) Det är mitt tips.
Försök att dela in projktet i flera små bitar och gå noga igenom hur lång tid du tror varje del tar. Lägg även gärna in lite ledig tid mellan dom olika iterationerna.

[olsserik]

MS Project (är bara det jag använt) funkar skapligt bra för detta tycker jag.
Det fina är att det går att använda det från första stadiet, skriv ner aktiviteter (behöver inte vara i tidsordning), kasta ut ungefärlig tid för varje aktivitet, ordna dem i tidslinje, länka dem, finjustera tidsramarna inom aktiviteterna, lägg ut resurser (personal med timkostnad) och kolla resultatet.

Det finns säkert andra liknande program som funkar lika bra eller bättre, tipsa gärna isåfall.

[goose]

börja med att aldrig uppskatta en veckas jobb till mer än 32timmar, dvs en dag iveckan går nästan alltid bort i möten, adminsysslor o annat junk. sen gäller det att låta dina programmerare vara väldigt delaktig i tidsuppskattningen.

[rhuse]

"Allt tar dubbelt så lång tid och kostar dubbelt så mycket som man tror" var något en gammal mentor i "projektledning" sa sig leva efter.

[Jonas]

Räkna 30% av tiden till kodning, resterande 70% till att testa & fixa buggar.
Så lägg till 70% av tiden pga detta.

Det är bättre att kunna leverera tidigare eller i tid än att leverera sent.

[Conny Westh]

Ett sätt att få lite fason på tidsestimaten är att bryta ner hela projekltet i små enheter, det finns en metod flr detta som kallas "Work Breakdown Structure" eller WBS.

Du ska ta med ALL tid som går åt till projektet, även resor till och från kunden, förhandlingar, kundmöten, kravspecificering, telefonsamtal, "tänkande", prototypande, skissande, egen utbildning (lära dig ett verktyg), avtalsskrivande, avtalsutformning, fråga kompisar om råd, planering av projektet, testning som du själv gör, testning som kunden gör men där du assisterar, slutleverans och kvittens på at allt är levererat m.m.

Kodning brukar traditionellt ta ca 15-25% av ett helt projekts tid.

Dokumentera varje projekt hur mycket tid det tar på varje delmoment så blir du bättre och bättre på att uppskatta tiden för varje projekt du gör.

Ta även hänsyn till att kunden ALDRIG blir nöjd med första utkastet utan de vill säkert ha 10-15 olika uppdateringar innan det blir klart.

[lesoft02]

Kann bara hålla med ConnyWesth, den metod som vi kommit fram till ger bäst säkerhet är att bryta ner projekten i fårhållandevis små beståndsdelar och tidsätta varje moment. Därefter måste det i slutkalkylen läggas till en post ospecificerad tid, lite beroende på komplexitet.

För att hitta en struktur som passar dig vid kalkylering se till att detaljerat bokföra all tid för de projekt du går där alla moment ingår inte bara kodnign och test utan även möten, utvärderingar dokumentation mm mm. Använd detta sedan för att bygga din egen kalkylmodell för framtida projekt.

[PerD]

Håller med om att ett arbetssätt med olika steg är att föredra. Finns en hel del böcker om utvecklingsprocessen där getta tas upp hur man ska beräkna tid, vad det ska kosta etc. Ett bra grundläggande råd är att se till vad som kan klaras av inom en viss tid. Att inte vara för optimistisk och att inte heller lägga till nya saker under projektets gång. Visst ska det finnas tid för anpassning och utvärdering men lägg inte till nya funktioner.

[studiox]

Hur mycket tid har du och hur mycket pengar handlar det om?

Desto mer tid du har och desto mer pengar det handlar om desto viktigare är det att du gör en bra uppskattning.

Med tiden kommer man lära sig att göra vettiga uppskattningar, men kommer även att göra fel

Håller med ConnyWesth - Jag brukar lägga in projektet i excel med huvuddelar och bryta ner det i beståndsdelar som jag kan överblicka.