Jamoa samaradorligini qanday o'lchash mumkin?

Kompaniyamizning yuqori menejmenti kelgusi yilda dasturiy guruhimiz uchun "15% ko'proq samarali" bo'lish maqsadini qo'ydi. Dasturiy ta'minotni ishlab chiqish muhitida samaradorlikni o'lchash juda subyektivdir, ammo biz hali ham bir qator o'lchovlar bilan ishlashimiz kerak.

Jamoamizning mahsuldorligini o'lchash uchun qanday ma'lumot to'plashimiz mumkin?

9
Martin Fowler bu haqda yaxshi maqola yozgan . Agar u bu erga joylashtirsa, men uni ovoz bilan o'qiyman :-)
qo'shib qo'ydi muallif David Espart, manba
Ishlab chiquvchilar har kuni to'planayotganini da'vo qilishlari mumkin va ular "nol istisno" ni belgilashadi yoki deyarli deyarli bajarilmoqda, faqat bitta tuzatish kerak. To'liq nima uchun ayon emas, lekin agar so'ralsa, Devs Sizga deyarli 0% imkoniyatga ega bo'lgan eng ijobiy rasmni bo'yashadi. Biz o'lchovlarni taqdim qilmagunimizcha loyihalarimiz deyarli har safar pasayib ketdi. Ish beruvchi nimani aniqlay olsa, ishlab chiquvchi nimani aniqlay oladi? Ko'pincha Devlar texnologiya jargonidan foydalanadi, chunki PMlar faqat e'tiborsizlik qiladilar.
qo'shib qo'ydi muallif devinmoore, manba
Loyihani ishlab chiquvchi sifatida yoshligimda har qanday o'lchovlarga qarshi turardim, chunki men qora san'at kabi ishlarni bajarishni istardim, shuning uchun loyiha/topshiriq paytida "kompilyatsiya" Vaqt orqasida edi. Bu masaladagi eng ko'p javoblarni o'qing. Asosan har qanday o'lchovlarga qarshi bahona topishga harakat qilmoqdalar, chunki o'lchovlar odatda Dev-ni javobgar qiladilar. Siz foydalanishingiz mumkin bo'lgan aniq o'lchovlar bor, lekin aniq ilmiy emas. Jamoa, loyihalar va hokazolarga ko'ra farq qilishi mumkin.
qo'shib qo'ydi muallif devinmoore, manba
Ha, bizda retrospektiv va ishchi taxtalar mavjud. Lekin nima sodir bo'lgan: - Ishbilarmon: "Shunday qilib, Butrus qanday qilib boradi?" -Peter (Tuzuvchi): "Bu kompilyatsiya qilinadi ..." -Biznes: "Har bir narsaga o'xshab ketadigan narsa bor, faqat 2 haftadan beri bu loyihani sindirib tashlamasligingizga ishonch hosil qiling".
qo'shib qo'ydi muallif devinmoore, manba
2006 yil iyul oyidan buyon kunlardagi o'lchovlarni o'tkazing. Kelgusi yilda 15% ga ko'payishi kerak va siz boshqa har qanday boshqa usulda foydalanishingiz mumkin.
qo'shib qo'ydi muallif fluffels, manba
@ Mag20: tengdosh tomonidan tasdiqlash. Bu kundalik kutish va ierarxiya tekshiruvining nuqtasi. Agar sizning butun jamoangiz gavdalantirsa, siz baribir vidolashibsiz. Boshqa kompaniyani ishga tushiring va keyingi safar ijaraga oling. Lekin, agar bitta ishlab chiquvchi qattiq ishchi bo'lsa va qolganlari bo'lmasa, u holda oxir-oqibat savollar berishni boshlaydi. (Ko'proq ehtimol, sizlar faqat bir nafasshunosga ega bo'lasizlar.)
qo'shib qo'ydi muallif fluffels, manba
@ Mag20: Shuning uchun biz bu narsalarni muntazam ravishda amalga oshirmoqdamiz va faqat vaqtni suratga olayotmaymiz ("kechagi/o'tgan haftada nima bo'lgan" va "hozir nimalar sodir bo'layapti?"). har kuni. Keyin, agar loyiha pasayib ketgan bo'lsa, sabablar orqaga qarab ketishi va aniqlanishi kerak. Agar ular aniqlanmasa, bir xil kechikishlarni takrorlashni kutasiz. (Agar biznes bu qarorni qabul qilsa). Agar ular keyinchalik ishlab chiquvchi har safar boshqa sababga ega bo'lishlari kerak bo'lsa. (Ular qaysi yo'l bilan ishlatilishi mumkin, ammo bu to'g'ri emas, balki bekor qilinmaydi.)
qo'shib qo'ydi muallif fluffels, manba
@ Mag20: Mening javobimda ta'kidlanganidek, ko'rinishlilik, albatta, harakat qilish kerak bo'lgan narsa, lekin raqamlar bilan o'lchanmaydi, bu standuplar va retrospektivlar va ishchi taxtalar yordamida amalga oshiriladi. Agar ishlab chiquvchilar biror narsani yashirishsa yoki yomonlashsa, ishlab chiquvchilar qattiq ishlaydilar va menejerlar nimadir yashirayotganlarini bilsalar, ko'rinishi yaxshilanishi kerak.
qo'shib qo'ydi muallif fluffels, manba
Agar menejment uni o'lchash uchun hech qanday usul bo'lmasa, uni 15% ga oshirish kerakligini yoki uni amalga oshirish mumkinligini bilishlarini qanday bilish mumkin?
qo'shib qo'ydi muallif Mr Rogers, manba
Ko'proq dasturiy ta'minot.
qo'shib qo'ydi muallif bstpierre, manba
Iterative Refactoring Factor hisoblash uchun jami LOC qo'shilgan yoki olib tashlangan.
qo'shib qo'ydi muallif bstpierre, manba
Faqat LOC-dan foydalaning, siz soxta narsalarni osonlashtiradigan narsadir.
qo'shib qo'ydi muallif thorsten müller, manba
Ular, aslida, ko'proq ishlay olishingizni xohlaydilar
qo'shib qo'ydi muallif ozz, manba
@JeffO lolz! ...
qo'shib qo'ydi muallif ozz, manba
Agar sizning jamoangiz ushbu talabga muvofiq olovga tutilgan bo'lsa, siz ko'rasiz, eng katta metrik - tark etiladigan muhandislarning soni
qo'shib qo'ydi muallif Jimmy Hoffa, manba
@pdr - bu yaxshi emas - ular daromadi pasayishidan aziyat chekadi: 2013 yilda 16,65%, 2014 yilda 14,27% va 2017 yilda 10% dan kam.
qo'shib qo'ydi muallif Matthew Flynn, manba
Men jiddiy xatoga yo'l qo'ymasam, bunday narsani aniq belgilash uchun (uhmm) "yuqori boshqaruv" vazifasi va vazifasi. Ular jahannamdan ko'proq pul olishadi, va men qayg'urgani uchun bu pul uchun biror narsa qilishlari kerak. Bu, aslida kutilgan narsalarga qarashni o'z ichiga oladi.
qo'shib qo'ydi muallif user43030, manba
Ishlab chiquvchilarning 15 foizi va qolganlari bir xil ishni bajarishini kutadilar. Agar qolganlar bir xil ishni qila olmasalar, yana olov yoqinglar. Ertami-kechmi, albatta, siz juda samarali bo'lganlarga tushasiz. (sarcasm-nogironlarga e'tibor bering: bu "sarqasm" deb nomlanadi)
qo'shib qo'ydi muallif parsifal, manba

6 javoblar

Ushbu saytda noto'g'ri javob yozmaslik uchun juda ko'p harakat qilaman, lekin bunga men ishonaman. Bu to'g'ri javob. Lekin men sizga yordam berishga harakat qilaman, lekin siz "qotib qololmaysiz".

Barcha jiddiylikda ishlab chiquvchilarning ishlab chiqarish samaradorligi aniq emas. Men buni menejerlar bilan kurashish qiyinligini bilaman, lekin bu haqiqat. Ushbu sohada juda tajribali kishilarning bir nechta havolalariga murojaat qiling. Bir necha misol uchun:

Martin Fowler

Shunday qilib, o'lchash uchun biznesning ahamiyati yo'q, ayni paytda ham vaqt bor. Ehtimol, ular qurgan dasturiy ta'minot chiqarilganidan keyin bir necha yilgacha jamoaning hosildorligini o'lchay olmaysiz.

     

Nima uchun unumdorligini o'lchash juda jozibador ekanligini ko'rishim mumkin. Agar biz buni qila olsak, dasturni hozirdan ko'ra osonroq va ob'ektiv baholash mumkin. Lekin soxta chora-tadbirlar faqat ishlarni yanada yomonlashtiradi. Bu bizning bilmasligimizni tan olishimiz kerak, deb o'ylayman.

Joel Spolsky

Qadimgi eski mahsuldorlik bilan boshlaylik. Dasturchilarning mahsuldorligini o'lchash juda qiyin; deyarli barcha metrikalar (disk raskadrovka kodlari, funktsiya nuqtalari, buyruqlar qatori argumentlari) o'yin uchun ahamiyatga ega emas va katta loyihalar bo'yicha aniq ma'lumotlarni olish juda qiyin, chunki u juda ko'p



Ikki dasturchi uchun ham xuddi shu ishni bajarish kerakligi aytilgan

Shuningdek, bu o'sish uchun mas'ul bo'lganlarni so'rang. chora-tadbirlarni olish uchun ruxsat berilgan ?

Menejerlar bu maqsadlarni qo'yganimdan kelib chiqib, chunki ular rivojlanish guruhlariga nisbatan qanday maqsadlarni belgilashni nolga tenglashtiradi. Ehtimol, siz ularga yordam berishingiz mumkin.

Sizga (yoki jamoaga) sizning maqsadlaringizni jiddiy qabul qilmoqchi ekaningizni tushuntiring, lekin ular SMART bo'lishi kerak yoki ular " ma'nosizdir. Ularga SMART bo'lgan ayrim maqsadlarni taklif qiling. Sizda qurish/CI-server bormi? Agar bunday bo'lmasa, SMART-gol. Agar shunday bo'lsa, sizda sifat statistikasini namoyish qilishning ba'zi usullari mavjudmi? Aks holda, bu SMART maqsad hamdir.

Agar shunday bo'lsa, u holda sizda juda aniq o'lchovli narsa bor: kod sifati. Ehtimol, texnik qarzdorlik darajangizni pastga tushirish sizning SMART maqsadingizdir, bu esa o'z navbatida, odamlarning ishdan bo'shatilganligini tasavvur qilmaguncha, hosildorlikni oshiradi.

Ularga sizga erishish mumkin bo'lgan maqsadlarni berishga yordam bering. Bir yildan buyon tasdiqlanmagan yoki tasdiqlanmagan maqsadlarga erishishdan qoniqish yo'q, yoki siz uni takomillashtirmasdan emas, balki vaqt o'yin tizimini isrof qilasiz.

28
qo'shib qo'ydi
Javob: o'lchov bilan chiqish emas.
qo'shib qo'ydi muallif bstpierre, manba
qo'shib qo'ydi muallif kennytm, manba
texnik qarzdorlik reytingingizni pastga tushirish SMART maqsad +1
qo'shib qo'ydi muallif Econ, manba

Mening eng samarali kunlarimdan biri 1000 kodli kodni tashladi.

 - Ken Thompson, original Unix operatsion tizimining dizaynerlari
 
-ni tanlang

Dasturiy mahsuldorlikni o'lchash juda qiyin, garchi u biroz befoyda bo'lsa ham. Dasturchilaringizdan so'rang va ularning ish vaqtining foizining noaniq chiqadigan vazifalarga va ularning nima ekanligini so'rang. Ular shaxsiy mahsuldorlik masalalariga emas, balki ishlab chiqarishga ajratilgan ish topshiriqlariga e'tibor qaratishlari kerak. Ba'zi bir misollar:

  • Sekinlashtirilgan manba nazoratini yangilashni kutish
  • Talablar o'zgarishi
  • Juda ko'p uzilishlar
  • Kompilyatorlar juda sekin
  • Regression testini amalga oshirish
  • Marketing sizni muhim ishlarni amalga oshirgandan keyin loyihalarni bekor qiladi
  • Vaziyat yangilanishlarini bajarish uchun ko'p vaqt sarflash
  • kutilmagan xatoliklar haqida juda ko'p vaqt sarflash yoki QA yoki maydondan xabar berilgan
  • Boshqa jamoalardan qaramliklarni kutish
  • Spagetti kodini ochish

Biroq, kuzatuvchi effekti tufayli, ushbu so'rov natijalarini har qanday mukofot yoki natijaga bog'lash mumkin emas dasturchilarga, shu jumladan menejmentni samaradorlik 15 foizga oshmaganiga g'azablantiradigan dastur. Ular shubhali bo'lsa-da, bu tizimni ishlatadi, bu raqamlar qanday ishlatilganligi va siz butunlay foydasiz metrika bilan yakunlanasiz.

nima qila olsangiz samaradorligini to'g'ri yo'nalishda harakat qilish uchun javoblardan foydalaning. Eng yomoni ikki yoki uchni tanlang va unga juda ko'p kuch sarflang. Yaxshilash ko'plab shaxsiy shikoyatlar uchun son jihatidan osonlik bilan o'lchanishi mumkin va umid qilamanki, kelgusi yilgi so'rovni qayta ko'rib chiqsangiz, shikoyatlarning ba'zilari endi ro'yxatga olinmaydi yoki hech bo'lmaganda sizning dasturchilaringiz kamroq hisobot berishi mumkin.

Boshqacha qilib aytganda, harakatni to'g'ri yo'nalishda kuzatishingiz mumkin, hatto siz buni aniqlay olmaysiz.

12
qo'shib qo'ydi
Agar siz kodning salbiy kodlari haqida latifaga havola berishni istasangiz - folklore.org/ StoryView.py?story=Negative_2000_Lines_Of_Code.‌ txt
qo'shib qo'ydi muallif user40980, manba

FogBugz kabi yaxshi vaziyatlarni boshqarish dasturidan foydalansangiz va eski ma'lumotlardan foydalansangiz, buni qilish qiyin, lekin mumkin. Shubhasiz, biz ishlashni 15 foizga teng aniq raqam bilan yaxshilashni ayta olmaymiz, ammo bu haqda albatta biror narsa qilishingiz mumkin. Keling, aytaylik:

5 ta ishlab chiquvchi

1 oylik ishlab chiqarish davri

Ular ozod qilishdan ozod bo'lishga juda mos kelishlari kerak, aks holda ular buzilishi mumkin. Siz o'lchaydigan va yaxshilashingiz mumkin bo'lgan ba'zi narsalar.

- Real dev vaqtiga nisbatan hisob-kitoblar .

Tez oqim tezligiga o'xshash. Agar ishlab chiquvchilar butun oy davomida ishlashni rejalashtirmoqchi bo'lsalar, bu oyda 5 dona uchun 20 kun yoki 100 kun aytaylik. Ular o'zlarining barcha vazifalarini baholadilar va rahbariyatga barcha xususiyatlarga mos kelishi mumkinligini aytishdi. Biroq, aslida 100 kun o'rniga 120 kun turdi.

20 kun (5 dona uchun qo'shimcha 4 kun), ko'plab bosim ostida va spaghetti kodini ko'p yozgan dasturchilar.

Shunday qilib, kelgusi oy uchun prognozlarni oshirish - 20% ga oshirib, haqiqiy vaqtga qanchalik yaqin bo'lishini ko'rish uchun. Agar siz hali ham o'chirilgan bo'lsa, uni keyingi versiyalar uchun yangilang. Ishlashni takomillashtirish 20 foizni tashkil qilmaydi, lekin juda muhim bo'lishi kerak, chunki juda kam stress, buglar va ishlaydigan dam olish kunlari bo'ladi.

- ishlab chiquvchilar tomonidan QA tomonidan topilgan xatoliklarni tuzatish uchun sarflangan vaqtning miqdori

Keling, ushbu versiya uchun QAga test qilish uchun 5 kishi/kun kerak bo'ldi.

Siz kamroq xatoliklar bilan ushbu raqamni yaxshilashga urinib ko'rishingiz mumkin:

  1. Gigantdagi avtomatlashtirilgan sinovni joriy qilish
  2. Qo`zni qabul qilgunga qadar reabilitatsiya qilish va optimallashtirish uchun vaqtni ajratib turing.
  3. Kod sharhlari

Xatoliklarni tuzatish vaqtini har bir qo'yib turing va yuqoridagi narsalarni taklif qilsangiz yaxshilanishlarni ko'rishingiz kerak.

-- Do some research on bottlenecks to development

Biznes tomoni va ishlab chiquvchilar orasida ishlash kabi salbiy ta'sirga ega bo'lgan boshqa narsalar ham bor. Ko'p marotaba, loyihaning aniqligi aniqlanmaganligi sababli, sekinlashuv yoki xususiyat talablari tufayli kechiktirilishi mumkin. Bu odatda qayta-qayta sodir bo'ladi.

Bu o'lchash uchun biroz qiyin, lekin undan foydalanish uchun o'lchovlardan foydalanishingiz mumkin. Buning uchun.

-- Type Faster...

Daq. So'zlar nafaqat ishlab chiquvchilar uchun, balki kompyuterdan foydalanadigan har qanday kishining ishlashini o'lchashning tasdiqlangan usuli hisoblanadi.

-- Measuring dev performance ain't easy

Boshqa odamlar allaqachon aytib o'tganidek, bu oson ish emas, shuning uchun uni "yuqori boshqaruv" ga qanday qilib bog'lashingiz juda muhimdir. O'lchovni rivojlantirish mahsulotni o'lchash kabi emasligini tushunishlari kerak. Qattiq raqamlar mavjud emas, lekin sizda yaxshilanishingiz mumkin bo'lgan ba'zi narsalar mavjud. Shunday qilib, ba'zi yaxshilanishlarni rejalashtirib, 1-bosqich va 2-bosqichda choralarni qo'llashingiz mumkin.

2
qo'shib qo'ydi
O'ylaymanki, mening keyingi sharhimiz bilan biz, ehtimol, davra suhbatlarini boshlaymiz. Kelishmaylik bilan rozi bo'laylik. Ushbu o'lchovlar kompaniyam uchun ishlagan, shuning uchun tajribangiz boshqacha bo'lishi mumkin. Yaxshi suhbatlar uchun rahmat.
qo'shib qo'ydi muallif devinmoore, manba
Muammolarning soni emas, balki muammolarni aniqlashga sarf qilingan vaqt. Sizda 10 ta xato 1 soatdan beri bir xil miqdorda bo'lishi mumkin. Vaqt soni kamroq bo'lsa - kod sifati yaxshiroq, shuning uchun unumdorlik yaxshiroq. Hisob-kitoblarga kelsak, ha, hech narsa o'ylanmaydi. Lekin men ishlab chiquvchilar, aslida ular bilan yaxshi ish qilishga intilishadi, deb hisoblayman, chunki yaxshiroq hisob-kitoblarni berish gigant va biznes uchun yaxshi. Bog'dagi odam, muddati fonetik bo'lsa, u samaradorlikni oshirmaydi. Shunday qilib, sizning a) aslida yuqoridagi b) sabab bo'ladi.
qo'shib qo'ydi muallif devinmoore, manba
Nima uchun men past ovozda ovoz beraman. Mening birinchi taklifim aslida shunga o'xshash/takroriy savolga javobdir: Bog'lanish
qo'shib qo'ydi muallif devinmoore, manba
Bashoratning aniqligi hosildorlik bilan bevosita bog'liq. Ikkinchidan, mukammallik bilan hech qanday aloqasi yo'q, lekin kodeksni takomillashtirish bilan bevosita bog'liq QA vaqtini kamaytirish uchun yaxshilash. Uchinchisi - haqiqiy, bir oz qiyin yordam qilishga harakat qildi. To'rtinchisi "Tezroq yozing ..." bu erda hazil-kattakon odam edi.
qo'shib qo'ydi muallif devinmoore, manba
@ Mag20: Boshqa javobga kelsak, u aslida buni amalga oshirish mumkin emasligini aytadi va u buni eng yaqin deb hisoblaydi. Siz buni qiyin, lekin imkoni borligini aytgansiz, bu juda boshqacha va'da. Men Martin Fowlerga yana bir marta baho beraman: noto'g'ri chora-tadbirlar faqat yomonlashadi. Ya'ni, men uning javobini puchga chiqmadim. Menimcha bu noto'g'ri. Men seni kamsitmadim, garchi menimcha, bu yanglishmasa kerak.
qo'shib qo'ydi muallif fluffels, manba
@ Mag20: Ko'pgina xatolar juda qisqa vaqt ichida o'rnatilishi mumkin. Boshqa tomondan, ularni topish, kunlar talab qilishi mumkin. Va bu kod sifati bilan juda oz narsa, yoki mahsuldorlik o'lchovidir, biroq bu samaradorlik omili. Men mukammal kodga ega bo'lishim mumkin va hech qachon hech qanday funksionallikni taqdim etolmayman, shuning uchun hech qachon hech qanday xatolarni keltira olmayman - zaryadlashni nolga o'tkazganim uchun g'olib chiqaman!
qo'shib qo'ydi muallif fluffels, manba
@ Mag20: Siz ishlab chiquvchilarni QA guruhiga tushgan muammolar soni bo'yicha o'lchaysiz, ular mukammallikka erishish uchun va shunday qilib samaradorlikni pasaytirishga qanday harakat qilyapsiz? Va sizning bog'langan javobingiz a) bu samaradorlikning o'lchovi emasligini va b) qanday qilib osonlik bilan o'ynashini (va shu sababli qanchalik foydasiz ekanligini) aniqroq tushuntiradi.
qo'shib qo'ydi muallif fluffels, manba
Dastlabki baholashni aniqligi. Ikkinchi baholash sifati va mukammallikni yetarlicha yaxshi dushman bo'lishga da'vat etadi. Uchinchisi - yaxshi amaliyot, lekin o'lchovli metrika emas; u ishlashni qanday qilib yaxshilashni so'ramadi, u qanday o'lchashni so'radi. Va tezroq yozib olish kotarchilar uchun yaxshi va yaxshi bo'ladi, lekin bizning tarmoqli kengligimizning ko'pchiligi o'ylamasdan va muloqot qiladilar, yozmaydi.
qo'shib qo'ydi muallif fluffels, manba
tezroq yozing bu barcha yozma kod tengdir. Qobiliyat darajasi, bir xil narsalarni qilishning turli xil usullari, turli dizayn naqshlari haqida va kodni o'chirishni hisobga oladimi?
qo'shib qo'ydi muallif ozz, manba

Menimcha, programmatchilar uchun faqatgina 1 metrik bor - bu boshqa kompaniyaga o'xshash ishlarni bajarish uchun ketadigan ishlab chiquvchilar soni.

Agar biror dasturchi boshqa joyda ishlash uchun etarli darajada baxtsiz bo'lsa, boshqa dasturchilar ham baxtsiz va yomon ishlashi mumkin.

2
qo'shib qo'ydi
bu jamoa samaradorligi bilan qanday bog'liq?
qo'shib qo'ydi muallif gnat, manba
Jamoa samaradorligiga ta'sir qilmaydigan "juda ko'p boshqa dasturchilar ham baxtsiz va yomon ishlash" haqida biror narsa bormi?
qo'shib qo'ydi muallif Brendan, manba

Men pdrning javobiga roziman. Bu boradigan yo'l. Ammo, yana bir narsa.

Ko'pgina jarayonni takomillashtirishga qaratilgan sa'y-harakatlar, sizningcha, hozirgi amaliyotlarni qanday o'lchash va keyinchalik asoslashga qaror qilish bilan boshlanishi kerak.

Dastlabki ma'lumotlardan qanday foydalanish kerak?

How about Joel's twelve questions?

Agar siz hali 11 yoki 12-ni qilmagan bo'lsangiz, unda yana 2 ta ishni qilishingiz kerak, va siz 15% yaxshilanishingizni olasiz.

1
qo'shib qo'ydi

Ba'zilar taklif qilganidek, dasturchilar uchun o'lchovlarga e'tibor berishning o'rniga, juda noaniq bo'lsa, quyidagi kabi kod bo'lmagan narsalarni taklif qilishni harakat qilib ko'ring:

  • XGb xotirasi har bir kompyuter uchun (u erda sizda x ortiq) va to'rt yadroli
  • Hamma uchun ikkita monitor (3 ga ega bo'lsangiz 3)
  • Menejerlar, qo'llab-quvvatlashlar, sotuvlar kabi har doim telefonda ishlaydigan yuqori darajali xodimlardan uzoqroq turadi.
  • yaxshiroq xususiyatlar
  • Bir nechta loyihalar orasidagi farqni o'zgartirishi tufayli kam kontekstli almashinuv.
  • Yig'ilishlarga taklif qilinadigan xodimlar uchun kam uchrashuvlar va e'tiborni yaxshiroq ko'rib chiqish/muhokama qilish

Nima uchun bularning har biri aslida dasturchini yanada samaraliroq qilishini batafsil tushuntirib bering.

Bu dasturchilarning mahsuldorligini oshirishga qodir bo'lgan narsalar turlari, LOC atrofida ba'zi noxush maqsadlarni belgilashga harakat qilmaslik yoki bug hisoblash.

1
qo'shib qo'ydi
Agar siz 15% ga ko'proq mahsuldorlikni oshiradigan narsalaringizni oshirsangiz, u holda unumdorlik 15% ga oshishi kerak. Bu oddiy matematik.
qo'shib qo'ydi muallif bstpierre, manba
OK, men biroz javob berishga harakat qildim :)
qo'shib qo'ydi muallif ozz, manba
Buni hech qachon ko'rmayapman. Ehtimol, "talab" - noto'g'ri so'z, lekin bu hosildorlikka yordam beradigan narsaning aniq turidir. Ularni to'g'ri yo'nalishga olib borish uchun ko'proq ko'raman.
qo'shib qo'ydi muallif ozz, manba
Batafsil tushunarli bo'lish; agar siz "menejerga borib, nima uchun so'rashganida o'lchashni qiyinlashtirishga ishora qilsangiz ..." deb javob bergan bo'lsangiz, javobingiz yaxshi bo'ladi. Bu qarama-qarshilik o'rniga hamkorlikka asoslangan yondashuvga to'g'ri keladi. Ehtimol, Joel Spolskiy testiga ham aloqasi yo'q. joelonsoftware.com/articles/fog0000000043.html
qo'shib qo'ydi muallif GlenH7, manba
Sizning javobingiz ikkala guruh orasidagi antagonistik munosabatlarni yaratadi yoki undan keyin yaratadi. Umumiy mahsuldorlikni oshirish uchun alternativ takliflarni taklif qilishda sizda yaxshi natija bor, lekin sizning tavsiya etilgan yondashuv noto'g'ri.
qo'shib qo'ydi muallif GlenH7, manba