Хөгжүүлэлтийн бүтээмжийг хэрхэн бодитой дүгнэж үнэлэх вэ?

"Хөгжүүлэлтийн баг хангалттай хурдан ажиллаж байна уу?" Энэ бол үүсгэн байгуулагчид, гүйцэтгэх захирлууд болон технологийн удирдлагуудын (CTO) хамгийн их асуудаг мөртлөө хариулахад төвөгтэй асуултуудын нэг байдаг. Хөгжүүлэгчийн бүтээмжийг буруу хэмжих нь багийн соёлыг эвдэж, техникийн өр үүсгэх, цаашлаад бизнесийн бодит зорилгоос хазайхад хүргэдэг.

Инженерийн бүтээмж гэдэг нь тухайн хөгжүүлэгчийн бичсэн кодын мөр (Lines of Code), хийсэн коммитын тоо, эсвэл хаасан тикетийн тоогоор тодорхойлогддог зүйл биш. Энэ бол системлэг шинж чанар юм.

Бүтээмж нь санааг бодит бүтээгдэхүүн болгож хэрэглэгчид хүргэх хүртэлх бүх үйл явцын үр ашиг, чанар, найдвартай байдлын нэгдэл болно.

Энэхүү нийтлэлээр бид хөгжүүлэлтийн бүтээмжийг хэмжих шалгарсан аргууд, тулгардаг эрсдэлүүд болон технологийн удирдлагууд багийнхаа гүйцэтгэлийг хэрхэн зөв үнэлж, сайжруулах шийдвэр гаргах талаар авч үзэх болно. Үүнийг уншсанаар та зөвхөн тоон үзүүлэлтэд хэт автахгүйгээр, багийн ажлын урсгал (flow), саадыг (bottleneck) бодитоор илрүүлэх мэдлэгтэй болно.

Үндсэн хэмжүүрүүд: Юуг, яаж хэмжих вэ?

Бүтээмжийг үнэлэхдээ гаралтын хэмжээг биш, хүргэж буй үр дүнг (Outcome) хэмжих нь хамгийн чухал. Системийн түвшинд бүтээмжийг дараах гурван үндсэн чиглэлээр хэмждэг:

1. Хүргэлтийн хурд ба тогтвортой байдал: Код бичигдэж дууссанаас хойш хэрэглэгчид хүрч, хэвийн ажиллах хүртэлх хугацаа.
2. Ажлын урсгалын үр ашиг (Flow efficiency): Идэвхтэй хөгжүүлэлт хийгдэж буй хугацааг хүлээлгэнд (код хянах, тестлэх, орчин бэлтгэх) зарцуулж буй хугацаатай харьцуулсан харьцаа.
3. Хөгжүүлэгчийн туршлага (Developer Experience - DevEx): Хөгжүүлэгчид ажлаа саадгүй, төвлөрч хийх боломж хэрхэн бүрдсэн байгааг илтгэх чанарын үзүүлэлт.

Эдгээрийг тэнцвэртэй хэмжихийн тулд зөвхөн нэг хэрэгсэлд (жишээ нь, зөвхөн Jira эсвэл зөвхөн GitHub) найдах нь өрөөсгөл юм. Учир нь төслийн удирдлагын систем нь ажлын төлөвлөлтийг харуулдаг бол кодын сан нь бодит гүйцэтгэлийг харуулдаг.

Бүтээмжийг үнэлэх шалгарсан загварууд

Инженерийн багийн гүйцэтгэлийг хэмжих хоёр үндсэн стандарт загвар салбарт өргөн хэрэглэгдэж байна. Эдгээр нь багийг хооронд нь уралдуулах биш, харин системийн доголдлыг илрүүлэх зорилготой.

1. DORA хэмжүүрүүд (Багийн хурд ба найдвартай байдал)

Google-ийн дэмжлэгтэйгээр хөгжүүлсэн DORA судалгааны тайлан нь өндөр гүйцэтгэлтэй багуудын нийтлэг шинж чанарыг дөрвөн үндсэн хэмжүүрээр тодорхойлдог:

• Байршуулах буюу продакшнд нэвтрүүлэх давтамж (Deployment Frequency): Баг хэр олон удаа шинэ хувилбарыг продакшн орчинд нэвтрүүлж байна вэ? (Өдөрт олон удаа байх тусмаа сайн)
• Өөрчлөлт хүргэх хугацаа (Lead Time for Changes): Код коммит хийгдсэнээс хойш продакшн орчинд орох хүртэлх хугацаа.
• Өөрчлөлтийн алдааны түвшин (Change Failure Rate): Продакшн руу нэвтрүүлсэн өөрчлөлтүүдийн хэдэн хувь нь алдаа засах, буцаах шаардлагатай болж байна вэ?
• Үйлчилгээг сэргээх хугацаа (Time to Restore Service / MTTR): Системд саатал гарсны дараа хэвийн байдалд оруулахад хэр их хугацаа зарцуулж байна вэ?

Хэзээ ашиглах вэ: DORA нь CI/CD дамжлага, девопс соёл болон технологийн архитектурын чадамжийг хэмжихэд төгс тохирно. Гэхдээ энэ нь бүтээгдэхүүний үнэ цэнэ эсвэл багийн дотоод харилцааг хэмжиж чадахгүй.

2. SPACE загвар (Бүтээмжийн цогц үнэлгээ)

DORA хэмжүүрүүдийн дутууг нөхөх зорилгоор SPACE загварын танилцуулга бий болсон бөгөөд энэ нь бүтээмжийг таван өөр хэмжигдэхүүнээр хардаг:

• Satisfaction & Well-being (Сэтгэл ханамж ба сайн сайхан байдал): Багийн гишүүд ашиглаж буй багаж хэрэгсэл, ажлын орчиндоо хэр сэтгэл хангалуун байна вэ? Ажлаас халшрах эсвэл ажилдаа ядрах эрсдэл байгаа эсэх.
• Performance (Гүйцэтгэл): Бидний бичиж буй код бизнест нөлөөлж чадаж байна уу? Хэрэглэгчийн сэтгэл ханамж өсөж байна уу?
• Activity (Идэвх): PR-ийн тоо, коммитын тоо, продакшнд нийлүүлсэн тоо зэрэг уламжлалт үйл ажиллагааны хэмжүүрүүд.
• Communication & Collaboration (Харилцаа холбоо, хамтын ажиллагаа): Код хянах (code review) үйл явц хэр хурдан явагддаг вэ? Багууд хоорондоо мэдээлэл солилцоход саад байна уу?
• Efficiency & Flow (Үр ашиг ба ажлын урсгал): Нэг ажлаас нөгөө рүү шилжихэд алдагдаж буй цаг, контекст солилцох үйл явцын давтамж зэрэг ажлын тасралтгүй байдлыг илтгэнэ.

Хэмжүүрийг нөхцөл байдалд тохируулан ашиглах нь

Технологийн компанийн хөгжлийн үе шат, төслийн онцлогоос хамааран юуг голчлон анхаарах нь өөрчлөгддөг.

Шинэ үүсгэн байгуулагдсан стартап болон хурдтай өсөлтийн үед: Шинэ бүтээгдэхүүн зах зээлд гаргаж буй энэ үед Байршуулах давтамж болон Ажлын урсгалын үр ашиг чухал байдаг. Үнэлгээ хийх гол зорилго нь хөгжүүлэгчдийг удаашруулж буй хүчин зүйлсийг (гараар хийдэг deploy, хэт нүсэр төлөвлөлтийн процессууд) олж илрүүлэхэд оршино.

Том хэмжээний интерпрайз баг: Энэ үед тогтвортой байдал чухал болж ирнэ. Өөрчлөлтийн алдааны түвшин, Үйлчилгээг сэргээх хугацаа (MTTR) болон SPACE-ийн харилцаа холбооны хэмжүүрүүд гол хэмжигдэхүүн болдог. Багууд томрохын хэрээр код хянах процесс удаашрах, хамаарлын (dependency) эргэлзээ болон алдаа ихсэх эрсдэлтэй тул үүнийг хэмжих шаардлагатай.

Эрсдэл ба хязгаарлалт: Юу буруугаар эргэдэг вэ?

Бүтээмжийг хэмжихэд тулгардаг хамгийн том эрсдэл бол хэмжүүрийг зорилго болгох явдал юм. Энэ үзэгдлийг Goodhart's Law гэж нэрлэдэг. "Ямар нэгэн хэмжүүр зорилтот үзүүлэлт болох үед, тэр нь сайн хэмжүүр байхаа больдог."

• Зорилтот хэмжүүрийн гажуудал: Хэрвээ та бичсэн кодын мөрөөр эсвэл хаасан тикетийн тоогоор урамшуулал олгох юм бол хөгжүүлэгчид хамгийн амархан хийгдэх, эрсдэл багатай жижиг ажлуудыг түүж хийх болно. Нарийн төвөгтэй, системийн суурь асуудлыг шийдэх ажилд хэн ч оролцохыг хүсэхгүй.
• Хамтын ажиллагааны доройтол: Хувийн үзүүлэлт хөөцөлдсөн хүн бусдын кодыг хянах, залуу хөгжүүлэгчдэд зөвлөх (mentoring) ажилд цаг гаргахаас татгалздаг. Ингэснээр хувь хүний үзүүлэлт өндөр гарах боловч, багийн нийт хурд (velocity) унана.

Үүний оронд үнэлгээг үргэлж багийн эсвэл системийн түвшинд хийх ёстой. Зорилго нь хэн муу ажиллаж байгааг хайх биш, харин системийн аль хэсэгт бөглөрөл үүссэнийг (bottleneck) олоход оршино.

Шийдвэр гаргах шалгуурууд ба харьцуулалт

Инженерийн бүтээмжийн өгөгдлийг цуглуулж, дүн шинжилгээ хийхдээ дараах харьцуулалтын шалгууруудыг ашиглан шийдвэр гаргахад дэмжлэг үзүүлж болно.

Түгээмэл алдаанууд ба тэднээс зайлсхийх

Технологийн удирдлагууд бүтээмж хэмжих үедээ гаргадаг хэд хэдэн нийтлэг алдаанууд бий. Мэргэжлийн багууд эдгээрээс хэрхэн сэргийлдэг болохыг авч үзье:

1. Story Point-ийг хурдны хэмжүүр болгож ашиглах:
   Энэ бол зөвхөн төлөвлөлтөд зориулагдсан хийсвэр баримжаа юм. Нэг багийн 5 оноо нөгөө багийн 5 онооноос тэс өөр. Хэрэв онооны нийлбэрийг бүтээмж гэж үзвэл багууд онооны хэмжээгээ зориудаар өсгөж (point inflation) эхэлнэ. Үүний оронд продакшнд нийлүүлэх давтамж эсвэл тикет хүргэлтийн бодит цагийг (cycle time) хэмжих хэрэгтэй.
2. Чанарын өгөгдлийг (Qualitative data) үл тоомсорлох: Системийн өгөгдөл нь "Юу" болж байгааг хэлж өгдөг бол, хөгжүүлэгчдийн санал асуулга "Яагаад" гэдгийг тайлбарладаг. Хөгжүүлэгчдээс сар бүр багаж хэрэгслийн хурд, баримт бичгийн ойлгомжтой байдал зэрэг сэдвээр богино хэмжээний судалгаа авч хэвших нь үнэтэй мэдээлэл өгдөг.
3. Хэмжүүрийг гүйцэтгэлийн үнэлгээтэй (KPI/Bonus) холбох: Хэмжүүрийг цалин, урамшуулалтай шууд уях нь системийг гажуудуулах хамгийн хурдан арга. Хэмжүүр нь үнэлгээний хэрэгсэл биш, харин суралцах, тасралтгүй сайжруулалт (continuous improvement) хийх оношилгооны хэрэгсэл байх ёстой.
4. Хэт олон зүйл зэрэг хэмжих: Эхний ээлжинд SPACE болон DORA-ийн бүх хэмжүүрийг зэрэг нэвтрүүлэх гэж оролдох нь төөрөгдөл үүсгэдэг. Эхлээд зөвхөн хамгийн их өвдөлт өгч буй цэгээ (жишээлбэл, код продакшн руу орох хүртлээ хэр удаж байна вэ) олоход л хангалттай.

Дүгнэлтүүд

• Бүтээмж нь системийн үр дүн: Хөгжүүлэлтийн бүтээмж нь бие хүмүүсийн хурдаас илүүтэйгээр багаж хэрэгсэл, процесс, технологийн архитектур хоорондын уялдаанаас шууд шалтгаалдаг.
• DORA болон SPACE загварыг хослуулах: Зөвхөн хурд (DORA) төдийгүй, хөгжүүлэгчийн сэтгэл ханамж, багийн харилцааг (SPACE) хослуулан хэмжсэнээр урт хугацааны тогтвортой гүйцэтгэлийг хадгалж чадна.
• Гаралтыг бус, үр дүнг чухалчил: Бичсэн кодын хэмжээгээр бус, хэрэглэгчид хүргэсэн үнэ цэнэ, шийдэгдсэн асуудлаар амжилтыг хэмж.
• Оношилгоонд ашиглах: Метрикийг хэн нэгнийг шийтгэх эсвэл урамшуулахын тулд бус, харин ажлын урсгал дахь саатал эсвэл асуудлыг олж илрүүлэн устгахад ашиглах нь удирдлагын зөв хандлага юм.