Video: Bea Lærer | SERVITØRYRKET 🤵🏼 (Oktober 2024)
Jeg har aldri møtt en delt nettverksstasjon i en virksomhet som ikke minst var litt slurvete. Delte servere er vanligvis designet for å muliggjøre samarbeid, samt gjøre filer og informasjon fritt tilgjengelig for våre medarbeidere. De hjelper også bedrifter med å fange og ta sikkerhetskopi av data enkelt og effektivt - i teorien, det vil si.
I virkeligheten blir de til stedet der bilder av firmafest fra seks år siden er lagret. I den siste setningen brukte jeg den passive stemmen med vilje fordi det ikke ser ut til at noen noen gang tar ansvar for å legge noe på en delt stasjon som ikke skulle være der. Ting bare vises. Ingen vet hvordan eller hvorfor de kom dit. Og derfor fjerner ingen dem av frykt for å tråkke på en annens tær eller slette noe som noen andre trenger.
Delte mellomrom bør utformes på en måte som samsvarer med en avdeling eller selskapets arbeidsflyt eller organisasjonskart. Ting som er parallelle i sin natur, som to team som rapporterer til samme ledernivå, bør ha parallell i mappestruktur. Når en ny person melder seg inn på en avdeling, skal hun eller han raskt kunne finne ut hvor viktige filer bor på et delt nettverk fordi plasseringen deres (mappenavn og hvordan den er nestet i andre mapper) skal speile hvordan virksomheten er designet. Et ekte rødt flagg er når noen som har jobbet på en tid lenge ikke kan finne ting fordi de ikke vet hvor det er, eller verre, ikke engang vet hvor det skal være.
Her er alt vi gjorde, steg for steg, for å rydde opp i vår slurvete servere. På slutten finner du et sammendrag av resultatene, i tillegg til notater om hva som gikk riktig og hva som gikk galt.
Serveropprydningsprosjektet
Trinn 1: Kommuniser. Først snakket vi om problemet med å ha en slurvete server, inkludert hvorfor det er et problem (ineffektivitet, inkonsekvenser, anstrenge nettverksområdet vårt), mulige løsninger og prosedyrer for implementering av disse løsningene.
Så snakket vi litt mer. Så snakket vi om hvem vi ellers hadde behov for å snakke med. Jeg kan ikke kjøre hjem nok viktigheten av kommunikasjon for å lykkes med dette prosjektet. Vi snakket mye, både personlig og via e-post.
I løpet av disse samtalene skjønte vi hvor viktig det ville være å kommunisere med IT-personalet også. Så vi sløyfet dem inn på planen vår og foreslo tidslinje. IT-teamet ga oss ett avgjørende råd som til slutt ble vårt virkelige startpunkt for prosjektet. De sa, ikke prøv å rydde opp i det du har; begynn heller med et tomt lerret og lag mappestrukturene du vil ha, og bare kopier over filer du vil beholde. Alt annet, sa de, de ville arkivere.
Trinn 2: Gå gjennom eksisterende data. For det andre satte alle interessentene - for det meste teamledere - seg ved et bord med en bærbar PC og en projektor. Vi koblet oss til den aktuelle serverplassen og sammen gjennomgikk noen av de eksisterende filene, bare for å være sikker på at ingen overså noen batch av filer vi skulle beholde.
Vi tenkte også på eksisterende data når det gjelder hvordan de gjorde eller ikke gjenspeilte dagens arbeidsflyt. Delte mellomrom brukes vanligvis til å samarbeide om arbeid. Strukturen og navnene på mapper må gjenspeile den arbeidsflyten nøyaktig for at den skal være nyttig.
Mye av det vi fant på serverne var grufullt utdatert. Det var mapper oppkalt etter ansatte som ikke hadde vært i selskapet på mange år. Vi fant filer fra 2003. Det var rester av prosjekter som aldri gikk av stabelen. Ingen trengte noe av dette.
Trinn 3: Kartlegg den nye strukturen. Mens vi fortsatt satt rundt bordet, tegnet vi mappestrukturen vi trodde skulle være på plass. Alle lederne hadde buy-in angående designen, som trengte for å gjenspeile teamstrukturen og arbeidsflyten. Dette er hva vi designet, selv om jeg har gjort navnene generiske slik at de vil være fornuftige for noen som ikke er kjent med vårt indre arbeid på vårt kontor:
På toppnivå har vi mapper for hvert team og spesialprosjekt eller oppgave, samt en for "Ressurser" som gjelder på tvers av alle team.
Hvert team har en undergruppe av mapper: noen få som viser arbeidsflyt, en for hvert teammedlem og flere mapper ettersom de gir mening for teamets behov. For eksempel ser teamets undermapper slik ut:
Vi brukte understrek og tall for å få arbeidsflytmappene til å sitte øverst i strukturen og vises i samme rekkefølge som arbeidet foregår. Mappen kalt "1_EDITING" er der filer som er klare til å redigeres, går og holder seg til redigeringen er ferdig. Deretter flytter de til "2_RTP" som betyr "klar til å produsere" - med andre ord, redigering er fullført og disse filene er klare til neste trinn. Etter at en fil er produsert, bør den flyttes til "3_PRODUCED, " som i hovedsak blir vårt levende arkiv. Alt i den mappen kan i teorien arkiveres, så vi vil alltid ha en cache av filer som vi vet at vi kan fjerne, hvis vi noen gang trenger å skaffe litt plass.
Trinn 4: Lag regler. Som jeg allerede har begynt å forklare i forrige avsnitt, har hver mappe noen regler knyttet til den om hva som kan og ikke kan gå inn på dem, eller hvordan de skal brukes. Hvis noen ønsker å dele bilder, for eksempel, må de legge dem i sin egen navnebrief-mappe. På den måten er det klart hvem som er ansvarlig for dataene.
Vi diskuterte også om vi hadde filer som må være tilgjengelige for flere team (vi gjorde det, og vi opprettet en Resources-mappe for dem) og om noe informasjon skulle være innelåst (ja: alt i Management Team-mappen).
Trinn 5: Sørg for konsistens. Da vi designet mappene og reglene for bruk av dem, ser vi også etter områder der vi kunne og burde være konsekvente. Når mappestrukturer og arbeidsflyter kan (og bør være) konsistente, sørger det for i perioder med personaleoverganger, for eksempel når noen forlater selskapet, går i barsel eller er uventet syk. Konsekvens på et delt serverplass hjelper alle i organisasjonen med å finne ut av aktuelle prosjekter, så vel som hva som er viktig, hvilket arbeid som allerede er fullført, og så videre.
Et oppfølgingsprosjekt (som vi nettopp implementerer nå) er å skape bedre konsistens på tvers av filnamnekonvensjonene våre. Vi bestemte oss for å fortsette å implementere denne filnavnsendringen før etter at alle var vant til å bruke de nye delte mappene for ikke å overbelaste noen med for mye ny informasjon på en gang.
Trinn 6: Sjekk en siste gang med alle interessenter. Før vi implementerte noe, gjennomførte vi en siste sjekk om planen med alle interessenter, inkludert noen få mennesker som vi opprinnelig ikke trodde å inkludere, men hvis navn kom opp i vår gjennomgang av eksisterende data. "Er det ikke Arielles kompetanseområde? Vi bør spørre henne hva hun mener må gjøres i denne delen."
Trinn 7: Fullfør og kommuniser tidslinjen. De siste trinnene var å ferdigstille tidslinjen og deretter sette i gang prosjektet. Dette var de siste brikkene i puslespillet:
- Bestem deg for når og hvordan du skal formidle informasjonen: Send e-post til alle ansatte i løpet av uken om den nye serverstrukturen, reglene og all relatert informasjon, inkludert datoer (se neste punkt).
- Angi datoer for: når folk må kopiere over filene de vil beholde (slutten av uken); når de skal begynne å bruke den nye strukturen (i vårt tilfelle umiddelbart etter mottak av e-posten); når den gamle serveren blir avskåret (vi fortalte dem slutten av uken, men i virkeligheten la vi ut denne fristen med noen ekstra dager).
- Planlegg noen få e-postmeldinger før du faktisk avslutter tilgangen til den gamle serveren.
- La IT utføre selve avskjæringen.
Serveropprydding
Den e-posten i midten av uken som inneholder all informasjonen om serveropprydding-prosjektet, gikk ut klokka 11.27 en onsdag. Noen få mennesker hadde brennende spørsmål, men svaret til alle tråden ble roet ned innen 11:57 am. Det betyr at alle grunnleggende spørsmål hadde blitt besvart innen 30 minutter.
I teamet mitt fortsatte ytterligere avklaringer angående arbeidsflyten vår - men den siste jeg har er datert 13:05 samme dag. Uten tvil stilte noen få spørsmål uten å svare på alle, men flertallet av spørsmålene ble besvart i løpet av to timer.
I løpet av de neste dagene fullførte vi tidslinjen uten problemer. IT-teamet kjørte en rask rapport som viser at vi reduserte de totale dataene med 76 prosent. Tallene taler for seg selv.
Før
- Total plass: 250 GB
- Antall filer: 447.249
- Antall mapper: 36 773
Etter
- Total plass: 59, 2 GB
- Antall filer: 58.624
- Antall mapper: 2, 962
Prosjekt Postmortem og tilbakemelding
Noen uker etter at vi var ferdig med migreringen og omstruktureringen av serveren, spurte jeg prosjektlederne, lederne og IT-nettverksadministratorene om de hadde noen tilbakemeldinger eller notater etter postmortem. Det gjorde ingen. Det hele gikk bemerkelsesverdig greit. Her var hva den ledende IT-fyren hadde å si:
"I ti-plussårene jeg har vært her, er dette første gang et avdelingsteam har påtatt seg et prosjekt som dette av egen interesse og gjennomført det så bra. Dette hjelper både [den andre IT-nettverksadministratoren] og meg bedre vedlikeholde nettverket, og jeg er sikker på at det hjelper teamet ditt med arbeidsflyt og organisering. Vi bokstavelig talt ba flere generasjoner ledelse om å gi mandat hva teamet ditt har oppnådd på grasrotnivå, og det er høyt verdsatt."
Fra mitt perspektiv er det en ting jeg skulle ønske vi hadde gjort litt annerledes. Jeg skulle ønske vi i utgangspunktet hadde fortalt ansatte om prosjektet personlig i et raskt improvisert møte, snarere enn via e-post. E-post er bra, og sikkert, ingen liker møter, men jeg følte at folk hadde følt seg mer inkludert i prosessen hadde de blitt fortalt under en åpen diskusjon i stedet for gjennom en "VIKTIG!" e-post.
Vi har nå en bedre, mer konsistent, mer effektiv og enklere delt server. Reglene for hvordan du bruker den er klare, med ansvarlighet innebygd. Teamledere er ansvarlige for teammapper, og enkeltpersoner er ansvarlige for hva som står i navnemappene.
Hvis du tenker på å sette i gang ditt eget serveropprydningsprosjekt i organisasjonen din, håper jeg du kan hente noen råd fra denne artikkelen om viktigheten av å få råd fra IT-avdelingen din, og å kommunisere grundig i alle ledd er avgjørende for å lykkes.
