Мен маркетинг саласында өмірімнің көп бөлігін жұмыс істеп келемін. YouTube арналарын One2-де і просветительство жасауды бастамас бұрын, PROMO агенттігінде клиенттер қызметі бөлімін басқардым. Инновациялар мені әрдайым қызықтырған, сондықтан Scrum әдістемесімен танысуым уақыт күтті.
Менің жобаларды басқаруға жолым
Жарнама агенттігінде мен есеп менеджерлерінен тұратын бөлімнің жетекшісі болдым. Жобаларды басқару жүйесі болған жоқ. Біз келісімшарттық міндеттемелерімізді орындауға уақытында үлгермедік немесе жұмысты нашар сапада орындадық. Сол себепті мен теріс клиенттік пікірлерді шешу үшін қиындықтарды шешуші болдым. Бұл тупиктік жол болды: проблеманы алдын ала болдырмау мүмкін болмады, мен оның салдарымен көтерістім.
Мен жағдайды шешу үшін құралдар жинағын іздей бастадым. Сол уақытта мен Agile немесе Scrum туралы білмедім, айтпағанда, Scrum әдістемесін IT емес командаларда қолдану жолдары туралы.
Мен теріс клиенттік пікірлерді шешу үшін қиындықтарды шешуші болдым.
Біз жобаларды басқару әдістемесін қалай таңдадық
Алдымен біз Канбанға қарадық. Ол ақауларды жөндеу немесе колл-орталығында өтініштерді өңдеу тәрізді ағын мәселелеріне ерекше қолайлы. Бірақ Канбанды енгізу үшін жоғары мотивацияланған және жақсы ұйымдастырылған команда қажет. Бұл біздің жағдайымызға қатысы жоқ еді.
Сондай-ақ біз Су құлауын (Waterfall) қарастырдық. Ол IT командалары үшін жақсы, себебі кезеңдердің анықтылығы кодтарды аз талап етеді, ал сіз жоғары көзқарастасыз. Scrum-дағы бірдей жоба мүлдем өзгеше көрінеді:
функционалдық зат —> икемдеу —> оңтайландыру
Су құлауындағы сенімділік оның кемшілігін жасырады – мерзімдерді бұзудың жоғары қаупі. Бизнестер нәтижелерді мүмкіндігінше тез алуды қалайды, бір жыл күтуден гөрі, таңдалған стратегияның жұмыс істемей тұрғанын одан әрі көру үшін. Scrum бұл “қиындықтан” бос емес.
Маркетинг агенттігіне қай Scrum құралдары сай келеді
Scrum мотивацияны арттыру үшін көптеген құралдар ұсынады:
- Scrum тақтасы. Scrum тақтасы тапсырмалардың күйін көрсетеді және сізді қиындықтар нүктелеріне жөнелте алады (мысалы, клиенттермен талқылау кезеңінде тым көп тапсырмалар бар). Біз клиенттерімізге тапсырмалардың күйін бақылау үшін Scrum тақталарын қолжетімді еттік. Бұл біздің есеп менеджерлерімізден жүктемені барынша азайтты.
- апталық стендапы. Команда мүшелері соңғы күннің нәтижелерін ұсыну, ағымдағы күн үшін уәде беру және мәселелермен бөлісу үшін кезек-кезек алады. Мұндай күнделікті стендаптар арқылы сіз ұйымдағы жағдайды түсініп, жұмысты тиімдірек ету жолдарын таба аласыз.
- жоспарлау. Бұл жұмыс процесін менеджер мен клиент үшін мөлдір етеді. Біз нақты клиенттерді шақырып, келесі спринттер үшін қандай тапсырмалар қою туралы бірге шешім қабылдадық.
- ретроспектива. Біз жасаған қателіктерімізді түсініп, оларды қалай түзету жолдарын таба аламыз (мысалы, сапаны төмендетпей, бір уақытта неғұрлым көп тапсырмаларды қалай ыңғайлауға болады).
- өнімнің демонстрациясы. Ол спринт бойы команда жетістіктерін көрсетеді. Әр команда мүшесі өнімнің өзінің бөлігін көрсетеді. Өнімнің демонстрациясы өзгерістер енгізуді жеңілдетеді, өнімді жақсартып, дайын өнімді ерте көрсету уақытын ысырап етпейді.
Бұрын менің жұмысым негізінен теріс клиенттік пікірлерді талдауға негізделген. Scrum енгізілгеннен кейін, біз клиенттердің пікірлерін түсіну үшін сұрау жасауды бастады, біздің қозғалысымыздың бағыты дұрыс paн дегеніміз. Біз тұтынушы қолдау индексін (NPS) жаңарттық.
Scrum-ның IT-емес командалар үшін кемшіліктері қандай?
Scrum-ның үш негізгі кемшілігі бар:
- Бизнес процесстері қымбаттайды. Біз өнім иесі лауазымын енгіздік, себебі ешқандай команда мүшесі мұндай маңызды рольді атқаруға қабілетті емес. Мұндай маман қымбат. Негізінен, өнім иесі және Scrum факторлары тікелей құн жасамайды; олар командадан тыс, ал негізінен қосымша шығындар санатына жатады.
- Scrum-да IT емес командалар үшін ыңғайлы жобаларды басқару қызметі жоқ. Біз Jira-ны пайдаланып келдік, бірақ оның бұрынғыдан кейінгі реттеуі маман шақыруды қажет етеді.
- Scrum-дағы IT терминологиясы IT емес компаниялар үшін бейімделмеген. IT компаниялары үшін Scrum-ды пайдалануды көрсететін егжей-тегжейлі нұсқаулар бар. Олар терминологияны түсіндіреді: қосымша функционалдық өнім; демонстрация өнімнің қалай жұмыс істейтінін көрсетеді. Біздің жағдайымызда, мазмұн жазуы өнімнің қызметіне қалай әсер ететіні анық емес болды. SEO-да қосымша не? Егер біз ештеңе жазып, оны веб-сайтқа орналастырсақ — бұл функционалдық өнім бе? Біздің қажеттіліктерімізге IT терминологиясын бейімдеуге үш айдан астам уақытымыз кетті.
Біз Scrum-ды енгізуге қалай сәтсіздік жасадық
Біз Scrum-ды команда жасақтаудан бастадық. Және бірден екі қателік жасадық.
Қате №1. Біз контекст жарнамасы мен SEO мамандарын бір топқа кіргіздік. Логика мынадай: олар клиенттердің веб-сайттарына трафик тартып, сатуды арттыра отырып, бірге жұмыс істейді. Топ бір клиенттің айналасында бірігеді.
Проблеманы қалай шештік: біраз уақыттан кейін, біз мамандарды құндылықтар мен өнімдер бойынша бөлдік. Кейбір клиенттер бірнеше есеп менеджерлері мен топтарды бір сәтте алды.
Біз не түсінді: топ бизнес мақсатына негізделген бірігуі керек. Мұндай команда дербес және клиент үшін құн жасау мүмкіндігіне ие.
Қате №2. Біз бірден Scrum мастері мен өнім иесін кім болатынын анықтаған жоқпыз.
Проблеманы қалай шештік: біз қолда бар топтық бухгалтер лауазымын Scrum мастері функциясымен толықтырдық. Бұрын ол команда өнімділігін және клиентке үздіксіз құн жеткізуді басқарды. Біз өнім иесі болу үшін бөлек адам жалдадық.
Мен Scrum енгізетін компанияларда жиі екі қателіктерді кездестіремін:
- Топтар бір функцияның айналасына біріктірілген. Бөлім тек топқа ауыстырылған. Проблема мынада, егер клиент веб-сайт қажет болса, топта бағдарламашы, дизайнер және менеджер болу керек. Бренд менеджерлерінен құралған маркетинг бөлімінің веб-сайты болмайды.
- Компаниялар бар құрылымды бұзудан қорқады. Төмендегі мысал шын болды. Бір есеп менеджер бірнеше жобаны — әрбірі әр түрлі SEO мамандарымен қолданып отырды. Жобалар SEO мамандарының жүктелуіне байланысты бөлінді. Мысалы, маман әр түрлі приоритеті бар 10 жобаны алып отыр. Приоритет жобаның менеджері бойынша белгіленеді, ал осы компанияда бірнеше жобашы болды. Ең жақсы мысалда, SEO маманы ең ұғынықты тапсырманы орындады, ең нашар мысалында — есеп менеджерінің дауысы ең высокая болды.
“Дұрыс” топтарға бірігу — бұл ауыр процесс.
Scrum мастері не үшін қажет?
Toyota-да Scrum мастері рөлін үлгі ретінде көрсету үшін қызықты жағдай бар. Зауытта кейбір жұмысшылар механик-инженерге көмектесу үшін бекітілді. Механик-инженердің бағасы тым жоғары болды, сондықтан өнімділікті арттыру және шығындарды азайту қажет болды. Механик-инженердің дұрыс кілт іздегенін байқалды — содан кейін көмекші оның қажетті кілттерін жеткізу үшін тағайындалды. Процесті одан әрі жеңілдету үшін: құралдардың шаблондары еденде боялып, көмекші оларды жұмыс алдында таңертең орналастырды.
Сондықтан, жақсы Scrum мастері Scrum-ды енгізудің 80% табысын қамтамасыз етеді. Егер сізде осы рөлді өз мойнына алатын адам жоқ болса, осы салада әрі қарай жұмыс істеуге қызығушылық танытатын адамды табыңыз. Соңғы шара ретінде, IT компанияларында Scrum мастері іздеп көріңіз.
Scrum мастері мынаны қамтамасыз етеді:
- Команда қайда нәтижесі төмен екендігін, қайда жылдамдату мүмкіндігі бар екендігі және қайда баяулатудың жақсы екендігін сезіну. Бұл қысымшы мерзімдер мен хаостың қарсы қырануға ұқсайды.
- Команда үшін қауіпсіздік сезімін қамтамасыз ету. Бұл “кеше бәрін бітіру” деп айтатын клиенттен қорғауды қамтиды. Мысалы, біз клиенттер үшін есептерді ұзақ уақыт бойы даярлап жатқан проблемамен кездестік. Scrum мастері бастамасымен, біз автоматтандырылған есептерді әрекет ететін шын нақты кезеңде құрдық. Енді клиент ай соңын күтудің қажеті жоқ, жағдайдың қалай жүріп жатқанын түсіну үшін. Барлық тараптар риза.
- Команданы Scrum-ды ерікті таңдау деңгейімен көтеру.
- Әр команда мүшесімен бір-бірімен байланыс. Қызметкердің проблемалары мен қиындықтары. Осылайша, кіші мамандар орта деңгейге тез жетеді, ал орта мамандар аға деңгейге көтеріледі. Персоналдың ауысымдылығы төмендейді.
Өнім иесі не үшін қажет?
Біз бірден кім өнім иесі болатынын және оның не болатындығын түсінбедік. Біз өнім иесі – бұл өнім туралы жақсы білім алған және контекст пен SEO стратегияларын жасауға қабілетті техникалық маман деген қорытындыға келдік, оларды клиентке жеткізеді. Басқаша айтқанда, бұл не істеу керектігін айтатын стратег.
Біздің өнім иесі не істейді?
- артқы қалдықтарды қалыптастырады;
- тапсырмалардың приоритеттерін реттейді;
- команданың мәліметтері негізінде стратегияларды түзетеді;
- клиенттерге нәтиже үшін жауапты.
Біз IT емес компанияда Scrum-ды қалай енгіздік
Мамандар бұрыннан бөлек жұмыс істеді: копирайтерлер мен редакторлар, сілтеме құрушылар және SEO аналитиктері. Scrum енгізу кезінде біз оларды араластырдық. Әр командада клиенттерге құн жеткізетін есеп менеджері бар.
Әрбір SEO аумағында командалар қалыптастырылды:
- сілтеме массасын басқару
- мазмұн жасау
- веб-сайтты қайта өңдеу.
Жұмысты спринттерге бөлдік, ол айлық жоспарлаудың негізіне айналды. Жоспарлау кезінде ай соңында нәтиже алуда сәтсіздік қаупін азайтуға тырыстық.
Біз спринт ұзақтығы бойынша эксперимент жасап жатырмыз. Scrum-ды енгізуді алғаш бастағанда, спринттер апталық болды. Апталық спринт процесс тиімділігін тез тексеруге және қай жерде қате кеткендігіңді түсінуге, жұмыскерлерді үйретуге және барлық нәрсенің қалай жұмыс істейтінін түсінуге мүмкіндік береді.
Маркетингтегі Scrum спринттерінің ұзақтығына арналған негізгі кеңес: пайдалы нәрсені жасауға жеткілікті мерзімді таңдаңыз.
Спринттер келесідей көрінеді:
жоспарлау —> стендап —> демонстрация —> ретроспектива.
Біз командалардың кейбірін екі апталық спринттарға қайта бағыттадық. Есіңізде болсын, спринт неғұрлым ұзақ болса, мерзімдерді бұзбау қаупі соғұрлым жоғары болады.
Біз жұмыстарымызда келесі құралдарды пайдаланаамыз:
- покер жоспарлау. Бұл техника өнімді жасауда шешілуі тиіс тапсырмалардың қиындықтарын және ауқымын бағалауға мүмкіндік береді. Топтың барлық мүшелері покер жоспарлауына қатысады. Карта пайдаланып, олар тапсырмаларды бағалап, бірлесіп шешім қабылдайды;
- экстремалды программалау негізіндегі жұптық программаланың аналогы. Бірнеше адам бір жұмыс орындарында жұмыс істейді. Бұл ереже: “Екі бас – бірден жақсы” демонстративті мысал. Біз оны сындарлы сәттерде қолданамыз;
- HADI циклдары. Олар гипотезаларды тексеру алгоритмдері, олар тұтынушының сенімін қамтамасыз етеді. HADI циклдары туралы жоғарыда оқыңыз.
HADI циклдары қандай және оларды қалай пайдалануға болады?
Бұл не? HADI циклы гипотезаны тексеру алгоритмі, ол келесідей көрінеді:
гипотеза —> тексеру —> нәтиже —> қорытындылар.
HADI циклдары Lean Startup цикліне ұқсайды:
құру —> өлшеу —> үйрену
Бұл қалай жұмыс істейді?
Сіз орындалуы күмәнді гипотезаларды генерациялайсыз. Егер тапсырма түсінікті және қажетті болса, оны HADI циклінде өңдеу мағынасы жоқ. Гипотезаны тексергеннен кейін, оның жұмыс істеп тұрғанын немесе жоқтығын анықтайсыз, және қаншалықты тиімді екендігін. Егер ол жұмыс істесе, оны спринтке енгізесіз, егер жоқ болса, жай ғана тастайсыз.
Бұл қалай көрінеді?
Мысалы, “егер мен өнімдерде байланыстыру жасасам, бұл трафиктің үш есе өсуін қамтамасыз етеді” деген гипотеза бар. Сіз гипотезаны бір өнімде тексереді, ішкі сілтемелерді веб-сайтта қолмен орнатасыз. Егер гипотеза жұмыс істеп жатса, бағдарламашыларға тапсырма бересіз: “Веб-сайт бойынша байланыстыруды қамтамасыз етіңіз”.
HADI циклдарының артықшылығы қандай?
Клиентке сіздің жаңа шешіміңіз тиімді болмайды деп ойлауы мүмкін. Бұл жағдайда, сіз бір элемент негізінде нақты мысалды көрсетесіз.
Гипотезаларды тіркеңіз, тіпті олар жұмыс істемесе де. Келесі спринтте сіз басқа біреуін тексере аласыз. Сонымен қатар, сіздің эксперименттеріңіз конфликттік қызығушылық тудырмайтынына көз жеткізіңіз (мысалы, бір веб-бетке байланысты гипотезалар бір уақытта тексерілмеуі керек). Әйтпесе, қандай гипотеза сәтті болғаны анық болмайды.
IT емес компания болсаңыз, Scrum енгізу үшін 7 кеңес
- Оқытудан бастаңыз. Арнайы әдебиеттерді оқыңыз, тренингтерге барыңыз.
- Сіздің мүдделі тараптарыңызды анықтаңыз. Содан кейін клиентке және мүдделі тарапқа құн жеткізу үшін жұмыс жасаңыз.
- Спринттер бірдей болуы тиіс. Басқа нәрселерді өзгертіп қорықпаңыз.
- “Салқын” болғандықтан бүкіл топты Scrum-ға бағыттаңыз. Мысалы, біздің копирайтерлер Канбан бойынша жұмыс істейді, себебі тексттерде приоритеттер жоқ – олар тек жылдам аяқталуы қажет.
- Сіздің командаңыздың оңтайлы көлемін анықтаңыз. Менің тәжірибем бойынша, IT емес компанияларда бес-жеті адам.
- Әр командаға жеке жұмыс аймағын ұйымдастырыңыз. Егер сізде ашық кеңсе болса, оффлайн Scrum тақталарын қосыңыз.
- Scrum енгізуді басқару. Егер басқару жаңа әдістеменің мақсатын түсінбесе, ештеңе орындалмайды.