Хөөе Хабр!
Бидэнд шинэ чухал сэдэв бий - мэдээллийн технологийн бүтээгдэхүүний өндөр чанартай хөгжил. HighLoad++ дээр бид завгүй үйлчилгээг хэрхэн хурдан болгох талаар ихэвчлэн ярьдаг бол Frontend Conf дээр удаашруулдаггүй гайхалтай хэрэглэгчийн интерфэйсийн тухай ярьдаг. Бидэнд тестийн тухай, DevOpsConf-д тест зэрэг янз бүрийн процессуудыг нэгтгэх тухай сэдвүүд байнга гардаг. Гэхдээ ерөнхийдөө чанар гэж юу болох, үүн дээр хэрхэн иж бүрэн ажиллах талаар - үгүй.
Үүнийг засъя — Бид хөгжлийн үе шат бүрт хэрэглэгчдэд эцсийн бүтээгдэхүүний чанарын талаар бодох соёлыг төлөвшүүлнэ. Хариуцлагын салбартаа анхаарлаа хандуулдаггүй, чанарыг зөвхөн шалгагч нартай холбодог зуршил.
Тасалгааны доор бид хөтөлбөрийн хорооны дарга, Tinkoff.Business-ийн туршилтын дарга, орос хэлээр ярьдаг QA нийгэмлэгийг бүтээгчтэй ярилцах болно. Анастасия Асеева-Нгуен QA салбарын байдал, шинэ хурлын эрхэм зорилгын талаар.
- Настя сайн уу. Та өөрийнхөө тухай яриач.
Анастасия: Би банкинд шалгалтыг удирддаг бөгөөд маш том багийг хариуцдаг—бид 90 гаруй хүн. Бидэнд бизнесийн чухал чиглэл бий, бид хуулийн этгээдийн экосистемийг хариуцдаг.
Би механик, математикийн чиглэлээр суралцаж, анх программист болохыг хүсдэг байсан. Гэхдээ сонирхолтой санал ирэхэд би өөрийгөө шалгагчаар туршиж үзэхээр шийдсэн. Хачирхалтай нь энэ миний дуудлага байсан юм. Одоо би энэ салбар дахь бүх ажлаа харж байна.
Би Чанарын баталгааны сахилга батыг тууштай баримталдаг хүн. Би ямар бүтээгдэхүүн бий болох, компани, хамт олон, зарчмын хувьд хөгжлийн явцад чанарт хэрхэн хандах талаар санаа тавьдаг.
Энэ нь надад ойлгомжтой Энэ чиглэлд нийгэм хангалттай төлөвшөөгүй байна, наад зах нь Орост. Чанарын баталгаа нь зөвхөн өргөдлийг шаардлагад нийцэж байгаа эсэхийг шалгах явдал биш гэдгийг бид тэр бүр ойлгодоггүй. Би энэ байдлыг өөрчлөхийг хүсэж байна.
— Та Чанарын баталгаа, тест гэдэг үгийг ашигладаг. Энгийн хүмүүсийн нүдээр энэ хоёр нэр томъёо нь ихэвчлэн давхцдаг. Хэрэв та гүн ухвал тэд юугаараа ялгаатай вэ?
Анастасия: Үүний оронд тэд ялгаатай биш юм. Туршилт нь Чанарын баталгаажуулалтын сахилга батын нэг хэсэг бөгөөд энэ нь шууд үйл ажиллагаа юм - би ямар нэг зүйлийг туршиж байгаа нь өөрөө юм. Үнэн хэрэгтээ маш олон төрлийн сорил байдаг бөгөөд янз бүрийн төрлийн сорилтыг янз бүрийн хүмүүс хариуцдаг. Гэхдээ энд Орост компаниудад шалгагч нийлүүлдэг аутсорсеруудын давалгаа гарч ирэхэд туршилтыг нэг төрөл болгон бууруулсан.
Ихэнх тохиолдолд тэдгээр нь зөвхөн функциональ туршилтаар хязгаарлагддаг: хөгжүүлэгчид кодчилсон зүйл нь техникийн үзүүлэлтэд нийцэж байгаа эсэхийг шалгадаг.
— Чанарын баталгаажуулалтын өөр ямар салбар байдаг талаар хэлж өгнө үү? Туршилтаас гадна энд юу багтсан бэ?
Анастасия: Чанарын баталгаа гэдэг нь юуны түрүүнд чанартай бүтээгдэхүүн бий болгох явдал юм. Өөрөөр хэлбэл, манай бүтээгдэхүүн ямар чанарын шинж чанартай байх ёстойг өөрөөсөө асуудаг. Үүний дагуу, хэрэв бид үүнийг ойлговол эдгээр чанарын шинж чанаруудад хэн нөлөөлж байгааг харьцуулж болно. хамаагүй, хөгжүүлэгч, төслийн менежер эсвэл бүтээгдэхүүний мэргэжилтэн Бүтээгдэхүүний хөгжил, түүний хоцрогдол, стратегид нөлөөлдөг хүн юм.
Туршилтын хүн өөрийнхөө үүргийг илүү ухамсарладаг. Түүний даалгавар бол зөвхөн шаардлагад нийцэж байгаа эсэхийг шалгахаас гадна шаардлагуудыг турших, бүтээгдэхүүний мэргэжилтэнээс ирсэн найрлагад эргэлзэх, үйлчлүүлэгчийн бүх далд шаардлага, хүлээлтийг илчлэх явдал гэдгийг тэрээр ойлгодог. Бид хэрэглэгчдэдээ шинэ функцийг хүргэхдээ тэдний хүлээлтийг бодитоор хангаж, зовлонг нь шийдэх ёстой. Хэрэв бид чанарын бүх шинж чанаруудын талаар бодох юм бол үйлчлүүлэгч сэтгэл хангалуун байх бөгөөд бүтээгдэхүүнээ ашигладаг компани нь түүний ашиг сонирхлыг үнэхээр анхаарч үздэг бөгөөд "зүгээр л нэг онцлог шинж чанар" гэсэн зарчмаар ажилладаггүй гэдгийг ойлгох болно.
- Таны сая дурдсан зүйл бол бүтээгдэхүүний мэргэжилтний үүрэг байх шиг байна. Энэ нь зарчмын хувьд туршилтын тухай биш, чанарын тухай биш - ерөнхийдөө бүтээгдэхүүний менежментийн тухай юм, тийм үү?
Анастасия: Үүнд. Чанарын баталгаа нь тодорхой нэг хүн хариуцдаг сахилга бат биш юм. Одоо туршилтын түгээмэл чиглэл гэж нэрлэгддэг арга байдаг Agile тест. Түүний тодорхойлолтод энэ нь тодорхой багц туршлагуудыг багтаасан туршилтын багийн арга барил гэдгийг тодорхой заасан байдаг. Бүхэл бүтэн баг энэ хандлагыг хэрэгжүүлэх үүрэгтэй бөгөөд багт шалгагч байх албагүй. Бүхэл бүтэн баг нь үйлчлүүлэгчдэд үнэ цэнийг хүргэх, үнэ цэнэ нь хэрэглэгчийн хүлээлтийг хангахад чиглэгддэг.
- Чанар нь эргэн тойрныхоо бараг бүх салбартай огтлолцож, эргэн тойрон дахь бүх зүйлд хүрээ ногдуулдаг гэж харагдаж байна?
Анастасия: Зөв. Чанартай бүтээгдэхүүн бүтээхийг хүсч байгаа тухай бодохдоо бид чанарын өөр өөр шинж чанаруудын талаар бодож эхэлдэг. Жишээлбэл, бид үйлчлүүлэгчдээ хэрэгтэй функцийг үнэхээр хийсэн эсэхийг хэрхэн шалгах вэ.
Энэ төрлийн шалгалт эндээс ирдэг: УАТ (хэрэглэгчийг хүлээн зөвшөөрөх туршилт). Харамсалтай нь энэ нь Орост ховор хэрэглэгддэг боловч заримдаа SCRUM багуудад эцсийн үйлчлүүлэгчдэд зориулсан демо хэлбэрээр байдаг. Энэ бол гадаадын компаниудад нэлээд түгээмэл туршилтын төрөл юм. Бүх хэрэглэгчдэд функцийг нээхээс өмнө бид эхлээд UAT хийдэг, өөрөөр хэлбэл, бид эцсийн хэрэглэгчийг туршиж үзэхийг урьж, бүтээгдэхүүн үнэхээр хүлээлтийг хангаж, өвдөлтийг арилгаж байгаа эсэх талаар санал хүсэлтээ шууд өгөхийг урьж байна. Үүний дараа л бусад бүх үйлчлүүлэгчид рүү шилжих боломжтой.
Өөрөөр хэлбэл, бид бизнест, эцсийн үйлчлүүлэгчид анхаарлаа төвлөрүүлдэг, гэхдээ нэгэн зэрэг технологийн талаар бүү мартаарай. Бүтээгдэхүүний чанар нь технологиос ихээхэн хамаардаг. Хэрэв бид муу архитектуртай бол функцуудыг хурдан гаргаж, хэрэглэгчийн хүлээлтийг хангах боломжгүй болно. Томруулах оролдлого, эсвэл дахин засварлах гэж оролдох үед бид ямар нэг зүйлийг эвдэж болзошгүй. Энэ бүхэн нь хэрэглэгчийн сэтгэл ханамжид нөлөөлнө.
Энэ үүднээс авч үзвэл архитектур нь бид бүх зүйлийг эвдэхээс айхгүй, хурдан өөрчлөлт хийх боломжийг олгодог цэвэр код бичих боломжтой байх ёстой. Бидэнд маш их өв залгамжлал байгаа учраас засварын давталт хэдэн сарын турш үргэлжлэхгүй байхын тулд бид урт хугацааны туршилтын үе шатуудыг хийх хэрэгтэй.
- Нийтдээ хөгжүүлэгчид, архитекторууд, бүтээгдэхүүний эрдэмтэд, бүтээгдэхүүний менежерүүд, шалгагчид өөрсдөө аль хэдийн хамрагдсан. Чанарын баталгаажуулалтын үйл явцад өөр хэн оролцдог вэ?
Анастасия: Одоо бид энэ функцийг аль хэдийн үйлчлүүлэгчид хүргэсэн гэж төсөөлөөд үз дээ. Бүтээгдэхүүнийг үйлдвэрлэж эхэлсэн ч чанарт нь хяналт тавих шаардлагатай нь ойлгомжтой. Энэ үе шатанд алдаа гэж нэрлэгддэг тодорхой бус хувилбарууд гарч ирж болно.
Эхний асуулт бол бид бүтээгдэхүүнийг аль хэдийн гаргасны дараа эдгээр алдаануудыг хэрхэн шийдвэрлэх вэ? Жишээлбэл, бид стресст хэрхэн хариу үйлдэл үзүүлдэг вэ? Хуудсыг ачаалахад 30 секундээс илүү хугацаа зарцуулагдсан тохиолдолд үйлчлүүлэгч тийм ч их баярлахгүй.
Эндээс л мөлжлөг буюу одоогийнх нь нэрлэж заншсанаар. DevOps. Үнэн хэрэгтээ эдгээр нь бүтээгдэхүүнийг аль хэдийн үйлдвэрлэж байгаа үед ажиллуулах үүрэгтэй хүмүүс юм. Үүнд янз бүрийн төрлийн мониторинг орно. Туршилтын нэг дэд төрөл байдаг - үйлдвэрлэл дээр туршилт, бид өөрсдийгөө ямар нэг зүйлийг гаргахаас өмнө туршихгүй байх боломжийг олгодог бөгөөд тэр даруй үйлдвэрлэл дээр туршиж үздэг. Энэ бол аливаа хэрэг явдалд түргэн шуурхай хариу арга хэмжээ авах, нөлөөлөх, засч залруулах боломжийг олгодог дэд бүтцийг зохион байгуулах үүднээс авч хэрэгжүүлсэн цуврал арга хэмжээ юм.
Дэд бүтэц бас чухал. Туршилтын үеэр үйлчлүүлэгчид өгөхийг хүссэн бүх зүйл бидэнд үнэхээр байгаа эсэхийг шалгах боломжгүй нөхцөл байдал ихэвчлэн тохиолддог. Бид үүнийг үйлдвэрлэлд нэвтрүүлж, тодорхой бус нөхцөл байдлыг барьж эхэлдэг. Туршилтын дэд бүтэц нь үйлдвэрлэлийн дэд бүтэцтэй тохирохгүй байгаатай холбоотой. Энэ нь шинэ төрлийн сорилтод хүргэдэг - дэд бүтцийн туршилт. Үүнд төрөл бүрийн тохиргоо, тохиргоо, мэдээллийн баазын шилжүүлэг гэх мэт орно.
Эндээс асуулт гарч ирнэ - магадгүй баг дэд бүтцийг код болгон ашиглах шаардлагатай байж магадгүй юм.
Дэд бүтэц нь бүтээгдэхүүний чанарт шууд нөлөөлдөг гэдэгт би итгэдэг.
Чуулган дээр бодит хэрэг бүхий илтгэл гарах байх гэж найдаж байна. Кодын дэд бүтэц чанарт хэрхэн нөлөөлдөг талаар өөрийн туршлагаас ярихад бэлэн байгаа бол бидэнд бичээрэй. Дэд бүтэц нь код нь бүх тохиргоог шалгах, өөрөөр хийх боломжгүй зүйлсийг шалгахад хялбар болгодог. Тиймээс үйл ажиллагаа нь чанартай бүтээгдэхүүн боловсруулах үйл явцад оролцдог.
- Аналитик, баримтжуулалтын талаар юу хэлэх вэ?
Анастасия: Энэ нь байгууллагын системд илүү хамаатай. Бизнесийн тухай ярихад шинжээч, системийн шинжээч зэрэг хүмүүс шууд санаанд орж ирдэг. Тэднийг заримдаа техникийн зохиолч гэж нэрлэдэг. Тэд техникийн тодорхойлолт бичиж, жишээлбэл, нэг сарын турш дуусгах даалгавар авдаг.
Ийм баримт бичгийг бичих нь маш урт хөгжүүлэлтийн давталт, сайжруулалтын урт давталтад хүргэдэг нь олон удаа нотлогдсон, учир нь туршилтын явцад алдаанууд илэрч, буцаж ирдэг. Үүний үр дүнд бүтээн байгуулалтын зардлыг нэмэгдүүлдэг олон гогцоо байдаг. Үүнээс гадна энэ нь эмзэг байдлыг үүсгэж болзошгүй. Бид лавлагаа код бичсэн юм шиг санагдаж байна, гэхдээ дараа нь бид төгс бодож боловсруулсан архитектурыг эвдсэн өөрчлөлтүүдийг хийсэн.
Үүний үр дүнд үр дүн нь тийм ч өндөр чанартай бүтээгдэхүүн биш юм, учир нь засварууд нь архитектурт аль хэдийн гарч ирсэн тул зарим газар код нь туршилтаар хангалттай хамрагдаагүй, учир нь эцсийн хугацаа дуусч байгаа тул бүх алдааг хурдан хаах хэрэгтэй. Анхны тодорхойлолт нь хэрэгжүүлэх шаардлагатай бүх зүйлийг анхаарч үзээгүй тул бүх зүйл.
Хөгжүүлэгчид хортон шавьж биш бөгөөд санаатайгаар алдаатай код бичдэггүй.
Хэрэв бид эхлээд шаардлагатай бүх зүйлийг багтаасан тодорхойлолтыг сайтар бодож үзсэн бол бүх зүйл яг шаардлагатай хэмжээгээр хэрэгжих байсан. Гэхдээ энэ бол утопи юм.
100 хуудастай төгс тодорхойлолт бичих боломжгүй байх. Тийм ч учраас баримт бичиг бичих өөр аргуудын талаар бодох хэрэгтэй, техникийн үзүүлэлтүүд, даалгаврын мэдэгдлүүд нь хөгжүүлэгч яг хэрэгтэй зүйлийг хийх боломжийг бидэнд ойртуулах болно.
Эндээс Agile арга барил санаанд орж ирдэг—хүлээн авах шалгуур бүхий хэрэглэгчийн түүхүүд. Энэ нь жижиг давталтаар хөгжиж буй багуудад илүү тохиромжтой.
— Хэрэглэх чадварын туршилт, бүтээгдэхүүний ашиглалт, дизайны талаар юу хэлэх вэ?
Анастасия: Энэ бол маш чухал зүйл, учир нь багт дизайнерууд байдаг. Ихэнх тохиолдолд дизайнеруудыг дизайны хэлтэс эсвэл аутсорсинг дизайнер үйлчилгээ болгон ашигладаг. Загвар зохион бүтээгч нь бүтээгдэхүүний эрдэмтний үгийг сонсож, ойлгосон зүйлээ хийсэн мэт нөхцөл байдал ихэвчлэн байдаг. Гэхдээ бид давталт хийж эхлэхэд бодитоор хийсэн зүйл нь хүлээгдэж буй зүйл биш болох нь харагдаж байна: дизайнер ямар нэг зүйлийг мартсан, зан төлөвийг бүрэн бодож амжаагүй, учир нь тэр багт ороогүй, контекст, эсвэл урд талд байгаагүй. -Төгсгөлийн хөгжүүлэгч түүний зохион байгуулалтыг бүрэн ойлгоогүй байна. Урд талын хөгжүүлэгчийн дизайны талаархи ойлголттой холбоотой асуудал гарсан тул хэд хэдэн давталт шаардлагатай байж магадгүй юм.
Дээрээс нь бас нэг асуудал байна. Дизайн системүүд одоо түгээмэл болж байна. Тэд шуугиан тарьж байгаа ч тэдний ашиг тус нь тийм ч тодорхой биш юм.
Дизайн систем нь нэг талаас хөгжлийг хялбаршуулдаг боловч нөгөө талаас интерфейс дээр маш их хязгаарлалт тавьдаг гэсэн үзэл бодолтой тулгарч байна.
Үүний үр дүнд бид үйлчлүүлэгчийн хүссэн функцийг хийдэггүй, харин бидэнд тохиромжтой зүйлийг хийдэг, учир нь бид үүнийг хийх боломжтой тодорхой шоо дөрвөлжин хэлбэртэй байдаг.
Энэ сэдэвт анхаарлаа хандуулж, дизайны ажлыг хялбарчлах оролдлого нь үйлчлүүлэгчийн зовлонг үнэхээр шийдэж байна уу гэж бодож байна.
- Чанарын баталгаатай холбоотой гайхалтай олон сэдэв бий. Орост бүгдийг нь хэлэлцэх хурал байдаг юм уу?
Анастасия: Энэ жил 25 дахь удаагаа зохион байгуулагдаж буй сорилтын хамгийн эртний хурал байдаг бөгөөд Чанарын баталгаажуулалтын бага хурал SQA өдрүүд гэж нэрлэгддэг. Энэ нь голчлон функциональ шалгагчдад зориулсан багаж хэрэгсэл, тусгай туршилтын аргуудыг хэлэлцдэг. Дүрмээр бол SQA Days-ийн тайлангууд нь нарийн төвөгтэй үйл ажиллагаа биш харин шалгагчдын өөрсдийнх нь хариуцлагын хүрээнд тодорхой чиглэлүүдийг гүнзгий судалж үздэг.
Энэ нь янз бүрийн арга хэрэгсэл, хандлагыг ойлгох, мэдээллийн сан, API-г хэрхэн шалгах гэх мэтийг ойлгоход ихээхэн тусалдаг. Гэхдээ үүнтэй зэрэгцэн, нэг талаас, энэ нь илүү сайн бүтээгдэхүүн бий болгоход зөвхөн туршилтаас илүү оролцохыг өдөөдөггүй. Нөгөөтэйгүүр, туршигчид бүтээгдэхүүний дэлхийн зорилго, түүний бизнесийн бүрэлдэхүүн хэсгийн талаар бодох үйл явцад илүү их оролцдоггүй.
Би томоохон хэлтсийг удирдаж, олон ярилцлага хийдэг бөгөөд энэ нь салбарын байдлыг бүхэлд нь ойлгох боломжийг олгодог. Дүрмээр бол манай залуус аж ахуйн нэгжид ажилладаг бөгөөд тэдний хариуцлагын тодорхой хэсэг байдаг. Гадаадын төслүүдэд ажилладаг хамт олон янз бүрийн төрлийн туршилтыг ашигладаг: тэд өөрсдөө ачааллын туршилт, гүйцэтгэлийн туршилт, тэр ч байтугай заримдаа аюулгүй байдлын тест хийх боломжтой, учир нь тэд багийнханд бүтээгдэхүүний чанарыг баталгаажуулахад үнэхээр тусалдаг.
Орос дахь залуус ч энэ салбар нь функциональ туршилтаар дуусдаггүй тухай бодож эхлэхийг хүсч байна.
— Энэ зорилгын үүднээс бид чанарын салшгүй салбар болох QualityConf хэмээх шинэ хурлыг зохион байгуулж байна. Санаагаа дэлгэрэнгүй ярина уу, чуулганы гол зорилго юу вэ?
Анастасия: Бид чанартай бүтээгдэхүүн үйлдвэрлэх сонирхолтой хүмүүсийн нийгэмлэгийг бий болгохыг хүсэж байна. Тэд ирж, тайлан сонсож, чанарыг сайжруулахын тулд юуг өөрчлөх шаардлагатай талаар тодорхой ойлголттойгоор чуулганыг орхиж болох платформыг санал болго.
Туршилт, чанарт асуудал гарвал яах вэ гэсэн хүсэлтийг өнөөдөр би байнга сонсдог. Багуудтай харилцаж эхлэхэд асуудал нь шалгагчид өөрсдөө биш, харин үйл явцын бүтэц зохион байгуулалтад байгаа гэдгийг та харж байна. Жишээлбэл, хөгжүүлэгчид зөвхөн код бичих үүрэгтэй гэж үзвэл тэдний үүрэг даалгаварыг тест рүү шилжүүлэх тэр мөчид л дуусна.
Муу бичигдсэн, муу архитектуртай, чанар муутай код нь төслийн томоохон асуудалд аюул учруулдаг гэдгийг хүн бүр боддоггүй. Тэд алдааны зардлын талаар боддоггүй бөгөөд үйлдвэрлэлд дуусдаг алдаа нь компани болон багийн хувьд их хэмжээний зардалд хүргэж болзошгүй юм. Энэ талаар бодох соёл алга. Чуулган дээр тарааж эхэлмээр байна.
Энэ бол инноваци биш гэдгийг би ойлгож байна.Чанарын 14 зарчмын зохиогч Эдвард Деминг өнгөрсөн зуунд алдааны үнэ цэнийн талаар бичсэн байдаг. Чанарын баталгаа нь сахилга батын хувьд энэ ном дээр үндэслэсэн боловч харамсалтай нь орчин үеийн хөгжил үүнийг мартдаг.
- Та туршилт, багаж хэрэгслийн талаар шууд ярихаар төлөвлөж байна уу?
Анастасия: Багаж хэрэгслийн талаар тайлан гарах болно гэдгийг би хүлээн зөвшөөрч байна. Компаниуд болон багууд бүтээгдэхүүнд нөлөөлж чадах бүх нийтийн хэрэгсэл байдаг.
Энэхүү арга, хэрэгсэл, арга, үйл явц, туршилтын төрлүүдийн тусламжтайгаар бид бүтээгдэхүүний чанарт нөлөөлж, үйлчлүүлэгчийн амьдралыг дээшлүүлсэн гэдгийг үзэгчдэд хүргэх гэсэн нийтлэг зорилго бүхий бүх тайланг дэлхий даяар нэгтгэх болно.
Бидэнд ямар нэгэн хэрэглүүрийн төлөө ямар нэгэн хэрэгслийн талаар мэдээлэхгүй нь гарцаагүй. Хөтөлбөрт багтсан бүх тайланг нэг зорилгод нэгтгэнэ.
-Чуулганы зочноор хэнийг харж байгаа, юу ярьж байгааг хэн сонирхох вэ?
Анастасия: Бид өөрсдийн төсөл, бүтээгдэхүүн, системийн хувь заяанд санаа тавьдаг хөгжүүлэгчдэд зориулсан тайлантай байх болно. Үүний нэгэн адил энэ нь тестерүүд болон миний бодлоор, ялангуяа менежерүүдэд сонирхолтой байх болно. Менежер гэж би шийдвэр гаргадаг, бүтээгдэхүүн, систем, багийн хувь заяа, хөгжилд нөлөөлж чадах хүмүүсийг хэлж байна.
Эдгээр нь бүтээгдэхүүн, системийн чанарыг хэрхэн сайжруулах талаар гайхдаг хүмүүс юм. Манай бага хурлаар тэд янз бүрийн арга хэмжээний талаар суралцаж, одоо юу нь болохгүй байгаа, юуг өөрчлөх шаардлагатай байгааг ойлгох болно.
Чанарт ямар нэг зүйл буруу байна гэдгийг ойлгож, түүнд нөлөөлөхийг хүсч байгаа нь гол шалгуур гэж бодож байна. Бид үүнийг анх удаа хийнэ гэж бодож байгаа хүмүүст хүрч чадахгүй байх.
-Таны бодлоор энэ салбар бүхэлдээ зөвхөн туршилтын тухай биш, харин чанарын соёлын тухай ярихад бэлэн байна уу?
Анастасия: Би өөрийгөө төлөвшсөн гэдэгт итгэж байна. Одоо олон компаниуд уламжлалт хүрхрээ арга барилаас Agile руу шилжиж байна. Үйлчлүүлэгчид анхаарлаа хандуулж, багийн хүмүүс хэрхэн чанартай бүтээгдэхүүн бүтээх талаар үнэхээр бодож эхэлж байна. Аж ахуйн нэгжийн компаниуд хүртэл чанарыг сайжруулахад анхаарлаа хандуулж байна.
Нийгэмд ирж буй хүсэлтийн тооноос харахад цаг нь болсон гэж үзэж байна. Мэдээжийн хэрэг, энэ нь том хэмжээний хувьсгал болно гэдэгт би итгэлгүй байна, гэхдээ би ухамсарт энэ хувьсгал хийхийг хүсч байна.
- Зөвшөөрч байна! Бид соёлыг суулгаж, ухамсарыг өөрчилнө.
Мэдээллийн технологийн бүтээгдэхүүний өндөр чанартай хөгжилд зориулсан бага хурал болох болно 7-р сарын XNUMX-нд Москвад. Өндөр чанартай бүтээгдэхүүнийг ямар үе шатуудаар бүрдүүлдэгийг та мэднэ, бид үйлдвэрлэлийн алдаатай амжилттай тэмцэж байсан тохиолдол байдаг, бид өөрсдийн практикт түгээмэл аргуудыг туршиж үзсэн - бидэнд таны туршлага хэрэгтэй байна. тэдний 1-р сарын XNUMX хүртэл өргөдөл гаргана, мөн Хөтөлбөрийн хороо нь чуулганы нэгдсэн нэгдмэл байдлын сэдвийг төвлөрүүлэхэд тусална.
Холбогдох , Бид чанарын асуудал болон бага хурлыг хэлэлцэх бөгөөд бүртгүүлэх хөтөлбөрийн мэдээг цаг тухайд нь авч байх.
Эх сурвалж: www.habr.com