Համակարգիչներ

Quesրագրաշարի մշակման նախագիծ սկսելուց առաջ պատասխանելու 5 հարց

Հեղինակ: Laura McKinney
Ստեղծման Ամսաթիվը: 3 Ապրիլ 2021
Թարմացման Ամսաթիվը: 16 Մայիս 2024
Anonim
Quesրագրաշարի մշակման նախագիծ սկսելուց առաջ պատասխանելու 5 հարց - Համակարգիչներ
Quesրագրաշարի մշակման նախագիծ սկսելուց առաջ պատասխանելու 5 հարց - Համակարգիչներ

Բովանդակություն

Ես 25-ամյա պրոֆեսիոնալ տեխնոլոգիայի վետերան եմ, 20-ամյա պրոֆեսիոնալ վեց երեխաների հայր և 24-ամյա պրոֆեսիոնալ ամուսին:

Ձեր սեփական ծրագրային լուծումները «տնային պայմաններում զարգացնելու» բազմաթիվ պատճառներ կան: Կարծես թե տնային տնտեսությունների լուծումների ամենամեծ շարժիչ գործոնը հետևյալն է. Ձեր ընկերության `ծրագրային ապահովման պահանջները վերահսկելու, նախագծումը, իրականացումը, աջակցությունը և ծրագրային լուծման պահպանումը կարողությունը շատ համոզիչ առավելություն է տնային լուծումների համար: Ձեր բիզնեսի առաքելության կարևոր ասպեկտները մղող ծրագրակազմ ստեղծելու ժամանակ հսկողությունը կարևոր է:

Մենք բոլորս ուզում ենք վերահսկողություն իրականացնել, ինչու՞ ոչ միշտ օգտագործել տնային լուծույթ: Իրականում հարց չէ, թե ինչու, այլ ավելի շուտ ՝ երբ: Շատ դեպքերում ընկերությունները չեն հաշվի առնում տնային պայմաններում լուծույթի հետ կապված ամբողջ ծախսերը: Աշխատուժի գինը (ՏՏ և ոչ ՏՏ) և կորցրած հնարավորությունները կարող են արագորեն գերազանցել ծրագրային լուծման օգուտները: Ահա հինգ բան (բացի ուղղակի ծախսերից), որոնք դուք պետք է հաշվի առնեք նախքան «տնային տնտեսություն» ծրագրակազմի ներքին նախագիծը սկսելը:


1. Որքա՞ն վերահսկողություն է պետք ինձ:

Սա թերեւս ինքներդ ձեզ տալու ամենակարևոր հարցն է: Ինչպես նշվեց նախաբանում, ձեր ծրագրաշարի նկատմամբ վերահսկողությունը, երբ այն ձեր բիզնեսի «գաղտնի սոուսն» է, կարևոր է: Օրինակ, եթե ձեր ընկերությունը ծրագրային ապահովում է որպես ծառայություն (SaaS) մատակարար, ձեր սեփական ծրագրակազմը զրոյից կառուցելը ձեզ հաջողության ամենամեծ շանսն է տալիս, հատկապես այն ժամանակ, երբ փորձում եք ձեր հաճախորդներին ապահովել մրցունակ ապրանք և ծառայություն:

Այնուամենայնիվ, շատերն ասում են. «Քանի որ ես արդեն ունեմ ծրագրակազմ մշակողներ, ես կթողնեմ նրանց հասցնել իմ ծրագրային ապահովման բոլոր կարիքները»: Բայց իսկապես վերահսկողության կարիք ունե՞ք բոլորը ձեր ծրագրային կարիքները? Օրինակ ՝ Ձեզ հարկավո՞ր է վերահսկել ծրագրակազմի պահանջները և ձեր հաշվապահական ծրագրերի իրականացումը: Ընկերությունների մեծ մասը չի գնում, ուստի գնում են հաշվապահական փաթեթ: Դա պայմանավորված է նրանով, որ որպես SaaS մատակարար, հաշվապահական հաշվառման ծրագրակազմը ձեր հիմնական բիզնեսի մաս չէ: դա պարզապես ավելի հեշտ և ճշգրիտ է դարձնում ձեր հաշվապահական հաշվառումը, այնպես որ դուք կառուցում եք ձեր հաշվապահական պրակտիկան և գործընթացները ձեր ընտրած հաշվապահական ծրագրերի առանձնահատկությունների և գործառույթների շուրջ:


Ձեր ծրագրակազմի նկատմամբ վերահսկողությունը կարևոր է, բայց կիրառեք այն միայն այնտեղ, որտեղ դա ձեզ անհրաժեշտ է: Պատկերացրեք հաշվապահական հաշվառման ծրագրակազմի համար ծրագրաշարի մշակման նախագիծը կառավարելու փորձի գինը, երբ հաշվապահական ծրագրերի մատակարար չեք: Թույլ մի տվեք, որ ձեր ծրագրակազմի մշակման թիմի կարողությունները թելադրեն `վերահսկողության կարիք ունեք, թե ոչ: թող բիզնեսի պահանջը թելադրի անհրաժեշտությունը:

2. Արդյո՞ք մենք նորից ենք հորինում անիվը:

Softwareրագրակազմի ցանկացած նախագծի վերլուծության փուլում անհրաժեշտ է գնահատել երրորդ կողմի լուծումները `պարզելու, արդյոք արդեն գոյություն ունի մեկը, որը կարող է իրականացնել նախագծի նույն գործառույթը, որը դուք ցանկանում եք ստանձնել: Շատ դեպքերում, երրորդ կողմի ընտրանքներ գոյություն կունենան, և արժեքի, առանձնահատկությունների և գործառույթի գնահատումը պետք է օգնի պարզել, թե արդյո՞ք ավելի ծախսարդյունավետ է երրորդ կողմի լուծում գնելը:

Projectրագրի շատ ղեկավարներ զեղչում են այս քայլը կամ ընդհանրապես բաց թողնում այն: Քանի որ ծրագրային ապահովման մշակողների մեծ մասը սիրում է վերահսկել ծրագրային լուծումները, նրանք հաճախ փորձում են կառավարությանը զերծ պահել երրորդ կողմի ծրագրակազմից կամ բաղադրիչներից: Softwareրագրակազմի լավ մշակողները կուղեկցեն երրորդ կողմի լուծումները, եթե դա նշանակում է, որ նրանց լուծման որոշակի բաղադրիչ մշակելու և պահպանելու անհրաժեշտություն չկա (նույնիսկ եթե դա ներքին բաղադրիչ է):


Այնուամենայնիվ, դուք կտեսնեք, որ կան դեպքեր և հանգամանքներ, որոնք պահանջում են «նորից հորինել» ձեր իսկ լուծման մեջ: Յուրաքանչյուր ընկերություն ունի եզակի «շտկումներ» և գործընթացների նախապատվություններ, որտեղ ղեկավարությունը չի ցանկանում փոխզիջման գնալ, և, հետևաբար, պետք է տեղավորվի իրենց ծրագրային լուծումներում:

3. Որքա՞ն ժամանակ է համապատասխանելու իմ ծրագրային լուծումը:

Ձեր ծրագրային լուծումները համապատասխան պահելը շատ դժվար խնդիր է:Շատ դեպքերում, ծրագրային ապահովման մշակման ծրագրի ավարտից հետո, մշակողները շարժվում են առաջ և լուծում են միայն կարևորագույն խնդիրները և սխալները, երբ դրանք հաղորդվում են: Ենթադրությունը, որ ծրագրակազմը պետք է գործի այնպես, ինչպես սպասվում էր, եթե սխալներ չեն հաղորդվել, սխալ է: Վերջնական օգտագործողները հաճախ փոխում են իրենց վարքագիծը `համակարգի թերություններն ու թերությունները փոխհատուցելու համար: Սա հայտնի է որպես «լուծում», և ծրագրակազմը համարվում է «լավ» աշխատող, քանի որ ոչ մի թերություն չի հաղորդվում:

«Փոփոխությունները» հակված են գործընթացին անարդյունավետություն և ծախսեր ներմուծելուն, և ժամանակի ընթացքում ամեն ինչ սկսում է գումարվել, մինչև այդ ծախսերը էապես ջնջեն ծրագրաշարի առավելությունները: Timeամանակն անցնում է, և ծրագրային լուծման մասին գիտելիքները կորչում են, սովորաբար ներդրվում են «նվագախմբային օժանդակ միջոցներ» և «արագ շտկումներ» ՝ տեխնոլոգիան ներկայումս զարգացող գործընթացներով պահելու համար, բայց նրանք նույնպես կարող են սկսել բուն ծրագրակազմի նախագիծը վերածել մի քանի համագումարի: ավելի փոքր նախագծեր, որոնք ամրացված են բնօրինակին:

Անառարկելիությունից խուսափելու համար գնահատեք, թե որքանով է լուծումը կօգտագործվի, որոշեք վերանայումների և թարմացման ժամկետները և հաճախակի խոսեք վերջնական օգտագործողների հետ ՝ տեսնելու, թե արդյոք հասե՞լ եք լուծման, որն աշխատում է ոչ թե նրանց դեմ, այլ նրանց հետ: Միշտ հիշեք, որ ծրագրակազմի մշակման նախագիծը ժամանակին և բյուջեով ավարտելու պատճառով չի նշանակում, որ այն հաջող էր:

4. Սա՞ է մեր ռեսուրսների լավագույն օգտագործումը:

Ի՞նչ ռեսուրսների մասին է խոսքը: Փող

Այն ամենը, ինչ դուք օգտագործում եք ձեր արտադրանքը կամ ծառայությունը ստեղծելու համար, կարող է (կամ պետք է) չափվի փողով: Սա կներառի ձեր ողջ ունեցվածքը, սարքավորումները, ժամանակը և, որքան էլ դա անխիղճ հնչի, ձեր մարդիկ:

Հատկապես խոսելով ձեր ծրագրակազմի մշակման թիմի մասին ՝ ձեր գումարի լավագույն օգտագործո՞ւմն է, որ նրանք այլևս գոյություն ունեն ունենան այլ ծրագրեր, որոնք կարող են անտեղի դառնալ մի քանի տարի անց: Ակնհայտ է, որ այս հարցը բեռնված է և չի հաշվի առնում ամբողջ տեղեկատվությունը, երբ որոշում կայացնի, թե ինչպես ծախսել ձեր զարգացման դոլարները:

Բաց թողած հնարավորություններից խուսափելու համար միշտ պետք է հաշվի առնել, թե ձեր զարգացման դոլարներն ուրիշ ինչի վրա կարող են ծախսվել: Կարո՞ղ են ձեր մշակողները աշխատել հիմնական արտադրանքի և ծառայությունների ամրապնդման ուղղությամբ:

5. Արդյո՞ք հիբրիդային լուծումը ճիշտ ճանապարհ է:

Հավանականությունը, որ գոյություն ունի կատարյալ երրորդ կողմի ծրագիր, որը համապատասխանում է ձեր բոլոր կարիքներին, բավականին փոքր է: Ընկերությունները, որոնք պատշաճ կերպով ղեկավարում են իրենց ծրագրակազմի մշակումը և գնահատում երրորդ կողմի ծրագրային ապահովման մատակարարներին, սովորաբար ընկնում են երրորդ կողմի ծրագրակազմի օգտագործման հիբրիդային մոդելի `իրենց սեփական ծրագրային ապահովման զարգացման նախագծերը բարելավելու համար:

Երրորդ կողմի լուծում գտնելը և գիտակցելը, որ այն իրականում կարող է ձեզ ժամանակ և գումար խնայել, ծրագրային ապահովման զարգացման ծախսերը վերահսկելու համար կարևոր նշանակություն ունի: Հաշվի առեք սա.

Ձեր ծրագրակազմը մշակողները ձեզ ասում են, որ նրանցից կպահանջվի մոտ 500 ժամ JavaScript- ի տվյալների կայուն ցանց ստեղծելու համար: Մշակողների ծախսերը գնահատելով և մնացած բոլոր ռեսուրսների համար 15% ավելացնելով (ծրագրի կառավարում, փորձարկում և այլն) կարող եք ծախսել $ 35,000:
Երրորդ կողմի լուծում փնտրելը կարող է արժենալ միայն $ 1,500 մեկ վեբ սերվերի համար: Դա ավելի քան 20 սերվերի լիցենզիա է ՝ նույն արժեքով, ինչ ձեր սեփականը մշակելը:

Ձեր ծրագրավորողն այժմ ունի լրացուցիչ 500 ժամ ծախսելու համար ՝ ապահովելու համար, որ իր կողմից աշխատող համակարգը պատշաճ կերպով մշակվի և ներդրվի ՝ առանց տնային պայմաններում գործող JavaScript տվյալների ցանց գրելու, իրականացնելու և պահպանելու լրացուցիչ ջանքերի:

Այլ կերպ ասած, դուք պարզապես խնայել եք 500 ժամ ծախս, որը կարող է իրացվել որպես խնայողություն կամ տեղափոխվել այլ նախագծեր

Եզրակացություն

Եկավարությունը պատասխանատվություն և պարտականություն ունի սահմանելու ուղղություններ և նախապատվություններ իրենց ծրագրային ապահովման մշակման թիմերի համար: Ձեր ուշադրությունը կենտրոնացնելով վերջնական արդյունքի վրա `միաժամանակ հավասարակշռելով ձեր ծրագրաշարի վերահսկման գործոնները, ռեսուրսների լավագույն օգտագործումը և ձեր ծրագրաշարի վավերությունը, խտացված ջանքեր է պահանջում: Երրորդ կողմի ծրագրաշարը ներգրավելը կարող է և հաճախ դա է ՝ ձեր նպատակներին հասնելու լավագույն միջոցը:

Այս հոդվածը ճշգրիտ է և համապատասխանում է հեղինակի լավագույն գիտելիքներին: Բովանդակությունը նախատեսված է միայն տեղեկատվական կամ ժամանցային նպատակներով և չի փոխարինում անձնական խորհրդատվությանը կամ մասնագիտական ​​խորհրդատվությանը բիզնեսի, ֆինանսական, իրավական կամ տեխնիկական հարցերում:

Պորտալի Հոդվածներ

Առաջարկվում Է

Մալուխի նույնականացման ուղեցույց. Ո՞րն է որն:
Misc

Մալուխի նույնականացման ուղեցույց. Ո՞րն է որն:

Էշլի Դոյլը Կանադայից է և հաճախ է հոդվածներ գրում համակարգիչների և տեխնոլոգիաների մասին:Մալուխների հետ աշխատելիս պարզել, թե յուրաքանչյուրն ինչ է անում, միշտ չէ, որ պարզ է, և իմանալը, թե ինչ է անհրաժեշտ...
Ինչպես նախագծել ձեր սեփական DIY ենթավուֆերը
Համակարգիչներ

Ինչպես նախագծել ձեր սեփական DIY ենթավուֆերը

Տարիներ շարունակ տնային կինոյի սիրահար եմ եղել և միշտ փնտրում եմ հաջորդ նորացման կամ DIY նախագիծը:Այս հոդվածը վերաբերում է այն բանին, թե ինչպես կառուցել ձեր սեփական DIY սուբվուֆերը: Երբ ես առաջին անգա...