Am fost implicat în marketing aproape toată viața mea. Înainte să încep să promovez canale YouTube în One2, gestionam departamentul de servicii pentru clienți în agenția PROMO. Inovațiile m‑au atras întotdeauna, așa că întâlnirea cu metodologia Scrum a fost o chestiune de timp.
Calea mea către managementul de proiect
În agenția de publicitate, am devenit liderul unui departament format din manageri de cont. Nu exista un sistem de management de proiect. Nu eram la timp pentru îndeplinirea datoriilor contractuale sau îndeplineam lucrări de calitate slabă. Astfel, am devenit o persoană care rezolvă probleme pentru a aborda feedback-ul negativ al clienților. A fost o cale fără ieșire: nereușind să previn o problemă, mă ocupam de consecințele acesteia.
Am început să caut un set de instrumente pentru a aborda situația. La acel moment, nu eram conștient de Agile sau Scrum, cu atât mai puțin de modalitățile de a folosi metodologia Scrum în echipe non-IT.
Am devenit o persoană care rezolvă probleme pentru a aborda feedback-ul negativ al clienților.
Cum am ales metodologia de management de proiect
La început, né-am uitat la Kanban. Este deosebit de eficient pentru problemele de flux precum corectarea erorilor sau procesarea aplicațiilor într-un call center. Dar pentru a introduce Kanban, ai nevoie de o echipă foarte motivată și bine organizată. Nu era cazul nostru.
De asemenea, am luat în considerare Waterfall. Este bun pentru echipele IT deoarece o secvență clară de etape necesită mai puțin cod, iar tu ești în ascensiune. Același proiect în Scrum va arăta complet diferit:
o muncă funcțională —> ajustare —> optimizare
Fiabilitatea Waterfall ascunde dezavantajul său – un risc ridicat de a încălca termenele. Afacerile doresc să obțină rezultate cât mai repede posibil, mai degrabă decât să aștepte un an întreg pentru a se convinge că strategia aleasă nu funcționează. Scrum nu este lipsit de această “problemă”.
Ce instrumente Scrum se potrivesc unei agenții de marketing
Scrum oferă o mulțime de instrumente pentru a impulsiona motivația:
- tablouri Scrum. Tablourile Scrum arată statusurile sarcinilor și te pot ghida spre punctele problematice (de exemplu, prea multe sarcini sunt în etapa de discuție cu clienții). Am făcut tablourile scrum disponibile pentru clienții noștri pentru a le permite să urmărească statusurile sarcinilor. Acest lucru a eliberat profund managerii noștri de cont de povara de lucru.
- întâlniri săptămânale. Toți membrii echipei se succed pentru a prezenta rezultatele zilei anterioare, pentru a promite pentru ziua curentă și pentru a împărtăși problemele. Datorită acestor întâlniri zilnice, poți înțelege ce se întâmplă în companie și găsi modalitatea de a face munca mai eficientă.
- planificare. Aceasta face procesul de muncă transparent pentru manager și pentru client. Am invitat clienți specifici și am decis împreună ce sarcini să stabilim pentru sprinturile următoare.
- retrospectivă. Putem înțelege greșelile pe care le-am făcut și modalitățile de a le corecta (de exemplu, cum să creștem numărul de sarcini simultane în desfășurare fără a compromite calitatea).
- demonstrarea produsului. Aceasta prezintă progresele echipei realizate pe parcursul sprintului. Fiecare membru al echipei își arată partea sa din produs. Demonstrarea produsului face posibilă efectuarea rapidă a modificărilor, îmbunătățirea produsului și evitarea pierderii de timp cu prezentări timpurii ale produsului finit.
Activitatea mea consta în principal în analiza feedback-ului negativ al clienților. După introducerea Scrum, am început să cerem opiniile clienților pentru a înțelege dacă direcția noastră de mișcare era corectă. Am îmbunătățit indexul de suport pentru consumatori (NPS).
Care sunt dezavantajele Scrum pentru echipele non-IT?
Scrum are trei deficiențe principale:
- Procesele de afaceri devin mai costisitoare. Am introdus funcția de owner de produs, deoarece niciun membru al echipei nu ar fi putut face față unui rol atât de important. Un astfel de specialist este costisitor. Nici owner-ul de produs, nici Scrum master-ul nu creează valoare direct; ei sunt în afara echipei și în esență aparține categoriei de cheltuieli indirecte.
- Nu există un serviciu convenabil de management de proiect în Scrum pentru echipele non-IT. Obişnuiam să utilizăm Jira, dar ajustarea acesteia necesită adesea implicarea unui specialist.
- Terminologia IT în Scrum nu este adaptată pentru companiile non-IT. Pentru companiile IT, există ghiduri detaliate care outlinează modalitățile de a face Scrum să funcționeze. Acestea explică terminologia: increment este un produs funcțional, demo este demonstrarea modalităților în care funcționează produsul. În cazul nostru, nu era clar cum influențea scrierea de conținut asupra funcționării produsului. Și ce este increment în SEO? Dacă am scris un text și l‑am postat pe site – este un produs funcțional? Né‑a luat mai mult de trei luni pentru a adapta terminologia IT la nevoile noastre.
Cum am eșuat în a introduce Scrum
Am început introducerea Scrum-ului formând echipe. Și imediat am făcut două greșeli.
Greșeala Nr. 1. Am inclus specialiști de publicitate context și SEO într‑o echipă. Logica este următoarea: toți aduc trafic pe site-urile clienților și cresc vânzările, ceea ce înseamnă că sunt bineveniți să colaboreze. Echipa este unită în jurul unui singur client.
Cum am rezolvat problema: după un timp, am împărțit specialiștii în funcție de valori și produse. Unii clienți au avut mai mulți manageri de cont și echipe deodată.
Ceea ce am înțeles: o echipă ar trebui să fie unită în jurul unui scop de afaceri. O astfel de echipă este autosuficientă și capabilă să creeze valoare pentru client de una singură.
Greșeala Nr. 2. Nu am reușit să definim din start cine urma să acționeze ca Scrum master și owner de produs.
Cum am rezolvat problema: am suplimentat funcția de contabil de grup existent cu funcția de Scrum master. Înainte, el era responsabil de productivitatea echipei și livrarea neîntreruptă a valorii pentru client. Am angajat o persoană separată pentru a fi owner de produs.
Întâlnesc adesea două greșeli în companiile care introduc și Scrum:
- Echipele sunt unite în jurul unei singure funcții. Un departament este pur și simplu redenumit într‑o echipă. Problema este că, dacă un client are nevoie de un site web, echipa ar trebui să aibă un programator, un designer și un manager. Niciun departament de marketing format din manageri de brand nu va crea un site web.
- Companiile se tem să distrugă structura existentă. Exemplul următor a fost real. Un manager de cont gestiona mai multe proiecte fiecare dintre care era susținut de diferiți specialiști SEO. Proiectele erau distribuite în funcție de încărcătura de lucru a specialiștilor SEO. Să presupunem că un specialist a obținut 10 proiecte cu priorități diferite. Prioritățile sunt stabilite de managerul de proiect, iar această companie avea mai mulți dintre ei. În cel mai bun caz, specialistul SEO a îndeplinit cea mai ușor de înțeles sarcină, în cel mai rău caz — sarcina managerului de cont care a strigat cel mai mult.
Uniting in „echipele corecte” este un proces dureros.
De ce avem nevoie de un Scrum master?
Toyota are un caz interesant pentru a exemplifica rolul Scrum master-ului. În fabrică, unii muncitori au fost desemnați să asiste un inginer mecanic pentru a optimiza munca. Inginerul mecanic era plătit pe oră, suma fiind destul de mare, astfel că performanța trebuia să fie crescută, iar costurile trebuiau reduse. S‑a observat că inginerul mecanic căuta cheia potrivită – apoi un ucenic a fost desemnat să‑i furnizeze cheile. A fost gândit să faciliteze procesul și mai mult: șabloanele pentru unelte au fost pictate pe podea, iar ucenicul le aranja dimineața înainte de muncă.
Așadar, un bun Scrum master asigură 80% din succesul introducerii Scrum. Dacă îți lipsește o persoană care să poată asuma acest rol, caută‑o pe aceea care este interesată de muncă suplimentară în acest domeniu. Ca ultimă opțiune, caută un Scrum master în companiile IT.
Scrum master-ul are următoarele funcții non-obișnuite:
- Simte unde echipa nu performează, unde este posibil să accelerezi și unde este mai bine să încetinești. Este ca un scut împotriva termenelor limită și haosului.
- Este responsabil de sentimentul de siguranță al echipei. Aceasta include protecția împotriva unui client care vrea „să facă totul pentru ieri”. De exemplu, am întâmpinat astfel de probleme: managerii de cont compilau rapoarte pentru clienți timp de mult timp. La instigarea Scrum master-ului, am configurat rapoarte automate generate în timp real. Acum clientul nu trebuie să aștepte sfârșitul lunii pentru a înțelege cum merg lucrurile. Toate părțile sunt mulțumite.
- Îmbunătățirea nivelului echipei de utilizare a Scrum prin alegere voluntară.
- Comunicarea unul la unul cu fiecare membru al echipei. Despre problemele și necazurile angajaților. În acest fel, specialiștii juniori vor ajunge mai repede la nivelul mediu, iar specialiștii de nivel mediu vor crește în seniori. Rotația personalului va scădea.
De ce avem nevoie de un owner de produs?
Nu am înțeles imediat cine urma să devină owner de produs și de ce era responsabil. Am ajuns la concluzia că owner-ul de produs este un specialist tehnic care are cunoștințe bune despre produs și capabil să elaboreze strategii de conținut și SEO, comunicându-le clientului. Cu alte cuvinte, acesta este un strategist care spune ce trebuie făcut.
Ce face owner-ul nostru de produs?
- formează backlog-uri;
- elimină și stabilește prioritățile sarcinilor;
- ajustează strategiile pe baza datelor obținute de la echipă;
- este responsabil față de clienți pentru rezultat.
Modalitatea în care am introdus Scrum într‑o companie non-IT
Specialiștii obișnuiau să lucreze separat: redactori și editori, constructori de linkuri și analiști SEO. În timp ce introduceam Scrum, i‑am amestecat unii cu alții. Fiecare echipă are și un manager de cont care livrează valoare clienților.
Echipele au fost formate pentru fiecare dintre cele trei domenii SEO:
- gestionarea masei de linkuri
- crearea de conținut
- refacerea site-ului web.
Activitatea a fost împărțită în sprinturi care stau la baza planificării lunare. În timpul planificării, am încercat să reducem riscul de a nu obține un rezultat la sfârșitul lunii.
Experimentăm cu durata sprinturilor. Când am început introducerea Scrum pentru prima dată, sprinturile au fost săptămânale. Un sprint săptămânal permite să rulezi rapid un proces și să realizezi unde greșești, să instruiești angajații și să înțelegi cum funcționează totul.
Sfaturi cheie pentru durata sprinturilor Scrum în marketing: alege un termen limită care este suficient pentru a realiza un lucru util.
Sprinturile arată astfel:
planificare —> întâlniri —> demonstrare —> retrospectivă.
Am redirecționat o parte din echipe pentru a avea sprinturi de două săptămâni. Țineți cont că, cu cât sprintul este mai lung, cu atât mai mult riști să ratezi termenele limită.
Folosim următoarele instrumente în munca noastră:
- planificarea poker. Tehnica permite evaluarea complexității și a domeniului sarcinilor care vor trebui abordate în timp ce produsul este creat. Toți membrii echipei sunt implicați în planificarea poker. Folosind cărți, ei evaluează sarcinile și iau decizii colective;
- analogul programării pereche bazat pe programarea extremă. Mai multe persoane lucrează la o sarcină la același loc de muncă. Este un exemplu demonstrativ al regulii – “Două capete sunt mai bune decât unul”. O folosim în momente critice;
- cicluri HADI. Acestea sunt algoritmi pentru verificarea ipotezelor controversate care ajută la câștigarea încrederii clienților. Citește mai multe despre ciclurile HADI mai jos.
Ce sunt ciclurile HADI și cum să le folosești?
Ce este? Un ciclu HADI este un algoritm pentru a verifica o ipoteză care arată astfel:
ipoteză —> verificare —> rezultat —> concluzii.
Ciclurile HADI sunt similare cu loop-ul Lean Startup:
construiește —> măsoară —> învață
Cum funcționează?
Generați ipoteze a căror fezabilitate este pusă la îndoială. Dacă o sarcină este clară și necesară, nu are sens să o procesăm într-un ciclu HADI. După ce verifici ipoteza, determină dacă a funcționat sau nu, și în ce măsură. Dacă a funcționat, o lansezi într-un sprint, dacă nu, pur și simplu o abandonezi.
Cum arată?
De exemplu, există o ipoteză: “Dacă fac interlinking pe produsele respective, va duce la o creștere de trafic de trei ori”. Verifici ipoteza pentru un produs, setând linkuri manual pe site. Dacă ipoteza a funcționat, dai o sarcină programatorilor: “Furnizați interlinking pe întregul site”.
Care este avantajul ciclurilor HADI?
Pare să‑i doresc clientului că noua ta soluție nu va performa bine. Ca răspuns, arăți exemplul real bazat pe un element.
Documentează-ți ipotezele, chiar dacă acestea nu au funcționat. În sprintul următor, poți testa o altă ipoteză. În plus, asigură-te că experimentele tale nu provoacă un conflict de interese (de exemplu, ca ipotezele legate de aceeași pagină web să nu fie testate simultan). În caz contrar, nu va fi clar care ipoteză a reușit.
7 sfaturi pentru a introduce Scrum dacă nu ești o companie IT
- Începe cu formarea. Citește literatură specializată, vizitează sesiuni de instruire.
- Determină cine este părțile interesate (parte interesată). Și apoi lucrează pentru a livra valoare clientului și părții interesate.
- Sprinturile ar trebui să rămână neschimbate. Nu te teme să schimbi restul lucrurilor.
- Nu redirecționa întreaga echipă la Scrum, doar pentru că “e cool”. De exemplu, redactori noștri lucrează prin Kanban, deoarece textele nu au priorități – trebuie să fie realizate cât mai repede posibil.
- Determină dimensiunea optimă a echipei tale. Conform experienței mele, este de cinci-șapte persoane în companiile non-IT.
- Organizează o zonă de lucru separat pentru fiecare echipă. Dacă ai un birou deschis, adaugă tablouri Scrum offline.
- Fii lider în implementarea Scrum. Dacă conducerea este ignorantă față de scopul unei noi metodologii, nimic nu va fi realizat.