ວິທີທີ່ພວກເຮົາເລືອກແນວຄວາມຄິດສໍາລັບການພັດທະນາຜະລິດຕະພັນຂອງພວກເຮົາ: ຜູ້ຂາຍຕ້ອງສາມາດໄດ້ຍິນ ...

ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຈະແບ່ງປັນປະສົບການຂອງຂ້າພະເຈົ້າໃນການເລືອກແນວຄວາມຄິດສໍາລັບການພັດທະນາການເຮັດວຽກຂອງຜະລິດຕະພັນຂອງພວກເຮົາແລະບອກທ່ານວິທີການຮັກສາ vectors ຕົ້ນຕໍຂອງການພັດທະນາ.

ພວກເຮົາກໍາລັງພັດທະນາລະບົບການຊໍາລະອັດຕະໂນມັດ (ACP) - ໃບບິນ. ໄລຍະ
ຊີວິດຂອງຜະລິດຕະພັນຂອງພວກເຮົາແມ່ນ 14 ປີ. ໃນເວລານີ້, ລະບົບໄດ້ພັດທະນາຈາກຮຸ່ນທໍາອິດຂອງລະບົບອັດຕາພາສີອຸດສາຫະກໍາໄປສູ່ສະລັບສັບຊ້ອນແບບໂມດູນທີ່ປະກອບດ້ວຍ 18 ຜະລິດຕະພັນທີ່ໃຫ້ກັນແລະກັນ. ຫນຶ່ງໃນລັກສະນະທີ່ສໍາຄັນທີ່ສຸດຂອງອາຍຸຍືນສໍາລັບໂຄງການແມ່ນການພັດທະນາຢ່າງຕໍ່ເນື່ອງ. ແລະການພັດທະນາຮຽກຮ້ອງໃຫ້ມີແນວຄວາມຄິດ.

ແນວຄວາມຄິດ

ແຫຼ່ງຂໍ້ມູນ

ມີ 5 ແຫຼ່ງ:

1. ໝູ່ຫຼັກຂອງຜູ້ພັດທະນາລະບົບຂໍ້ມູນຂ່າວສານຂອງບໍລິສັດແມ່ນ ລູກ​ຄ້າ. ແລະລູກຄ້າແມ່ນຮູບພາບລວມຂອງຜູ້ຕັດສິນໃຈ, ຜູ້ສະຫນັບສະຫນູນໂຄງການ, ເຈົ້າຂອງແລະຜູ້ປະຕິບັດຂະບວນການ, ຜູ້ຊ່ຽວຊານດ້ານໄອທີພາຍໃນ, ຜູ້ໃຊ້ທົ່ວໄປແລະຈໍານວນຜູ້ສົນໃຈຫຼາຍໃນລະດັບທີ່ແຕກຕ່າງກັນ. ມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາທີ່ຕົວແທນຂອງລູກຄ້າແຕ່ລະຄົນມີທ່າແຮງທີ່ຈະເປັນຜູ້ສະຫນອງແນວຄວາມຄິດ. ໃນກໍລະນີຮ້າຍແຮງທີ່ສຸດ, ພວກເຮົາພຽງແຕ່ໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນໃນທາງລົບກ່ຽວກັບບັນຫາໃນລະບົບ. ໃນກໍລະນີທີ່ດີທີ່ສຸດ, ມີບຸກຄົນທີ່ຢູ່ຂ້າງລູກຄ້າທີ່ເປັນແຫຼ່ງຄົງທີ່ຂອງແນວຄວາມຄິດສໍາລັບການປັບປຸງ, ໃຫ້ຂໍ້ມູນທີ່ມີໂຄງສ້າງກ່ຽວກັບຄວາມຕ້ອງການຂອງລູກຄ້າ.
2. ຂອງພວກເຮົາ ພະນັກງານຂາຍ ແລະຜູ້ຈັດການບັນຊີ ເປັນ​ແຫຼ່ງ​ທີ່​ສໍາ​ຄັນ​ທີ່​ສອງ​ຂອງ​ແນວ​ຄວາມ​ຄິດ​ສໍາ​ລັບ​ການ​ປັບ​ປຸງ​. ພວກເຂົາເຈົ້າຕິດຕໍ່ສື່ສານຢ່າງຫ້າວຫັນແລະກວ້າງຂວາງກັບຜູ້ຕາງຫນ້າອຸດສາຫະກໍາແລະໄດ້ຮັບການສອບຖາມຄັ້ງທໍາອິດກ່ຽວກັບການເຮັດວຽກການເອີ້ນເກັບເງິນຈາກລູກຄ້າທີ່ມີທ່າແຮງ. ຜູ້ຂາຍແລະບັນຊີຕ້ອງຮັບຮູ້ເຖິງການປ່ຽນແປງທີ່ສໍາຄັນທັງຫມົດໃນຫນ້າທີ່ຂອງພວກເຂົາແລະການປັບປຸງຫລ້າສຸດຂອງຊອບແວຂອງຄູ່ແຂ່ງ, ແລະສາມາດຊີ້ໃຫ້ເຫັນເຖິງຂໍ້ດີແລະຂໍ້ເສຍຂອງວິທີແກ້ໄຂທີ່ແຕກຕ່າງກັນ. ເຫຼົ່ານີ້ແມ່ນພະນັກງານຂອງພວກເຮົາຜູ້ທີ່ມີຄວາມຮູ້ສຶກທໍາອິດຖ້າຫາກວ່າຄວາມສາມາດການເອີ້ນເກັບເງິນບາງກາຍເປັນມາດຕະຖານ de facto, ໂດຍບໍ່ມີການທີ່ຊອບແວບໍ່ສາມາດພິຈາລະນາສໍາເລັດ.
3. ເຈົ້າຂອງຜະລິດຕະພັນ — ຫນຶ່ງໃນຜູ້ຈັດການຊັ້ນນໍາຂອງພວກເຮົາຫຼືຜູ້ຈັດການໂຄງການທີ່ມີປະສົບການຫຼາຍ. ຮັກສາເປົ້າຫມາຍຍຸດທະສາດຂອງບໍລິສັດຢູ່ໃນໃຈແລະປັບແຜນການພັດທະນາຜະລິດຕະພັນໃຫ້ສອດຄ່ອງກັບພວກເຂົາ.
4. Architect, ບຸກຄົນທີ່ເຂົ້າໃຈຄວາມສາມາດແລະຂໍ້ຈໍາກັດຂອງວິທີແກ້ໄຂເຕັກໂນໂລຢີທີ່ເລືອກ / ໃຊ້ແລະຜົນກະທົບຕໍ່ການພັດທະນາຜະລິດຕະພັນ.
   ທີມ​ງານ​ການ​ພັດ​ທະ​ນາ​ແລະ​ການ​ທົດ​ສອບ​. ຜູ້ທີ່ມີສ່ວນຮ່ວມໂດຍກົງໃນການພັດທະນາຜະລິດຕະພັນ.

ການຈັດປະເພດຄໍາຮ້ອງຂໍ

ພວກເຮົາໄດ້ຮັບຂໍ້ມູນດິບຈາກແຫຼ່ງຕ່າງໆ - ຈົດຫມາຍ, ປີ້, ຄໍາຮ້ອງຂໍຄໍາ. ທັງໝົດ
ການອຸທອນຖືກຈັດປະເພດ:

• ປຶກສາຫາລື ດ້ວຍຄວາມຫມາຍ "ເຮັດແນວໃດມັນ?", "ມັນເຮັດວຽກແນວໃດ?", "ເປັນຫຍັງມັນບໍ່ເຮັດວຽກ?", "ຂ້ອຍບໍ່ເຂົ້າໃຈ ... ". ການຮ້ອງຂໍປະເພດນີ້ໄປຫາສາຍສະຫນັບສະຫນູນລະດັບ 1. ມັນເປັນໄປໄດ້ທີ່ຈະ retrain ການປຶກສາຫາລືເຂົ້າໄປໃນປະເພດອື່ນໆຂອງການຮ້ອງຂໍ.
• ເຫດການ ຫມາຍຄວາມວ່າ "ບໍ່ເຮັດວຽກ" ແລະ "ຄວາມຜິດພາດ". ປະມວນຜົນໂດຍ 2 ແລະ 3 ສາຍສະຫນັບສະຫນູນ. ຖ້າການແກ້ໄຂດ່ວນແລະການປ່ອຍ patch ແມ່ນມີຄວາມຈໍາເປັນ, ພວກເຂົາສາມາດຖືກໂອນຈາກການສະຫນັບສະຫນູນໂດຍກົງກັບການພັດທະນາ. ມັນເປັນໄປໄດ້ທີ່ຈະຈັດປະເພດມັນເປັນຄໍາຮ້ອງຂໍການປ່ຽນແປງໃຫມ່ແລະສົ່ງໄປທີ່ backlog.
• ການຮ້ອງຂໍການປ່ຽນແປງແລະການພັດທະນາ. ພວກເຂົາເຈົ້າເຂົ້າໄປໃນ backlog ຜະລິດຕະພັນ, bypassing ສາຍສະຫນັບສະຫນູນ. ແຕ່ມີຂັ້ນຕອນການປຸງແຕ່ງແຍກຕ່າງຫາກສໍາລັບພວກເຂົາ.

ມີສະຖິຕິກ່ຽວກັບການຮ້ອງຂໍ: ທັນທີຫຼັງຈາກການປ່ອຍຕົວ, ຈໍານວນຄໍາຮ້ອງຂໍເພີ່ມຂຶ້ນ 10-15% ໃນເວລາສັ້ນໆ. ນອກຈາກນີ້ຍັງມີການຮ້ອງຂໍເພີ່ມຂຶ້ນເມື່ອລູກຄ້າໃຫມ່ທີ່ມີຈໍານວນຜູ້ໃຊ້ຈໍານວນຫລາຍເຂົ້າມາບໍລິການຟັງຂອງພວກເຮົາ. ປະຊາຊົນກໍາລັງຮຽນຮູ້ທີ່ຈະນໍາໃຊ້ຄວາມສາມາດຂອງຊອບແວໃຫມ່, ພວກເຂົາຕ້ອງການຄໍາແນະນໍາ. ເຖິງແມ່ນວ່າລູກຄ້າຂະຫນາດນ້ອຍ, ໃນເວລາທີ່ເລີ່ມຕົ້ນເຮັດວຽກຢູ່ໃນລະບົບ, ໄດ້ຢ່າງງ່າຍດາຍໄຫມ້ຫຼາຍກ່ວາ 100 ຊົ່ວໂມງຂອງການປຶກສາຫາລືຕໍ່ເດືອນ. ດັ່ງນັ້ນ, ເມື່ອເຊື່ອມຕໍ່ລູກຄ້າໃຫມ່, ພວກເຮົາສະເຫມີສະຫງວນເວລາສໍາລັບການປຶກສາຫາລືເບື້ອງຕົ້ນ. ເລື້ອຍໆພວກເຮົາເລືອກຜູ້ຊ່ຽວຊານສະເພາະ. ລາຄາເຊົ່າ, ແນ່ນອນ, ບໍ່ໄດ້ກວມເອົາຄ່າໃຊ້ຈ່າຍແຮງງານເຫຼົ່ານີ້, ແຕ່ເມື່ອເວລາຜ່ານໄປ, ສະຖານະການຈະອອກ. ໄລຍະເວລາການປັບຕົວມັກຈະໃຊ້ເວລາຈາກ 1 ຫາ 3 ເດືອນ, ຫຼັງຈາກນັ້ນ, ຄວາມຕ້ອງການໃຫ້ຄໍາປຶກສາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.

ກ່ອນຫນ້ານີ້, ພວກເຮົາໃຊ້ວິທີແກ້ໄຂທີ່ຂຽນດ້ວຍຕົນເອງເພື່ອເກັບຮັກສາຄໍາຮ້ອງຂໍ. ແຕ່ພວກເຮົາຄ່ອຍໆປ່ຽນໄປຫາຜະລິດຕະພັນ Atlassian. ຫນ້າທໍາອິດ, ພວກເຮົາໄດ້ໂອນການພັດທະນາເພື່ອເຮັດໃຫ້ມັນງ່າຍຕໍ່ການເຮັດວຽກຕາມ Agile, ຫຼັງຈາກນັ້ນສະຫນັບສະຫນູນ. ໃນປັດຈຸບັນຂະບວນການທີ່ສໍາຄັນທັງຫມົດອາໄສຢູ່ໃນ Jira SD, ບວກກັບພວກເຂົາໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍ plugins ຕ່າງໆສໍາລັບ Jira, ບວກກັບ Confluence. ການແກ້ໄຂທີ່ຂຽນດ້ວຍຕົນເອງແມ່ນຍັງມີພຽງແຕ່ສໍາລັບຂະບວນການທີ່ບໍ່ສໍາຄັນສໍາລັບກິດຈະກໍາຂອງບໍລິສັດ. ມັນ turns ໃຫ້ ເຫັນ ວ່າ ວຽກ ງານ ຂອງ ພວກ ເຮົາ ໃນ ປັດ ຈຸ ບັນ ແມ່ນ ຂ້າມ ຕັດ ແລະ ສາ ມາດ ໂອນ ລະ ຫວ່າງ ການ ສະ ຫນັບ ສະ ຫນູນ ແລະ ການ ພັດ ທະ ນາ ໂດຍ ບໍ່ ມີ ການ ກະ ໂດດ ຈາກ ລະ ບົບ ຫນຶ່ງ ໄປ ອີກ.

ຈາກການເຊື່ອມຕໍ່ນີ້ພວກເຮົາສາມາດໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບວຽກງານທັງຫມົດ, ຄ່າແຮງງານຕາມແຜນການແລະຕົວຈິງ, ການນໍາໃຊ້ທາງເລືອກລາຄາຕ່າງໆສໍາລັບລູກຄ້າແລະສ້າງເອກະສານສໍາລັບຄວາມຕ້ອງການພາຍໃນແລະການລາຍງານລູກຄ້າ.

ກຳລັງປະມວນຜົນຄຳຮ້ອງຂໍການປ່ຽນແປງ

ໂດຍປົກກະຕິ, ການຮ້ອງຂໍດັ່ງກ່າວມາໃນຮູບແບບຂອງຂໍ້ກໍານົດການເຮັດວຽກ. ນັກວິເຄາະຂອງພວກເຮົາສຶກສາຄໍາຮ້ອງຂໍ, ສ້າງຂໍ້ກໍາຫນົດແລະລະດັບດ້ານວິຊາການດ້ານເທິງ. ໂອນຂໍ້ມູນຈໍາເພາະແລະຂໍ້ກໍານົດດ້ານວິຊາການໃຫ້ກັບຜູ້ທີ່ສົ່ງຄໍາຮ້ອງຂໍການອະນຸມັດ - ພວກເຮົາຕ້ອງແນ່ໃຈວ່າພວກເຮົາເວົ້າພາສາດຽວກັນກັບລູກຄ້າ.

ໄດ້ຮັບການຢືນຢັນຈາກລູກຄ້າທີ່ພວກເຮົາເຂົ້າໃຈກັນຢ່າງຖືກຕ້ອງ, ນັກວິເຄາະເຂົ້າໄປໃນຄໍາຮ້ອງຂໍເຂົ້າໄປໃນ backlog ຜະລິດຕະພັນ.

ການຄຸ້ມຄອງການທໍາງານຂອງຜະລິດຕະພັນ

backlog ໄດ້ສະສົມການຮ້ອງຂໍທີ່ເຂົ້າມາສໍາລັບການປ່ຽນແປງແລະການພັດທະນາ. ສະພາວິຊາການ, ປະກອບດ້ວຍຜູ້ອໍານວຍການ, ຫົວຫນ້າສະຫນັບສະຫນູນ, ການພັດທະນາ, ການຂາຍແລະສະຖາປະນິກລະບົບ, ກອງປະຊຸມທຸກໆຫົກເດືອນ. ໃນ​ຮູບ​ແບບ​ການ​ສົນ​ທະ​ນາ, ຄະ​ນະ​ກໍາ​ມະ​ການ​ວິ​ເຄາະ​ແລະ​ຈັດ​ລໍາ​ດັບ​ຄວາມ​ສໍາ​ຄັນ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຈາກ backlog ແລະ​ເຫັນ​ດີ​ກ່ຽວ​ກັບ 5 ວຽກ​ງານ​ພັດ​ທະ​ນາ​ສໍາ​ລັບ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ການ​ປ່ອຍ​ຕໍ່​ໄປ​.

ໃນຄວາມເປັນຈິງ, ສະພາວິຊາການຕອບສະຫນອງຄວາມຕ້ອງການຂອງອຸດສາຫະກໍາແລະຕະຫຼາດໂດຍການທົບທວນຄວາມຕ້ອງການທີ່ສະແດງອອກໃນຄໍາຮ້ອງສະຫມັກ. ທຸກສິ່ງທຸກຢ່າງທີ່ມີຄວາມກ່ຽວຂ້ອງຫນ້ອຍຍັງຄົງຢູ່ໃນ backlog ແລະບໍ່ສາມາດບັນລຸການພັດທະນາ.

ການຈັດປະເພດຂອງການຮ້ອງຂໍການປ່ຽນແປງແລະການເງິນ

ການພັດທະນາແມ່ນລາຄາແພງ. ດັ່ງນັ້ນ, ພວກເຮົາຈະບອກທ່ານທັນທີວ່າທາງເລືອກໃດທີ່ພວກເຮົາອາດຈະມີຖ້າການຮ້ອງຂໍການປ່ຽນແປງມາຈາກລູກຄ້າແລະບໍ່ແມ່ນພະນັກງານ.

ພວກເຮົາຈັດປະເພດການຮ້ອງຂໍການປ່ຽນແປງດັ່ງຕໍ່ໄປນີ້: ຄວາມຕ້ອງການອຸດສາຫະກໍາຫຼືລັກສະນະສ່ວນບຸກຄົນຂອງວິສາຫະກິດ; ຈໍານວນທີ່ສໍາຄັນຂອງຫນ້າທີ່ໃຫມ່ຫຼືການແກ້ໄຂເລັກນ້ອຍ. ການ​ແກ້​ໄຂ​ເລັກ​ນ້ອຍ​ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສ່ວນ​ບຸກ​ຄົນ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ໂດຍ​ບໍ່​ມີ​ການ frills ໃດ​. ການຮ້ອງຂໍສ່ວນບຸກຄົນຖືກຄິດໄລ່ແລະປະຕິບັດສໍາລັບລູກຄ້າສະເພາະເປັນສ່ວນຫນຶ່ງຂອງການເຮັດວຽກໂຄງການກັບລາວ.

ຖ້ານີ້ບໍ່ແມ່ນຄວາມຕ້ອງການອຸດສາຫະກໍາຂະຫນາດໃຫຍ່ແລະປະລິມານການທໍາງານແມ່ນຂະຫນາດໃຫຍ່, ຫຼັງຈາກນັ້ນ, ການຕັດສິນໃຈອາດຈະຖືກສ້າງຂື້ນເພື່ອພັດທະນາໂມດູນແຍກຕ່າງຫາກໃຫມ່ທີ່ຈະຂາຍນອກເຫນືອການທໍາງານຕົ້ນຕໍ. ຖ້າການຮ້ອງຂໍດັ່ງກ່າວໄດ້ຮັບຈາກລູກຄ້າ, ພວກເຮົາສາມາດກວມເອົາຄ່າໃຊ້ຈ່າຍໃນການພັດທະນາໂມດູນ, ໃຫ້ລູກຄ້າມີໂມດູນໂດຍບໍ່ເສຍຄ່າຫຼືມີການຈ່າຍເງິນບາງສ່ວນ, ແລະວາງໂມດູນເອງເພື່ອຂາຍ. ໃນສະຖານະການດັ່ງກ່າວ, ລູກຄ້າໃຊ້ເວລາສ່ວນຫນຶ່ງຂອງການໂຫຼດຂອງວິທີການແລະສໍາຄັນດໍາເນີນການທົດລອງຂອງໂມດູນດ້ວຍຕົນເອງ.

ຖ້າຫາກວ່ານີ້ແມ່ນຄວາມຕ້ອງການອຸດສາຫະກໍາອັນໃຫຍ່ຫຼວງ, ຫຼັງຈາກນັ້ນ, ການຕັດສິນໃຈອາດຈະຖືກເຮັດໃຫ້ລວມເອົາຫນ້າທີ່ໃຫມ່ໃນຜະລິດຕະພັນພື້ນຖານ. ຄ່າ​ໃຊ້​ຈ່າຍ​ໃນ​ກໍ​ລະ​ນີ​ນີ້​ຕົກ​ຢູ່​ກັບ​ພວກ​ເຮົາ​ທັງ​ຫມົດ​, ແລະ​ການ​ທໍາ​ງານ​ໃຫມ່​ປະ​ກົດ​ວ່າ​ໃນ​ສະ​ບັບ​ປະ​ຈຸ​ບັນ​ຂອງ​ໂຄງ​ການ​.
ລູກຄ້າເກົ່າໄດ້ຮັບການອັບເດດ.

ມັນອາດຈະເປັນວ່າລູກຄ້າຈໍານວນຫນຶ່ງມີຄວາມຕ້ອງການທີ່ຄ້າຍຄືກັນ, ແຕ່ມັນບໍ່ມີຄຸນສົມບັດສໍາລັບຜະລິດຕະພັນມະຫາຊົນ. ໃນກໍລະນີນີ້, ພວກເຮົາສາມາດສົ່ງຂໍ້ມູນສະເພາະກັບລູກຄ້າເຫຼົ່ານີ້ແລະສະເຫນີໃຫ້ແບ່ງປັນຄ່າໃຊ້ຈ່າຍໃນການພັດທະນາລະຫວ່າງພວກເຂົາ. ໃນທີ່ສຸດ, ທຸກຄົນຊະນະ: ລູກຄ້າໄດ້ຮັບການທໍາງານດ້ວຍຄ່າໃຊ້ຈ່າຍຕ່ໍາ, ພວກເຮົາເສີມສ້າງຜະລິດຕະພັນ, ແລະຫຼັງຈາກເວລາໃດຫນຶ່ງ, ຜູ້ເຂົ້າຮ່ວມຕະຫຼາດອື່ນໆຍັງສາມາດໄດ້ຮັບຫນ້າທີ່ສໍາລັບການນໍາໃຊ້ຂອງພວກເຂົາ.

DevOps

ການພັດທະນາກະກຽມສອງສະບັບທີ່ສໍາຄັນຕໍ່ປີ. ​ໃນ​ແຕ່ລະ​ສະບັບ​ແມ່ນ​ໄດ້​ສະຫງວນ​ເວລາ​ໃຫ້​ແກ່​ການ​ປະຕິບັດ 5 ວຽກ​ງານ​ທີ່​ໄດ້​ຮັບ​ຈາກ​ສະພາ​ເຕັກນິກ. ດັ່ງນັ້ນ, ໃນທ່າມກາງການປົກກະຕິ, ພວກເຮົາບໍ່ເຄີຍລືມກ່ຽວກັບການພັດທະນາຜະລິດຕະພັນ.

ແຕ່ລະການປ່ອຍແມ່ນຜ່ານຊຸດການທົດສອບທີ່ເຫມາະສົມແລະເອກະສານ. ຕໍ່ໄປ, ການປ່ອຍນີ້ໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນສະພາບແວດລ້ອມການທົດສອບຂອງລູກຄ້າທີ່ສອດຄ້ອງກັນ, ຜູ້ທີ່, ກວດເບິ່ງທຸກຢ່າງຢ່າງລະອຽດແລະພຽງແຕ່ຫຼັງຈາກນັ້ນການປ່ອຍໄດ້ຖືກໂອນໄປສູ່ການຜະລິດ.

ນອກເຫນືອໄປຈາກລະບົບການປ່ອຍ, ມີຮູບແບບສໍາລັບການແກ້ໄຂ bug ຢ່າງໄວວາເພື່ອໃຫ້ລູກຄ້າບໍ່ຢູ່ກັບຄວາມຜິດພາດສໍາລັບຫົກເດືອນ. ຮູບແບບລະດັບປານກາງນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດຕອບສະຫນອງຕໍ່ເຫດການທີ່ມີຄວາມສໍາຄັນອັນດັບທໍາອິດແລະປະຕິບັດຕາມ SLAs ທີ່ລະບຸໄວ້.

ທັງຫມົດຂ້າງເທິງນີ້ແມ່ນຄວາມຈິງຕົ້ນຕໍສໍາລັບຂະແຫນງການບໍລິສັດແລະການແກ້ໄຂບັນຫາຢູ່ໃນສະຖານທີ່. ສໍາລັບການບໍລິການຄລາວທີ່ແນໃສ່ພາກສ່ວນ SMB, ບໍ່ມີໂອກາດທີ່ກວ້າງຂວາງສໍາລັບລູກຄ້າທີ່ຈະມີສ່ວນຮ່ວມໃນການພັດທະນາຜະລິດຕະພັນ. ຮູບແບບການເຊົ່າ SMB ບໍ່ສົມມຸດວ່ານີ້. ແທນທີ່ຈະມີການຮ້ອງຂໍການປ່ຽນແປງໃນຮູບແບບຂອງຄວາມຕ້ອງການທີ່ຊັດເຈນຈາກຝ່າຍບໍລິສັດ, ໃນທີ່ນີ້ມີພຽງແຕ່ຄໍາຄຶດຄໍາເຫັນແລະຄວາມປາຖະຫນາສໍາລັບການບໍລິການທົ່ວໄປ. ພວກເຮົາພະຍາຍາມຟັງ, ແຕ່ຜະລິດຕະພັນແມ່ນຂະຫນາດໃຫຍ່ແລະຄວາມປາຖະຫນາຂອງລູກຄ້າຫນຶ່ງທີ່ຈະນໍາເອົາສິ່ງທີ່ຄຸ້ນເຄີຍຈາກລະບົບປະຫວັດສາດເກົ່າຂອງພວກເຂົາອາດຈະຂັດແຍ້ງກັບຍຸດທະສາດການພັດທະນາຂອງລະບົບທັງຫມົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com