Նախագծերը տարբեր են, և դրանք պետք է կառավարվեն տարբեր ձևերով: Խոշոր նախագծերում, որտեղ մեծ թվովմշակողների, էլ չեմ խոսում բիզնես վերլուծաբանների, փորձարկողների և նախագծի իրական պատվիրատուների մասին, առաջին պլան է մղվում գործողությունների համակարգման հարցը՝ ստվերելով մնացած բոլոր առաջադրանքները։
Հենց այս դեպքի համար է հորինվել Agile նախագծի կառավարման մեթոդոլոգիան։
Նրա 4 հիմնական պոստուլատները հետևյալն են.
- անհատները և նրանց փոխազդեցությունները ավելի կարևոր են, քան գործընթացներն ու գործիքները,
- աշխատանքային ծրագրակազմն ավելի կարևոր է, քան ամբողջական փաստաթղթերը,
- հաճախորդի հետ համագործակցությունն ավելի կարևոր է, քան պայմանագրային պարտավորությունները,
Փոփոխություններին արձագանքելը ավելի կարևոր է, քան պլանին հետևելը:
Ծրագրին և ամբողջական փաստաթղթերին հետևելու փոխարեն հաղորդակցությունների և վերջնական արդյունքի վրա կենտրոնանալը ձեզ ավելի ճկունություն է տալիս և թույլ է տալիս չբյուրոկրատացնել կոդավորման գործընթացը: Նման դեմոկրատական մոտեցման բացասական կողմը հստակ պլանավորման բացակայությունն է, օրենսգրքի արդեն գրված մասերը անընդհատ վերափոխելու անհրաժեշտությունը և դրա հետ կապված կանոնավոր շտապողականությունը:
Չնայած մի շարք թերություններին, շատ դեպքերում արագաշարժ մեթոդոլոգիան անփոխարինելի է։ Ուստի զարգացման բաժնի ցանկացած ղեկավար պետք է ծանոթ լինի դրան։
Զարգացման վարչության պետի պարտականությունները
Զարգացման չափանիշների և քաղաքականության մշակում ծրագրային ապահովումընկերության ՏՏ ընդհանուր քաղաքականությանը համապատասխան.
- զարգացման բաժնի աշխատանքների պլանավորում և համակարգում.
- Ծրագրի ժամանակացույցին համապատասխանության մշակում և մոնիտորինգ;
- նախագծերի բարդության գնահատում և զարգացման առաջադրանքների բաշխում ծրագրավորողների / մշակողների միջև.
- զարգացման գործընթացի կառավարում;
- զարգացում տեխնիկական առաջադրանքըծրագրային մոդուլների վրա;
- վարչության բյուջեի կատարման պլանավորում և վերահսկում.
- ծրագրային ապահովման մշակման մեջ ներգրավված արտաքին ռեսուրսների կառավարում.
- բաժնի աշխատանքը կարգավորող նորմատիվ փաստաթղթերի մշակում և գործառական ստորաբաժանումների հետ փոխգործակցության կարգը.
- մասնակցություն ընկերության զարգացման ռազմավարության մշակմանը.
Աշխատավարձի առաջարկներ և գործատուների պահանջներ
Մոսկվայի զարգացման բաժնի ղեկավարի միջին աշխատավարձի առաջարկը կազմում է 150000 ռուբլի, Սանկտ Պետերբուրգում՝ 117,000 ռուբլի, Վոլգոգրադում՝ 66,000 ռուբլի, Վորոնեժում՝ 75,000 ռուբլի, Եկատերինբուրգում՝ 100,000 ռուբլի՝ 0 ռուբ. - 90,000 ռուբլի, Նիժնի Նովգորոդում` 70,000 ռուբլի, Նովոսիբիրսկում` 85,000 ռուբլի, Օմսկում` 75,000 ռուբլի, Պերմում` 85,000 ռուբլի, Դոնի Ռոստովում` 75,000 ռուբլի` 75,000 ռուբլի: , Չելյաբինսկում՝ 84000 ռուբլի։
Զարգացման ղեկավարի պաշտոնին առաջին անգամ դիմող դիմորդները պետք է ունենան բարձրագույն կրթություն(պրոֆիլ կամ տեխնիկական), ծրագրային ապահովման մշակման փորձ առնվազն 3 տարի։ Օբյեկտ-կողմնորոշված ծրագրավորման և ծրագրային ապահովման մշակման մեթոդոլոգիայի (RUP, MSF) սկզբունքների իմացությունը պարտադիր է, պարտադիր է DBMS-ի հետ աշխատելու հմտություններ: Գործատուները ողջունում են ծրագրավորման մի քանի լեզուների իմացությունը: Մոսկվայի զարգացման բաժինների սկսնակ ղեկավարների մեկնարկային աշխատավարձը տատանվում է 70 000-ից 110 000 ռուբլի, Սանկտ Պետերբուրգում՝ 55 000-ից 86 000 ռուբլի, Վորոնեժում և Պերմում՝ 35 000-ից 55 000 ռուբլի։
| Քաղաք | Եկամտի մակարդակը, ռուբ. (այս պաշտոնում փորձ չկա) |
|
| Մոսկվա | 70 000 - 110 000 | - Բարձրագույն կրթություն (տեխնիկական/ՏՏ) - Ծրագրավորման մեկ կամ մի քանի լեզուների իմացություն - Հասկանալով օբյեկտի վրա հիմնված ծրագրավորման սկզբունքները - Ծրագրային ապահովման մշակման մեթոդիկայի իմացություն (RUP, MSF) -Գիտելիք անգլերեն լեզվիցտեխնիկական փաստաթղթերի ընթերցման մակարդակում - Փորձ DBMS-ի հետ - Ծրագրային ապահովման մշակման ոլորտում 3+ տարվա փորձ Դիմորդի դիմանկարը 1 միջակայքում |
| Սանկտ Պետերբուրգ | 55 000 - 86 000 | |
| Վոլգոգրադ | 30 000 - 48 000 | |
| Վորոնեժ | 35 000 - 55 000 | |
| Եկատերինբուրգ | 47 000 - 74 000 | |
| Կազան | 35 000 - 55 000 | |
| Կրասնոյարսկ | 42 000 - 66 000 | |
| Նիժնի Նովգորոդ | 33 000 - 52 000 | |
| Նովոսիբիրսկ | 39 000 - 62 000 | |
| Պերմի | 35 000 - 55 000 | |
| Օմսկ | 40 000 - 63 000 | |
| Դոնի Ռոստով | 35 000 - 55 000 | |
| Սամարա | 35 000 - 55 000 | |
| Ուֆա | 37 000 - 55 000 | |
| Չելյաբինսկ | 40 000 - 62 000 |
Զարգացման բաժինը 1 տարուց ավելի ղեկավարելու փորձ ունեցող թեկնածուներից գործատուներն ակնկալում են, առաջին հերթին, զարգացած կազմակերպչական և առաջնորդական հմտություններ։ Աշխատանքային պահանջները վերաբերում են նախագծերի պլանավորման, կազմակերպման և իրականացման փորձին, տեխնիկական փաստաթղթերի մշակմանը, ինչպես նաև օգտագործելու հմտություններին: գործիքներծրագրի կառավարում. Մայրաքաղաքում համապատասխան թափուր աշխատատեղերի համար դիմորդները կարող են ակնկալել մինչև 140,000 ռուբլի աշխատավարձ, Նևայի քաղաքում՝ մինչև 109,000 ռուբլի, Վորոնեժում և Պերմում՝ մինչև 70,000 ռուբլի:
| Քաղաք | Եկամտի մակարդակը, ռուբ. (1 տարվա աշխատանքային փորձով) |
Մասնագիտական հմտությունների պահանջներ և ցանկություններ |
| Մոսկվա | 110 000 - 140 000 | -Զարգացած կազմակերպչական և կառավարման հմտություններ - Ծրագրերի պլանավորման, կազմակերպման և իրականացման հմտություններ - Ծրագրի կառավարման գործիքների օգտագործման հմտություններ - Տեխնիկական փաստաթղթեր մշակելու ունակություն Դիմորդի դիմանկարը 2-րդ միջակայքում |
| Սանկտ Պետերբուրգ | 86 000 - 109 000 | |
| Վոլգոգրադ | 48 000 - 62 000 | |
| Վորոնեժ | 55 000 - 70 000 | |
| Եկատերինբուրգ | 74 000 - 94 000 | |
| Կազան | 55 000 - 70 000 | |
| Կրասնոյարսկ | 66 000 - 84 000 | |
| Նիժնի Նովգորոդ | 52 000 - 66 000 | |
| Նովոսիբիրսկ | 62 000 - 78 000 | |
| Պերմի | 55 000 - 70 000 | |
| Օմսկ | 63 000 - 80 000 | |
| Դոնի Ռոստով | 55 000 - 70 000 | Սամարա | 55 000 - 70 000 | Ուֆա | 55 000 - 70 000 | Չելյաբինսկ | 62 000 - 78 000 |
Լրացուցիչ կրթությունՏՏ ոլորտում և ամբողջական զարգացման ցիկլի ստեղծման փորձ. սրանք առավել բնորոշ պահանջներն են զարգացման կառավարման ավելի քան 2 տարվա փորձ ունեցող դիմորդների համար: Եկամուտը, որի վրա կարող են հույս դնել նման մասնագետները, հասնում է 175,000 ռուբլու մայրաքաղաքի ընկերություններում, 137,000 ռուբլի Սանկտ Պետերբուրգում և 88,000 ռուբլի Վորոնեժում և Պերմում:
| Քաղաք | Եկամտի մակարդակը, ռուբ. (2+ տարվա փորձով) |
Մասնագիտական հմտությունների պահանջներ և ցանկություններ |
| Մոսկվա | 140 000 - 175 000 | - Լրացուցիչ կրթություն ՏՏ ոլորտում - Զարգացման ամբողջական ցիկլի ստեղծման փորձ (սկսած տեխնիկական բնութագրերից մինչև նախագիծը շահագործման հանձնելը) Դիմորդի դիմանկարը 3-րդ միջակայքում |
| Սանկտ Պետերբուրգ | 109 000 - 137 000 | |
| Վոլգոգրադ | 62 000 - 77 000 | |
| Վորոնեժ | 70 000 - 88 000 | |
| Եկատերինբուրգ | 94 000 - 117 000 | |
| Կազան | 70 000 - 88 000 | |
| Կրասնոյարսկ | 84 000 - 105 000 | |
| Նիժնի Նովգորոդ | 66 000 - 82 000 | |
| Նովոսիբիրսկ | 78 000 - 98 000 | |
| Պերմի | 70 000 - 88 000 | |
| Օմսկ | 80 000 - 100 000 | |
| Դոնի Ռոստով | 70 000 - 88 000 | |
| Սամարա | 70 000 - 90 000 | |
| Ուֆա | 70 000 - 88 000 | |
| Չելյաբինսկ | 78 000 - 100 000 |
Ամենաբարձր աշխատավարձն առաջարկում են զարգացման բաժինների ղեկավարներին խոշոր ձեռնարկություններ. Այս գործատուները թեկնածուներից պահանջում են ունենալ առնվազն 3 տարվա փորձ նմանատիպ չափի կազմակերպություններում: Արտասահմանյան գործընկերներ ունեցող ընկերությունները գերադասում են մասնագետների, ովքեր վարժ տիրապետում են անգլերենին: Աշխատավարձի առավելագույն չափը Մոսկվայում հասնում է 300.000 ռուբլու, Սանկտ Պետերբուրգում՝ 235.000 ռուբլու, Վորոնեժում և Պերմում՝ 150.000 ռուբլու։
| Քաղաք | Եկամտի մակարդակը, ռուբ. (3 տարվա փորձով) |
Մասնագիտական հմտությունների պահանջներ և ցանկություններ |
| Մոսկվա | 175 000 - 300 000 | - Կառույցում զարգացման կառավարման փորձ մեծ ընկերություն 3 տարուց Հնարավոր ցանկություն. Անգլերենի իմացություն խոսակցական կամ սահուն մակարդակով Դիմորդի դիմանկարը 4-րդ միջակայքում |
| Սանկտ Պետերբուրգ | 137 000 - 235 000 | |
| Վոլգոգրադ | 77 000 - 130 000 | |
| Վորոնեժ | 88 000 - 150 000 | |
| Եկատերինբուրգ | 117 000 - 200 000 | |
| Կազան | 88 000 - 150 000 | |
| Կրասնոյարսկ | 105 000 - 180 000 | |
| Նիժնի Նովգորոդ | 82 000 - 140 000 | |
| Նովոսիբիրսկ | 98 000 - 170 000 | |
| Պերմի | 88 000 - 150 000 | |
| Օմսկ | 100 000 - 170 000 | |
| Դոնի Ռոստով | 88 000 - 150 000 | |
| Սամարա | 90 000 - 150 000 | |
| Ուֆա | 88 000 - 150 000 | |
| Չելյաբինսկ | 100 000 - 170 000 |
Դիմորդի դիմանկարը
Զարգացման բաժնի պետի պաշտոնին հավակնողներից մեծամասնությունը միջին տարիքի տղամարդիկ են՝ բարձրագույն կրթությամբ։ Դիմորդների թվում թույլ սեռի ներկայացուցիչները կազմում են ընդամենը 5 տոկոս, ինչը բնորոշ է ՏՏ ոլորտին։ Դիմորդների 58%-ը 30-ից 39 տարեկան մասնագետներ են։ Զարգացման բաժինների ղեկավարների 96%-ն ունի բարձրագույն կրթություն։ Յուրաքանչյուր երրորդ դիմորդը վարժ տիրապետում է անգլերենին:
Բլոգի ներկառուցման կոդը
Զարգացման վարչության պետ
Ծրագրի կառավարման հմտություններ - այս պահանջը հաճախ հանդիպում է զարգացման մենեջերի թափուր աշխատատեղերում: Իրականում այս խոսքերի հետևում կարող է շատ ավելին լինել, քան թվում է առաջին հայացքից։
Հաջորդ փուլն է հաճախորդին տեղեկացնել տեխնոլոգիայի մասին.
- Խոշոր նախագծերում մենք, անկասկած, ունենք « Դասախոսությունների և սեմինարների դասընթաց դիզայնի տեխնոլոգիայի ներդրման վերաբերյալ«. Դասախոսությունների այս դասընթացում մենք հաճախորդի աշխատակիցներին ներկայացնում ենք, թե ինչպես է տեղի ունենալու նախագծի ողջ գործընթացը.
- Ինչպե՞ս է կատարվում նախագիծը մեր տեխնոլոգիայի միջոցով:
- Ո՞վ ինչի համար է պատասխանատու.
- Ով ինչ է անում:
- Ինչո՞ւ են կատարվում որոշակի գործողություններ։
- Ինչու է անհրաժեշտ այս փաստաթուղթը: Ի՞նչ է նա տալիս երկու կողմերին: (աշխատողներին հասկանալի դարձնելու համար, որ գործընկերությունները օգուտներ են տալիս ոչ միայն մեզ, այլ նաև հաճախորդին):
- Ամեն հնարավորության դեպքում մենք Աշխատանքի ընթացքում առաջացող բոլոր խնդիրների մասին տեղեկացնում ենք որոշում կայացնողին. Դա անելու համար մենք ունենք մի շարք հատուկ ամենօրյա փաստաթղթեր, օրինակ՝ «Կոնտակտների օրագիրը» կամ «Շեղումների հայտարարությունը»: Եվ եթե ոչ ամենօրյա, ապա մի քանի օրը մեկ, հաճախորդի ղեկավարությունը պետք է ծանոթանա դրանց հետ։ Եվ քանի որ, որպես կանոն, անմիջապես արդարացումներ են գտնում՝ ես զբաղված էի, չէի կարդացել և այլն, ուրեմն, համապատասխանաբար, պետք է անընդհատ հիշեցնել այս մասին, գուցե նույնիսկ նմանակել որոշ իրավիճակներ, որոնք ղեկավարությանը ստիպում են կարդալ այս փաստաթղթերը:
Այս փուլի արդյունքն այն է, որ հաճախորդի բոլոր պատասխանատու անձինք ավարտել են դասախոսությունների դասընթացը և, որ ամենակարևորն է, ղեկավարությունը հստակ պատկերացնում է, թե ինչպես է կատարվում աշխատանքը (բնականաբար, եթե դա բավականաչափ սերտորեն վերահսկում է նախագիծը):
Հաճախորդի հետ հարաբերությունների կազմակերպում
Հաջորդ փուլը Հաճախորդի հետ հարաբերությունների կազմակերպումն է։ Այստեղ ես ուզում եմ ձեզ պատմել մեկ հետաքրքիր «հնարքի» մասին. մենք նախագծում ունենք այնպիսի դերեր (դրանք պաշտոններ չեն, այլ դերեր), ինչպիսիք են «Պայմանագրի մենեջեր» և «Օբյեկտի կառավարիչ» (առավել հաճախ դրանք կարող են նաև համակցվել և որոշների հետ: այլ պատասխանատվություն): Ինչպես նշված է այստեղ սլայդում, այս դերերը համապատասխանում են «վատ» և «լավ» սահմանումներին:
- Պայմանագրի կառավարիչվատ է". Սա կարող է լինել անհատ կամ թոփ մենեջերներից մեկը: Ամենից հաճախ պայմանագրային կառավարչի գործառույթը կատարում է ծրագրի ղեկավարը (եթե, իհարկե, նա ի վիճակի է դա անել): Այս մարդը «ոչ» է. նա կարող է գալ որոշում կայացնողի մոտ և ասել. «Մեր պայմանագրով այսպես է գրված, բայց հիմա դուք այլ կերպ եք անում, և դրա պատճառով շեղում կա: Եկեք պարզենք դա»: Նա միշտ մատնանշում է թերությունները, տեխնոլոգիային չհամապատասխանելը, կոչ է անում պահպանել փաստաթղթերըԴրա համար նա միշտ վատն է:
- ԲԱՅՑ օբյեկտի կառավարիչ- սա լավ է»: Սա մի մարդ է, ով տարբեր պատճառներով հաճախորդից լավ հարաբերություններ է հաստատել որոշում կայացնողի հետ: Միգուցե նա հենց այնպես դուր եկավ նրան: Կամ, օրինակ, նրանք ինչ-որ կապեր ունեն (ազգական, կլանային, ընկերական՝ ինչ էլ լինի): Հիմնական բանն այն է, որ հաճախորդը գտնվում է նրա մոտ:
Կառավարիչ օբյեկտը իրականում պահպանում է այս օբյեկտը: Խնդրում ենք նկատի ունենալ, որ սա նախագծի ղեկավար չէ, սա հատուկ մարդ է, ով ինչ է անում լավ հարաբերություններ է պահպանում հաճախորդի ղեկավարության հետ, իսկ երբ լինում են սուր խնդիրներ, հարթեցնում է դրանք։
Օրինակ, այն բանից հետո, երբ պայմանագրի մենեջերը խոսեց հաճախորդի հետ մեր պայմանագրերի որոշ պայմանների չկատարման մասին (սա կարող է ավարտվել, ընդհանուր առմամբ, մեզ համար ինչ-որ տհաճ խոսակցությունով), գալիս է օբյեկտի մենեջերը և սկսում հանգստացնել հաճախորդին. .
Իզուր չէի ասում, որ մենեջերի օբյեկտը կոչվում է «լավ»։ Սովորաբար ասում են, որ «լավ տղա» լինելը մասնագիտություն չէ։ Բայց սա մեր մասնագիտությունն է։ Օբյեկտի կառավարիչը «լավ տղան» է։ Նա կարող է ոչ մի բանի պրոֆեսիոնալ մասնագետ չէ, բայց հաճախորդն իրեն լավ է զգում՝ եկել, խոսել է նրա հետ (գուցե քաղաքականությունից, ֆուտբոլից և այլն), հաճախորդն իրեն լավ է զգում, վերաբերմունքը փոխվել է։ Մինչ այդ հաճախորդը պատրաստվում էր մեզ ինչ-որ բանի համար նկատողություն անել, ինչ-որ բանի համար պատժել, բայց հիմա արդեն ամեն ինչ հասկանում է, ընդհանրապես անհարմար է մեզ հետ վատ խոսել։
Սա օբյեկտների կառավարչի գործառույթն է: Այն նշանակված է յուրաքանչյուր բավականին լուրջ հաճախորդի:
Իհարկե, այն ամենը, ինչի մասին ես խոսում եմ, պահանջում է որոշակի ռեսուրսներ և ծախսեր։ Եվ, իհարկե, այս ամբողջ կառույցի ստեղծումը հանուն փոքր խանութի իմաստ չունի. այս ամենը արվում է միայն բավականաչափ մեծ օբյեկտների համար:
Այս փուլի արդյունքը տվյալ հաճախորդի համար համապատասխան պայմանագրի և օբյեկտի մենեջերի նշանակումն է, քանի որ շատ կարևոր է այդ մարդկանց ճիշտ ընտրելը։
Ծրագրի գործընթացների կազմակերպում
Հաջորդ փուլն է նախագծային գործընթացների կազմակերպում. Իմ կարծիքով, դրանցից միայն երկուսն են.
- Ծրագրի առաջընթացի մոնիտորինգ;
- Եվ մոնիտորինգի արդյունքների հիման վրա կառավարման որոշումներ կայացնելը:
Ամենակարևորը հաճախորդին համոզելն է աշխատել մեր տեխնոլոգիայով. Այս ընթացակարգը բացատրվում է հաճախորդին և՛ որոշում կայացնողների հետ անձնական զրույցներում, և՛ երբ պատասխանատու աշխատակիցները մասնակցում են դասախոսությունների դասընթացին (այն բացատրում է, թե ինչպես և ինչ կլինի նախագծում. հաճախորդի աշխատակիցները պետք է անպայման մասնակցեն այս դասընթացին, ստորագրության տակ):
Երբեմն կարող է շատ դժվար լինել հաճախորդին համոզելն աշխատել մեր տեխնոլոգիայի հետ: Օրինակ, մենք ունեինք մեկ հաճախորդ՝ շատ մեծ ՏՏ ընկերություն։ Ավելին, նա ինքն էր զբաղվում MS Navision-ի ավտոմատացումով, բայց որոշակի պատճառներով նա որոշեց զանգահարել մեզ, որպեսզի կարողանանք դրանք ավտոմատացնել 1C-ում: Այսպիսով, նրանց հետ աշխատելը իսկական մղձավանջ էր՝ բոլորը լաց էին լինում՝ և՛ մենեջերները, և՛ ծրագրավորողները: Քանի որ դա շատ մեծ ընկերություն էր (մենք նրանց համեմատ փոքր ենք), և նրանք կարծում էին, որ ամեն ինչ գիտեն և փորձում էին մեզ սովորեցնել։ Անընդհատ ասում էին. «տղերք, ամեն ինչ այդպես չեք անում, այսինչ տեխնոլոգիան կա, այսպես պետք է անեք»։ Բնականաբար, դա տեղի ունեցավ միայն միջին մակարդակում, ղեկավարը (որը ընկերության հիմնական սեփականատերն ու գլխավոր տնօրենն էր), իհարկե, ամեն ինչ հիանալի հասկացավ, և նրա միջամտությունից հետո ամեն ինչ որոշվեց, բայց նրան ձեռք բերելը շատ դժվար էր։ Իսկ միջին մակարդակում անընդհատ խնդիրներ են եղել, դասավանդելու անընդհատ փորձեր։
Մենք յուրաքանչյուր նախագծի վրա ենք, առանց ձախողման, Մենք փորձում ենք հաճախորդին փոխանցել այն միտքը, որիր բիզնեսում նա պրոֆեսիոնալ է (և մենք, իհարկե, այնտեղ չենք գնում), իսկ ավտոմատացման հարցերում մենք պրոֆեսիոնալ ենք, ուստի պետք է վստահել և չփորձել մեզ ասել, թե ինչ և ինչպես անել: Հատկապես եթե մեզ ոչ թե ուղղակի ասում են, այլ փորձում են ստիպել՝ «եկեք այլ կերպ վարվենք, քանի որ ես եմ ուզում»։ Սրանք այն բաներն են, որոնք մենք փորձում ենք անմիջապես կանգնեցնել: Իհարկե, «կանգն» ուժեղ բառ է, ամեն դեպքում փորձեք մեղմ բացատրել։ Եթե մենք համաձայնվեցինք այս նախագծին, որոշեցինք, որ դա մեզ ձեռնտու է, ներքաշվեցինք այս «ճակատամարտում», հիմա, իհարկե, պետք է աշխատենք դրա հետ։
Հաճախորդի ցանկությունների սահմանափակում
Հաջորդ փուլն է հաճախորդի ցանկությունների սահմանափակում. Բոլորը, հավանաբար, բախվել են դրան (երբ սկսվում է այսպես կոչված «Ցանկությունների ցուցակը՝ ավելի, ավելի ու ավելի շատ): Այստեղ մենք դա անում ենք բավականին պարզ.
- Օրինակ, երբ հաճախորդն ասում է, որ հատկացված բյուջեի և ժամկետների մեջ սա և սա նույնպես պետք է արվի, ապա դա սկսվում է բավականին հաճախ, դժվար բացատրելով, թե ինչպես է այդ ամենը աշխատում. Հաճախորդին հիշեցնում ենք, որ իր հետ ունենք բյուջե, մարդիկ են հատկացվում (համատեղ աշխատանքային խումբ), ծրագրի յուրաքանչյուր կողմ ներդնում է իր ռեսուրսները։ Հետեւաբար, եթե լրացուցիչ աշխատանք է առաջանում, ապա լրացուցիչ ժամեր, լրացուցիչ մարդիկ են պահանջվում։ Որտեղի՞ց վերցնել դրանք:
Կամ եթե հաճախորդը հետաձգում է նախագիծը, ուրեմն և՛ մերոնք, և՛ նրա մարդիկ պարապ են, և նրանց գումար են վճարում։ Որտեղի՞ց ստանալ այս ռեսուրսները: Էլ չեմ խոսում այն մասին, որ այդ մարդիկ ոչ միայն աշխատավարձ են ստանում, այլեւ որոշակի շահույթ են բերում ընկերությանը։ Բնականաբար, ընկերությունը չի ցանկանում կորցնել այս շահույթը։ Հաճախորդին այն բացատրվում է բավական մանրամասն, և հաճախորդը սովորաբար շատ լավ է արձագանքում: - Մենք բացատրում ենք մենք տալիս ենք մանրամասն թվային դասավորություն- որտեղ, ինչ, կոպեկին: Եվ մենք դա ասում ենք եթե ցանկանում եք, որ մենք նույնպես դա անենքապա խնդրում եմ այդքան ժամ կպահանջվի, և դրանք պետք է վճարվեն. Ի վերջո, հաճախորդը համաձայնվում է մեզ հետ և կամ հրաժարվում է իր «Ցանկությունների ցուցակից», կամ վճարում է լրացուցիչ ժամերի համար։ Իհարկե, դա տեղի է ունենում տարբեր ձևերով. ես հիմա մի փոքր իդեալականացնում եմ նկարը:
Այստեղ ես ուզում եմ հարաբերությունների մեկ այլ օրինակ բերել. Մենք աշխատեցինք մեկ շատ մեծ ընկերության հետ (նրանք արդեն տեխնիկական սպասարկման փուլում էին), և այնտեղ պարբերաբար առաջանում էին բարելավման որոշ խնդիրներ. օրինակ՝ ինչ-որ խրթին հաշվետվություն կազմել կամ այլ բան: Եվ այսպես, ընկերության գլխավոր հաշվապահը մեզ վստահեց որոշակի աշխատանք, և մենք դա արեցինք։ Եվ երբ եկավ վճարելու ժամանակը, նա ասաց. «Ընդհանուր առմամբ, ես սխալվեցի, մեզ ընդհանրապես պետք չէ այս ամենը»: Բայց գործն արված էր, հետեւաբար՝ պետք էր վճարել։ Եվ նա ասում է. «Ոչ, ես չեմ վճարի դրա համար, բայց ես չեմ կարող գնալ ընկերության նախագահի մոտ և ասել, որ ես հիմար եմ և սխալ բան եմ պատվիրել»: Ավելին, ընկերությունը շատ մեծ էր, նավթային ընկերություն, հարաբերությունները լավ էին և՛ նրա հետ, և՛ այս մարդու հետ։ Իսկ մենք չպնդեցինք՝ չի վճարում, չի վճարում։ Չնայած սրա պատճառով մենք այն ժամանակ բավականին մեծ գումար ենք կորցրել մեզ համար (2004թ.)։ Տարեվերջին կար դավանանք (ադրբեջանական մանաթը զրոները դեն նետեց): Եվ բոլոր հաճախորդների համար, ովքեր եղել են մեր ծառայության մեջ, մենք կատարել ենք այս վերահաշվարկը աշխատանքային կարգով` առանց հավելյալ գումարի: Բայց այս հաշվապահին (այն ժամանակ բառացիորեն մեկ տարի էլ չէր անցել այդ դեպքից), մոտեցանք և ասացինք. Հետո մենք գնացինք քեզ հանդիպելու: Հիմա՝ դավանանք։ Եկեք դա անենք անվճար»: Հարցեր չեն տրվել՝ հաշիվ-ապրանքագիր ենք տվել, վճարել է։
Ինչո՞ւ բերեցի այս օրինակը: Լավ հարաբերությունների կարևորության մասին. Եթե մենք այն ժամանակ մեծանայինք և պահանջեինք վճարել մեզ այս գումարը, ապա կունենայինք լավ հաճախորդ կորցնելու վտանգ: Եվ այսպես, մենք կապ պահպանեցինք նրա հետ։
Ո՞վ է պատասխանատու այս բյուջեի բացատրության համար:
- Սա բիզնեսի ձևով, աշխատանքի կանոնավոր ընթացքովնշանված է Ծրագրի ղեկավար- համատեղ աշխատանքային խմբի ղեկավարը, որն, ըստ էության, իրականացնում է նախագիծը։
- Եթե ձախողվում է, ուրեմն կապում է պայմանագրային կառավարիչ, ով բացատրում է թվերով և ասում, որ սա է. պայմանագրի խախտում, պայմանագրի խախտում.
- Ամենադժվար դեպքերումկապում է օբյեկտի կառավարիչով փորձում է բացատրել (արդեն, իհարկե, առանց որևէ կոշտ շրջանակի) հաճախորդին, թե ինչու է նա պետք սահմանափակի իր ցանկությունները:
Սովորաբար, եթե թվերը գրված են շատ մանրամասն, ապա այս դասավորությունը և դրա բացատրությունը բավական են։
Աշխատանքների առաքում
Աշխատանքների առաքում. Այստեղ, ընդհանուր առմամբ, սովորաբար մեծ խնդիրներ չեն լինում, քանի որ Աշխատանքների հանձնման կարգը շատ մանրամասն է մերհամապատասխան փաստաթղթեր.
Բայց այս փուլում ոչ պաշտոնականության տարրը ( լավ հարաբերություններ), իհարկե նաև հեշտացնում է կյանքը և՛ մեր, և՛ հաճախորդի համարնույնպես։
Այս փուլի նպատակն է հասնել աշխատանքների առաքմանը համապատասխան փաստաթղթերում սահմանված կանոններին համապատասխան, որոնք և՛ պատվիրատուի, և՛ մեր կողմից ստորագրված պայմանագրի հավելվածն են: Ըստ այդմ, միշտ կարելի է ցույց տալ, որ կան նման կանոններ։
Հետնախագծային հարաբերություններ
Եվ վերջապես, հետնախագծային հարաբերություններ: Սա նույնպես շատ կարևոր մասն է։ Ինչի՞ն պետք է ուղղված լինենք նախագծի վերջում: Ծառայության պայմանագրի կնքմանը, իհարկե։ Բայց միշտ չէ, որ այդպես է։ Որովհետև կա «արդյունք» հասկացությունը, և կա «արդյունք» հասկացությունը, և դրանք մի փոքր տարբեր բաներ են:
Ես ձեզ օրինակ բերեմ. Մենք նախագիծ ունեինք մեկ շատ լուրջ ընկերության հետ, և այդ նախագծի արդյունքը մեզ համար փայլուն էր. դա այն հազվադեպ դեպքերից էր, երբ մենք ամբողջությամբ կատարեցինք և՛ բյուջեն, և՛ վերջնաժամկետը՝ ճիշտ այնպես, ինչպես ի սկզբանե նախատեսված էր: Սա էր արդյունքը. Իսկ նախագծի արդյունքը եղավ այն, որ սպասարկման պայմանագիրը չկնքվեց։ Ավելին, հաճախորդն ասաց, որ այլեւս երբեք չի աշխատի մեզ հետ։ Ահա արդյունքը. Այսինքն՝ արդյունքը փայլուն է, բայց արդյունքը՝ շատ տխուր։
Ինչու՞ դա տեղի ունեցավ: Որովհետև ոչ պաշտոնական հարաբերություններ չեն եղել։ Մենք հենց այդ ժամանակ մշակել էինք մեր նախագծային փաստաթղթերի տեխնոլոգիան, և սա այն պատվիրատուն էր, որի վրա ցուցադրվեց այս ամբողջ տեխնոլոգիան իր ողջ փառքով: Եվ երբ մենք հաճախորդին հարցրինք. «Դե, դուք չեք աշխատի մեզ հետ, բայց կա՞ն որևէ պահանջ մեր դեմ»: Եվ մեզ զայրույթից ատամների միջով ասացին. «Դա է խնդիրը, որ մենք չենք կարող որևէ պահանջ ներկայացնել, ինչ էլ ասես, ամեն ինչի համար թղթի կտոր ունես, և մենք ոչինչ չենք կարող անել: Սա մեզ չի բավարարում, և մենք ձեզ հետ այլևս չենք աշխատի։ Մյուս ընկերություններին կարող են խնդրել լրացուցիչ ինչ-որ բան անել, բայց դուք հրաժարվում եք՝ ահա ձեր բյուջեն, ահա դուք ունեք այն, ինչպես պետք է լինի, ահա վերջնաժամկետը: Մի կողմ քաշվեք, և դուք անմիջապես մեզ ցույց եք տալիս մեր ստորագրությամբ մի թուղթ։
Այսպիսով, արդյունքը տխուր է: Բայց ևս մեկ անգամ շեշտում եմ, որ նման արդյունքը պայմանավորված էր նրանով, որ ոչ պաշտոնական հարաբերություններ չեն եղել։
Այս հոդվածը հիմնված է հեղինակի կողմից 2014 թվականի հոկտեմբերի 29-31, 2014 թվականի հոկտեմբերի 29-31-ը IE Infostart կոնֆերանսի ժամանակ կարդացած զեկույցի վրա:
Մենք ձեզ հրավիրում ենք նոր կոնֆերանսի:
Լավ օր! Այսօր ես կցանկանայի խոսել այն ձևերի մասին, որոնցով հաճախորդը փոխգործակցում է աութսորսինգ ընկերության հետ, ինչպես նաև ձեզնից մեկնաբանություններ ստանալ այն մասին, թե ինչպես եք շփվում ձեր հաճախորդների/ծրագրային ապահովման մշակողների հետ: Այս հոդվածը գրված է փորձի հիման վրա և, մեծ մասամբ, նախատեսված է ծրագրային ապահովման հաճախորդների համար: Նպատակը հաճախորդի և ծրագրային ապահովման մշակման ծառայություններ առաջարկող ընկերության հարաբերություններում «խցաններ» գտնելն է։
Թույլ տվեք ներկայացնել ինքս ինձ. ես Յուրի Կորխովն եմ և այս հոդվածն առաջինն է իմ Habré-ում: Ավարտել է Բելառուսի ազգային տեխնիկական համալսարանը (անվտանգության ինժեներ), Բելառուսի պետական համալսարանը (ներդրումների մենեջեր): Աշխատանքային փորձ - ավելի քան 6 տարի ՏՏ ոլորտում գրեթե բոլոր պաշտոններում՝ վեբ վարպետ, դասավորության դիզայներ, վեբ դիզայներ, ծրագրավորող, նախագծի մենեջեր և կես դրույքով UI ծրագրավորող, բաժնի ղեկավար... Ընդհանուր առմամբ, այս ընթացքում ավելի քան 80 նախագիծ իրականացվել են՝ փոքր կայքերից, բջջային հեռախոսների համար նախատեսված խաղերից մինչև խոշոր ինտերնետային պորտալներ... Հիմնական պրոֆիլը ՏՏ ոլորտում նախագծերի մշակման կառավարումն է։ Նա աշխատում էր և՛ պատվիրատուի, և՛ ծրագրավորողի կողմից՝ և՛ ռուսական շուկայում, և՛ արտասահմանյան։
Գրառման ստեղծման նախապատմություն կամ Շնորհակալություն Wargaming:
Այս գրառման ստեղծման պատմությունը շրջանցելը լավ չի լինի, քանի որ. Ես շատ երկար եմ կարդում habr-ը, բայց ձեռքերս չհասցրեցին հոդված գրել, բայց այստեղ դա «շանսի» հարց է, և այժմ հոդվածը պատրաստ է:
Արդեն մի երկու ամիս է աշխատանքից ընդմիջում եմ, քանի որ հոգնել եմ աութսորսինգից, որոշեցի կյանքի իմաստը գտնել ու կամաց-կամաց նախագիծս պատրաստեմ մեկնարկի, ու մի գեղեցիկ օր հեռախոսը զանգեց։ Wargaming-ի հավաքագրողը («tanchiki»-ի հիմնադիրները և, իմ կարծիքով, Մինսկի լավագույն ֆիրմաներից մեկը) զանգահարեց ինձ՝ Վաճառողի մենեջերի թափուր աշխատատեղի համար հարցազրույցի առաջարկով (այստեղ պետք է ասել, որ ես աշխատանք չէի փնտրում։ , և, դատելով նրանց թափուր աշխատատեղից, ես նրանց լավ չէի սազում): «Դա հետաքրքիր է»: -Մտածեցի ու որոշեցի կատարել թեստային առաջադրանքը, մանավանդ որ այն բավականին հետաքրքիր էր ինձ համար։ Հավաքագրողն ասաց, որ իրենք ունեն բոլոր պայմանները հաճելի, առողջ (ֆիթնես, ապահովագրություն և այլն) և լավ վարձատրվող աշխատանքի համար, և, ամենակարևորը, թեստային առաջադրանքը կատարելու համար ինձանից կպահանջվի մոտ 3 ժամ: Կասկածում եմ, որ ինչ-որ մեկը կկարողանար կատարել ամբողջ թեստային առաջադրանքը նշված ժամկետում, ինչ վերաբերում է ինձ, այն տևեց մոտ 6 ժամ:
Ի ափսոսանք, ընկերության արձագանքը հեռախոսազրույցում էր և արտահայտվում էր «ամեն ինչ լավ է, բոլորին դուր եկավ» չոր արտահայտությամբ (բառացի չեմ հիշում, բայց էությունը սա է) և առանց որևէ կոնկրետության։ Կասկածում եմ, որ կարողացել եմ մատնանշել բոլոր հիմնական «խցանները». Աշխատանքը վատնելը լավ չէ, ես որոշեցի թեստային առաջադրանքի պատասխանները (փոքր փոփոխություններով, հարմարության համար) հրապարակել հանրությանը և շնորհակալ կլինեմ habra հանդիսատեսին հոդվածում լրացումների և առողջ մեկնաբանությունների համար:
Հաճախորդի և ծրագրաշարի մշակողի միջև փոխգործակցության սխեման առաջին հանդիպումից մինչև հարաբերությունների ավարտը:
Շղթա նախագծելիս նկատի ունեմ.- Ծրագրաշարի մշակողը կարողանում է ավարտին հասցնել նախագիծը:
- Մինչ այդ ծրագրային ապահովման մշակողի հետ պայմանագիր չի կնքվել, նախագծեր էլ չեն եղել։
- TK-ն պատրաստ է։
- Վճարման պայմանները կարգավորվում են պայմանագրով:
- Օգտագործվում են նախագծերի կառավարման համակարգեր և ծրագրային ապահովման մշակման մեթոդոլոգիաներ (XP, Scrum, Lean, Kanban, ScrumBut և այլն):
- Հայտի բովանդակությամբ լրացումը (անհրաժեշտության դեպքում) կատարվում է հաճախորդի կողմից:
Ծրագրային ապահովման մշակման վաճառողի և հաճախորդի միջև պայմանագրի ասպեկտները ձեռնտու են վաճառողի համար խուսափելուց (պարզեցնել, ընդհանրապես հեռացնել պայմանագրից):
- Վերջնաժամկետները պահպանելու պատասխանատվությունը կրում է մշակողը, և եթե վերջին պահին ժամկետները բաց են թողնվել (այսինքն՝ կառուցապատողը նախապես չի տեղեկացրել, որ ժամանակ չի ունեցել փակվելուց առաջ), պետք է տույժեր սահմանվեն (կա մեծ ընտրություն։ տարբերակներից):
Պատճառը. ժամկետների չկատարումը ամենամեծ խնդիրներից է, և պայմանագրում դրա մասին նշելն այնքան էլ հետաքրքիր չէ, քանի որ. Մեծ մասամբ, վերջնաժամկետները չկատարելը ծրագրավորողի կողմն է: Այստեղ պետք է հաշվի առնել, որ դժվար է ճշգրիտ հաշվարկել, սակայն պետք է նախապես զգուշացնել, որ մշակողը ժամանակ չունի մշակման փուլն ավարտելու որոշակի ժամկետում, և դա պետք է նախատեսված լինի պայմանագրում. . - Երաշխիքային պայմաններ՝ ծրագրավորողի մեղքով «վրիպակներ» շտկելու համար, որոնք ժամանակին չեն հայտնաբերվել։ Երաշխիքի սովորական ժամկետը 3 ամիս է:
Պատճառը. հաճախ է պատահում, որ որոշ «սխալներ» չեն շտկվել կամ արդեն հայտնվել են աշխատանքի ընթացքում, ուստի այս կետը հաճախ փորձում են չնշել կամ նվազեցնել երաշխիքային ժամանակը: Իմ կարծիքն այն է, որ 3 ամսից պակասը բավարար չէ։ - Մշակված ծրագրերի, մոդուլների, բլոկների և այլնի իրավունքները: պատկանում է հաճախորդին և չի կարող օգտագործվել հետագա վերավաճառքի համար:
Պատճառը. Կառուցապատողի համար ձեռնտու է ունենալ մտավոր սեփականության իրավունքներ կամ կարողանալ վաճառել/օգտագործել մշակումները այլ հաճախորդների համար, ինչն իր հերթին կարող է հաճախորդին դնել շուկայում անհարմար իրավիճակում: - Համակարգում նոր մոդուլ մշակելիս, որն ազդում է այլ մոդուլների կամ ամբողջ համակարգի աշխատանքի վրա, մշակողը պետք է ապահովի ամբողջ համակարգի գործունեությունը:
Պատճառը. հաճախ մեկ մոդուլի մշակումը կարող է վնասել մեկ այլ մոդուլի կամ ընդհանրապես ամբողջ համակարգի աշխատանքին, և հետագա բարելավումները կարող են ընկնել հաճախորդի «ուսերին» (ֆինանսական առումով): Մշակողը պարտավոր է հաշվի առնել ամբողջ համակարգի կառուցվածքը և հաճախորդի կողմից հայտնաբերված «սխալների» դեպքում անվճար ուղղել այն։ - Մշակման համար տեխնիկական փաստաթղթերը պետք է կազմվեն՝ հաշվի առնելով հաճախորդի պահանջները:
Պատճառը. մշակողների համար ձեռնտու է լիովին կապվել հաճախորդի հետ և հաճախ է պատահում, որ փաստաթղթերը չեն պահպանվում: - Կայքի մշակման դեպքում կապալառուն պետք է հաշվի առնի կայքի SEO-ի օպտիմալացումը, այն է՝ նկարների նկարագրությունը, էջերը…
Պատճառը՝ «փոքր բաների վրա» ժամանակ խնայելը, որը, կախված պայմանագրի պայմաններից, կարող է հանգեցնել հաճախորդի ֆինանսական կորուստների (ծրագրաշարի մշակողը խնայում է ժամանակը/ֆինանսները): - Համակարգի փորձարկումը պետք է տրամադրվի համակարգի մշակողի կողմից:
Հաճախորդի կողմից պատրաստի մոդուլի ընդունումը չպետք է վերածվի համակարգի փորձարկման, այսինքն. ծրագրավորողը պարտավոր է հաճախորդի կողմից հայտնաբերված «սխալների» վերացումը ձեռնարկել իր հաշվին: Սա անհրաժեշտ է մշակողի կողմից արտադրանքի որակի փորձարկումն ապահովելու համար: Մինչ ծրագրավորողը ասում է «կատարված է» և սկսվում է հաճախորդի կողմից փորձարկումը, «սխալները» շտկվում են անվճար: - Ծրագրի հյուրընկալման պատասխանատվությունը հաճախորդի կողմից ստանձնում է մշակողը: Այս դեպքում հաճախորդը պարտավոր է ապահովել կայքի տեխնիկական պահանջների պահպանումը:
Պատճառը՝ հաճախորդի կողմից նախագծի հոսթինգը երբեմն կարող է որոշակի դժվարություններ առաջացնել, ինչը կարող է հանգեցնել «գլխարկի», ուստի սերվերի հոսթինգի և կազմաձևման պատասխանատվությունը պետք է լինի ծրագրաշարի մշակողի վրա: - Եթե ծրագրակազմ մշակողը ստիպված է դիմել իր թիմից դուրս գտնվող մասնագետների օգնությանը, նա պարտավոր է իր վրա վերցնել արտահոսքի, տվյալների կորստի կամ ցանկացած այլ վնասի հետ կապված բոլոր ռիսկերը, որոնք արտաքին աշխատակիցը կարող է պատճառել իր գործողություններով կամ անգործությամբ:
Պատճառը՝ պատահում է, որ ծրագրավորողը կարող է հիվանդանալ, հեռանալ և այլն։ աշխատակիցներից մեկը. Այս դեպքում հաճախորդը պետք է ապահովագրված լինի։ - Ծրագրի կրկնօրինակները պետք է տրամադրվեն մշակողի կողմից առնվազն օրական մեկ անգամ: Ծրագրի վերաբերյալ տվյալների կորստի հետ կապված ցանկացած խնդիր պետք է ստանձնի մշակողը:
Պատճառը. այստեղ դուք պետք է նշեք, թե ով է պատասխանատու նախագծի անվտանգության համար ցանկացած ձախողման դեպքում: - Մշակողը պետք է ելնի այն տեխնոլոգիաների կիրառման հանրաճանաչությունից, որն օգտագործում է ընտրելիս։
Պատճառը՝ կապված սեփական տեխնոլոգիաների հետ, ինչը կբարդացնի կյանքը, եթե հաճախորդը տեղափոխվի այլ մշակողի:
Աութսորսինգի աշխատանքի արժեքը իրականության համեմատ գերագնահատելու հայտնի եղանակներ, ենթադրում եմ, որ դրանք ավելի շատ են:
- Նախագծի մշակման արժեքի մակերեսային գնահատում, որպես ամբողջություն, առանց այն փուլերի բաժանելու, ինչը կարող է հանգեցնել ծրագրի արժեքի 2x-3x գերազանցմանը:
- Պայմանագրով սահմանված ժամկետում կատարված աշխատանքի վերաբերյալ հաշվետվություններ չտրամադրելը կամ հաճախորդի կողմից զարգացման առաջընթացը վերահսկելու անկարողությունը.
- Տեխնոլոգիայի սխալ ընտրությունը տեխնիկական մասի իրականացման ժամանակ կարող է զգալիորեն մեծացնել զարգացման արժեքը։
- Մշակողների թիմում ճիշտ մասնագետների բացակայությունը, ինչը մեծացնում է մշակման ժամանակն ու արժեքը։
- Ծրագրի կամ մոդուլի մշակման ֆիքսված ծախս և արժեքի հետագա ավելացում յուրաքանչյուր փոքր բանի համար, որը երկու կողմերն էլ տարբեր կերպ էին հասկանում:
- Ծրագրի մշակման ֆիքսված ծախսերի սահմանում. ավելի բարձր ռիսկը ստիպում է ներառել ծրագրի արժեքի մեջ:
- Դիզայնը մշակելիս նախատիպավորումը չի օգտագործվում, և դիզայնի մշակումն իրականացվում է տեքստային TOR-ի հիման վրա, ինչը, ի վերջո, հանգեցնում է մեծ թվով բարելավումների / ուղղումների և, համապատասխանաբար, նախագծի արժեքի բարձրացման:
- Ֆունկցիոնալության ավելացում / բարդացում: Դուք կարող եք դա ավելի հեշտացնել - դժվարացնել այն:
- «Գեղեցիկ», որտեղ դրանք պետք չեն (կարող եք ասել կայքի ադմինիստրատորի մասի մասին, եթե կարող եք օգտագործել css շրջանակները ադմինի արագ հարմարեցման համար. մասերը. դրանք սկսում են զարգանալ զրոյից):
«Հաճախորդ-ծրագրային ապահովման մշակման վաճառող» հարաբերությունների օրինակը, որն, իմ կարծիքով, ամենամոտ է գործնական օգտագործմանը:
Շատ աութսորսինգ ընկերություններ նախընտրում են մուտք չտալ իրենց նախագծերի կառավարման համակարգերին՝ առանց մանրամասն տեղեկություններ տրամադրելու, ես անձամբ կարծում եմ, որ մուտքը պետք է տրամադրվի հաճախորդի խնդրանքով: Հաճախորդը պատասխանատու է նախագծի իրականացման համար, և զարգացման առաջընթացը իրական ժամանակում տեսնելը կարևոր է:Ծրագրաշարի մշակողի և հաճախորդի միջև փոխգործակցության հիմնական կետերը, որոնք ես համարում եմ օպտիմալ.
Նաև կարծում եմ, որ ծրագրի ընդհանուր արժեքի հաշվարկը հաշվի առնելով ծրագրային ապահովում մշակելը փողի ու նյարդի վատնում է, նման զարգացումը սովորաբար հանգեցնում է կոնֆլիկտային իրավիճակների։
- Աշխատանքի համար վճարում՝ հիմնված աշխատողների աշխատանքի ժամավճարի կամ զարգացման ամբողջ թիմի մասնագետի աշխատանքի միջին արժեքի վրա: Անհրաժեշտ է գնահատել զարգացման փուլերը: Ինչու եմ կարծում, որ գնագոյացման այս ձևը օպտիմալ է.
- Այն չի պահանջում շատ բծախնդիր մոտեցում նախագծի գնահատման հարցում, որը գրեթե անհնար է 100%-ով ճշգրիտ դարձնել: Եթե գնահատումը սխալ է արվում, և ծրագրաշարի մշակողը սկսում է դա հասկանալ, ապա ֆունկցիոնալությունը «խախտվում է» հնարավորության դեպքում, ինչը, ի վերջո, կազդի օգտագործելիության վրա:
- Բարելավում է ծրագրային ապահովման մշակողի և հաճախորդի միջև փոխըմբռնումը, ինչպես հիմնական խնդիրը կրճատվում է սկզբունքով. «դա արեք արդյունավետ և արագ», և ոչ թե «ներդնեք սեղմ բյուջեում և ինչպես դա լավ կաշխատի»:
- Հաճախորդը, հիմնվելով ծախսած ժամերի վերաբերյալ ամենօրյա հաշվետվությունների վրա, կարող է տեսնել, թե մշակման ընթացքում աշխատողները որքան ժամանակ են ծախսում տարբեր բլոկների վրա, ինչը հնարավորություն է տալիս հասկանալ ծրագրային ապահովման մշակողների աշխատողների աշխատանքի արագությունն ու որակը:
- Հաճախորդի և ծրագրի ղեկավարի փոխազդեցությունն իրականացվում է հնարավորինս անմիջականորեն, այսինքն. skype-ից, հեռախոսներից և այլնից օգտվելիս:
- Միայն 2-շաբաթյա հաշվետվությունները և պլանները պետք է ուղարկվեն փոստով (հսկողության համար):
- Հաճախորդը տրամադրում է հավելվածի նախատիպը կամ այն մշակվում է ծրագրային ապահովման մշակման թիմի կողմից, եթե անհրաժեշտ է.
- Պարզեցնում է նախագծի հիմնական ֆունկցիոնալության ըմբռնումը:
- Բարձրացնում է նախագծի մշակման ընդհանուր արագությունը:
- Հստակ պահանջներ ինչպես հաճախորդի, այնպես էլ մշակողի ֆունկցիոնալության համար:
- Հստակ պատկերացում, թե ուր է շարժվելու նախագիծը:
- Ծրագրի կառավարման համակարգ՝ ծրագրի առաջընթացին հետևելու և գործընթացը վերահսկելու ունակության, յուրաքանչյուր առաջադրանքի վրա ծախսվող զարգացման ժամանակը: Ցավոք, մշակողները հազվադեպ են մուտքի հնարավորություն տալիս:
- Ցանկալի է, որ ամբողջ նախագիծը կատարվի մեկ թիմի կողմից, այսինքն. այնպես չլինի, որ մի փուլը մի ընկերությունն է անում, մյուսը՝ մյուսը և այլն։
- Անցակետերը («վազում») յուրաքանչյուր 2 շաբաթը լավագույն ժամանակն է նախագիծը վերահսկելու համար:
- Մշակման ժամանակ նախապատվությունը տրվում է հայտնի շրջանակներին, ինչպես նաև ավելի հեշտ ադապտացման համար ցանկացած իրավիճակում, երբ անհրաժեշտ է նախագիծը փոխանցել այլ մշակողների:
- Որակի փորձարկումը մշակողի կողմից ուղղակի պատասխանատվություն է: Նախագիծը կամ դրա մի մասը հաճախորդին փոխանցելիս ամեն ինչ պետք է մանրակրկիտ ստուգվի։
- Տարբեր բրաուզերների աջակցությունը մշակողի անմիջական խնդիրն է
ԵզրակացությունՀիմնական բանը գործընկերային / փոխշահավետ և վստահելի հարաբերություններին հավատարիմ մնալն է ՝ հասկանալով, որ մշակողները նույն մարդիկ են, և նրանց կյանքը բարդացնելը բարդացնում է կյանքը ձեզ համար: Յուրաքանչյուրը պետք է պատասխանատու լինի աշխատանքի իր մասի համար, հաճախորդը պետք է պատասխանատու լինի հստակ տեխնիկական բնութագրի տրամադրման և առաջացող հարցերին օպերատիվ արձագանքելու համար՝ չմոռանալով վճարել աշխատանքի համար, իսկ մշակողը` որակի, ժամանակի, արագության համար: Իդեալին, իհարկե, չի հաջողվել, բայց մենք ճիշտ ուղու վրա ենք։
ես հավանում եմ
21Վաճառքի վերաբերյալ գրականության տարբեր աղբյուրներում դուք կարող եք գտնել վաճառքի տարբեր փուլեր: Յուրաքանչյուր հեղինակ դրանք դիտարկում է իր տեսանկյունից։
Առաջարկում եմ դիտարկել հաճախորդի հետ աշխատելու հիմնական փուլերը>.
Փուլ 1 «Կապ հաստատելը» կամ «Կապ հաստատելը»
Ցանկացած վաճառք սկսվում է այս փուլից։
Այս փուլի նպատակըՀաղթել Հաճախորդին և հետաքրքրել նրան հետագա շփման մեջ:
Հաճախորդի հետ կապ հաստատելիս կարևոր է ողջունել նրան և ներկայանալ:
"Բարի օր. Ես Միխայիլն եմ, ես «Windows Plus» ընկերության մենեջերն եմ։
Հաճախորդի կարիքների մասին զրույց սկսելուց առաջ խորհուրդ է տրվում նրա հետ զրուցել վերացական թեմայով («Փոքր խոսակցություն» տեխնիկան), կամ առաջարկել թեյ, սուրճ, կարող եք հաճոյախոսություն անել կամ օգտագործել մի շարք այլ տեխնիկա։ կապ հաստատելու փուլում։
«Ի՞նչ գիտեք մեր ընկերության մասին: Ինչու՞ ընտրել մեզ: Ի՞նչ եք նախատեսում գնել:
Կարևոր է, որ մենեջերը իր ոչ խոսքային վարքագծով դրսևորի հաճախորդի հետ շփվելու հետաքրքրություն, նրան օգնելու ցանկություն, բարի կամք: Ոչ խոսքային վարքագիծը ներառում է բաց ժեստերը, կեցվածքը, ժպիտը, մարմնի թեքությունը դեպի Հաճախորդը, բաց հայացքը:
Հաճախորդի վարքագծով հնարավոր է որոշել՝ արդյոք կապ հաստատվել է Հաճախորդի հետ, թե ոչ: Եթե նա դրական է արձագանքում մենեջերի խոսքերին, իրեն հանգիստ է զգում, ինքն է հարցեր տալիս, կարելի է ենթադրել, որ կապ է հաստատվել։ Եթե Հաճախորդը չի պահպանում տեսողական կապը մենեջերի հետ, լարված է, չի պատասխանում հարցերին կամ պատասխանում է դժկամությամբ, ապա իմաստ ունի ավելի շատ ժամանակ հատկացնել կապի հաստատման փուլին:
Փուլ 2 «Կարիքների նույնականացում»
Այս փուլի նպատակը: որոշելու հաճախորդի կարիքները:
Որքան ավելի ճշգրիտ կառավարիչը որոշի Հաճախորդի կարիքները, այնքան ավելի արդյունավետ կերպով նա կներկայացնի ապրանքների և ծառայությունների ներկայացումը, ինչը հետագայում կհանգեցնի գործարքի:
Կարիքները բացահայտելիս կարևոր է, որ ղեկավարը կարողանա հարցեր տալ և լսել Հաճախորդին:
Հաճախորդի հետ շփվելիս կարևոր է, որ նա ավելի շատ խոսի, այլ ոչ թե մենեջերը, դրա համար մենեջերին խորհուրդ է տրվում ավելի շատ բան սահմանել. բաց հարցեր.
Ի՞նչ պատուհան եք նախատեսում գնել: Որտեղ եք փոխելու պատուհանը: Ինչպիսի՞ն է կլիման բնակարանում ձմռանը և ամռանը: Էլ ովքե՞ր են ապրում բնակարանում: Ինչի՞ հիման վրա եք ընտրում պատուհանը:
Փակ հարցերմենեջերը թույլ է տալիս հստակեցնել Հաճախորդի կարիքները:
«Հաճա՞խ եք օդափոխում սենյակը։ Դուք կենդանիներ ունե՞ք: Ձեզ հարմար է, եթե մեր չափիչը գա վաղը առավոտյան ժամը 9-ին»։
Այլընտրանքային հարցերհաճախորդին առաջարկել տարբերակների ընտրություն.
«Ձեզ համար հարմար է, որ չափիչը գա առավոտը, թե ցերեկը։ Մենք պլանավորում ենք նոր պատուհաններ տեղադրել այս շաբաթ, թե հաջորդ շաբաթ»:
Հաճախորդի հետ ամբողջ հանդիպման ընթացքում օգտակար է նրան ուշադիր լսել, քանի որ հաճախորդները հաճախ իրենք են բաց խոսում իրենց կարիքների մասին: Եթե Հաճախորդի որոշ խոսքեր պարզ չեն մենեջերին կամ նա լսել է դրանք, խորհուրդ է տրվում Հաճախորդին տալ պարզաբանող հարցեր.
«Ես ճի՞շտ հասկացա, որ ձեզ հարկավոր է բարձր ձայնամեկուսացումով պատուհան: Ինչքան հասկացա, դու ուզում ես, որ պատուհանի մի շղթան պտտվող լինի, մյուսը թեքվի»։
Յուրաքանչյուր քննարկված հարցից հետո ցանկալի է ամփոփել միջանկյալ արդյունքը։ Հատկապես, եթե մենեջերը Հաճախորդի հետ քննարկում է մի քանի ապրանքներ կամ ծառայություններ:
«Այսպիսով, մենք պայմանավորվեցինք, որ վաղը չափագրելու ենք, իսկ հաջորդ շաբաթ՝ ուրբաթ օրը, կտեղադրենք պատուհանները։ Այսպիսով, դուք նախատեսում եք տեղադրել երկու նոր պատուհան՝ խոհանոցում՝ երկթեղանի պատուհան՝ թեքվող թևերով, և սենյակում՝ եռաթև պատուհան, որի մեջ երկու թևերը թեքվում են և շրջվում։ մեկը «խուլ» է։
Կարևոր է ճշգրիտ բացահայտել հաճախորդի կարիքները և միայն դրանից հետո իրականացնել ապրանքների և ծառայությունների ներկայացում:
Փուլ 3 «Ներկայացում»
Թիրախ:առաջարկել ապրանք կամ ծառայություն, որը լավագույնս համապատասխանում է Հաճախորդի կարիքներին:
Ապրանքների և ծառայությունների ներկայացումը պարունակում է ապրանքների և ծառայությունների բնութագրերի նկարագրություն, հաճախորդի կողմից դրանց օգտագործումից օգուտները և սպառողին ստացած օգուտները:
Օգտակար է սկսել ներկայացումը Հաճախորդի հիմնական առավելություններից, որոնք բխում են գնորդի կարիքներից, որոնք բացահայտվել են մենեջերի կողմից նախորդ փուլում:
Կարևոր է տարբերակել, թե ինչպես է ապրանքի կամ ծառայության օգուտը տարբերվում օգուտից:
Առավելությունայն օգուտն է, որը ցանկացած Հաճախորդ ստանում է՝ օգտագործելով այս ապրանքը կամ ծառայությունը:
«Այս ծառայության միջոցով դուք կարող եք խնայել ժամանակը և կրճատել ծախսերը 10%-ով»: «Այս կցամասը թույլ է տալիս նվազեցնել ճշգրտումների քանակը»:
Օգուտհատկանիշ կամ առավելություն է, որը թույլ է տալիս բավարարել Հաճախորդի հատուկ կարիքը:
Այսպիսով, ցանկացած հատկանիշ կամ առավելություն կարող է դառնալ օգուտ, պայմանով, որ Հաճախորդը դրա կարիքն ունի:
«Դուք ուզում էիք, որ պատուհանը հեշտ բացվի և փակվի, դա կարող են ապահովել եվրոպական որակի կցամասերը»: «Ասացիք, որ բնակարանը գտնվում է առաջին հարկում և վախենում եք բնակարանի անվտանգության համար, առաջարկում եմ նոր պատուհանների վրա տեղադրել հակագողական կցամասեր»։
Ներկայացման ընթացքում մենեջերը պետք է Հաճախորդին ներառի ակտիվ երկխոսության մեջ՝ օգտագործելով հարցեր:
«Ինչպե՞ս եք վերաբերվում իմ առաջարկին», «Ի՞նչ եք մտածում այս մասին», «Ինչպե՞ս եք հավանում իմ առաջարկը»:
Փուլ 4 «Աշխատանք առարկությունների հետ»
Թիրախ:Փարատել գնման վերաբերյալ Հաճախորդի կասկածները և հեռացնել բացասականը ապրանքի կամ ծառայության հետ կապված:
Հաճախորդի առարկությունների թիվը նվազեցնելու համար մենեջերի համար օգտակար է ավելի շատ ժամանակ հատկացնել նախորդ փուլերին: Հաճախ Հաճախորդների առարկությունները կապված են այն բանի հետ, որ նրա հետ շփումը լավ չի հաստատվել, նրա կարիքները մասնակիորեն բացահայտվել են, կամ ապրանքների և ծառայությունների ներկայացումը հաճախորդին հետաքրքիր չէր, չափազանց երկար և չէր բավարարում նրա կարիքները:
Կարևոր է Հաճախորդի առարկությունները ընկալել որպես ազդանշան, որ ղեկավարը պետք է շտկի իր վարքը (հատկապես, եթե առարկությունները շատ են):
Հաճախորդի կողմից առարկություններ կարող են առաջանալ նաև վաճառքի նախորդ փուլերում: Ինչպե՞ս վարվել առաջացող առարկությունների հետ:
Արդյունավետորեն հետևեք առարկությունների մշակման սխեմային.
1. լսել Հաճախորդին;
2. չեզոքացնել նրա հույզերը՝ օգտագործելով հասկացող արտահայտություններ.
«Ես հասկանում եմ քեզ», «Այո, ես համաձայն եմ, որ դա տհաճ է ...»:
3. անհրաժեշտության դեպքում պարզաբանել տեղեկատվությունը` օգտագործելով հարցեր.
4. առաջարկել կառուցողական լուծումներ կամ կատարել այլընտրանքային առաջարկ։
Հաճախորդների առարկությունների 4 տեսակ կա.
1. փոփոխությունների հետ կապված առարկություններ.
«Ինչու՞ է ինձ դա պետք», «Ես դրա իմաստը չեմ տեսնում»
Նման առարկության հետ վարվելիս կառավարիչը պետք է Հաճախորդին բացատրի, որ ռիսկերը բացառված են, ցույց տա հետևանքները, եթե իրավիճակը շարունակվի, օրինակներ բերի ինչ-որ բան առաջին անգամ օգտագործելու դրական փորձի օրինակներ:
«Գնելով եվրոպական կցամասերով պատուհան՝ երաշխավորված եք պաշտպանված լինելու հոսքերից, պարկի ճնշման լրացուցիչ կարգավորումներից, փակման մեխանիզմի խցանումից»։
2. գնի հետ կապված առարկություններ.
«Ինձ համար չափազանց թանկ է».
Փաստարկների մեջ կառավարիչը պետք է ուշադրություն դարձնի այն լրացուցիչ օգուտին, որը ստանում է Հաճախորդը, դուք կարող եք համեմատել ապրանքի արժեքը ցանկացած այլ ոչ առանձնապես անհրաժեշտ իրի արժեքի հետ կամ բաժանել արժեքը որոշակի ժամանակահատվածի վրա:
«Մեր ընկերությունից պատուհան գնելիս դուք նվեր եք ստանում պատուհանի խնամքի հավաքածու, ինչպես նաև կցամասերի անվճար կարգավորումից օգտվելու հնարավորություն», «Խոհանոցում գեղեցիկ նոր պատուհանը ձեզ կարժենա ընդամենը 300 ռուբլի: մեկ օրում».
3. առարկություններ՝ կապված բացասական փորձի հետ։
«Ես լսել եմ, որ վատ պրոֆիլ ունես»։
Օգտակար է մենեջերի համար պարզաբանել տեղեկատվությունը Հաճախորդին հարցեր տալով, հաճախորդին ցույց տալ, որ դուք հասկանում եք նրան և ընդունում եք տհաճ իրադարձությունների փաստերը (եթե դրանք իրականում են եղել), ապա առաջարկել այլընտրանքային լուծում:
«Այո, իսկապես, մենք ունեինք թերի պրոֆիլի խմբաքանակ, որը վերադարձրինք մատակարարին: Այս պահին մենք ստացել ենք նոր խմբաքանակ, արդեն պատրաստել և տեղադրել ենք ավելի քան 30 պատուհան, բոլոր հաճախորդները գոհ են»։
4. որոշման հետ կապված առարկություններ.
«Ես պետք է մտածեմ», «Ես պետք է խորհրդակցեմ կնոջս հետ»:
Նման առարկությունների հետ վարվելիս կառավարիչը կարող է ևս մեկ անգամ պարզաբանել, թե ինչի հետ է կապված նման որոշումը, համոզվել, որ հաճախորդն ընդունել և հասկացել է ամբողջ տեղեկատվությունը, ինչպես նաև օգտագործել գործարքը ավարտելու մեթոդները:
«Եթե մենք հիմա պայմանագիր կնքենք ձեզ հետ, ապա շաբաթվա վերջում դուք կկարողանաք հիանալ խոհանոցի նոր պատուհանով»։ «Միայն մինչև ամսվա վերջ մենք ունենք զեղչ այս ապրանքի վրա»։
Փուլ 5 «Գործարքի ավարտը».
Թիրախ:Հաճախորդին մղել գործարքի և հաստատել նրա կողմից ընդունված որոշման ճիշտությունը:
Գործարքի ավարտից առաջ (պայմանագիր ստորագրելուց) կառավարիչը պետք է համոզվի, որ Հաճախորդը պատրաստ է գործարք կնքել:
Սա երևում է այն ազդանշաններից, որը ցույց է տալիս.
- դրական կարծիք ապրանքի կամ ծառայության մասին;
- Հաճախորդը հավանություն է հայտնում մենեջերի խոսքերին (համաձայնում է, գլխով անում և այլն);
- ուղղակիորեն ասում է, որ համաձայն է.
- պարզաբանող հարցեր է տալիս.
Գործարքի ավարտման մեթոդներ.
1. պայմանների և ժամանակի սահմանափակման մեթոդ.
«Եթե այսօր ստորագրեք պայմանագիրը, մենք ձեզ պատուհանի 20% զեղչ ենք տալիս»։
2. հաճոյախոսության մեթոդ.
«Դուք իսկապես ճիշտ ընտրություն եք կատարել»:
3. հաղթող-հաղթող այլընտրանք:
«Երեքշաբթի կամ չորեքշաբթի ձեզ կգրվե՞ն չափման համար»:
Եզրափակելով, ես կցանկանայի ասել, որ վաճառքի արդյունավետությունը կախված է մենեջերների հմտությունից: Որքան շատ մեթոդներ և վաճառքի տեխնիկա ունենա մենեջերը, այնքան ավելի ճկուն և հաջողակ է նա հաճախորդի հետ շփվելիս: Վաճառքի մենեջերի մասնագիտությունը պահանջում է հմտությունների մշտական զարգացում և ինքնազարգացում։ Մաղթում ենք Ձեզ հաջողություն մասնագիտական աճի և վաճառքի աճի ճանապարհին։
Գոյատևեն միայն սիրահարները
Երեխաներին ուղղված գովազդի առանձնահատկությունները
հին լուսանկարների ռետուշավորում photoshop-ում հին լուսանկարների ռետուշավորում
Ինչ է NPO. վերծանում, նպատակների սահմանում, գործունեության տեսակները Արդյո՞ք շահույթ չհետապնդող կազմակերպությունն իրավունք ունի.
Գլեբ Նիկիտինի առաջին տեղակալ