Introduktion
Gennem årene har jeg i mit arbejde inden for IT og især inden for IT-salg set mange pilotprojekter, men de fleste af dem endte uden resultater på trods af betydelige tidsomkostninger.
Når vi taler om test af hardwareløsninger, som for eksempel SAN, er der ofte en ventetid på næsten et år for hver demo-system. Hver test i tidsplanen kan føre til et salg eller, omvendt, ødelægge et salg. Det giver ingen mening at overveje en situation, hvor testen ikke påvirker salget, da testen selv heller ikke giver mening — det er en spildt investering af tid og optager ressourcer fra demo-systemet.
Så hvordan kan vi gøre det ordentligt, så alt rent faktisk sker?
Forberedelse
Pilotmål
Hvor begynder en pilot? Ikke med at tilslutte udstyr i rack'et, slet ikke. Før vi begynder at arbejde med udstyret, er der et arbejde med dokumenterne. Og vi starter med at definere pilotens mål.
Pilotens mål er at afhjælpe indvendinger fra den endelige kunde. Ingen indvendinger — ingen pilot. Ja, netop så enkelt.
Men hvilke hovedklasser af indvendinger kan vi se?
* Vi tvivler på pålideligheden
* Vi tvivler på ydeevnen
* Vi tvivler på skalerbarheden
* Vi tvivler på kompatibiliteten og evnen til at arbejde med vores systemer
* Vi tror ikke på jeres slides og vil sikre os, at jeres system rent faktisk kan det, I siger
* Alt dette bliver meget svært; vores ingeniører er allerede belastede og vil finde det vanskeligt
I sidste ende får vi tre grundlæggende typer af pilot-testning og, som et særtilfælde af piloten, proof of concept (PoC):
* Belastningstest (+ skalerbarhed)
* Funktionel test
* Test af fejltolerance
I det konkrete tilfælde, afhængigt af de specifikke kunders tvivl, kan pilotens mål kombineres, eller der kan kun være ét af dem.
Piloten begynder med et dokument, der beskriver på klart dansk – hvorfor denne testning udføres. Derudover skal der obligatorisk inkluderes et sæt målbare kriterier, som entydigt kan fastslå – om piloten er gennemført med succes eller hvad der specifikt ikke er bestået. Målbare kriterier kan være numeriske (som for eksempel forsinkelse i ms, IOPS) eller binære (ja/nej). Hvis der i din pilot er en umålelig størrelse som kriterium – så giver piloten ingen mening, det er udelukkende et værktøj til manipulation.
Udstyr
Piloten kan gennemføres på demoudstyr fra leverandøren/distributøren/partneren eller på kundens udstyr. Strengt taget er forskellen lille, den overordnede tilgang er den samme.
Hovedspørgsmålet om udstyret FØR piloten – er der et komplet udstyrssetup til stede (inklusiv switches, datatransmissionskabler, strømkabler)? Er udstyret klar til testning (de rette firmware-versioner, alt er under support, alle lamper er grønne)?
Den rigtige rækkefølge af handlinger efter fastlæggelse af testformålene – fuld klargøring af udstyret til testning FØR det overdrages til kunden. Selvfølgelig er der loyale kunder uden hastværk, men det er snarere undtagelsen. Det vil sige, at det komplette udstyr skal være samlet på partnerens site, alt skal kontrolleres og samles. Systemet skal absolut være startet, og du skal sikre dig, at alt fungerer, softwaren kører uden fejl, osv. Det kunne virke enkelt, men 3 ud af 4 piloter starter med at lede efter kabler eller SFP-transceivere.
Det skal understreges, at du under kontrollen af demomaskinen skal sikre dig dens renhed. Alle data fra tidligere test skal udelukkende være slettet fra systemet før overdragelsen. Det er ikke usandsynligt, at der er blevet udført test med virkelige data, og der kan være alt muligt, herunder forretningshemmeligheder og personlige oplysninger.
Testprogram
Før udstyret overdrages til kunden, skal der obligatorisk være udarbejdet et testprogram, der svarer til testformålene. Hver test skal have et målbart resultat og klare succeskriterier.
Testprogrammet kan udarbejdes af leverandøren, partneren, kunden eller sammen – men det skal nødvendigvis ske FØR testene påbegyndes. Og kunden skal nødvendigvis underskrive, at denne program er tilfredsstillende for ham.
Mennesker
I forbindelse med forberedelsen til piloten skal datoerne for gennemførelsen af piloten og tilstedeværelsen af alle nødvendige personer samt deres parathed til testning aftales, både fra leverandørens/partnerens side og fra kundens side. Åh, hvor mange piloter er begyndt med, at den primære person i piloten hos kunden tog på ferie dagen efter installationen af udstyret!
Ansvarsområder/adgang
I pilotprogrammet skal ansvarsområderne for alle involverede parter være klart defineret og ideelt set beskrevet. Hvis nødvendigt, skal der være aftalt fjern- eller fysisk adgang for leverandørens/partnerens ingeniører til kundens systemer og data med kundens sikkerhedstjeneste.
Pilot
Hvis vi har gennemført alle de tidligere punkter, så er den mest kedelige del – selve piloten. Men den skal forløbe som smurt. Hvis ikke, så betyder det, at der var noget galt i forberedelsesfasen.
Afslutning af piloten
Ved afslutningen af piloten udarbejdes et dokument om den udførte test. Ideelt set med alle testene i programmet markeret med en grøn flueben som Gennemført. Det kan være nødvendigt at udarbejde en præsentation til ledelsen for at træffe en positiv beslutning om køb eller optagelse på listen over godkendte indkøbssystemer.
Hvis du ikke har et dokument med en liste over gennemførte test og markeringer for bestået ved slutningen af piloten – så er piloten mislykket, og det skulle slet ikke have været startet.
Kilde: habr.com
