Թիմ Լիսթեր - գրքերի համահեղինակ
- «Մարդկային գործոն. Հաջողակ նախագծեր և թիմեր» (բնօրինակ գիրքը կոչվում է «Peopleware»)
- «Վալս արջերի հետ. ռիսկերի կառավարում ծրագրային նախագծերում»
- «Ադրենալինի խենթ և զոմբիացված օրինաչափություններով. Ծրագրի թիմերի վարքագծի ձևերը»
Այս բոլոր գրքերը դասական են իրենց ոլորտում և գրվել են գործընկերների հետ միասին . Ռուսաստանում նրա գործընկերներն առավել հայտնի են. и , ով գրել է նաև բազմաթիվ հայտնի գործեր։
Թիմը 40 թվականին ծրագրային ապահովման մշակման 1975 տարվա փորձ ունի (այս տարի գրողներից ոչ մեկը չի ծնվել), Թիմն արդեն եղել է Yourdon Inc-ի գործադիր փոխնախագահը։ Այժմ նա իր ժամանակն անցկացնում է խորհրդատվության, դասավանդման և գրելու վրա՝ երբեմն այցելություններ կատարելով համաժողովներ ամբողջ աշխարհում:
Հատուկ Habr-ի համար հարցազրույց ենք արել Թիմ Լիստերի հետ։ Նա կբացի DevOops 2019 կոնֆերանսը, և մենք շատ հարցեր ունենք՝ գրքերի և այլնի վերաբերյալ: Հարցազրույցը վարում են Միխայիլ Դրուժինինը և Օլեգ Չիրուխինը կոնֆերանսի ծրագրի կոմիտեից։
Մայքլ. Կարո՞ղ եք մի քանի խոսք ասել այն մասին, թե ինչով եք այժմ զբաղվում։
Թիմ. Ես Atlantic Systems Guild-ի ղեկավարն եմ: Գիլդիայում մենք վեց հոգի ենք, մենք մեզ տնօրեն ենք անվանում: Երեքը ԱՄՆ-ում և երեքը Եվրոպայում, այդ իսկ պատճառով Գիլդիան կոչվում է Ատլանտիկ: Մենք այնքան երկար տարիներ միասին ենք, որ ուղղակի չես կարող հաշվել: Մենք բոլորս ունենք մեր մասնագիտությունները: Ես աշխատել եմ հաճախորդների հետ վերջին տասնամյակում կամ ավելի: Իմ նախագծերը ներառում են ոչ միայն կառավարում, այլ նաև պահանջների ձևավորում, ծրագրի պլանավորում և գնահատում: Թվում է, թե վատ սկսվող նախագծերը սովորաբար վատ են ավարտվում։ Հետևաբար, արժե համոզվել, որ բոլոր գործողություններն իսկապես լավ մտածված և համակարգված են, որ ստեղծագործողների գաղափարները համակցված են: Արժե մտածել, թե ինչ եք անում և ինչու: Ինչ ռազմավարություններ օգտագործել նախագիծն ավարտին հասցնելու համար:
Ես երկար տարիներ խորհուրդ եմ տալիս հաճախորդներին տարբեր ձևերով: Հետաքրքիր օրինակ է մի ընկերություն, որը ռոբոտներ է պատրաստում ծնկի և ազդրի վիրահատության համար: Վիրաբույժը լիովին ինքնուրույն չի վիրահատում, այլ օգտագործում է ռոբոտ։ Անվտանգությունն այստեղ, անկեղծ ասած, կարևոր է: Բայց երբ փորձես պահանջներ քննարկել մարդկանց հետ, ովքեր կենտրոնացած են խնդիրների լուծման վրա... Տարօրինակ կհնչի, բայց ԱՄՆ-ում կա. (Դեղերի դաշնային վարչություն), որը լիցենզավորում է այս ռոբոտների նման արտադրանքը: Նախքան որևէ բան վաճառելը և այն օգտագործել կենդանի մարդկանց վրա, դուք պետք է լիցենզիա ստանաք: Պայմաններից մեկն այն է, որ ցույց տաք ձեր պահանջները, թե որոնք են թեստերը, ինչպես եք դրանք փորձարկել, ինչպիսին են թեստի արդյունքները։ Եթե դուք փոխում եք պահանջները, ապա դուք պետք է նորից ու նորից անցնեք այս հսկայական փորձարկման գործընթացը: Մեր հաճախորդներին հաջողվել է հավելվածների վիզուալ դիզայնը ներառել իրենց պահանջների մեջ։ Նրանք ուղղակիորեն սքրինշոթներ ունեին որպես պահանջների մաս: Մենք պետք է հանենք դրանք և բացատրենք, որ այս բոլոր ծրագրերը մեծ մասամբ ոչինչ չգիտեն ծնկների և կոնքերի մասին, տեսախցիկի հետ կապված այս բոլոր բաները և այլն: Մենք պետք է վերաշարադրենք պահանջների փաստաթղթերը, որպեսզի դրանք երբեք չփոխվեն, եթե չփոխվեն իսկապես կարևոր հիմքում ընկած պայմանները: Եթե տեսողական դիզայնը պահանջների մեջ չէ, արտադրանքի թարմացումը շատ ավելի արագ կլինի: Մեր խնդիրն է գտնել այն տարրերը, որոնք վերաբերում են ծնկի, կոնքերի, մեջքի վիրահատություններին, դրանք հանել առանձին փաստաթղթերի մեջ և ասել, որ դրանք են լինելու հիմնարար պահանջները: Եկեք ծնկի վիրահատությունների վերաբերյալ պահանջների առանձին խումբ կազմենք: Սա թույլ կտա մեզ ստեղծել ավելի կայուն պահանջների շարք: Մենք կխոսենք ամբողջ արտադրանքի գծի մասին, այլ ոչ թե կոնկրետ ռոբոտների:
Շատ աշխատանք կատարվեց, բայց նրանք դեռ հասան այն վայրերին, որտեղ նախկինում նրանք շաբաթներ ու ամիսներ էին անցկացնում կրկնվող թեստերի առանց իմաստի կամ անհրաժեշտության, քանի որ թղթի վրա նկարագրված նրանց պահանջները չէին համընկնում իրական պահանջների հետ, որոնց համար կառուցվել էին համակարգերը: FDA-ն ամեն անգամ նրանց ասում էր. ձեր պահանջները փոխվել են, այժմ դուք պետք է ամեն ինչ ստուգեք զրոյից: Ամբողջ արտադրանքի ամբողջական վերաստուգումները սպանեցին ձեռնարկությանը:
Այսպիսով, կան այնպիսի հրաշալի առաջադրանքներ, երբ հայտնվում ես ինչ-որ հետաքրքիր բանի հենց սկզբում, և հենց առաջին գործողությունները սահմանում են խաղի հետագա կանոնները։ Եթե դուք համոզվեք, որ այս վաղ գործունեությունը սկսում է լավ աշխատել ինչպես կառավարչական, այնպես էլ տեխնիկական տեսանկյունից, ապա հավանականություն կա, որ դուք կհայտնվեք հիանալի նախագծի հետ: Բայց եթե այս մասը դուրս է եկել ռելսերից և ինչ-որ տեղ սխալվել է, եթե դուք չեք կարող գտնել հիմնարար համաձայնությունները... ոչ, այնպես չէ, որ ձեր նախագիծը անպայմանորեն ձախողվելու է: Բայց դուք այլևս չեք կարողանա ասել. «Մենք հիանալի արեցինք, մենք ամեն ինչ արեցինք իսկապես արդյունավետ»: Սրանք այն բաներն են, որոնք ես անում եմ հաճախորդների հետ շփվելիս:
Մայքլ. Այսինքն՝ դուք նախագծեր եք սկսում, ինչ-որ մեկնարկ եք անում և ստուգում, որ ռելսերը ճիշտ ուղղությամբ են գնում։
Թիմ. Մենք նաև գաղափարներ ունենք, թե ինչպես կարելի է միավորել փազլի բոլոր մասերը. ինչ հմտություններ են մեզ անհրաժեշտ, կոնկրետ երբ են դրանք անհրաժեշտ, ինչպիսին է թիմի միջուկը և նման այլ հիմնարար բաներ: Մեզ պետք են լրիվ դրույքով աշխատողներ, թե՞ կարող ենք ինչ-որ մեկին վարձել կես դրույքով: Պլանավորում, կառավարում. Հարցեր, ինչպիսիք են. Ի՞նչն է առավել կարևոր այս նախագծի համար: Ինչպե՞ս հասնել դրան: Ի՞նչ գիտենք այս ապրանքի կամ նախագծի մասին, որո՞նք են ռիսկերը և որտեղ են անհայտները, ինչպե՞ս ենք վարվելու այս ամենի հետ: Իհարկե, այս պահին ինչ-որ մեկը սկսում է բղավել «Իսկ արագաշարժ»: Լավ, դուք բոլորդ ճկուն եք, բայց ի՞նչ: Կոնկրետ ի՞նչ տեսք ունի նախագիծը, ինչպե՞ս եք պատրաստվում այն հանել նախագծին համապատասխան: Դուք չեք կարող պարզապես ասել, որ «մեր մոտեցումը ձգվում է ամեն ինչի, մենք Scrum թիմ ենք»: Սա անհեթեթություն է և անհեթեթություն: Հաջորդը ո՞ւր եք գնալու, ինչո՞ւ պիտի աշխատի, ո՞ւր է իմաստը։ Ես սովորեցնում եմ իմ հաճախորդներին մտածել այս բոլոր հարցերի շուրջ:
19 տարի արագաշարժ
Մայքլ. Agile-ում մարդիկ հաճախ փորձում են նախապես ոչինչ չսահմանել, այլ որոշումներ կայացնել որքան հնարավոր է ուշ՝ ասելով. «Մենք շատ մեծ ենք, չեմ մտածի ընդհանուր ճարտարապետության մասին»: Փոխարենը ես չեմ մտածի մի շարք այլ բաների մասին, ես հենց հիմա կմատուցեմ հաճախորդին մի բան, որն աշխատում է:
Թիմ. Կարծում եմ, որ արագաշարժ մեթոդոլոգիաները, սկսած 2001 թվականին բացեց ոլորտի աչքերը: Բայց մյուս կողմից, ոչինչ կատարյալ չէ։ Ես բոլորը կրկնվող զարգացման կողմնակից եմ: Նախագծերի մեծ մասում կրկնությունը շատ իմաստ ունի: Բայց հարցը, որի մասին պետք է մտածեք, հետևյալն է. երբ ապրանքը դուրս է գալիս և օգտագործվում, որքա՞ն ժամանակ է այն պահպանվում: Արդյո՞ք սա այն ապրանքն է, որը կծառայի վեց ամիս՝ նախքան այլ բանով փոխարինելը: Թե՞ սա արտադրանք է, որը կաշխատի շատ ու շատ տարիներ: Անուններ, իհարկե, չեմ նշի, բայց... Նյու Յորքում և նրա ֆինանսական համայնքում ամենահիմնական համակարգերը շատ հին են։ Սա զարմանալի է: Դուք նայում եք նրանց և մտածում, եթե միայն կարողանայիք ժամանակի հետ վերադառնալ 1994 թվական և ծրագրավորողներին ասել. «Ես եկել եմ ապագայից՝ 2019 թվականից: Պարզապես զարգացրեք այս համակարգը այնքան ժամանակ, որքան ձեզ անհրաժեշտ է: Դարձրեք այն ընդարձակելի, մտածեք ճարտարապետության մասին: Այնուհետև այն կբարելավվի ավելի քան քսանհինգ տարի: Եթե մի փոքր հետաձգեք զարգացումը, իրերի մեծ սխեմայի մեջ ոչ ոք չի նկատի»: Երկարաժամկետ հեռանկարում իրերը գնահատելիս պետք է հաշվի առնել, թե ընդհանուր առմամբ որքան կարժենա: Երբեմն լավ մշակված ճարտարապետությունը իսկապես արժե այն, իսկ երբեմն՝ ոչ: Մենք պետք է նայենք մեր շուրջը և հարցնենք ինքներս մեզ՝ արդյոք մենք ճիշտ իրավիճակում ենք նման որոշման համար:
Այսպիսով, գաղափարը, ինչպիսին է «Մենք արագաշարժության համար ենք, հաճախորդն ինքն է մեզ կասի, թե ինչ է ուզում ստանալ» - դա չափազանց միամիտ է: Հաճախորդները նույնիսկ չգիտեն, թե ինչ են ուզում, և նույնիսկ ավելին, նրանք չգիտեն, թե ինչ կարող են ստանալ: Ոմանք կսկսեն որպես փաստարկ պատմական օրինակներ բերել, սա արդեն տեսել եմ։ Բայց տեխնիկապես զարգացած մարդիկ սովորաբար դա չեն ասում: Նրանք ասում են. «Սա 2019 թվականն է, սրանք այն հնարավորություններն են, որոնք մենք ունենք, և մենք կարող ենք ամբողջությամբ փոխել այս բաների մեր հայացքը»: Գոյություն ունեցող լուծումները ընդօրինակելու, դրանք մի փոքր ավելի գեղեցիկ և սանրված դարձնելու փոխարեն, երբեմն պետք է դուրս գալ և ասել. «Եկեք ամբողջությամբ վերահայտնենք այն, ինչ մենք փորձում ենք անել այստեղ»:
Եվ ես չեմ կարծում, որ հաճախորդների մեծ մասը կարող է այդպես մտածել խնդրի մասին: Նրանք տեսնում են միայն այն, ինչ արդեն ունեն, վերջ։ Որից հետո նրանք գալիս են այնպիսի խնդրանքներով, ինչպիսիք են՝ «եկեք դա մի քիչ ավելի պարզ դարձնենք» կամ այն, ինչ նրանք սովորաբար ասում են: Բայց մենք մատուցող կամ մատուցողուհի չենք, որ ինչքան էլ հիմարություն լինի, կարող ենք պատվեր ընդունել, հետո թխել խոհանոցում։ Մենք նրանց ուղեցույցն ենք։ Մենք պետք է բացենք նրանց աչքերը և ասենք. հեյ, մենք այստեղ նոր հնարավորություններ ունենք։ Գիտակցո՞ւմ եք, որ մենք իսկապես կարող ենք փոխել ձեր բիզնեսի այս հատվածի ձևը: Agile-ի խնդիրներից մեկն այն է, որ այն հեռացնում է գիտակցությունը, թե ինչն է հնարավորություն, ինչ խնդիր է, ինչ պետք է անենք, առկա տեխնոլոգիաները լավագույնս համապատասխանում են տվյալ իրավիճակին:
Միգուցե ես չափից դուրս թերահավատ եմ այստեղ. արագաշարժ համայնքում շատ հրաշալի բաներ են կատարվում: Բայց ես խնդիր ունեմ, որ մարդիկ նախագիծ սահմանելու փոխարեն սկսում են ձեռքերը վեր գցել։ Ես այստեղ կհարցնեի՝ ի՞նչ ենք անում, ինչպե՞ս ենք անելու։ Եվ ինչ-որ կերպ կախարդական կերպով միշտ ստացվում է, որ հաճախորդը պետք է ավելի լավ իմանա, քան որևէ մեկը: Բայց հաճախորդը ամենից լավ գիտի միայն այն ժամանակ, երբ ընտրում է ինչ-որ մեկի կողմից արդեն կառուցված իրերից: Եթե ես ուզում եմ մեքենա գնել և գիտեմ իմ ընտանիքի բյուջեի չափը, ապա ես արագ կընտրեմ իմ ապրելակերպին համապատասխան մեքենա: Այստեղ ես ամեն ինչ գիտեմ բոլորից լավ: Բայց նկատի ունեցեք, որ ինչ-որ մեկն արդեն պատրաստել է մեքենաները: Ես գաղափար չունեմ, թե ինչպես հորինել նոր մեքենա, ես փորձագետ չեմ: Երբ մենք ստեղծում ենք հատուկ կամ հատուկ ապրանքներ, հաճախորդի ձայնը պետք է հաշվի առնել, բայց սա արդեն միակ ձայնը չէ:
Օլեգ. Դուք նշեցիք Agile Manifesto-ը: Պե՞տք է ինչ-որ կերպ թարմացնենք կամ վերանայենք այն՝ հաշվի առնելով հարցի ժամանակակից ըմբռնումը։
Թիմ. Ես նրան չէի դիպչի։ Կարծում եմ, որ դա մեծ պատմական փաստաթուղթ է: Այսինքն՝ նա այնպիսին է, ինչպիսին կա։ Նա դառնում է 19 տարեկան, ծեր է, բայց իր ժամանակին հեղափոխություն է արել. Լավ արեց այն, որ արձագանքեց, և մարդիկ սկսեցին շշնջալ նրա մասին: Դուք, ամենայն հավանականությամբ, 2001 թվականին դեռ չէիք աշխատում ոլորտում, բայց հետո բոլորն աշխատում էին ըստ գործընթացների։ Ծրագրային ճարտարագիտության ինստիտուտ, ծրագրային ապահովման ամբողջականության մոդելի հինգ մակարդակ (CMMI): Չգիտեմ՝ խոր հնության նման լեգենդները ձեզ ինչ-որ բան են ասում, բայց հետո դա բեկումնային էր: Սկզբում մարդիկ հավատում էին, որ եթե գործընթացները ճիշտ ստեղծվեն, ապա խնդիրներն ինքնին կվերանան։ Եվ հետո գալիս է Մանիֆեստը և ասում. «Ոչ, ոչ, ոչ, մենք հիմնված կլինենք մարդկանց վրա, ոչ թե գործընթացների»: Մենք ծրագրային ապահովման մշակման վարպետ ենք։ Մենք հասկանում ենք, որ իդեալական գործընթացը միրաժ է, դա տեղի չի ունենում. Նախագծերում չափազանց շատ յուրահատկություն կա, բոլոր նախագծերի համար մեկ կատարյալ գործընթացի գաղափարն իմաստ չունի: Խնդիրները չափազանց բարդ են պնդելու համար, որ ամեն ինչի միայն մեկ լուծում կա (բարև, նիրվանա):
Չեմ ենթադրում նայել դեպի ապագա, բայց կասեմ, որ մարդիկ այժմ սկսել են ավելի շատ մտածել նախագծերի մասին։ Կարծում եմ, որ Agile Manifesto-ն շատ լավ է դուրս թռչելու և ասելու մեջ. Դուք նավի վրա եք, և դուք ինքներդ եք վարում այս նավը: Դուք ստիպված կլինեք որոշում կայացնել՝ մենք բոլոր իրավիճակների համար համընդհանուր բաղադրատոմս չենք առաջարկի։ Դուք նավի անձնակազմն եք, և եթե բավականաչափ լավն եք, կարող եք ճանապարհ գտնել դեպի նպատակը։ Քեզնից առաջ այլ նավեր են եղել, քեզնից հետո էլ այլ նավեր են լինելու, բայց այնուամենայնիվ, ինչ-որ առումով քո ճանապարհորդությունը եզակի է»։ Նման մի բան! Դա մտածելակերպ է: Ինձ համար արևի տակ նոր բան չկա, մարդիկ նախկինում նավարկել են և նորից նավարկելու են, բայց քեզ համար սա քո գլխավոր ճանապարհորդությունն է, և ես քեզ չեմ ասի, թե կոնկրետ ինչ կլինի քեզ հետ։ Դուք պետք է ունենաք թիմում համակարգված աշխատանքի հմտություններ, և եթե դրանք իսկապես ունեք, ամեն ինչ կստացվի, և դուք կհասնեք այնտեղ, որտեղ ցանկանում էիք:
Peopleware. 30 տարի անց
Օլեգ. Peopleware-ը հեղափոխությո՞ւն էր, ինչպես նաև Մանիֆեստը:
Թիմ. Peopleware... Ես և Թոմը գրել ենք այս գիրքը, բայց չէինք կարծում, որ դա այսպես կլինի: Ինչ-որ կերպ այն արձագանքեց շատ մարդկանց գաղափարների հետ: Սա առաջին գիրքն էր, որտեղ ասվում էր. Ծրագրային ապահովման մշակումը շատ մարդատար գործունեություն է: Չնայած մեր տեխնիկական բնույթին, մենք նաև մարդկանց համայնք ենք, որը կառուցում է ինչ-որ մեծ, նույնիսկ հսկայական, շատ բարդ բան: Ոչ ոք միայնակ չի կարող նման բաներ ստեղծել, չէ՞: Այսպիսով, «թիմի» գաղափարը շատ կարևոր դարձավ։ Եվ ոչ միայն կառավարման տեսանկյունից, այլ նաև տեխնիկական մարդկանց համար, ովքեր հավաքվել էին իսկապես բարդ խորը խնդիրներ լուծելու մի փունջ անհայտներով։ Անձամբ ինձ համար սա ինտելեկտի հսկայական փորձություն էր իմ ողջ կարիերայի ընթացքում: Եվ այստեղ դուք պետք է կարողանաք ասել. այո, այս խնդիրն ավելին է, քան ես կարող եմ ինքնուրույն լուծել, բայց միասին մենք կարող ենք գտնել էլեգանտ լուծում, որով կարող ենք հպարտանալ: Եվ ես կարծում եմ, որ հենց այս գաղափարն է ամենաշատը արձագանքել: Գաղափարը, որ մենք ժամանակի մի մասն աշխատում ենք ինքնուրույն, որոշ ժամանակ՝ որպես խմբի մաս, և հաճախ որոշումը կայացնում է խումբը: Խմբային խնդիրների լուծումն արագորեն դարձել է բարդ նախագծերի կարևոր հատկանիշ:
Չնայած այն հանգամանքին, որ Թիմը մեծ թվով զրույցներ է ունեցել, դրանցից շատ քչերն են տեղադրվում YouTube-ում։ Դուք կարող եք դիտել «The Return of Peopleware» զեկույցը 2007 թ. Որակը, իհարկե, շատ բան է թողնում:
Մայքլ. Ինչ-որ բան փոխվե՞լ է գրքի տպագրությունից հետո վերջին 30 տարում:
Թիմ. Դուք կարող եք դրան նայել շատ տարբեր կողմերից: Սոցիոլոգիապես ասած... ժամանակին, ավելի պարզ ժամանակներում, դուք և ձեր թիմը նստել եք նույն գրասենյակում։ Դուք կարող եք ամեն օր մտերիմ լինել, միասին սուրճ խմել և քննարկել աշխատանքը։ Իրականում փոխվել է այն, որ թիմերն այժմ կարող են բաշխվել աշխարհագրորեն, տարբեր երկրներում և ժամային գոտիներում, բայց նրանք դեռ աշխատում են նույն խնդրի վրա, և դա ավելացնում է բարդության մի ամբողջ նոր շերտ: Սա կարող է հնացած թվալ, բայց ոչինչ նման չէ դեմ առ դեմ հաղորդակցությանը, որտեղ դուք բոլորդ միասին եք, աշխատում եք միասին, և կարող եք մոտենալ գործընկերոջը և ասել՝ տեսեք, թե ինչ եմ հայտնաբերել, ինչպե՞ս է ձեզ դուր գալիս սա: Դեմ առ դեմ խոսակցությունները ոչ պաշտոնական հաղորդակցությանն անցնելու արագ ճանապարհ են տալիս, և ես կարծում եմ, որ արագաշարժ սիրահարներին դա նույնպես պետք է դուր գա: Եվ ես նաև անհանգստանում եմ, որովհետև իրականում աշխարհը շատ փոքր է դարձել, և այժմ այն ծածկված է բաշխված թիմերով, և այդ ամենը շատ բարդ է:
Մենք բոլորս ապրում ենք DevOps-ում
Մայքլ. Անգամ կոնֆերանսի ծրագրի հանձնաժողովի տեսակետից մենք ունենք Կալիֆոռնիայում, Նյու Յորքում, Եվրոպայում, Ռուսաստանում... Սինգապուրում դեռ մարդ չկա։ Աշխարհագրության տարբերությունը բավականին մեծ է, և մարդիկ սկսում են ավելի շատ տարածվել։ Եթե մենք խոսում ենք զարգացման մասին, կարո՞ղ եք մեզ ավելին պատմել devops-ի և թիմերի միջև պատնեշները քանդելու մասին: Հայեցակարգ կա, որ բոլորը նստած են իրենց բունկերում, իսկ հիմա բունկերները փլուզվում են, ի՞նչ եք կարծում այս անալոգիայի մասին։
Թիմ. Ինձ թվում է, որ վերջին տեխնոլոգիական առաջընթացի լույսի ներքո, devops-ը մեծ նշանակություն ունի: Նախկինում դուք ունեիք ծրագրավորողների և ադմինիստրատորների թիմեր, նրանք աշխատում էին, աշխատում էին, աշխատում էին, և ինչ-որ պահի հայտնվեց մի բան, որի հետ դուք կարող եք գալ ադմինների մոտ և այն դուրս բերել արտադրության համար: Եվ ահա խոսակցությունը բունկերի մասին սկսվեց, քանի որ ադմինները մի տեսակ դաշնակիցներ են, ոչ թե թշնամիներ, համենայնդեպս, բայց դու խոսեցիր նրանց հետ միայն այն ժամանակ, երբ ամեն ինչ պատրաստ էր արտադրության գնալու համար։ Ինչ-որ բանով գնացե՞լ եք նրանց մոտ և ասել՝ տեսեք, թե ինչ հավելված ունենք, բայց կարո՞ղ եք այս հավելվածը բացել: Եվ հիմա առաքման ամբողջ հայեցակարգը փոխվել է դեպի լավը: Ես նկատի ունեմ, որ կար այս գաղափարը, որ դուք կարող եք արագորեն առաջ մղել փոփոխությունները: Մենք կարող ենք թարմացնել ապրանքները անմիջապես: Ես միշտ ժպտում եմ, երբ նոութբուքիս Firefox-ը հայտնվում է և ասում. «Հեյ, մենք թարմացրել ենք ձեր Firefox-ը հետին պլանում, և հենց որ մի րոպե ունենաք, դեմ կլինե՞ք սեղմել այստեղ, և մենք ձեզ կտրամադրենք վերջին թողարկումը: Եվ ես ասացի. «Օ, այո, երեխա»: Մինչ ես քնած էի, նրանք աշխատում էին ինձ նոր թողարկում ուղարկել հենց իմ համակարգչով: Սա հրաշալի է, անհավանական։
Բայց ահա դժվարությունը. դուք ունեք այս հատկությունը ծրագրաշարը թարմացնելու հետ կապված, բայց մարդկանց ինտեգրելը շատ ավելի դժվար է: Այն, ինչ ես ուզում եմ բարձրաձայնել DevOops-ի հիմնական ելույթում այն է, որ մենք այժմ ունենք շատ ավելի շատ խաղացողներ, քան երբևէ ունեցել ենք: Եթե դուք պարզապես մտածում եք բոլորի մասին, ովքեր ներգրավված են ընդամենը մեկ թիմում…. Դուք մտածել եք դրա մասին որպես թիմ, և դա շատ ավելին է, քան պարզապես ծրագրավորողների թիմ: Սրանք փորձարկողներ են, նախագծի ղեկավարներ և մի խումբ այլ մարդիկ: Եվ յուրաքանչյուրն ունի իր սեփական հայացքները աշխարհի մասին: Արտադրանքի մենեջերները բոլորովին տարբերվում են նախագծի ղեկավարներից: Ադմիններն ունեն իրենց առաջադրանքները: Բավականին բարդ խնդիր է դառնում համակարգել բոլոր մասնակիցներին, որպեսզի շարունակեն տեղյակ լինել կատարվածից և չխելագարվել: Պետք է առանձնացնել խմբի առաջադրանքները և առաջադրանքները, որոնք վերաբերում են բոլորին։ Սա շատ բարդ խնդիր է։ Մյուս կողմից, կարծում եմ, որ ամեն ինչ շատ ավելի լավ է, քան շատ տարիներ առաջ էր: Սա հենց այն ճանապարհն է, որով մարդիկ աճում և սովորում են ճիշտ վարվել։ Ինտեգրում անելիս հասկանում ես, որ ստորգետնյա զարգացում չպետք է լինի, որպեսզի ամենավերջին պահին ծրագրաշարը դուրս չսողա, ինչպես jack-in-the-box. լայք, տես, թե ինչ արեցինք այստեղ: Գաղափարն այն է, որ դուք կկարողանաք կատարել ինտեգրում և զարգացում, իսկ վերջում դուք կկազմեք կոկիկ և կրկնվող ձևով: Այս ամենն ինձ համար շատ բան է նշանակում։ Սա հնարավորություն է տալիս ավելի մեծ արժեք ստեղծել համակարգի օգտագործողների և ձեր հաճախորդի համար:
Մայքլ. devops-ի ամբողջ գաղափարը հնարավորինս շուտ բովանդակալից զարգացումներ ապահովելն է: Ես տեսնում եմ, որ աշխարհը սկսել է ավելի ու ավելի արագանալ։ Ինչպե՞ս հարմարվել նման արագացումներին: Տասը տարի առաջ սա գոյություն չուներ։
Թիմ. Իհարկե, բոլորը ցանկանում են ավելի ու ավելի շատ ֆունկցիոնալություն: Շարժվելու կարիք չկա, պարզապես կուտակեք ավելին: Երբեմն դուք նույնիսկ պետք է դանդաղեցնեք հաջորդ աստիճանական թարմացումը, որպեսզի որևէ օգտակար բան բերեք, և դա լիովին նորմալ է:
Գաղափարը, որ պետք է վազել, վազել, վազել, լավագույնը չէ: Դժվար թե որևէ մեկը ցանկանա այդպես ապրել իր կյանքով։ Ես կցանկանայի, որ առաքումների ռիթմը սահմաներ նախագծի սեփական ռիթմը: Եթե դուք պարզապես արտադրում եք փոքր, համեմատաբար անիմաստ բաների հոսք, ապա այդ ամենն անիմաստ է դառնում: Իրերը որքան հնարավոր է շուտ ազատելու անմիտ փորձելու փոխարեն, այն, ինչ արժե քննարկել առաջատար մշակողների և արտադրանքի և նախագծերի ղեկավարների հետ, ռազմավարությունն է: Սա նույնիսկ իմաստ ունի՞:
Նախշեր և հակապատկերներ
Օլեգ. Դուք սովորաբար խոսում եք օրինաչափությունների և հակաօրինաչափությունների մասին, և սա է նախագծերի կյանքի և մահվան տարբերությունը: Եվ հիմա, devops-ը մեր կյանք է մտնում: Արդյո՞ք այն ունի իր սեփական նախշերն ու հակաօրինաչափությունները, որոնք կարող են տեղում սպանել նախագիծը:
Թիմ. Կաղապարներն ու հակաօրինաչափությունները միշտ լինում են: Խոսելու բան. Դե, կա մի բան, որը մենք անվանում ենք «փայլուն իրեր»: Մարդիկ իսկապես սիրում են նոր տեխնոլոգիաները: Նրանք պարզապես հիացած են այն ամենի փայլով, ինչը թույն և ոճային տեսք ունի, և նրանք դադարում են հարցեր տալ. Ինչի՞ ենք մենք հասնելու։ Արդյո՞ք այս բանը վստահելի է, իմաստ ունի՞: Ես հաճախ եմ տեսնում մարդկանց, այսպես ասած, տեխնոլոգիայի ամենաբարձր մակարդակի վրա: Նրանք հիպնոսացված են այն ամենից, ինչ կատարվում է աշխարհում։ Բայց եթե ավելի ուշադիր նայեք, թե ինչ օգտակար բաներ են նրանք անում, հաճախ պարզապես օգտակար ոչինչ չկա:
Հենց նոր ընկերների հետ քննարկում էինք, որ այս տարի հոբելյանական է, հիսուն տարի է, ինչ մարդիկ իջել են լուսնի վրա։ Սա 1969 թվականին էր: Տեխնոլոգիան, որն օգնեց մարդկանց հասնել այնտեղ, նույնիսկ 1969-ի տեխնոլոգիան չէ, այլ 1960-ին կամ 62-ին, քանի որ NASA-ն ցանկանում էր օգտագործել միայն այն, ինչը վստահելիության լավ ապացույցներ ուներ: Եվ այսպես, դուք նայում եք դրան և հասկանում, այո, և դրանք ճշմարիտ էին: Հիմա, ոչ, ոչ, բայց դուք տեխնոլոգիայի հետ կապված խնդիրների մեջ եք ընկնում պարզապես այն պատճառով, որ ամեն ինչ շատ է մղվում, վաճառվում է բոլոր ճեղքերից: Մարդիկ ամեն տեղից բղավում են. «Տեսե՛ք, ի՜նչ բան, սա ամենանոր բանն է, ամենագեղեցիկը աշխարհում, բոլորի համար հարմար է»։ Դե, վերջ... սովորաբար այս ամենը պարզապես խաբեություն է ստացվում, իսկ հետո այդ ամենը պետք է դեն նետել։ Թերևս ամեն ինչ այն պատճառով, որ ես արդեն ծեր մարդ եմ և մեծ թերահավատությամբ եմ նայում նման բաներին, երբ մարդիկ դուրս են գալիս և ասում, որ գտել են լավագույն տեխնոլոգիաները ստեղծելու միակ, ամենաճիշտ ձևը: Այս պահին իմ ներսում արթնանում է մի ձայն, որն ասում է. «Ինչ խառնաշփոթ է»:
Մայքլ. Իսկապես, որքա՞ն հաճախ ենք մենք լսել հաջորդ արծաթե փամփուշտի մասին:
Թիմ. Ճիշտ է, և սա իրերի սովորական ընթացքն է։ Օրինակ... թվում է, թե սա արդեն կատակ է դարձել ամբողջ աշխարհում, բայց այստեղ մարդիկ հաճախ են խոսում բլոկչեյն տեխնոլոգիայի մասին։ Եվ դրանք իրականում իմաստ ունեն որոշակի իրավիճակներում: Երբ ձեզ իսկապես անհրաժեշտ են իրադարձությունների հավաստի ապացույցներ, որ համակարգը աշխատում է, և որ մեզ ոչ ոք չի խաբել, երբ դուք ունեք անվտանգության խնդիրներ և այդ ամենը խառնված, բլոկչեյնը իմաստ ունի: Բայց երբ ասում են, որ Blockchain-ն այժմ կտարածի աշխարհով մեկ՝ ջնջելով ամեն ինչ իր ճանապարհին: Երազե՛ք ավելին։ Սա շատ թանկ և բարդ տեխնոլոգիա է: Տեխնիկապես բարդ և ժամանակատար: Այդ թվում զուտ ալգորիթմական, ամեն անգամ, երբ պետք է վերահաշվարկել մաթեմատիկան, ամենափոքր փոփոխություններով... և սա հիանալի գաղափար է, բայց միայն որոշակի դեպքերի համար: Իմ ամբողջ կյանքն ու կարիերան եղել է այս մասին՝ հետաքրքիր գաղափարներ շատ կոնկրետ իրավիճակներում: Շատ կարևոր է հստակ հասկանալ, թե ինչ վիճակում է գտնվում:
Մայքլ. Այո, գլխավոր «կյանքի, տիեզերքի և ամեն ինչի հարցը»՝ այս տեխնոլոգիան կամ մոտեցումը հարմար է ձեր իրավիճակին, թե ոչ:
Թիմ. Այս հարցն արդեն կարելի է քննարկել տեխնոլոգիական խմբի հետ։ Գուցե նույնիսկ ինչ-որ խորհրդատու բերեք: Նայեք նախագծին և հասկացեք՝ մենք հիմա ինչ-որ բան կանե՞նք ճիշտ և օգտակար, ավելի լավ, քան նախկինում: Միգուցե տեղավորվի, գուցե ոչ։ Բայց ամենակարևորը, լռելյայն մի կայացրեք նման որոշում, պարզապես այն պատճառով, որ ինչ-որ մեկը բղավել է. «Մեզ խիստ անհրաժեշտ է բլոկչեյն: Ես հենց նոր կարդացի նրա մասին ինքնաթիռում գտնվող ամսագրում»։ Լուրջ? Դա նույնիսկ ծիծաղելի չէ:
Առասպելական «Դևոպս ինժեներ»
Օլեգ. Հիմա բոլորն իրականացնում են devops: Ինչ-որ մեկը ինտերնետում կարդում է devops-ի մասին, իսկ վաղը հերթական թափուր աշխատատեղ է հայտնվում հավաքագրման կայքում: «Դևոպս ինժեներ». Այստեղ ես կցանկանայի ձեր ուշադրությունը հրավիրել. ի՞նչ եք կարծում, այս տերմինը՝ «դևոպս ինժեներ», կյանքի իրավունք ունի՞: Կարծիք կա, որ devops-ը մշակույթ է, և այստեղ ինչ-որ բան չի հավաքվում:
Թիմ. Այնպես ոչինչ. Թող անմիջապես ինչ-որ բացատրություն տան այս տերմինի վերաբերյալ։ Ինչ-որ բան այն յուրահատուկ դարձնելու համար: Քանի դեռ նրանք չապացուցեն, որ նման թափուր աշխատատեղի հետևում հմտությունների ինչ-որ յուրահատուկ համադրություն կա, ես այն չեմ գնի: Նկատի ունեմ, լավ, մենք ունենք աշխատանքի կոչում, «devops engineer», հետաքրքիր կոչում, այո, իսկ հետո: Աշխատանքային կոչումները ընդհանրապես շատ հետաքրքիր բան են։ Եկեք ասենք «մշակող» - ինչ է դա, այնուամենայնիվ: Տարբեր կազմակերպություններ նշանակում են բոլորովին այլ բաներ: Որոշ ընկերություններում բարձրորակ ծրագրավորողները գրում են թեստեր, որոնք ավելի իմաստալից են, քան այլ ընկերություններում հատուկ պրոֆեսիոնալ փորձարկողների կողմից գրված թեստերը: Ուրեմն ի՞նչ, նրանք հիմա ծրագրավորողներ են, թե՞ փորձարկողներ:
Այո, մենք ունենք աշխատանքի կոչումներ, բայց եթե բավական երկար հարցեր եք տալիս, ի վերջո պարզվում է, որ մենք բոլորս խնդիրներ լուծողներ ենք: Մենք լուծում փնտրողներ ենք, և ոմանք ունեն որոշակի տեխնիկական հմտություններ, իսկ ոմանք՝ տարբեր: Եթե դուք ապրում եք մի միջավայրում, որտեղ DevOps-ը ներթափանցել է, դուք զբաղվում եք զարգացման և վարչարարության ինտեգրմամբ, և այս գործունեությունն ունի բավականին կարևոր նպատակ։ Բայց եթե քեզ հարցնեն, թե կոնկրետ ինչ ես անում և ինչի համար ես պատասխանատու, պարզվում է, որ մարդիկ անհիշելի ժամանակներից անում են այս ամենը։ «Ես պատասխանատու եմ ճարտարապետության համար», «Ես պատասխանատու եմ տվյալների շտեմարանների համար» և այլն, ինչ էլ որ տեսնեք, այս ամենը եղել է «devops»-ից առաջ:
Երբ ինչ-որ մեկն ինձ ասում է իր աշխատանքի անվանումը, ես իրականում շատ չեմ լսում: Ավելի լավ է թույլ տանք նրան ասել ձեզ, թե իրականում ինչի համար է պատասխանատու, դա մեզ թույլ կտա շատ ավելի լավ հասկանալ խնդիրը: Իմ սիրելի օրինակն այն է, երբ մարդը պնդում է, որ «նախագծի մենեջեր» է: Ինչ? Դա ոչինչ չի նշանակում, ես դեռ չգիտեմ, թե դու ինչ ես անում։ Ծրագրի մենեջերը կարող է լինել ծրագրավորող, չորս հոգուց բաղկացած թիմի ղեկավար, կոդ գրել, աշխատանք կատարել, ով դարձել է թիմի ղեկավար, ում մարդիկ իրենք իրենց մեջ ճանաչում են որպես առաջնորդ: Եվ նաև, ծրագրի մենեջերը կարող է լինել մենեջեր, ով ղեկավարում է վեց հարյուր հոգու նախագծում, կառավարում է այլ մենեջերների, պատասխանատու է ժամանակացույցերի կազմման և բյուջեների պլանավորման համար, այսքանը: Սրանք երկու բոլորովին տարբեր աշխարհներ են: Բայց նրանց աշխատանքի անվանումը նույնն է հնչում:
Եկեք այս հարցը մի փոքր այլ կերպ շրջենք: Ինչո՞վ ես իսկապես լավ, մեծ փորձ ունես, տաղանդ ունե՞ս: Ինչի՞ համար եք պատասխանատվություն ստանձնելու, քանի որ կարծում եք, որ կարող եք գլուխ հանել առաջադրանքից: Եվ այստեղ ինչ-որ մեկը անմիջապես կսկսի հերքել. ոչ, ոչ, ոչ, ես ընդհանրապես ցանկություն չունեմ զբաղվելու նախագծի ռեսուրսներով, դա իմ գործը չէ, ես տեխնիկական տղա եմ և հասկանում եմ օգտագործելիությունն ու ինտերֆեյսը, չեմ հասկանում: ուզում եմ ընդհանրապես կառավարել մարդկանց բանակները, ավելի լավ է գնամ աշխատանքի:
Եվ, ի դեպ, ես այն մոտեցման մեծ կողմնակիցն եմ, որտեղ հմտությունների այս տեսակ տարանջատումը լավ է աշխատում: Այնտեղ, որտեղ տեխնիկները կարող են զարգացնել իրենց կարիերան այնքան, որքան ցանկանում են: Այնուամենայնիվ, ես դեռ տեսնում եմ կազմակերպություններ, որտեղ տեխնոլոգները դժգոհում են. Երբեմն դա հանգեցնում է սարսափելի արդյունքների: Լավագույն տեխնոլոգները բոլորովին էլ լավ մենեջերներ չեն, իսկ լավագույն մենեջերները չեն կարողանում գլուխ հանել տեխնոլոգիայից: Եկեք անկեղծ լինենք այս հարցում:
Ես հիմա դրա համար մեծ պահանջարկ եմ տեսնում: Եթե դուք տեխնոլոգ եք, ձեր ընկերությունը կարող է օգնել ձեզ, բայց անկախ նրանից, դուք իսկապես պետք է գտնեք ձեր սեփական կարիերայի ուղին, քանի որ տեխնոլոգիան անընդհատ փոխվում է, և դուք պետք է նորովի հայտնագործեք ինքներդ ձեզ հետ միասին: Ընդամենը քսան տարվա ընթացքում տեխնոլոգիաները կարող են փոխվել առնվազն հինգ անգամ։ Տեխնոլոգիան տարօրինակ բան է...
«Ամեն ինչի մասնագետներ»
Մայքլ. Ինչպե՞ս կարող են մարդիկ հաղթահարել տեխնոլոգիական փոփոխությունների նման արագությունը: Նրանց բարդությունն աճում է, նրանց թիվը մեծանում է, մարդկանց միջև շփման ընդհանուր ծավալը նույնպես մեծանում է, և պարզվում է, որ «ամեն ինչի փորձագետ» չես կարող դառնալ։
Թիմ. Ճիշտ! Եթե աշխատում ես տեխնոլոգիայի ոլորտում, այո, անպայման պետք է ինչ-որ կոնկրետ բան ընտրել ու խորանալ դրա մեջ։ Որոշ տեխնոլոգիաներ, որոնք ձեր կազմակերպությունն օգտակար է համարում (և գուցե իրականում օգտակար կլինի): Եվ եթե դա ձեզ այլևս չի հետաքրքրում, ես երբեք չէի հավատա, որ ես սա կասեմ, լավ, գուցե դուք պետք է տեղափոխվեք որևէ այլ կազմակերպություն, որտեղ տեխնոլոգիան ավելի հետաքրքիր է կամ ավելի հարմար ուսումնասիրելու համար:
Բայց ընդհանուր առմամբ, այո, դու ճիշտ ես։ Տեխնոլոգիաները միանգամից զարգանում են բոլոր ուղղություններով, ոչ ոք չի կարող ասել. Մյուս կողմից, կան սպունգ մարդիկ, ովքեր բառացիորեն կլանում են տեխնոլոգիական գիտելիքները և խելագարվում են դրա համար։ Ես տեսել եմ մի քանի այդպիսի մարդկանց, նրանք բառացիորեն շնչում և ապրում են դրանով, նրանց հետ զրուցելը օգտակար և հետաքրքիր է: Նրանք ուսումնասիրում են ոչ միայն այն, ինչ կատարվում է կազմակերպության ներսում, այլ ընդհանրապես, խոսում են այդ մասին, նրանք նաև իսկապես թույն տեխնոլոգներ են, շատ գիտակից են և նպատակասլաց։ Նրանք պարզապես փորձում են մնալ ալիքի գագաթին, անկախ նրանից, թե որն է իրենց հիմնական աշխատանքը, քանի որ նրանց կիրքը Տեխնոլոգիայի շարժումն է, տեխնոլոգիայի առաջմղումը։ Եթե հանկարծ հանդիպեք նման մարդու, պետք է գնալ նրա հետ ճաշելու և ճաշի ընթացքում քննարկել տարբեր զով բաներ։ Կարծում եմ՝ ցանկացած կազմակերպության պետք է գոնե մի երկու այդպիսի մարդ։
Ռիսկեր և անորոշություն
Մայքլ. Վաստակավոր ինժեներներ, այո։ Քանի դեռ ժամանակ ունենք, անդրադառնանք ռիսկերի կառավարմանը։ Մենք սկսեցինք այս հարցազրույցը բժշկական ծրագրաշարի քննարկմամբ, որտեղ սխալները կարող են հանգեցնել սարսափելի հետևանքների: Այնուհետև մենք խոսեցինք Լուսնի ծրագրի մասին, որտեղ սխալի արժեքը միլիոնավոր դոլարներ է, և հնարավոր է մի քանի մարդկային կյանքեր: Բայց հիմա արդյունաբերության մեջ տեսնում եմ հակառակ շարժումը, մարդիկ չեն մտածում ռիսկերի մասին, չեն փորձում կանխատեսել դրանք, նույնիսկ չեն դիտարկում։
Օլեգ. Շարժվեք արագ և կոտրեք իրերը:
Մայքլ. Այո, արագ շարժվեք, կոտրեք իրերը, ավելի ու ավելի շատ բաներ, մինչև մեռնեք ինչ-որ բանից: Ձեր տեսանկյունից ինչպե՞ս պետք է այժմ սովորական մշակողը մոտենա սովորելու ռիսկերի կառավարմանը:
Թիմ. Եկեք այստեղ գիծ քաշենք երկու բանի միջև՝ ռիսկերի և անորոշության միջև: Սրանք տարբեր բաներ են։ Անորոշությունը տեղի է ունենում, երբ դուք չունեք բավարար տվյալներ ժամանակի ցանկացած պահի վերջնական պատասխանի հասնելու համար: Օրինակ՝ նախագծի շատ վաղ փուլում, եթե ինչ-որ մեկը ձեզ հարցնի՝ «երբ կավարտեք աշխատանքը», եթե բավականին ազնիվ մարդ եք, կասեք՝ «Գաղափար չունեմ»։ Դուք պարզապես չգիտեք, և դա նորմալ է: Դուք դեռ չեք ուսումնասիրել խնդիրները և ծանոթ չեք թիմին, չգիտեք նրանց հմտությունները և այլն։ Սա անորոշություն է։
Ռիսկերը առաջանում են, երբ հնարավոր խնդիրներն արդեն իսկ հնարավոր են բացահայտել: Նման բան կարող է պատահել, դրա հավանականությունը զրոյից մեծ է, բայց հարյուր տոկոսից պակաս, ինչ-որ տեղ արանքում: Դրա պատճառով ամեն ինչ կարող է պատահել՝ ձգձգումներից և ավելորդ աշխատանքից, բայց նույնիսկ մինչև նախագծի համար ճակատագրական արդյունք: Արդյունքը, երբ ասում եք՝ տղերք, եկեք ծալենք մեր հովանոցները և լքենք լողափը, մենք այն երբեք չենք ավարտի, ամեն ինչ ավարտված է, կետ: Մենք ենթադրում էինք, որ այս բանը կաշխատի, բայց դա ընդհանրապես չի աշխատում, ժամանակն է դադարեցնել: Սրանք իրավիճակներ են։
Հաճախ խնդիրներն ամենադյուրին են լուծվում, երբ դրանք արդեն ի հայտ են եկել, երբ խնդիրը հենց հիմա է տեղի ունենում: Բայց երբ խնդիրն անմիջապես ձեր առջև է, դուք չեք անում ռիսկերի կառավարում, այլ զբաղվում եք խնդիրների լուծումով, ճգնաժամային կառավարմամբ: Եթե դուք առաջատար ծրագրավորող կամ մենեջեր եք, դուք պետք է մտածեք, թե ինչ կարող է տեղի ունենալ, որը կհանգեցնի հետաձգումների, ժամանակի վատնման, ավելորդ ծախսերի կամ ամբողջ նախագծի փլուզմանը: Ի՞նչը մեզ կստիպի կանգ առնել և սկսել նորից: Երբ այս բոլոր բաները աշխատեն, ի՞նչ ենք անելու դրանց հետ։ Կա մի պարզ պատասխան, որը վավեր է շատ իրավիճակների համար՝ մի փախեք ռիսկերից, աշխատեք դրանց վրա: Տեսեք, թե ինչպես կարող եք լուծել ռիսկային իրավիճակը, նվազեցնել այն ոչնչի, խնդրից վերածել այլ բանի: Փոխանակ ասենք՝ դե, ոնց որ առաջանան, կլուծենք։
Անորոշությունն ու ռիսկը պետք է լինեն ամեն ինչի առաջնագծում, ինչի հետ գործ ունեք: Դուք կարող եք վերցնել ծրագրի պլանը, նախօրոք դիտարկել որոշ կրիտիկական ռիսկեր և ասել. մենք պետք է զբաղվենք այս հարցով հենց հիմա, քանի որ եթե այս ամենից որևէ մեկը սխալ ընթանա, ուրիշ ոչինչ նշանակություն չի ունենա: Դուք չպետք է անհանգստանաք սեղանի վրա դրված սփռոցի գեղեցկության համար, եթե պարզ չէ, թե արդյոք կարող եք ճաշ պատրաստել: Նախ պետք է բացահայտել համեղ ընթրիք պատրաստելու բոլոր ռիսկերը, զբաղվել դրանցով և միայն դրանից հետո մտածել մնացած բոլոր բաների մասին, որոնք իրական վտանգ չեն ներկայացնում։
Կրկին ինչո՞վ է ձեր նախագիծը յուրահատուկ: Տեսնենք, թե ինչը կարող է ստիպել մեր նախագծին դուրս գալ ռելսերից: Ի՞նչ կարող ենք անել, որպեսզի նվազագույնի հասցնենք դրա հավանականությունը: Սովորաբար չի կարելի նրանց 100%-ով չեզոքացնել և հանգիստ խղճով հայտարարել. Ինձ համար սա մեծահասակների վարքի նշան է: Սա է տարբերությունը երեխայի և մեծահասակի միջև. երեխաները կարծում են, որ իրենք անմահ են, որ ոչինչ չի կարող սխալվել, ամեն ինչ լավ կլինի: Միևնույն ժամանակ, մեծահասակները դիտում են, թե ինչպես են երեք տարեկան երեխաները ցատկում խաղահրապարակում, աչքերով հետևում շարժումներին և ասում իրենց՝ «օհ-օհ, օօ-օհ»: Ես կանգնած եմ մոտակայքում և պատրաստվում եմ բռնել, երբ երեխան ընկնում է:
Մյուս կողմից, այս բիզնեսը ինձ այդքան դուր է գալիս, այն ռիսկային է։ Մենք բաներ ենք անում, և այդ բաները ռիսկային են: Նրանք պահանջում են մեծահասակների մոտեցում: Միայն խանդավառությունը չի լուծի ձեր խնդիրները:
Մեծահասակների ինժեներական մտածողություն
Մայքլ. Երեխաների օրինակը լավն է։ Եթե ես սովորական ինժեներ եմ, ուրեմն ուրախ եմ, որ երեխա եմ։ Բայց ինչպե՞ս եք շարժվում դեպի ավելի մեծահասակների մտածողություն:
Թիմ. Գաղափարներից մեկը, որը հավասարապես լավ է աշխատում ինչպես սկսնակ, այնպես էլ կայացած ծրագրավորողի հետ, համատեքստի հայեցակարգն է: Ինչ ենք անում, ինչի ենք հասնելու։ Ի՞նչն է իսկապես կարևոր այս նախագծում: Կարևոր չէ, թե ով եք դուք այս նախագծում, պրակտիկանտ եք, թե գլխավոր ճարտարապետ, բոլորին անհրաժեշտ է համատեքստ: Մենք պետք է ստիպենք բոլորին մտածել ավելի մեծ մասշտաբով, քան իրենց սեփական գործերը: «Ես պատրաստում եմ իմ ստեղծագործությունը, և քանի դեռ իմ ստեղծագործությունն աշխատում է, ես երջանիկ եմ»: Ոչ և կրկին ոչ: Միշտ արժե (առանց կոպիտ լինելու) հիշեցնել մարդկանց այն համատեքստի մասին, որտեղ նրանք աշխատում են: Այն, ինչին մենք բոլորս միասին փորձում ենք հասնել։ Գաղափարներ, որ դուք կարող եք երեխա լինել, քանի դեռ ամեն ինչ լավ է ձեր նախագծի հետ կապված. խնդրում եմ, մի արեք դա: Եթե մենք ընդհանրապես անցնենք վերջնագիծը, ապա միայն միասին կանցնենք այն։ Դուք մենակ չեք, մենք բոլորս միասին ենք։ Եթե նախագծում ընդգրկված բոլոր մարդիկ՝ և՛ տարեցները, և՛ երիտասարդները, սկսեն խոսել այն մասին, թե կոնկրետ ինչն է կարևոր նախագծի համար, ինչու է ընկերությունը գումարներ ներդնում այն ամենի մեջ, ինչ մենք բոլորս փորձում ենք հասնել... նրանցից շատերը իրենց շատ ավելի լավ կզգան, քանի որ նրանք կտեսնեն, թե ինչպես է նրանց աշխատանքը փոխկապակցված բոլորի աշխատանքի հետ: Մի կողմից ես հասկանում եմ այն կտորը, որի համար անձամբ պատասխանատու եմ։ Բայց գործն ավարտելու համար մեզ պետք են նաև մնացած բոլոր մարդիկ: Եվ եթե իսկապես կարծում եք, որ ավարտել եք, մենք միշտ անելիքներ ունենք նախագծում:
Օլեգ. Համեմատաբար ասած, եթե աշխատում ես ըստ Kanban-ի, երբ ինչ-որ թեստավորման նժարին ես հարվածում, կարող ես թողնել այն, ինչ անում էիր այնտեղ (օրինակ՝ ծրագրավորումը) և գնալ փորձարկողներին օգնելու։
Թիմ. Հենց ճիշտ. Կարծում եմ, լավագույն տեխնոլոգները, եթե ուշադիր նայեք նրանց, նրանք մի տեսակ իրենց մենեջերներն են: Ինչպե՞ս կարող եմ սա ձևակերպել...
Օլեգ. Ձեր կյանքը ձեր նախագիծն է, որը դուք ղեկավարում եք:
Թիմ. Ճիշտ! Այսինքն՝ դու պատասխանատվություն ես վերցնում, հասկանում ես խնդիրը և շփվում ես մարդկանց հետ, երբ տեսնում ես, որ քո որոշումները կարող են ազդել նրանց աշխատանքի վրա, նման բաներ: Խոսքը այն մասին չէ, որ պարզապես նստես գրասեղանի մոտ, կատարես քո աշխատանքը և նույնիսկ չհասկանաս, թե ինչ է կատարվում շուրջդ: Ոչ ոչ ոչ. Ի դեպ, Agile-ի ամենալավ բաներից մեկն այն է, որ նրանք առաջարկեցին կարճ սպրինտներ, քանի որ այսպիսով բոլոր մասնակիցների գործերի վիճակը հստակ նկատվում է, նրանք կարող են տեսնել այդ ամենը միասին: Մենք ամեն օր խոսում ենք միմյանց մասին:
Ինչպես մտնել ռիսկերի կառավարման մեջ
Օլեգ. Կա՞ որևէ պաշտոնական գիտելիքի կառուցվածք այս ոլորտում: Օրինակ, ես Java-ի ծրագրավորող եմ և ցանկանում եմ հասկանալ ռիսկերի կառավարումը՝ առանց կրթության իրական ծրագրի ղեկավար դառնալու: Հավանաբար սկզբում կկարդամ Մաքքոնելի «Ինչքան արժե ծրագրային ապահովման նախագիծը», հետո ի՞նչ: Որո՞նք են առաջին քայլերը:
Թիմ. Առաջինը՝ սկսել շփվել նախագծում ընդգրկված մարդկանց հետ: Սա ապահովում է գործընկերների հետ շփման մշակույթի անմիջական բարելավում: Մենք պետք է սկսենք ամեն ինչ լռելյայն բացելով՝ այն թաքցնելու փոխարեն: Ասա. սրանք այն բաներն են, որոնք ինձ անհանգստացնում են, սրանք այն բաներն են, որոնք ինձ արթնացնում են գիշերը, ես այսօր արթնացա գիշերը և ասացի. Աստված իմ, ես պետք է մտածեմ այս մասին: Մյուսները նույն բանը տեսնու՞մ են։ Որպես խումբ՝ մենք պե՞տք է արձագանքենք այս հնարավոր խնդիրներին: Դուք պետք է կարողանաք աջակցել այս թեմաների քննարկմանը: Չկա նախապես պատրաստված բանաձեւ, որով մենք աշխատում ենք։ Խոսքը համբուրգեր պատրաստելու մասին չէ, այլ մարդկանց: «Չիզբուրգեր եմ պատրաստել, չիզբուրգեր վաճառել» ամենևին էլ մեր բանը չէ, և դրա համար ես շատ եմ սիրում այս աշխատանքը: Ինձ դուր է գալիս, երբ այն ամենը, ինչ նախկինում անում էին մենեջերները, այժմ դառնում է թիմի սեփականությունը։
Օլեգ. Դուք գրքերում և հարցազրույցներում խոսել եք այն մասին, թե ինչպես են մարդիկ ավելի շատ մտածում երջանկության մասին, քան գրաֆիկի թվերի մասին: Մյուս կողմից, երբ թիմին ասում ես. մենք գնում ենք դեպի devops, և այժմ ծրագրավորողը պետք է անընդհատ շփվի, սա կարող է շատ հեռու լինել իր հարմարավետության գոտուց: Եվ այս պահին նա կարող է, ասենք, խորապես դժգոհ լինել։ Ի՞նչ անել այս իրավիճակում:
Թիմ. Ես վստահ չեմ, թե կոնկրետ ինչ անել: Եթե մշակողը չափազանց մեկուսացված է, նա չի տեսնում, թե ինչու է աշխատանքը կատարվում առաջին հերթին, նրանք պարզապես նայում են աշխատանքի իրենց հատվածին, և նրանք պետք է մտնեն այն, ինչ ես անվանում եմ «համատեքստ»: Նա պետք է պարզի, թե ինչպես է ամեն ինչ փոխկապակցված: Եվ իհարկե, ես նկատի չունեմ պաշտոնական ներկայացումներ կամ նման այլ բաներ: Ես խոսում եմ այն մասին, որ դուք պետք է գործընկերների հետ շփվեք աշխատանքի մասին, որպես ամբողջություն, և ոչ միայն դրա այն մասի, որի համար պատասխանատու եք: Այստեղ դուք կարող եք սկսել քննարկել գաղափարներ, ընդհանուր համաձայնագրեր, որպեսզի ձեր աշխատանքը լավ համընկնի և ինչպես միասին լուծեք ընդհանուր խնդիրը:
Որպեսզի օգնեն նրանց հարմարվել, նրանք հաճախ ցանկանում են վարպետներին ուղարկել վերապատրաստման, և նրանք քննարկում են վերապատրաստումը: Իմ ընկերը սիրում է ասել, որ վարժեցնելը շների համար է: Մարդկանց համար թրեյնինգ կա։ Որպես ծրագրավորող սովորելու լավագույն բաներից մեկը ձեր հասակակիցների հետ շփվելն է: Եթե ինչ-որ մեկն իսկապես լավ է ինչ-որ բանում, դուք պետք է հետևեք նրա աշխատանքին կամ խոսեք նրա հետ իր աշխատանքի կամ այլ բաների մասին: Որոշ սովորական Քենթ Բեքը անընդհատ խոսում էր էքստրեմալ ծրագրավորման մասին: Ծիծաղելի է, քանի որ XP-ն այնքան պարզ գաղափար է, բայց այն շատ խնդիրներ է առաջացնում: Ոմանց համար XP անելը նման է ընկերների առաջ մերկանալուն: Նրանք կտեսնեն, թե ինչ եմ անում: Նրանք իմ գործընկերներն են, ոչ միայն կտեսնեն, այլև կհասկանան։ Սարսափելի! Որոշ մարդիկ սկսում են լրջորեն նյարդայնանալ։ Բայց երբ հասկանում ես, որ սա սովորելու վերջնական միջոցն է, ամեն ինչ փոխվում է: Դուք սերտորեն համագործակցում եք մարդկանց հետ, և որոշ մարդիկ ձեզանից շատ ավելի լավ են հասկանում թեման:
Մայքլ. Բայց այս ամենը ստիպում է քեզ դուրս գալ հարմարավետության գոտուց։ Որպես ինժեներ, դուք պետք է դուրս գաք ձեր հարմարավետության գոտուց և շփվեք: Որպես խնդիր լուծող՝ դուք պետք է անընդհատ ձեզ թույլ դիրքի մեջ դնեք և մտածեք, թե ինչ կարող է սխալ լինել։ Աշխատանքի այս տեսակն ի սկզբանե նախատեսված է անհանգստություն պատճառելու համար: Դուք գիտակցաբար ձեզ դնում եք սթրեսային իրավիճակների մեջ։ Սովորաբար մարդիկ փախչում են նրանցից, մարդիկ սիրում են երջանիկ երեխաներ լինել։
Թիմ. Ինչ կարելի է անել, դուք կարող եք դուրս գալ և բացահայտ ասել. «Ամեն ինչ կարգին է, ես կարող եմ դա անել: Ես միակը չեմ, ով անհարմար է զգում: Եկեք քննարկենք տարբեր անհարմար բաներ, բոլորս միասին, թիմով»: Սրանք մեր ընդհանուր խնդիրներն են, մենք պետք է զբաղվենք դրանցով, գիտե՞ք: Կարծում եմ, որ յուրօրինակ հանճար մշակողները նման են մամոնտի, նրանք անհետացան: Իսկ դրանց նշանակությունը շատ սահմանափակ է։ Եթե չես կարողանում շփվել, չես կարող լավ մասնակցել։ Հետեւաբար, պարզապես խոսեք: Եղեք ազնիվ և բաց: Շատ եմ ցավում, որ ինչ-որ մեկի համար սա տհաճ է։ Պատկերացնու՞մ եք, շատ տարիներ առաջ մի ուսումնասիրություն կար, ըստ որի ԱՄՆ-ում հիմնական վախը ոչ թե մահն է, այլ գուշակեք, թե ինչ: Վախ հանրային ելույթից։ Սա նշանակում է, որ ինչ-որ տեղ կան մարդիկ, ովքեր նախընտրում են մեռնել, քան բարձրաձայն հաճոյախոսություն ասել: Եվ ես կարծում եմ, որ ձեզ համար բավական է ունենալ որոշ հիմնական հմտություններ՝ կախված նրանից, թե ինչ եք անում: Խոսելու հմտություններ, գրելու հմտություններ, բայց միայն այնքան, որքան իսկապես անհրաժեշտ է ձեր աշխատանքում: Եթե դուք աշխատում եք որպես վերլուծաբան, բայց չգիտեք կարդալ, գրել կամ խոսել, ապա, ցավոք, դուք անելիք չեք ունենա իմ նախագծերում:
Կապի գինը
Օլեգ. Մի՞թե տարբեր պատճառներով նման արտագնա աշխատողների աշխատանքի ընդունելն ավելի թանկ չէ։ Չէ՞ որ նրանք աշխատելու փոխարեն անընդհատ զրուցում են։
Թիմ. Ես նկատի ունեի թիմի կորիզը, և ոչ միայն բոլորին: Եթե դուք ունեք մեկը, ով իսկապես լավ է կարգավորել տվյալների շտեմարանները, սիրում է տվյալների բազաները կարգավորել և պատրաստվում է շարունակել կարգավորել ձեր տվյալների շտեմարանները իր ողջ կյանքի ընթացքում, և վերջ, լավ, շարունակեք այդպես: Բայց ես խոսում եմ այն մարդկանց մասին, ովքեր ցանկանում են ապրել հենց նախագծում: Թիմի կորիզը՝ ուղղված նախագծի զարգացմանը։ Այս մարդիկ իսկապես կարիք ունեն անընդհատ շփվելու միմյանց հետ։ Եվ հատկապես նախագծի սկզբում, երբ քննարկում եք ռիսկերը, գլոբալ նպատակներին հասնելու ուղիները և այլն:
Մայքլ. Սա վերաբերում է բոլորին, ովքեր ներգրավված են նախագծում՝ անկախ մասնագիտությունից, հմտություններից և աշխատելու ձևից: Բոլորդ շահագրգռված եք նախագծի հաջողությամբ։
Թիմ. Այո, դուք զգում եք, որ բավականաչափ խորասուզված եք նախագծի մեջ, որ ձեր խնդիրն է օգնել նախագծի իրականացմանը: Անկախ նրանից՝ դուք ծրագրավորող եք, վերլուծաբան, ինտերֆեյսի դիզայներ, որևէ մեկը: Սա է պատճառը, որ ես ամեն առավոտ գալիս եմ աշխատանքի, և սա այն է, ինչ մենք անում ենք: Մենք պատասխանատու ենք այս բոլոր մարդկանց համար՝ անկախ նրանց հմտություններից։ Սա մեծահասակների խոսակցություններ ունեցող մարդկանց խումբ է:
Օլեգ. Իրականում, խոսելով շատախոս աշխատակիցների մասին, ես փորձեցի նմանակել մարդկանց, հատկապես մենեջերների առարկությունները, որոնց խնդրում են անցնել devops-ի, աշխարհի այս ամբողջ նոր տեսլականին: Եվ դուք, որպես խորհրդատուներ, պետք է ավելի լավ տեղյակ լինեք այս առարկությունների մասին, քան ես՝ որպես ծրագրավորող: Կիսվեք, թե ինչն է ամենից շատ անհանգստացնում մենեջերներին:
Թիմ. Մենեջերներ. Հմ. Ամենից հաճախ մենեջերները ճնշման տակ են գտնվում խնդիրների պատճառով, բախվում են ինչ-որ բան շտապ ազատելու և առաքում կատարելու անհրաժեշտությանը և այլն: Նրանք նայում են, թե ինչպես ենք մենք անընդհատ ինչ-որ բան քննարկում, վիճում, և դա տեսնում են այսպես՝ խոսակցություններ, խոսակցություններ, խոսակցություններ... Էլ ի՞նչ խոսակցություններ։ Վերադարձեք աշխատանքին։ Քանի որ խոսելը նրանց համար աշխատանք չի թվում: Դուք չեք գրում կոդ, չեք փորձարկում ծրագրակազմը, կարծես ոչինչ չեք անում, ինչո՞ւ չուղարկել ձեզ ինչ-որ բան անելու համար: Ի վերջո, առաքումն արդեն մեկ ամսից է:
Մայքլ. Գնա մի կոդ գրիր։
Թիմ. Ինձ թվում է՝ նրանց մտահոգում է ոչ թե աշխատանքը, այլ առաջընթացի տեսանելիությունը։ Որպեսզի թվա, թե մենք մոտենում ենք հաջողությանը, նրանք պետք է տեսնեն, թե ինչպես ենք սեղմում ստեղնաշարի կոճակները: Ամբողջ օրը առավոտից երեկո։ Սա թիվ մեկ խնդիրն է:
Օլեգ. Միշա, դու ինչ-որ բանի մասին ես մտածում։
Մայքլ. Կներեք, ես մոլորվեցի մտքերի մեջ և հետադարձ հայացք բռնեցի: Այս ամենն ինձ հիշեցրեց երեկ տեղի ունեցած մի հետաքրքիր հանրահավաք... Երեկ շատ հանրահավաքներ եղան... Եվ այդ ամենը շատ ծանոթ է հնչում։
Կյանքն առանց աշխատավարձի
Թիմ. Ի դեպ, հաղորդակցության համար ամենևին էլ պետք չէ «հանրահավաքներ» կազմակերպել։ Նկատի ունեմ, որ մշակողների միջև ամենաօգտակար քննարկումները տեղի են ունենում, երբ նրանք պարզապես խոսում են միմյանց հետ: Առավոտյան մի բաժակ սուրճով ներս ես մտնում, հինգ հոգի հավաքված են ու կատաղած քննարկում են ինչ-որ տեխնիկական բան։ Ինձ համար, եթե ես այս նախագծի ղեկավարն եմ, ավելի լավ է պարզապես ժպտամ և գնամ ինչ-որ տեղ իմ գործով, թող քննարկեն: Նրանք արդեն ներգրավված են հնարավորինս։ Սա լավ նշան է։
Օլեգ. Ի դեպ, ձեր գրքում դուք ունեք մի փունջ նշումներ այն մասին, թե որն է լավը, ինչը` վատը: Դուք ինքներդ օգտագործում եք դրանցից որևէ մեկը: Համեմատաբար ասած, այժմ դուք ունեք ընկերություն, որը կառուցված է շատ անսովոր ձևով...
Թիմ. Անսովոր, բայց այս սարքը մեզ հիանալի է սազում։ Մենք իրար վաղուց ենք ճանաչում։ Մենք վստահում ենք միմյանց, շատ էինք վստահում միմյանց մինչև գործընկեր դառնալը։ Իսկ օրինակ՝ մենք ընդհանրապես աշխատավարձ չունենք։ Մենք ուղղակի աշխատում ենք, և, օրինակ, եթե ես իմ հաճախորդներից գումար էի աշխատում, ապա ամբողջ գումարը գնում էր ինձ։ Դրանից հետո մենք կազմակերպության անդամավճարներ ենք վճարում, և դա բավարար է հենց ընկերությանն աջակցելու համար։ Բացի այդ, մենք բոլորս մասնագիտացած ենք տարբեր բաների մեջ: Օրինակ՝ ես աշխատում եմ հաշվապահների հետ, լրացնում եմ հարկային հայտարարագրերը, ամենատարբեր ադմինիստրատիվ գործեր եմ անում ընկերության համար, և ինձ ոչ ոք դրա դիմաց չի վճարում։ Ջեյմսն ու Թոմը աշխատում են մեր կայքում, և նրանց նույնպես ոչ ոք չի վճարում: Քանի դեռ դուք վճարում եք ձեր տուրքերը, ոչ ոք չի մտածի ձեզ ասել, թե ինչ պետք է անեք: Օրինակ՝ Թոմն այժմ շատ ավելի քիչ է աշխատում, քան նախկինում։ Հիմա նա այլ շահեր ունի, ինչ-որ բաներ անում է ոչ գիլդիայի համար: Բայց քանի դեռ նա վճարում է իր պարտքերը, ոչ ոք չի մոտենա ու ասի. «Հեյ, Թոմ, գնա գործի»։ Շատ հեշտ է գործ ունենալ գործընկերների հետ, երբ ձեր միջև փող չկա։ Եվ հիմա մեր հարաբերությունները տարբեր մասնագիտությունների հետ կապված հիմնարար գաղափարներից են։ Այն աշխատում է և շատ լավ է աշխատում:
լավագույն խորհուրդը
Մայքլ. Վերադառնալով «լավագույն խորհրդին», կա՞ որևէ բան, որ դուք անընդհատ ասում եք ձեր հաճախորդներին: 80/20-ի մասին պատկերացում կա, և որոշ խորհուրդներ, հավանաբար, ավելի հաճախ են կրկնվում։
Թիմ. Մի անգամ մտածում էի, որ եթե դու գրես այնպիսի գիրք, ինչպիսին է Արջերի հետ վալսը, դա կփոխի պատմության ընթացքը, և մարդիկ կկանգնեն, բայց... Դե, տես, ընկերությունները հաճախ ձևացնում են, թե իրենց հետ ամեն ինչ լավ է։ Հենց ինչ-որ վատ բան է տեղի ունենում, դա նրանց համար շոկ է և անակնկալ։ «Տեսեք, մենք փորձարկեցինք համակարգը, և այն չի անցնում համակարգի ոչ մի փորձարկում, և սա ևս երեք ամիս չնախատեսված աշխատանք է, ինչպե՞ս կարող է դա տեղի ունենալ: Ով գիտեր? Ի՞նչը կարող է սխալ լինել: Լուրջ, դու հավատու՞մ ես սրան։
Փորձում եմ բացատրել, որ պետք չէ շատ բարկանալ ստեղծված իրավիճակի համար։ Մենք պետք է խոսենք դրա մասին, իսկապես հասկանանք, թե ինչ կարող էր սխալ լինել, և ինչպես կանխել նման բաները ապագայում: Եթե խնդիր առաջանա, ինչպե՞ս ենք դրա դեմ պայքարելու, ինչպե՞ս ենք զսպելու։
Ինձ համար այս ամենը սարսափելի է թվում: Մարդիկ առնչվում են բարդ, հուզիչ խնդիրների հետ և շարունակում են ձևացնել, որ եթե մատները խաչեն և հույս ունենան լավագույնի վրա, իրականում «լավագույնը» տեղի կունենա: Ոչ, այդպես չի ստացվում:
Զբաղվեք ռիսկերի կառավարմամբ:
Մայքլ. Ձեր կարծիքով, քանի՞ կազմակերպություն է զբաղվում ռիսկերի կառավարմամբ:
Թիմ. Ինձ վրդովեցնում է այն, որ մարդիկ պարզապես գրի են առնում ռիսկերը, նայում են ստացված ցուցակը և գնում աշխատանքի: Իրականում նրանց համար ռիսկերի բացահայտումը ռիսկերի կառավարումն է: Բայց ինձ համար սա առիթ է հարցնելու. լավ, կա ցուցակ, կոնկրետ ի՞նչ եք փոխելու: Դուք պետք է փոխեք ձեր ստանդարտ գործողությունների հաջորդականությունը՝ հաշվի առնելով այս ռիսկերը: Եթե կա աշխատանքի ամենադժվար մաս, դուք պետք է զբաղվեք դրանով և միայն դրանից հետո անցնեք ավելի պարզ բանի: Առաջին սպրինտներում սկսեք բարդ խնդիրներ լուծել։ Սա արդեն նման է ռիսկերի կառավարման: Բայց սովորաբար մարդիկ չեն կարողանում ասել, թե ինչ են փոխել ռիսկերի ցանկը կազմելուց հետո։
Մայքլ. Եվ այնուամենայնիվ, այդ ընկերություններից քանի՞սն է ներգրավված ռիսկերի կառավարման մեջ՝ հինգ տոկոս:
Թիմ. Ցավոք սրտի, ես ատում եմ դա ասել, բայց սա շատ աննշան հատված է: Բայց հինգից ավելի, քանի որ կան իսկապես մեծ նախագծեր, և դրանք պարզապես չեն կարող գոյություն ունենալ, եթե գոնե ինչ-որ բան չանեն: Ասենք, որ շատ կզարմանամ, եթե գոնե 25% լինի։ Փոքր նախագծերը սովորաբար այսպիսի հարցերին պատասխանում են՝ եթե խնդիրն ազդում է մեզ վրա, ապա մենք այն կլուծենք։ Այնուհետև նրանք հաջողությամբ հայտնվում են փորձանքի մեջ և զբաղվում խնդիրների կառավարմամբ և ճգնաժամային կառավարմամբ: Երբ փորձում եք որևէ խնդիր լուծել, և խնդիրը չի լուծվում, համեցեք ճգնաժամային կառավարման:
Այո, ես հաճախ եմ լսում, «մենք կլուծենք խնդիրները, ինչպես որ դրանք ծագեն»: Անշուշտ մենք կանե՞նք: Իսկապե՞ս կորոշենք։
Օլեգ. Դուք կարող եք դա անել միամտորեն և պարզապես գրել կարևոր ինվարիանտներ նախագծի կանոնադրության մեջ, և եթե ինվարիանտները կոտրվեն, պարզապես վերագործարկեք նախագիծը: Պարզվում է, որ շատ պիեմբակ է:
Մայքլ. Այո, ինձ հետ պատահել է, որ երբ ռիսկեր են առաջանում, նախագիծը պարզապես վերաիմաստավորվել է: Լավ, բինգո, խնդիրը լուծված է, այլևս մի անհանգստացեք:
Թիմ. Եկեք սեղմենք վերակայման կոճակը: Ոչ, այդպես չի ստացվում:
Հիմնական ելույթ DevOops 2019-ում
Մայքլ. Գալիս ենք այս հարցազրույցի վերջին հարցին. Դուք գալիս եք հաջորդ DevOops-ին հիմնական նոտայով, կարո՞ղ եք բարձրացնել գաղտնիության վարագույրը այն մասին, ինչ պատրաստվում եք պատմել:
Թիմ. Հենց հիմա նրանցից վեցը գիրք են գրում աշխատանքային մշակույթի, կազմակերպությունների չասված կանոնների մասին։ Մշակույթը որոշվում է կազմակերպության հիմնական արժեքներով: Սովորաբար մարդիկ դա չեն նկատում, բայց երկար տարիներ աշխատելով խորհրդատվական ոլորտում՝ մենք սովոր ենք դա նկատել։ Մտնում ես ընկերություն և բառացիորեն մի քանի րոպեի ընթացքում սկսում ես զգալ, թե ինչ է կատարվում։ Մենք սա անվանում ենք «համը»: Երբեմն այս բույրը իսկապես լավ է, իսկ երբեմն էլ, լավ, օփ: Տարբեր կազմակերպությունների համար ամեն ինչ շատ տարբեր է:
Մայքլ. Ես նույնպես տարիներ շարունակ աշխատում եմ խորհրդատվությամբ և լավ եմ հասկանում, թե ինչի մասին եք խոսում։
Թիմ. Իրականում, հիմնական բանախոսության ժամանակ արժե խոսել այն բանից, որ ամեն ինչ չէ, որ որոշում է ընկերությունը: Դուք և ձեր թիմը, որպես համայնք, ունեք ձեր թիմային մշակույթը: Սա կարող է լինել ամբողջ ընկերությունը, կամ առանձին բաժին, առանձին թիմ: Բայց մինչ դուք ասացիք, ահա թե ինչին ենք մենք հավատում, ահա թե ինչն է կարևոր... Դուք չեք կարող փոխել մշակույթը, քանի դեռ չեն հասկացվել կոնկրետ գործողությունների հետևում գտնվող արժեքներն ու համոզմունքները: Վարքագիծը հեշտ է դիտարկել, բայց համոզմունքներ փնտրելը դժվար է: DevOps-ը պարզապես հիանալի օրինակ է այն բանի, թե ինչպես են ամեն ինչ դառնում ավելի ու ավելի բարդ: Փոխազդեցությունները միայն ավելի են բարդանում, դրանք ամենևին էլ ավելի մաքուր կամ պարզ չեն դառնում, ուստի պետք է մտածել, թե ինչին եք հավատում, և ինչի մասին լռում են ձեր շրջապատը։
Եթե ցանկանում եք արագ արդյունքների հասնել, ահա ձեզ համար լավ թեմա. տեսե՞լ եք ընկերություններ, որտեղ ոչ ոք չի ասում «ես չգիտեմ»: Կան վայրեր, որտեղ դուք բառացիորեն տանջում եք մարդուն այնքան ժամանակ, քանի դեռ նա չի ընդունում, որ ինչ-որ բան չգիտի: Բոլորն ամեն ինչ գիտեն, բոլորն էլ անհավանական էրուդիտ են։ Դուք մոտենում եք ցանկացած մարդու, և նա պետք է անմիջապես պատասխանի հարցին։ «Չգիտեմ» ասելու փոխարեն։ Ուռա, մի խումբ էրուդիտներ են վարձել։ Իսկ որոշ մշակույթներում ընդհանրապես շատ վտանգավոր է «չգիտեմ» ասելը, դա կարող է ընկալվել որպես թուլության նշան: Կան նաև կազմակերպություններ, որոնցում, ընդհակառակը, բոլորը կարող են ասել «չգիտեմ»։ Այնտեղ դա լիովին օրինական է, և եթե ինչ-որ մեկը սկսում է չարախոսել՝ ի պատասխան հարցի, ապա լրիվ նորմալ է պատասխանել. և այդ ամենը վերածել կատակի:
Իդեալում, դուք կցանկանայիք ունենալ այնպիսի աշխատանք, որտեղ դուք կարող եք մշտապես երջանիկ լինել: Հեշտ չի լինի, ամեն օր չէ, որ արևոտ և հաճելի է, երբեմն պետք է շատ աշխատել, բայց երբ սկսես հաշվել, կստացվի. վայ, սա իսկապես հիանալի վայր է, ես ինձ լավ եմ զգում այստեղ աշխատելով, ինչպես էմոցիոնալ, այնպես էլ ինտելեկտուալ: Եվ կան ընկերություններ, որտեղ դուք գնում եք որպես խորհրդատու և անմիջապես հասկանում եք, որ չեք կարող դիմանալ երեք ամիս և սարսափած կփախչեք: Ահա թե ինչի մասին եմ ուզում խոսել զեկույցում։
Թիմ Լիսթերը կժամանի հիմնական ելույթով DevOops 2019 համաժողովին, որը տեղի կունենա 29 թվականի հոկտեմբերի 30-2019-ը Սանկտ Պետերբուրգում։ Դուք կարող եք տոմսեր գնել . Մենք սպասում ենք ձեզ DevOops-ում:
Source: www.habr.com