វាត្រូវបានគេដឹងថាសមត្ថភាពរបស់ CTO ត្រូវបានសាកល្បងតែលើកទីពីរដែលគាត់បំពេញតួនាទីនេះ។ ដោយសារតែវាជារឿងមួយដែលធ្វើការនៅក្នុងក្រុមហ៊ុនអស់រយៈពេលជាច្រើនឆ្នាំ វិវត្តន៍ជាមួយវា ហើយនៅក្នុងបរិបទវប្បធម៌ដូចគ្នា បន្តិចម្តងៗទទួលបានទំនួលខុសត្រូវកាន់តែច្រើន។ ហើយវាជារឿងមួយទៀតដែលចូលមកក្នុងមុខតំណែងជានាយកបច្ចេកទេសនៅក្រុមហ៊ុនដែលមានឥវ៉ាន់កេរដំណែល និងបញ្ហាជាច្រើនត្រូវបានបោសសម្អាតយ៉ាងស្អាតនៅក្រោមកម្រាលព្រំ។

ក្នុងន័យនេះ បទពិសោធន៍របស់ Leon Fire ដែលគាត់បានចែករំលែក DevOpsConfវាមិនប្លែកទេ ប៉ុន្តែគុណនឹងបទពិសោធន៍របស់គាត់ និងចំនួនតួនាទីផ្សេងៗគ្នា ដែលគាត់បានព្យាយាមក្នុងរយៈពេល 20 ឆ្នាំ វាពិតជាមានប្រយោជន៍ខ្លាំងណាស់។ ខាងក្រោមនេះជាការកាត់តគឺជាកាលប្បវត្តិនៃព្រឹត្តិការណ៍ជាង 90 ថ្ងៃ និងរឿងជាច្រើនដែលគួរឱ្យអស់សំណើចនៅពេលដែលវាកើតឡើងចំពោះអ្នកដ៏ទៃ ប៉ុន្តែអ្វីដែលមិនគួរឱ្យរីករាយក្នុងការប្រឈមមុខនឹងមនុស្សម្នាក់។

Leon និយាយជាភាសារុស្សីច្រើនពណ៌ ដូច្នេះប្រសិនបើអ្នកមានពេល 35-40 នាទី ខ្ញុំសូមណែនាំឱ្យមើលវីដេអូ។ កំណែអត្ថបទដើម្បីសន្សំសំចៃពេលវេលាខាងក្រោម។

កំណែដំបូងនៃរបាយការណ៍គឺជាការពិពណ៌នាដែលមានរចនាសម្ព័ន្ធល្អនៃការធ្វើការជាមួយមនុស្ស និងដំណើរការដែលមានការណែនាំមានប្រយោជន៍។ ប៉ុន្តែនាងមិនបានបង្ហាញពីការភ្ញាក់ផ្អើលទាំងអស់ដែលបានជួបប្រទះនៅតាមផ្លូវនោះទេ។ ដូច្នេះហើយ ខ្ញុំបានផ្លាស់ប្តូរទម្រង់ និងបង្ហាញបញ្ហាដែលលេចឡើងនៅចំពោះមុខខ្ញុំ ដូចជា Jack-in-the-box នៅក្នុងក្រុមហ៊ុនថ្មី និងវិធីសាស្រ្តសម្រាប់ដោះស្រាយវាតាមលំដាប់លំដោយ។

មួយខែមុន។

ដូចរឿងល្អៗជាច្រើន រឿងនេះចាប់ផ្តើមពីគ្រឿងស្រវឹង។ យើងកំពុងអង្គុយជាមួយមិត្តភ័ក្តិនៅក្នុងបារមួយ ហើយដូចការរំពឹងទុកក្នុងចំណោមអ្នកជំនាញផ្នែកព័ត៌មានវិទ្យា គ្រប់គ្នាកំពុងយំអំពីបញ្ហារបស់ពួកគេ។ ម្នាក់ក្នុងចំណោមពួកគេទើបតែផ្លាស់ប្តូរការងារ ហើយកំពុងនិយាយអំពីបញ្ហារបស់គាត់ជាមួយនឹងបច្ចេកវិទ្យា និងជាមួយមនុស្ស និងជាមួយក្រុម។ កាន់តែស្តាប់ខ្ញុំកាន់តែដឹងថាគាត់គួរតែជួលខ្ញុំ ព្រោះទាំងនេះគឺជាបញ្ហាដែលខ្ញុំបានដោះស្រាយអស់រយៈពេល ១៥ ឆ្នាំចុងក្រោយនេះ។ ខ្ញុំ​បាន​ប្រាប់​គាត់​ដូច្នេះ ហើយ​ថ្ងៃ​បន្ទាប់​យើង​បាន​ជួប​គ្នា​ក្នុង​បរិយាកាស​ការងារ។ ក្រុមហ៊ុននេះត្រូវបានគេហៅថា យុទ្ធសាស្ត្របង្រៀន។

យុទ្ធសាស្ត្របង្រៀនគឺជាទីផ្សារឈានមុខគេក្នុងកម្មវិធីសិក្សាសម្រាប់កុមារតូចៗចាប់ពីកំណើតដល់អាយុបីឆ្នាំ។ ក្រុមហ៊ុន "ក្រដាស" បែបប្រពៃណីមានអាយុ 40 ឆ្នាំហើយ ហើយកំណែឌីជីថល SaaS នៃវេទិកានេះមានអាយុ 10 ឆ្នាំ។ ថ្មីៗនេះ ដំណើរការនៃការកែសម្រួលបច្ចេកវិទ្យាឌីជីថលទៅនឹងស្តង់ដាររបស់ក្រុមហ៊ុនបានចាប់ផ្តើម។ កំណែ "ថ្មី" បានចាប់ផ្តើមនៅឆ្នាំ 2017 ហើយស្ទើរតែដូចកំណែចាស់ មានតែវាដំណើរការកាន់តែអាក្រក់។

អ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺថាចរាចរណ៍របស់ក្រុមហ៊ុននេះគឺអាចព្យាករណ៍បាន - ពីមួយថ្ងៃទៅមួយថ្ងៃ ពីមួយឆ្នាំទៅមួយឆ្នាំ អ្នកអាចទស្សន៍ទាយបានយ៉ាងច្បាស់ថាតើមានមនុស្សប៉ុន្មាននាក់នឹងមកនៅពេលណា។ ជាឧទាហរណ៍ ចាប់ពីម៉ោង 13 ដល់ម៉ោង 15 រសៀល កុមារទាំងអស់នៅក្នុងសាលាមត្តេយ្យចូលគេង ហើយគ្រូបង្រៀនចាប់ផ្តើមបញ្ចូលព័ត៌មាន។ ហើយរឿងនេះកើតឡើងជារៀងរាល់ថ្ងៃ លើកលែងតែចុងសប្តាហ៍ ព្រោះស្ទើរតែគ្មាននរណាម្នាក់ធ្វើការនៅចុងសប្តាហ៍។

សម្លឹងទៅមុខបន្តិច ខ្ញុំនឹងកត់សម្គាល់ថាខ្ញុំចាប់ផ្តើមការងាររបស់ខ្ញុំក្នុងអំឡុងពេលនៃចរាចរណ៍ប្រចាំឆ្នាំខ្ពស់បំផុត ដែលគួរឱ្យចាប់អារម្មណ៍សម្រាប់ហេតុផលផ្សេងៗ។

វេទិកាដែលហាក់ដូចជាមានអាយុត្រឹមតែ 2 ឆ្នាំប៉ុណ្ណោះ មានជង់ពិសេសមួយ៖ ColdFusion & SQL Server ពីឆ្នាំ 2008 ។ ColdFusion ប្រសិនបើអ្នកមិនដឹង ហើយអ្នកទំនងជាមិនដឹង គឺជា PHP សហគ្រាសដែលបានចេញនៅពាក់កណ្តាលទសវត្សរ៍ទី 90 ហើយចាប់តាំងពីពេលនោះមកខ្ញុំក៏មិនបានឮអំពីវាដែរ។ វាក៏មាន៖ Ruby, MySQL, PostgreSQL, Java, Go, Python ។ ប៉ុន្តែ monolith សំខាន់ដំណើរការលើ ColdFusion និង SQL Server ។

បញ្ហា

កាលណាខ្ញុំនិយាយជាមួយបុគ្គលិកក្រុមហ៊ុនកាន់តែច្រើនអំពីការងារ និងបញ្ហាអ្វីដែលត្រូវជួបប្រទះ នោះខ្ញុំកាន់តែដឹងថាបញ្ហាមិនត្រឹមតែមានលក្ខណៈបច្ចេកទេសប៉ុណ្ណោះទេ។ មិនអីទេ បច្ចេកវិទ្យាចាស់ហើយ ពួកគេមិនដំណើរការលើវាទេ ប៉ុន្តែមានបញ្ហាជាមួយក្រុម និងដំណើរការនានា ហើយក្រុមហ៊ុនបានចាប់ផ្តើមយល់ពីរឿងនេះ។

ជាប្រពៃណី អ្នកបច្ចេកទេសរបស់ពួកគេអង្គុយនៅជ្រុងម្ខាង ហើយធ្វើការងារមួយចំនួន។ ប៉ុន្តែអាជីវកម្មកាន់តែច្រើនឡើងបានចាប់ផ្តើមឆ្លងកាត់កំណែឌីជីថល។ ដូច្នេះហើយ ក្នុងឆ្នាំចុងក្រោយមុនខ្ញុំចាប់ផ្តើមធ្វើការ អ្នកថ្មីបានបង្ហាញខ្លួននៅក្នុងក្រុមហ៊ុន៖ ក្រុមប្រឹក្សាភិបាល CTO CPO និងនាយក QA ។ នោះគឺក្រុមហ៊ុនបានចាប់ផ្តើមវិនិយោគលើវិស័យបច្ចេកវិទ្យា។

ដាននៃកេរដំណែលដ៏ធ្ងន់មួយមិនត្រឹមតែនៅក្នុងប្រព័ន្ធប៉ុណ្ណោះទេ។ ក្រុមហ៊ុនមានដំណើរការកេរដំណែល មនុស្សកេរដំណែល វប្បធម៌កេរដំណែល។ ទាំងអស់នេះត្រូវតែផ្លាស់ប្តូរ។ ខ្ញុំ​បាន​គិត​ថា វា​ច្បាស់​ជា​មិន​គួរ​ឱ្យ​ធុញ​ទេ ហើយ​បាន​សម្រេច​ចិត្ត​សាកល្បង​វា។

ពីរថ្ងៃមុន។

ពីរថ្ងៃមុនពេលចាប់ផ្តើមការងារថ្មី ខ្ញុំបានទៅដល់ការិយាល័យ បំពេញឯកសារចុងក្រោយ ជួបក្រុម ហើយបានដឹងថាក្រុមកំពុងជួបបញ្ហានៅពេលនោះ។ វាគឺថាពេលវេលាផ្ទុកទំព័រជាមធ្យមលោតដល់ 4 វិនាទី ពោលគឺ 2 ដង។

ដោយវិនិច្ឆ័យតាមក្រាហ្វ អ្វីមួយបានកើតឡើងយ៉ាងច្បាស់ ហើយវាមិនច្បាស់ថាអ្វីនោះទេ។ វាប្រែថាបញ្ហាគឺភាពយឺតនៃបណ្តាញនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ៖ ភាពយឺតយ៉ាវ 5 ms នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យប្រែទៅជា 2 វិនាទីសម្រាប់អ្នកប្រើប្រាស់។ ខ្ញុំ​មិន​ដឹង​ថា​ហេតុ​អ្វី​បាន​ជា​វា​កើត​ឡើង ប៉ុន្តែ​ក្នុង​ករណី​ណា​មួយ​វា​បាន​ដឹង​ថា​បញ្ហា​គឺ​នៅ​ក្នុង​មជ្ឈមណ្ឌល​ទិន្នន័យ។

ថ្ងៃដំបូង

ពីរថ្ងៃបានកន្លងផុតទៅ ហើយនៅថ្ងៃធ្វើការដំបូងរបស់ខ្ញុំ ខ្ញុំបានរកឃើញថាបញ្ហាមិនបាត់ទៅណាទេ។

សម្រាប់រយៈពេលពីរថ្ងៃ ទំព័ររបស់អ្នកប្រើប្រាស់បានផ្ទុកជាមធ្យមក្នុងរយៈពេល 4 វិនាទី។ ខ្ញុំសួរថាតើពួកគេបានរកឃើញបញ្ហាអ្វី

- បាទ, យើងបានបើកសំបុត្រមួយ។
- និង?
- មែនហើយ គេមិនទាន់ឆ្លើយយើងទេ។

បន្ទាប់មកខ្ញុំបានដឹងថាអ្វីគ្រប់យ៉ាងដែលខ្ញុំត្រូវបានគេប្រាប់ពីមុនគ្រាន់តែជាព័ត៌មានតូចមួយនៃផ្ទាំងទឹកកកដែលខ្ញុំត្រូវប្រយុទ្ធ។

មាន​សម្រង់​ដ៏​ល្អ​មួយ​ដែល​សម​នឹង​ចំណុច​នេះ​យ៉ាង​ល្អ៖

"ពេលខ្លះដើម្បីផ្លាស់ប្តូរបច្ចេកវិទ្យា អ្នកត្រូវតែផ្លាស់ប្តូរអង្គភាព។"

ប៉ុន្តែចាប់តាំងពីខ្ញុំចាប់ផ្តើមការងារនៅពេលមមាញឹកបំផុតនៃឆ្នាំនេះ ខ្ញុំត្រូវមើលជម្រើសទាំងពីរសម្រាប់ការដោះស្រាយបញ្ហា៖ ទាំងរហ័ស និងរយៈពេលវែង។ ហើយចាប់ផ្តើមជាមួយនឹងអ្វីដែលសំខាន់ឥឡូវនេះ។

ថ្ងៃទី ៣ ។

ដូច្នេះការផ្ទុកមានរយៈពេល 4 វិនាទីហើយពី 13 ទៅ 15 កំពូលខ្ពស់បំផុត។

នៅថ្ងៃទីបីក្នុងអំឡុងពេលនេះ ល្បឿនទាញយកមើលទៅដូចនេះ៖

តាមទស្សនៈរបស់ខ្ញុំ គ្មានអ្វីដំណើរការទាល់តែសោះ។ តាមទស្សនៈរបស់មនុស្សគ្រប់គ្នា វាដំណើរការយឺតជាងធម្មតា។ ប៉ុន្តែវាមិនកើតឡើងដូច្នេះទេ - វាជាបញ្ហាធ្ងន់ធ្ងរ។

ខ្ញុំបានព្យាយាមបញ្ចុះបញ្ចូលក្រុម ដែលពួកគេបានឆ្លើយថា ពួកគេគ្រាន់តែត្រូវការម៉ាស៊ីនមេបន្ថែមទៀត។ នេះពិតណាស់គឺជាដំណោះស្រាយចំពោះបញ្ហា ប៉ុន្តែវាមិនតែងតែជាដំណោះស្រាយតែមួយគត់ និងមានប្រសិទ្ធភាពបំផុតនោះទេ។ ខ្ញុំបានសួរថាហេតុអ្វីបានជាមានម៉ាស៊ីនមេមិនគ្រប់គ្រាន់ តើបរិមាណចរាចរគឺជាអ្វី ខ្ញុំបានស្រង់ទិន្នន័យ ហើយបានរកឃើញថា យើងមានសំណើប្រហែល 150 ក្នុងមួយវិនាទី ដែលតាមគោលការណ៍ ស្ថិតក្នុងដែនកំណត់សមហេតុផល។

ប៉ុន្តែយើងមិនត្រូវភ្លេចថាមុនពេលអ្នកទទួលបានចម្លើយត្រឹមត្រូវ អ្នកត្រូវសួរសំណួរដែលត្រឹមត្រូវ។ សំណួរបន្ទាប់របស់ខ្ញុំគឺ៖ តើយើងមានម៉ាស៊ីនមេផ្នែកខាងមុខប៉ុន្មាន? ចម្លើយ "ធ្វើឱ្យខ្ញុំភ្ញាក់ផ្អើលបន្តិច" - យើងមាន 17 ម៉ាស៊ីនមេផ្នែកខាងមុខ!

- ខ្ញុំខ្មាស់អៀនក្នុងការសួរ ប៉ុន្តែ 150 ចែកនឹង 17 ផ្តល់ឱ្យប្រហែល 8? តើអ្នកនិយាយថាម៉ាស៊ីនមេនីមួយៗអនុញ្ញាត 8 សំណើក្នុងមួយវិនាទី ហើយប្រសិនបើថ្ងៃស្អែកមានសំណើ 160 ក្នុងមួយវិនាទី យើងនឹងត្រូវការម៉ាស៊ីនមេ 2 បន្ថែមទៀត?

ជាការពិតណាស់ យើងមិនត្រូវការម៉ាស៊ីនមេបន្ថែមទេ។ ដំណោះ​ស្រាយ​គឺ​នៅ​ក្នុង​កូដ​ខ្លួន​វា​ផ្ទាល់​និង​នៅ​លើ​ផ្ទៃ​:

var currentClass = classes.getCurrentClass();
return currentClass;

មានមុខងារមួយ។ getCurrentClass()ពីព្រោះអ្វីៗទាំងអស់នៅលើគេហទំព័រដំណើរការក្នុងបរិបទនៃថ្នាក់ - នោះជាការត្រឹមត្រូវ។ ហើយសម្រាប់មុខងារមួយនេះនៅលើទំព័រនីមួយៗមាន 200+ សំណើ.

ដំណោះ​ស្រាយ​តាម​វិធី​នេះ​គឺ​សាមញ្ញ​ណាស់ អ្នក​មិន​ចាំបាច់​សរសេរ​អ្វី​ឡើង​វិញ​ទេ៖ គ្រាន់​តែ​កុំ​សួរ​រក​ព័ត៌មាន​ដដែល​ម្ដង​ទៀត។

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

ខ្ញុំ​សប្បាយ​ចិត្ត​ណាស់​ព្រោះ​ខ្ញុំ​សម្រេច​ចិត្ត​ថា​នៅ​ថ្ងៃ​ទី​បី​ខ្ញុំ​បាន​រក​ឃើញ​បញ្ហា​ចម្បង។ ឆោតល្ងង់ដូចខ្ញុំ នេះគ្រាន់តែជាបញ្ហាមួយក្នុងចំណោមបញ្ហាជាច្រើន។

ប៉ុន្តែ​ការ​ដោះស្រាយ​បញ្ហា​ដំបូង​នេះ​បាន​ទម្លាក់​ក្រាហ្វ​កាន់តែ​ទាប។

ក្នុងពេលជាមួយគ្នានេះ យើងកំពុងធ្វើការបង្កើនប្រសិទ្ធភាពផ្សេងទៀត។ មាន​រឿង​ជា​ច្រើន​នៅ​ក្នុង​ការ​មើល​ឃើញ​ដែល​អាច​ត្រូវ​បាន​ជួសជុល។ ជាឧទាហរណ៍ នៅថ្ងៃទីបីដូចគ្នា ខ្ញុំបានរកឃើញថាមានឃ្លាំងសម្ងាត់នៅក្នុងប្រព័ន្ធ (ដំបូងខ្ញុំគិតថាសំណើទាំងអស់បានមកដោយផ្ទាល់ពីមូលដ្ឋានទិន្នន័យ)។ នៅពេលខ្ញុំគិតពីឃ្លាំងសម្ងាត់ ខ្ញុំគិតពីស្តង់ដារ Redis ឬ Memcached ។ ប៉ុន្តែខ្ញុំជាមនុស្សតែម្នាក់គត់ដែលគិតដូច្នេះ ពីព្រោះប្រព័ន្ធនោះបានប្រើ MongoDB និង SQL Server សម្រាប់ឃ្លាំងសម្ងាត់ ដែលជាទិន្នន័យតែមួយដែលទើបតែបានអាន។

ថ្ងៃទីដប់

សប្តាហ៍ដំបូងដែលខ្ញុំបានដោះស្រាយបញ្ហាដែលចាំបាច់ត្រូវដោះស្រាយនៅពេលនេះ។ នៅកន្លែងណាមួយក្នុងសប្តាហ៍ទី 2 ខ្ញុំបានមកឈរឡើងជាលើកដំបូងដើម្បីទាក់ទងជាមួយក្រុម ដើម្បីមើលថាតើមានអ្វីកើតឡើង និងរបៀបដែលដំណើរការទាំងមូលកំពុងដំណើរការ។

អ្វីដែលគួរឱ្យចាប់អារម្មណ៍ត្រូវបានរកឃើញម្តងទៀត។ ក្រុមនេះមាន: អ្នកអភិវឌ្ឍន៍ 18; 8 អ្នកសាកល្បង; អ្នកគ្រប់គ្រង ៣ នាក់; ស្ថាបត្យករ ២ រូប។ ហើយពួកគេទាំងអស់គ្នាបានចូលរួមក្នុងពិធីធម្មតា ពោលគឺមនុស្សជាង 3 នាក់បានមកឈរនៅរាល់ព្រឹក ហើយប្រាប់ពីអ្វីដែលពួកគេបានធ្វើ។ វាច្បាស់ណាស់ថាកិច្ចប្រជុំមិនបានចំណាយពេល 2 ឬ 30 នាទី។ គ្មាន​នរណា​ម្នាក់​ស្តាប់​នរណា​ម្នាក់​ទេ​ព្រោះ​អ្នក​រាល់​គ្នា​ធ្វើ​ការ​នៅ​លើ​ប្រព័ន្ធ​ផ្សេង​គ្នា​។ នៅក្នុងទម្រង់នេះ សំបុត្រ 5-15 ក្នុងមួយម៉ោងសម្រាប់វគ្គសម្អាងការគឺជាលទ្ធផលដ៏ល្អរួចទៅហើយ។

រឿងដំបូងដែលយើងបានធ្វើគឺបំបែកក្រុមទៅជាបន្ទាត់ផលិតផលជាច្រើន។ សម្រាប់ផ្នែក និងប្រព័ន្ធផ្សេងៗ យើងបានបែងចែកក្រុមដាច់ដោយឡែក ដែលរួមមានអ្នកអភិវឌ្ឍន៍ អ្នកសាកល្បង អ្នកគ្រប់គ្រងផលិតផល និងអ្នកវិភាគអាជីវកម្ម។

ជាលទ្ធផលយើងទទួលបាន៖

• កាត់បន្ថយការក្រោកឈរ និងការប្រមូលផ្តុំ។
• ចំណេះដឹងអំពីផលិតផល។
• អារម្មណ៍នៃភាពជាម្ចាស់។ នៅពេលដែលមនុស្សប្រើដើម្បី tinker ជាមួយប្រព័ន្ធគ្រប់ពេលវេលា ពួកគេដឹងថានរណាម្នាក់ផ្សេងទៀតទំនងជាត្រូវធ្វើការជាមួយកំហុសរបស់ពួកគេ ប៉ុន្តែមិនមែនខ្លួនពួកគេទេ។
• កិច្ចសហប្រតិបត្តិការរវាងក្រុម។ មិនចាំបាច់និយាយទេ QA មិនបានប្រាស្រ័យទាក់ទងច្រើនជាមួយអ្នកសរសេរកម្មវិធីពីមុនទេ ផលិតផលបានធ្វើដោយខ្លួនឯង ។ល។ ឥឡូវនេះពួកគេមានចំណុចរួមនៃការទទួលខុសត្រូវ។

យើងផ្តោតជាសំខាន់លើប្រសិទ្ធភាព ផលិតភាព និងគុណភាព - ទាំងនេះគឺជាបញ្ហាដែលយើងបានព្យាយាមដោះស្រាយជាមួយនឹងការផ្លាស់ប្តូរក្រុម។

ថ្ងៃទីដប់មួយ។

នៅក្នុងដំណើរការនៃការផ្លាស់ប្តូររចនាសម្ព័ន្ធក្រុម ខ្ញុំបានរកឃើញពីរបៀបរាប់ រឿងពិន្ទុ. 1 SP គឺស្មើនឹងមួយថ្ងៃ ហើយសំបុត្រនីមួយៗមាន SP សម្រាប់ទាំងការអភិវឌ្ឍន៍ និង QA ពោលគឺយ៉ាងហោចណាស់ 2 SP ។

តើខ្ញុំបានរកឃើញនេះដោយរបៀបណា?

យើងបានរកឃើញកំហុសមួយ៖ នៅក្នុងរបាយការណ៍មួយ ដែលកាលបរិច្ឆេទចាប់ផ្តើម និងបញ្ចប់នៃរយៈពេលដែលត្រូវការរបាយការណ៍ត្រូវបានបញ្ចូល ថ្ងៃចុងក្រោយមិនត្រូវបានយកមកពិចារណាទេ។ នោះគឺនៅកន្លែងណាមួយនៅក្នុងសំណើមិនមាន <= ប៉ុន្តែគ្រាន់តែ <។ ខ្ញុំ​ត្រូវ​បាន​គេ​ប្រាប់​ថា​នេះ​គឺ​ជា​ចំណុច​រឿង​បី​, នោះ​គឺ​ 3 ថ្ងៃ.

បន្ទាប់ពីនេះយើង:

• ប្រព័ន្ធវាយតម្លៃ Story Points ត្រូវបានកែសម្រួល។ ឥឡូវនេះជួសជុលសម្រាប់កំហុសតូចតាចដែលអាចត្រូវបានឆ្លងកាត់យ៉ាងលឿនតាមរយៈប្រព័ន្ធទៅដល់អ្នកប្រើប្រាស់លឿនជាងមុន។
• យើងបានចាប់ផ្តើមបញ្ចូលគ្នានូវសំបុត្រដែលពាក់ព័ន្ធសម្រាប់ការអភិវឌ្ឍន៍ និងការធ្វើតេស្ត។ ពីមុន រាល់សំបុត្រ រាល់កំហុស គឺជាប្រព័ន្ធអេកូបិទជិត មិនជាប់នឹងអ្វីផ្សេងទេ។ ការផ្លាស់ប្តូរប៊ូតុងបីនៅលើទំព័រមួយអាចជាសំបុត្របីផ្សេងគ្នាជាមួយនឹងដំណើរការ QA ផ្សេងគ្នាចំនួនបីជំនួសឱ្យការធ្វើតេស្តស្វ័យប្រវត្តិមួយក្នុងមួយទំព័រ។
• យើងបានចាប់ផ្តើមធ្វើការជាមួយអ្នកអភិវឌ្ឍន៍លើវិធីសាស្រ្តក្នុងការប៉ាន់ប្រមាណតម្លៃពលកម្ម។ បីថ្ងៃដើម្បីប្តូរប៊ូតុងមួយគឺមិនគួរឱ្យអស់សំណើចទេ។

ថ្ងៃទីម្ភៃ

នៅកន្លែងណាមួយនៅពាក់កណ្តាលខែដំបូង ស្ថានការណ៍មានស្ថិរភាពបន្តិច ខ្ញុំបានស្វែងយល់ពីអ្វីដែលជាមូលដ្ឋានកំពុងកើតឡើង ហើយបានចាប់ផ្តើមសម្លឹងមើលទៅអនាគតរួចហើយ ហើយគិតអំពីដំណោះស្រាយរយៈពេលវែង។

គោលដៅរយៈពេលវែង៖

• វេទិកាគ្រប់គ្រង។ សំណើរាប់រយនៅលើទំព័រនីមួយៗមិនធ្ងន់ធ្ងរទេ។
• និន្នាការដែលអាចទស្សន៍ទាយបាន។ មានកម្រិតចរាចរណ៍តាមកាលកំណត់ដែលនៅក្រឡេកមើលដំបូងមិនទាក់ទងជាមួយម៉ែត្រផ្សេងទៀតទេ យើងត្រូវយល់ពីមូលហេតុដែលវាកើតឡើង ហើយរៀនទាយ។
• ការពង្រីកវេទិកា។ អាជីវកម្មកំពុងរីកចម្រើនឥតឈប់ឈរ អ្នកប្រើប្រាស់កាន់តែច្រើនឡើង ហើយចរាចរណ៍ក៏កើនឡើង។

កាលពីមុនគេច្រើនតែនិយាយថា៖ "តោះ​សរសេរ​អ្វី​គ្រប់​យ៉ាង​ជា​ [ភាសា/ក្របខណ្ឌ] អ្វី​គ្រប់​យ៉ាង​នឹង​ដំណើរការ​កាន់​តែ​ប្រសើរ!"

ក្នុងករណីភាគច្រើនវាមិនដំណើរការទេ វាជាការល្អប្រសិនបើការសរសេរឡើងវិញដំណើរការទាំងអស់។ ដូច្នេះហើយ យើងត្រូវបង្កើតផែនទីបង្ហាញផ្លូវ ដែលជាយុទ្ធសាស្ត្រជាក់លាក់មួយ ដែលបង្ហាញជាជំហានៗពីរបៀបដែលគោលដៅអាជីវកម្មនឹងត្រូវបានសម្រេច (អ្វីដែលយើងនឹងធ្វើ និងហេតុអ្វី) ដែល៖

• ឆ្លុះបញ្ចាំងពីបេសកកម្ម និងគោលដៅនៃគម្រោង។
• ផ្តល់អាទិភាពដល់គោលដៅសំខាន់ៗ;
• មានកាលវិភាគសម្រាប់ការសម្រេចបាន។

មុននេះ គ្មាននរណាម្នាក់បាននិយាយជាមួយក្រុមអំពីគោលបំណងនៃការផ្លាស់ប្តូរណាមួយដែលត្រូវបានធ្វើឡើងនោះទេ។ នេះទាមទាររង្វាស់ជោគជ័យត្រឹមត្រូវ។ ជាលើកដំបូងនៅក្នុងប្រវត្តិសាស្រ្តរបស់ក្រុមហ៊ុន យើងកំណត់ KPIs សម្រាប់ក្រុមបច្ចេកទេស ហើយសូចនាករទាំងនេះត្រូវបានចងភ្ជាប់ទៅនឹងស្ថាប័ន។

នោះគឺ KPIs របស់អង្គការត្រូវបានគាំទ្រដោយក្រុម ហើយ KPIs ក្រុមត្រូវបានគាំទ្រដោយ KPIs នីមួយៗ។ បើមិនដូច្នេះទេ ប្រសិនបើ KPIs បច្ចេកវិជ្ជាមិនស្របគ្នានឹងស្ថាប័នទេ នោះអ្នកគ្រប់គ្នាទាញភួយមកលើខ្លួនឯង។

ឧទាហរណ៍ KPIs របស់ស្ថាប័នមួយកំពុងបង្កើនចំណែកទីផ្សារតាមរយៈផលិតផលថ្មី។

តើអ្នកអាចគាំទ្រគោលដៅនៃការមានផលិតផលថ្មីបន្ថែមទៀតដោយរបៀបណា?

• ដំបូង យើង​ចង់​ចំណាយ​ពេល​ច្រើន​ក្នុង​ការ​បង្កើត​ផលិតផល​ថ្មី ជាជាង​ការ​ជួសជុល​កំហុស។ នេះគឺជាដំណោះស្រាយឡូជីខលដែលងាយស្រួលក្នុងការវាស់វែង។
• ទីពីរ យើងចង់គាំទ្រការកើនឡើងនៃបរិមាណប្រតិបត្តិការ ពីព្រោះចំណែកទីផ្សារកាន់តែច្រើន អ្នកប្រើប្រាស់កាន់តែច្រើន ហើយតាមនោះ ចរាចរណ៍ក៏កាន់តែច្រើន។

បន្ទាប់មក KPIs បុគ្គលដែលអាចត្រូវបានប្រតិបត្តិក្នុងក្រុមនឹងជាឧទាហរណ៍នៅកន្លែងដែលពិការភាពចម្បងមកពី។ ប្រសិនបើអ្នកផ្តោតជាពិសេសលើផ្នែកនេះ អ្នកអាចធ្វើឱ្យប្រាកដថាមានគុណវិបត្តិតិចជាងមុន ហើយបន្ទាប់មកពេលវេលាសម្រាប់ការអភិវឌ្ឍផលិតផលថ្មី ហើយម្តងទៀតសម្រាប់ការគាំទ្រ KPIs របស់ស្ថាប័ននឹងកើនឡើង។

ដូច្នេះ រាល់ការសម្រេចចិត្ត រួមទាំងការសរសេរកូដឡើងវិញ ត្រូវតែគាំទ្រដល់គោលដៅជាក់លាក់ដែលក្រុមហ៊ុនបានកំណត់សម្រាប់យើង (ការរីកលូតលាស់នៃអង្គការ លក្ខណៈពិសេសថ្មី ការជ្រើសរើសបុគ្គលិក)។

ក្នុងអំឡុងពេលដំណើរការនេះ រឿងគួរឱ្យចាប់អារម្មណ៍មួយបានកើតឡើង ដែលបានក្លាយជាព័ត៌មានមិនត្រឹមតែសម្រាប់បច្ចេកវិទ្យាប៉ុណ្ណោះទេ ប៉ុន្តែជាទូទៅនៅក្នុងក្រុមហ៊ុន៖ សំបុត្រទាំងអស់ត្រូវតែផ្តោតលើយ៉ាងហោចណាស់មួយ KPI ។ នោះគឺប្រសិនបើផលិតផលមួយនិយាយថាខ្លួនចង់បង្កើតមុខងារថ្មី សំណួរដំបូងគួរតែត្រូវបានសួរថា "តើ KPI នេះគាំទ្រមុខងារអ្វីខ្លះ?" បើមិនដូច្នោះទេសូមអភ័យទោស - វាហាក់ដូចជាលក្ខណៈពិសេសដែលមិនចាំបាច់។

ថ្ងៃទីសាមសិប

នៅចុងខែនេះ ខ្ញុំបានរកឃើញភាពខុសប្លែកមួយទៀត៖ គ្មាននរណាម្នាក់នៅក្នុងក្រុម Ops របស់ខ្ញុំមិនដែលឃើញកិច្ចសន្យាដែលយើងបញ្ចូលជាមួយអតិថិជននោះទេ។ អ្នកអាចសួរថាហេតុអ្វីបានជាអ្នកត្រូវការមើលទំនាក់ទំនង។

• ទីមួយ ដោយសារ SLAs ត្រូវបានបញ្ជាក់នៅក្នុងកិច្ចសន្យា។
• ទីពីរ SLAs គឺខុសគ្នាទាំងអស់។ អតិថិជនម្នាក់ៗបានមកជាមួយនឹងតម្រូវការផ្ទាល់ខ្លួនរបស់គាត់ ហើយផ្នែកលក់បានចុះហត្ថលេខាដោយមិនមើល។

ភាពគួរឱ្យចាប់អារម្មណ៍មួយទៀតគឺថាកិច្ចសន្យាជាមួយអតិថិជនដ៏ធំបំផុតមួយចែងថាកំណែកម្មវិធីទាំងអស់ដែលគាំទ្រដោយវេទិកាត្រូវតែជា n-1 នោះមិនមែនជាកំណែចុងក្រោយបំផុតនោះទេ ប៉ុន្តែជាកំណែចុងក្រោយបំផុត។

វាច្បាស់ណាស់ថាតើយើងនៅឆ្ងាយប៉ុណ្ណាពី n-1 ប្រសិនបើវេទិកានេះគឺផ្អែកលើ ColdFusion និង SQL Server 2008 ដែលលែងត្រូវបានគាំទ្រនៅខែកក្កដា។

ថ្ងៃទីសែសិបប្រាំ

ប្រហែលពាក់កណ្តាលខែទីពីរ ខ្ញុំមានពេលគ្រប់គ្រាន់ដើម្បីអង្គុយចុះ តម្លៃស្ទ្រីមផែនទី ទាំងស្រុងសម្រាប់ដំណើរការទាំងមូល។ ទាំងនេះគឺជាជំហានចាំបាច់ដែលត្រូវធ្វើ ចាប់ពីការបង្កើតផលិតផល រហូតដល់ការចែកចាយវាដល់អ្នកប្រើប្រាស់ ហើយពួកគេចាំបាច់ត្រូវពិពណ៌នាឱ្យបានលម្អិតតាមដែលអាចធ្វើទៅបាន។

អ្នកបំបែកដំណើរការទៅជាបំណែកតូចៗ ហើយមើលអ្វីដែលត្រូវចំណាយពេលច្រើនពេក អ្វីដែលអាចត្រូវបានធ្វើឱ្យប្រសើរ កែលម្អ។ល។ ឧទាហរណ៍ តើវាត្រូវការពេលប៉ុន្មានសម្រាប់ការស្នើសុំផលិតផលដើម្បីឆ្លងកាត់ការសំអិតសំអាង ពេលដែលវាទៅដល់សំបុត្រដែលអ្នកអភិវឌ្ឍន៍អាចយក QA ជាដើម។ ដូច្នេះ​អ្នក​មើល​ជំហាន​នីមួយៗ​ដោយ​លម្អិត ហើយ​គិត​អំពី​អ្វី​ដែល​អាច​ត្រូវ​បាន​គេ​ធ្វើ​ឱ្យ​ប្រសើរ​ឡើង។

ពេល​ខ្ញុំ​ធ្វើ​បែប​នេះ រឿង​ពីរ​ទាក់​ភ្នែក​ខ្ញុំ៖

• ភាគរយខ្ពស់នៃសំបុត្រត្រឡប់ពី QA ត្រឡប់ទៅអ្នកអភិវឌ្ឍន៍;
• ទាញការពិនិត្យមើលសំណើចំណាយពេលយូរពេក។

បញ្ហាគឺថាទាំងនេះជាការសន្និដ្ឋានដូចជា: វាហាក់ដូចជាចំណាយពេលច្រើន ប៉ុន្តែយើងមិនប្រាកដថារយៈពេលប៉ុន្មាននោះទេ។

"អ្នកមិនអាចកែលម្អអ្វីដែលអ្នកមិនអាចវាស់វែងបានទេ។"

តើ​ធ្វើ​ដូចម្តេច​ដើម្បី​បញ្ជាក់​ថា​តើ​បញ្ហា​ធ្ងន់ធ្ងរ​ប៉ុណ្ណា? តើវាខ្ជះខ្ជាយថ្ងៃឬច្រើនម៉ោងទេ?

ដើម្បីវាស់វែងនេះ យើងបានបន្ថែមជំហានពីរបីទៅដំណើរការ Jira៖ "រួចរាល់សម្រាប់ dev" និង "រួចរាល់សម្រាប់ QA" ដើម្បីវាស់ថាតើសំបុត្រនីមួយៗរង់ចាំរយៈពេលប៉ុន្មាន និងប៉ុន្មានដងដែលវាត្រឡប់ទៅជំហានជាក់លាក់មួយ។

យើងក៏បានបន្ថែម "នៅក្នុងការពិនិត្យ" ដើម្បីដឹងថាតើមានសំបុត្រប៉ុន្មានជាមធ្យមសម្រាប់ការពិនិត្យឡើងវិញ ហើយពីនេះអ្នកអាចចាប់ផ្តើមរាំបាន។ យើង​មាន​ម៉ែត្រ​ប្រព័ន្ធ ឥឡូវ​យើង​បាន​បន្ថែម​ម៉ែត្រ​ថ្មី ហើយ​ចាប់​ផ្ដើម​វាស់៖

• ប្រសិទ្ធភាពនៃដំណើរការ៖ ការអនុវត្តនិងផែនការ / ចែកចាយ។
• គុណភាពដំណើរការ៖ ចំនួននៃពិការភាព, ពិការភាពពី QA ។

វាពិតជាជួយឱ្យយល់ពីអ្វីដែលកំពុងដំណើរការល្អ និងអ្វីដែលមិនល្អ។

ថ្ងៃទីហាសិប

នេះជាការពិតណាស់ ល្អ និងគួរឱ្យចាប់អារម្មណ៍ ប៉ុន្តែនៅចុងបញ្ចប់នៃខែទី 2 មានអ្វីមួយបានកើតឡើង ដែលតាមគោលការណ៍អាចព្យាករណ៍បាន ទោះបីជាខ្ញុំមិនបានរំពឹងថានឹងមានមាត្រដ្ឋានបែបនេះក៏ដោយ។ មនុស្ស​ចាប់​ផ្តើម​ចាក​ចេញ​ដោយ​សារ​តែ​អ្នក​គ្រប់​គ្រង​កំពូល​បាន​ផ្លាស់​ប្តូរ។ មនុស្ស​ថ្មី​ចូល​មក​គ្រប់គ្រង ហើយ​ចាប់​ផ្ដើម​ផ្លាស់​ប្តូរ​អ្វី​ៗ​ទាំង​អស់ ហើយ​អ្នក​ចាស់​ក៏​ឈប់។ ហើយជាធម្មតានៅក្នុងក្រុមហ៊ុនដែលមានអាយុច្រើនឆ្នាំ គ្រប់គ្នាគឺជាមិត្តភ័ក្តិ ហើយគ្រប់គ្នាស្គាល់គ្នា។

នេះ​ត្រូវ​បាន​គេ​រំពឹង​ទុក ប៉ុន្តែ​ទំហំ​នៃ​ការ​បញ្ឈប់​ការងារ​មិន​បាន​រំពឹង​ទុក​ទេ។ ជាឧទាហរណ៍ ក្នុងសប្តាហ៍មួយ អ្នកដឹកនាំក្រុមចំនួនពីរបានដាក់ការលាលែងពីតំណែងដោយឆន្ទៈសេរីផ្ទាល់ខ្លួនរបស់ពួកគេ។ ដូច្នេះ ខ្ញុំ​មិន​ត្រឹម​តែ​ភ្លេច​បញ្ហា​ផ្សេង​ទៀត​ប៉ុណ្ណោះ​ទេ ប៉ុន្តែ​ត្រូវ​ផ្តោត​ទៅ​លើ ការបង្កើតក្រុម. នេះជាបញ្ហាដ៏វែងឆ្ងាយ និងពិបាកដោះស្រាយ ប៉ុន្តែត្រូវតែដោះស្រាយ ព្រោះខ្ញុំចង់ជួយសង្គ្រោះមនុស្សដែលនៅសេសសល់ (ឬភាគច្រើននៃពួកគេ)។ វាចាំបាច់ក្នុងប្រតិកម្មដូចម្ដេចចំពោះការពិតដែលថាមនុស្សចាកចេញដើម្បីរក្សាសីលធម៌នៅក្នុងក្រុម។

តាមទ្រឹស្ដី នេះគឺល្អ៖ មនុស្សថ្មីម្នាក់ចូលមកដែលមានមុខម្ហូបពេញលេញ ដែលអាចវាយតម្លៃជំនាញរបស់ក្រុម និងជំនួសបុគ្គលិកបាន។ តាមពិតទៅ អ្នក​មិន​អាច​នាំ​មនុស្ស​ថ្មី​មក​ដោយ​ហេតុផល​ច្រើន​នោះទេ​។ តុល្យភាពគឺតែងតែត្រូវការ។

• ចាស់និងថ្មី។ យើងត្រូវរក្សាមនុស្សចាស់ដែលអាចផ្លាស់ប្តូរ និងគាំទ្របេសកកម្ម។ ប៉ុន្តែនៅពេលជាមួយគ្នានេះ យើងត្រូវបញ្ចូលឈាមថ្មី យើងនឹងនិយាយអំពីវានៅពេលក្រោយ។
• បទពិសោធន៍។ ខ្ញុំបាននិយាយច្រើនជាមួយយុវជនល្អៗ ដែលមានបំណងចង់ធ្វើការជាមួយយើង។ ប៉ុន្តែ​ខ្ញុំ​មិន​អាច​ទទួល​ពួកគេ​បាន​ទេ ព្រោះ​មិន​មាន​មនុស្ស​ចាស់​គ្រប់គ្រាន់​ដើម្បី​ជួយ​ដល់​យុវជន និង​ធ្វើ​ជា​អ្នក​ណែនាំ​សម្រាប់​ពួកគេ​។ ​ដំបូង​គេ​ត្រូវ​ជ្រើសរើស​អ្នក​កំពូល ហើយ​បន្ទាប់​មក​មានតែ​យុវជន​ប៉ុណ្ណោះ។
• ការ៉ុតនិងដំបង។

ខ្ញុំមិនមានចម្លើយល្អចំពោះសំណួរថាតើសមតុល្យត្រឹមត្រូវគឺជាអ្វី របៀបថែទាំវា តើមានមនុស្សប៉ុន្មានដែលត្រូវរក្សា និងចំនួនប៉ុន្មានដែលត្រូវរុញ។ នេះគឺជាដំណើរការបុគ្គលសុទ្ធសាធ។

ថ្ងៃទីហាសិបមួយ។

ខ្ញុំ​ចាប់​ផ្ដើម​មើល​ក្រុម​ឲ្យ​បាន​ដិត​ដល់​ដើម្បី​យល់​ថា​ខ្ញុំ​មាន​នរណា ហើយ​ម្ដង​ទៀត​ខ្ញុំ​នឹក​ឃើញ​ថា​៖

"បញ្ហាភាគច្រើនគឺជាបញ្ហារបស់មនុស្ស"។

ខ្ញុំបានរកឃើញថាក្រុមបែបនេះ - ទាំង Dev និង Ops - មានបញ្ហាធំបី៖

• ការពេញចិត្តនឹងស្ថានភាពបច្ចុប្បន្ន។
• កង្វះការទទួលខុសត្រូវ - ព្រោះ​មិន​ដែល​មាន​អ្នក​ណា​យក​លទ្ធផល​ការងារ​របស់​អ្នក​សម្តែង​មក​ជះ​ឥទ្ធិពល​លើ​អាជីវកម្ម​នោះ​ទេ។
• ការភ័យខ្លាចនៃការផ្លាស់ប្តូរ។

ការផ្លាស់ប្តូរតែងតែនាំអ្នកចេញពីតំបន់សុខស្រួលរបស់អ្នក ហើយមនុស្សវ័យក្មេងកាន់តែច្រើន ពួកគេកាន់តែមិនចូលចិត្តការផ្លាស់ប្តូរ ដោយសារតែពួកគេមិនយល់ពីមូលហេតុ ហើយពួកគេមិនយល់ពីរបៀប។ ចម្លើយទូទៅបំផុតដែលខ្ញុំបានលឺគឺ "យើងមិនដែលបានធ្វើវាទេ" ។ លើសពីនេះទៅទៀតវាបានឈានដល់ចំណុចនៃភាពមិនសមហេតុផលទាំងស្រុង - ការផ្លាស់ប្តូរតិចតួចបំផុតមិនអាចកើតឡើងដោយគ្មាននរណាម្នាក់ខឹងនោះទេ។ ហើយ​មិន​ថា​ការ​ផ្លាស់​ប្តូរ​បាន​ប៉ះ​ពាល់​ដល់​ការងារ​របស់​ពួក​គេ​ប៉ុណ្ណា​នោះ​ទេ មនុស្ស​ម្នា​បាន​និយាយ​ថា​៖ «ទេ ហេតុ​អ្វី? នេះ​នឹង​មិន​ដំណើរការ​ទេ»។

ប៉ុន្តែ​អ្នក​មិន​អាច​ប្រសើរ​ឡើង​ដោយ​គ្មាន​ការ​ផ្លាស់​ប្តូរ​អ្វី​ឡើយ។

ខ្ញុំ​មាន​ការ​សន្ទនា​មិន​ទំនង​ទាល់​តែ​សោះ​ជាមួយ​និយោជិត​ម្នាក់ ខ្ញុំ​បាន​ប្រាប់​គាត់​ពី​គំនិត​របស់​ខ្ញុំ​សម្រាប់​ការ​បង្កើន​ប្រសិទ្ធភាព ដែល​គាត់​បាន​ប្រាប់​ខ្ញុំ៖
- អូអ្នកមិនបានឃើញអ្វីដែលយើងមានកាលពីឆ្នាំមុនទេ!
- អញ្ចឹង?
"ឥឡូវ​នេះ​វា​ល្អ​ជាង​វា​ទៅ​ទៀត។"
- អញ្ចឹងវាមិនអាចប្រសើរជាងនេះបានទេ?
- ដើម្បី​អ្វី?

សំណួរល្អ - ហេតុអ្វី? វាដូចជាប្រសិនបើវាប្រសើរជាងឥឡូវនេះ នោះអ្វីៗគឺល្អគ្រប់គ្រាន់ហើយ។ នេះនាំឱ្យមានការខ្វះទំនួលខុសត្រូវ ដែលពិតជាធម្មតាជាគោលការណ៍។ ដូច​ខ្ញុំ​បាន​និយាយ ក្រុម​បច្ចេកទេស​នៅ​ខាង​ក្រៅ​បន្តិច។ ក្រុមហ៊ុនជឿថាពួកគេគួរតែមាន ប៉ុន្តែ គ្មាននរណាម្នាក់កំណត់ស្តង់ដារទេ។. ការគាំទ្រផ្នែកបច្ចេកទេសមិនដែលឃើញ SLA ទេ ដូច្នេះវាពិតជា "អាចទទួលយកបាន" សម្រាប់ក្រុម (ហើយវាធ្វើឱ្យខ្ញុំចាប់អារម្មណ៍បំផុត)៖

• ផ្ទុក 12 វិនាទី;
• ការផ្អាក 5-10 នាទីរាល់ការចេញផ្សាយ;
• ការដោះស្រាយបញ្ហាសំខាន់ៗត្រូវចំណាយពេលច្រើនថ្ងៃ និងច្រើនសប្តាហ៍។
• កង្វះបុគ្គលិកកាតព្វកិច្ច 24x7 / តាមការហៅ។

គ្មាននរណាម្នាក់ធ្លាប់ព្យាយាមសួរថាហេតុអ្វីបានជាយើងមិនធ្វើវាឱ្យប្រសើរជាងនេះទេ ហើយគ្មាននរណាម្នាក់ធ្លាប់ដឹងថាវាមិនចាំបាច់ធ្វើបែបនេះទេ។

ជាប្រាក់រង្វាន់ មានបញ្ហាមួយទៀត៖ កង្វះបទពិសោធន៍. មនុស្សចាស់បានចាកចេញ ហើយក្រុមក្មេងៗដែលនៅសល់បានធំឡើងនៅក្រោមរបបមុន ហើយត្រូវបានបំពុលដោយវា។

លើស​ពី​នេះ​ទៅ​ទៀត មនុស្ស​ក៏​ភ័យ​ខ្លាច​នឹង​ការ​បរាជ័យ ហើយ​ហាក់​ដូច​ជា​អសមត្ថភាព។ នេះត្រូវបានបញ្ជាក់នៅក្នុងការពិតដែលថាជាដំបូងពួកគេ។ មិនស្ថិតក្រោមកាលៈទេសៈណាក៏ដោយ សុំជំនួយ. តើ​យើង​បាន​និយាយ​ជា​ក្រុម និង​ជា​បុគ្គល​ប៉ុន្មាន​ដង ហើយ​ខ្ញុំ​បាន​និយាយ​ថា “សួរ​សំណួរ​មួយ​ប្រសិន​បើ​អ្នក​មិន​ដឹង​ធ្វើ​អ្វី​មួយ”។ ខ្ញុំជឿជាក់លើខ្លួនឯង ហើយដឹងថាខ្ញុំអាចដោះស្រាយបញ្ហាណាមួយបាន ប៉ុន្តែវានឹងត្រូវការពេលវេលា។ ដូច្នេះ​បើ​ខ្ញុំ​អាច​សួរ​អ្នក​ដែល​ដឹង​ពី​វិធី​ដោះស្រាយ​ក្នុង​រយៈពេល ១០ នាទី ខ្ញុំ​នឹង​សួរ។ អ្នក​មាន​បទពិសោធន៍​តិច អ្នក​កាន់តែ​ខ្លាច​ក្នុង​ការ​សួរ​ព្រោះ​អ្នក​គិត​ថា​អ្នក​នឹង​ត្រូវ​បាន​គេ​ចាត់​ទុក​ថា​ជា​អ្នក​គ្មាន​សមត្ថភាព។

ការភ័យខ្លាចនៃការសួរសំណួរនេះបង្ហាញឱ្យឃើញដោយខ្លួនវាផ្ទាល់នៅក្នុងវិធីគួរឱ្យចាប់អារម្មណ៍។ ជាឧទាហរណ៍ អ្នកសួរថា "តើអ្នកកំពុងធ្វើកិច្ចការនេះដោយរបៀបណា?" - នៅសល់ពីរបីម៉ោងទៀត ខ្ញុំនឹងបញ្ចប់ហើយ។ នៅថ្ងៃបន្ទាប់អ្នកសួរម្តងទៀត អ្នកទទួលបានចម្លើយថាអ្វីគ្រប់យ៉ាងគឺល្អ ប៉ុន្តែមានបញ្ហាមួយ វាប្រាកដជានឹងរួចរាល់នៅចុងថ្ងៃ។ ថ្ងៃ​មួយ​ទៀត​កន្លង​ផុត​ទៅ ហើយ​រហូត​ទាល់​តែ​អ្នក​ត្រូវ​បាន​ខ្ទាស់​នឹង​ជញ្ជាំង ហើយ​បង្ខំ​ឱ្យ​និយាយ​ជាមួយ​នរណា​ម្នាក់ វា​នៅ​តែ​បន្ត។ មនុស្សម្នាក់ចង់ដោះស្រាយបញ្ហាដោយខ្លួនឯង គាត់ជឿថា ប្រសិនបើគាត់មិនដោះស្រាយបញ្ហាដោយខ្លួនឯងទេ វានឹងបរាជ័យធំ។

នោះហើយជាមូលហេតុ អ្នកអភិវឌ្ឍន៍បានបំប៉ោងការប៉ាន់ស្មាន. វា​ជា​រឿង​ខ្លី​ដដែល​នោះ នៅ​ពេល​ដែល​ពួកគេ​កំពុង​ពិភាក្សា​អំពី​កិច្ចការ​ជាក់លាក់​មួយ ពួកគេ​បាន​ផ្ដល់​តួលេខ​ដល់​ខ្ញុំ​ដែល​ខ្ញុំ​ភ្ញាក់ផ្អើល​ជា​ខ្លាំង។ ដែលខ្ញុំត្រូវបានគេប្រាប់ថា នៅក្នុងការប៉ាន់ស្មានរបស់អ្នកអភិវឌ្ឍន៍ អ្នកអភិវឌ្ឍន៍រួមបញ្ចូលពេលវេលាដែលសំបុត្រនឹងត្រូវប្រគល់មកវិញពី QA ព្រោះពួកគេនឹងរកឃើញកំហុសនៅទីនោះ និងពេលវេលាដែល PR នឹងយក និងពេលវេលាដែលមនុស្សដែលគួរពិនិត្យមើលឡើងវិញ។ វានឹងរវល់ - នោះគឺជាអ្វីគ្រប់យ៉ាងដែលអាចធ្វើទៅបាន។

ទីពីរ មនុស្ស​ដែល​ខ្លាច​លេច​មុខ​អសមត្ថភាព វិភាគលើស. ពេល​អ្នក​និយាយ​ថា​ត្រូវ​ធ្វើ​អ្វី​ឲ្យ​ប្រាកដ វា​ចាប់​ផ្ដើម​៖ “អត់​ទេ ចុះ​បើ​យើង​គិត​អំពី​វា​នៅ​ទី​នេះ? ក្នុងន័យនេះ ក្រុមហ៊ុនរបស់យើងមិនប្លែកទេ នេះគឺជាបញ្ហាស្តង់ដារសម្រាប់យុវវ័យ

ជាការឆ្លើយតប ខ្ញុំបានណែនាំការអនុវត្តដូចខាងក្រោមៈ

• ក្បួន 30 នាទី។ ប្រសិនបើអ្នកមិនអាចដោះស្រាយបញ្ហាក្នុងរយៈពេលកន្លះម៉ោងបានទេ សូមសួរនរណាម្នាក់ឱ្យជួយ។ វាដំណើរការជាមួយនឹងកម្រិតនៃភាពជោគជ័យផ្សេងៗគ្នា ពីព្រោះមនុស្សនៅតែមិនសួរ ប៉ុន្តែយ៉ាងហោចណាស់ដំណើរការបានចាប់ផ្តើមហើយ។
• លុបបំបាត់អ្វីៗទាំងអស់លើកលែងតែខ្លឹមសារក្នុងការប៉ាន់ប្រមាណថ្ងៃផុតកំណត់សម្រាប់ការបញ្ចប់កិច្ចការ នោះគឺពិចារណាថាតើវាត្រូវចំណាយពេលប៉ុន្មានដើម្បីសរសេរកូដ។
• ការរៀនសូត្រឥតឈប់ឈរ សម្រាប់អ្នកដែលវិភាគលើស។ វាគ្រាន់តែជាការងារជាប់លាប់ជាមួយមនុស្សប៉ុណ្ណោះ។

ថ្ងៃទីហុកសិប

ខណៈ​ពេល​ដែល​ខ្ញុំ​កំពុង​ធ្វើ​កិច្ចការ​ទាំង​អស់​នេះ វា​ដល់​ពេល​ត្រូវ​រក​ថវិកា។ ជា​ការ​ពិត​ណាស់ ខ្ញុំ​បាន​រក​ឃើញ​រឿង​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​ជា​ច្រើន​នៅ​កន្លែង​ដែល​យើង​ចំណាយ​ប្រាក់​របស់​យើង។ ឧទាហរណ៍ យើងមាន rack ទាំងមូលនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដាច់ដោយឡែកមួយដែលមានម៉ាស៊ីនមេ FTP មួយដែលត្រូវបានប្រើប្រាស់ដោយម៉ាស៊ីនភ្ញៀវមួយ។ វាប្រែថា "... យើងបានផ្លាស់ប្តូរ ប៉ុន្តែគាត់នៅដដែល យើងមិនផ្លាស់ប្តូរគាត់ទេ" ។ វាគឺ 2 ឆ្នាំមុន។

ការចាប់អារម្មណ៍ជាពិសេសគឺវិក័យប័ត្រសម្រាប់សេវាកម្មពពក។ ខ្ញុំជឿថាហេតុផលចម្បងសម្រាប់វិក័យប័ត្រពពកខ្ពស់គឺអ្នកអភិវឌ្ឍន៍ដែលមានសិទ្ធិចូលប្រើម៉ាស៊ីនមេគ្មានដែនកំណត់ជាលើកដំបូងក្នុងជីវិតរបស់ពួកគេ។ ពួកគេមិនចាំបាច់សួរថា "សូមផ្តល់ឱ្យខ្ញុំនូវម៉ាស៊ីនមេសាកល្បង" ពួកគេអាចយកវាដោយខ្លួនឯងបាន។ លើសពីនេះ អ្នកអភិវឌ្ឍន៍តែងតែចង់បង្កើតប្រព័ន្ធត្រជាក់បែបនេះ ដែល Facebook និង Netflix នឹងច្រណែន។

ប៉ុន្តែអ្នកអភិវឌ្ឍន៍មិនមានបទពិសោធន៍ក្នុងការទិញម៉ាស៊ីនមេ និងជំនាញក្នុងការកំណត់ទំហំដែលត្រូវការនៃម៉ាស៊ីនមេទេ ព្រោះពួកគេមិនត្រូវការវាពីមុនមក។ ហើយជាធម្មតាពួកគេមិនយល់ច្បាស់ពីភាពខុសគ្នារវាងការធ្វើមាត្រដ្ឋាន និងការអនុវត្ត។

លទ្ធផលសារពើភ័ណ្ឌ៖

• យើងចាកចេញពីមជ្ឈមណ្ឌលទិន្នន័យដូចគ្នា។
• យើងបានបញ្ចប់កិច្ចសន្យាជាមួយសេវាកម្មកំណត់ហេតុចំនួន 3 ។ ដោយសារតែយើងមាន 5 ក្នុងចំណោមពួកគេ - អ្នកអភិវឌ្ឍន៍ទាំងអស់ដែលចាប់ផ្តើមលេងជាមួយអ្វីមួយបានយកថ្មីមួយ។
• ប្រព័ន្ធ AWS 7 ត្រូវបានបិទ។ ជាថ្មីម្តងទៀត គ្មាននរណាម្នាក់បញ្ឈប់គម្រោងដែលស្លាប់នោះទេ ពួកគេទាំងអស់គ្នានៅតែបន្តធ្វើការ។
• កាត់បន្ថយការចំណាយលើកម្មវិធី 6 ដង។

ថ្ងៃទីចិតសិបប្រាំ

ពេលវេលាបានកន្លងផុតទៅ ហើយក្នុងរយៈពេលពីរខែកន្លះ ខ្ញុំត្រូវជួបជាមួយក្រុមប្រឹក្សាភិបាល។ ក្រុមប្រឹក្សាភិបាលរបស់យើងមិនប្រសើរជាង ឬអាក្រក់ជាងអ្នកដទៃទេ ដូចជាក្រុមប្រឹក្សាភិបាលទាំងអស់ ចង់ដឹងអ្វីៗទាំងអស់។ មនុស្សវិនិយោគលុយ ហើយចង់យល់ថាតើអ្វីដែលយើងធ្វើត្រូវនឹង KPIs ដែលកំណត់។

ក្រុមប្រឹក្សាភិបាលទទួលបានព័ត៌មានជាច្រើនជារៀងរាល់ខែ៖ ចំនួនអ្នកប្រើប្រាស់ កំណើនរបស់ពួកគេ សេវាកម្មអ្វីដែលពួកគេប្រើប្រាស់ និងរបៀប ដំណើរការ និងផលិតភាព ហើយចុងក្រោយ ល្បឿនផ្ទុកទំព័រជាមធ្យម។

បញ្ហាតែមួយគត់គឺថាខ្ញុំជឿថាជាមធ្យមគឺអាក្រក់សុទ្ធ។ ប៉ុន្តែវាពិបាកណាស់ក្នុងការពន្យល់រឿងនេះដល់ក្រុមប្រឹក្សាភិបាល។ ពួកគេត្រូវបានទម្លាប់ធ្វើការកត់សំគាល់ក្នុងប្រតិបត្តិការជាមួយលេខសរុប ហើយមិនមែនឧទាហរណ៍ការរីករាលដាលនៃពេលវេលាផ្ទុកក្នុងមួយវិនាទី។

មានចំណុចគួរឱ្យចាប់អារម្មណ៍មួយចំនួននៅក្នុងរឿងនេះ។ ជាឧទាហរណ៍ ខ្ញុំបាននិយាយថា យើងត្រូវបំបែកចរាចរណ៍រវាងម៉ាស៊ីនមេបណ្តាញដាច់ដោយឡែក អាស្រ័យលើប្រភេទនៃមាតិកា។

នោះគឺ ColdFusion ឆ្លងកាត់ Jetty និង nginx ហើយបើកដំណើរការទំព័រ។ ហើយរូបភាព JS និង CSS ឆ្លងកាត់ nginx ដាច់ដោយឡែក ជាមួយនឹងការកំណត់ផ្ទាល់ខ្លួនរបស់ពួកគេ។ នេះ​ជា​ការអនុវត្ត​ស្តង់ដារ​ត្រឹមត្រូវ​ដែល​ខ្ញុំ​កំពុង​និយាយ បានសរសេរ ពីរបីឆ្នាំមុន។ ជាលទ្ធផល រូបភាពផ្ទុកលឿនជាងមុន ហើយ... ល្បឿនផ្ទុកជាមធ្យមបានកើនឡើង 200 ms ។

វាបានកើតឡើងដោយសារតែក្រាហ្វត្រូវបានបង្កើតឡើងដោយផ្អែកលើទិន្នន័យដែលភ្ជាប់មកជាមួយ Jetty ។ នោះគឺមាតិកាលឿនមិនត្រូវបានរាប់បញ្ចូលក្នុងការគណនាទេ - តម្លៃមធ្យមបានលោត។ នេះច្បាស់ណាស់សម្រាប់ពួកយើង យើងសើច ប៉ុន្តែតើយើងអាចពន្យល់ដល់ក្រុមប្រឹក្សាភិបាលថាហេតុអ្វីបានជាយើងធ្វើអ្វីមួយ ហើយអ្វីៗកាន់តែអាក្រក់ទៅៗ 12%?

ថ្ងៃទីប៉ែតសិបប្រាំ

នៅចុងបញ្ចប់នៃខែទី 3 ខ្ញុំបានដឹងថាមានរឿងមួយដែលខ្ញុំមិនបានគិតទាល់តែសោះគឺពេលវេលា។ អ្វីគ្រប់យ៉ាងដែលខ្ញុំបាននិយាយអំពីត្រូវការពេលវេលា។

នេះ​ជា​ប្រតិទិន​ប្រចាំ​សប្តាហ៍​ពិត​ប្រាកដ​របស់​ខ្ញុំ - គ្រាន់​តែ​ជា​សប្តាហ៍​ការងារ​ប៉ុណ្ណោះ មិន​រវល់​ខ្លាំង​ទេ។ មិនមានពេលវេលាគ្រប់គ្រាន់សម្រាប់អ្វីគ្រប់យ៉ាងទេ។ ដូច្នេះម្តងទៀត អ្នកត្រូវជ្រើសរើសមនុស្សដែលនឹងជួយអ្នកដោះស្រាយបញ្ហា។

សេចក្តីសន្និដ្ឋាន

នោះមិនមែនទាំងអស់ទេ។ នៅក្នុងរឿងនេះ ខ្ញុំមិនទាន់បានដឹងពីរបៀបដែលយើងធ្វើការជាមួយផលិតផល និងព្យាយាមតាមដានរលកទូទៅ ឬរបៀបដែលយើងរួមបញ្ចូលជំនួយផ្នែកបច្ចេកទេស ឬវិធីដែលយើងដោះស្រាយបញ្ហាបច្ចេកទេសផ្សេងទៀត។ ជាឧទាហរណ៍ ខ្ញុំបានរៀនដោយចៃដន្យថានៅលើតារាងធំបំផុតនៅក្នុងមូលដ្ឋានទិន្នន័យដែលយើងមិនប្រើ SEQUENCE. យើងមានមុខងារសរសេរដោយខ្លួនឯង។ nextIDហើយវាមិនត្រូវបានប្រើប្រាស់ក្នុងប្រតិបត្តិការទេ។

មានរឿងស្រដៀងគ្នាមួយលានទៀត ដែលយើងអាចនិយាយបានក្នុងរយៈពេលយូរ។ ប៉ុន្តែអ្វីដែលសំខាន់បំផុតដែលនៅតែត្រូវនិយាយគឺវប្បធម៌។

វា​ជា​វប្បធម៌​ឬ​កង្វះ​វា​ដែល​នាំ​ឱ្យ​មាន​បញ្ហា​ផ្សេង​ទៀត​ទាំង​អស់​។ យើងកំពុងព្យាយាមកសាងវប្បធម៌មួយដែលមនុស្ស៖

• មិនខ្លាចការបរាជ័យ;
• រៀនពីកំហុស;
• សហការជាមួយក្រុមផ្សេងទៀត;
• ផ្តួចផ្តើមគំនិត;
• ទទួលខុសត្រូវ;
• ស្វាគមន៍លទ្ធផលជាគោលដៅ;
• អបអរសាទរជោគជ័យ។

ជាមួយនេះអ្វីៗផ្សេងទៀតនឹងមក។

Leon Fire នៅលើ twitter, ហ្វេសប៊ុក និងនៅលើ មធ្យម.

មានយុទ្ធសាស្ត្រពីរទាក់ទងនឹងកេរដំណែល៖ ជៀសវាងធ្វើការជាមួយវាគ្រប់ការចំណាយ ឬជំនះការលំបាកដែលពាក់ព័ន្ធដោយក្លាហាន។ យើង គ DevOpsConf យើងកំពុងយកផ្លូវទីពីរ ផ្លាស់ប្តូរដំណើរការ និងវិធីសាស្រ្ត។ ចូលរួមជាមួយពួកយើង YouTube, ព្រឹត្តិបត្រ и ទូរលេខហើយរួមគ្នាយើងនឹងអនុវត្តវប្បធម៌ DevOps ។

ប្រភព: www.habr.com