georg strøm bloghoved

Hvad skal vi lære unge om at gennemføre IT projekter?

Jeg har en klasse hvor omkring halvdelen gerne vil have en IT-karriere. Det er på et teknisk gymnasium, hvor et af mine fag er teknologi, det vil sige produktudvikling. Eleverne har IT-fag, hvor de lærer om det tekniske. Mit fag handler om at komme frem til et produkt som kan produceres og leveres, og som kunderne eller brugerne bliver glade for.

Det er en kæmpefordel, hvis de kan lære om processen og hvad de skal gøre, flere år før de ellers ville lære om udvikling af IT i en videregående uddannelse. De kan endda lave nogle produkter som kommer ud, før de slutter med gymnasiet.

Jeg har nogle spørgsmål om, hvad det er vigtigt for dem at lave og lære, på de 300 skematimer og 100 timer de har til hjemmeopgaver. Her er hvad jeg selv tænker.

En væsentlig del handler om personas og samtaler med brugere om de problemer som de oplever, og de situationer hvor de skal bruge applikationen. Altså om at finde ud af, hvad brugerne helt konkret savner en løsning på.

En anden indgang er baseret på forskning. Det kan være indenfor naturvidenskab, psykologi eller andet, som fører til nye produkter. Jeg har nogle elever som undersøgte, hvordan det var muligt at lave et spil, der kunne lære unge at nedtrappe konfrontationer. Det kræver studier af den relevante psykologiske forskning. Det er almindeligt at fysiske opfindelser er baseret på videnskabelig viden, men det er ikke så almindeligt for software.

Problemet i gymnasiet er, at eleverne rent teknisk er langt fra at kunne realisere deres visioner. Derfor har jeg kørt projekter, hvor de fik besked på at de ikke skulle tage hensyn til om de selv kunne implementere projektet. Ellers ville de være stærkt begrænsede. Det kan til gengæld give dem en lidt overfladisk holdning til om en software kan realiseres eller ej.

Jeg har taget fat på æstetik i min undervisning i udvikling af software, selvom æstetik er noget med kunst, mens software er noget du kan tjene penge på.

Der er behovet for test, enten brugertest eller andre test, som kan sige noget om, hvor godt produktet vil fungere i praksis. Til gengæld har jeg ikke taget fat på mulige undskyldninger, når det viser sig at softwaren ikke kan bruges.

Endelig er der min personlige holdning. De fleste danske haver i japansk stil er kedelige. Det skyldes, at de er inspireret af japanske haver i Japan, mens haverne i Japan er inspireret af naturen. Det er svært at lave god IT uden en forankring i den fysiske virkelighed. Gode IT-folk har brug for en eller anden form for almen dannelse, men hvilken?

Mit spørgsmål er: Hvad er det en god ide at unge lærer før de starter på en IT-uddannelse? Hvilke konkrete punkter skal jeg tage fat på, ud over at kold pizza er totalt acceptabelt som morgenmad, bare de samtidig får noget varm kaffe?

Altså hvad vil læserne med en solid erfaring i udvikling af software og arbejde med IT godt have at eleverne lærer af metoder og holdninger?

Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Klaus Kolle

Som underviser på en ingeniørhøjskole glæder det mig meget at du tager fat på at få defineret produktet - sådan opfatter jeg det du skriver. Det oplever jeg ofte er et stort problem. Så nogle gode arbejdsmetoder til at bryde et uoverskueligt problem ned i forståelige bidder er velkommen.

Man kunne jo også tage fat i BeagleBone Black og/eller Raspberry Pi, som er overkommelige platforme at komme i gang med. Der er nogle venlige programmeringssprog, som jeg er sikker på at det meget hurtigt lærer at beherske. Så må vi evt. pille lidt unoder af dem senere. De vil give dem en mulighed for at afprøve koncepter, som de har fundet i undersøgelsen af problemet. Det er min erfaring af de dimplomingeniørstuderende vi har med at gøre meget gerne vil omsætte "luftige" tanker til virkelighed.

Vi har et par år afholdt en RoboticHackathon for gymnasieelever med ret stor succes. Selv om de ankommer med noget nær nul erfaring i at bygge mekanik, elektronik og programmere får de - med passende hjælp fra nogle 1. og 2. års studerende (og et par af os gamle) på 24 timer skabt en robot, som kan gennemføre den opstillede bane. De programmerer i C/C++ forholdsvist let efter nogle korte introduktioner; de styrer servoer, motorer og aflæser sensorer ganske fint.

Så hæld bare på i alle ender af spektret - problemidentifikation, systems engineering, prototyper, elektronik, servoer, motorer og programmering af enkelte dele osv. Der er masser af muligheder.

  • 2
  • 1
Thomas Paaske Højgaard

Det er rigtig positivt hvis du kan lærer dem noget om hvordan man finder ud af hvad kunden i virkeligheden har brug for i stedet for bare at lave præcis det kunden bestiller.

Samt noget om at arbejde agilt da verden som regel forandrer sig efterhånden som alle omkring et projekt bliver klogere.

Endelig at der som regel er brug for forskellige roller i et IT projekt. Nogle skal være rigtig gode til at kommunikerer for at komme frem til den gode løsning og andre skal måske mere hardcore ned i tekniske problemstillinger.

  • 0
  • 0
Torben Mogensen Blogger

En vigtig pointe er også, at omfanget af nødvendig styring af et projekt vokser mere end lineært i projektets størrelse (målt i antal mandår), i en sådan grad, at meget store projekter har brug for mere styring end egentligt produktionsarbejde, men at dette heller ikke er uden problemer, fordi et stort antal mennesker i styringsprocessen kan mindske effektiviteten af denne.

  • 1
  • 0
Martin Kirk

Teknisk Gymnasium = HTX ??

Nu er det godt nok 12 år siden jeg selv gik ud af HTX, men som jeg husker niveauet, så er eleverne begyndere i programmering, dvs de ikke engang ved hvad Strings, Arrays, Double og Integers går ud på, ej heller For-loops, Async, Classes osv osv..

Da jeg gik på HTX gik jeg igang med at lære VBScript, Microsoft Access / SQL, VisualBasic og lavede små programmer og scriptede hjemmesider.

Hvis formålet er at eleverne skal blive gode til at kode - hvilket er hvad virksomheder har brug for, så vil jeg foreslå at bistå eleverne i at udvikle et af deres hobby projekter. Bare det at have en mentor og sparingspartner er guld værd..

Jeg var selv overladt til mig selv og måtte bruge Eksperten.dk for at blive klogere... Men det var først da jeg kom på DTU at jeg lærte principperne i programmering. Det tog dog et år som programmør at blive god til at lave programmer/hjemmesider.

Når det kommer til selve projekteringen / ideskabelsen, så lærte jeg ingenting på HTX - der var ingen af lærene som var i stand til at forklare hvad et projekt gik ud på eller hvordan man kom igang. Der var heller ingen der var i stand til at forklare på en forståelig måde hvordan en projekt rapport skulle se ud, for alle lærene var uenige om formen og indholdet... totalt cirkus.

Hvis jeg selv skulle oplære en klasse, ville jeg nok starte med at få de basale kundskaber på plads, "hello world" osv. hvilket nok tager de første 50-100 timer.

step 2 må være at lære dem SCRUM eller lign iterativ process, opbyg nogle små hold som består af en designer, manager og codemonkeys.

step 3 (afslutnings projekt) - kunne så være at de producere et-eller-andet valgfrit eller afgrænset. hvis de har en god ide, så lad dem tage den, ellers har du noget de kan gå igang med fx. en hjemmeside, et spil etc.

  • 0
  • 0
Allan Ebdrup Blogger

Lære at stille spørgsmålet hvorfor? Fristende at kaste sig ud i kodning inden forretningens behov er afklarede. De bedste IT projekter er nok dem der blev aflyst fordi behovene ikke stod mål med udgifterne.

Meget enig. Jeg tænker det ville være oplagt at kaste nogle curveballs i løbet af uddannelsen.

1) Skrive en overordnet specifikation af et system de skal bygge, der i virkeligheden er alt for kompliceret. Fx noget med at generere print i en arbejdsgang der kan klares 100% digitalt, el. lignende. Og så se om de stiller spørgsmålet Hvorfor

2) Bestille et specialudviklet system, der kan løses meget bedre og billigere med et eksisterende SaaS system, i stedet for at bygge det selv.

3) Bestille et lille specialudviklet system, der i virkeligheden kan implementeres med 20 linjers bash script. Eller på anden måde kan løses meget nemt ved at bruge noget eksisterende.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det vigtigste de skal kunne er at sige nej.

Nej til idiotiske ideer.

Nej til overkomplexe systemer.

Nej til urimeligt store specifikationer.

Nej til urealistiske tidsplaner.

Nej til at teste senere

Nej til at sikkerhed kigger vi på senere

Nej til at gå på kompromis med kvaliteten

  • 4
  • 0
Bo Victor Thomsen

Amen til det -

Og så venter vi 10 - 15 år, indtil de har erstattet de primus-motor-personer i det offentlige, som har bestilt og "gennemført" Amanda, Polsag, ProAsk og andre Titanic-lignende projekter i det offentlige.

Min egne 10 øre: Hav fokus på de grundliggende data og sammenhængen/tilgangen/snitfladen til disse - Hvis det er i orden kan du oftest udskifte brugerfladen til noget, der lugter mindre dårligt.

  • 0
  • 0
Troels Henriksen

Nej til overkomplexe systemer.

Dette er det bedste råd. Hvis en total decentraliseret anarkisk gruppe kan lave fungerende programmel, som det sker indenfor open source-verdenen, så bør man måske se på hvad de gør. Så vidt jeg kan se handler det mest om iterativ udvikling og løs kobling (med følgende enkle komponenter). Det er lidt en nødvendighed når ingen kan planlægge på andres vegne og ingen kan definere det overordnede design, men det virker åbenbart i praksis.

  • 0
  • 0
Jesper Louis Andersen

Softwareprojekter er umådeligt komplekse fordi de opererer i en verden de ikke passer ind i. Computere kan beregne ting meget meget hurtigt, men de kan kun udføre deres beregninger hvis du kan komme på en række regler de kan overholde. At forstå hvornår du skal have mennesket-ind-i-beslutningsprocessen er ekstremt vigtigt. Projekter fejler ofte fordi der er en vision om at mennesket kan erstattes med maskinen for et problem hvor dette overhovedet ikke kan lade sig gøre, eller uden at nogen har gjort sig et begreb om hvilke regler maskinen skal udføre.

Typiske projekter har visse virkelighedsbegrænsninger:

  • Penge
  • Tid
  • Teknisk abstraktion (Vi ved hvad vi vil have, men aner ikke hvordan vi skal beregne det)
  • Teknisk kompleksitet (Vi kan sagtens beregne vores problem, men der er mange små delkomponenter og vi kan ikke overskue deres sammensætning/sammenhæng)
  • Kravspecifikation (Vi ved end ikke hvad vi vil have løst!)
  • Kvalitet (Hvad er prisen for en fejl?)

Projekter navigerer i dette farvand af begrænsninger. Grundet penge og tid slækkes der på f.eks. test hvilket betyder kvalitetstab. Eller også er problemet ikke forstået ordentligt, hvilket gør at enhver løsning vil være utilstrækkelig.

Hvis jeg skulle pege på noget, så går det i tråd med Poul-Henning. Ofte går væsentlig information tabt i kommunikation mellem forskellige led i projektet. Man sidder i et møde og aftaler en løsning. Alle går derfra med en god forståelse, tror de. Men i praksis er opfattelsen af problemets omfang overhovedet ikke i balance forskellige interessenter imellem. Derfor er det vigtigt at man dels kan sige nej, dels kan spørge "dumt" indtil det bliver klart hvilket omfang problemet har.

Man skal være sikker på at alle har den samme opfattelse af projektet, og man skal være parat til at ændre sin viden, så snart det opdages at man ikke havde balance i hvad man laver.

Derfor er "nej" et vigtigt værktøj. Barber så meget som muligt væk, diskuter det tilbageværende der har substans. Det handler ikke om at løse problemer, men om at løse dem der har effekt.

  • 0
  • 0
Torben Mogensen Blogger

Et udmærket motto er "Deadline, price, specifications: Pick any two".

Pointen er, at det er urealistisk at lave et (større) projekt til fast pris og deadline og med faste specifikationer. Mindst en af de tre ting vil skride.

  • 2
  • 0
Georg Strøm Blogger

Der er nogle gode punkter, som jeg selv og mine kolleger godt kan bruge i undervisningen. Jeg kan ikke gå gennem dem alle, så her er mit sammendrag af, hvad jeg synes er specielt vigtigt.

I modsætning til elever på STX, har mine elever et IT-fag hvor de lærer om programmering og udvikling af software. Enkelte kan endda nå frem til produkter på et niveau som er kommercielt interessante. I betragtning af den tid der er til rådighed, er det område nogenlunde dækket.

Indenfor mit eget fag - teknologi - er der flere punkter som jeg kan se skal styrkes. Faget handler mere generelt om produktudvikling - og en del af problemerne her findes også i andet end IT-projekter.

Eleverne skal lære at tage udgangspunkt i kundernes eller brugernes aktuelle behov - det er en af mine egne kæpheste. Problemet er at det tager tid at arrangere interview med kunder, og at der ofte er tidspres i projekterne.

Eleverne skal lære at arbejde iterativt med produktudvikling. En stor del af den produktudvikling de kan komme til at lave vil være iterativt. Enten planlagt eller ufrivilligt, når der bliver ved at komme nye fejl i et faseopdelt projekt.

Eleverne skal lære om hvordan projekter foregår i praksis og hvad der ofte går galt. De skal være klar over, at lærebøgernes beskrivelser ofte er et ideal, mens der i den virkelige verden er problemer med forsinkelser, dele som ikke fungerer som planlagt, eller løsninger som ikke passer til problemet. De skal lære at det ikke bare er noget de kan opleve i skolen, men noget de skal lære at håndtere i en fremtidig karriere.

  • 0
  • 0
Log ind eller Opret konto for at kommentere