---

ការគ្រប់គ្រងគម្រោង និងដំណើរការដែលមានប្រសិទ្ធភាពគឺមានសារៈសំខាន់សម្រាប់អង្គការទាំងអស់។

នៅ Blue, យើងបានធ្វើឱ្យវាជាមេស្ស៊ីយ៉ាងខ្លាំង ដើម្បីរៀបចំការងារនៅលើពិភពលោកដោយការសាងសង់វេទិកាគ្រប់គ្រងគម្រោងល្អបំផុតនៅលើផែនដី—ធម្មតា, មានអំណាច, មានភាពអាចបត់បែន និងមានតម្លៃសមរម្យសម្រាប់គ្រប់គ្នា។

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

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

អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនមានតួនាទីសំខាន់នៅក្នុងវេទិកា B2B SaaS, ជាពិសេសនៅក្នុងឧបករណ៍គ្រប់គ្រងគម្រោង, ដែលទីតាំងរវាងការសហការនិងសុវត្ថិភាពអាចធ្វើឱ្យគម្រោងជោគជ័យឬបរាជ័យ។

ប៉ុន្តែនេះគឺជាដែល Blue ធ្វើការយ៉ាងខុសគ្នា: យើងជឿថាមុខងារមានគុណភាពសម្រាប់សហគ្រាសមិនគួរត្រូវបានរក្សាទុកសម្រាប់ថវិកាសហគ្រាសទេ។

នៅក្នុងសម័យដែល AI អាចជួយក្រុមតូចឱ្យដំណើរការនៅកម្រិតដែលមិនធ្លាប់មាន, ហេតុអ្វីបានជាសុវត្ថិភាព និងការប្ដូរត្រូវបានចោល?

នៅក្នុងការមើលពីក្រោយនេះ, យើងនឹងស្វែងយល់ពីរបៀបដែលយើងអភិវឌ្ឍមុខងារ អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនរបស់យើង, បង្កើតការប្រឈមមុខនឹងស្ថានភាពសេវាកម្ម SaaS, និងនាំមុខសុវត្ថិភាពដែលមានអំណាច និងអាចបត់បែនទៅកាន់អាជីវកម្មទាំងអស់។

មិនថាអ្នកជាក្រុមហ៊ុនចាប់ផ្តើមដែលមានក្តីសុបិន្តធំឬជាអ្នកលេងដែលបានបង្កើតឡើងហើយកំពុងស្វែងរកការបង្កើនដំណើរការរបស់អ្នក, អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនអាចអនុញ្ញាតឱ្យមានករណីប្រើថ្មីៗដែលអ្នកមិនដែលដឹងថាអាចធ្វើទៅបាន។

ការយល់ដឹងអំពីអាជ្ញាប័ណ្ណអ្នកប្រើផ្ទាល់ខ្លួន

មុននឹងយើងចូលទៅក្នុងដំណើររបស់យើងក្នុងការអភិវឌ្ឍអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនសម្រាប់ Blue, យើងសូមចំណាយពេលមួយដើម្បីយល់ពីអាជ្ញាប័ណ្ណអ្នកប្រើផ្ទាល់ខ្លួនគឺជាអ្វី និងហេតុអ្វីបានជាវាពិតជាសំខាន់ក្នុងកម្មវិធីគ្រប់គ្រងគម្រោង។

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

នៅក្នុងបរិបទនៃកម្មវិធីគ្រប់គ្រងគម្រោងដូចជា Blue, អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនរួមមាន៖

• ការគ្រប់គ្រងការចូលដែលមានភាពម៉ត់ចត់: កំណត់ថានរណាអាចមើល, កែប្រែ, ឬលុបប្រភេទទិន្នន័យគម្រោងជាក់លាក់។
• ការកំណត់មុខងារតាមមូលដ្ឋាន: អនុញ្ញាតឬបិទមុខងារមួយចំនួនសម្រាប់អ្នកប្រើឬក្រុមជាក់លាក់។
• កម្រិតអារម្មណ៍ទិន្នន័យ: កំណត់កម្រិតផ្សេងៗនៃការចូលទៅកាន់ព័ត៌មានដែលមានអារម្មណ៍នៅក្នុងគម្រោង។
• អាជ្ញាប័ណ្ណដែលពាក់ព័ន្ធនឹងដំណើរការ: សម្របសម្រួលសមត្ថភាពអ្នកប្រើជាមួយជំហានឬកត្តាជាក់លាក់នៃដំណើរការគម្រោងរបស់អ្នក។

សារៈសំខាន់នៃអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនក្នុងការគ្រប់គ្រងគម្រោងមិនអាចនិយាយអស់បានទេ៖

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

ទៅកាន់ YES

យើងបានសរសេរមុននេះ, ថាមុខងារទាំងអស់នៅក្នុង Blue ត្រូវតែជាការយល់ព្រម យ៉ាងខ្លាំង មុនពេលយើងសម្រេចចិត្តសាងសង់វា។ យើងមិនមានភាពស្រួលក្នុងការមានវិស្វករច្រើននិងចំណាយពេល និងប្រាក់ក្នុងការសាងសង់អ្វីដែលអតិថិជនមិនត្រូវការទេ។

ដូចនេះ, ផ្លូវទៅកាន់ការអនុវត្តអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួននៅក្នុង Blue មិនមែនជាបន្ទាត់ស្មើ។ ដូចជាមុខងារដែលមានអំណាចជាច្រើន, វាបានចាប់ផ្តើមដោយតម្រូវការជាក់លាក់ពីអ្នកប្រើរបស់យើង ហើយបានអភិវឌ្ឍតាមរយៈការពិចារណា និងការធ្វើផែនការ។

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

ក្រុមហ៊ុនចាប់ផ្តើមតូចៗដែលធ្វើការជាមួយអតិថិជនក្រៅ, ក្រុមហ៊ុនមធ្យមដែលមានដំណើរការអនុម័តស្មុគស្មាញ, និងអាជីវកម្មធំៗដែលមានតម្រូវការសុវត្ថិភាពតឹងរឹងបានបញ្ចេញតម្រូវការដូចគ្នា៖

ការបត់បែនបន្ថែមក្នុងការគ្រប់គ្រងការចូលដំណើរការរបស់អ្នកប្រើ។

បើទោះបីជាមានតម្រូវការដែលច្បាស់លាស់, យើងបានចាប់ផ្តើមចាប់អារម្មណ៍ក្នុងការចូលទៅក្នុងការអភិវឌ្ឍអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន។

ហេតុអ្វី?

យើងបានយល់ពីភាពស្មុគស្មាញដែលពាក់ព័ន្ធ!

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

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

វាបានច្បាស់ថាហេតុអ្វី: ការបង្កើតវាជាប្រហែលមួយចំនួន, និងហានិភ័យគឺខ្ពស់។

ការអនុវត្តអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនមិនត្រឹមតែអាចនាំឱ្យមានកំហុសដ៏សំខាន់ឬកង្វល់សុវត្ថិភាព, ប៉ុន្តែអាចធ្វើឱ្យប្រព័ន្ធទាំងមូលមានការប៉ះពាល់។ ការយល់ដឹងនេះបានបង្ហាញពីទំហំរបស់ការប្រឈមដែលយើងកំពុងពិចារណា។

ការប្រឈមមុខនឹងស្ថានភាពសេវាកម្ម

ទោះយ៉ាងណា, នៅពេលដែលយើងបន្តកើនឡើង និងអភិវឌ្ឍ, យើងបានឈានទៅរកការយល់ដឹងសំខាន់មួយ៖

គំរូ SaaS ប្រពៃណីដែលរក្សាមុខងារមានអំណាចសម្រាប់អតិថិជនសហគ្រាសមិនមានអត្ថន័យទៀតនៅក្នុងទីផ្សារអាជីវកម្មសព្វថ្ងៃ។

នៅឆ្នាំ 2024, ជាមួយអំណាចនៃ AI និងឧបករណ៍កម្រិតខ្ពស់, ក្រុមតូចអាចដំណើរការនៅកម្រិត និងភាពស្មុគស្មាញដែលប្រកួតប្រជែងជាមួយអង្គការធំៗ។ ក្រុមហ៊ុនចាប់ផ្តើមមួយអាចកំពុងដោះស្រាយទិន្នន័យអតិថិជនដែលមានអារម្មណ៍នៅក្នុងប្រទេសជាច្រើន។ អាជីវកម្មទីផ្សារតូចមួយអាចកំពុងចាប់ផ្តើមគម្រោងអតិថិជនជាច្រើនដែលមានតម្រូវការសម្ងាត់ផ្សេងៗគ្នា។ អាជីវកម្មទាំងនេះត្រូវការសុវត្ថិភាព និងការប្ដូរដូចជាអាជីវកម្មធំៗណាមួយ។

យើងបានសួរខ្លួនឯង៖ ហេតុអ្វីបានជាអចិន្រ្តៃយ៍នៃកម្លាំងនៃក្រុមហ៊ុនឬថវិកាគួរតែកំណត់សមត្ថភាពរបស់ពួកគេក្នុងការការពារទិន្នន័យ និងដំណើរការរបស់ពួកគេឱ្យមានប្រសិទ្ធភាព?

អាជ្ញាប័ណ្ណសម្រាប់សហគ្រាសសម្រាប់គ្រប់គ្នា

ការយល់ដឹងនេះបាននាំឱ្យយើងមានទស្សនៈមួយដែលឥឡូវនេះជាដំណើរការចម្បងនៃការអភិវឌ្ឍនៅ Blue: មុខងារមានគុណភាពសម្រាប់សហគ្រាសគួរត្រូវបានអាចចូលដំណើរការបានសម្រាប់អាជីវកម្មទាំងអស់។

យើងជឿថា:

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

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

ការសម្រេចចិត្តនេះបានដាក់យើងនៅលើផ្លូវនៃការរចនាដែលមានការពិចារណា, ការអភិវឌ្ឍដែលមានការបន្ត, និងមតិយោបល់ពីអ្នកប្រើដែលបន្តនាំឱ្យមានមុខងារ អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនដែលយើងមានមោទនភាពក្នុងការផ្តល់ជូននៅថ្ងៃនេះ។

នៅក្នុងផ្នែកបន្ទាប់, យើងនឹងចូលទៅក្នុងរបៀបដែលយើងបានចូលទៅក្នុងដំណើរការរចនានិងអភិវឌ្ឍដើម្បីនាំមុខមុខងារដែលមានភាពស្មុគស្មាញនេះទៅជីវិត។

ការរចនា និងការអភិវឌ្ឍ

នៅពេលដែលយើងបានសម្រេចចិត្តដោះស្រាយអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន, យើងបានយល់ឃើញយ៉ាងឆាប់រហ័សថាយើងកំពុងប្រឈមមុខនឹងការងារធំមួយ។

នៅការមើលដំបូង, "អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន" អាចស្តាប់ដូចជាអ្វីដែលមានភាពសាមញ្ញ, ប៉ុន្តែវាជាមុខងារដែលមានភាពស្មុគស្មាញយ៉ាងខ្លាំងដែលប៉ះពាល់ដល់គ្រប់ផ្នែកនៃប្រព័ន្ធរបស់យើង។

ការប្រឈមមុខគឺគួរឱ្យខ្លាច: យើងត្រូវការអនុវត្តអាជ្ញាប័ណ្ណដែលមានភាពចុះបន្ត, អនុញ្ញាតឱ្យមានការកែប្រែតាមរយៈការបន្ថែម, ធ្វើការផ្លាស់ប្តូរទិន្នន័យសំខាន់, និងធានាថាធ្វើការការងារយ៉ាងរលូននៅក្នុងអេកូស៊ីស្តេមទាំងមូលរបស់យើង – វេបសាយ, Mac, Windows, កម្មវិធី iOS និង Android, និង API និង webhook របស់យើង។

ភាពស្មុគស្មាញគឺគ្រប់គ្រងសម្រាប់អ្នកអភិវឌ្ឍដែលមានបទពិសោធន៍។

វិធីសាស្ត្ររបស់យើងផ្អែកលើគោលការណ៍សំខាន់ពីរដូចខាងក្រោម៖

1. បំបែកមុខងារទៅជាភាពអាចគ្រប់គ្រងបាន
2. ការទទួលយកការដឹកជញ្ជូនជាបន្ត។

នៅពេលដែលយើងប្រឈមមុខនឹងភាពស្មុគស្មាញនៃអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនទាំងមូល, យើងបានសួរខ្លួនឯងសំណួរមួយសំខាន់៖

តើអ្វីជាកំណត់ត្រាដំបូងដែលមានភាពសាមញ្ញបំផុតនៃមុខងារនេះ?

វិធីសាស្ត្រនេះស្របនឹងគោលការណ៍ agile នៃការផ្តល់ជូនផលិតផលដែលអាចប្រើបានអប្បបរមា (MVP) និងធ្វើការបន្ថែមដោយផ្អែកលើមតិយោបល់។

ចម្លើយរបស់យើងគឺមានភាពសាមញ្ញយ៉ាងចម្លែក៖

1. នាំចូលការបិទដើម្បីលាក់ផ្ទាំងសកម្មភាពគម្រោង
2. បន្ថែមការបិទផ្សេងទៀតដើម្បីលាក់ផ្ទាំងទម្រង់

នេះគឺជាអ្វីដែលមាន។

គ្មានសំឡេង និងស្លាក, គ្មានម៉ាត្រិកសិទ្ធិដែលស្មុគស្មាញ—គ្រាន់តែពីរបិទដែលសាមញ្ញប៉ុណ្ណោះ។

នៅពេលដែលវាអាចមើលទៅដូចជាមិនគួរឱ្យចាប់អារម្មណ៍នៅការមើលដំបូង, វីធីសាស្ត្រនេះផ្តល់អត្ថប្រយោជន៍ដ៏សំខាន់ជាច្រើន៖

• ការអនុវត្តឆាប់រហ័ស: ការបិទសាមញ្ញទាំងនេះអាចត្រូវបានអភិវឌ្ឍនិងតេស្តបានយ៉ាងឆាប់រហ័ស, អនុញ្ញាតឱ្យយើងទទួលបានមុខងារដំបូងនៃអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនចូលដល់ដៃអ្នកប្រើបានយ៉ាងឆាប់រហ័ស។
• តម្លៃអ្នកប្រើច្បាស់: ទោះបីជាមានតែជាជម្រើសទាំងនេះពីរប៉ុណ្ណោះ, យើងកំពុងផ្តល់តម្លៃដែលអាចចាប់អារម្មណ៍បាន។ ក្រុមខ្លះអាចចង់លាក់អត្ថបទសកម្មភាពពីអតិថិជន, ខណៈពេលដែលអ្នកផ្សេងទៀតអាចត្រូវការកំណត់ការចូលដំណើរការទៅកាន់ទម្រង់សម្រាប់ក្រុមអ្នកប្រើជាក់លាក់។
• មូលដ្ឋានសម្រាប់ការកើនឡើង: ការចាប់ផ្តើមសាមញ្ញនេះបានដាក់មូលដ្ឋានសម្រាប់អាជ្ញាប័ណ្ណដែលមានភាពស្មុគស្មាញជាងនេះ។ វាបានអនុញ្ញាតឱ្យយើងកំណត់រចនាសម្ព័ន្ធមូលដ្ឋានសម្រាប់អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនដោយមិនត្រូវបានគេចាប់ខ្លួនក្នុងភាពស្មុគស្មាញពីដំបូង។
• មតិយោបល់ពីអ្នកប្រើ: ដោយការបញ្ចេញកំណែសាមញ្ញនេះ, យើងអាចប្រមូលមតិយោបល់ពីពិភពលោកអំពីរបៀបដែលអ្នកប្រើអន្តរកម្មជាមួយអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន, ដែលជួយបង្កើនការអភិវឌ្ឍនាពេលអនាគត។
• ការសិក្សាបច្ចេកទេស: ការអនុវត្តដំបូងនេះបានផ្តល់ឱ្យក្រុមអភិវឌ្ឍន៍របស់យើងនូវបទពិសោធន៍ពិតប្រាកដក្នុងការផ្លាស់ប្តូរអាជ្ញាប័ណ្ណនៅលើវេទិការបស់យើង, ដែលបានរៀបចំយើងសម្រាប់ការបន្ថែមដែលមានភាពស្មុគស្មាញជាងនេះ។

ហើយអ្នកដឹងទេ, វាពិតជាមានអារម្មណ៍ស្រួលដើម្បីមានទស្សនៈធំសម្រាប់អ្វីមួយ, ហើយបន្ទាប់មកដាក់អ្វីមួយដែលជាភាគតិចនៃទស្សនៈនោះ។

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

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

ទីពីរ, គឺជាជម្រើសសម្រាប់អ្នកគ្រប់គ្រងគម្រោងដើម្បីបិទក្រុមអ្នកប្រើពីការអាចអញ្ជើញអ្នកប្រើផ្សេងទៀត។ នេះគឺល្អប្រសិនបើអ្នកមានគម្រោងដែលមានអារម្មណ៍ដែលអ្នកចង់ធានាថានៅលើមូលដ្ឋាន "ត្រូវមើល"។

មួយពេលដែលយើងបានបញ្ចេញនេះ, យើងមានការតស៊ូបន្ថែម និងសម្រាប់កំណែទីបីរបស់យើង, យើងបានដោះស្រាយអាជ្ញាប័ណ្ណកម្រិតជួរ, ដែលមានន័យថាអាចសម្រេចចិត្តថាតើក្រុមអ្នកប្រើជាក់លាក់អាចមើលឬកែប្រែទិន្នន័យកំណត់ត្រាអ្វីបានខ្លះ។

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

បន្ទាប់មក, យើងបានបន្តទៅកាន់ការបង្កើតអាជ្ញាប័ណ្ណដែលមានមូលដ្ឋានលើបញ្ជី, ដែលអ្នកគ្រប់គ្រងគម្រោងអាចសម្រេចចិត្តថាតើក្រុមអ្នកប្រើអាចមើល, កែប្រែ, និងលុបបញ្ជីជាក់លាក់មួយ។ ប្រសិនបើពួកគេលាក់បញ្ជីមួយ, កំណត់ត្រាទាំងអស់នៅក្នុងបញ្ជីនោះក៏ត្រូវបានលាក់ផងដែរ, ដែលគឺល្អព្រោះវាមានន័យថាអ្នកអាចលាក់ផ្នែកជាក់លាក់នៃដំណើរការរបស់អ្នកពីសមាជិកក្រុមឬអតិថិជន។

នេះគឺជាលទ្ធផលចុងក្រោយ៖

ការពិចារណាបច្ចេកទេស

នៅក្នុងចិត្តនៃស្ថាបត្យកម្មបច្ចេកទេសរបស់ Blue មាន GraphQL, ជាជម្រើសសំខាន់ដែលបានប៉ះពាល់យ៉ាងខ្លាំងដល់សមត្ថភាពរបស់យើងក្នុងការអនុវត្តមុខងារដែលមានភាពស្មុគស្មាញដូចជា អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន។ ប៉ុន្តែមុននឹងយើងចូលទៅក្នុងព័ត៌មានលម្អិត, យើងសូមចំណាយពេលមួយដើម្បីយល់ពីអ្វីដែល GraphQL គឺជាអ្វី និងវាផ្សេងពីវិធីសាស្ត្រ REST API ដែលមានប្រពៃណីយ៉ាងដូចម្តេច។
GraphQL ប្រៀបធៀបនឹង REST API: ការពន្យល់ដែលអាចចូលដំណើរការ

ស្រមៃថាអ្នកនៅក្នុងភោជនីយដ្ឋាន។ ជាមួយ REST API, វាដូចជាការបញ្ជាទិញពីម៉ឺនុយដែលបានកំណត់។ អ្នកស្នើសុំម្ហូបជាក់លាក់ (ចំណុចចូល), ហើយអ្នកទទួលបានអ្វីគ្រប់យ៉ាងដែលមកជាមួយវា, មិនថាអ្នកចង់បានវាទាំងអស់ឬអត់។ ប្រសិនបើអ្នកចង់ប្ដូរម្ហូបរបស់អ្នក, អ្នកអាចត្រូវការបញ្ជាទិញច្រើន (ការហៅ API) ឬស្នើសុំម្ហូបដែលបានរៀបចំជាពិសេស (ចំណុចចូលផ្ទាល់ខ្លួន)។

GraphQL, ទៅវិញ, គឺដូចជាការពិភាក្សាជាមួយអ្នកចម្អិនដែលអាចរៀបចំអ្វីគ្រប់យ៉ាង។ អ្នកប្រាប់អ្នកចម្អិនថាអ្នកចង់បានគ្រឿងផ្សំអ្វី (វាលទិន្នន័យ), និងនៅក្នុងបរិមាណអ្វី។ អ្នកចម្អិនបន្ទាប់មករៀបចំម្ហូបដែលគឺជាអ្វីដែលអ្នកបានស្នើសុំ - មិនច្រើនទេ, មិនតិចទេ។ នេះគឺជាអ្វីដែល GraphQL ធ្វើ - វាអនុញ្ញាតឱ្យអតិថិជនស្នើសុំទិន្នន័យដែលពួកគេចាំបាច់, ហើយម៉ាស៊ីនបម្រើផ្តល់ជូនតែអ្វីដែលបានស្នើសុំ។

អាហារថ្ងៃត្រង់សំខាន់មួយ

ប្រហែលប្រាំមួយសប្តាហ៍ចូលក្នុងការអភិវឌ្ឍដំបូងរបស់ Blue, វិស្វករដឹកនាំរបស់យើង និង CEO បានចេញទៅបរិច្ឆេទ។

ប្រធានបទនៃការពិភាក្សា?

ថាតើត្រូវប្ដូរពី REST API ទៅ GraphQL។ នេះមិនមែនជាការសម្រេចចិត្តដែលត្រូវធ្វើដោយមិនយកចិត្តទុកដាក់ - ការទទួលយក GraphQL នឹងមានន័យថាត្រូវបោះបង់ការងារដំបូងប្រាំមួយសប្តាហ៍។

នៅក្នុងការដើរចូលទៅកាន់ការិយាល័យ, CEO បានសួរសំណួរមួយសំខាន់ទៅវិស្វករដឹកនាំ៖ "តើយើងនឹងសោកស្តាយដែលមិនបានធ្វើវានៅប្រាំឆ្នាំពីឥឡូវនេះទេ?"

ចម្លើយបានច្បាស់: GraphQL គឺជាវិធីដែលត្រូវទៅ។

យើងបានស្គាល់សមត្ថភាពនៃបច្ចេកវិទ្យានេះនៅពេលដំបូង, មើលឃើញថាវាអាចគាំទ្រទស្សនៈរបស់យើងសម្រាប់វេទិកាគ្រប់គ្រងគម្រោងដែលមានភាពអាចបត់បែន និងមានអំណាច។

ការមើលឃើញរបស់យើងក្នុងការទទួលយក GraphQL បានផ្តល់ផលចំណេញនៅពេលដែលវាមកដល់ការអនុវត្តអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន។ ជាមួយ REST API, យើងនឹងត្រូវការចំណុចចូលផ្សេងៗសម្រាប់ការកំណត់អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនគ្រប់ប្រភេទ - វិធីសាស្ត្រដែលនឹងក្លាយជាការលំបាក និងពិបាកក្នុងការថែទាំ។

GraphQL, ទៅវិញ, អនុញ្ញាតឱ្យយើងគ្រប់គ្រងអាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនយ៉ាងឌីណាមិច។ នេះគឺជារបៀបដែលវាធ្វើការងារ៖

• ការត្រួតពិនិត្យអាជ្ញាប័ណ្ណតាមរយៈការបន្ថែម: នៅពេលដែលអតិថិជនធ្វើការស្នើសុំ, ម៉ាស៊ីនបម្រើ GraphQL របស់យើងអាចត្រួតពិនិត្យអាជ្ញាប័ណ្ណរបស់អ្នកប្រើត្រឹមពីមូលដ្ឋានទិន្នន័យរបស់យើង។
• ការទាញយកទិន្នន័យដែលមានភាពច្បាស់លាស់: ដោយផ្អែកលើអាជ្ញាប័ណ្ណទាំងនេះ, GraphQL ត្រឡប់តែទិន្នន័យដែលបានស្នើសុំដែលសមស្របជាមួយសិទ្ធិចូលរបស់អ្នកប្រើ។
• សំណើដែលអាចបត់បែន: នៅពេលដែលអាជ្ញាប័ណ្ណផ្លាស់ប្តូរ, យើងមិនត្រូវការបង្កើតចំណុចចូលថ្មី ឬកែប្រែចំណុចចូលដែលមានស្រាប់ទេ។ សំណើ GraphQL ដូចគ្នាអាចបត់បែនទៅតាមការកំណត់អាជ្ញាប័ណ្ណផ្សេងៗ។
• ការទាញយកទិន្នន័យដែលមានប្រសិទ្ធភាព: GraphQL អនុញ្ញាតឱ្យអតិថិជនស្នើសុំអ្វីដែលពួកគេចាំបាច់។ នេះមានន័យថាយើងមិនបានទាញយកទិន្នន័យច្រើនពេក, ដែលអាចបង្ហាញព័ត៌មានដែលអ្នកប្រើមិនគួរតែចូលដំណើរការ។

ភាពអាចបត់បែននេះគឺសំខាន់សម្រាប់មុខងារដែលមានភាពស្មុគស្មាញដូចជា អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួន។ វាអនុញ្ញាតឱ្យយើងផ្តល់ការគ្រប់គ្រងដែលមានភាពម៉ត់ចត់ ដោយគ្មាន ការបាត់បង់សមត្ថភាពឬការថែទាំ។

បញ្ហា

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

អន្តរកម្មអ្នកប្រើសម្រាប់អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនបានបង្ហាញពីការប្រឈមមួយទៀត។ យើងត្រូវការធ្វើឱ្យអន្តរកម្មមានភាពងាយស្រួល និងអាចគ្រប់គ្រងបានសម្រាប់អ្នកគ្រប់គ្រង, ទោះបីយើងបានបន្ថែមជម្រើសច្រើន និងបន្ថែមភាពស្មុគស្មាញទៅប្រព័ន្ធ។

ដំណោះស្រាយរបស់យើងបានរួមបញ្ចូលការធ្វើតេស្តអ្នកប្រើជាច្រើនដង និងការរចនាដែលមានការបន្ត។

យើងបានណែនាំម៉ាត្រិកអាជ្ញាប័ណ្ណដែលមានភាពច្បាស់លាស់ដែលអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងមើល និងកែប្រែអាជ្ញាប័ណ្ណឱ្យបានយ៉ាងឆាប់រហ័សនៅក្នុងតួនាទីនិងតំបន់គម្រោងផ្សេងៗ។

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

បន្ទាប់មក, យើងបានអភិវឌ្ឍស៊ុម UI ដែលអាចបត់បែនទៅតាមការផ្លាស់ប្តូរអាជ្ញាប័ណ្ណទាំងនេះនៅក្នុងពេលវេលាពិត, ផ្តល់នូវបទពិសោធន៍ដែលរលូនដោយគ្មានការលំបាកណាមួយ។

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

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

ការបញ្ចេញជាបន្ទាត់បានបង្ហាញពីការល្អឥតខ្ចោះ, ជួយយើងកំណត់ និងដោះស្រាយបញ្ហាដូចជាបញ្ហាដ៏តិចតួច និងចំណុចច្រឡំរបស់អ្នកប្រើដែលយើងមិនបានរំពឹងទុក, បញ្ចប់នាំឱ្យមានមុខងារដែលមានភាពស្អាត និងងាយស្រួលប្រើសម្រាប់អ្នកប្រើទាំងអស់របស់យើង។

វិធីសាស្ត្រនេះនៃការបញ្ចេញទៅកាន់ក្រុមអ្នកប្រើមួយចំនួន, រួមជាមួយនឹងរយៈពេល "Beta" ប្រហែល 2-3 សប្តាហ៍នៅលើ Beta សាធារណៈរបស់យើងជួយឱ្យយើងគេងបានស្រួលក្នុងយប់។ :)

ការមើលទៅមុខ

ដូចជាមុខងារទាំងអស់, គ្មានអ្វីដែលត្រូវបាន "បញ្ចប់"។

ទស្សនៈរយៈពេលវែងរបស់យើងសម្រាប់មុខងារ អាជ្ញាប័ណ្ណផ្ទាល់ខ្លួនបានពង្រីកទៅលើស្លាក, ការត្រួតពិនិត្យវាលផ្ទាល់ខ្លួន, ការបង្ហាញគម្រោងដែលអាចប្ដូរបាន, និងការគ្រប់គ្រងមតិយោបល់។

ចូរយើងចូលទៅក្នុងរាល់អត្ថបទ។

អាជ្ញាប័ណ្ណស្លាក

យើងគិតថាវានឹងអស្ចារ្យក្នុងការអាចបង្កើតអាជ្ញាប័ណ្ណដោយផ្អែកលើថាតើកំណត់ត្រាមួយមានស្លាកមួយឬច្រើន។ ករណីប្រើដែលច្បាស់លាស់បំផុតគឺថាអ្នកបង្កើតតួនាទីអ្នកប្រើផ្ទាល់ខ្លួនដែលមានឈ្មោះ "អតិថិជន" ហើយអនុញ្ញាតឱ្យអ្នកប្រើនៅក្នុងតួនាទីនោះមើលតែកំណត់ត្រាដែលមានស្លាក "អតិថិជន"។

នេះផ្តល់ឱ្យអ្នកនូវទិដ្ឋភាពមួយឱ្យមើលថាតើកំណត់ត្រាអាចឬមិនអាចមើលឃើញដោយអតិថិជនរបស់អ្នក។

នេះអាចក្លាយជាអំណាចជាងនេះជាមួយនឹង AND/OR combinators, ដែលអ្នកអាចកំណត់ច្បាប់ស្មុគស្មាញជាងនេះ។ ឧទាហរណ៍, អ្នកអាចកំណត់ច្បាប់មួយដែលអនុញ្ញាតឱ្យចូលទៅកាន់កំណត់ត្រាដែលមានស្លាកទាំង "អតិថិជន" និង "សាធារណៈ", ឬកំណត់ត្រាដែលមានស្លាកទាំង "ក្នុងស្រុក" ឬ "សម្ងាត់"។ កម្រិតនៃភាពអាចបត់បែននេះអាចអនុញ្ញាតឱ្យមានការកំណត់អាជ្ញាប័ណ្ណដែលមានភាពច្បាស់លាស់ខ្ពស់, បំពេញតម្រូវការដែលមានភាពស្មុគស្មាញបំផុត។

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

ការត្រួតពិនិត្យវាលផ្ទាល់ខ្លួន

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

ស្រមៃថាអ្នកអាចកំណត់អាជ្ញាប័ណ្ណដូចខាងក្រោម៖

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

ការបង្ហាញគម្រោងដែលអាចប្ដូរបាន

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

ការគ្រប់គ្រងមតិយោបល់

នៅក្នុងអនាគត, យើងចង់មានការច្នៃប្រឌិតក្នុងរបៀបដែលយើងអនុញ្ញាតឱ្យអតិថិជនរបស់យើងសម្រេចចិត្តថានរណាអាចមើលឬមិនអាចមើលមតិយោបល់។ យើងអាចអនុញ្ញាតឱ្យមានតំបន់មតិយោបល់ដែលមានបន្ទាត់ច្រើននៅក្រោមកំណត់ត្រាមួយ, ហើយមួយៗអាចមើលឬមិនមើលឱ្យក្រុមអ្នកប្រើផ្សេងៗ។

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

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

ដូច្នេះមាននេះ, នេះគឺជារបៀបដែលយើងបានចូលទៅក្នុងការសាងសង់មុខងារដែលគួរឱ្យចាប់អារម្មណ៍ និងមានអំណាចបំផុតមួយ! ដូចដែលអ្នកអាចមើលឃើញនៅក្នុងឧបករណ៍ប្រៀបធៀបគម្រោងរបស់យើង, មានតែបន្តិចបន្តួចនៃប្រព័ន្ធគ្រប់គ្រងគម្រោងដែលមានការកំណត់អាជ្ញាប័ណ្ណដែលមានអំណាចដូចនេះ, ហើយអ្នកដែលមានវាគឺរក្សាទុកសម្រាប់ផែនការសហគ្រាសដែលមានតម្លៃខ្ពស់បំផុត, ធ្វើឱ្យវាមិនអាចចូលដំណើរការបានសម្រាប់ក្រុមហ៊ុនតូចឬមធ្យមធម្មតា។

ជាមួយ Blue, អ្នកមាន មុខងារទាំងអស់ ដែលអាចចូលដំណើរការបានជាមួយផែនការរបស់យើង—យើងមិនជឿថាមុខងារមានគុណភាពសម្រាប់សហគ្រាសគួរតែរក្សាទុកសម្រាប់អតិថិជនសហគ្រាសទេ!