Այս հոդվածում ես կկիսվեմ իմ փորձով մեր արտադրանքի ֆունկցիոնալությունը զարգացնելու գաղափարների ընտրության հարցում և կպատմեմ ձեզ, թե ինչպես պահպանել զարգացման հիմնական վեկտորները:
Մենք մշակում ենք հաշվարկային ավտոմատացված համակարգ (ACP)՝ բիլինգ։ Ժամկետ
Մեր արտադրանքի կյանքը 14 տարի է: Այս ընթացքում համակարգը արդյունաբերական սակագնային համակարգի առաջին տարբերակներից վերածվել է մոդուլային համալիրի՝ բաղկացած 18 ապրանքներից, որոնք լրացնում են միմյանց: Ծրագրերի երկարակեցության կարևորագույն կողմերից մեկը մշտական զարգացումն է: Իսկ զարգացումը գաղափարներ է պահանջում։
Գաղափարներ
Տեղեկատվության աղբյուրներ
Կան 5 աղբյուր.
- Կորպորատիվ տեղեկատվական համակարգերի մշակողի գլխավոր ընկերն է հաճախորդ. Իսկ հաճախորդը որոշում կայացնողների, նախագծերի հովանավորների, գործընթացների սեփականատերերի և կատարողների, ներքին ՏՏ մասնագետների, սովորական օգտատերերի և տարբեր աստիճանի շահագրգիռ անհատների հավաքական կերպար է: Մեզ համար կարևոր է, որ հաճախորդի յուրաքանչյուր ներկայացուցիչ լինի գաղափարների պոտենցիալ մատակարար: Վատագույն դեպքում մենք միայն բացասական արձագանք ենք ստանում համակարգում առկա խնդիրների մասին։ Լավագույն դեպքում, հաճախորդի կողքին կա մարդ, ով բարելավման գաղափարների մշտական աղբյուր է՝ տրամադրելով կառուցվածքային տեղեկատվություն հաճախորդի կարիքների մասին:
- Մեր վաճառողներ և հաշվի մենեջերներ բարելավման գաղափարների երկրորդ կարևոր աղբյուրն են: Նրանք ակտիվորեն և լայնորեն շփվում են ոլորտի ներկայացուցիչների հետ և պոտենցիալ հաճախորդներից առաջին ձեռքից հարցումներ են ստանում բիլինգի ֆունկցիոնալության վերաբերյալ: Վաճառողները և հաշիվները պետք է տեղյակ լինեն իրենց ֆունկցիոնալության բոլոր էական փոփոխություններին և մրցակիցների ծրագրային ապահովման վերջին թարմացումներին և կարողանան հիմնավորել տարբեր լուծումների դրական և բացասական կողմերը: Սրանք մեր աշխատակիցներն են, ովքեր առաջինն են զգում, թե արդյոք որոշ հաշվարկային հնարավորություններ դառնում են դե ֆակտո ստանդարտ, առանց որի ծրագրակազմը չի կարող ամբողջական համարվել:
- Ապրանքի սեփականատեր — մեր թոփ մենեջերներից մեկը կամ շատ փորձառու նախագծի ղեկավար: Մտքում պահում է ընկերության ռազմավարական նպատակները և դրանց համապատասխան ճշգրտում արտադրանքի զարգացման պլանները:
- Ճարտարապետ, մարդ, ով հասկանում է ընտրված/օգտագործված տեխնոլոգիական լուծումների հնարավորություններն ու սահմանափակումները և դրանց ազդեցությունը արտադրանքի զարգացման վրա։
Մշակման և փորձարկման թիմեր. Մարդիկ, ովքեր անմիջականորեն ներգրավված են արտադրանքի մշակման մեջ:
Հարցումների դասակարգում
Մենք հում տվյալներ ենք ստանում աղբյուրներից՝ նամակներ, տոմսեր, բանավոր հարցումներ: Բոլորը
բողոքները դասակարգվում են.
- Խորհրդակցություններ «Ինչպե՞ս անել», «Ինչպե՞ս է դա աշխատում», «Ինչու չի ստացվում», «Չեմ հասկանում...» իմաստներով: Այս տեսակի հարցումները գնում են 1-ին մակարդակի աջակցության գիծ: Խորհրդատվությունը հնարավոր է վերապատրաստել այլ տեսակի հարցումների մեջ:
- Միջադեպեր «Չի աշխատում» և «Սխալ» իմաստներով: Մշակվում է 2 և 3 աջակցության տողերով: Եթե անհապաղ ուղղումներ և կարկատանի թողարկում են անհրաժեշտ, դրանք կարող են փոխանցվել աջակցությունից անմիջապես մշակման: Հնարավոր է վերադասակարգել այն որպես փոփոխության հարցում և ուղարկել հետնախագահ:
- Փոփոխությունների և զարգացման հարցումներ. Նրանք մտնում են ապրանքի հետքաղություն՝ շրջանցելով աջակցության գծերը։ Բայց դրանց համար առանձին մշակման կարգ կա։
Հարցումների վերաբերյալ վիճակագրություն կա՝ թողարկումից անմիջապես հետո հարցումների թիվը կարճ ժամանակով ավելանում է 10-15%-ով։ Կան նաև հարցումների աճ, երբ մեծ թվով օգտվողներով նոր հաճախորդ գալիս է մեր ամպային ծառայություններին: Մարդիկ սովորում են օգտագործել ծրագրային ապահովման նոր հնարավորությունները, նրանց խորհուրդ է պետք: Նույնիսկ փոքր հաճախորդը, երբ սկսում է աշխատել համակարգում, հեշտությամբ այրում է ամսական ավելի քան 100 ժամ խորհրդատվություն: Հետևաբար, նոր հաճախորդին միացնելիս մենք միշտ ժամանակ ենք վերապահում նախնական խորհրդատվությունների համար: Հաճախ նույնիսկ կոնկրետ մասնագետ ենք ընտրում։ Վարձակալության գինը, իհարկե, չի ծածկում այս աշխատանքային ծախսերը, սակայն ժամանակի ընթացքում իրավիճակը հարթվում է։ Հարմարվողականության շրջանը սովորաբար տևում է 1-ից 3 ամիս, որից հետո խորհրդատվության կարիքը զգալիորեն կրճատվում է։
Նախկինում մենք օգտագործում էինք ինքնուրույն գրավոր լուծումներ՝ հարցումները պահելու համար: Բայց մենք աստիճանաբար անցանք Atlassian արտադրանքին։ Նախ, մենք տեղափոխեցինք զարգացում, որպեսզի հեշտացնենք աշխատել ըստ Agile-ի, ապա աջակցություն: Այժմ բոլոր կրիտիկական գործընթացները ապրում են Jira SD-ում, գումարած, դրանք աջակցվում են Jira-ի տարբեր պլագիններով, գումարած Confluence: Ինքնագրված լուծումները մնացին միայն այն գործընթացների համար, որոնք կարևոր չէին ընկերության գործունեության համար: Ստացվում է, որ մեր առաջադրանքները այժմ խաչաձև են և կարող են փոխանցվել աջակցության և զարգացման միջև՝ առանց մի համակարգից մյուսը անցնելու:
Այս հղումից մենք կարող ենք ստանալ տվյալներ բոլոր առաջադրանքների, պլանավորված և փաստացի աշխատուժի ծախսերի վերաբերյալ, օգտագործել գնագոյացման տարբեր տարբերակներ հաճախորդների համար և ստեղծել փաստաթղթեր ներքին կարիքների համար և հաշվետվություններ ներկայացնել հաճախորդներին:
Փոփոխության հարցումների մշակում
Սովորաբար, նման հարցումները գալիս են ֆունկցիոնալության պահանջների տեսքով: Մեր վերլուծաբանն ուսումնասիրում է հարցումը, ստեղծում է հստակեցում և բարձր մակարդակի տեխնիկական բնութագրեր: Հստակեցումը և տեխնիկական բնութագրերը փոխանցում է այն անձին, ով ներկայացրել է այս հարցումը հաստատման համար. մենք պետք է վստահ լինենք, որ մենք խոսում ենք նույն լեզվով հաճախորդի հետ:
Հաճախորդից ստանալով հաստատում, որ մենք ճիշտ ենք հասկացել միմյանց, վերլուծաբանը հարցումը մուտքագրում է ապրանքի հետքաշում:
Արտադրանքի ֆունկցիոնալ կառավարում
Հետագնացությունը կուտակում է փոփոխությունների և զարգացման մուտքային հարցումները: Տեխնիկական խորհուրդը, որը բաղկացած է տնօրենից, աջակցության, զարգացման, վաճառքի և համակարգի ճարտարապետից, հավաքվում է վեց ամիսը մեկ։ Քննարկման ձևաչափով խորհուրդը վերլուծում և առաջնահերթություն է տալիս առկա հայտերը և համաձայնեցնում է զարգացման 5 առաջադրանքները հաջորդ թողարկումում իրականացնելու համար:
Փաստորեն, տեխնիկական խորհուրդը արձագանքում է արդյունաբերության և շուկայի պահանջներին՝ վերանայելով դիմումներում արտահայտված կարիքները: Այն ամենը, ինչ քիչ արդիական է, մնում է հետին պլանում և չի հասնում զարգացման։
Փոփոխության հարցումների և ֆինանսների դասակարգում
Զարգացումը թանկ է. Հետևաբար, մենք անմիջապես կպատմենք ձեզ, թե ինչ տարբերակներ կարող ենք ունենալ, եթե փոփոխության հարցումը ստացվել է հաճախորդից և ոչ թե աշխատողից:
Փոփոխության հարցումները մենք դասակարգում ենք հետևյալ կերպ. արդյունաբերության կարիք կամ ձեռնարկության անհատական բնութագիր. զգալի քանակությամբ նոր ֆունկցիոնալություն կամ աննշան ուղղում: Փոքր շտկումները և անհատական հարցումները մշակվում են առանց որևէ նրբության: Անհատական հարցումները հաշվարկվում և իրականացվում են կոնկրետ հաճախորդի համար որպես նրա հետ նախագծային աշխատանքի մի մաս:
Եթե սա արդյունաբերության զանգվածային կարիք չէ, և ֆունկցիոնալության ծավալը մեծ է, ապա կարող է որոշում կայացվել մշակել նոր առանձին մոդուլ, որը կվաճառվի հիմնական ֆունկցիոնալությունից բացի: Եթե հաճախորդից ստացվում է նման խնդրանք, մենք կարող ենք ստանձնել մոդուլի մշակման ծախսերը, հաճախորդին տրամադրել մոդուլը անվճար կամ մասնակի վճարումով և ինքնին մոդուլը հանել վաճառքի: Նման իրավիճակում հաճախորդն իր վրա է վերցնում մեթոդաբանական բեռի մի մասը և, ըստ էության, իր վրա է իրականացնում մոդուլի փորձնական իրականացումը:
Եթե սա արդյունաբերության զանգվածային կարիք է, ապա կարող է որոշում կայացվել բազային արտադրանքում նոր գործառույթներ ներառելու մասին: Ծախսերն այս դեպքում ամբողջությամբ ընկնում են մեզ վրա, և նոր ֆունկցիոնալությունը հայտնվում է ծրագրերի ընթացիկ տարբերակում:
Հին հաճախորդներին տրամադրվում է թարմացում:
Կարող է նաև լինել, որ մի քանի հաճախորդներ ունեն նմանատիպ կարիք, բայց դա չի համապատասխանում զանգվածային արտադրանքի: Այս դեպքում մենք կարող ենք ճշգրտումն ուղարկել այս հաճախորդներին և առաջարկել նրանց միջև բաժանել զարգացման ծախսերը: Ի վերջո, բոլորը հաղթում են. հաճախորդները ստանում են ցածր գնով իրականացվող ֆունկցիոնալությունը, մենք հարստացնում ենք ապրանքը, և որոշ ժամանակ անց շուկայի մյուս մասնակիցները նույնպես կարող են ստանալ իրենց օգտագործման ֆունկցիոնալությունը:
DevOps
Մշակումը պատրաստում է տարեկան երկու հիմնական թողարկում: Յուրաքանչյուր թողարկումում ժամանակ է վերապահված տեխնիկական խորհրդից ստացված 5 առաջադրանքների իրականացմանը։ Այսպիսով, առօրյայի մեջ մենք երբեք չենք մոռանում արտադրանքի մշակման մասին:
Յուրաքանչյուր թողարկում ենթարկվում է համապատասխան փորձարկումների և փաստաթղթերի: Հաջորդը, այս թողարկումը տեղադրվում է համապատասխան հաճախորդի թեստային միջավայրում, որն էլ իր հերթին մանրակրկիտ ստուգում է ամեն ինչ և միայն դրանից հետո թողարկումը տեղափոխվում է արտադրություն։
Բացի թողարկման համակարգից, կա վրիպակների արագ շտկման ձևաչափ, որպեսզի հաճախորդները վեց ամիս չապրեն սխալներով: Այս միջանկյալ ձևաչափը թույլ կտա արագ արձագանքել առաջին առաջնահերթ միջադեպերին և կատարել նշված SLA-ները:
Վերոհիշյալ բոլորը հիմնականում վերաբերում են կորպորատիվ հատվածին և ներտնային լուծումներին: SMB սեգմենտին ուղղված ամպային ծառայությունների համար հաճախորդների համար արտադրանքի մշակմանը մասնակցելու նման լայն հնարավորություններ չկան: SMB-ի վարձույթի ձևաչափը նույնիսկ դա չի ենթադրում: Կորպորատիվ կողմի հստակ պահանջների տեսքով փոփոխության խնդրանքի փոխարեն, այստեղ կա միայն սովորական արձագանքներ և ցանկություններ ծառայության համար: Մենք փորձում ենք լսել, բայց արտադրանքը զանգվածային է, և մեկ հաճախորդի ցանկությունը՝ բերելու ինչ-որ ծանոթ իր հին պատմական համակարգից, կարող է հակասել ընդհանուր համակարգի զարգացման ռազմավարությանը:
Source: www.habr.com