របៀបដែលយើងជ្រើសរើសគំនិតសម្រាប់ការអភិវឌ្ឍន៍ផលិតផលរបស់យើង៖ អ្នកលក់ត្រូវតែអាចស្តាប់…

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងចែករំលែកបទពិសោធន៍របស់ខ្ញុំក្នុងការជ្រើសរើសគំនិតសម្រាប់ការអភិវឌ្ឍន៍មុខងារនៃផលិតផលរបស់យើង និងប្រាប់អ្នកពីរបៀបរក្សាវ៉ិចទ័រអភិវឌ្ឍន៍សំខាន់ៗ។

យើងកំពុងបង្កើតប្រព័ន្ធទូទាត់ដោយស្វ័យប្រវត្តិ (ACS) - ការចេញវិក្កយបត្រ។ រយៈពេល
អាយុកាលនៃផលិតផលរបស់យើងគឺ 14 ឆ្នាំ។ ក្នុងអំឡុងពេលនេះ ប្រព័ន្ធបានផ្លាស់ប្តូរពីកំណែដំបូងនៃអ្នកវាយតម្លៃឧស្សាហកម្មទៅជាស្មុគស្មាញម៉ូឌុលដែលមានផលិតផល 18 ដែលបំពេញគ្នាទៅវិញទៅមក។ ទិដ្ឋភាពដ៏សំខាន់បំផុតមួយនៃភាពជាប់បានយូរសម្រាប់កម្មវិធីគឺការអភិវឌ្ឍន៍ជាបន្តបន្ទាប់។ ហើយគំនិតគឺចាំបាច់សម្រាប់ការអភិវឌ្ឍន៍។

Идеи

ប្រភព។

មាន 5 ប្រភព៖

1. មិត្តចម្បងរបស់អ្នកបង្កើតប្រព័ន្ធព័ត៌មានសាជីវកម្មគឺ អតិថិជន. ហើយអតិថិជនគឺជារូបភាពសមូហភាពនៃអ្នកធ្វើការសម្រេចចិត្ត អ្នកឧបត្ថម្ភគម្រោង ម្ចាស់ និងអ្នកប្រតិបត្តិនៃដំណើរការ អ្នកឯកទេសផ្នែកព័ត៌មានវិទ្យាក្នុងផ្ទះ អ្នកប្រើប្រាស់ធម្មតា និងមនុស្សមួយចំនួនធំដែលចាប់អារម្មណ៍លើកម្រិតផ្សេងៗគ្នា។ វាមានសារៈសំខាន់សម្រាប់យើងដែលតំណាងរបស់អតិថិជននីមួយៗមានសក្តានុពលជាអ្នកផ្គត់ផ្គង់គំនិត។ ក្នុងករណីដ៏អាក្រក់បំផុត យើងទទួលបានតែមតិកែលម្អអវិជ្ជមានអំពីបញ្ហានៅក្នុងប្រព័ន្ធប៉ុណ្ណោះ។ ល្អបំផុត គឺមានមនុស្សម្នាក់នៅខាងអតិថិជន ដែលជាប្រភពនៃគំនិតឥតឈប់ឈរសម្រាប់ការកែលម្អ ផ្តល់ព័ត៌មានដែលមានរចនាសម្ព័ន្ធអំពីតម្រូវការរបស់អតិថិជន។
2. របស់យើង អ្នកលក់ និងអ្នកគ្រប់គ្រងគណនី គឺជាប្រភពដ៏សំខាន់បំផុតទីពីរនៃគំនិតសម្រាប់ការកែលម្អ។ ពួកគេប្រាស្រ័យទាក់ទងគ្នាច្រើន និងសកម្មជាមួយអ្នកតំណាងឧស្សាហកម្ម ទទួលសំណើដោយផ្ទាល់ដៃសម្រាប់មុខងារចេញវិក្កយបត្រពីអតិថិជនសក្តានុពល។ ពាណិជ្ជករ និងគណនីត្រូវតែដឹងអំពីការផ្លាស់ប្តូរសំខាន់ៗទាំងអស់នៅក្នុងមុខងាររបស់ពួកគេ និងការអាប់ដេតកម្មវិធីចុងក្រោយបំផុតរបស់ដៃគូប្រកួតប្រជែង អាចបង្ហាញអំពីគុណសម្បត្តិ និងគុណវិបត្តិនៃដំណោះស្រាយផ្សេងៗ។ វាគឺជាបុគ្គលិករបស់យើងទាំងនេះ ដែលមានអារម្មណ៍ដំបូងគេ ប្រសិនបើលក្ខណៈវិក្កយបត្រមួយចំនួនក្លាយជាស្តង់ដារជាក់ស្តែង ដោយគ្មានកម្មវិធីនោះមិនអាចចាត់ទុកថាពេញលេញបានទេ។
3. ម្ចាស់ផលិតផល អ្នកគ្រប់គ្រងកំពូលម្នាក់របស់យើង ឬអ្នកគ្រប់គ្រងគម្រោងដែលមានបទពិសោធន៍ច្រើន។ រក្សាគោលដៅយុទ្ធសាស្ត្ររបស់ក្រុមហ៊ុនក្នុងចិត្ត និងកែសម្រួលផែនការអភិវឌ្ឍន៍ផលិតផលស្របតាមពួកគេ។
4. ស្ថាបត្យករជាមនុស្សម្នាក់ដែលយល់ពីលទ្ធភាព និងដែនកំណត់នៃដំណោះស្រាយបច្ចេកវិជ្ជាដែលបានជ្រើសរើស/ប្រើប្រាស់ និងឥទ្ធិពលរបស់វាទៅលើការអភិវឌ្ឍន៍ផលិតផល។
   ក្រុមអភិវឌ្ឍន៍ និងសាកល្បង។ មនុស្សដែលចូលរួមដោយផ្ទាល់ក្នុងការអភិវឌ្ឍន៍ផលិតផល។

ចំណាត់ថ្នាក់នៃការទស្សនា

យើងទទួលបានទិន្នន័យឆៅពីប្រភព - សំបុត្រ សំបុត្រ សំណើផ្ទាល់មាត់។ ទាំងអស់។
បណ្តឹងឧទ្ធរណ៍ត្រូវបានចាត់ថ្នាក់៖

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

មានស្ថិតិបែបនេះនៅលើការទស្សនា - ភ្លាមៗបន្ទាប់ពីការចេញផ្សាយចំនួននៃការទស្សនាកើនឡើង 10-15% ក្នុងរយៈពេលខ្លី។ វាក៏មានការហៅចេញផងដែរ នៅពេលដែលអតិថិជនថ្មីដែលមានអ្នកប្រើប្រាស់មួយចំនួនធំមកសេវាកម្មពពករបស់យើង។ មនុស្សកំពុងរៀនប្រើមុខងារកម្មវិធីថ្មីៗ ពួកគេត្រូវការដំបូន្មាន។ សូម្បីតែអតិថិជនតូចមួយនៅពេលចាប់ផ្តើមការងារនៅក្នុងប្រព័ន្ធក៏ងាយឆេះការពិគ្រោះយោបល់ច្រើនជាង 100 ម៉ោងក្នុងមួយខែ។ ដូច្នេះនៅពេលភ្ជាប់អតិថិជនថ្មី យើងតែងតែទុកពេលវេលាសម្រាប់ការពិគ្រោះយោបល់ដំបូង។ ជាញឹកញយ យើងថែមទាំងជ្រើសរើសអ្នកឯកទេសជាក់លាក់ទៀតផង។ ពិតណាស់ តម្លៃជួលមិនសងថ្លៃពលកម្មទាំងនេះទេ ប៉ុន្តែយូរ ៗ ទៅស្ថានភាពបានធ្លាក់ចុះ។ តាមក្បួនមួយរយៈពេលនៃការសម្របខ្លួនត្រូវចំណាយពេលពី 1 ទៅ 3 ខែ បន្ទាប់ពីនោះតម្រូវការសម្រាប់ការប្រឹក្សាត្រូវបានកាត់បន្ថយយ៉ាងខ្លាំង។

ពីមុន យើងប្រើដំណោះស្រាយដែលសរសេរដោយខ្លួនឯងដើម្បីរក្សាទុកការហៅទូរសព្ទ។ ប៉ុន្តែបន្តិចម្តង ៗ ប្តូរទៅផលិតផល Atlassian ។ ទីមួយការអភិវឌ្ឍន៍ត្រូវបានផ្ទេរដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការធ្វើការលើ Agile បន្ទាប់មកការគាំទ្រ។ ឥឡូវនេះដំណើរការសំខាន់ៗទាំងអស់រស់នៅក្នុង Jira SD បូករួមទាំងកម្មវិធីជំនួយផ្សេងៗសម្រាប់ Jira បូកនឹង Confluence។ ដំណោះស្រាយដែលសរសេរដោយខ្លួនឯងនៅតែមានតែលើដំណើរការដែលមិនសំខាន់សម្រាប់សកម្មភាពរបស់ក្រុមហ៊ុន។ វាបានប្រែក្លាយថាភារកិច្ចរបស់យើងឥឡូវនេះគឺពីទីបញ្ចប់ទៅចុងបញ្ចប់ពួកគេអាចត្រូវបានផ្ទេររវាងការគាំទ្រនិងការអភិវឌ្ឍន៍ដោយមិនលោតពីប្រព័ន្ធមួយទៅប្រព័ន្ធមួយទៀត។

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

ដំណើរការសំណើផ្លាស់ប្តូរ

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

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

ការគ្រប់គ្រងមុខងារផលិតផល

Backlog ប្រមូលបានសំណើសម្រាប់ការផ្លាស់ប្តូរ និងការអភិវឌ្ឍន៍។ រៀងរាល់ប្រាំមួយខែម្តង ក្រុមប្រឹក្សាបច្ចេកទេស ដែលរួមមាននាយក ប្រធានផ្នែកថែទាំ ការអភិវឌ្ឍន៍ ការលក់ និងស្ថាបត្យករប្រព័ន្ធ បានជួបប្រជុំគ្នា។ នៅក្នុងទម្រង់នៃការពិភាក្សា ក្រុមប្រឹក្សាបានវិភាគ និងផ្តល់អាទិភាពលើកម្មវិធីពី backlog ហើយយល់ព្រមលើកិច្ចការអភិវឌ្ឍន៍ចំនួន 5 សម្រាប់ការអនុវត្តនៅក្នុងការចេញផ្សាយបន្ទាប់។

ជាការពិត ក្រុមប្រឹក្សាបច្ចេកទេសឆ្លើយតបទៅនឹងតម្រូវការនៃឧស្សាហកម្ម និងទីផ្សារ ដោយពិចារណាលើតម្រូវការដែលបានកត់ត្រានៅក្នុងកម្មវិធី។ អ្វីគ្រប់យ៉ាងដែលពាក់ព័ន្ធតិចតួចនៅតែមាននៅក្នុង backlog និងមិនឈានដល់ការអភិវឌ្ឍន៍។

ចំណាត់ថ្នាក់នៃសំណើផ្លាស់ប្តូរ និងហិរញ្ញវត្ថុ

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

សំណើផ្លាស់ប្តូរត្រូវបានចាត់ថ្នាក់ដូចខាងក្រោមៈ តម្រូវការជាក់លាក់នៃឧស្សាហកម្ម ឬលក្ខណៈបុគ្គលរបស់សហគ្រាស; ចំនួនដ៏សំខាន់នៃមុខងារថ្មី ឬការជួសជុលតូចមួយ។ ការជួសជុលតូចតាច និងសំណើបុគ្គលត្រូវបានដំណើរការដោយគ្មានបញ្ហា។ សំណើបុគ្គលត្រូវបានគណនា និងអនុវត្តសម្រាប់អតិថិជនជាក់លាក់ដែលជាផ្នែកមួយនៃការងារគម្រោងជាមួយគាត់។

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

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

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

DevOps

ការអភិវឌ្ឍន៍រៀបចំការចេញផ្សាយធំពីរក្នុងមួយឆ្នាំ។ នៅក្នុងការចេញផ្សាយនីមួយៗ ពេលវេលាត្រូវបានបម្រុងទុកសម្រាប់ការអនុវត្តកិច្ចការចំនួន 5 ដែលទទួលបានពីក្រុមប្រឹក្សាបច្ចេកទេស។ ដូច្នេះហើយ នៅពីក្រោយការប្រែក្លាយ យើងមិនដែលភ្លេចអំពីការអភិវឌ្ឍន៍ផលិតផលនោះទេ។

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

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

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

ប្រភព: www.habr.com