Fördelen med att estimera tid som gruppaktivitet

Tidsuppskattning är en viktig del i ett projekt. Om inte dagligen så ber jag killarna och tjejerna i mitt team att skatta uppgifter minst en gång i veckan.

image3Genom att låta dem tidsuppskatta i grupp får jag bättre tider - mer korrekta tider. Om jag ber en programmerare skatta tiden för att koda in feature X, och han i grupp får bedöma tid skapar det diskussion. Kanske har någon annan programmare gjort någonting liknande, eller kanske är det en grafiker som påpekar att det även inkluderar grafiska resurser. Kommer en diskussion upp om en feature är det också ett gott tecken - kommunikation minskar chansen att featuren har misstolkats. Inte minst gör grupp skattandet att man lär sig av andras erfarenheter. Givetvis tar själva skattandet lite längre tid men i slutändan har man ändå vunnit på det.

Min erfarenhet är dock att det tar lite tid innan folk vänjer sig vid att estimera tid "offentligt"... Den tid man anser sig behöva kan ju till synes göra ens "kompetens" synlig. Jag tror därför det är viktigt att man som projektledare ser till att uppmuntra ärliga tider och inte "jag är grym, därför tar det bara 4 timmar".


-DNPL

Varför får du inte jobbet?

CNN har listat 25 anledningar över varför du inte får jobbet som du söker... inte några fantastiska avslöjanden utan ganska standard som tex. undvik stavfel, inte undersökt företaget ordentligt som du söker till. Faktum är att jag är ganska förvånad ibland när jag håller intervjuer och den sökande inte ens har försökt att titta upp de produkter som vi har släppt på marknaden tidigare. Lite intresse tack!

-DNPL

Herd your black sheep

Herd your black sheep - Brad Bird från Pixar menar att efter varje avslutat projekt har man ett antal frustrerade människor som fnyser och suckar över att man borde ha gjort saker och ting på andra sätt än man gjorde. För att skaka upp produktionsteamen och inte tappa gnistan Ser Bird till att dessa avfällingar får chans att bevisa sina teorier.

image2


Vi har den typen av människor också. Det är jobbigt under själva projektet att hela tiden tampas med personer som har bättre metoder, ideer och arbetsflöden. Ofta (men inte alltid) brister deras teorier på kontakt med resten av teamet. Dom är ofta fokuserade på en specifik arbetsuppgift eller lösning.

Jag tycker dock man skall stötta dessa - utan deras galna "out-of-the-box-ideér" stagnerar man. Vi behöver utmaning i projektet.

Det är dock en svår balans, men kanske har Bird en grym poäng där han låter dessa svarta får få utspel i början av ett projekt.

Frustrerade teammedlemmar är dessutom de första som sticker om de inte får något som helst gehör... och kan ju dra med sig andra i bara farten.

Intervjun med Brad Bird hittar du här.

-DNPL

Telia får iPhone

Igår kom ett litet kort pressmeddelande om att Telia blir leverantör av iPhone. Det gör mig mycket glad eftersom vi har företagsabonnemang hos Telia. Kanske blir det att skaffa sig en liten iPhone senare då...

Om du missat hela iPhone fenomenet går det att läsa upp sig lite på MacWorld's iPhone sidor.

-DNPL

Intressant artikel om kreativa team

På Found|Read finns ett utdrag ur en intervju med Pixar's Brad Bird om hur man göder kreativa team. Brad Bird är regissören bakom The Incredibles och Ratatouille. Den fulla intervjun finns på McKinsley Quarterly och kräver registrering (gratis dock).

Brad Bird's läxor:
  1. Herd your black sheep
  2. Perfect is the enemy of perfection
  3. Look for intensity
  4. Innovation doesn't happen in vacuum
  5. High morale makes creativity cheap
  6. Dont try to "protect your success"
  7. Steve Jobs says "interaction = innovation"
  8. Encourage inter-disciplinary learning
  9. Get rid of weak links
  10. Making $$ can't be your focus
Många bra punkter. I mitt team har jag jagat efter punkt 2, 4 och 5 ganska hårt. Det jag verkligen skulle behöva gå efter nu 3 och 9.

- DNPL

Sätt upp mål tidigt i ditt projekt!

GoalsVi har precis avslutat en iteration på projektet jag leder just nu efter 10 veckors utveckling. Det blev en mycket bra release som jag kände levererade vad den skulle. Dock känner jag att jag skulle varit hårdare i begränsandet av features som mina team chefer ville få in. Vi tog helt klart på oss för många features och jag var tvungent att skära i dem rätt hårt efter sex veckor. Det skapade en del stress och mindre bra situationer. Jag tror att man kan leverera projekt utan att behöva ta till med övertid!

Nu i efterhand känns det som om jag inte var tillräckligt hård från början. Det är en jobbig balans att vilja leverera "allt" och bara "good enonugh" som gör att man kommer i mål. Dock anser jag att om man kan leverera färre antal features har man mycket större möjlighet att polera resultatet. I min branch handlar stor del av hur produkten upplevs och kvalitet har därmed mycket att säga till om.

Varför lyckades det smita in nya funktioner och händelser i produkten under utvecklingen?
  • Vi driver projekten agilt - dvs vi omfamnar förändring och itererande. Detta är ett helt ämne i sig själv som jag sparar till en annan gång...
  • Dålig eller otillräcklig ursprungsvision av projektet. Mycket av projektet fanns "i huvudet" på min chefsdesigner. Jag borde ha tryckt på starkare att han skulle ta fram visionen tidigare och presenterat det för vårt team.
  • Inga projektmål nedskrivna vid start av projektet. När jag fick projektet från mina chefer var det i still med: "Vi vill att du tar fram ungefär detta och detta, men kanske inte så mycket av detta"... jag trodde att vi var synkade och trodde inte det skulle vara några som helst problem. Efter ett par veckor in i projektet när jag presenterade våra framsteg kom det fram att min chef ändrat sig. Tack vare eller för modligen på grund av att vi inte tagit tid vid start och formulerat projekmål var det omöjligt att säga att vi fått andra direktiv. Bara att bita i det sura äpplet och försöka hinna med att korrigera projektet. Detta skapade en hel del nya och oplanerade features i ett sent skede.

Slutledning:
  • Var hård. Sätt tidiga gränser och se till att dom efterlevs. Det är projektledaren som i slutändan ansvarar för att projektet blir genomfört i tid och på budget!
  • Skriv ned projektmålen vid start, se till att samtliga projektintressenter får ta del av dem och tidigt påpeka om någonting inte stämmer eller uppfattas annorlunda.

Well... fortsättning följer...

- DNPL

Hello world

Jaha då skall vi se. Skapa konto, gett namn på bloggen och sedan vips. Nu är vi igång. Ändra lite inställningar. Testa olika teman (oj vad få färdiga teman det fanns) och nu första inlägget.

När jag fått lite kläm på detta bloggandet kommer jag att ägna mig åt det jag egentligen vill få utlopp för på denna bloggen. Vilket är att skriva om mina erfarenheter som projektledare - ny projektledare. Jag hoppas att även om jag kommer harkla ur mig en hel del idiotiska inlägg att det även kommer en och annan guldklimp som någon någonstans kommer att ha nytta av i en ledarskapsroll.

För säkerhetsskull vill jag påpeka redan här och nu i första inlägget att jag inte anser mig själv vara en stjärna inom ämnet - men - att jag ämnar att bli någon gång i framtiden, helst före jag fyller 40 eller i alla fall 50.

På återseende.

.DNPL

(Den Nya Projektledaren)

Välkommen till min nya blogg!


RSS 2.0