ហេតុអ្វីបានជាយើងរៀបចំកម្មវិធី hackathon សម្រាប់អ្នកសាកល្បង?

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

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

ខ្ញុំមិនអាចនិយាយសម្រាប់ក្រុមហ៊ុន IT ទាំងអស់បានទេ ប៉ុន្តែយើងបានប្រគល់តួនាទីរបស់ QA/QC ដល់អ្នកឯកទេសគុណភាពរបស់យើង។ ពួកគេគឺជាផ្នែកមួយនៃក្រុមអភិវឌ្ឍន៍ និងចូលរួមក្នុងគ្រប់ដំណាក់កាលនៃការអភិវឌ្ឍន៍ ចាប់ពីការស្រាវជ្រាវ រហូតដល់ការចេញផ្សាយកំណែថ្មី។

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

អ្វីដែលយើងជួបប្រទះនៅពេលស្វែងរកអ្នកសាកល្បង

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

បន្ទាប់ ខ្ញុំនឹងប្រាប់អ្នកពីជំហានដែលយើងបានធ្វើ និងកំហុសអ្វីខ្លះដែលយើងបានបោះជំហាន ដើម្បីស្វែងរកអ្នកប្រយុទ្ធដែលទន្ទឹងរង់ចាំជាយូរមកហើយទាំងនោះប្រកបដោយគុណភាព។

របៀបដែលយើងបានព្យាយាមជួសជុលស្ថានភាព

ដោយបានហត់នឿយខ្លួនយើងជាមួយនឹងប្រភពអ្នកជំនាញដែលផលិតរួចរាល់ហើយ យើងបានចាប់ផ្តើមកំណត់គោលដៅតំបន់ក្បែរៗនោះ៖

1. យើងបានព្យាយាមអនុវត្តការអនុវត្តការវាយតម្លៃដើម្បីកំណត់អត្តសញ្ញាណក្នុងចំណោមមនុស្ស "ចាកចេញ" ជាច្រើន ដែលជាអ្នកដែលយើងអាចបង្កើតអ្នកឯកទេសខ្លាំង។

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

   ជាពិសេស យើងបានបង្កើតភារកិច្ចដើម្បីសាកល្បងការយកចិត្តទុកដាក់ ការយល់ដឹងអំពីសមត្ថភាពនៃបច្ចេកវិទ្យា និងលក្ខណៈពិសេសនៃពហុវប្បធម៌៖

   
   

2. យើងបានរៀបចំកិច្ចប្រជុំសម្រាប់អ្នកសាកល្បង ដើម្បីពង្រីកព្រំដែននៃការយល់ដឹងអំពីវិជ្ជាជីវៈក្នុងចំណោមអ្នកប្រកួតប្រជែងដែលមានស្រាប់។

   ខ្ញុំនឹងប្រាប់អ្នកបន្តិចអំពីពួកគេម្នាក់ៗ។

   Ufa Software QA and Testing Meetup #1 គឺជាការប៉ុនប៉ងលើកដំបូងរបស់យើងក្នុងការប្រមូលផ្តុំអ្នកដែលយកចិត្តទុកដាក់លើវិជ្ជាជីវៈ ហើយក្នុងពេលតែមួយយល់ថាតើសាធារណជននឹងចាប់អារម្មណ៍លើអ្វីដែលយើងចង់បង្ហាញដល់ពួកគេដែរឬទេ។ ជាទូទៅ របាយការណ៍របស់យើងគឺអំពីកន្លែងដែលវាល្អប្រសើរជាងមុនដើម្បីចាប់ផ្តើម ប្រសិនបើអ្នកបានសម្រេចចិត្តក្លាយជាអ្នកសាកល្បង។ ជួយអ្នកចាប់ផ្តើមបើកភ្នែករបស់ពួកគេ ហើយមើលការធ្វើតេស្តដូចមនុស្សពេញវ័យ។ យើងបាននិយាយអំពីជំហានដែលអ្នកសាកល្បងថ្មីថ្មោងត្រូវធ្វើដើម្បីចូលរួមអាជីព។ អំពីអ្វីដែលជាគុណភាពនិងរបៀបដើម្បីសម្រេចបានវានៅក្នុងលក្ខខណ្ឌជាក់ស្តែង។ ហើយផងដែរ អ្វីដែលជាការសាកល្បងដោយស្វ័យប្រវត្តិ និងកន្លែងដែលវាសមស្របជាងក្នុងការប្រើប្រាស់វា។

   
   
   បន្ទាប់មក ដោយមានចន្លោះពេល 1-2 ខែ យើងបានរៀបចំការប្រជុំពីរទៀត។ មានអ្នកចូលរួមច្រើនជាងពីរដងរួចទៅហើយ។ នៅ “Ufa Software QA and Testing Meetup #2” យើងបានធ្លាក់ចូលទៅក្នុងប្រធានបទកាន់តែស៊ីជម្រៅ។ ពួកគេបាននិយាយអំពីប្រព័ន្ធតាមដានកំហុស ការធ្វើតេស្ត UI/UX ប៉ះលើ Docker, Ansible និងក៏បាននិយាយអំពីជម្លោះដែលអាចកើតមានរវាងអ្នកអភិវឌ្ឍន៍ និងអ្នកសាកល្បង និងវិធីដើម្បីដោះស្រាយពួកគេ។

   កិច្ចប្រជុំលើកទី 3 របស់យើង "Ufa Software QA and Testing Meetup #2" ទាក់ទងដោយប្រយោលទៅនឹងការងាររបស់អ្នកសាកល្បង ប៉ុន្តែមានប្រយោជន៍ក្នុងការរំលឹកអ្នកសរសេរកម្មវិធីទាន់ពេលវេលាអំពីភារកិច្ចបច្ចេកទេស និងអង្គការរបស់ពួកគេ៖ ការធ្វើតេស្តផ្ទុក ការធ្វើតេស្ត eXNUMXe សេលេញ៉ូមក្នុងការធ្វើតេស្តស្វ័យប្រវត្តិ ភាពងាយរងគ្រោះនៃកម្មវិធីគេហទំព័រ .

   គ្រប់ពេលវេលានេះ យើងបានរៀនពីរបៀបបង្កើតពន្លឺ និងសំឡេងធម្មតានៅក្នុងការផ្សាយពីព្រឹត្តិការណ៍របស់យើង៖

   → ជំហានដំបូងក្នុងការធ្វើតេស្ត - Ufa Software QA និង Testing Meetup #1
   → ការធ្វើតេស្ត UI/UX – Ufa Software QA និង Testing Meetup #2
   → ការធ្វើតេស្តសុវត្ថិភាព ការធ្វើតេស្តផ្ទុក និងការធ្វើតេស្តស្វ័យប្រវត្តិ - Ufa QA និង Testing Meetup #3

3. ហើយ​នៅ​ទី​បញ្ចប់ យើង​បាន​សម្រេច​ចិត្ត​ព្យាយាម​រៀបចំ​កម្មវិធី hackathon សម្រាប់​អ្នក​សាកល្បង

របៀបដែលយើងបានរៀបចំ និងធ្វើកម្មវិធី hackathon សម្រាប់អ្នកសាកល្បង

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

ការឈឺក្បាលចម្បងរបស់យើងគឺកង្វះការអនុវត្តក្នុងចំណោមអ្នកសាកល្បងក្នុងស្រុកក្នុងការបង្កើតផែនទីសាកល្បងច្បាស់លាស់។ ពួកគេមិនចំណាយពេលស្រាវជ្រាវរឿងអ្នកប្រើប្រាស់មុនការអនុវត្ត និងបង្កើតលក្ខណៈវិនិច្ឆ័យទទួលយកដែលច្បាស់លាស់ចំពោះអ្នកអភិវឌ្ឍន៍សម្រាប់តម្រូវការមុខងារ និងមិនដំណើរការ UI/UX សុវត្ថិភាព បន្ទុកការងារ និងកម្រិតខ្ពស់បំផុត។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តជាលើកដំបូង ដើម្បីឆ្លងកាត់ផ្នែកដែលគួរឱ្យចាប់អារម្មណ៍ និងច្នៃប្រឌិតបំផុតនៃការងាររបស់ពួកគេ - ការវិភាគ និងការបង្កើតតម្រូវការកំឡុងពេលស្រាវជ្រាវមុនគម្រោង។

យើងបានប៉ាន់ប្រមាណចំនួនអ្នកចូលរួមសក្តានុពល ហើយបានសម្រេចចិត្តថាយើងត្រូវការយ៉ាងហោចណាស់ 5 backlog សម្រាប់ការចេញផ្សាយ MVP ផលិតផល 5 និងមនុស្ស 5 នាក់ដែលនឹងដើរតួជាម្ចាស់ផលិតផល បកស្រាយតម្រូវការអាជីវកម្ម និងធ្វើការសម្រេចចិត្តលើការរឹតបន្តឹង។

នេះជាអ្វីដែលយើងទទួលបាន៖ backlogs សម្រាប់ hackathon.

គំនិតចម្បងគឺបង្កើតប្រធានបទដែលនៅឆ្ងាយពីការងារប្រចាំថ្ងៃរបស់អ្នកចូលរួមទាំងអស់តាមដែលអាចធ្វើទៅបាន និងផ្តល់ឱ្យពួកគេនូវវិសាលភាពសម្រាប់ការហោះហើរប្រកបដោយភាពច្នៃប្រឌិត។

តើ​យើង​មាន​កំហុស​អ្វី​ខ្លះ ហើយ​តើ​យើង​អាច​ធ្វើ​អ្វី​បាន​ល្អ​ជាង​នេះ?

ការប្រើប្រាស់ការអនុវត្តការវាយតម្លៃ ដែលមានប្រជាប្រិយភាពខ្លាំងក្នុងវិស័យជួលបុគ្គលិកផ្នែកលក់ និងអ្នកគ្រប់គ្រងកម្រិតទាប បានខិតខំប្រឹងប្រែងយ៉ាងច្រើន ប៉ុន្តែមិនអនុញ្ញាតឱ្យយើងយកចិត្តទុកដាក់គ្រប់គ្រាន់ចំពោះអ្នកចូលរួមម្នាក់ៗ និងវាយតម្លៃសមត្ថភាពរបស់គាត់នោះទេ។ ជាទូទៅ ជម្រើសនៃការជ្រើសរើសនេះបង្កើតរូបភាពអវិជ្ជមានរបស់ក្រុមហ៊ុន ចាប់តាំងពីមនុស្សជាច្រើនទទួលបានមតិកែលម្អមិនគ្រប់គ្រាន់ ហើយក្រោយមកបង្កើតនៅក្នុងខ្លួនពួកគេ និងអ្នកដទៃ ឥទ្ធិពលនៃការជិះជាន់របស់និយោជក (ការទំនាក់ទំនងនៅក្នុងសហគមន៍ IT ត្រូវបានអភិវឌ្ឍយ៉ាងខ្លាំង)។ ជាលទ្ធផល យើងនៅសល់បេក្ខជនដែលមានសក្តានុពលពីរនាក់ដែលមានអនាគតឆ្ងាយ។

ការជួបជុំគ្នាគឺជារឿងល្អ។ មូលដ្ឋានយ៉ាងទូលំទូលាយសម្រាប់ភាពល្អិតល្អន់ត្រូវបានបង្កើតឡើង ហើយកម្រិតទូទៅនៃអ្នកចូលរួមកើនឡើង។ ក្រុមហ៊ុនកាន់តែមានភាពល្បីល្បាញនៅលើទីផ្សារ។ ប៉ុន្តែ​កម្លាំង​ពលកម្ម​នៃ​កិច្ចការ​បែបនេះ​មិន​តូច​ទេ​។ អ្នក​ត្រូវ​យល់​ច្បាស់​ថា​ការ​រៀបចំ​ការ​ជួប​ជុំ​នឹង​ត្រូវ​ចំណាយ​ពេល​ប្រហែល 700-800 ម៉ោង​ក្នុង​មួយ​ឆ្នាំ។

សម្រាប់ការធ្វើតេស្ត hackathon ។ ប្រភេទនៃព្រឹត្តិការណ៍ទាំងនេះមិនទាន់ក្លាយជារឿងគួរឱ្យធុញនៅឡើយទេ ព្រោះថាមិនដូចការ hackathons សម្រាប់អ្នកអភិវឌ្ឍន៍ទេ ព្រឹត្តិការណ៍ទាំងនោះត្រូវបានធ្វើឡើងតិចជាងញឹកញាប់។ អត្ថប្រយោជន៍នៃគំនិតនេះគឺថា ក្នុងលក្ខណៈធូរស្រាល អ្នកអាចផ្លាស់ប្តូរចំណេះដឹងជាក់ស្តែងមួយចំនួនធំ និងកំណត់យ៉ាងត្រឹមត្រូវនូវកម្រិតនៃអ្នកចូលរួមនីមួយៗ។

បន្ទាប់ពីការវិភាគលទ្ធផលនៃព្រឹត្តិការណ៍នេះ យើងដឹងថាយើងមានកំហុសជាច្រើន៖

1. កំហុសដែលមិនអាចលើកលែងបានបំផុតគឺជឿថា 4-5 ម៉ោងនឹងគ្រប់គ្រាន់សម្រាប់យើង។ ជា​លទ្ធផល គ្រាន់​តែ​ការ​ណែនាំ​និង​ស្គាល់​ពី​ការ​លួច​ចម្លង​ត្រូវ​ចំណាយ​ពេល​ជិត ២ ម៉ោង។
   ការធ្វើការជាមួយម្ចាស់ផលិតផលនៅដំណាក់កាលដំបូង និងពេលវេលាដើម្បីមុជទឹកចូលទៅក្នុងប្រធានបទបានចំណាយពេលដូចគ្នា។ ដូច្នេះ​ពេល​វេលា​ដែល​នៅ​សេសសល់​ច្បាស់​ជា​មិន​គ្រប់​គ្រាន់​សម្រាប់​ការ​អភិវឌ្ឍ​យ៉ាង​ទូលំទូលាយ​នៃ​ផែនទី​សាកល្បង។
2. មិនមានពេលវេលា និងថាមពលគ្រប់គ្រាន់សម្រាប់មតិកែលម្អលម្អិតនៅលើផែនទីនីមួយៗទេ ដោយសារវាយប់ហើយ។ ដូច្នេះហើយ យើងច្បាស់ជាបានបរាជ័យផ្នែកនេះ ប៉ុន្តែដំបូងឡើយ គឺមានបំណងមានតម្លៃបំផុតនៅក្នុង hackathon ។
3. យើងបានសម្រេចចិត្តវាយតម្លៃគុណភាពនៃការអភិវឌ្ឍន៍ដោយការបោះឆ្នោតសាមញ្ញរបស់អ្នកចូលរួមទាំងអស់ ដោយបែងចែក 3 សម្លេងសម្រាប់ក្រុមនីមួយៗ ដែលពួកគេអាចផ្តល់ឱ្យសម្រាប់ការងារដែលមានគុណភាពខ្ពស់បំផុត។ ប្រហែល​ជា​វា​ជា​ការ​ប្រសើរ​ក្នុង​ការ​រៀបចំ​គណៈវិនិច្ឆ័យ។

តើអ្នកបានសម្រេចអ្វីខ្លះ?

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

ប្រភព: www.habr.com