Արտադրանքի թարմացումների մեծ մասը ձախողվում է, քանի որ ասում է ինչ է թողարկվել, բայց չի ցույց տալիս ինչ է իրականում փոխվել օգտատերի համար։ Այս հոդվածում կսովորեք գրել թարմացումներ այնպես, կարծես diff-վերլուծություն է, պարզ ձևով նկարագրելով նախկին և նոր վարքագիծը և բացատրելով փոփոխության պատճառը։
Արտադրանքի թարմացումները պարզապես հայտարարություններ չեն։ Դրանք թարգմանություն են այն բանի միջև, ինչ ձեր թիմը ստեղծել է, և այն բանի, ինչ ձեր հաճախորդները վաղը պետք է անեն այլ կերպ։ Երբ թարմացումները մշուշոտ են, օգտատերը զգում է դիմադրություն. ինչ-որ բան տեղափոխվել է, ինչ-որ բան այլ կերպ է աշխատում, ինչ-որ բան «կարծես դանդաղել է», և արդյունքում աճում են հարցումները աջակցությանը, նվազում է ընդունումը, և խաթարվում է վստահությունը։
Գործնական մոտեցում է դիտարկել յուրաքանչյուր թարմացում որպես diff-վերլուծություն։ Ծրագրավորման մեջ diff-ը ցույց է տալիս, թե կոնկրետ ինչ է փոխվել. ինչն է ավելացվել, հեռացվել կամ փոփոխվել։ Օգտատերերին նույն հստակությունն է պետք, պարզապես արտադրանքի լեզվով։ «Վահանակը բարելավվել է» փոխարեն օգտակար է ասել. «Ֆիլտրը հիմա լռելյայն դրված է վերջին 30 օրերի վրա, ոչ թե 7, որպեսզի հաշվետվությունները համընկնեն ձեր հաշիվների շրջանի հետ»։ Սա է տարբերությունը ինֆորմացիայի և հասկացողության միջև։
Շատ թողարկման նշումներ թվարկում են ֆունկցիաները, բայց հաճախորդները փոփոխությունը գնահատում են արդյունքների և սովորությունների միջոցով։ Նրանք մտածում են. արդյո՞ք իմ աշխատանքային ընթացքը կխաթարվի, արդյո՞ք արդյունքները կփոխվեն, արդյո՞ք պետք է թիմին վերապատրաստեմ։ Եթե դուք չեք պատասխանում այս հարցերին, թարմացումը դառնում է ֆոնային աղմուկ, կամ վատագույն դեպքում անակնկալ։
Լավ թարմացումը կապում է չորս շերտ.
Եթե շերտերից մեկը բացակայում է, օգտատերը ստիպված է ենթադրել։ Ենթադրությունը թանկ է և ստեղծում է անորոշություն։
Կարող եք թարմացումները դարձնել զգալիորեն հստակ, եթե յուրաքանչյուր կարևոր փոփոխություն ներկայացնեք որպես փոքր diff։ Օգտագործեք այս կառուցվածքը շարունակաբար.
Նկարագրեք նախորդ վարքագիծը պարզ լեզվով։ Առանց մեղադրելու անցյալը, պարզապես ասեք ինչպես էր աշխատում։
Նկարագրեք նոր վարքագիծը, ներառյալ UI-ի փոփոխությունները և հիմքում ընկած կանոնները (լռելյայններ, սահմանափակումներ, եզրային դեպքեր)։
Բացատրեք պատճառը, ցանկալի է կապելով օգտատիրոջ նպատակի կամ չափելի խնդրի հետ (արագություն, ավելի քիչ սխալներ, ավելի լավ կոնվերսիա, ռիսկի նվազեցում)։
Տվեք մեկ հստակ առաջարկվող քայլ։ Եթե քայլ չի պահանջվում, դա էլ ասեք ուղիղ։
Այս մոտեցումը կանխում է «հայտարարության մշուշը» և հեշտացնում է, որ Customer Success-ը և վաճառքը նույն կերպ փոխանցեն հաղորդագրությունը։
Ստորև օրինակներ են, որոնք ցույց են տալիս, թե նույն թարմացումը ինչպես կարող է շփոթեցնել կամ պարզաբանել։
Մշուշոտ. «Մենք բարելավեցինք ծանուցումների կարգավորումները ավելի լավ փորձի համար»։
Diff-ոճով.
Մշուշոտ. «Մենք վերադասավորեցինք նավիգացիան»։
Diff-ոճով.
Փոքր փոփոխություններն էլ են կոտրում սովորությունը, և diff-ոճը դա հարգում է։
Մշուշոտ. «Մենք արագացրինք հավելվածը»։
Diff-ոճով.
Եթե հայտարարում եք բարելավում, չափեք և ներկայացրեք թվերով։ Դա թերահավատությունը դարձնում է վստահություն։
Ոչ ամեն փոփոխություն է արժանի լայն հաղորդագրության։ Նպատակը ավելի շատ հրապարակելը չէ, այլ այն, ինչը փոխում է որոշումները։ Օգտագործեք այս ֆիլտրերը.
Փոքր բագերի շտկումները կարող են մնալ changelog-ում, բայց աշխատանքային և արդյունքային փոփոխությունները պահանջում են պատմություն և ուղղորդում։
Օգտատերերին պետք չեն ներքին քննարկումները։ Պետք է կարճ և հավատալի պատճառ։ Սովորաբար «ինչու»-ն տեղավորվում է այս խմբերում.
Նույնիսկ կատարյալ հայտարարությունը ձախողվում է, եթե այն սխալ ալիքով է հասնում։ Շատ թիմեր հույս են դնում միայն մեկ վայրի վրա (բլոգ կամ changelog), բայց օգտատերերը աշխատում են տարբեր միջավայրերում։ Գործնական բաշխման խառնուրդը կարող է լինել հետևյալը.
Այստեղ ավտոմատացումը կարող է որոշիչ լինել «հրապարակեցինք» և «հաճախորդը հասկացավ» տարբերության մեջ։ Staffono.ai (https://staffono.ai) կարող է աշխատել որպես 24/7 AI աշխատակից WhatsApp-ում, Instagram-ում, Telegram-ում, Facebook Messenger-ում և web chat-ում, պատասխանելով «ինչ է փոխվել» հարցերին նույն diff-հստակությամբ։ Հաճախորդը չի սպասում աջակցությանը, այլ հարցնում է իր նախընտրած ալիքով և ստանում է միատեսակ պատասխան։
Թարմացումն ուղարկելուց հետո սկսվում է իրական աշխատանքը. հարցեր, եզրային դեպքեր, շփոթություն, ներքին ուսուցում։ Լավ թիմերը նախօրոք պատրաստում են FAQ և օրինակներ։
Յուրաքանչյուր խոշոր թարմացման համար կազմեք «ազդեցության փաթեթ».
Եթե օգտագործում եք Staffono.ai, կարող եք այս FAQ-ները տեղադրել ձեր մեսենջերային ավտոմատացված հոսքերում, որպեսզի AI աշխատակիցը անմիջապես լուծի կրկնվող հարցերը, բարդ դեպքերը ուղղորդի մարդու մոտ, և նաև հավաքի հետադարձ կապ այն մասին, թե ինչն է դեռ անհասկանալի։ Ժամանակի ընթացքում դուք կունենաք չափելի հաղորդակցություն. կտեսնեք ինչ են հարցնում, որտեղ են խրվում, և ինչ փաստաթուղթ է պետք բարելավել։
Հրապարակումը վերջը չէ։ Պետք են ազդանշաններ, որ օգտատերը հասկացավ և կիրառեց փոփոխությունը։ Ընտրեք մի քանի մետրիկա ըստ թարմացման տեսակի.
Քանի որ Staffono.ai-ն աջակցում է messaging-first շփումներին, այն կարող է օգնել նաև թարմացումից հետո արագ հավաքել կարծիք մեծ ծավալով։ Օրինակ, երբ օգտատերը ավարտում է նոր հոսքը, AI աշխատակիցը կարող է տալ մեկ կարճ հարց. «Նոր քայլը ժամանակ խնայե՞ց, այո թե ոչ» և պիտակավորել պատասխանները արտադրանքի թիմի համար։
Հաջորդ հայտարարության համար օգտագործեք այս կառուցվածքը յուրաքանչյուր կարևոր փոփոխության համար.
Եթե սա ճիշտ եք անում, թարմացումները դառնում են կուտակվող ակտիվ. նվազեցնում են աջակցությունը, բարձրացնում են ընդունումը և սովորեցնում են հաճախորդներին, թե ինչպես եք մտածում։
Եթե ցանկանում եք, որ ձեր թարմացումները հասնեն այն նույն ալիքներին, որտեղ ձեր հաճախորդներն արդեն հաղորդակցվում են, և այդ հայտարարությունները վերածվեն անմիջապես օգտակար պատասխանների ցանկացած ժամի, Staffono.ai (https://staffono.ai) կարող է օգնել։ AI աշխատակիցներով, որոնք կառավարում են հաճախորդների խոսակցությունները հանրահայտ մեսենջերներում և web chat-ում, դուք կարող եք վստահությամբ թողարկել փոփոխություններ, պահել օգտատերերին տեղեկացված իրական ժամանակում և ազատել թիմի ուշադրությունը հաջորդ թողարկման համար։