Мэдээллийн технологийн төслийн багийн ажлын явцыг зохион байгуулах

Сайн уу найзуудаа. Ихэнхдээ, ялангуяа аутсорсингийн ажилд би ижил дүр зургийг хардаг. Төрөл бүрийн төслүүд дээр багуудын ажлын тодорхой урсгал байхгүй байна.

Хамгийн гол нь программистууд үйлчлүүлэгчтэйгээ болон өөр хоорондоо хэрхэн харилцахаа ойлгодоггүй. Чанартай бүтээгдэхүүн үйлдвэрлэх тасралтгүй үйл явцыг хэрхэн бий болгох вэ. Ажлын өдөр, спринтийг хэрхэн төлөвлөх вэ.

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

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

Төслийн хариуцлага хүлээхийг хэн ч хүссэнгүй (үйлчилгээний томоохон зах зээл), эргэлт нь аймшигтай байсан, үйлчлүүлэгч зүгээр л урж хаясан. Гүйцэтгэх захирал ямар нэгэн байдлаар над руу ойртож, танд шаардлагатай туршлага байгаа тул гартаа картууд байгаа гэж хэлсэн. Төслийг өөртөө аваарай. Хэрэв та бужигнавал бид төслийг хааж, бүгдийг нь хөөх болно. Энэ нь гарч ирнэ, энэ нь сайхан байх болно, дараа нь түүнийг удирдан чиглүүлж, өөрийн үзэмжээр хөгжүүлээрэй. Үүний үр дүнд би төслийн багийн ахлагч болж, бүх зүйл миний мөрөн дээр буусан.

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

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

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

Энэ нь миний төсөл дээр хэрэгждэг тул хэн нэгэнд тустай байж магадгүй юм. Тиймээс төслийг хэмнэхэд тусалсан үйл явц нь өөрөө:

"Миний дуртай төсөл" төслийн багийн ажлын явц

a) Багийн үйл явцын хүрээнд (хөгжүүлэгчдийн хооронд)

  • Бүх ажлыг Жира системд хийдэг
  • Даалгавар бүрийг аль болох тайлбарлаж, нэг үйлдлийг гүйцэтгэх ёстой.
  • Аливаа шинж чанар, хэрэв энэ нь хангалттай төвөгтэй бол олон жижиг даалгаварт хуваагддаг
  • Баг нь нэг даалгавар болгон онцлог шинж чанарууд дээр ажилладаг. Эхлээд бид нэг функцийг хамтдаа хийж, туршилтанд оруулаад дараагийнхыг нь авна.
  • Даалгавар бүрийг backend эсвэл frontend гэсэн шошготой
  • Даалгавар болон алдааны төрлүүд байдаг. Та тэдгээрийг зөв зааж өгөх хэрэгтэй.
  • Даалгаврыг гүйцэтгэсний дараа энэ нь кодыг шалгах статус руу шилждэг (хамтран ажиллагчдаа татах хүсэлтийг үүсгэсэн)
  • Даалгаврыг гүйцэтгэсэн хүн энэ ажлыг хийх цагаа шууд хянадаг
  • Кодыг шалгасны дараа PR-г баталж, үүний дараа энэ ажлыг гүйцэтгэсэн хүн үүнийг бие даан мастер салбар руу нэгтгэж, дараа нь статусаа dev серверт байрлуулахад бэлэн болгож өөрчилдөг.
  • Хөгжүүлэгчийн серверт байрлуулахад бэлэн байгаа бүх даалгаврыг багийн ахлагч (түүний хариуцах хэсэг), заримдаа яаралтай ямар нэг зүйл байвал багийн гишүүн гүйцэтгэдэг. Байрлуулсны дараа, байршуулахад бэлэн байхаас эхлээд хөгжүүлэлт хүртэл бүх ажлуудыг төлөвт шилжүүлж, төхөөрөмж дээр туршихад бэлэн болно.
  • Бүх ажлыг үйлчлүүлэгч шалгадаг
  • Үйлчлүүлэгч уг даалгаврыг төхөөрөмж дээр туршиж үзэхэд түүнийг үйлдвэрлэлд ашиглахад бэлэн байдалд шилжүүлдэг.
  • Үйлдвэрлэлд нэвтрүүлэхийн тулд бид ашиглалтын өмнөхөн мастерийг нэгтгэдэг тусдаа салбартай
  • Туршилтын явцад үйлчлүүлэгч алдаа олсон бол тэр даалгаврыг хянан үзэхээр буцааж, түүний статусыг засварлахаар буцаана. Бид шинэ даалгавруудыг туршиж үзээгүй ажлуудаас ингэж ялгадаг.
  • Үүний үр дүнд бүх ажлуудыг бүтээхээс дуусгах хүртэл явагдана: Хийх → Хөгжүүлэлтэд → Код хянан үзэх → Хөгжүүлэгчид ашиглахад бэлэн → Хөгжүүлэгч дээр QA → (Хөгжүүлэгч рүү буцах) → Үйлдвэрлэлд ашиглахад бэлэн → Бүтээгдэхүүн дээрх QA → Дууслаа
  • Хөгжүүлэгч бүр өөрийн кодыг бие даан, тэр дундаа сайтын хэрэглэгчийн хувьд туршиж үздэг. Код ажиллаж байгаа нь тодорхойгүй бол салбарыг үндсэн салбартай нэгтгэхийг хориглоно.
  • Ажил бүр тэргүүлэх чиглэлтэй байдаг. Тэргүүлэх чиглэлийг үйлчлүүлэгч эсвэл багийн ахлагч тогтоодог.
  • Хөгжүүлэгчид хамгийн түрүүнд тэргүүлэх ажлуудыг хийдэг.
  • Хэрэв системд янз бүрийн алдаа олдсон эсвэл нэг ажил нь хэд хэдэн мэргэжилтний ажилд орсон бол хөгжүүлэгчид бие биедээ даалгавар өгч болно.
  • Үйлчлүүлэгчийн бүтээсэн бүх даалгаврыг багийн ахлагч руу илгээж, тэр тэднийг үнэлж, эцсийн байдлаар дуусгахыг захиалагчаас хүсэх эсвэл багийн гишүүдийн аль нэгэнд даалгана.
  • Хөгжүүлэгч эсвэл үйлдвэрлэлд байрлуулахад бэлэн байгаа бүх даалгаврыг хэзээ, хэрхэн байрлуулахаа бие даан тодорхойлдог багийн ахлагч хариуцдаг. Байршуулах бүрийн дараа багийн ахлагч (эсвэл багийн гишүүн) энэ талаар хэрэглэгчдэд мэдэгдэх ёстой. Мөн даалгаврын статусыг dev/prod дээр туршихад бэлэн болгож өөрчлөх.
  • Өдөр бүр нэгэн зэрэг (бид 12.00 цагт) бид багийн бүх гишүүдийн дунд жагсаал хийдэг.
  • Өчигдөр юу хийсэн, өнөөдөр юу хийхээр төлөвлөж байгаагаа багийн ахлагч гэлтгүй жагсаалд оролцсон хүн бүр тайлагнадаг. Юу нь болохгүй байна, яагаад. Тиймээс хэн юу хийж байгаа, ямар шатандаа яваа төсөл гэдгийг бүхэл бүтэн баг мэдэж байгаа. Энэ нь шаардлагатай бол бидний тооцоо, эцсийн хугацааг урьдчилан таамаглах, тохируулах боломжийг бидэнд олгодог.
  • Уулзалтаар багийн ахлагч төслийн бүх өөрчлөлт, захиалагчийн олж илрүүлээгүй одоогийн алдааны түвшинг зарладаг. Бүх алдаануудыг ангилж, тэдгээрийг шийдвэрлэхийн тулд багийн гишүүн бүрт хуваарилдаг.
  • Жагсаал дээр багийн ахлагч нь хөгжүүлэгчдийн одоогийн ачаалал, тэдний мэргэжлийн сургалтын түвшин, мөн тухайн ажил нь хөгжүүлэгчийн одоо хийж байгаа зүйлтэй ойрхон байгааг харгалзан тус бүрд үүрэг даалгавар өгдөг.
  • Уулзалтаар багийн ахлагч архитектур, бизнесийн логикийн ерөнхий стратегийг боловсруулдаг. Үүний дараа бүхэл бүтэн баг энэ талаар ярилцаж, зохицуулалт хийх эсвэл энэ стратегийг хэрэгжүүлэх эсэхээ шийддэг.
  • Хөгжүүлэгч бүр нэг архитектур, бизнесийн логикийн хүрээнд код бичиж, алгоритмуудыг бие даан бүтээдэг. Хүн бүр хэрэгжүүлэх алсын хараагаа илэрхийлж болно, гэхдээ хэн ч үүнийг ингэж хий гэж албаддаггүй, өөр аргаар биш. Шийдвэр бүр үндэслэлтэй. Хэрэв илүү сайн шийдэл байгаа бол одоо үүнийг хийх цаг байхгүй бол кодын тодорхой хэсгийг ирээдүйд дахин засварлах даалгаврыг өөхөн дээр үүсгэнэ.
  • Хөгжүүлэгч даалгавраа хийхдээ түүнийг хөгжлийн төлөв рүү шилжүүлдэг. Үйлчлүүлэгчтэй хийх даалгаврыг тодруулахтай холбоотой бүх харилцаа холбоо хөгжүүлэгчийн мөрөн дээр унадаг. Техникийн асуултыг багийн ахлагч эсвэл хамтран ажиллагсдаас асууж болно.
  • Хэрэв хөгжүүлэгч даалгаврын мөн чанарыг ойлгохгүй, үйлчлүүлэгч үүнийг ухаалгаар тайлбарлаж чадаагүй бол дараагийн ажил руугаа орно. Мөн багийн ахлагч одоогийнхыг авч, үйлчлүүлэгчтэй ярилцдаг.
  • Хөгжүүлэгч өдөр бүр үйлчлүүлэгчийн чат дээр өчигдөр ямар ажил хийсэн, өнөөдөр ямар ажил хийх талаар бичих ёстой.
  • Ажлын урсгал нь Scrum дээр суурилдаг. Бүх зүйл спринт гэж хуваагддаг. Спринт бүр хоёр долоо хоног үргэлжилнэ.
  • Спринтийг багийн ахлагч үүсгэж, бөглөж, хаадаг.
  • Хэрэв төсөл нь хатуу эцсийн хугацаатай бол бид бүх ажлыг ойролцоогоор тооцоолохыг хичээдэг. Мөн бид тэднээс спринт цуглуулдаг. Хэрэв үйлчлүүлэгч спринтэд илүү олон даалгавар нэмэхийг оролдвол бид тэргүүлэх чиглэлийг тогтоож, дараагийн спринт руу бусад ажлыг шилжүүлдэг.

б) Үйлчлүүлэгчтэй ажиллах үйл явц

  • Хөгжүүлэгч бүр үйлчлүүлэгчтэй харилцах боломжтой бөгөөд харилцах ёстой
  • Та үйлчлүүлэгч өөрийн тоглоомын дүрмийг ногдуулахыг зөвшөөрч болохгүй. Үйлчлүүлэгчдээ эелдэг, найрсаг байдлаар бид тухайн салбартаа мэргэшсэн хүмүүс гэдгээ ойлгуулах шаардлагатай бөгөөд зөвхөн бид ажлын процессыг бий болгож, түүнд үйлчлүүлэгчийг татан оролцуулах ёстой.
  • Аливаа функцийг хэрэгжүүлэхийн өмнө тухайн функцийн (ажлын урсгал) бүхэл бүтэн логик үйл явцын схемийг үүсгэх шаардлагатай. Мөн баталгаажуулахын тулд харилцагч руу илгээнэ үү. Энэ нь зөвхөн төлбөрийн систем, мэдэгдлийн систем гэх мэт нарийн төвөгтэй, тодорхой бус функцүүдэд хамаарна. Энэ нь үйлчлүүлэгчид яг юу хэрэгтэй байгааг илүү нарийвчлалтай ойлгох, тухайн функцийн баримт бичгийг хадгалах, мөн ирээдүйд үйлчлүүлэгч бид түүний хүссэн зүйлийг хийгээгүй гэж хэлэхээс өөрийгөө хамгаалах боломжийг олгоно.
  • Бүх диаграмм / урсгал диаграм / логик гэх мэт. Бид Confluence/Fat-д хадгалдаг бөгөөд бид үйлчлүүлэгчээс ирээдүйн хэрэгжилтийн зөв эсэхийг баталгаажуулахыг санал хүсэлтээр асуудаг.
  • Бид үйлчлүүлэгчдэд техникийн нарийн ширийн зүйлийг дарамтлахгүй байхыг хичээдэг. Хэрэв үйлчлүүлэгч хэрхэн хүсч байгааг ойлгох шаардлагатай бол бид хэрэглэгч өөрөө ойлгож, засах / өөрчлөх боломжтой схемийн хэлбэрээр энгийн алгоритмуудыг зурдаг.
  • Хэрэв үйлчлүүлэгч төсөлд алдаа олсон бол бид танаас үүнийг өөхөнд нарийвчлан тайлбарлахыг хүсч байна. Туршилтын явцад үйлчлүүлэгч ямар нөхцөл байдалд, хэзээ, ямар дарааллаар хийсэн үйлдэл хийсэн бэ. Дэлгэцийн агшинг хавсаргана уу.
  • Бид өдөр бүр, хамгийн ихдээ хоёр өдөр тутам хөгжүүлэлтийн серверт байршуулахыг хичээдэг. Дараа нь үйлчлүүлэгч функцийг туршиж эхлэх бөгөөд төсөл сул зогсохгүй. Үүний зэрэгцээ, энэ нь үйлчлүүлэгчийн хувьд төсөл бүрэн хөгжиж байгаа бөгөөд хэн ч түүнд үлгэр ярихгүй байгаагийн тэмдэг юм.
  • Үйлчлүүлэгч өөрт нь юу хэрэгтэй байгааг бүрэн ойлгохгүй байх тохиолдол элбэг байдаг. Тэрээр хараахан дибаг хийгдээгүй процессуудтай өөртөө зориулж шинэ бизнесийг бий болгодог. Тиймээс бид бүхэл бүтэн кодын хогийн сав руу хаяж, програмын логикийг өөрчлөх нь маш түгээмэл тохиолдол юм. Үүнээс үзэхэд бүх зүйлийг туршилтаар хамрах шаардлагагүй юм. Зөвхөн чухал функцийг тестээр, дараа нь захиалгаар хамрах нь утга учиртай.
  • Биднийг заасан хугацаанд багтааж чадахгүй байгааг багийнхан ойлгох тохиолдол байдаг. Дараа нь бид даалгаврын аудитыг шуурхай хийж, энэ талаар үйлчлүүлэгчид нэн даруй мэдэгдэнэ. Нөхцөл байдлаас гарах гарцын хувьд бид чухал, чухал функцийг цаг тухайд нь эхлүүлэхийг санал болгож байна, үлдсэнийг нь гаргасны дараа үлдээхийг зөвлөж байна.
  • Хэрэв үйлчлүүлэгч толгойноосоо янз бүрийн даалгавар гаргаж, хуруугаараа төсөөлж, тайлбарлаж эхэлбэл бид түүнээс хуудасны зохион байгуулалт, бүхэл бүтэн зохион байгуулалт, түүний үйлдлийг бүрэн дүрсэлсэн логикоор урсахыг биднээс хүсч байна. элементүүд.
  • Бид аливаа ажлыг хийхээсээ өмнө энэ онцлогийг манай гэрээ/гэрээнд тусгасан эсэхийг шалгах ёстой. Хэрэв энэ нь бидний анхны тохиролцооноос давсан шинэ онцлог бол бид энэ функцийг ((ойролцоогоор хүлээн авах хугацаа + 30%) x 2) тооцоолж, үүнийг дуусгахад маш их цаг хугацаа шаардагдахыг хэрэглэгчдэд хэлэх ёстой. эцсийн хугацааг хоёроор үржүүлсэн тооцоолсон хугацаанд шилжүүлнэ. Даалгавраа илүү хурдан хийцгээе - гайхалтай, хүн бүр үүнээс л ашиг хүртэх болно. Үгүй бол бид даатгалд хамрагдана гэсэн үг.

в) Бид багт юуг хүлээн зөвшөөрдөггүй вэ:

  • Тогтворгүй байдал, уялдаа холбоогүй байдал, мартамхай байдал
  • "Өглөөний цайгаар хооллох". Хэрэв та даалгавраа хийж чадахгүй бол яаж хийхээ мэдэхгүй байгаа бол энэ талаар багийн ахлагчдаа нэн даруй мэдэгдэх хэрэгтэй бөгөөд сүүлчийнх хүртэл хүлээх хэрэггүй.
  • Бровада, чадвар, мэргэжлийн ур чадвараа үйл ажиллагаагаар нотолж амжаагүй хүнээс сайрхаж байна. Хэрэв нотлогдвол ёс суртахууны хүрээнд боломжтой 🙂
  • Бүх илрэлээрээ луйвар. Хэрэв даалгавар дуусаагүй бол түүний статусыг дууссан гэж өөрчлөх ёсгүй бөгөөд бэлэн болсон гэж үйлчлүүлэгчийн чат руу бичээрэй. Компьютер эвдэрсэн, систем эвдэрсэн, нохой зөөврийн компьютерээ зажилсан - энэ бүхэн хүлээн зөвшөөрөгдөхгүй. Бодит давагдашгүй хүчин зүйл тохиолдвол багийн даргад нэн даруй мэдэгдэх ёстой.
  • Мэргэжилтэн байнга офлайн байдаг бөгөөд ажлын цагаар түүнтэй холбогдоход хэцүү байдаг.
  • Багийн дотор хордлого хийхийг хориглоно! Хэрвээ хэн нэг нь санал нийлэхгүй байгаа бол бүгд цуглаад жагсаал цуглаан хийж, хэлэлцээд шийддэг.

Бүх үл ойлголцлыг арилгахын тулд үйлчлүүлэгчээсээ заримдаа асуудаг хэд хэдэн асуулт / дипломууд:

  1. Таны чанарын шалгуур юу вэ?
  2. Төсөлд асуудал байгаа эсэхийг яаж тодорхойлох вэ?
  3. Системийг өөрчлөх/сайжруулах талаарх бидний бүх зөвлөмж, зөвлөмжийг зөрчиж, бүх эрсдлийг зөвхөн та өөрөө хариуцна.
  4. Төслийн аливаа томоохон өөрчлөлт (жишээлбэл, бүх төрлийн нэмэлт урсгал) нь алдаа гарч болзошгүй (мэдээж бид үүнийг засах болно)
  5. Төсөл дээр ямар асуудал гарсныг хэдхэн минутын дотор ойлгох боломжгүй, тэр ч байтугай үүнийг засах боломжгүй юм.
  6. Бид тодорхой бүтээгдэхүүний урсгал дээр ажилладаг (Zhira дахь даалгавар - Хөгжүүлэлт - Туршилт - Байршуулах). Энэ нь бид чат дахь бүх хүсэлт, гомдлын урсгалд хариу өгөх боломжгүй гэсэн үг юм.
  7. Программистууд бол мэргэжлийн шалгагч биш зүгээр л програмистууд бөгөөд төслийн туршилтын зохих чанарыг хангаж чадахгүй
  8. Эцсийн туршилт, борлуулалтын даалгаврыг хүлээн авах хариуцлага нь бүхэлдээ танд хамаарна
  9. Хэрэв бид аль хэдийн даалгавраа авсан бол одоо байгаа ажлыг дуусгах хүртлээ бусад руу шууд шилжих боломжгүй (эс тэгэхгүй бол энэ нь илүү олон алдаа гарч, боловсруулах хугацааг нэмэгдүүлэх болно)
  10. Багийн гишүүд цөөхөн байна (амралт эсвэл өвчний улмаас), ажил их байгаа тул бид таны хүссэн бүх зүйлд хариу өгөх цаг зав гарахгүй.
  11. Хөгжүүлэгч дээр туршсан даалгаваргүйгээр үйлдвэрлэлд нэвтрүүлэхийг хүсэх нь зөвхөн таны эрсдэл болохоос хөгжүүлэгчийнх биш
  12. Хэрэв та бүдэг бадаг даалгавруудыг зөв урсгалгүй, дизайн хийлгүйгээр хийх юм бол энэ нь биднээс илүү их хүчин чармайлт, хэрэгжүүлэх хугацаа шаарддаг, учир нь бид таны оронд нэмэлт ажил хийх ёстой.
  13. Алдаатай холбоотой аливаа даалгавар, тэдгээрийн гарал үүсэл, дэлгэцийн агшинг нарийвчлан тайлбарлаагүй нь бидэнд юу буруу болсныг ойлгох боломжийг олгодоггүй бөгөөд бид энэ алдааг хэрхэн гаргаж болохыг ойлгох боломжийг олгодоггүй.
  14. Төсөл нь гүйцэтгэл, аюулгүй байдлыг сайжруулахын тулд байнгын сайжруулалт, сайжруулалтыг шаарддаг. Тиймээс баг зарим цагаа эдгээр сайжруулалтад зарцуулдаг.
  15. Бидэнд илүү цагаар ажилладаг (яаралтай засварууд) байгаа тул бусад өдрүүдэд нөхөн олговор олгох ёстой

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

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

Жич: Манай талд төслийн менежер байхгүй гэдгийг тодруулмаар байна. Энэ нь үйлчлүүлэгчийн талд байдаг. Ерөөсөө техникч биш. Европын төсөл. Бүх харилцаа холбоо зөвхөн англи хэл дээр байна.

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

миний эх сурвалж блог шуудан.

Эх сурвалж: www.habr.com