- controale
- politici
- procese
Un control consta in descrierea in linii mari, idee care apoi este implementata drept una sau mai multe politici care apoi sunt folosite pentru a fi standardizate iintr-un set de proceduri.
Este important sa le avem pe toate 3 deoarece controalele sunt descrise vag, politicile sunt generale si cu scop larg, ceea ce inseamna ca pentru a livra rezultate consistente dpdv al calitatii este necesar un set de proceduri prescriptive denumite la unele firme drept Proceduri de Operare Standardizate - “Standard Operating Procedures” (SOP)
Ideea unui SOP este sa produca rezultate consistente indiferent de cine il foloseste. Asta inseamna ca toate SOP-urile trebuie sa fie asemenatoare, familiare si usor de urmat si nu in ultimul rand, potrivite pentru oricine trebuie sa le urmeze. Pornind de la aceste cerinte, pentru a avea rezultate consistente nu se poate lasa loc pentru ambiguitati. Aceasta trebuie sa fie explicita si sa acopere orice context necesar. Ambiguitatea este inamicul numarul 1 al consistentei.
Un caz concret: Daca se cere sa recompilezi un software iar parametrii de compilare sunt numerosi si nu poti determina care parametru a fost folosit in trecut ai putea sa devii nervos atunci cand te intrebi daca il compilezi cum trebuie. Cand te duci si intrebi cine l-a compilat, persoana respectiva poate spune "Nu stii sa compilezi software ?" iar raspunsul ar putea fi sub forma: "Stiu, dar nu stiu cum compilati VOI un software". Este important ca persoanei care implementeaza procedura sa ii fie oferite toate informatiile si contextul necesar ca sa inteleaga si, daca este necesar, sa interpreteze informatia in functie de situatia din acel moment.
Primul lucru de punctat la un SOP este definirea unui template pe care toti sa il respecte. Fara un template standard fiecare autor isi va scrie procedura in stilul lor unic. Unele persoane vor scrie o carte, altii vor da un copy-paste din terminal.Asadar template-ul trebuie sa asigure un anume flux care asigura ca toate informatiile necesare sunt incluse dar intr-un mod concis si complet.Pe langa asta vrem ca cei care fac SOP-uri sa se concentreze numai la scrierea continutului si nu la dezbaterea formatului.
Exemplu de template folosit la Joyent (markup-ul este in Confluence):
* Author: {page-info:created-user} created at: {page-info:created-date}
* Version: 1
* Revisions: {page-info:current-version}
* Reviewed by: (User @ date)
* Time to implement: 1hr
* Products this applies to: (SKU1)
{toc}
h1. Description & Scope
h1. Prerequisites
* Root access to node
* [SOP-222: Something|SOP-222: Something]
* [SOP-224: Something else|SOP-224: Something else]
h1. Procedure
h3. Step 1: Do this
{noformat}
Example
{noformat}
h3. Step 2: Do that
h3. ...
h1. Procedure Validation
# Login and verify external connectivity (ping google.com)
# curl zone IP address, page returns
# etc.
h1. Notes/Jira Examples
* [http://confluence.atlassian.com/display/DOC/JIRA+Issues+Macro]
* [http://confluence.atlassian.com/display/DOC/JIRA+Portlet+Macro]
* [https://studio.plugins.atlassian.com/browse/CONFJIRA-154]
Descriere template-ului:
Toate SOP-urile trebuie sa fie numerotate pentru a fi gasite usor. Chiar si template-ul trebuie definit ca SOP-000. Titlul ar putea fi sub forma SOP-102 "Creating LDAP Users"
Partea superioara contine numai metadate: autorul, data la care a fost creat, versiunea, numarul reviziei si produsele (sau proiectele, etc.) la care acest SOP face referire.
Se observa si doua campuri: Reviewd By si Time to implement care sunt si cele mai importante Dupa ce un SOP a fost creat acesta trebuie revizuit de altcineva din grup, preferabil cineva cu cat mai putine cunostinte despre subiect. Acestia ar trebui sa citeasca si sa urmeze SOP-ul creat, pornind un cronometru cand incepe si oprindu-l cand acestia isi termina treaba.
Timpul cronometrat devine estimarea timpului pentru implementare. Acest lucru este foarte important pentru ca autorul va da un timp prea scurt pentru ca stie mai multe decat un simplu n00b.
Mai departe in template, "Description and Scope": Aici se descrie contextul. Despre ce vorbim, ce implica mai exact, ce impact are, etc. Vrem sa includem cat mai multe informatii posibila aici fiind scheletul pentru procdeura ce va urma.
Continutul SOP-ului este procedura propriu-zisa. Cred cu o mare convingere ca aceasta trebuie sa fie sub forma "Pasul 1... Pasul 2 ... Pasul 3", trebuie sa fie usor de citit si de urmat iar in unele situatii pot fi folosite ca un checklist in cazul unor proceduri delicate. Este important ca acestea sa porneasca de la inceput si sa ajunga la sfarsit. "Pasul 1: Logheaza-te pe serverul X" poate parea foarte simplist dar necesar pentru a clarifica daca sunt mai multe sisteme implicate. Imi place sa termin procedura cu cuvantul "Terminat" ca sa fie clar ca ai ajuns la sfarsit.
La fel de important este si "Validation Steps". Pentru a asigura un job de calitate nu trebuie fie urmati doar pasii din procedura ci sa ii si validam intr-un fel sau altul pentru a ne asigura ca a fost facut corect. Acest lucru are ca efect secundar satisfactia oferita persoanei ca a urmat procedura si a fost facuta cum trebuie si nu a gresit cu ceva cand parcurgeau etapele procedrii.
Ultimul pas consta in includerea link-urilor externe oriunde se crede de cuviinta. Unde este posibil includerea unui link catre tichetele pe care s-au bazat pe SOP-ul respectiv astfel incat in cazul in care exista confuzii pot gasi exemple rezolvate in trecut.
O sectiune optionala pe care am folosit-o in trecut este "Rationale". In aceasta sectiune se pot include note de genul: "de ce ai ales sa implementezi procedura in acest fel". Acest lucru permite imbunatatirea continua a SOP-ului. In majoritatea cazurilor sunt multe metode de a rezolva o problema, dar cand se ofera o explicatie pentru decizia de a folosi o metoda anume, asta ajuta la imbunatarirea procedurii in viitor, in timp ce se invata din trecut. Fara aceasta sectiune este posibila sa apara regresii sau proceduri duplicate.
Acest model a fost folosit la Joyent timp de mai multi ani si a rezistat la testul timpului. Cred ca este un standard bun pentru a crea SOP-uri si impartirea cunostintelor in interiorul organizatiei, evitand astfel situatiile in care o singura persoana reprezinta o constrangere.
Sursa:
http://cuddletech.com/blog/?p=776
No comments:
Post a Comment