Хөгжүүлэгч буюу Хөтөлбөрлөгч

Нөхөр буюу Дайсан

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

Ихэнхи тохиолдолд би иймэрхүү асуудлаас зайлсхийхийг чармайдаг. Хэрвээ компанийн шийдвэр гаргагчид туурвил хөгжүүлэлтийг надаас өөр өнцгөөр хардаг бол ийм компанид ажиллахгүй байх нь дээр гэж би үздэг. Ингэх олон шалтгаан бий. Нэгдүгээрт, төсөл бүтэлгүйтэн нурахыг би тэвчдэггүй, тэр тусмаа соёлын мөргөлдөөнөөс болж төсөл шатах магадлал өндөр. Хоёрдугаарт, соёлын эрс ялгаанаас улбаалан туурвил хөгжүүлэх үйл явцад юуг үр дүнтэй, амжилттай гэж үзэх талаар бөөн будилаан, эргэлзээ төрнө. Хэрэв хэн нэгэн этгээд миний сайн хийж буй зүйлийг үнэлэхгүй бол өөрийгөө үнэлүүлэх гэж зүтгэх нь ямар ч утга учиргүй зүйл болж хувирна.

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

Харин Майкрософт хамтлаг шал өөр соёлтой. Тэднийг Майкрософт Хөтөлбөрлөгчдийн Сүлжээ гэх биш, харин Майкрософт Хөгжүүлэгчдийн Сүлжээ гэж нэрлэдэг.

"Хөгжүүлэгчид" нь "хөтөлбөрлөгчдөөс" илүү өргөн хүрээтэй хариуцлага үүрнэ. Тодруулбал, хөгжүүлэгч болно гэдэг нь зөвхөн код бичихээс гадна туурвил хөгжүүлэх бусад олон асуудал дээр анхаарлаа хандуулна. Бэлдэцийн судалгаа хийх, сорилт бичих, шаардлагуудаа төвхнүүлэх гэх мэт - тухайн нөхцлөөс хамааран хэн нэгэн хөгжүүлэгч энэ бүхнийг бүгдийг нь юмуу заримыг нь хийж болно.

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

Хатуу төмөр дэвсгэртэй, нэг ёсондоо цехийн дамжлагаар хүмүүжсэн хүмүүс үүнийг барагтай бол ойлгохгүй. Тэдний бодлоор, туурвил хөгжүүлнэ гэдэг нь цэвэр механик үйл явц.

Нэгэн цагт, систем гэгч нь хангалттай энгийн хялбар байх үед механикаар ажиллах нь хэдий оновчтой зөв шийдэл байгаагүй боловч байж болох хувилбар байлаа. Харин одоо ийм үйл явц ёстой бүтэхгүй.

Амжилттай ажиллахын тулд, юмыг хэрхэн шийдэх талаар өргөн цар хүрээнд харах чадварыг хөгжүүлэгч хүн эзэмшсэн байх ёстой. Тухайн систем юу хийх талаархи ерөнхий ойлголтыг шийдвэр гаргагчид хянаж чаддаг байх ёстой гэдэг боловч өндөр хурдацтай өөрчлөгдөн буй технологийн хөгжил болон туурвил хөгжүүлэх үйлдвэрлэл дэхь арга техникийн хувьслын нөлөөгөөр хөгжүүлэлт хэрхэн хийгдэх ёстой талаар оновчтой шийдвэр гаргахад шийдвэр гаргагчдын ур чадвар яалт ч үгүй дутдаг. Тэд, тухайлбал, хөгжүүлэлтэнд туслах юмуу хурдасгахад ямархуу гуравдагч /third party/ технологи хэрэглэх нь илүү ашигтай вэ гэдэг талаар ухаалаг шийдвэр гаргаж чаддаггүй. Иймэрхүү болон өөр бусад олон асуудлууд дээр хөгжүүлэгч хүмүүс нь өөрсдийгөө шийдвэр гаргагчид хэмээн үздэг хүмүүсээс илт давуу шийдвэр гаргах чадвартай байдаг.

Үүнийг хүлээн зөвшөөрөх нь тэдэнд маш хэцүү. Үүний тулд ядруухан хөтөлбөрлөгчдөд хэзээ ч хүлээлгэж байгаагүй тийм их итгэл, хариуцлагыг хөгжүүлэгчдэд хүлээлгэх шаардлага гарна. Мэдээж хэрэг, өөрийн сул талыг хүлээн зөвшөөрнө гэдэг ямар ч хүний хувьд хүнд бэрх даваа.

Гэвч, хэрвээ үүнийгээ хүлээн зөвшөөрөхгүй бол тэд өөрсдийгөө хэд хэдэн төрлийн зовлонд унагана. Нэгдүгээрт, хөгжүүлэх үйл явц руу элс цацсанаараа, тэд асуудлыг илүү хүндрүүлж байна. Хоёрдугаарт, олонхи тохиолдолд, өөрчлөгдөн буй технологи болон үйлдвэрлэлийн хувьсан буй соёлтой авцалдахгүй бүрхэг ойлголт дээрээ тулгуурлан "яаж" гэдэг асуудал руу өнгийснөөрөө, тэд төсөл бүтэлгүйтэх эрсдлийг нэмэгдүүлж байна.

Шилдэг хүмүүсийг өөрийн байгууллагаасаа дайжихад хүргэж буйгаар тэд бас давхар хохирол амсана. Авъяаслаг хүмүүс хөгжүүлж буй системийнхээ талаар шийдэл гаргах боломжоо хумиулан зөвхөн механик эрэг шургийн үүрэг гүйцэтгэхийг тэсвэрлэж чаддаггүй. Энэ бол зөвхөн сэтгэлзүйн дарамт төдий үзэгдэл биш - энэ нь тухайн хүн цааш ахиж дэвжихэд нь бас хөнөөлтэй. Хэрвээ тэд хөгжүүлэлттэй холбоотой бүх төрлийн хариуцлага үүрэх явдлаас чөлөөлөгдвөл ирээдүйд гарах олон боломжууд тэдний өмнө хаагдана.

Техникийн Ахлах Ажилтан (ТАА) гэдэг ухагдахуун анх гарч моодонд орж байхад нь би үүнийг бүх талаараа дэмжиж байлаа. Учир нь ТАА нь технологийн асуудлыг шийдэх тал дээр байгууллагуудад үнэхээр тус дэм үзүүлнэ гэдэгт итгэж байв. Гэвч харамсалтай нь ТАА-тай нягт хамтран ажиллах явцдаа хийсэн хувийн дүнгэлтээс харахад тэд хөгжүүлэлтийг хурдасгах биш харин сааруулах хүчин зүйл болох нь элбэг байсныг дурдах хэрэгтэй. Эндээс ажигласан нэг зүйл гэвэл туурвил хөгжүүлэгч бид мэтийн хүмүүсийг тэдний өөрсдийнх нь хэлээр ердөө л "хөтөлбөрлөгч" гэж үздэг нь төслийг амжилтанд хүргэхэд томоохон саад бэрхшээл учруулдаг гол хүчин зүйл болж байгаа юм.

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=239

Жич: Төсөл хугацаандаа амжин дуусаж чадах эсэх нь удирдлага, зохион байгуулалт буюу менежмент хэр сайн муу байхаас шалтгаална гэсэн үзэл санаа дэлхий дахинаа түгээмэл тархсан байдаг. Энэ нь туурвил /software/ хөгжүүлэх үйл явц бол цехийн шат дамжлагаар явагддаг цэвэр механик шинжтэй үйл ажиллагаа, энэ үйл ажиллагаанд тавих хөндлөнгийн хяналтыг сайжруулснаар амжилтанд хүрч болно гэсэн итгэл үнэмшил дээр суурилдаг. Хөндлөнгийн хяналтыг сайжруулах ажлын хүрээнд нэг өдөр, нэг долоо хоног, эсвэл нэг сарын хугацаанд бичигдэх кодын мөрийн тоонд хяналт тавих (гол төлөв хэдийчинээ олон мөр код бичнэ, төдийчинээ сайн гэж үзэх), түгээмэл гарах алдааны статистик бүртгэл хөтлөн мэдлэгийн сан бүрдүүлэх гэх мэт ажлууд ордог. Уг нь бол зөв санаа.

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

Тэр тусмаа өнөөдрийн гол асуудал нь мэдлэгийн сан байгуулах явдал биш, харин мэдлэгийн сан яаж байгуулахгүй байх ёстой вэ гэсэн эсрэг утга руугаа тэмүүлж байна. Бид хэдийчинээ өнгөрснөөсөө хурдан салж чадна, цаг үетэйгээ төдийчинээ хурдан зохицож чадна. Мэддэг зүйлээсээ хурдан татгалзаж салж чаддаг байх хэрэгтэй. Учир нь бидний мэддэг зүйл маань урагш хөгжихөд маань маш том саад учруулдаг. Шинэ технологи нь ямагт хуучнаасаа татгалзах, өмнөхөө үгүйсгэх замаар цааш хөгждгийг санацгаая.

Өнөөдөр сайн багаж, сайн технологи нь төслийн хувь заяанд шийдвэрлэх ач холбогдолтой болж байгаа гэдэгтэй миний бие санал бүрэн нийлдэг. Жишээ нь хүмүүсийн гаргадаг алдаа дэлхий даяар нийтлэг байдаг. Ийм алдаануудад дүн шинжилгээ хийгээд мэдлэгийн сан бүрдүүлсэн сайт ч олноороо байдаг. Бас шилдэг техникүүдийн мэдлэгийн сан, өөрийгөө сорих сорилтуудын сан (үүнийг туршиж үзвэл их зүгээр) гээд хүн бүрийн мэдэж байвал зохих хэрэгслэлүүд бий. Тийм болохоор бидний хувьд жишээ нь туршлагаа үлдээнэ, баримтжуулна гэдэг нь цаг үрсэн, илүүц ажил болж харагдаад байна.

Хэдэн жилийн дараа, эсвэл хэдэн сарын дараа кодоо дахин эргэж харахад тулах цэг хэрэгтэй, тэр тулах цэг нь кодын тайлбарууд, баримтууд, гарсан алдаанууд, түүнийг шийдсэн шийдлүүд гэх мэт олон зүйлийг хамарсан мэдлэгийн сан байна гэдэг. Буруу биш. Гэхдээ өнөөгийн software re-engineering tools хангалттай өндөр түвшинд кодонд дүн шинжилгээ, задаргаа хийн шаардлагатай бол кодыг автоматаар шинэчлэн бичиж бас чадна. Үүнд маш бага хугацаа орно. Энэ салбарт өнөөдөр AI буюу хиймэл оюун ухааныг өргөн ашиглаж байна. Ийм багажуудын үнэ ханш ч өдөр ирэх тусам бууж байгаа. Хэрвээ бид цаг үеийнхээ асуудалтай хэт их зууралдаж цаг алдвал, хэрвээ бид мэддэг зүйлээсээ хурдан татгалзаж чадахгүй бол шинэ үеийн технологиудад бут цохигдох магадлал өндөр бий гэдгийг дашрамд тэмдэглэх нь зүйтэй болов уу.

Асуудлыг бүрэн олж харахын тулд маш өргөн хүрээнд сэтгэх шаардлага бий. Энэ удаад үүгээр өндөрлөе. Дараа өөр олон асуудлуудыг хөндсөн блог тэмдэглэл олж орчуулах болов уу хэмээн найдъя.

Жишээ нь agile development tools-ын талаар хэзээ нэгэн цагт дурдах хэрэг гарах болов уу, энэ нь ерөнхийдөө туршилт + сорилт + continuity + integration маягийн багаж гэж төсөөлж байна. Зарчмын хувьд урьдчилан төлөвлөх, хяналт тавихаас аль болох татгалзах чиг хандлагатай, хувь хүний эрх, эрх чөлөө, хариуцлага маш өндөр байхыг шаардсан өөрөө өөрийгөө хянах тогтолцоо гэж ойлгож байна. Ойрын ирээдүй иймэрхүү дүр төрхтэй болох болов уу, тиймээс бид ч бас энэ чиг хандлага руу аажмаар дөхөх ёстой юм болов уу гэж бодож байна.

Алдаатай дайн зарлах биш, харин алдаатай ойртон нөхөрлөх аргачлалд суурилсан хөгжүүлэлтийг өөрөөр test driven development гэдэг. Өөгүй тогтолцоо хэзээ ч ажилладаггүй гэсэн инженерийн алтан дүрэм байдгийг энэ дашрамд дурдаад тэмдэглэлээ өндөрлөе.