Vad kostar en svensk webbutvecklare?
 

Jag är ute efter ett slags snittpris på en relativ vass svensk webbutvecklare som anlitas på timbasis som konsult. Till exempel 25 timmar.

Vad ligger timpriset på ungefär? (ex moms).

Vi förutsätter att konsulten fakturerar genom eget bolag och har ca 5 års professionell erfarenhet med både backend och frontend.

Det beror på en mängd faktorer såsom vilken kunskap som efterfrågas, ju mer specifik den är och om få personer behärskar detta.
Om det handlar om ganska normala saker och utvecklaren ska vara duktig tippar jag på 800+

Beror som sagt på måpnga saker som nosnaj sa.
En viktig faktor är också hur långt uppdrag det är. Är det ett ett längre eller ett löpande uppdrag med ett garanterat antal timmar kan man ofta komma ned lite i pris om konsulten inte redan har mycket att göra.
Mellan 700 och 1200 per timme är nog vad de flesta tar för ganska generella uppdrag som inte kräver spetskompetens inom något specifikt.

Obs: Jag är inte ute efter att anlita någon utan behöver denna uppgift av en annan anledning.

Jag fick ett PM från en som tog 850.

En seriös utvecklare borde ligga ungefär i intervallet 700-1000 kr/h för den längden på uppdrag, lite beroende på.

Är det PHP så verkar det finnas gott om folk som knackar kod för 300 kr/h, men jag förmodar att det oftast inte är så hög kvalitet på arbetet.

Man bör också betänka att duktiga utvecklare generellt jobbar effektivare och att det blir ett längre antal timmar; vilket rimligen innebär att prisskillnaden inte blir så stor i slutänden.

Instämmer i kören, 800kr+ låter vettigt för ett uppdrag i stil med det du beskriver.

Det ovanstående stämmer även överens med min erfarenhet.

För uppdrag som ligger på 25 timmar kan man knappast ens prata om "utveckling". Då pratar vi enbart webbdesign. en utvecklare hinner inte ens läsa in sig på uppdraget på så kort tid, så det blir en omöjlig uppgift.

Att man hinner knacka lite HTML, CSS och Javascript på 25 timmar innebär inte att man (enligt min mening) skulle kalla sig utvecklare.

För att det ska vara frågan om "utveckling" behöver uppdraget vara från 2-3 månader och uppåt.

Men uppdrag (för en riktig utvecklare) som är kortare än 2 veckor får man räkna med att betala från 1250 kr/tim och uppåt. Den karaktären kan vara att hålla kortare kurser, delta i strategimöten, granskning av arkitekturdokument o.s.v. (m a o högst kvalificerade arbetsuppgifeter).

Men är det egentligen frågan om webbdesign så är det ju andra nägot lägre prisnivåer, detta enligt min erfarenhet i alla fall.

Jag skulle vara ytterst tveksam till att ta på mig ett uppdrag som "utvecklare" om det är mindre än 3 månader på heltid, för man hinner inte göra ett vettigt jobb på så kort tid.

Conny, inte för att vara sån men det är nog dags att vakna upp och inse att världen har förändrats....

Annars, håller med övriga på 800kr linjen.

800 kr ner till runt 3-500kr vid längre uppdrag av min erfarenhet.

Conny, jag vet inte om du är långsam på att utföra dina uppdrag, då dem tar flera månader, eller om du anser att ett projekt bara får kallas "utveckling" om den innefattar komplexitet som facebook. Jag vet inte, men oftast tar inte en sida flera månader att utveckla om man jobbar heltid..

800kr är nog en rätt bra riktlinje..

Vilken typ av utveckling hinner man göra på 25 timmar? Specificera gärna, jag har aldrig sett såna "utvecklingsuppdrag", däremot webbdesign av små väldigt enkla webbplatser.

Du hinner ju inte ha särskilt många möten med en kund på 25 timmar.

Det kortaste utvecklingsuppdrag jag själv varit involverad i sedan 1988 (dvs på de senaste 24 åren) när jag började som professionell utvecklare var på 62 timmar och då kopierade jag en gammal applikation i MS-DOS och gjorde några enkla registreringsformulär och en mycket enkel utskriftsfil för kontrolluppgifter för ett försäkringsbolag (inte hela bolagets redovisning utan några 100-tal specialförsäkringar inom Pension/Liv) till skatteverket (detta var ca 1994-1995). Då fick jag mycket beröm för att det var extremt snabbt jobbat. Det var dessutom ett internt uppdrag hos min dåvarande arbetsgivare så det var inte så mycket specifikationsarbete som behövde göras utöver det som redan fanns att läsa in sig på och det jag redan kunde.

På 25 timmar (det är ca 3 dagar) så hinner man inte göra utvecklingsarbete, däremot support.

Det är nog andra än jag som behöver vakna från en törnrosadröm där man helt saknar verklighetsförankring.

Jag utmanar den som kan specificera vad du hinner på 25 timmar att visa vad du kan åstadkomma på den tiden, så får vi se, jag har inga såna refernser att visa upp och jag vet ingen annan som har det heller och då har jag jobbat sedan 1988 med utveckling och arbetat i många och påe långa och korta projekt i både små och stora företag.

Jag vet att det jag gör är fel, men hade jag fakturerat min kund för den tiden vi är på möten så hade jag inte haft någon kund.

Då är ditt arbetsätt knappast särskilt affärsmässigt eller professionellt.

Det blir väl inte mindre affärsmässigt bara för att han kanske måste ge lite för att få senare? Man gör väl vad man måste.

SUCK!!! Jag tyar icke mer....

Hej,

Skulle det vara mer professionellt för att det tar lång tid? Det är 2012!

En utvecklare i mitt närområde mobilanpassade en sajt på ca 25 timmar (tror det snarare var 20). Den funkar precis som den ska i Android, iPhone, Windows och BlackBerry. Den ser lika proffsig ut som vilket storföretags mobilversion som helst.

Jag vågar knappt nämna den blygsamma summan han tog.

Själv tar jag 170 spänn i timmen för externt jobb, men bor ju i Thailand ;-)

Titta på presentationerna från 24H BC. Många färdiga projekt, många fullgoda prototyper och många projekt som bara behöver avslutas. Det är 24 timmar, minus eventuell sömn.

Att man sällan hinner med hela applikationer på 25 timmar är väl sant. Men väldigt ofta söker företag någon för mindre uppdrag, som att mobilanpassa en sida, prestanda-optimera ett par vyer, rekommendera/analysera en mindre infrastruktur, konfigurera en servermiljö, göra små ändringar i en färdig modul osv.

Vore intressant att veta vilken sida som mobilanpassats så kan vi "utvecklare" här se vad resultatet är ;) Om det t.ex. bara handlar om en wordpress-sida och installera ett tema är det ju långtifrån ett riktigtutvecklingsjobb.

Hehe, kan hålla med dig i vissa avseenden, det är inte alltför långt man kommer på ett projekt under 3 dagar.
Möjligen kan man hinna modifiera ett befintligt litet projekt eller skapa en väldigt liten sak.
Troligen räknar väl folk en Wordpress-installation till hardcore utvecklingsjobb :-)

Jag håller med, ofast tar inte ett projekt 3 dagar. Jag är inne på min 8e dag idag på ett projekt nu. Vi tar 400 - 500kr per timme.

Men jag känner fortfarande att all typ av kodning kan kallas för utveckling. Kanske inte på professionell nivå, men allt från att utveckla en ny sorteringsmeny till en befintlig hemsida, till att utveckla en helt ny hemsida - kan kallas för utveckling :)

Hej,

Att diskutera hur lång tid ett projekt tar kan ju att jämföras med frågan om hur långt ett snöre är.

Bara för att ta ett exempel kan ju en logo-design kan ju ta allt ifrån en timme till ett par år och kosta allt från nästan gratis till miljoner. Det finns suveräna loggos utformade på ett par timmar, likaväl som det finns katastrof-exempel som tagit månader (med en halv byrå bakom) att ta fram. Vem minns inte Telisa med en himla massa stjärnor. Sedan med alla variationer däremellan.

Dock är väl 700-1000 ett vanligt timarvode i Sverige bland mindre utvecklare och designers.

noshaj,

Det är ingen Wordpresssida som låg bakom. Dock använder han en (delvis) egenutvecklad modell som är enkel att applicera på de flesta sajter som inte kräver alltför skräddarsydda lösningar.

Ja, det hela beror ju på vad kunden har för krav. En liten kund som vill oftast ha en enkel webbsida utan specialanpassning till ett lågt pris. Då gäller det att kunna möta kundens krav.

Det är inga problem att sätta upp en sida baserat på Wordpress eller eget system där man redan gjort grunderna på 25 timmar om man förberett sig och har har en grundmall/grundtema som man baserar allt på.

Har man en bra grund är det inga problem att sätta upp en bra sida på 10-15 timmar (5 timmar design, 5-10 implementation). Lägg sedan eventuellt till ett par specialfunktioner (5-10h) och ändringar efter kunds önskemål (1-5+ timmar).
Då landar vi på någonstans mellan 15 och 30 timmar för själva produktionen, varav 10 timmar är front-end-utveckling(vilket också är webbutveckling) och 5-15 timmar back-end-utveckling.
Sedan tillkommer möten för att ta reda på vad kunden vill ha(2 timmar, detaljerad kravspecifikation är onödigt i det här läget och det är inget kunden vill betala för) samt en del arbete med att skriva offert administration kring fakturering m.m. (1-2 timmar).
Totalt hamnar man då på under 20 timmar för en kund som inte har speciellt höga krav och 30-40 för en med lite mer krav. Då kan man leverera en sida för 15-20 tusen kronor.

Det hela beror ju som sagt på vad kunden har för krav, önskemål och budget.

Det är som sagt var ingen större idé att lyssna på Conny i de här sammanhangen, han väljer att envist leva kvar på 90-talet av någon märklig anledning.

Han har dock rätt i en sak nämligen att det handlar om ett mycket kort projekt. Timpriset kommer då bli relativt högt och jag tror liksom flera andra att du får närma dig tusenlappen. Sen beror det alltid på hur marknaden ser ut just vid det tillfället, om du behöver särskild expertis, vilka övriga krav som finns osv.

Connys ständiga övervärdering av utvecklare framför designers är naturligtvis inte heller korrekt. Ska man anlita en riktigt vass designer så går priserna upp rejält även där. Design tar också mycket tid i anspråk om det inte bara handlar om en simpel företagspresentation.

Ha, äntligen någon som fattar.... :-)

Om man räknar med ett 3-dagars-uppdrag (på heltid, dvs 8 tim/dag) så är det rimligt att ta ca 30 KSEK, dvs 1250 SEK/tim. detta just får att uppdraget är så extremt kort. det är mycket administration runt omkring som säljmöten, avtal, fakturering, rapportering som man inte kan specificera till kund men jobbet måste ändå göras. därför är kortare uppdrag dyrare än längre uppdrag då längre uppdrag har fler timmar att fördela overheadkostnaderna på. Det uppstår även s.k. "slack", dvs "tidspillan" (advokater specificerar "tidspillan" på fakturan till domstolarna, det kan vara "6 timmar biträde klient" och "3 timmar tidspillan" på en typisk advokatfaktura).

Att man tar mer betalt för korta uppdrag innebär inte att man som konsult tjänar mer pengar på ett års sikt utan bara att man kan hålla samma nivå som för längre uppdrag. Nu skriver jag om "uppdrag" för det här är inte utvecklingsuppdrag utan mer installation, konfiguration, webbdesign, front-end (anpassning av HTML, CSS, JavaScript) och support. Jag kallar INTE sånt för "utveckling" utan mer konfiguration/installation av befintliga lösningar.

Men möten med kunden som ingår i jobbet som presentationer, demo av färdiga produkten, kunskapsöverföring till kunden, tester, allt detta kan man normalt debitera för om man jobbar på löpande räkning. Jobbar man med fastpris så ska man ju lägga på ytterligare en dos med risk- och trygghetspremie. När man jobbar på fastpris så säljer man ju trygghet till kunden, det är något man kan ta betalt för (givetvis skriver man inte "trygghet" som en fakturarad, men det är ändå "trygghet" man säljer till kunden. "tryggheten" att veta vad det kostar). Men diskussionen om löpande räkning eller fastpris får vi ta i en annan tråd.

Ja, fast nu utgår jag från att beställaren inte räknar med ett nytt Facebook på dessa 25 timmar :) Tar man in någon på timbasis på det här viset så handlar det antagligen, och förhoppningsvis, om ett gäng tydligt specade punkter som ska kunna göras utan en massa möten och annat tjafs. Då kan en anställd, insatt utvecklare på företaget introducera konsulten snabbt genom ett Skype-möte eller dylikt. Man måste alltid anpassa arbetsmetoderna efter förutsättningarna. Det går självfallet inte att köra samma upplägg på ett årslångt projekt som på ett 25-timmars konsultuppdrag.

Det här gällde då ett typisk fall av installation av exempelvis Wordpress eller någon annan "färdig produkt" som bara ska installeras, konfigureras och köras.

Vi är nog helt överens om att ett 25-timmars-uppdrag och ett 2 500-timmars-uppdrag har helt olika upplägg.

Men jag hävdar ju dessutom att när vi pratar om ett 25-timmars-uppdrag, så är det knappast frågan om "utveckling", utan mer om installation, konfiguration, support. Det är knappast "utvecklare" som jobbar med den typen av uppdrag utan snarare tekniker- eller support-personal om man ser till hur verksamheten är organiserad i en lite större organisation.

I ett litet små-skutte-företag så gör samma person många olika arbetsuppgifter så bara för att man ägnar 1 timme av ett 25-timmars-uppdrag åt att kopiera 10 rader javaScript-kod och ändra en connectionsträng eller skruva på några CSS-värden för att justera färg och form på en webbsite så blir man inte utvecklare för det. Man är då snarare en installationstekniker. Det är inget fel eller nedvärderande i det (det är bara helt olika yrken) men jag anser inte att det är "utveckling".

Om man tar som jämförelse skillnaden mellan en bilmekaniker och en utvecklare av nya bilmodeller på Volvo eller Wolksvagen, båda yrkesgrupperna arbetar med bilar men de har helt olika yrkesroller, den ena arbetar med bilens underhåll medan den andre "utvecklar" nya bilmodeller (jag gör fortfarande inte någon "nedvärdering" av endera yrket, men man måste ändå skilja dem åt för det är helt olika kompetenser som krävs).

Om man ser till större företag så brukar en aktivitet vara i storleksordningen 200 mantimmar i den löpande förvaltningen av applikationer och det är först när man kommer upp i manår (ett manår är ca 1200-1250 mantimmar beroende på bolag) som man brukar lägga upp en "projekt" för en samlad grupp aktiviteter.

När man hyr in konsulter så brukar man specificera ett antal aktiviteter för varje konsult men man är ofta fler personer som jobbar paralellet med olika delar av ett projekt, ibland delar man även upp aktiviteter så det är fler som jobbar med dem. Men det är att föredra att man allokerar en person för varje aktivitet.

Personligen föredrar jag att en aktivitet sk delas upp så den räknas i några dagar eller helt inte mer än någon vecka. Men det beror på vad det gäller för uppgift.

Enligt metoderna Toyotas Lean, Rational/IBMs RUP och KanBan så kan aktiviteterna variera i storlek och även iterationerna, SCRUM har inte den flexibiliteteten utan där har man bestämt att en "sprint" (SCRUMS namn på en iteration) alltid ska vara exakt en viss längd (tror det var 2 veckor).

Jag tycker att en kombination av Lean (generella principer för att hitta och undvika flaskhalsar i produktionsprocesser), RUP (Utvecklingsmetod), PROPS (projektstyrningsmetod) och KanBan(projektstyrningsmetod) är mest intressant. SCRUM (projektstyrningsmetod) är en "hjärnskadad" metod som inte borde användas.

Jepp det är dyrt i Sverige.

Har man ork att gå igenom utlandet med mycket inkompetens för att hitta guldklimpen så finns det duktiga utvecklare som knackar för 150-200 kr per timma där.

Men det krävs ganska mycket jobb, och du bör även kunna granska koden/arbete själv och inte förlita dig på att de gör rätt. Men den regeln tror jag gäller även i Sverige.

SCRUM fungerar bra om du kan jobba relativt nära med kunden då möten hålls såpass frekvent. Fördelen med denna metod är att man är mer flexibel och kan svänga projektet, något som ofta sker inom webbprojekt. Möjligt det inte fungerar lika bra på stora projekt där man är många utvecklare...har bara erfarenhet upp till ~10st och då var det inga problem.

Okej, det kanske mest handlar om en definitionsfråga då. Jag kallar det för utveckling oavsett om det handlar om ett stort projekt byggt från grunden eller om det gäller vidareutveckling eller nyutveckling av ett fåtal funktioner. Även i större koncerner så är det idag ganska vanligt med bred kompetens och växlande arbetsuppgifter då de ofta är uppdelade på ett stort antal mindre bolag. Så är det exempelvis inom de större mediekoncernerna idag vilka äger de flesta större webbplatser.

Jag har mycket stor respekt för ditt kunnande inom det mesta Conny, men när det gäller utvecklingsmetodik har du en väldigt ålderdomlig syn.

Mer eller mindre hela IT-branschen har anammat agila utvecklingsmetoder där man jobbar i små utvecklingsteam och i korta iterationer. Av alla utvecklingsmetoder är Scrum den mest utbredda och en av mest hyllade. Att säga att det är en hjärnskadad metod visar bara din ignorans på det här området. En viktig sak att poängtera är att de flesta av dessa utvecklingsmetoder bara är ramverk för hur man ska lägga upp saker och det finns väldigt stora möjligheter att anpassa metoderna efter verksamheten och den kompetens man har i teamet. I Scrum är det t.ex. inga problem att välja den sprintlängd som passar bäst, det kan vara allt mellan 1 vecka till 1 månad, eller i undantagsfall ännu längre. Scrum ÄR väldigt flexibelt.

RUP är däremot en väldigt föråldrad utvecklingsmetod även om det finns många bra delar som fortfarande är väldigt användbara, men inte riktigt på samma sätt. RUP förespråkar till stor del vattenfallsmodellen(även om det utvecklats en hel del iom agil-vågen) som de allra flesta har dömt ut på grund av dess inflexibilitet och för att det blir väldigt mycket oproduktivt arbete som inte skapar värde(waste/muda i lean terminologi). Man kan plocka ut guldkornen ut RUP och använda dem agilt. T.ex. kan ett klassdigram vara ett levande dokument som gör ändringar i allteftersom man implementerar klasserna istället för att försöka tänka igenom allt på förhand och spika det innan man börjar med implementationen. RUP har givetvis flera tillämpningsområden och passar väldigt bra i vissa projekt. Jag tänker främst på stora projekt där man vet vad man vill ha och det inte finns så mycket osäkerhet eller risk för att kraven kommer att ändras, t.ex. banksystem. Vid utveckling av nya innovativa lösningar måste man vara mer lättrörlig så att man hantera ändrade förutsättningar och därmed krav på ett effektivt sätt med minimalt med spill och bortkastat arbete.
Innovativa företag som t.ex. Facebook och Google måste jobba väldigt agilt för att kunna upprätthålla innovationskraften medan banker oftast inte jobbar speciellt agilt eftersom det viktigaste där är stabilitet och att lösningarna är väldigt välgenomtänkta och vältestade.

Att kombinera Scrum och Kanban är ofta en enormt lyckad kombination. Här är en kort video om det: http://www.youtube.com/watch?v=0EIMxyFw9T8

För det första Ignorera betyder att strunbta i på svenska, att vara ignorant betyder att vara en person som struntar i något (på svenska).

På engelska betyder "Ignorant" att man är "okunnig" eller "saknar kompetens".

Din beskrivning av RUP bevisar bara att du inte har en aning om vad du pratar om! RUP var en föregångare när det gäller korta utvecklingscykler, iterativ och inkrementell utveckling. RUP är extremt flexibel som metod och det finns inte ett spår av vattenfallsmodell inom RUP. RUP är även en verktygslåda med färdiga definitioner som man kan använda OM MAN VILL. Men det finns inte mycket man MÅSTE göra annat än iterationer, inkrementellt och iterativt utvecklingsarbete, samt att man levererar s.k. artefakter (leverabler). Ett viktigt dokument i RUP är SAD (Software Architecture Document).( Se detaljer om metoden på Wikipedia: http://sv.wikipedia.org/wiki/Rational_Unified_Process )

Det finns faser där man fokuserar på olika saker men de är i högsta grad flytande från projekt till projekt.

SCUM har by definition satt in Timeboxing så att man alltid måste hålla samma längd på sprintarna vilket gör att man "by definition" måste skapa ganska krystade leveranser och om du följer med i nyhetsforumen på internet så klagar folk på just detta som ett stort problem med SCRUM. Om du anpassar längden på en sprint så följer du inte SCRUM-metoden och bör inte hävda det. Då har du ju insetta tt den inte funkar som den är "out-of-the-box" som det hävdas att den ska göra utan du måste anpassa den så den blir mer likt RUP med sin flexibla inställning till hela utvcklings-processen.

Agile RUP: http://www.agilemodeling.com/essays/...odelingRUP.htm (RUP ur en agil synvinkel)
Se detaljer om Toyota LEAN Production: http://sv.wikipedia.org/wiki/Lean_production
Se detaljer om KanBan: http://www.crisp.se/gratis-material-och-guider/kanban
Se detaljer om SCRUM: http://sv.wikipedia.org/wiki/Scrum

Jag är specialist på systemutveckling och systemutvcklingsmetoder så kom inte med idiotiska kommentarer om att jag inte vet vad jag pratar om eller att jag har ett förlegat synsätt på arbetsmetoder inom systemutveckling. Då gör du dig själv bara till åtlöje.

Det jag menade med "ignorant" var just det, att du inte vill ta till dig de nya metoderna som kommer, inte att du är okunnig eller saknar kompetens.

Angående RUP har du säkert rätt. Större delen av min erfarenhet av RUP som process kommer ifrån mina universitetsstudier och där fick jag en ganska negativ bild av det som en utvecklingsprocess. Men det kanske berodde på mer på utbildningens uppbyggnad än RUP som metod.

Min största invändning emot RUP är just det som beskrivs tydligt i Wikipedia-artikeln du länkade till - de fyra faserna som måste genomföras varje iteration och att fokuset enligt RUP ska ligga på de två första faserna (Inception och Elaboration). Det står ju till och med såhär i Wikipedia-artikeln: Visst är det bra att undersöka saker innan men i RUP går det till överdrift. Hur kan förberedelsen inför en uppgift vara viktigare än själva uppgiften. Ett mycket bättre sätt för både projektet och beställaren(kunden) är, enligt mig, att lägga tiden på en prototyp, s.k. rapid protoyping. Det innebär att man snabbt slänger ihop en prototyp(gärna en klickbar) så att kunden kan få en bild av hur slutresultatet kan komma att se ut och att man redan här kan börja ta in feedback. Med RUP känns det som konstruktionsfasen sällan utgör mer än 50% av all arbetstid, medan man i Scrum förmodligen nästan alltid hamnar över 80%. Det skulle jag absolut inte vilja betala för som kund om man säger så.

Min andra invändning är kravet på att producera massa artefakter som i slutändan inte bidrar med speciellt mycket värde varken för kunden eller utvecklarna(massa dokument och modeller). Jag säger inte att det är dåligt med dokument, men jag tycker fokuset i RUP verkar vara att producera dokument och modeller snarare än att utveckla systemet många gånger vilket jag tycker är idiotiskt, eller "hjärnskadat" om man ska använda ditt uttryck. Att man sedan "måste" leverera dessa artefakter innan man kan börja implementera är ofta bortkastad tid. Jag ser mer värde i att dokumentera under tiden man jobbar eller efter när man vet hur systemet är uppbyggt än att man tvunget ska göra det innan man kan börja implementera för att testa sina antaganden emot verkligheten snarare än teorin.

Givetvis finns det problem med Scrum, men det gör det med alla metoder.
Scrum har inte några direkta regler utan man tar de metoder man gillar och ändrar på de man inte gillar. Det finns många anledningar till att man har fasta sprintlängder, t.ex. att man kan mäta scrum velocity med en burndown chart och att man får kontinuitet som gör det enklare att planera. Att ha daglig uppföljning och många leveranser gör också att att man blir mer motiverad. Vid leverans levererar man bara de user sories som är helt klara vilket gör att det inte blir så krystade leveranser, åtminstone inte om man planerar bra.
Vill man inte ha fasta sprintlängder finns en metod som kallas Scrum-ban, vilket är en kombination av Scrum och Kanban utan fasta sprinttider men där man har bland annat har scrummöten.

Fel. Det är samma ord (från latinets ignorare) och kan användas på samma sätt i bägge språken även om det i vardagligt tal fått en liten annan utveckling i Sverige.

I så fall är det förmodligen inte systemutveckling enligt din definition som de flesta av oss här på WN arbetar med dagligen helt enkelt. Din spetskompetens har legat utanför webben medan det omvända gäller majoriteten här. Då blir det ganska naturligt en del skilda åsikter eftersom det har varit två vitt skilda världar (som dock närmat sig varandra under senare år). När en fråga ställs här gällande utveckling så handlar det med största sannolikhet om webben om inget annat anges. Därför blir det en del "vilda" reaktioner när du applicerar för denna verksamhet tämligen irrelevanta arbetssätt. Var sak har sin plats helt enkelt.

Snacka om att detta blev en höna av en fjäder...
Men om det nu redan gått som det har. Så kan ju jag ha lite kul och skriva av mig också :-)

Min syn på timpengen:
Det är ju bara är att konstatera att alla uppdrag är olika och behöver olika kompetens. Ju svårare att få tag i kompetensen ju dyrare lär det ju vara speciellt om personen som behövs vet om dess egna specifika värde... Att sätta ett pris på en timpeng blir ju därmed också tämligen svårt. Då det givetvis beror på uppgiften och om personen som tillfrågas vet om att behovet är större än tillgången osv osv. Dvs, vi är tillbaka på den gamla regeln om tillgång och efterfrågan :-).

Min syn på olika processer:
Vad gäller olika sätt att jobba kan jag bara konstatera att det finns ett otal sätt att tjäna pengar på genom att sälja processer med instruktioner på hur företag skall jobba. Ja, det är Big Business... Med många aktörer som vill ha sin del av kakan för att lära ut DERAS arbetssätt för att få jobbet gjort. Finns en hel del företag som lever enbart på detta. Och det mesta de lär ut är egentligen bara common sense/logik. En företagsidé med väldigt låga kostnader men med oförskämt bra payback... Samtidigt kräver oftast dessa processer en massa extra arbete framförallt initialt för ett företag. Men med en stark ledning kan den med tiden slimmas för att passa det som företaget egentligen behöver... Finns en massa exempel på att de processer som lärs ut faktiskt inte alltid bara är av godo eller på något sätt felfria (exempelvis Toyotas återkallning av bilar efter försäljning... Trots att de använt "perfekt" metodik sen lång tid tillbaka).
Ibland har man en känsla av att företag tror att de blir mer konkurrenskraftigt om de jobbar som någon annan gör. Men det ligger i sakens natur att vi alla är olika och därmed också inte kan passa in i en och samma process. Sen kan man ju också konstatera att för att vara unik och lyckas lite extra kan man inte vara som alla andra... Så varför eftersträva det då?

Ta godbitarna ur processerna och gör det som passar. Lägg sen till lite eget "salt" så lär det "smaka" bättre :-)

Så, då har jag fått prata av mig också :-)

Problemet är att du helt har missuppfattat hur man kan använda RUP, faserna är inte det viktiga i sig, det är iterationerna i RUP som motsvarar sprintarna i SCRUM, faserna är mer en överblick för stora projekt för att visa på att man i olika faser jhar olika fokus, men som det TYDLIGT framgår i wikipediaatriklen om RUP så har man exempelvis kravhantering under HELA projektet, man har implementation (dvs i princip kodning) likväl under i stort sett hela projektet.

Inceptionfasen motsvarar begreppet Förstudie och det är vanligt att man har helt egna projekt för det. Det är vanligt att en förstudie aldrig kommer vidare och blir ett system, eftersom det kanske beräknas ge för liten avkastning på investeringen ellr innebär för stor risk. Eftersom man i RUP har inkluderat denna fas i metoden så täcker den en större del av ett systems livscykel än vad SCRUM gör. SCRUM verkar enbart vara inriktad på motsvarigheten till konstruktionsfasen i RUP. SCRUM har inte ens med detta i sitt koncept.

I RUP finns även Deployment med, det finns även ytterliagre en fas som kallas maintenance men den brukar inte tas med när man pratar om utvecklingen eftersom den är "förvaltningsfasen" (Men skateverket har enstor och viktig användning av den fasen eftersom de flesta sstem de har lever under så lång tid, men det sker ständiga förändringar).

Prototyping är en av hörnstenarna i RUP så att sätta prototyping och RUP i motsats till varandra är helt enkelt en missuppfattning.

Jag har även gått på systemutvecklingskurser på universitetet och de har en generel missuppfattning om vad RUP är och hur den fungerar. RUP är by definition mer flexibel än SCRUM för att ta ett exempel. Den lärare jag hade på universitetet förstod inte RUP så vi hamnade i konflikt om just det. Jag har nämligen gått utbildning i just RUP och då specifikt OOAD-kursen (OOAD => object Oriented Analysis and Design) och det kändes pinsamt att de på universitetet hade så dålig koll på en av nutidens mest kända och använda systemutvecklingsmetoder.

De använde samma argument som du använder, men det är många utav styrkorna med RUP att den är iterativ, inkrementell, och att man använder prototyping och TIDIGA leveranser, testa de högsta riskerna först m.m.

Faserna i RUP beskriver INTE en vattenfallsmodell, det är en helt felaktigt uppfattning. det är iterationerna som är grunden, med leverans av KÖRBARA program vid VARJE iterations slut.

Programkod är en artefakt! En artefakt är en leverabel, dvs programkod eller en exekverbar programfil, eller vad som önskas efter varje iteration. Ja fokus ligger på Leveranser av artefakter (dvs i princip körbara program).

RUP är dessutom så komplett och flexibelt byggt att det fungerar att skala upp från de minsta appar man utvecklar för mobilen till jätte-bauta-appar för USAs försvarsdepeartements logistiksystem (som i sig är en jätte-bauta-big app, det finns säkert fler som jag inte känner till).

RUP bygger dessutom på att ständigt ta in ny kunskap och nya erfarenheter (det är aktiv del av hela konceptet), något som kallas "Best Practises", dvs vilket betyder den bästa kunskap vi känner till just nu.

RUP är dessutom en "Systemutvecklingsmodell" vilket INTE SCRUM är, SCRUM är en "projektstyrningsmodell", det finns inte ett ord om HUR man ska bygga ett system i SCRUM. RUP är däremot mycket fokuserad på att beskriva HUR man ska bygga ett system för att det ska bli bra.