Vi har en tendens til at behandle ny teknologi som den hellige gral, en lysfyr og svaret på alt hvad der er langsomt, ineffektivt og gammelt. Og det kan være det - hvis det implementeres med en lastbilbelastning med planlægning og fremsyn.
Men vi ved alle, hvordan det går.
Under mine år i regeringen, hvor det undertiden føltes som om vi spillede et spil teknologisk indhentning, som umuligt var at vinde, lærte jeg, hvad der kan ske, når denne fremsyn tages for givet. Det ligner lidt den hellige gral og meget mere som omkostningsoverskridelser, forsinkelser og indviklede løsninger på ellers enkle problemer.
Som jeg lærte, er en af de vigtigste nøgler til et vellykket teknologiprojekt det harmoniske forhold mellem forretningsholdet og teknologiteamet. Efter min erfaring kørte forretningsteamet ofte ændringen (vi har brug for et mere komplekst system til at spore føderalt tilskudsudgifter, for eksempel), men vi kunne ikke opnå et smidigt fremskridt, uden at udviklerne og it-projektledere kunne klare det ske. Projekter endte ofte langt fra harmoniske, et resultat af i det væsentlige at tale forskellige sprog og opretholde meget forskellige forventninger (en ændring, der forekom mig mindre, for eksempel viste det sig ofte at være stor for udviklerne).
Men forretning og teknologi kan - og skal - være venner. Den gode nyhed? At opnå harmoni er virkelig ikke så kompliceret. Som ethvert samarbejde har det at gøre med frekvensen og kvaliteten af kommunikationen, et gensidigt aftalt mål og en plan til håndtering af den næsten uundgåelige ændring af disse mål. Her er et par grundlæggende retningslinjer for styring af kløften inden for forretningsteknologi.
1. Formålet med at negle kravene første gang
Tænk på forretningskrav som en plan. Du ville ikke tegne et tegnet sæt tegninger til et hus, levere dem til entreprenøren og ønske ham held og lykke. Du ville ikke komme tre uger tilbage i byggeriet og bede ham om at tilføje en tredje sal og et fjerde badeværelse og måske et karvindue i stuen. Og du ville bestemt ikke tegne dine tegninger uden input fra en arkitekt og en ingeniør.
Et teknologiprojekt er ikke så anderledes. Det skal designes med præcision, og når udviklingen først begynder, er det ikke altid let at rumme ændringer uden at påvirke hele fundamentet. Derfor er det vigtigt at være så omfattende som muligt fra starten og få det input og den ekspertise, du har brug for, når du tænker over, hvad løsningen vil kræve. Interview slutbrugere for at forstå de udfordringer, de står overfor, og nøjagtigt, hvordan de skal bruge den nye teknologi. Foretag ikke antagelser, og lad ikke dele af planlægningen ligge til senere.
2. Men erkender, at du vil savne nogle få
Når det er sagt, fandt jeg det næsten umuligt at se for mig hver eneste funktion, vi havde brug for i de abstrakte planlægningsstadier. Når systemet først var under udvikling, ville vi uundgåeligt indse, at vi glemte at bede om en avanceret søgefunktion eller en "Gem og fortsæt" -knap. Da vi henvendte os til udviklerne for at bede dem om at imødekomme disse nye anmodninger, blev vi ofte mødt med frustration. Måske vil den nye ændring kræve, at de fortryder det arbejde, de allerede havde gjort, og omarkitekterer dele af løsningen. Måske så vi os, at det skulle tage to timer, når det faktisk ville tage en dag.
Du er muligvis ikke i stand til at forhindre disse afsløringer senere i spillet, så det bedste, du kan gøre, er at opbygge en buffer for at rumme dem. Tilføj en ekstra uge til din oprindelige tidslinje og yderligere 5-10% til dit budget. Mange organisationer, der anerkender, hvor ofte forventningerne ændrer sig, har indtaget en smidig tilgang til udvikling og implementeret teknologi i faser for at muliggøre periodisk revurdering. Uanset hvad du tager, skal du ikke begå den fejl at tænke, at du har tænkt på alt fra get-go. Det sker næsten aldrig.
3. Know Scope Creep, når du ser det
Når projektet går videre og nye behov kommer frem, er det vigtigt at skelne mellem dem, du virkelig har brug for, og dem, du blot ønsker. At bede dine udviklere om at imødekomme hver klokke og fløjte, som sindet kan drømme om, fører typisk til uendelige projekter og alt for komplekse slutresultater. Hver ny anmodning, før den fremsendes, bør prioriteres.
Når du overvejer en funktion, skal du stille dig selv nogle grundlæggende spørgsmål: Vil systemet fungere uden det? Hvor lang tid vil det tage at gennemføre, og hvor meget fordel vil i sidste ende leveres til slutbrugeren? Hvis vi venter, indtil en fremtidig frigivelse til at tackle det, vil noget gå tabt? Det er en øvelse med prioritering, og alt kan tildeles en status som høj, medium eller lav. Hvis det er lavt, skal du lægge det på en figurativ parkeringsplads - jeg har hørt om virksomheder, der har "drømmeudviklingsanmodning" -dokumenter, som enhver kan tilføje ideer til, og ingeniørerne kan gennemse i deres fritid. Det kan altid revideres som en del af en række forbedringer, der skal foretages, når projektet er væk fra jorden og kører med succes.
4. Udvikle et fælles sprog
Ethvert nyt system har et sæt forretningsmæssige mål i kernen. Det giver dig mulighed for at fange flere data, strømline en eksisterende proces eller tilbyde nye tjenester til dine kunder. Det er kritisk, at forretningsholdet og teknologiteamet sætter sig ned, inden noget arbejde er påbegyndt og kommunikerer disse mål. De forretningsmæssige mål må ikke gå tabt i et hav af tech-talk, og de skal være fast i tankerne i hver fase af arbejdet.
At udvikle et fælles sprog betyder ikke kun kollektiv målsætning, men sporing af fremskridt på en måde, der fungerer for alle. Erhverv og teknologi kan bruge forskellige værktøjer til at måle deres arbejde, men der skal være mindst et syn på fremskridt, der deles. Dette kan være så simpelt som en projektplan eller et regneark med aftalte felter, som datoer og mål og procent afsluttet, så alle har adgang til status for hver opgave, der skal udføres. Målet er at undgå en situation, hvor forretningsteamet tror, de er halvvejs der, og tech-teamet siger, at de bare er et kvarter - alle skal have den samme forståelse af, hvad der er gjort, og hvad der er tilbage at gøre.
Du kan tale i forretningsplaner og PowerPoints, og de taler måske i kode, men medmindre du kommunikerer klart fra start, kommer du aldrig ud af Babel. Et vellykket teknologiprojekt handler om et sindsmøde - ikke bare i begyndelsen, men på hvert trin undervejs. Anerkend dine antagelser, og prøv ikke at lave for mange. Jo mindre skillet mellem forretning og teknologi er, jo lettere vil det være at krydse dine broer sammen.
