Тим Листер - номын хамтран зохиогч
- "Хүний хүчин зүйл. Амжилттай төслүүд ба багууд" (эх номыг "Peopleware" гэж нэрлэдэг)
- "Баавгайтай вальс тоглох нь: Програм хангамжийн төслийн эрсдэлийг удирдах нь"
- “Адреналинд автаж, хээ угалзаараа зомбижсон. Төслийн багуудын зан үйлийн хэв маяг"
Эдгээр номууд бүгд салбартаа сонгодог бүтээлүүд бөгөөд хамт олонтойгоо хамтран бичсэн . Орос улсад түүний хамтран ажиллагсад хамгийн алдартай - и , мөн олон алдартай бүтээл туурвисан.
Тим програм хангамж хөгжүүлэлтийн чиглэлээр 40 жилийн туршлагатай; 1975 онд (энэ habrapost-ийг бичсэн хүмүүсийн хэн нь ч энэ жил төрөөгүй) Тим аль хэдийн Yourdon Inc-ийн гүйцэтгэх дэд ерөнхийлөгч байсан. Тэрээр одоо цаг заваа зөвлөгөө өгөх, зааж сургах, бичихэд зарцуулж, хааяа очиж уулздаг дэлхий даяар бага хурал.
Бид Тим Листертэй тусгайлан Хабрд зориулж ярилцлага хийсэн. Тэрээр DevOops 2019 чуулганыг нээх бөгөөд бидэнд ном болон бусад олон асуулт байна. Ярилцлагыг хурлын хөтөлбөрийн хорооноос Михаил Дружинин, Олег Чирухин нар хийж байна.
Майкл: Одоо хийж байгаа зүйлийнхээ талаар хэдэн үг хэлэхгүй юу?
Тим: Би Atlantic Systems Guild-ийн тэргүүн. Гильд бид зургаа байдаг, бид өөрсдийгөө захирал гэж нэрлэдэг. Гурав нь АНУ-д, гурав нь Европт - тийм ч учраас Гильдийг Атлантын далай гэж нэрлэдэг. Бид маш олон жил хамт байсан тул тоолж баршгүй. Бид бүгдээрээ өөрийн гэсэн онцлогтой. Би сүүлийн арав ба түүнээс дээш жил үйлчлүүлэгчидтэй ажиллаж байна. Миний төслүүдэд зөвхөн менежмент төдийгүй шаардлага тавих, төслийн төлөвлөлт, үнэлгээ багтдаг. Муу эхэлсэн төслүүд ихэвчлэн муу дуусдаг юм шиг санагддаг. Тиймээс, бүх үйл ажиллагаа нь үнэхээр сайн бодож, зохицуулагдсан, бүтээгчдийн санааг нэгтгэсэн эсэхийг шалгах нь зүйтэй. Юу хийж, яагаад хийж байгаагаа бодох нь зүйтэй. Төслийг дуусгахын тулд ямар стратеги ашиглах вэ.
Би олон жилийн турш үйлчлүүлэгчдэд янз бүрийн арга замаар зөвлөгөө өгсөн. Сонирхолтой жишээ бол өвдөг, түнхний мэс засалд зориулсан робот үйлдвэрлэдэг компани юм. Мэс засалч бүрэн бие даан ажилладаггүй, харин робот ашигладаг. Энд ний нуугүй хэлэхэд аюулгүй байдал чухал. Гэхдээ асуудлыг шийдвэрлэхэд анхаарлаа төвлөрүүлж буй хүмүүстэй шаардлага хэлэлцэх гэж оролдоход ... Энэ нь хачирхалтай сонсогдох боловч АНУ-д байдаг. (Холбооны Эмийн Захиргаа) нь эдгээр роботууд шиг бүтээгдэхүүний лицензийг олгодог. Аливаа зүйлийг зарж, амьд хүмүүст хэрэглэхээсээ өмнө лиценз авах хэрэгтэй. Үүний нэг нөхцөл нь таны шаардлага, ямар шалгалт байгаа, хэрхэн туршиж үзсэн, шинжилгээний хариу ямар байгааг харуулах явдал юм. Хэрэв та шаардлагуудыг өөрчилвөл энэ том туршилтын процессыг дахин дахин давах хэрэгтэй. Манай үйлчлүүлэгчид өөрсдийн шаардлагад хэрэглээний визуал дизайныг оруулж чадсан. Тэд шаардлагын нэг хэсэг болгон шууд дэлгэцийн агшинтай байсан. Бид тэдгээрийг сугалж аваад, ихэнх тохиолдолд эдгээр бүх програмууд өвдөг, ташааны талаар юу ч мэддэггүй, камертай холбоотой бүх зүйл гэх мэтийг тайлбарлах ёстой. Бид шаардлагын баримт бичгүүдийг дахин бичих хэрэгтэй бөгөөд ингэснээр зарим нэг чухал суурь нөхцөл өөрчлөгдөхгүй бол тэдгээр нь хэзээ ч өөрчлөгдөхгүй. Хэрэв харааны дизайн шаардлагад нийцэхгүй бол бүтээгдэхүүнийг шинэчлэх нь илүү хурдан байх болно. Бидний ажил бол өвдөг, хонго, нурууны мэс засалд хамаарах элементүүдийг олж, тэдгээрийг тусад нь баримт бичиг болгон гаргаж, эдгээр нь үндсэн шаардлага байх болно гэж хэлэх явдал юм. Өвдөгний үений мэс заслын талаар тусгаарлагдсан бүлэг шаардлагуудыг хийцгээе. Энэ нь бидэнд илүү тогтвортой шаардлагуудыг бий болгох боломжийг олгоно. Бид тодорхой роботуудын тухай биш харин бүхэл бүтэн бүтээгдэхүүний талаар ярих болно.
Маш их ажил хийгдсэн боловч цаасан дээр дурдсан шаардлагууд нь системийг бий болгосон бодит шаардлагад нийцэхгүй байсан тул өмнө нь долоо хоног, сараар давтан туршилтыг утга учиргүй, шаардлагагүй өнгөрөөсөн газруудад очсон хэвээр байна. FDA тэдэнд: Таны шаардлага өөрчлөгдсөн, одоо та бүгдийг эхнээс нь шалгах хэрэгтэй гэж хэлдэг. Бүхэл бүтэн бүтээгдэхүүнийг бүрэн дахин шалгах нь аж ахуйн нэгжийг устгаж байв.
Тиймээс, ямар нэгэн сонирхолтой зүйлийн эхэнд өөрийгөө олох үед ийм гайхалтай даалгавар байдаг бөгөөд хамгийн эхний үйлдлүүд нь тоглоомын цаашдын дүрмийг тогтоодог. Хэрэв та энэхүү эхний үйл ажиллагаа нь менежментийн болон техникийн аль алиных нь талаас сайн ажиллаж эхлэх юм бол гайхалтай төсөлтэй болох магадлал өндөр байна. Гэхдээ хэрэв энэ хэсэг замаасаа гарч, буруу тийшээ явсан бол, хэрэв та үндсэн хэлэлцээрүүдийг олж чадахгүй бол ... үгүй, энэ нь таны төсөл заавал бүтэлгүйтэх болно гэсэн үг биш юм. Гэхдээ та "Бид маш сайн ажилласан, бид бүх зүйлийг үнэхээр үр дүнтэй хийсэн" гэж хэлэх боломжгүй болно. Эдгээр нь үйлчлүүлэгчидтэй харилцахдаа миний хийдэг зүйлүүд юм.
Майкл: Өөрөөр хэлбэл, та төслүүдээ эхлүүлж, ямар нэг эхлэлийг тавьж, төмөр зам зөв чиглэлд явж байгаа эсэхийг шалгадаг уу?
Тим: Бидэнд оньсогоын бүх хэсгүүдийг хэрхэн нэгтгэх талаар санаанууд бий: бидэнд ямар ур чадвар хэрэгтэй вэ, яг хэзээ хэрэгтэй вэ, багийн цөм нь ямар байх ёстой гэх мэт бусад үндсэн зүйлс. Бидэнд бүтэн цагийн ажилтан хэрэгтэй юу эсвэл хэн нэгнийг хагас цагаар ажиллуулж болох уу? Төлөвлөлт, менежмент. Асуулт: Энэ төслийн хувьд хамгийн чухал нь юу вэ? Үүнд хэрхэн хүрэх вэ? Энэ бүтээгдэхүүн, төслийн талаар бид юу мэдэх вэ, ямар эрсдэлтэй, үл мэдэгдэх зүйл хаана байна, бид энэ бүхнийг хэрхэн даван туулах вэ? Мэдээжийн хэрэг, энэ үед хэн нэгэн "Agile яах вэ?!" гэж хашгирч эхэлнэ. За, та нар бүгд уян хатан байна, гэхдээ яах вэ? Төсөл яг ямар харагдаж байна, төсөлдөө тохирсон байдлаар яаж гаргах гэж байна вэ? Та зүгээр л "бидний арга барил юунд ч хамаатай, бид бол Scrum баг!" гэж хэлж болохгүй. Энэ бол утгагүй, дэмий зүйл. Дараа нь хаашаа явах гэж байна, яагаад ажиллах ёстой вэ, гол нь хаана байна? Би үйлчлүүлэгчиддээ эдгээр бүх асуултын талаар бодохыг заадаг.
19 жил авхаалж самбаатай
Майкл: Agile-д хүмүүс ихэвчлэн юу ч урьдчилан тодорхойлохгүй байхыг хичээдэг, гэхдээ аль болох оройтож шийдвэр гаргахыг хичээдэг: бид хэтэрхий том байна, би ерөнхий архитектурын талаар бодохгүй байна. Би өөр олон зүйлийн талаар бодохгүй, үүний оронд би яг одоо хэрэглэгчдэд тохирсон зүйлийг хүргэх болно.
Тим: -ээс эхлээд agile арга зүй гэж би боддог 2001 онд салбарынхны нүдийг нээсэн. Гэхдээ нөгөө талаас төгс төгөлдөр зүйл гэж байдаггүй. Би бүгд давтагдах хөгжлийн төлөө байна. Ихэнх төслүүдэд давталт нь маш их утга учиртай байдаг. Гэхдээ таны бодож үзэх ёстой асуулт бол бүтээгдэхүүн гарч, ашиглалтад орсны дараа хэр удаан үргэлжлэх вэ? Энэ нь өөр зүйлээр солигдохоос өмнө зургаан сарын хугацаатай бүтээгдэхүүн мөн үү? Эсвэл энэ олон жил ажиллах бүтээгдэхүүн үү? Мэдээжийн хэрэг, би нэрийг нь хэлэхгүй, гэхдээ ... Нью-Йорк болон түүний санхүүгийн нийгэмлэгт хамгийн суурь системүүд маш эртний байдаг. Энэ гайхалтай юм. Та тэднийг хараад, 1994 он руу буцаж очоод хөгжүүлэгчиддээ: "Би ирээдүйгээс ирсэн, 2019 оноос хойш ирсэн. Энэ системийг хүссэн үедээ л хөгжүүлээрэй. Үүнийг өргөтгөх боломжтой болго, архитектурын талаар бод. Дараа нь энэ нь хорин таван жил гаруйн хугацаанд сайжирна. Хэрэв та хөгжлийг жаахан хойшлуулбал хэн ч анзаарахгүй!" Та аливаа зүйлийг урт хугацаанд тооцохдоо нийтдээ хэдий хэмжээний зардал гарахыг тооцох хэрэгтэй. Заримдаа сайн зохион бүтээгдсэн архитектур үнэхээр үнэ цэнэтэй, заримдаа тийм биш юм. Бид эргэн тойрноо харж, өөрөөсөө асуух хэрэгтэй: ийм шийдвэр гаргахад бид зөв нөхцөл байдалд байна уу?
Тиймээс "Бид авхаалж самбаатай, үйлчлүүлэгч өөрөө юу авахыг хүсч байгаагаа бидэнд хэлэх болно" гэх мэт санаа бол үнэхээр гэнэн юм. Үйлчлүүлэгчид юу хүсч байгаагаа ч мэддэггүй бөгөөд үүнээс ч илүүтэйгээр тэд юу авахаа мэдэхгүй байна. Зарим хүмүүс түүхийн жишээг аргумент болгон дурдаж эхэлнэ, би үүнийг аль хэдийн харсан. Гэхдээ техникийн өндөр түвшний хүмүүс үүнийг ихэвчлэн хэлдэггүй. Тэд: "Энэ бол 2019 он, энэ бол бидэнд байгаа боломжууд бөгөөд бид эдгээр зүйлийг харах хандлагаа бүрэн өөрчилж чадна!" Одоо байгаа шийдлүүдийг дуурайж, тэднийг бага зэрэг гоёмсог, самнасан болгохын оронд заримдаа гарч ирээд: "Бид энд хийх гэж байгаа зүйлээ бүхэлд нь шинээр зохион бүтээцгээе!" гэж хэлэх хэрэгтэй.
Мөн ихэнх үйлчлүүлэгчид асуудлын талаар ингэж бодож чадахгүй гэж би бодож байна. Тэд өөрт байгаа зүйлээ л хардаг, тэгээд л тэр. Үүний дараа тэд "Үүнийг арай хялбар болгоё" гэх мэт хүсэлтүүд ирдэг, эсвэл тэд ихэвчлэн хэлдэг. Гэхдээ бид зөөгч, үйлчлэгч биш болохоор ямар ч тэнэг байсан ч захиалгаа аваад гал тогооны өрөөнд жигнэх боломжтой. Бид тэдний хөтөч. Бид тэдний нүдийг нээж хэлэх ёстой: хөөе, бидэнд шинэ боломжууд байна! Таны бизнесийн энэ хэсгийг бид үнэхээр өөрчилж чадна гэдгийг та ойлгож байна уу? Agile-ийн нэг бэрхшээл нь боломж гэж юу вэ, асуудал юу вэ, бид юу хийх ёстой вэ, энэ нөхцөл байдалд ямар технологи хамгийн тохиромжтой вэ гэсэн ойлголтыг арилгадаг явдал юм.
Магадгүй би энд хэтэрхий эргэлзэж байгаа байх: Agile нийгэмлэгт маш олон гайхалтай зүйл тохиолддог. Гэтэл хүмүүс төсөл тодорхойлохын оронд гараа хаяад эхэлдэг нь надад нэг асуудал байна. Би эндээс асууя - бид юу хийж байна, яаж хийх гэж байна? Ямар нэгэн байдлаар үйлчлүүлэгч хэнээс ч илүү мэддэг байх ёстой гэдэг нь ид шидтэй байдаг. Гэхдээ хэн нэгний босгосон зүйлээс сонголт хийхдээ л үйлчлүүлэгч хамгийн сайн мэддэг. Хэрэв би машин худалдаж авахыг хүсч, гэр бүлийнхээ төсвийн хэмжээг мэддэг бол өөрийнхөө амьдралын хэв маягт тохирсон машиныг хурдан сонгох болно. Энд би бүх зүйлийг хэнээс ч илүү мэддэг! Гэхдээ хэн нэгэн машиныг аль хэдийн хийсэн гэдгийг анхаарна уу. Би яаж шинэ машин зохион бүтээх талаар ямар ч ойлголтгүй, би мэргэжилтэн биш. Бид захиалгат эсвэл тусгай бүтээгдэхүүн бүтээхдээ үйлчлүүлэгчийн дуу хоолойг харгалзан үзэх ёстой, гэхдээ энэ нь цорын ганц дуу хоолой байхаа больсон.
Олег: Та Agile тунхаглалыг дурдсан. Асуудлын талаарх орчин үеийн ойлголтыг харгалзан бид ямар нэгэн байдлаар шинэчлэх эсвэл өөрчлөх шаардлагатай байна уу?
Тим: Би түүнд хүрэхгүй. Энэ бол агуу түүхэн баримт бичиг гэж бодож байна. Тэр бол байгаагаараа л гэсэн үг. Тэр 19 нас хүрч байгаа, хөгширсөн ч цаг үед нь хувьсгал хийсэн. Түүний сайн хийсэн зүйл бол тэр хариу үйлдэл үзүүлж, хүмүүс түүний тухай шивнэж эхэлсэн. Та 2001 онд энэ салбарт хараахан ажиллаж амжаагүй байх магадлалтай, гэхдээ дараа нь бүгд үйл явцын дагуу ажилласан. Програм хангамжийн инженерийн хүрээлэн, програм хангамжийн бүрэн байдлын загвар (CMMI) -ийн таван түвшин. Эрт дээр үеийн ийм домог танд ямар нэг зүйл хэлж байгааг би мэдэхгүй, гэхдээ дараа нь энэ нь нээлт байсан. Эхлээд хүмүүс процессыг зөв тохируулсан бол асуудал өөрөө алга болно гэж итгэдэг байсан. Дараа нь Манифест гарч ирээд: "Үгүй, үгүй, үгүй - бид үйл явц дээр биш, харин хүмүүст тулгуурлах болно." Бид програм хангамж хөгжүүлэлтийн мастерууд. Тохиромжтой үйл явц бол гайхамшиг гэдгийг бид ойлгож байгаа бөгөөд энэ нь тохиолддоггүй. Төсөлд хэт их өвөрмөц байдал байдаг тул бүх төслүүдэд зориулсан нэг төгс үйл явцын санаа нь ямар ч утгагүй юм. Асуудал нь бүх зүйлд ганцхан шийдэл байдаг (сайн уу, нирвана) гэж хэлэхэд хэтэрхий төвөгтэй байдаг.
Би ирээдүйгээ харна гэж бодохгүй байна, гэхдээ одоо хүмүүс төслийн талаар илүү их бодож эхэлсэн гэж хэлье. Agile Manifesto нь үсрэн гарч ирээд “Хөөе! Та хөлөг онгоцон дээр байгаа бөгөөд та өөрөө энэ хөлөг онгоцыг жолоодож байна. Та шийдвэр гаргах хэрэгтэй болно - бид бүх нөхцөл байдалд бүх нийтийн жор санал болгохгүй. Та бол хөлөг онгоцны багийнхан бөгөөд хэрэв та хангалттай сайн байвал зорилгодоо хүрэх арга замыг олж чадна. Чамаас өмнө өөр хөлөг онгоцууд байсан, чиний дараа ч бас өөр хөлөг онгоцууд байх болно, гэхдээ таны аялал нэг талаараа өвөрмөц юм." Тиймэрхүү нэг юм! Энэ бол сэтгэлгээний арга юм. Миний хувьд наран дор шинэ зүйл байхгүй, хүмүүс өмнө нь далайгаар аялж байсан, дахин аялах болно, гэхдээ таны хувьд энэ бол таны гол аялал бөгөөд танд яг юу тохиолдохыг би хэлэхгүй. Та багаар хамтран ажиллах ур чадвартай байх ёстой бөгөөд хэрэв танд үнэхээр байгаа бол бүх зүйл бүтэж, хүссэн газартаа хүрэх болно.
Peopleware: 30 жилийн дараа
Олег: Peopleware бол Манифест шиг хувьсгал байсан уу?
Тим: Peopleware... Том бид хоёр энэ номыг бичсэн ч ийм зүйл болно гэж бодсонгүй. Энэ нь ямар нэгэн байдлаар олон хүний санааг шингээсэн. Энэ бол "Програм хангамж боловсруулах нь хүний маш их эрчимтэй үйл ажиллагаа юм" гэсэн анхны ном байсан. Техникийн шинж чанартай хэдий ч бид том, бүр асар том, маш нарийн төвөгтэй зүйлийг бүтээдэг хүмүүсийн нийгэмлэг юм. Хэн ч ганцаараа ийм зүйлийг бүтээж чадахгүй биз дээ? Тиймээс "баг" гэсэн санаа маш чухал болсон. Зөвхөн менежментийн үүднээс ч биш, бас олон үл мэдэгдэх зүйлтэй үнэхээр нарийн төвөгтэй асуудлыг шийдэхийн тулд нэгдэж байсан техникийн хүмүүст зориулагдсан. Миний хувьд энэ бол миний карьерын туршид оюун ухааныг шалгах маш том шалгалт байсан. Энд та хэлэх боломжтой байх хэрэгтэй: тийм ээ, энэ асуудал миний бие даан даван туулж чадахаас хамаагүй их юм, гэхдээ бид хамтдаа бахархаж болох гоёмсог шийдлийг олж чадна. Энэ санаа хамгийн их цуурайтсан гэж би бодож байна. Цагийн тодорхой хэсгийг бие даан, нэг хэсэг нь бүлгийн нэг хэсэг болж, ихэнх тохиолдолд шийдвэрээ бүлэг гаргадаг гэсэн санаа. Бүлгийн асуудлыг шийдвэрлэх нь нарийн төвөгтэй төслүүдийн чухал шинж чанар болсон.
Тим маш олон илтгэл тавьсан ч тэдний маш цөөхөн нь YouTube дээр тавигдсан байдаг. Та 2007 оны "Хүмүүсийн эргэн ирэлт" тайланг үзэж болно. Чанар нь мэдээжийн хэрэг хүссэн зүйлээ үлдээдэг.
Майкл: Ном хэвлэгдсэнээс хойш сүүлийн 30 жилийн хугацаанд ямар нэгэн өөрчлөлт гарсан уу?
Тим: Та үүнийг олон талаас нь харж болно. Социологийн хувьд... нэгэн цагт энгийн үед та болон танай хамт олон нэг өрөөнд сууж байсан. Та өдөр бүр дотно байж, хамтдаа кофе ууж, ажлаа ярилцаж болно. Үнэхээр өөрчлөгдсөн зүйл бол багуудыг газарзүйн хувьд, өөр өөр улс орон, цагийн бүсэд хуваарилах боломжтой болсон ч тэд ижил асуудал дээр ажиллаж байгаа бөгөөд энэ нь цоо шинэ төвөгтэй байдлыг нэмж байна. Энэ нь хуучны юм шиг санагдаж магадгүй, гэхдээ та бүгдээрээ хамтдаа, хамтдаа ажиллаж, хамт ажилладаг хүн рүүгээ алхаж ирээд "Миний олж мэдсэн зүйлийг хараарай, чамд энэ таалагдаж байна уу?" гэж хэлэх нүүр тулсан харилцаа шиг зүйл байхгүй. Нүүр тулсан яриа нь албан бус харилцаанд хурдан шилжих боломжийг олгодог бөгөөд энэ нь уян хатан сонирхогчдод таалагдах ёстой гэж би бодож байна. Мөн би бас санаа зовж байна, учир нь бодит байдал дээр дэлхий маш жижигхэн болж хувирсан, одоо бүх зүйл хуваарилагдсан багуудаар бүрхэгдсэн, бүх зүйл маш нарийн төвөгтэй болсон.
Бид бүгд DevOps-д амьдардаг
Майкл: Чуулганы хөтөлбөрийн хорооны үүднээс ч гэсэн Калифорнид, Нью-Йоркт, Европт, Орост... Сингапурт одоохондоо нэг ч хүн байхгүй. Газарзүйн ялгаа нэлээд том бөгөөд хүмүүс улам бүр тархаж эхэлж байна. Хэрэв бид хөгжлийн тухай ярьж байгаа бол та бидэнд devops болон багууд хоорондын саад бэрхшээлийг арилгах талаар илүү ихийг хэлж чадах уу? Хүн бүр бункертээ суугаад, одоо бункерууд нь нурж унадаг гэсэн ойлголт байдаг, энэ зүйрлэлийг та юу гэж бодож байна вэ?
Тим: Сүүлийн үеийн технологийн ололт амжилтаас харахад devops маш чухал юм шиг санагдаж байна. Өмнө нь та хөгжүүлэгч, администраторуудын багтай байсан, тэд ажиллаж, ажиллаж, ажиллаж байсан бөгөөд хэзээ нэгэн цагт админууд дээр ирж, үүнийг үйлдвэрлэлд нэвтрүүлэх боломжтой зүйл гарч ирэв. Эндээс бункерын тухай яриа эхэлсэн, учир нь админууд нь дайсан биш харин холбоотнууд юм, гэхдээ та бүх зүйл үйлдвэрлэлд ороход бэлэн болсон үед л тэдэнтэй ярилцсан. Та тэдэн дээр ямар нэгэн зүйл аваад: Манайд ямар програм байгааг хараарай, гэхдээ та энэ програмыг гаргаж чадах уу? Одоо хүргэлтийн тухай ойлголт бүхэлдээ илүү сайн болж өөрчлөгдсөн. Өөрчлөлтийг хурдан даван туулж чадна гэсэн санаа байсан. Бид бүтээгдэхүүнээ хурдан шинэчлэх боломжтой. Миний зөөврийн компьютер дээр Firefox гарч ирэхэд би үргэлж инээмсэглэж, "Хөөе, бид таны Firefox-г ард нь шинэчилсэн. Та энд дарж нэг минут болмогц бид танд хамгийн сүүлийн хувилбарыг өгөх болно" гэж хэлэх үед инээмсэглэдэг. Тэгээд би "Өө тийм ээ, хонгор минь!" Намайг унтаж байхад тэд миний компьютер дээр шинэ хувилбарыг хүргэхээр ажиллаж байсан. Энэ бол гайхалтай, итгэмээргүй юм.
Гэхдээ энд хэцүү зүйл байна: програм хангамжийг шинэчлэхэд танд ийм боломж байгаа боловч хүмүүсийг нэгтгэх нь илүү хэцүү байдаг. DevOops-ийн үндсэн илтгэл дээр миний хэлэхийг хүсч буй зүйл бол одоо бид урьд өмнө байгаагүй олон тоглогчтой болсон. Хэрэв та зөвхөн нэг багт оролцсон бүх хүмүүсийн талаар бодох юм бол .... Та үүнийг баг гэж бодсон бөгөөд энэ нь зөвхөн програмистуудын баг биш юм. Эдгээр нь тестер, төслийн менежерүүд болон бусад олон хүмүүс юм. Мөн хүн бүр ертөнцийг үзэх өөрийн гэсэн үзэл бодолтой байдаг. Бүтээгдэхүүний менежерүүд төслийн менежерүүдээс тэс өөр. Админууд өөрсдийн гэсэн даалгавартай байдаг. Юу болж байгааг үргэлжлүүлэн мэдэж, галзуурахгүй байхын тулд бүх оролцогчдыг зохицуулах нь нэлээд хэцүү асуудал болж хувирдаг. Бүлгийн даалгавар, хүн бүрт хамаарах ажлуудыг салгах шаардлагатай. Энэ бол маш хэцүү ажил юм. Нөгөөтэйгүүр, олон жилийн өмнөхөөс хамаагүй дээрдсэн гэж бодож байна. Хүмүүс яг ийм замаар л өсөж, биеэ зөв авч явж сурдаг. Интеграцчилал хийх үед та газар доорх бүтээн байгуулалт байх ёсгүй гэдгийг ойлгож байгаа бөгөөд ингэснээр програм хангамж нь эцсийн мөчид хайрцагт үүр шиг мөлхөхгүй байх болно: бид энд юу хийснийг хараарай! Интеграци, хөгжүүлэлт хийж, эцэст нь цэгцтэй, давтагдах байдлаар өнхрөх болно гэсэн санаа юм. Энэ бүхэн надад маш их ач холбогдолтой. Энэ нь системийн хэрэглэгчид болон таны үйлчлүүлэгчдэд илүү их үнэ цэнийг бий болгох боломжтой болгодог.
Майкл: Devops-ийн бүх санаа бол утга учиртай хөгжлийг аль болох эрт хүргэх явдал юм. Дэлхий улам бүр хурдасч эхэлснийг би харж байна. Ийм хурдатгалд хэрхэн дасан зохицох вэ? Арван жилийн өмнө ийм зүйл байгаагүй!
Тим: Мэдээжийн хэрэг, хүн бүр илүү олон функцийг хүсдэг. Хөдлөх шаардлагагүй, зүгээр л илүү их овоолно. Заримдаа ямар нэгэн хэрэгтэй зүйлийг авчрахын тулд дараагийн нэмэлт шинэчлэлтийг удаашруулах шаардлагатай болдог бөгөөд энэ нь хэвийн үзэгдэл юм.
Гүйх, гүйх, гүйх хэрэгтэй гэсэн санаа бол хамгийн сайн зүйл биш юм. Хэн ч ийм амьдралаар амьдрахыг хүсэх нь юу л бол. Хүргэлтийн хэмнэл нь төслийн өөрийн хэмнэлийг тохируулахыг хүсч байна. Хэрэв та зүгээр л жижиг, харьцангуй утгагүй зүйлсийн урсгалыг бий болговол энэ бүхэн ямар ч утгагүй болно. Аливаа зүйлийг аль болох эрт гаргахыг ухаангүй оролдохын оронд тэргүүлэх хөгжүүлэгчид болон бүтээгдэхүүн, төслийн менежерүүдтэй ярилцах нь зүйтэй зүйл бол стратеги юм. Энэ бүр утга учиртай юу?
Загвар ба эсрэг хэв маяг
Олег: Та ихэвчлэн хэв маяг, эсрэг хэв маягийн талаар ярьдаг бөгөөд энэ нь төслүүдийн амьдрал ба үхлийн хоорондох ялгаа юм. Одоо бидний амьдралд devops орж ирж байна. Төслийг газар дээр нь устгаж чадах өөрийн гэсэн хэв маяг, эсрэг хээтэй юу?
Тим: Загвар болон эсрэг загварууд байнга тохиолддог. Ярих зүйл байна. За, бидний "гялалзсан зүйл" гэж нэрлэдэг ийм зүйл байдаг. Хүмүүс шинэ технологид үнэхээр дуртай. Тэд зүгээр л дажгүй, загварлаг харагддаг бүх зүйлийн гялалзсан байдалд ховсдог бөгөөд тэд асуулт асуухаа больсон: энэ нь зайлшгүй шаардлагатай юу? Бид юунд хүрэх гэж байна вэ? Энэ зүйл найдвартай юу, ямар нэгэн утга учиртай юу? Технологийн дэвшилтэт дэвшилтэт хүмүүс гэж би олонтаа хардаг. Тэд дэлхий дээр болж буй үйл явдалд ховсдуулдаг. Гэхдээ хэрэв та тэдний ямар ашигтай зүйл хийдгийг сайтар ажиглавал ямар ч ашиг тустай зүйл байдаггүй.
Энэ жил саран дээр бууснаас хойш тавин жилийн ой тохиож байна гээд л нөхдүүдтэйгээ ярилцаж байлаа. Энэ нь 1969 онд болсон. Хүмүүсийг тэнд очиход тусалсан технологи нь 1969 он ч биш, харин 1960 эсвэл 62 он юм, учир нь НАСА найдвартай байдлын сайн нотолгоотой зүйлийг л ашиглахыг хүссэн юм. Тиймээс та үүнийг хараад ойлгоорой - тийм ээ, тэд үнэн байсан! Одоо, үгүй, үгүй, гэхдээ бүх зүйл хэтэрхий хүчтэй түлхэгдэж, бүх хагарлаас зарагдсан тул та технологийн асуудалд ордог. Хүмүүс хаа сайгүй хашгирч байна: "Хараач, энэ бол дэлхийн хамгийн шинэ, хамгийн үзэсгэлэнтэй, бүх хүнд тохирсон зүйл юм!" За, тэгээд л ... ихэвчлэн энэ бүхэн зүгээр л хууран мэхлэлт болж хувирдаг бөгөөд дараа нь бүгдийг нь хаях хэрэгтэй. Магадгүй энэ бүхэн би аль хэдийн хөгшин болсон болохоор хүмүүс гүйж ирээд, шилдэг технологи бүтээх цорын ганц, хамгийн зөв аргыг олсон гэж хэлэх үед ийм зүйлийг маш их эргэлзэж хардагтай холбоотой байх. Яг энэ мөчид миний дотор “Ямар эмх замбараагүй юм бэ!” гэх дуу хоолой сэрж байна.
Майкл: Үнэхээр бид дараагийн мөнгөн сумны тухай хэр олон удаа сонссон бэ?
Тим: Яг л, энэ бол ердийн зүйл юм! Жишээ нь... энэ нь дэлхий даяар аль хэдийн хошигнол болсон юм шиг санагддаг, гэхдээ энд хүмүүс блокчэйн технологийн талаар их ярьдаг. Мөн тэд тодорхой нөхцөл байдалд үнэхээр утга учиртай байдаг! Танд үйл явдлын найдвартай нотлох баримт хэрэгтэй бол, систем ажиллаж байгаа бөгөөд хэн ч биднийг хуурч мэхлээгүй, аюулгүй байдлын асуудал болон бусад зүйлс холилдсон үед блокчэйн нь утга учиртай болно. Гэхдээ тэд Blockchain одоо дэлхий даяар шүүрдэж, замдаа таарсан бүх зүйлийг шүүрдэх болно гэж хэлэх үед? Илүү ихийг мөрөөд! Энэ бол маш үнэтэй, нарийн төвөгтэй технологи юм. Техникийн хувьд төвөгтэй, цаг хугацаа их шаарддаг. Зөвхөн алгоритмын хувьд ч гэсэн бага зэрэг өөрчлөлт оруулан математикийг дахин тооцоолох шаардлагатай болдог ... энэ бол маш сайн санаа - гэхдээ зөвхөн тодорхой тохиолдлуудад. Миний бүх амьдрал, карьер энэ тухай байсан: маш тодорхой нөхцөл байдалд сонирхолтой санаанууд. Таны нөхцөл байдал яг ямар байгааг ойлгох нь маш чухал юм.
Майкл: Тиймээ, "амьдрал, орчлон ертөнц ба бүх зүйлийн тухай" гол асуулт: энэ технологи, арга барил нь таны нөхцөл байдалд тохирох уу, үгүй юу?
Тим: Энэ асуултыг технологийн бүлэгтэй аль хэдийн ярилцаж болно. Бүр зөвлөх авчирч магадгүй. Төслийг хараад ойлгоорой - одоо бид өмнөхөөсөө илүү зөв, хэрэгтэй зүйл хийх үү? Энэ нь тохирох байх, магадгүй энэ нь тохирохгүй байх. Гэхдээ хамгийн чухал нь хэн нэгэн: "Бидэнд блокчэйн маш их хэрэгтэй байна! Би дөнгөж сая онгоцон дээр түүний тухай сэтгүүлээс уншсан! Ноцтой юу? Энэ нь бүр инээдтэй биш юм.
Домогт "девопс инженер"
Олег: Одоо бүгд devops хэрэгжүүлж байна. Хэн нэгэн интернетээс devops-ийн тухай уншдаг бол маргааш ажилд авах сайт дээр өөр нэг сул орон тоо гарч ирнэ. "devops инженер". Энд би та бүхний анхаарлыг татахыг хүсч байна: "devops engineer" гэдэг энэ нэр томьёо амьд явах эрхтэй гэж та бодож байна уу? Девопс бол соёл бөгөөд энд ямар нэг зүйл байдаггүй гэсэн үзэл бодол байдаг.
Тим: Тийм болохоор. Тэдэнд энэ нэр томъёоны талаар нэн даруй тайлбар өгөөч. Үүнийг өвөрмөц болгох ямар нэг зүйл. Ийм сул орон тооны ард ур чадварын өвөрмөц хослол байгааг тэд нотлох хүртэл би үүнийг худалдаж авахгүй! Бидэнд "devops engineer" гэсэн албан тушаал, сонирхолтой цол бий, тийм ээ, дараа нь яах вэ? Ажлын байрны нэр нь ерөнхийдөө маш сонирхолтой зүйл юм. "Хөгжүүлэгч" гэж хэлье - энэ нь юу вэ? Өөр өөр байгууллага шал өөр зүйлийг хэлдэг. Зарим компаниудад өндөр чанартай програмистууд бусад компаниудын тусгай мэргэжлийн тестерүүдийн бичсэн тестээс илүү утга учиртай тест бичдэг. Тэгвэл тэд одоо программист эсвэл тестер үү?
Тийм ээ, бидэнд ажлын байр бий, гэхдээ хэрэв та хангалттай удаан асуулт асуувал эцэст нь бид бүгд асуудал шийддэг хүмүүс болох нь тодорхой болно. Бид шийдлийг эрэлхийлэгчид бөгөөд зарим нь техникийн ур чадвартай, зарим нь өөр өөр чадвартай байдаг. Хэрэв та DevOps нэвтэрсэн орчинд амьдардаг бол та хөгжүүлэлт, удирдлагын нэгдмэл байдалд оролцож байгаа бөгөөд энэ үйл ажиллагаа нь нэлээд чухал зорилготой юм. Харин чамаас яг юу хийдэг, ямар хариуцлага хүлээдэг вэ гэж асуухад энэ бүх зүйлийг эрт дээр үеэс хүмүүс хийж ирсэн байдаг. "Би архитектурыг хариуцдаг", "Би мэдээллийн баазыг хариуцдаг" гэх мэт юу ч байсан, энэ бүхэн "devops"-ээс өмнө байсан.
Хэн нэгэн надад ажлынхаа нэрийг хэлэхэд би нэг их сонсдоггүй. Түүнд яг юу хариуцаж байгаагаа хэлэхийг зөвшөөрсөн нь дээр, энэ нь бидэнд асуудлыг илүү сайн ойлгох боломжийг олгоно. Миний хамгийн дуртай жишээ бол хүн өөрийгөө "төслийн менежер" гэж зарлах явдал юм. Юу? Энэ нь юу ч гэсэн үг биш, би чамайг юу хийдэгийг мэдэхгүй хэвээр байна. Төслийн менежер нь хөгжүүлэгч, дөрвөн хүний бүрэлдэхүүнтэй багийн ахлагч, код бичдэг, ажил хийдэг, багийн ахлагч болсон, хүмүүс өөрсдөө удирдагч гэж хүлээн зөвшөөрдөг хүн байж болно. Мөн төслийн менежер нь төсөл дээр зургаан зуун хүнийг удирддаг, бусад менежерүүдийг удирддаг, хуваарь гаргах, төсөв төлөвлөх үүрэгтэй менежер байж болно. Эдгээр нь огт өөр хоёр ертөнц юм! Гэхдээ тэдний ажлын нэр адилхан сонсогдож байна.
Үүнийг арай өөрөөр эргүүлье. Та юунд үнэхээр сайн, асар их туршлагатай, авьяастай юу? Та даалгавраа даван туулж чадна гэж бодож байгаа учраас юунд хариуцлага хүлээх вэ? Энд хэн нэгэн тэр даруй үгүйсгэж эхэлнэ: үгүй, үгүй, үгүй, би төслийн нөөцтэй харьцах хүсэлгүй байна, энэ бол миний бизнес биш, би техникийн залуу, ашиглах чадвар, хэрэглэгчийн интерфейсийг ойлгодог, би тэгэхгүй. Хүмүүсийн армийг удирдахыг хүсч байна, би ажилдаа явцгаая.
Дашрамд хэлэхэд, би ийм төрлийн ур чадваруудыг салгах нь сайн ажилладаг хандлагыг дэмжигч юм. Техникийн ажилчид хүссэнээрээ карьераа өсгөх боломжтой газар. Гэсэн хэдий ч би техникийн ажилтнууд гомдоллодог байгууллагуудыг харсаар байна: Би төслийн менежментэд орох хэрэгтэй болно, учир нь энэ нь энэ компанид цорын ганц арга зам юм. Заримдаа энэ нь аймшигтай үр дагаварт хүргэдэг. Шилдэг техникчид сайн менежерүүд огтхон ч биш, харин шилдэг менежерүүд технологийг зохицуулж чаддаггүй. Энэ талаар шударга байцгаая.
Би одоо ийм эрэлт хэрэгцээ их байгааг харж байна. Хэрэв та техникч бол танай компани танд тусалж чадна, гэхдээ технологи байнга өөрчлөгдөж байдаг тул та өөрийн карьераа олох хэрэгтэй. Хориодхон жилийн дотор технологи дор хаяж тав дахин өөрчлөгдөж болно. Технологи бол хачирхалтай зүйл ...
"Бүх зүйл дээр мэргэжилтнүүд"
Майкл: Ийм хурдацтай технологийн өөрчлөлтийг хүмүүс яаж даван туулах вэ? Тэдний нарийн төвөгтэй байдал нэмэгдэж, тэдний тоо нэмэгдэж, хүмүүсийн хоорондын харилцааны нийт хэмжээ нэмэгдэж байгаа тул та "бүх зүйлд мэргэжилтэн" болж чадахгүй.
Тим: Зөв! Хэрэв та технологийн чиглэлээр ажилладаг бол, тийм ээ, та тодорхой зүйлийг сонгож, түүнийгээ судлах хэрэгтэй. Танай байгууллагын хэрэгцээтэй гэж үзсэн зарим технологи (магадгүй хэрэг болох байх). Хэрэв та үүнийг сонирхохоо больсон бол би үүнийг хэлнэ гэдэгт би хэзээ ч итгэхгүй байсан - магадгүй та технологи нь илүү сонирхолтой эсвэл суралцахад илүү тохиромжтой өөр байгууллагад шилжих хэрэгтэй болов уу.
Гэхдээ ерөнхийдөө тийм ээ, таны зөв. Технологи нэг дор бүх чиглэлд хөгжиж байна, хэн ч "Би одоо байгаа бүх технологийн мэргэшсэн технологич" гэж хэлж чадахгүй. Нөгөөтэйгүүр технологийн мэдлэгийг жинхэнэ утгаар нь шингээж, түүндээ галзуурдаг хөвөн хүмүүс байдаг. Би ийм хэдэн хүмүүсийг харсан, тэд шууд утгаараа амьсгалж, амьдардаг, тэдэнтэй ярилцах нь ашигтай бөгөөд сонирхолтой юм. Байгууллага дотор болж байгаа үйл явдлыг судлаад зогсохгүй ерөнхийдөө энэ тухай ярьдаг, бас үнэхээр дажгүй технологичид, маш ухамсартай, зорилготой байдаг. Тэдний хүсэл тэмүүлэл нь Технологийн хөдөлгөөн, технологийг сурталчлах явдал учраас үндсэн ажил нь юу байхаас үл хамааран тэд долгионы оргилд үлдэхийг хичээдэг. Хэрэв та ийм хүнтэй гэнэт таарвал түүнтэй хамт өдрийн хоолонд очиж, үдийн хоолны үеэр янз бүрийн сайхан зүйлийг ярилцах хэрэгтэй. Ямар ч байгууллагад ганц хоёр ч гэсэн ийм хүн хэрэгтэй гэж боддог.
Эрсдэл ба тодорхойгүй байдал
Майкл: Гавьяат инженерүүд, тийм ээ. Завтай байхад эрсдэлийн удирдлагын талаар хөндөе. Алдаа нь аймшигтай үр дагаварт хүргэж болзошгүй эмнэлгийн программ хангамжийн талаар ярилцсанаар бид энэ ярилцлагыг эхлүүлсэн. Дараа нь бид "Сарны хөтөлбөр"-ийн талаар ярилцсан бөгөөд алдаа нь олон сая доллар, магадгүй хэд хэдэн хүний амь насыг авчирдаг. Харин одоо энэ салбарт эсрэгээрээ хөдөлгөөн өрнөж байгааг харж байна, хүмүүс эрсдэлийн талаар боддоггүй, урьдчилан таамаглах гэж оролддоггүй, бүр ажигладаггүй.
Олег: Хурдан хөдөлж, юм эвд!
Майкл: Тийм ээ, хурдан хөдөлж, аливаа зүйлийг эвдэж, илүү олон зүйлийг, ямар нэгэн зүйлээс болж үхэх хүртлээ. Таны бодлоор дундаж хөгжүүлэгч эрсдэлийн менежментэд суралцахад одоо хэрхэн хандах ёстой вэ?
Тим: Эрсдэл ба тодорхойгүй байдал гэсэн хоёр зүйлийн хоорондох шугамыг энд татъя. Эдгээр нь өөр өөр зүйл юм. Тодорхой хариулт өгөхөд хангалттай мэдээлэл байхгүй үед тодорхойгүй байдал үүсдэг. Жишээ нь, төслийн хамгийн эхний шатанд хэн нэгэн чамаас “Та ажлаа хэзээ дуусгах вэ” гэж асуувал, хэрэв та нэлээд шударга хүн бол “Надад ямар ч ойлголт байхгүй” гэж хариулах болно. Та зүгээр л мэдэхгүй байна, энэ нь зүгээр юм. Та асуудлыг хараахан судлаагүй, багийг сайн мэдэхгүй, тэдний ур чадварыг мэдэхгүй гэх мэт. Энэ бол тодорхойгүй байдал.
Боломжит асуудлуудыг аль хэдийн илрүүлж чадвал эрсдэл үүсдэг. Иймэрхүү зүйл тохиолдож болно, магадлал нь тэгээс их, гэхдээ зуугаас бага, хаа нэгтээ. Үүнээс болж хоцрогдол, шаардлагагүй ажил, гэхдээ төслийн хувьд үхлийн үр дагавар хүртэл юу ч тохиолдож болно. Үр дүн нь: Залуус аа, шүхрээ эвхээд далайн эргээс гарцгаая, бид үүнийг хэзээ ч дуусгахгүй, бүх зүйл дууслаа. Бид энэ зүйл ажиллах болно гэж таамагласан боловч энэ нь огт ажиллахгүй байгаа тул зогсоох цаг болжээ. Эдгээр нь нөхцөл байдал юм.
Асуудлыг аль хэдийн үүссэн үед, яг одоо асуудал гарч байгаа үед шийдвэрлэхэд хамгийн хялбар байдаг. Гэхдээ асуудал таны өмнө тулгарвал та эрсдэлийн менежментийг хийхгүй, харин асуудлыг шийдэж, хямралын менежмент хийж байна. Хэрэв та тэргүүлэх хөгжүүлэгч эсвэл менежер бол саатал, цаг хугацаа алдах, шаардлагагүй зардал эсвэл бүхэл бүтэн төслийг сүйрүүлэхэд хүргэж болох зүйл юу болохыг та гайхаж байна уу? Юу биднийг зогсоож, дахин эхлүүлэх вэ? Эдгээр бүх зүйл ажиллахад бид тэдэнтэй юу хийх вэ? Ихэнх нөхцөл байдалд тохирсон энгийн хариулт байдаг: эрсдэлээс бүү зугт, түүн дээр ажилла. Эрсдэлтэй нөхцөл байдлыг хэрхэн шийдэж, юу ч биш болгож, асуудлаас өөр зүйл болгон хувиргаж болохыг хараарай. За яахав гэж хэлэхийн оронд бид асуудлыг шийдэх болно.
Тодорхойгүй байдал, эрсдэл нь таны тулгарч буй бүх зүйлийн тэргүүн эгнээнд байх ёстой. Та төслийн төлөвлөгөө гаргаж, тодорхой чухал эрсдэлүүдийг урьдчилан харж, "Бид үүнийг одоо шийдэх хэрэгтэй, учир нь хэрэв энэ нь буруу болвол өөр юу ч хамаагүй болно" гэж хэлж болно. Хэрэв та оройн хоол хийж чадах эсэх нь тодорхойгүй байвал ширээн дээрх ширээний бүтээлэгний гоо үзэсгэлэнгийн талаар санаа зовох хэрэггүй. Эхлээд та амттай оройн хоол бэлтгэх бүх эрсдлийг тодорхойлж, тэдэнтэй харьцаж, зөвхөн дараа нь бодит аюул занал учруулахгүй бусад бүх зүйлийн талаар бодох хэрэгтэй.
Дахин хэлэхэд таны төсөл юугаараа онцлог вэ? Төсөл маань замаас гарахад юу нөлөөлж болохыг харцгаая. Ийм тохиолдох магадлалыг багасгахын тулд бид юу хийж чадах вэ? Ихэвчлэн та тэднийг 100% саармагжуулж, "Тийм байна, энэ асуудал байхаа больсон, эрсдэл шийдэгдсэн!" гэж цэвэр ухамсартайгаар тунхаглаж чадахгүй. Миний хувьд энэ бол насанд хүрэгчдийн зан байдлын шинж тэмдэг юм. Энэ бол хүүхэд болон насанд хүрэгчдийн хоорондох ялгаа юм - хүүхдүүд өөрсдийгөө үхэшгүй мөнх гэж боддог, юу ч болохгүй, бүх зүйл сайхан болно! Үүний зэрэгцээ насанд хүрэгчид гурван настай хүүхдүүд тоглоомын талбай дээр хэрхэн үсэрч байгааг харж, хөдөлгөөнийг нүдээрээ дагаж, "өө-өө, өө-өө" гэж хэлдэг. Би хажууд зогсоод хүүхэд унах үед барихад бэлддэг.
Нөгөөтэйгүүр, яагаад энэ бизнес надад маш их таалагдаж байна вэ гэвэл эрсдэлтэй. Бид аливаа зүйлийг хийдэг бөгөөд тэдгээр нь эрсдэлтэй байдаг. Тэд насанд хүрэгчдийн хандлагыг шаарддаг. Зөвхөн урам зориг таны асуудлыг шийдэж чадахгүй!
Насанд хүрэгчдийн инженерийн сэтгэлгээ
Майкл: Хүүхдүүдтэй харьцах жишээ бол сайн. Хэрэв би жирийн инженер бол хүүхэд болсондоо баяртай байна. Гэхдээ та илүү насанд хүрэгчдийн сэтгэлгээ рүү хэрхэн шилжих вэ?
Тим: Эхлэгч эсвэл тогтсон хөгжүүлэгчийн аль алинд нь адилхан сайн ажилладаг санаануудын нэг бол контекстийн тухай ойлголт юм. Бид юу хийж байна, юунд хүрэх гэж байна. Энэ төсөлд үнэхээр чухал зүйл юу вэ? Та энэ төсөлд хэн байх нь хамаагүй, та дадлагажигч эсвэл ерөнхий архитектор байхаас үл хамааран хүн бүрт контекст хэрэгтэй. Бид хүн бүрийг өөрсдийн бүтээлээс илүү өргөн цар хүрээтэй сэтгэдэг болгох хэрэгтэй. "Би бүтээлээ хийдэг, миний бүтээл ажиллаж байгаа цагт би баяртай байна." Үгүй бас дахин үгүй. Хүмүүст ажиллаж буй нөхцөл байдлаа сануулах нь үргэлж үнэ цэнэтэй юм (бүдүүлэг байхгүйгээр!). Бид бүгд хамтдаа юунд хүрэхийг хичээж байна. Төслийн бүх зүйл сайхан байвал хүүхэд байж болно гэсэн санаанууд - битгий тэгээрэй. Ерөөсөө барианы шугамыг давчихвал хамтдаа л давна. Та ганцаараа биш, бид бүгд хамтдаа. Төсөлд хамрагдаж буй хөгшин залуу гэлтгүй бүх хүмүүс төсөлд чухам юу чухал вэ, компани яагаад бидний зорьж байгаа зүйлд хөрөнгө оруулалт хийж байгаа талаар ярьж эхэлбэл... тэдний ихэнх нь илүү сайн байх болно. Тэдний ажил бусад хүмүүсийн ажилтай хэрхэн уялдаж байгааг харах болно. Нэг талаараа би хувьдаа хариуцлага хүлээдэг хэсгийг ойлгож байна. Гэхдээ ажлаа дуусгахын тулд бидэнд бусад бүх хүмүүс хэрэгтэй. Хэрэв та үнэхээр ажлаа дуусгасан гэж бодож байгаа бол бидэнд төсөлд хийх ажил үргэлж бий!
Олег: Харьцангуй хэлэхэд, хэрэв та Канбаны дагуу ажилладаг бол зарим туршилтын бөглөрөлтэй тулгарвал тэнд хийж байсан зүйлээ (жишээлбэл, програмчлал) орхиж, шалгагчдад туслах боломжтой.
Тим: Яг. Миний бодлоор шилдэг техникчид, хэрэв та тэднийг анхааралтай ажиглавал тэд өөрсдийнхөө менежерүүд юм. Би үүнийг яаж томъёолох вэ ...
Олег: Таны амьдрал бол таны удирддаг төсөл юм.
Тим: Яг! Хариуцлагаа үүрч, асуудлаа ойлгоод, таны гаргасан шийдвэр тэдний ажилд нөлөөлнө гэх мэтээр хүмүүстэй харьцдаг гэсэн үг. Энэ нь зүгээр л ширээний ард суугаад, ажлаа хийж, эргэн тойронд юу болж байгааг ч анзаарахгүй байх тухай биш юм. Үгүй үгүй үгүй. Дашрамд хэлэхэд, Agile-ийн хамгийн сайн талуудын нэг нь тэд богино спринт санал болгосон явдал бөгөөд ингэснээр бүх оролцогчдын нөхцөл байдал тодорхой ажиглагдаж, тэд бүгдийг хамтдаа харж чадна. Бид өдөр бүр бие биенийхээ тухай ярьдаг.
Эрсдэлийн менежментэд хэрхэн орох вэ
Олег: Энэ чиглэлээр албан ёсны мэдлэгийн бүтэц бий юу? Жишээлбэл, би Java програмын програмист бөгөөд боловсролын чиглэлээр жинхэнэ төслийн менежер болохгүйгээр эрсдэлийн менежментийг ойлгохыг хүсч байна. Би эхлээд Макконнелийн "Програм хангамжийн төсөл хэр үнэтэй вэ" номыг уншаад дараа нь яах вэ? Эхний алхамууд юу вэ?
Тим: Эхнийх нь төслийн хүмүүстэй харилцаж эхлэх явдал юм. Энэ нь хамт ажиллагсадтайгаа харилцах соёлыг нэн даруй сайжруулах боломжийг олгодог. Бид бүх зүйлийг нуухын оронд анхдагч байдлаар нээхээс эхлэх хэрэгтэй. Гэж хэлээрэй: эдгээр нь намайг зовоож байгаа зүйлүүд, эдгээр нь намайг шөнө унтуулдаггүй, би өнөөдөр шөнө сэрээд: Бурхан минь, би энэ талаар бодох хэрэгтэй байна! Бусад хүмүүс ижил зүйлийг харж байна уу? Бүлгийн хувьд бид эдгээр болзошгүй асуудлуудад хариу өгөх ёстой юу? Та эдгээр сэдвээр хэлэлцүүлгийг дэмжих чадвартай байх хэрэгтэй. Бидний ажилладаг урьдчилан бэлтгэсэн томъёо байхгүй. Гамбургер хийх тухай биш, харин хүмүүст хамаатай. "Чизбургер хийсэн, чизбургер зарах" нь бидний хийх зүйл биш, тиймээс би энэ ажилд маш их дуртай. Менежерүүдийн хийж байсан бүх зүйл одоо багийн өмч болж байгаа нь надад таалагдаж байна.
Олег: График дээрх тооноос илүү аз жаргалыг хүмүүс хэрхэн чухалчилдаг талаар та ном, ярилцлагадаа ярьж байсан. Нөгөөтэйгүүр, та багийнханд: бид devops руу шилжиж байна, одоо программист байнга харилцах ёстой гэж хэлэхэд энэ нь түүний тав тухтай бүсээс хол байж магадгүй юм. Энэ мөчид тэр үнэхээр аз жаргалгүй байж магадгүй гэж бодъё. Ийм нөхцөлд юу хийх вэ?
Тим: Би яг юу хийхээ мэдэхгүй байна. Хэрэв хөгжүүлэгч хэтэрхий тусгаарлагдсан бол тэд юуны түрүүнд яагаад ажил хийгдэж байгааг олж харахгүй, зөвхөн ажлынхаа хэсгийг хардаг бөгөөд миний нэрлэж буй "контекст" руу орох хэрэгтэй. Тэр бүх зүйл хоорондоо хэрхэн холбогдож байгааг олж мэдэх хэрэгтэй. Мэдээжийн хэрэг, би албан ёсны танилцуулга эсвэл үүнтэй төстэй зүйлийг хэлэх гэсэнгүй. Та зөвхөн хариуцаж буй хэсгийг нь биш, харин бүхэл бүтэн ажлын талаар хамт ажиллагсадтайгаа харилцах хэрэгтэй гэдгийг би хэлж байна. Эндээс та санаануудаа ярилцаж, ажлаа сайн уялдуулах нийтлэг тохиролцоо, нийтлэг асуудлыг хэрхэн хамтдаа шийдвэрлэх талаар ярилцаж эхлэх боломжтой.
Тэднийг дасан зохицоход нь туслахын тулд тэд ихэвчлэн техникчдийг сургалтанд явуулахыг хүсдэг бөгөөд тэд сургалтын талаар ярилцдаг. Миний нэг найз нохойг сургадаг гэж хэлэх дуртай. Хүмүүст зориулсан сургалт байдаг. Хөгжүүлэгчийн хувьд суралцах хамгийн сайхан зүйлсийн нэг бол үе тэнгийнхэнтэйгээ харилцах явдал юм. Хэрэв хэн нэгэн нь ямар нэгэн зүйлд үнэхээр сайн бол та түүний ажлыг харж эсвэл түүнтэй ажлын эсвэл ямар нэгэн зүйлийн талаар ярилцах хэрэгтэй. Зарим ердийн Кент Бек экстрим програмчлалын талаар байнга ярьдаг байсан. XP бол маш энгийн санаа боловч маш олон асуудал үүсгэдэг учраас энэ нь инээдтэй юм. Зарим хүмүүсийн хувьд XP хийх нь найз нөхдийнхөө өмнө албадан нүцгэлсэнтэй адил юм. Тэд миний юу хийж байгааг харах болно! Тэд бол миний хамт олон, тэд зөвхөн харах төдийгүй ойлгох болно! Аймшигтай! Зарим хүмүүс ноцтой сандарч эхэлдэг. Гэхдээ энэ бол суралцах эцсийн арга гэдгийг ойлгох үед бүх зүйл өөрчлөгддөг. Та хүмүүстэй ойр ажилладаг бөгөөд зарим хүмүүс энэ сэдвийг чамаас хамаагүй илүү ойлгодог.
Майкл: Гэхдээ энэ бүхэн таныг тав тухтай бүсээсээ гарахад хүргэдэг. Инженер хүний хувьд тав тухтай бүсээсээ гарч, харилцах ёстой. Асуудлыг шийддэг хүний хувьд та өөрийгөө сул дорой байдалд байнга оруулж, юу нь буруу байж болох талаар бодож байх ёстой. Энэ төрлийн ажил нь угаасаа төвөг учруулахаар бүтээгдсэн байдаг. Та өөрийгөө ухамсартайгаар стресстэй нөхцөл байдалд оруулдаг. Ихэвчлэн хүмүүс тэднээс зугтдаг, хүмүүс аз жаргалтай хүүхэд байх дуртай.
Тим: Юу хийж болох вэ, чи гарч ирээд илэн далангүй хэлж болно: "Бүх зүйл зүгээр, би үүнийг даван туулж чадна! Би ганцаараа эвгүй санагддаг. Хамтдаа, нэг баг болж янз бүрийн эвгүй зүйлсийг ярилцъя!" Эдгээр нь бидний нийтлэг асуудал, бид тэдгээрийг шийдвэрлэх ёстой, та мэдэх үү? Өвөрмөц суут хөгжүүлэгч нар мамонт шиг алга болсон гэж би боддог. Мөн тэдний ач холбогдол маш хязгаарлагдмал. Хэрэв та харилцаж чадахгүй бол сайн оролцож чадахгүй. Тиймээс зүгээр л ярь. Шударга, нээлттэй бай. Энэ нь хэн нэгэнд тааламжгүй байгаад би маш их харамсаж байна. Та төсөөлж байна уу, олон жилийн өмнө АНУ-д гол айдас нь үхэл биш гэсэн судалгаа гарч байсан, гэхдээ юу болохыг тааварлаж байна уу? Олон нийтийн өмнө үг хэлэхээс айдаг! Энэ нь хаа нэгтээ чанга дуугаар магтахаас илүү үхэхийг илүүд үздэг хүмүүс байдаг гэсэн үг юм. Хийж байгаа зүйлээсээ шалтгаалаад зарим нэг үндсэн ур чадвар эзэмшсэн байхад хангалттай гэж би бодож байна. Ярианы ур чадвар, бичих чадвар - гэхдээ зөвхөн таны ажилд шаардлагатай хэмжээгээр л. Хэрэв та шинжээчээр ажилладаг ч уншиж, бичиж, ярьж чадахгүй бол харамсалтай нь та миний төслүүдэд хийх зүйлгүй болно!
Харилцааны үнэ
Олег: Ийм гадагшаа гарсан ажилчдыг ажиллуулах нь янз бүрийн шалтгааны улмаас илүү үнэтэй биш гэж үү? Эцсийн эцэст тэд ажиллахын оронд байнга чатлаж байна!
Тим: Би зөвхөн хүн бүр биш багийн гол цөмийг хэлсэн. Хэрэв танд өгөгдлийн санг тааруулахдаа үнэхээр гайхалтай, мэдээллийн санг тааруулах дуртай, насан туршдаа мэдээллийн батаа тааруулах гэж байгаа хүн байгаа бол ингээд үргэлжлүүлээрэй. Гэхдээ би төсөл өөрөө амьдрах хүсэлтэй хүмүүсийн тухай ярьж байна. Төслийг боловсруулахад чиглэсэн багийн гол хэсэг. Эдгээр хүмүүс үнэхээр бие биетэйгээ байнга харилцах хэрэгтэй. Ялангуяа төслийн эхэнд эрсдэл, дэлхийн зорилгод хүрэх арга зам гэх мэт асуудлыг хэлэлцэх үед.
Майкл: Энэ нь мэргэжил, ур чадвар, ажлын арга барилаас үл хамааран төсөлд хамрагдсан бүх хүмүүст хамаарна. Та бүгд төслийн амжилтыг сонирхож байна.
Тим: Тийм ээ, та төсөлд хангалттай шимтсэн, таны даалгавар бол төслийг хэрэгжүүлэхэд нь туслах явдал юм. Та програмист, шинжээч, интерфэйс дизайнер, хэн ч бай. Энэ бол өглөө бүр ажилдаа ирдэг шалтгаан бөгөөд бидний хийдэг зүйл юм. Бид энэ бүх хүмүүсийн ур чадвараас үл хамааран хариуцлага хүлээдэг. Энэ бол насанд хүрэгчдийн яриа өрнүүлдэг бүлэг хүмүүс юм.
Олег: Үнэн хэрэгтээ, яриа хөөрөөтэй ажилчдын тухай ярихдаа би дэлхийн шинэ үзэл баримтлалд шилжихийг хүссэн хүмүүсийн, ялангуяа менежерүүдийн эсэргүүцлийг дууриахыг хичээсэн. Зөвлөхүүдийн хувьд та эдгээр эсэргүүцлийг хөгжүүлэгчийн хувьд надаас илүү мэддэг байх ёстой! Менежерүүдийг юу хамгийн их зовоож байгааг хуваалцаач?
Тим: Менежерүүд үү? Хм. Ихэнхдээ менежерүүд асуудлын дарамтанд орж, ямар нэг зүйлийг яаралтай гаргах, хүргэлт хийх гэх мэт асуудлуудтай тулгардаг. Тэд биднийг ямар нэг зүйлийн талаар байнга ярилцаж, маргаж байгааг ажиглаж, тэд үүнийг ингэж хардаг: яриа, яриа, яриа... Өөр ямар яриа вэ? Ажилдаа эргэн ор! Учир нь тэдэнд ярих нь ажил мэт санагддаггүй. Та код бичдэггүй, програм хангамжийг шалгадаггүй, юу ч хийхгүй байгаа юм шиг - яагаад чамайг ямар нэг зүйл хийлгэхээр илгээж болохгүй гэж? Эцсийн эцэст хүргэлт аль хэдийн сарын дараа байна!
Майкл: Явж код бичээрэй!
Тим: Тэд ажилдаа санаа зовдоггүй, харин ахиц дэвшил харагдахгүй байгаад санаа зовоод байх шиг байна. Амжилтанд ойртож байгаа мэт харагдуулахын тулд тэд биднийг гар дээрх товчлууруудыг дарж байгааг харах хэрэгтэй. Өглөөнөөс орой хүртэл бүтэн өдөр. Энэ бол номер нэг асуудал.
Олег: Миша, чи ямар нэг зүйлийн талаар бодож байна.
Майкл: Уучлаарай, би бодолд төөрч, эргэн санахад авлаа. Энэ бүхэн надад өчигдөр болсон нэгэн сонирхолтой жагсаалыг санагдууллаа... Өчигдөр хэтэрхий олон жагсаал цуглаан болсон... Тэгээд энэ бүхэн их танил сонсогдож байна!
Цалингүй амьдрал
Тим: Дашрамд хэлэхэд харилцаа холбооны "жагсаал" зохион байгуулах шаардлагагүй. Хөгжүүлэгчдийн хоорондох хамгийн ашигтай хэлэлцүүлэг нь тэд хоорондоо зүгээр л ярилцах үед болдог. Та өглөө аяга кофе барин орж ирэхэд таван хүн цугларч, ямар нэг техникийн талаар ширүүн ярилцаж байна. Миний хувьд, хэрэв би энэ төслийн менежер бол зүгээр л инээж, ажил хэргийнхээ талаар хаа нэг тийшээ явсан нь дээр. Тэд аль болох их оролцож байна. Энэ бол сайны шинж.
Олег: Дашрамд хэлэхэд, таны номонд юу сайн, юу нь муу вэ гэсэн олон тэмдэглэл бий. Та өөрөө аль нэгийг нь ашигладаг уу? Харьцангуйгаар хэлбэл, одоо та маш өвөрмөц байдлаар зохион байгуулагдсан компанитай болсон ...
Тим: Уламжлалт бус, гэхдээ энэ төхөөрөмж бидэнд төгс тохирно. Бид бие биенээ удаан хугацаанд мэддэг. Бид бие биедээ итгэдэг, хамтрагч болохоосоо өмнө маш их итгэдэг байсан. Мөн жишээ нь манайд цалин огт байхгүй. Бид зүгээр л ажилладаг, жишээ нь би үйлчлүүлэгчдээсээ мөнгө олсон бол бүх мөнгө надад очсон. Үүний дараа бид тухайн байгууллагад гишүүнчлэлийн татвар төлдөг бөгөөд энэ нь компанийг тэжээхэд хангалттай. Дээрээс нь бид бүгд өөр өөр зүйлээр мэргэшсэн. Жишээлбэл, би нягтлан бодогч нартай ажилладаг, татварын тайлан бөглөдөг, компанид янз бүрийн захиргааны ажил хийдэг, надад хэн ч мөнгө өгдөггүй. Жеймс, Том хоёр манай вэбсайт дээр ажилладаг бөгөөд хэн ч тэдэнд цалин өгдөггүй. Та төлбөрөө төлж байгаа цагт юу хийх хэрэгтэйг чинь хэн ч хэлэхгүй. Жишээлбэл, Том одоо өмнөхөөсөө хамаагүй бага ажилладаг. Одоо түүнд өөр ашиг сонирхол байгаа, тэр зарим зүйлийг Гильдийн төлөө бус хийдэг. Гэхдээ тэр төлбөрөө төлж байгаа цагт хэн ч түүн дээр ирээд “Хөөе, Том, ажилдаа ор!” гэж хэлэхгүй. Та хоёрын хооронд мөнгө байхгүй үед хамт ажиллагсадтайгаа харьцах нь маш хялбар байдаг. Одоо бидний харилцаа бол янз бүрийн мэргэжилтэй холбоотой үндсэн санаануудын нэг юм. Энэ нь ажилладаг бөгөөд энэ нь маш сайн ажилладаг.
Шилдэг зөвлөгөө
Майкл: "Хамгийн сайн зөвлөгөө" рүү буцахдаа үйлчлүүлэгчиддээ дахин дахин хэлэх зүйл байна уу? 80/20 гэсэн санаа байдаг бөгөөд зарим зөвлөгөө илүү олон удаа давтагддаг байх.
Тим: Баавгайтай вальс шиг ном бичвэл түүхийн замналыг өөрчилнө, хүмүүс зогсоно гэж би нэг удаа бодож байсан ч... За хар даа, компаниуд тэдэнд бүх зүйл сайхан байгаа мэт дүр эсгэдэг. Муу зүйл тохиолдсон даруйд тэдний хувьд цочирдол, гэнэтийн зүйл болдог. "Хараач, бид системийг туршиж үзсэн бөгөөд энэ нь системийн шалгалтанд тэнцээгүй бөгөөд энэ нь дахин гурван сарын төлөвлөгөөгүй ажил юм, яаж ийм зүйл тохиолдох вэ? Хэн мэдсэн бэ? Юу буруу болж болох вэ? Үнэнийг хэлэхэд та үүнд итгэж байна уу?
Одоо байгаа нөхцөл байдалд хэт уурлаж болохгүй гэж тайлбарлах гэж байна. Бид үүнийг ярилцаж, юу нь болохгүй байсан, ирээдүйд ийм зүйл гарахаас хэрхэн сэргийлэх талаар сайн ойлгох хэрэгтэй. Асуудал гарч ирвэл бид яаж тэмцэх вэ, түүнийг яаж барих вэ?
Миний хувьд энэ бүхэн аймшигтай санагдаж байна. Хүмүүс ээдрээтэй, уйтгартай асуудлуудтай тулгардаг бөгөөд хэрэв тэд зүгээр л хуруугаа завилж, хамгийн сайн сайхныг найдвал "хамгийн сайн" нь биелэх болно гэж дүр эсгэсээр байдаг. Үгүй ээ, ийм байдлаар ажиллахгүй.
Эрсдэлийн удирдлагын дадлага!
Майкл: Таны бодлоор хэчнээн байгууллага эрсдэлийн удирдлагын чиглэлээр ажилладаг вэ?
Тим: Хүмүүс зүгээр л эрсдэлээ бичээд, гарсан жагсаалтыг хараад ажилдаа ордог нь миний уурыг хүргээд байна. Үнэн хэрэгтээ тэдний хувьд эрсдэлийг тодорхойлох нь эрсдэлийн менежмент юм. Гэхдээ миний хувьд энэ нь асуух шалтгаан шиг санагдаж байна: за, жагсаалт байна, та яг юу өөрчлөх вэ? Та эдгээр эрсдлийг харгалзан стандарт үйлдлийн дарааллаа өөрчлөх хэрэгтэй. Хэрэв ажлын хамгийн хэцүү хэсэг байгаа бол та үүнийг даван туулах хэрэгтэй бөгөөд зөвхөн дараа нь илүү энгийн зүйл рүү шилжих хэрэгтэй. Эхний спринт дээр нарийн төвөгтэй асуудлыг шийдэж эхэл. Энэ нь аль хэдийн эрсдэлийн менежмент шиг харагдаж байна. Гэхдээ ихэнхдээ хүмүүс эрсдэлийн жагсаалтыг гаргасны дараа юу өөрчлөгдсөнийг хэлж чадахгүй.
Майкл: Гэсэн хэдий ч эдгээр компаниудын хэд нь эрсдэлийн менежментэд оролцож байна вэ, таван хувь нь?
Тим: Харамсалтай нь би үүнийг хэлэхийг үзэн ядаж байна, гэхдээ энэ бол маш ач холбогдолгүй хэсэг юм. Гэхдээ таваас дээш, учир нь үнэхээр том төслүүд байдаг бөгөөд тэд дор хаяж ямар нэг зүйл хийхгүй бол оршин тогтнох боломжгүй юм. Ядаж л 25% байвал их гайхна гэж хэлье. Жижиг төслүүд ихэвчлэн ийм асуултанд хариулдаг: хэрэв асуудал бидэнд нөлөөлж байвал бид үүнийг шийдэх болно. Дараа нь тэд өөрсдийгөө асуудалд амжилттай оруулж, асуудлын менежмент, хямралын менежментэд оролцдог. Асуудлыг шийдэх гэж оролдоод асуудал шийдэгдээгүй бол хямралын менежментэд тавтай морил.
Тийм ээ, "бид тулгамдсан асуудлыг шийдэх болно" гэж би байнга сонсдог. Бид мэдээж тэгэх үү? Бид үнэхээр шийдэх үү?
Олег: Та үүнийг гэнэн байдлаар хийж, төслийн дүрэмд чухал инвариантуудыг бичиж болно, хэрэв инвариантууд эвдэрвэл төслийг дахин эхлүүлнэ үү. Энэ нь маш хачирхалтай харагдаж байна.
Майкл: Тийм ээ, эрсдэл үүсэх үед төслийг зүгээр л дахин тодорхойлсон тохиолдол надад тохиолдсон. Сайхан, бинго, асуудал шийдэгдсэн, битгий санаа зов!
Тим: Дахин тохируулах товчийг дарцгаая! Үгүй ээ, ийм байдлаар ажиллахгүй.
DevOops 2019-ийн гол илтгэл
Майкл: Бид энэ ярилцлагын сүүлчийн асуултанд ирлээ. Та дараагийн DevOops-д үндсэн илтгэлээр ирэх гэж байна. Та хэлэх гэж байгаа зүйлийнхээ нууцын хөшгийг өргөж чадах уу?
Тим: Яг одоо тэдний зургаа нь ажлын соёл, байгууллагын ярьдаггүй дүрэм журмын тухай ном бичиж байна. Соёл нь байгууллагын үндсэн үнэт зүйлсээр тодорхойлогддог. Ер нь хүмүүс үүнийг анзаардаггүй ч олон жил зөвлөхөөр ажилласан болохоор анзаарч дассан. Та компанид орж, хэдхэн минутын дотор юу болж байгааг мэдэрч эхэлдэг. Бид үүнийг "амт" гэж нэрлэдэг. Заримдаа энэ үнэр үнэхээр сайхан, заримдаа үнэхээр сайхан үнэртэй байдаг. Янз бүрийн байгууллагын хувьд бүх зүйл өөр өөр байдаг.
Майкл: Би ч бас олон жил зөвлөхөөр ажиллаж байгаа бөгөөд таны юу яриад байгааг сайн ойлгож байна.
Тим: Үнэн хэрэгтээ, үндсэн илтгэл дээр ярих ёстой нэг зүйл бол бүх зүйлийг компани тодорхойлдоггүй явдал юм. Та болон танай баг хамт олны хувьд өөрийн гэсэн багийн соёлтой. Энэ нь бүхэл бүтэн компани эсвэл тусдаа хэлтэс, тусдаа баг байж болно. Гэхдээ та хэлэхээсээ өмнө, бидний итгэдэг зүйл энд байна, энд чухал зүйл байна ... Тодорхой үйлдлүүдийн ард байгаа үнэт зүйл, итгэл үнэмшилийг ойлгохоос өмнө та соёлыг өөрчилж чадахгүй. Зан төлөвийг ажиглахад хялбар байдаг ч итгэл үнэмшлийг хайхад хэцүү байдаг. DevOps бол бүх зүйл улам бүр төвөгтэй болж байгаагийн гайхалтай жишээ юм. Харилцан ойлголцол улам бүр төвөгтэй болж, илүү цэвэр, тодорхой болж чадахгүй байгаа тул та юунд итгэдэг, эргэн тойрныхоо хүмүүс юуны талаар чимээгүй байгаа талаар бодох хэрэгтэй.
Хэрэв та хурдан үр дүнд хүрэхийг хүсч байвал танд нэг сайхан сэдэв байна: "Би мэдэхгүй" гэж хэн ч хэлдэггүй компаниудыг харж байсан уу? Хүнийг ямар нэгэн зүйл мэдэхгүй гэдгээ хүлээн зөвшөөрөх хүртэл нь тамлаж байдаг газар байдаг. Хүн бүр бүгдийг мэддэг, хүн бүр гайхалтай мэдлэгтэй байдаг. Та ямар ч хүнд ханддаг, тэр даруй асуултанд хариулах ёстой. "Би мэдэхгүй" гэж хэлэхийн оронд. Өө, тэд хэдэн эрдэмтнийг хөлсөлсөн! Зарим соёлд "Би мэдэхгүй" гэж хэлэх нь ерөнхийдөө маш аюултай бөгөөд үүнийг сул дорой байдлын шинж тэмдэг гэж ойлгож болно. Эсрэгээрээ хүн бүр "Би мэдэхгүй" гэж хэлж чаддаг байгууллагууд бас байдаг. Тэнд энэ нь бүрэн хууль ёсны бөгөөд хэрэв хэн нэгэн асуултанд хариулахдаа хогийн үг хэлж эхэлбэл: "Чи юу ярьж байгаагаа мэдэхгүй байна, тийм үү?" гэж хариулах нь хэвийн зүйл юм. тэгээд бүгдийг нь хошигнол болгон хувирга.
Та үргэлж аз жаргалтай байх ажилтай болмоор байна. Энэ нь амаргүй байх болно, өдөр бүр нартай, тааламжтай байдаггүй, заримдаа шаргуу ажиллах шаардлагатай байдаг, гэхдээ та дүгнэлт хийж эхлэхэд: хөөе, энэ үнэхээр гайхалтай газар юм, би энд ажиллахад таатай байна, сэтгэл санааны хувьд ч, оюун ухааны хувьд ч. Зөвлөхөөр очоод гурван сар тэвчиж чадалгүй айж зугтахаа шууд ойлгодог компаниуд байдаг. Энэ бол миний илтгэл дээр ярих гэсэн юм.
Тим Листер үндсэн илтгэлээр ирэх болно 2019 оны 29-р сарын 30-2019-ны өдрүүдэд Санкт-Петербургт болох DevOops XNUMX чуулганд. Та тасалбар худалдаж авах боломжтой . Бид таныг DevOops дээр хүлээж байна!
Эх сурвалж: www.habr.com