Reset

Reset

Буг

Саяхан би vimomn.net дээр доорхыг саваагүй байдлаар бичсэн чинь улсууд нэг их дургүй хүлээж авахгүй байх шиг болохоор нь блог дээрээ тавьчихая гэж бодлоо.

Анхны лампан диод дээр тулгуурласан компьютер дотор шавьж буюу Англи хэлээр bug орж богино холбоо үүсгэх байдлаар ихээхэн ядаргаа болж байнга л цэвэрлэдэг байж.

Хожим програм дотор алдаа илрэхийг дээрхтэй ижилтгэн Program bug гэх болсон. Мөн програмын алдааг олохоор задлан ажиллуулахыг debug гэх болсон байх юм.

Үүнийг монгол хэлнээ одоогийн байдлаар "програмын бааг" гэж бичдэг. Заримдаа "програмын баг" ч гэх шиг.

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

Программистуудаа буггүй програм бичицгээж байя.

Энэ хэллэгийг хэрэглэн ярих хэдэн жишээнүүд:

Зөв ажиллаж байгаа програмд бид дуртай. Харин бугтай програмыг хэн ч үзэн яддаг.

Асар их бугтай чөтгөр шүглэсэн програмыг суулгах болон support хийх шиг хар дарсан зүүд үгүй.

Бугийг илрүүлэн програмыг эмчлэх нь програм зохиогч өөрийгөө сорих шаанс байдаг.

гэх мэтээр ярьж болох юмаа гэж. ;)

Си хэл, нээлттэй эхийн програм хангамж бас бус

Ойрд блог бичсэнгүй. Нэг салхи оруулмаар санагдлаа. Блог бичэхгүй байгаагаа зөвтгөх шалтгаан бас байгаа боловч одоохондоо дурдалгүй орхиё гэж...

Саяхан надаас миний нэгэн анд ийм асуулт асуулаа.

1. Програмчлал сурмаар байнаа. Хамгийн эхлээд ямар програмчлалын хэл сурах вэ? гэж асуудаг юм байна. Тэрээр өөрөө IT-ийн биш мэргэжилтэй, физикийн ухааны Ph.D нэгэн л дээ.

Энэ асуултанд би гэдэг хүн шууд хариулж харамсалтай нь чаддаггүй юм байна даа. Та байсан бол юу гэж хариулах вэ?

Мэдээж олон зүйлээс ямар програмчлалын хэл үзэж эхлэх вэ гэдэг нь хамаарна. Жишээ нь системийн админ нэгэн script хэлүүдийг сурч shell programming чаддаг болохоор зорилго нь хязгаарлагдаж байвал нэг өөр. Мэргэжлийн кодер болох гэж байгаа бол бас нэг ондоо. Хөгжүүлэгч, Системийн шинжээч зохиомжлогч, Тестер, Төслийн менежер болох гэж байгааг бүгдээрэнг нь харгалзаж үзэх хэрэг.

Мөн саяхан мэйлинг листээр онлайн маргаанд оролцож явтал нэгэн анд надад ийм зүйл хэлж байна.

2. Юникс, Си програмчлалыг үзлээ гээд одоо зах зээлд үүнийг хэрэглэх тохироо бүрдээгүй байна. Түүний оронд C#, Delphi, Visual Basic, Java үзвэл илүү хэрэгтэй гэлээ.

Би Их Сургуульд програмчлал цөөхөн хэдэн жил зааж байсан. Мөн үйлдвэрлэл дээр кодер, хөгжүүлэгч, шинжээч, зохиомжлогч, SE, PM гээд бүгдийг нь хальт хульт хийснийх зарим нэг бодлоо энэ тал дээр хуваалцмаар санагдлаа.

Эхлээд 2-р асуултаас эхлэж ярьмаар санагдаж байна. Миний ойлголтоор Их дээд сургууль хүнд хэрэг болох хамгийн суурь боловсролыг олгох нь хамгийн чухал үүрэг нь байдаг. Ялангуяа IT-ийн чиглэлийн хувьд технологийн маш олон чиглэл байх бөгөөд тэдгээрийн зах зээлийн эрэлт хэрэгцээ нь тогтмол хувьсан өөрчлөгдөж байдаг. Мөн нөгөөтэйгүүр IT салбар бол бүр төгсөгч ямар компанид ажилд орж байгаагаас хамаараад төрөл бүрийн сургуульд огт үзэж байгаагүй зүйл хийж эхлэх нь элбэг. МТ-ийн Компани бүр мэргэшсэн чиглэлтэй заримдаа бүр хэлтэс дэд баг бүр нь мэргэшсэн чиглэлтэй байдаг. Ийм газар очоод ажилд орох нь хийж байгаа ажилын бараг 80, 90%-д нь төрөл бүрийн гарын авлага, заавар, ижил төсттэй нээлттэй бүтээгдэхүүний судалгааг хийдэг. Хүн өөрөө бараг 10-с бага хувьд нь өөрөө шинээр үйлдвэрлэж хийж байдаг шахуу. Ийм л учраас их дээд сургууль зах зээлд тохируулахаас илүүтэйгээр хаана ч ямар ч салбарт очоод хэрэг болох суурь боловсролыг нь нарийвчлан заах нь чухал байдаг. Иймээс харин ч эсрэгээрээ Visual Basic, Delphi гэх мэт програмчлалын хэлийг заахгүй байх нь зөв байх болов уу гэж боддог. (Хэрэв заагаад төгсөгчдийг улам явцуу байдалтай болгоод түүнээсээ нийтээрээ салахаа болох талтай)

Тэгэхээр сайн кодер бэлтгэх суурь боловсрол гэж чухам юуг хэлэх вэ гэдэг асуулт зүй ёсоор гарах байх.
Дахиад өөрөөрөө жишээлэе. Би математикийн мэргэжлийг МУИС-ийн Математикийн факультетэд эзэмшсэн нэгэн. Миний мэдэхийн физик, математикийн мэргэжлээс IT-руу орсон сайн мэргэжилтэн би олныг мэддэг. Мөн одоо ажил дээр ажиллаж байх явцад ч тэр зарим нэг проблем шийдэх, код загварчлал хийхэд ч тэр математикийн мэргэжил дээр заалгаж байсан ойлголтууд хэрэг болох нь бараг өдөр болгон гарч байдаг. Магадгүй миний сурах арга математикаар дамжсан болоод ч тийм байдагийг үгүйсгэхгүй. Гэхдээ гол хэлэх санаа нь математикийг хаана хэрэглэхийг их сургуульд бараг заадаггүй. Хаана хэрэглэхээ ч би өөрөө мэддэггүй байсан. Суурь мэдлэг гэдэг харин хаана ч хэрэг болдог хэрэг. Математикийн яриаг түр орхиод МТ-ийн яриандаа ороё.

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

Үйлдлийн Системийг хийнэ гэдэг бол агуу ажил. Гэтэл үүнийг дэлхийг тойрсон сайн дурын программистууд хийгээд эх нь нээлттэйгээр байж байна. (Мэдээж хүн бүр Linus Torvaldo шиг агуу байх албагүй) Нээлттэй эхийн том бага маш олон төслүүд төрөл бүрийн байдлаар менежментээ хийгээд нүүр тулж үзээгүй програмистууд нэгэн бүтээгдэхүүнийг дэлхийн хэдэн өнцгөөс хувааж аваад хийж байна. Хуваана ч гэж бүр нэг файл доторх кодыг хэдэн талаас нь засаад зассанаа нийлүүлээд төвөггүй төсөл хөгжиж байна.

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

Дээрх суурь чадваруудыг хаана хэрхэн олж авах вэ гэвэл яахын аргагүй C, Java мэт хэлүүдээр эхлэлээ тавьж, нээлттэй эхэд хүчээ үзэж байж олж авах нь хамгийн сайн арга байдаг гэдэгтэй санал нэгдэх байх гэж найдаж байна. Гэхдээ миний хувьд C-ийг анхлан үзэж байсан бөгөөд одоо бодоход бүх л суурийг энэ хэлээс олж авсан байдаг болов уу. Гэхдээ дээр хэлсэн анх програчмлал сурч байгаа хүнийг Java үзэхийг зөвлөх гэтэл бас асуудлууд байнаа. Гэтэл С-г сурснаар бас давуу талууд ч байнаа.

Гэхдээ энэ бүгд миний хувийн бодол гэдэгийг дурдаад үргэлжлүүлэхэд Монголын Их дээд сургуулиудын компьютерийн лабораторийг бүгдийг нь Linux болгоё. Microsoft Windows-ийг больсон дээр гэж бодоод байгаа. Яахав албан газар, багш эдэр Windows хэрэглээд байж байхад асуудал байхгүй. Зөвхөн их дээд сургуулийн бүх лабораторийг л ийм болгох нь зүйтэй юм гэж бодоод байгаа юм. Боловсролын байгууллагын хувьд нээлттэй эхийн бүтээгдэхүүн хэрэглэхийн олон олон давуу талыг би энд цувуулан бичсэнгүй. Тэр нь өөрөө эргээд маш том хүрээг хамарч таарна.

За төгсгөлд нь энэ хүртэл уншсан үүгээр зорчин өнгөрөгч таниас нэг зүйл асууя. Дээр асуусан манай найзын асуултанд юу гэж хариулах вэ? Тэрээр мэргэжлийн программист болох гэсэн нэгэн л дээ. Та юу гэж зөвлөх вэ чухам яагаад? Мөн 2-р асуудал дээр ч бодлыг тань сонсоход маш сонин байна.

CMMI гэсэн үг Япон хэлээр

CMMI=Capability Maturity Model Integration=能力成熟度モデル統合

Дээрх нэр томьёог орчуулах албагүй ч үг нэг бүр нь дангаараа хэрэглэх
үзэгдэл элбэг тул ямар нэг хэмжээгээр орчуулах нь зүйтэй бололтой.
Японууд яаж орчуулсныг сонирхоё.

Capability=能力гэж орчуулсан байгаа.
能 гэдэг бол авьяас, 力 гэдэг бол чадал гэдэг утгатай ханзууд бөгөөд
нийлээд авъяас чадвар буюу "чадавхи" гэсэн үг болох байх.

Maturity=成熟度 гэж орчуулсан байгаа.
成 гэдэг нь болох, 熟 гэдэг нь бүрэн гэсэн утгатай бөгөөд Япон хэлэнд 2
ханз нийлж нэр үг үүсгэж байгаа тохиолдолд голдуу хойноосоо урагш нь
нийлүүлж харахад эцсийн утгаа хэлдэг. Тэгэхээр энэ 2 ханз нийлээд
бүрэн болсон буюу "боловсорсон" гэсэн утга илэрхийлж байна.
度 гэдэг нь ямар нэг зүйлийн түвшин хэмжээг илэрхийлдэг бөгөөд эцсийн
байдлаар "боловсролын түвшин" гэдэг утгыг илэрхийлэх юм байна. Үүнийг
товчоор боловсорсон, боловсорсон байдал гэх мэтээр ярьж болох байх.

Integration=統合 гэж орчуулсан байгаа.
統 гэдэг нь хянах, 合 гэдэг нь уулзсан гэсэн утга бөгөөд уулзаж
хянагдсан, нэгдмэл, цогц гэсэн утгыг илэрхийлнэ. Үүнийг товчоор "цогц
байдал" гэж ч хэлж болох байх.

Дээрх CMMI гэдэг үгийг гэхдээ нийлүүлээд хэлэхэд төвөгтэй юм. "Чадавхи
Боловсролын Загварын Цогц" гэж муйхардаж орчуулж болох л юм. Гэхдээ
ＣＭＭＩ-раа байсан нь дээр байх.

Дээрх дээр зарим нэг хэрэглэх хэлбэрийг товч жишээлж үзэе.

Company Capability →　Компаны Чадавх
Matured Company → Боловсорсон Компани
Company Maturity　→　Компаний боловсорсон байдал

гэх мэтээр ярьж болох байх. Энгийн Монголоор ярихад дараах байдлаар
ярьж болох юм. （Хэл бичигийн авъяас мууг харгалзаж ойлгоорой）
Жишээ:
Компани хичнээн чадавхитай байлаа гээд бүрэн боловсроогүй бол
өөрийнхөө хамгийн өндөр бүтээмжээр ажиллаж чаддахгүй байх нь элбэг
байдаг. Чанартай, оновчтой ажиллах хэлбэр олон байж болох ч компаний
процесст гарцаагүй шаардлагатай зүйлс гээгдсэн байх нь элбэг байдаг.
Мөн дотоод процессын уялдаат холбоо цогц байдал нь бүрэн хяналтанд
ороогүй байх нь элбэг. CMMI нь боловсорсон компанид гарцаагүй байвал
зохих зүйлсийн загварыг цогц байдлаар томьёолон гаргасан дэлхийд
хүлээн зөвшөөрөгдсөн загвар юм.

Хийхгүй эсвэл Чадахгүй

Японуудтай харилцана гэдэг бол байнга харилцааны дайн байдаг. Манай
хэлтсийн дарга надаас болон бусдаас нэг асуултыг байнга асуудаг нь
баталгаагаар хангаж чадах уу гэдэг асуулт юм.

Би түүнд нь баталгаагаар хангаж чадна, гэхдээ батлахгүй гэж дүйвүүлдэг
болсон. Энэ нь логикийн хувьд ямар ч утгагүй хариулт ч гэлээ харилцааны
хувьд төрүүлэх сэтгэгдэл нь яльгүй ялгаатай байдаг. Зөв бурууг мэдэхгүй?
Та юу гэж бодож байна?

Толгой загатанаад бас өвдөөд байна.

Одоо үүр цайж байна. Шөнө унтаагүй болоод нүд аргаж толгой өвдөж мөр чилж байна. NEC-ийн сервер машинуудын өрөөнд хоносон надад тухтай суух ажлын ширээ ч үнэндээ алга. Хаа очиж Японы Softbank Connect Card гэх утасгүй интернет компаниас өгсөн нь хурд сайтай тул интернет надад хань болж байгаа хэрэг. Хийж байгаа төслийн маань ээлжил золгоо (立会い) маргааш болох тул бэлдээд сүйд. 2 жил зууралдсан төсөлийн маань эхний шат дуусах уг нь дөхөж байна. Манай багийн хийсэн систем Ханэда онгоцны буудал дээр ажиллаж эхлэх хугацаа ойртож байна. Оосака, Кансай, Фүкүока гээд дараа дараагийн онгоцны буудал дээр ажиллах системүүдийн үзүүлэх тоглолтыг маргааш хийх гээд толгойгоо маажаад сууж байгаа нь энэ хэрэг. Нислэгийн удирдлагын төхөөрөмжүүд, аюулгүй байдал, чанартай програм, алдаагүй болтол шалгах, ард нь том хариуцлага бас шаанс гээд бид гүрийж байна, зарим үед ганцаараа энэ их ажлын дунд Монгол руу гүүр хийх, алдааг нь шинжлэх учрыг нь тайлах, Япон талтай хэл амаа ололцох, хийсэн системийг суулгах, нэвтрүүлэх сургах, тестлэх бүх л зүйл ганц гүүр инженер над дээр түгжирч сүлжээгээр бол траффик ихтэй bridge хийсээр хүчдэлдээ халж бас элэгдэлд орж байх шигээ.  Нервтэх, цагаан үс ургах, үрчлээтэх, хараа муудах, өтлөх гээд элэгдэлд орох явцын хурдатгалтайгаар хурдасчайхшиг. Монголын маань анир чимээгүй тал нутагаа, царцааны чимээ хонины мах сархадаа, хуурын аялгуугаа санаж ч байх шиг. Ядаж байхад энэ Японд гэртээ ч чанга хашгирч караокэдэж болохгүй байрнаасааа хөөгдчих гээд бөөн дарамт. За дараа тэгээд төслийнхөө ард гарч байгаад нэг завтайхан шиг жаахан буу халнаа. Одоо нойрмогтоод юу бичижайгаагаа ч хянах сэгээ алга шив ингээд болиё. Багадаа хугалж байсан зүүн эгэмний яс яагаад ч юм өнөөдөр анх өвдөж байхын. Одоо хоёрын хооронд ширээ дэрлэж унтаснаас гадаа гарч жаахан алхая.

Төсөл дахь Япон маягийн харилцааны талаар

Япон маягийн харилцааны арга барилын талаар төрсөн сэтгэгдлээ товч хуваалцья гэж бодлоо. Миний хийж байгаа төсөл дээр тестийн ажил нь нийт ажлын бараг 60-с 70% нь болчихсон өвөрмөц төсөл бөгөөд нэг системийг 10 орчим компани хувааж авч хөгжүүлж байгаа юм. Ийм тохиолдолд төслийн менежментэд communication буюу харилцааны асуудал нь их чухал зүйл байх нь мэдээж юм. Орчин үед бүх тайлан явц ил харагдах автоматжисан дэд бүтэцүүдийг ихэд голчилж хавтгай удирдлагыг чухилчилж үздэгийг Америк, Европ гаралтай номын дуу сонсож ажиллаж амьдарч байгаа бид бүхэн мэдэх хэрэг. Японы хувьд ч ижил боловч харилцааны хувьд нилээд ялгаатай байдаг. Магадгүй энэ нь ч Япон аутсоорсингийн том зах зээл хэдий ч сайн нэвтэрч болдоггүйн нэгэн шалтгаан нь байж болох л юм. Мэдээж ханз үсэг, хэл энэ тэр гээд өөр олон шалтгаан байгаа л даа.

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

• 窓口-мадогүчи буюу шагайвч цонхны үүрэг гүйцэтгэгч нар. Энэ нь гадны ямар нэг компанитай харилцах цонх болох дүр юм. Дүрийг сонгохдоо communication skill болон тухайн компанитай харилцаж байсан туршлага, танил тал, харилцаж байгаа үйл ажиллагааны чиглэлийн туршлага зэрэгээс хамааруулаад менежментийн тодорхой туршлагатай хүнийг тавих хэрэг.

• 受付-үкэцүкэ буюу хүлээн авагч нар. Гаднаас манай компанид ирж байгаа материалуудыг хүлээн авч түүний менежментийг гүйцэтгэгч нар. Энэ нь нөгөө талаасаа бусад компанид ганц л хүнтэй харилцах таатай хэлбэрийг үүсгэх бөгөөд дотор талдаа төвлөрсөн хяналтыг бий болгож эргээд компани дотороо задлан хуваарьлах менежмент нь хялбар болдог.

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

• Bridge SE буюу гүүр системийн инженерүүд. Системийн шинжилгээ зохиомжийг төслийн үндсэн багийнхантай хамт гаргаж түүнийгээ хөгжүүлэлтийн баг руу хүргэх үүрэгийг гүйцэтгэгч нар буюу миний одоогийн голлон хийж байгаа ажил. (Гэхдээ дээр хэлсэн дүрүүдийг ч хийж байсан)

• Бамбай эсвэл Хуяг. Бамбай нар нь өөрийн компаныг бусдаас хамгаалах үүрэгийг гүйцэтгэгч нар юм. Японуудын хувьд хамгийн чухалчилдаг зүйлийн нэг нь энэ бөгөөд компани гэлтгүй хүн бүр өөртөө бамбайтай байдаг гэхэд болох байх. Харин Монголчуудын хувьд хүн бүр ингэж бамбайтай байдаггүй бололтой юм. Тийм болохоор Монгол компаны хувьд ийм “бамбай” дүрийг бүр тусгайлан гаргах хэрэгтэй гэж боддог болоод байгаа. Ингээд энэ Бамбай дүрийн талаар жаахан дэлгэрэнгүй ярья.
  Японд дэд гэрээлэгчийн схем хүчтэй хөгжсөн тул дэд гэрээлэгч тус бүр өөрийгөө хуяглаж байж хариуцлагаас мултардаг аж. Өөрийн компаны ажил удаашрах шалтгаан, төлөвлөгөөг сунгах шалтгаан, ажилын явц зогссон шалтгаан зэрэгийн шалтгааны харагдахгүй менежмент Япон оронд бий. Эдгээр шалтгаануудыг өөрийн компаниас зайлуулж бусад руу бөмбөгийг шилжүүлэх үүрэгийг гүйцэтгэгч нар юм. Бусад руу бөмбөгийг шилжүүлэх олон техник бий.

  • Өөрийн ажлын орцыг нэхэмжлэх болон хоцроож хүлээн авсан тохиолдолд түүнийг өөрийн төслийн төлөвлөгөөнд нөлөөлөх шалтгаан мөн эсэхийг шинжлэн хэлэлцээрийг явуулах

  • Хийж буй ажилд асуулт гарсан тохиолдолд асуух, түүнийг хариулт нь заасан хугацаанд хариулагдах эсэх болон тэр нь ажлын явцад нөлөөлөх шалтгаан болж буй эсэхийг хянах

  • Бусад компаниудаас өөрийн компаний хийж байгаа ажилд нөлөөлөх өөрчлөлт ирэх тутамд түүнийг өөрийн ажилд нөлөөлөх шалтгааны менежментэд оруулах

  • Хэрэв манай хийж байгаа систем дотор бусад компаны үйлдвэрлэсэн дэд хэсэг агуулагдсан бөгөөд тэр нь ямар нэг байдлаар гологдол гарах бүрийд түүнийг мөн өөрийн ажилд нөлөөлөх шалтгааны менежментэд оруулах

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

Дээрх зүйлийг би ямар нэг ном зохиол дээр суурьлалгүй зүгээр л тулгарч байгаа зүйлсээсээ түүгээд биччихсэн тул түүхий зүйл байгаа нь ойлгомжтой. Харин энэ талаар ном зохиол байдаг байх л даа. Тийм бол коммент дээр үлдээвээс thanks.