Motstridiga krav ställer till det för Firefox 3

En användbarhetsexpert konstaterar i dagens tidning att Firefox har ställt till det för sig när man stoppar accessen till websiter med felaktiga certifikat. Detta är ett klassiskt exempel på motstridiga krav (användbarhet vs säkerhet) och jag är inte förvånad att just användbarhetskraven står i ena ringhörnan…

Tyvärr går ofta användbarheten stick i stäv med de flesta icke-funktionalla kravtyperna såsom säkerhet, prestanda och budget.

Vad kan man då göra för att hantera denna typ av konflikter mellan krav? Inte mycket, tyvärr… Det är dock viktigt att man ställer kraven mot varandra och prioriterar mellan dem så att det åtminstone är ett genomtänkt beslut att offra t.ex. prestanda till förmån för användbarhet. En annan sak man kan göra är att man kan komplettera med krav på felhanteringen och information till användarna. Tydligen använder Firefox följande felmeddelande: ”Error code: ssl_error_bad_cert_domain”. Kanske inte den mest pedagogiska formuleringen… Ett tredje alternativ är att göra systemet konfigurerbart och ge användarna möjlighet att välja; hög eller låg säkerhet, van eller ovan användare. Tyvärr leder detta alternativ ofta till system som är mer komplexa och tar längre tid att utveckla.

Läs mer på http://computersweden.idg.se/2.2683/1.176655

Agil kravhantering borde heta situationsanpassad kravhantering

I samband med artikeln jag nämnde i mitt föregående inlägg så skriver man också om ”agil kravhantering”. Jag hör allt oftare det presenteras som lösningen på alla kravhanteringens problem. Ofta menar man med detta ett arbetssätt med mindre fokus på textdokument och mer fokus på kontinuerlig dialog mellan utvecklare och kravställare.

Jag är helt med på att det är ett effektivt sätt att arbeta på. Jag tycker dock inte att man skall se det som det enda tänkbara sättet att arbeta med krav på. Olika arbetssätt fungerar olika bra i olika sammanhang.

Jag har t.ex. arbetat med traditionella kravdokument i försvarsmakten, som upphandlingsunderlag och i projekt där vi inte haft möjlighet till dagliga möten med kravställarna. I dessa fall har det fungerat väldigt bra. I andra fall har jag kunnat sitta i samma rum som såväl beställare och utvecklare. Då blir kravarbetet väldigt annorlunda… Roligare? Absolut! Mer effektivt? Inte helt säker! Mindre effektivt? Absolut inte!

Agil kravhantering handlar därför i mina ögon inte om att minska antalet dokument utan om att anpassa medlen till förutsättningarna. Situationsanpassad kravhantering med andra ord.

En tredjedel av alla utvecklingsprojekt avbryts i förtid

I dagens computer sweden finns det en artikel där man konstaterar dålig kravhantering kostar 100-tals miljoner bokstavligen slängs bort varje år, bara i Sverige! Jag är lite osäker på varifrån man fått den siffran men man skriver även om en ny undersökning av det amerikanska konsultföretaget Voke där man kommit fram till att mindre än två tredjedelar av alla projekt slutförs och att endast 37 procent av projekten uppfyller behoven. 125 affärsutvecklare deltog i undersökningen, av dessa arbetade drygt hälften på företag med minst 5 000 anställda.

Ungefär samma resultat som i alla andra undersökningar som publicerats de senaste 15 åren med andra ord…

Läs artikeln på http://computersweden.idg.se/2.2683/1.176420

Recension av Brandväggar av Matthew Strebe

Språk: Teknisk svenska

Förkunskaper: Goda kunskaper i nätverskteknik
Antal sidor: 540
Kategori: Systemadministration, säkerhet
Målgrupp: Systemadministratöre

Jag har på senare tid blivit alltmer orolig för mitt hemmanätverk i allmänhet och framför allt huruvida min brandvägg är konfigurerad på ett bra sätt. För att få lite djupare kunskaper om detta så har jag läst denna bok. Tyvärr är den alldeles för avancerad för mig. Personerna som har skrivit boken började som ”hackers” i USA på mitten av 80-talet och arbetar idag som säkerhetskonsulter. De kan onekligen sitt område och boken innehåller också en hel del information för nätverksadministratörer på företag. Tyvärr hjälpte det inte mig…

Recension av ”Att läsa och förstå bokslut” av Nancy Holmström

Språk: Lättläst svenska

Förkunskaper: Inga
Antal sidor: 230
Kategori: Redovisning
Målgrupp: Egna företagare

Boken består av tre delar;

  1. Lagstiftning
  2. Analys
  3. Värdering

Lagstiftningsdelen innehåller grundläggande information om vad ett bokslut är för något, vilka som måste göra det, vad det måste innehålla, vad menas med god redovisningssed m.m. Inte speciellt mycket som de flesta egna företagare inte redan känner till, men i alla fall en bra repetition. Framförallt är det också bra att ha all denna information samlad på ett ställe.

Analysdelen är den del som gör boken läsvärd för mig.
Den innehåller följande delar

  1. Läsanvisningar för den ovane
  2. Resultatanalys
  3. Lönsamhetsanalys
  4. Kapitalanalys
  5. Kostnads- och intäktsanalys
  6. Tillgångs- och skuldanalys
  7. Tillväxt- och förändringsanalys
  8. Icke-finansiell analys

Varje del ovan innehåller exempel och definitioner av nyckeltal inom respektive område. Mycket bra för den ovane (som mig). Den icke-finansiella delen innehåller nyckeltal för företagets mjuka värden.

Bokens avslutande del – Värdering, var inte så intressant för mig i dagsläget då den innehåller information om hur man kan värdera ett företag man vill köpa eller sälja. Kanske får jag dock nytta av den kunskapen också en vacker dag.

Recension av user stories applied av Mike Cohn

Språk: Lättläst engelska
Förkunskaper: Inga
Antal sidor: 268
Kategori: Krav, projektledning, utvecklingsmetodik
Målgrupp: kravställare, utvecklare, projektledare

Recension
Mike Cohn är en erfaren utvecklare som med tiden gått över mer och mer mot projektledning och metodik. Han var bl.a. med och tog fram ”the agile manifesto” och har även skrivit ”agile planning and estimation”. Cohn skriver konkret, lättläst och rakt på sak. Denna bok innehåller många handfasta råd. User stories är en teknik för att fånga krav och engagera kravställare på och har blivit ett vedertaget sätt att arbeta med krav i agila systemutvecklingsprojekt. Cohn argumenterar såväl för som mot user stories och även andra kravtekniker. User stories jämförs med användningsfall, användbarhetsvärldens scenarios (ej att förväxla med användningsfalls-scenarios) och IEEE’s standard för krav. Enkelt uttryckt kan user stories sägas vara små användnings¬fall där man medvetet utelämnar detaljer för att tvinga fram en öga mot öga-diskussion mellan utvecklare och kravställare. En viktig poäng med user stories-tänket är just att de inte skall innehålla alla detaljer utan skall istället fungera som underlag för diskussioner mellan kravställare och utvecklare. I grund och botten är de heller inte tänkta att förvaltas efter projektet, eftersom kraven med stor sannolikhet ändå då kommer att ha förändrats.
Cohn har stor erfarenhet av såväl extreme programming som scrum och beskriver med denna bok hur kravhantering i ett sådant projekt kan gå till. Boken är dock så välskriven och riktlinjerna så bra att man kan ta till sig stora delar av detta angreppssätt i alla projekt där man löper risken att kraven kan förändras (och vilket projekt gör inte det…) oavsett om man använder sig av traditionella kravlistor, användningsfall eller någon annan kravteknik.

Del 1: user stories (85 sidor)
Cohn går igenom grunderna till vad user stories är, hur man hittar och beskriver dem samt ger praktiska tips för hur man säkrar att en story får ”rätt” storlek. Avsnittet innehåller också en matnyttig del om modellering av användarroller.

Del 2: tidsuppskattning och planering (46 sidor)
Detta avsnitt kan sägas vara en sammanfattning av Cohns andra bok; agile planning and estimation. Cohn går igenom hur man kan använda sig av user stories som underlag för projektets tidsupp¬skatt-ning (i form av story points). Planeringspoker är en teknik för tidsuppskattning som dels involverar hela projektgruppen dels ofta ger ett bra resultat. Cohn går också igenom release- och iterations-planering utifrån user stories. Denna planering görs strikt enligt kundens prioritering. Avslutningsvis går Cohn också igenom begreppet velocity och varför det är så viktigt för en projektledare samt presenterar några olika sätt att följa upp projektet på.

Del 3: Vanliga frågor (60 sidor)
Det märks att Cohn har mycket erfarenhet eftersom han i denna del av boken diskuterar många av de problem som de flesta av oss ofta får kravarbete i allmänhet (som t.ex. får stora krav, beroenden mellan krav, för mycket detaljer i kravspecen och för tidig inblandning av användargränssnittet samt kunder som inte vill skriva ned och prioritera kraven. Cohn lägger också fram många genomtänkta argument för ”user stories”, argument som borde kunna användas för att övertyga även den mest motsträviga kvalitetsansvarige.

Del 4: Exempelprojekt (40 sidor)
Cohn presenterar ett projekt som skall ta fram en jobbsökar-site och börjar med att modellera användarroller för att sedan gå vidare med user stories. Ett antal stories presenteras i ett antal olika bearbetningar, från deras initiala utformning till den slutgiltiga implementerade versionen. Kapitlet ger en bra förståelse dels för hur man arbetar med stories, dels för hur pass detaljerade de bör vara.

Appendix: (37 sidor)
På bara 37 sidor hinner Cohn inte bara sammanfatta eXtreme Programmings 12 principer utan också dess grundläggande filosofi

Recension av användbarhetsboken av Tommy Sundström

Språk: Lättläst svenska

Förkunskaper: Inga
Antal sidor: 450
Kategori: Användbarhet, Krav, utvecklingsmetodik
Målgrupp: kravställare, utvecklare, projektledare

Boken är skriven rakt på sak, inget onödigt trams utan nästan enbart hårda fakta och riktlinjer för användbarhet. Den är uppdelad i 8 delar;

  1. om användarorientering i utvecklingsprojektet,
  2. se (om grafisk design),
  3. läsa (om språket),
  4. hitta (om informationsdesign),
  5. använda (om interaktionsdesign),
  6. förtroende
  7. tillgänglighet
  8. praktikfall – e-handel

Varje del innehåller ett antal konkreta och handfasta råd som är kategoriserade som skall, bör eller tips. Till varje råd finns också en förklaring/bakgrund.

Exempel på ett råd är

Avståndet mellan punkter skall vara större än radavståndet
Skall
I punktlistor skall det vara större avstånd mellan punkterna än mellan raderna. Detta för att göra det lättare för ögat att se vad som är en ny punkt och vad som bara är texten till en punkt som råkat bli lång nog att delas av på flera ställen.

Varje råd taget för sig kanske inte är speciellt revolutionerande men boken i sin helhet innehåller otroligt mycket kunskap och erfarenhet. Den bör läsas av alla webbdesigners.

Semesterlitteratur

Äntligen semester. Visst, jag har varit ”barnledig” sedan i januari men jag förstår inte varför de kallar det för barnledighet. Det borde snarare heta barnarbete, men det är väl inte politiskt korrekt…

Jag förstår heller inte varför det inte ses som en större merit på arbetsmarknaden, att ha varit barnledig, än vad det gör. Personligen så tror jag att många som kallar sig för projektledare i arbetslivet skulle uppleva det som körigt att få ihop livet som föräldraledig (jag vet att jag så har varit fallet för mig…).

I mina ögon kommer i framtiden alltid den konsult som varit föräldraledig att ha företräde framför den som inte varit det (allt annat lika givetvis, plus att föräldraledigheten inte tagits ut under fotbolls-VM eller OS förstås.)

Nog om det, nu är jag i alla fall på västkusten tillsammans med familjen och äntligen hoppas jag få lite tid att läsa de böcker som jag inte hunnit med under våren.

  • The silent takeover – Global capitalism and the death of democracy av Noreena Hertz
  • Marknadsföringens 10 dödssynder av Philip Kotler
  • Software project secrets – Why software projects fail av George Stepanek
  • EQ på svenska av Bodil Wennberg
  • Karismakoden av Eva Kihlström
  • Ditt personliga varumärke av Isabel Werner Runebjörk
  • Användbarhetsboken av Tommy Sundström
  • Freakonomics av Steven D Levitt
  • Brandväggar av Matthew Strebe
  • Att läsa och förstå bokslut av Nancy Holmström

Kvinnliga anställningsvillkor – finns det?

Jag anser mig vara en relativt jämlik person. Givetvis så dras jag, i likhet med alla andra män med den manliga arvssynden som gör det svårt att alltid se saker och ting ur kvinnors perspektiv. Å andra sidan så tvingas ju alla kvinnor att släpa på den kvinnliga arvssynden som ger dem samma problem (eller är det det motsatta problemet, att inte alltid kunna se saker och ting ur en mans perspektiv?).

När vi diskuterar anställningsvillkor och förmåner m.m. på Systemvaruhuset har det därför varit en självklarhet att hitta könsneutrala sådana. Till min förvåning har man nu viskat i mitt öra att vissa av våra förmåner är väldigt attraktiva för kvinnor. Ett exempel på en sådan är att vi toppar upp föräldraförsäkringen ovanför lönetaket. Detta har vi gjort för att vi ser det som viktigt för alla att kunna vara hemma med barnen. Vi har också principen att enbart arbeta övertid i extrema undantagsfall och tillåter vår personal att själva välja arbetstider så länge som inte arbetet blir lidande. Ovanstående har vi gjort, inte för att premiera kvinnor, utan för att vi tycker att de är självklarheter för en bra arbetsgivare.

I likhet med många andra IT-konsulter är vi mansdominerade (d.v.s. majoriteten av vår personal är män) men skulle gärna bli fler kvinnor. Ett sätt att bli det på är kanske att identifiera ”kvinliga anställningsvillkor” och erbjuda dessa. Kan någon ge mig ett exempel på ett ”kvinnligt anställningsvillkor”, snälla!

Corporate social responsibility – marknadsföring eller allvar?

På Systemvaruhuset har vi visionen att revolutionera IT-branschen i grunden, men vi är inte beredda att gå över lik för att göra det. Senare denna vecka skall vi i Styrelsen sätta oss ned och diskutera vår vision och målen för de kommande 3-5 åren. Som ett led i förberedelserna för det har jag börjat fundera igenom vad det är jag vill uppnå med Systemvaruhuset. Varför tyckte jag det var en bra idé att starta ett företag?

Efter lite funderande har jag kommit fram till att det var framförallt två faktorer som gjorde mitt beslut lätt; jag vill kunna påverka (min och andras) situation och jag vill bygga ett ”bra” företag. Med ”bra” menar jag ett ansvarstagande företag som inte drivs av kortsiktiga vinstintressen utan i det långa loppet bidrar till ett bättre samhälle.

Hur kan Systemvaruhuset göra det? Ett sätt är genom vår konsumption, genom att köpa miljömärkta varor m.m. så ökar vi efterfrågan på dessa. Ett annat sätt är genom att medvetandegöra vår personal och göra det möjligt för dem att göra samma val. Ett tredje sätt är genom aktiva insatser. Jag kanske aldrig kommer att ställa mig i Stadsmissionens soppkök och servera mat till hemlösa, men jag hoppas att jag en dag kommer att få tummen ur och faktiskt gå ned och göra det. Riktigt kul skulle det vara om hela företaget kunde göra det (det bygger dock på att alla andra skulle vilja det…)

Nåväl, åter till historien. När jag kom fram till ovanstående drivkrafter så fortsatte jag att fundera en stund och började leta förebilder. Kända, ansvarstagande, företag. Något förvånat gav jag nästan upp efter 10 minuter utan att ha kommit på ett enda! Jag fick ta till knepet att ropa ”kaffepaus!” på kontoret och fråga mina kollegor.

Efter lite diskussioner hittade vi ett antal mindre, nystartade företag som faktiskt kan göra anspråk på att vara ”goda” företag. Framförallt verkar klädindustrin ha kommit en bit på väg här. Varför är det så svårt att hitta stora företag som är ”goda”? Corporate social responsibility blir ju hetare och hetare som marknadsföringstrend! Är det kanske just det som är problemet, att det är en marknadsföringstrend. Är skiljelinjen mellan ”onda” och ”goda” företag så avgrundsdjup att det krävs en helt annan företagsstruktur för att vara ett ”gott” företag och i så fall; hur ser en sådan ut?