Video: ORGANIZIRAJTE SA MNOM CIJELU KUĆU (Oktober 2024)
Še nikoli nisem srečal skupnega omrežnega pogona v podjetju, ki ni bilo vsaj malo pocukrano. Skupni strežniki so običajno zasnovani tako, da omogočajo sodelovanje, pa tudi da bi datoteke in informacije prosto dostopni našim sodelavcem. Prav tako podjetjem pomagajo enostavno in učinkovito zajemanje in varnostno kopiranje podatkov - teoretično, to je.
V resnici se spremenijo v kraj, kjer so shranjene fotografije družbenega praznika pred šestimi leti. V zadnjem stavku sem namerno uporabil pasivni glas, ker se zdi, da nihče nikoli ne prevzame odgovornosti za to, da bi nekaj postavil na skupni pogon, ki ga tam ne bi smelo biti. Stvari se šele pojavijo. Nihče ne ve, kako ali zakaj so prišli tja. In zato jih nihče ne odstrani iz strahu, da bi stopili na prste nekoga drugega ali izbrisali nekaj, kar nekdo drug potrebuje.
Skupni prostori naj bodo zasnovani tako, da ustrezajo delovnemu toku ali organizacijskemu načrtu oddelka ali podjetja. Stvari, ki so po naravi vzporedne, kot dve ekipi, ki poročata na isti ravni upravljanja, bi morale imeti vzporedno strukturo map. Ko se nova oseba pridruži oddelku, bi morala imeti možnost, da hitro ugotovi, kje v skupnem omrežju živijo pomembne datoteke, ker bi morala biti njihova lokacija (ime mape in kako je ugnezdena v drugih mapah) zrcala, kako je podjetje zasnovano. Prava rdeča zastava je, ko nekdo, ki je dlje časa delal, ne najde stvari, ker ne ve, kje je, ali še huje, niti ne ve, kje bi moral biti.
Tukaj je vse, kar smo storili, korak za korakom, da očistimo svoje navidezne strežnike. Na koncu boste našli povzetek rezultatov ter opombe o tem, kaj je šlo narobe in kaj narobe.
Projekt čiščenja strežnika
1. korak: komunicirajte. Najprej smo se pogovarjali o težavi, ki ima naključen strežnik, vključno s tem, zakaj je to težava (neučinkovitost, neskladnosti, obremenitev našega omrežnega prostora), možnimi rešitvami in postopki za njihovo izvajanje.
Potem smo se pogovarjali še nekaj. Nato smo se pogovarjali o tem, s kom moramo še govoriti. Ne morem se dovolj voziti domov, kako pomembna je komunikacija za uspeh tega projekta. Veliko smo se pogovarjali, tako osebno kot po e-pošti.
Med temi pogovori smo ugotovili, kako pomembna bi bila tudi komunikacija z osebjem IT. Tako smo jih vpisali v naš načrt in predlagano časovnico. Ekipa IT nam je dala en ključni nasvet, ki je na koncu postal naša prava izhodiščna točka za projekt. Rekli so, ne poskušajte očistiti tega, kar imate; raje začnite s praznim platnom in ustvarite želene strukture map in kopirajte le datoteke, ki jih želite obdržati. Vse drugo, so rekli, arhivirali.
2. korak: Preglejte obstoječe podatke. Drugič, vsi deležniki - večinoma vodje skupin - so sedeli za mizo s prenosnikom in projektorjem. Povezali smo se z zadevnim strežniškim prostorom in skupaj pogledali nekatere obstoječe datoteke, samo da se prepričamo, da nihče ni spregledal nekaj datotek, ki bi jih morali obdržati.
Razmišljali smo tudi o obstoječih podatkih z vidika, kako so to storili ali niso odsevali naših trenutnih delovnih procesov. Skupni prostori se običajno uporabljajo za sodelovanje pri delu. Struktura in imena map morajo natančno odražati ta potek dela, da so uporabni.
Veliko tega, kar smo našli na strežnikih, je bilo grozno zastarelo. Imeli so mape za zaposlene, ki že leta niso bili s podjetjem. Našli smo kartoteke iz leta 2003. Bilo je ostankov projektov, ki niso nikoli zašli. Nihče ni potreboval nobene te stvari.
3. korak: Izčrpajte novo strukturo. Medtem ko smo še sedeli okrog mize, smo skicirali strukturo map, za katero smo mislili, da mora biti na svojem mestu. Vsi direktorji so imeli nakup v zvezi z zasnovo, ki je morala odražati našo strukturo in potek dela. Tukaj je nekaj, kar smo zasnovali, čeprav sem imena generično oblikoval tako, da bodo imeli smisel za nekoga, ki ni seznanjen z notranjim delovanjem naše pisarne:
Na najvišji ravni imamo na voljo mape za vsako ekipo in poseben projekt ali nalogo, pa tudi eno za "Viri", ki veljajo za vse ekipe.
Vsaka ekipa ima podmnožico map: nekaj, ki prikazujejo potek dela, po eno za vsakega člana ekipe in dodatne mape, saj so smiselne za potrebe te ekipe. Na primer, podmape moje ekipe so videti takole:
S podčrtaji in številkami smo naredili, da naše mape delovnega toka sedijo na vrhu strukture in se prikažejo v istem vrstnem redu, kot je delo. V mapi »1_EDITING« gredo datoteke, ki so pripravljene za urejanje, in ostanejo, dokler urejanje ni končano. Nato se premaknejo na "2_RTP", kar pomeni "pripravljen za izdelavo" - z drugimi besedami, urejanje je končano in te datoteke so pripravljene za naslednjo stopnjo. Ko je datoteka izdelana, jo je treba premakniti v "3_PRODUCED", ki v bistvu postane naš živi arhiv. Teoretično bi bilo mogoče karkoli v tej mapi arhivirati, zato bomo vedno imeli predpomnilnik datotek, za katere vemo, da jih lahko odstranimo, če bomo kdaj potrebovali, da pridobimo nekaj prostora.
4. korak: Ustvarite pravila. Kot sem že začel razlagati v prejšnjem razdelku, ima vsaka mapa nekaj pravil, ki so povezana z njo, kaj lahko in česa ne more iti vanje ali kako jih je treba uporabiti. Če želi na primer nekdo deliti fotografije, ga mora shraniti v svojo lastno mapo. Tako je jasno, kdo je odgovoren za podatke.
Razpravljali smo tudi o tem, ali imamo datoteke, ki morajo biti dostopne več skupinam (naredili smo in ustvarili smo mapo z viri zanje) in ali je treba kakršne koli podatke zakleniti (ja: vse v mapi Management Team).
5. korak: Zagotovite doslednost. Ko smo oblikovali svoje mape in pravila za njihovo uporabo, iščemo tudi področja, na katerih bi lahko in morali biti dosledni. Kadar so strukture mape in potek dela lahko (in bi morali biti) dosledni, to velja za čas prehoda osebja, na primer ko nekdo zapusti podjetje, gre na porodniški dopust ali je nepričakovano bolan. Doslednost v skupnem prostoru strežnika pomaga vsem v organizaciji ugotoviti stanje trenutnih projektov, pa tudi, kaj je pomembno, kakšno delo je že zaključeno in podobno.
Nadaljnji projekt (ki ga šele zdaj izvajamo) je ustvariti boljšo skladnost tudi v naših konvencijah o poimenovanju datotek. Odločili smo se, da bomo odložili to spremembo poimenovanja datotek, dokler se vsi niso navadili na uporabo novih map v skupni rabi, da nikogar ne bi preobremenili s preveč novih informacij naenkrat.
6. korak: Zadnjič preverite vse zainteresirane strani. Preden smo izvedli karkoli, smo z vsakim deležnikom opravili še en končni pregled načrta, vključno z nekaj ljudmi, ki jih prvotno nismo mislili vključiti, a njihova imena so se pojavila v našem pregledu obstoječih podatkov. "Ali to ni Arielleino strokovno znanje? Bolje bi jo vprašali, kaj meni, da je treba storiti v tem razdelku."
7. korak: Dokončajte in sporočite časovnico. Zadnji koraki so bili dokončna časovnica in nato začetek projekta. To so bili zadnji deli uganke:
- Odločite se, kdaj in kako razširjati informacije: Sredi tedna pošljite vsem zaposlenim podatke o novi strukturi strežnika, pravilih in vseh povezanih informacijah, vključno z datumi (glejte naslednjo točko).
- Določite datume za: ko morajo ljudje kopirati datoteke, ki jih želijo hraniti (konec tedna); kdaj naj začnejo uporabljati novo strukturo (v našem primeru takoj po prejemu e-pošte); kdaj bo stari strežnik odrezan (povedali smo jim konec tedna, v resnici pa smo ta rok podaljšali z nekaj dodatnimi dnevi).
- Načrtujte nekaj opozorilnih e-poštnih sporočil, preden dejansko prekinete dostop do starega strežnika.
- Naj IT izvede dejanski presek.
Rezultati čiščenja strežnika
Tistega e-poštnega sporočila sredi tedna, ki vsebuje vse podatke o projektu čiščenja strežnika, je izšlo ob sredi ob 11:27. Nekaj ljudi je imelo pereča vprašanja, toda nit odgovora na vse se je utihnila do 11:57, kar pomeni, da so na vsa osnovna vprašanja odgovorili v 30 minutah.
V moji skupini so se nadaljevala dodatna pojasnila glede našega delovnega procesa - vendar je zadnje, ki sem ga imel, zjutraj zjutraj ob 13.05. Brez dvoma je nekaj ljudi postavilo dodatna vprašanja, ne da bi na vse odgovorilo, vendar je večina vprašanj odgovorila v dveh urah.
V naslednjih nekaj dneh smo časovno vrstico zaključili brez zagate. Ekipa IT je pripravila nekaj kratkih poročil, v katerih je pokazala, da smo skupne podatke zmanjšali za 76 odstotkov. Številke govorijo same zase.
Prej
- Skupni prostor: 250 GB
- Število datotek: 447.249
- Število map: 36, 773
Po tem
- Skupni prostor: 59, 2 GB
- Število datotek: 58, 624
- Število map: 2962
Projekt Postmortem in povratne informacije
Nekaj tednov po zaključku selitve in prestrukturiranja strežnika sem vodje projekta, vodje in skrbnike omrežij IT vprašal, če imajo kakršne koli povratne informacije ali postmortem opombe. Nihče ni storil. Vse je potekalo izjemno gladko. Tukaj je povedal vodilni IT fant:
"V desetih letih, ko sem bil tukaj, je to prvič, da je oddelčna skupina izvedla takšen projekt iz lastnega interesa in ga tako dobro izpeljala. To pomaga tako [drugim skrbnikom IT omrežja] kot bolje vzdržujem mrežo in prepričan sem, da vaši ekipi pomaga pri delovnem toku in organizaciji. Dobesedno smo prosili več generacij vodstva, da pooblastijo, kar je vaša ekipa dosegla na lokalni ravni, in to zelo cenimo."
Z moje perspektive želim, da bi naredili nekoliko drugače. Želim si, da bi prvotno osebno o projektu povedali osebno na hitrem improviziranem sestanku, ne pa po e-pošti. E-poštni naslov je v redu in zagotovo nihče ne mara srečanj, vendar sem se počutil, kot bi se ljudje počutili bolj vključene v postopek, če bi jim to povedali med odprto razpravo, ne pa prek "POMEMBNO!" E-naslov.
Zdaj imamo boljši, doslednejši, učinkovitejši in enostavnejši deljeni strežnik. Pravila, kako ga uporabljati, so jasna, vgrajena je odgovornost. Vodje ekip so odgovorni za mape v skupinah, posamezniki pa so odgovorni za mape v svojem imenu.
Če razmišljate, da bi v svoji organizaciji začeli projekt lastnega čiščenja strežnikov, upam, da boste v tem članku lahko prejeli nekaj nasvetov o pomembnosti pridobivanja nasvetov oddelka za IT in temeljito komunikacijo na vsaki stopnji, ki je ključnega pomena za uspeh.
