ທ້າຍອາທິດນີ້ຂ້ອຍເລີ່ມຕົ້ນການສົນທະນາກັບນັກສິລະປິນທ້ອງຖິ່ນຜູ້ທີ່ໄດ້ຊ່ວຍເຫຼືອເຈົ້າຂອງເຈົ້າດ້ວຍການຄຸ້ມຄອງໂປແກຼມເວັບສອງສາມໃບທີ່ເຈົ້າຂອງເຈົ້າເປັນເຈົ້າຂອງ.
ການສົນທະນາໄດ້ຫັນ ໜ້າ ແລະມີການສົນທະນາກ່ຽວກັບການຈ່າຍຄ່າພັດທະນາປະ ຈຳ ອາທິດໂດຍບໍ່ໄດ້ເຫັນຄວາມຄືບ ໜ້າ ໃດໆກັບນັກພັດທະນາທີ່ພວກເຂົາໄດ້ເຮັດວຽກ ນຳ. ດຽວນີ້ນັກພັດທະນາຕ້ອງການຄິດຄ່າບໍລິການໃຫ້ພວກເຂົາອີກຄັ້ງ ໜຶ່ງ ເພື່ອໃຫ້ ສຳ ເລັດໂຄງການພ້ອມທັງຄ່າ ທຳ ນຽມ ບຳ ລຸງຮັກສາປະ ຈຳ ອາທິດເພື່ອໃຫ້ກວມເອົາ ຄຳ ຮ້ອງຂໍອື່ນໆ. ມັນຮ້າຍແຮງກວ່າເກົ່າ.
ນັກພັດທະນາໄດ້ໂອນຊື່ໂດເມນດັ່ງນັ້ນລາວຈຶ່ງສາມາດຈັດການກັບພວກມັນໄດ້. ນັກພັດທະນາຍັງເປັນເຈົ້າພາບໃນໂປແກຼມບັນຊີຖາມຂອງລາວ. ໂດຍຫຍໍ້, ນັກພັດທະນາຕອນນີ້ ກຳ ລັງຖືພວກເຂົາຢູ່ໃນຄວາມເປັນທາດ.
ໂຊກດີທີ່ແມ່ຍິງຂ້ອຍ ກຳ ລັງເຮັດວຽກກັບຄວາມຕ້ອງການດ້ານການບໍລິຫານໃນໄລຍະຜ່ານມາເພື່ອດັດແກ້ບາງເອກະສານ ສຳ ລັບເວັບໄຊທ໌້. ນັກພັດທະນາສາມາດສະ ໜອງ ການເຂົ້າເຖິງທີ່ ຈຳ ກັດຂອງລາວແຕ່ລາວບໍ່ໄດ້ເຮັດ. ລາວ (ຂີ້ກຽດ) ໄດ້ໃຫ້ນາງເຂົ້າສູ່ລະບົບການບໍລິຫານເຂົ້າໃນເວັບໄຊທ໌້. ຄືນນີ້ຂ້ອຍໄດ້ໃຊ້ການເຂົ້າເຖິງນັ້ນເພື່ອ ສຳ ຮອງຂໍ້ມູນທັງ ໝົດ ຂອງລະຫັດ ສຳ ລັບເວບໄຊທ໌. ຂ້າພະເຈົ້າຍັງໄດ້ຄົ້ນຫາໂປຼແກຼມການຄຸ້ມຄອງທີ່ລາວ ກຳ ລັງໃຊ້ແລະ ນຳ ທາງໄປຫາການບໍລິຫານຖານຂໍ້ມູນເຊິ່ງຂ້ອຍສາມາດສົ່ງອອກທັງຂໍ້ມູນຂອງໂປແກຼມແລະໂປແກຼມຕາຕະລາງ. Whew.
ເຈົ້າຂອງ ກຳ ລັງວາງແຜນການຍ້າຍສະຖານທີ່ດັ່ງກ່າວໄປຫາຊື່ໂດເມນ ໃໝ່ ເມື່ອການພັດທະນາໄດ້ ສຳ ເລັດ. ມັນເປັນສິ່ງທີ່ໃຫຍ່ຫຼວງເພາະມັນ ໝາຍ ຄວາມວ່າໂດເມນໃນປະຈຸບັນອາດຈະ ໝົດ ອາຍຸໃນກໍລະນີທີ່ມີການແຍກກັນຢ່າງໂກດແຄ້ນລະຫວ່າງຜູ້ພັດທະນາແລະບໍລິສັດ. ຂ້ອຍເຄີຍເຫັນສິ່ງນີ້ເກີດຂື້ນມາກ່ອນ.
ຄຳ ແນະ ນຳ ບາງຢ່າງຖ້າທ່ານ ກຳ ລັງຈະໄດ້ຮັບທີມງານພັດທະນາດ້ານນອກ:
-
ລົງທະບຽນໂດເມນ
ລົງທະບຽນຊື່ໂດເມນຂອງທ່ານໃນຊື່ບໍລິສັດຂອງທ່ານ. ມັນບໍ່ແມ່ນສິ່ງທີ່ບໍ່ດີທີ່ຈະມີນັກພັດທະນາຂອງທ່ານເປັນຜູ້ຕິດຕໍ່ທາງວິຊາການໃນບັນຊີ, ແຕ່ວ່າ ບໍ່ເຄີຍ ໂອນ ກຳ ມະສິດຂອງໂດເມນໃຫ້ທຸກຄົນທີ່ຢູ່ນອກບໍລິສັດຂອງທ່ານ.
-
ໂຮດສະ ໝັກ ຫລືເວັບໄຊທ໌ຂອງເຈົ້າ
ມັນດີຫຼາຍທີ່ນັກພັດທະນາຂອງທ່ານອາດຈະມີບໍລິສັດໂຮດຕິ້ງແລະສາມາດໂຮດເວັບໄຊທ໌້ຂອງທ່ານໃຫ້ທ່ານ, ແຕ່ຢ່າເຮັດມັນ. ແທນທີ່ຈະ, ຖາມ ຄຳ ແນະ ນຳ ຂອງລາວ ສຳ ລັບບ່ອນທີ່ຈະເປັນເຈົ້າພາບໃນການສະ ໝັກ. ມັນເປັນຄວາມຈິງທີ່ນັກພັດທະນາຮູ້ຈັກກັບໂປແກຼມຄຸ້ມຄອງ, ຮຸ່ນແລະທີ່ຕັ້ງຂອງຊັບພະຍາກອນແລະທີ່ສາມາດຊ່ວຍໃຫ້ຜະລິດຕະພັນຂອງທ່ານ ສຳ ເລັດໄວໆນີ້. ທີ່ເວົ້າວ່າ, ເຖິງແມ່ນວ່າ, ເປັນເຈົ້າຂອງບັນຊີຖາມແລະເພີ່ມນັກພັດທະນາຂອງທ່ານດ້ວຍການເຂົ້າສູ່ລະບົບແລະເຂົ້າເຖິງຕົວເອງ. ວິທີນີ້, ທ່ານສາມາດດຶງປັplugກໄດ້ທຸກຄັ້ງທີ່ທ່ານຕ້ອງການ.
-
ເປັນເຈົ້າຂອງລະຫັດ
ຢ່າຄິດວ່າທ່ານເປັນເຈົ້າຂອງລະຫັດ, ຂຽນໃສ່ເປັນລາຍລັກອັກສອນ. ຖ້າທ່ານບໍ່ຕ້ອງການໃຫ້ນັກພັດທະນາຂອງທ່ານໃຊ້ວິທີແກ້ໄຂທີ່ທ່ານຈ່າຍໃຫ້ລາວເພື່ອພັດທະນາຢູ່ບ່ອນອື່ນ, ທ່ານຕ້ອງຕັດສິນໃຈໃນເວລາສັນຍາ. ຂ້ອຍໄດ້ພັດທະນາວິທີແກ້ໄຂດ້ວຍວິທີນີ້ແຕ່ຂ້ອຍຍັງໄດ້ພັດທະນາພວກມັນຢູ່ບ່ອນທີ່ຂ້ອຍຮັກສາສິດໃນການລະຫັດ. ໃນກໍລະນີສຸດທ້າຍ, ຂ້າພະເຈົ້າໄດ້ເຈລະຈາຄ່າໃຊ້ຈ່າຍໃນການສະ ໝັກ ໃຫ້ຕໍ່າກວ່າເພື່ອໃຫ້ມີແຮງຈູງໃຈໃຫ້ບໍລິສັດໃຫ້ສິດແກ່ຂ້ອຍ. ຖ້າທ່ານບໍ່ສົນໃຈນັກພັດທະນາຂອງທ່ານທີ່ໃຊ້ລະຫັດຂອງທ່ານຢູ່ບ່ອນອື່ນ, ທ່ານກໍ່ບໍ່ຄວນຈ່າຍເງິນໂດລາສູງສຸດ!
-
ໄດ້ຮັບຄວາມຄິດເຫັນທີ່ສອງ!
ມັນບໍ່ເຈັບປວດຄວາມຮູ້ສຶກຂອງຂ້ອຍເມື່ອຄົນອື່ນໆບອກຂ້ອຍວ່າພວກເຂົາ ກຳ ລັງສະ ເໜີ ລາຄາຫຼືປຶກສາກັບຜູ້ຊ່ຽວຊານອື່ນໆ. ໃນຄວາມເປັນຈິງ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ມັນ!
ເສັ້ນທາງລຸ່ມແມ່ນວ່າທ່ານ ກຳ ລັງຈ່າຍເງິນໃຫ້ກັບພອນສະຫວັນຂອງນັກພັດທະນາຂອງທ່ານແຕ່ທ່ານຕ້ອງຮັກສາການຄວບຄຸມແລະຄວາມເປັນເຈົ້າຂອງ ເໜືອ ຄວາມຄິດ. ມັນເປັນຂອງທ່ານ. ມັນແມ່ນທ່ານຜູ້ທີ່ລົງທຶນໃນມັນ, ທ່ານຜູ້ທີ່ສ່ຽງທຸລະກິດແລະ ກຳ ໄລຂອງທ່ານ ສຳ ລັບມັນ ... ແລະມັນແມ່ນທ່ານຜູ້ທີ່ຄວນຮັກສາມັນໄວ້. ນັກພັດທະນາສາມາດຖືກທົດແທນໄດ້ແລະທີ່ບໍ່ຄວນເຮັດໃຫ້ ຄຳ ຮ້ອງສະ ໝັກ ຂອງທ່ານ, ຫຼືຮ້າຍແຮງກວ່າເກົ່າ - ທຸລະກິດຂອງທ່ານ, ມີຄວາມສ່ຽງ.
ຂ້ອຍເປັນຜູ້ພັດທະນາແອັບເວັບ ແລະຂ້ອຍເຫັນດີກັບຈຸດຂອງເຈົ້າສ່ວນໃຫຍ່ (ບາງທີອາດມີທັງໝົດ) ແຕ່ຂ້ອຍຕ້ອງການຄວາມກະຈ່າງແຈ້ງໃນ #3.
ການຂາຍຊໍ້າຊ້ອນຂອງເວັບໄຊ ຫຼືແອັບພລິເຄຊັນທີ່ຂາຍໃຫ້ບໍລິສັດອື່ນ (ຫຼືຄູ່ແຂ່ງທີ່ຮ້າຍໄປກວ່ານັ້ນ) ແມ່ນບໍ່ມີຈັນຍາບັນ ແລະຄວນຈະຖືກກຳນົດໄວ້ສະເໝີວ່າບໍ່ສາມາດຍອມຮັບໄດ້ໃນສັນຍາຂອງເຈົ້າ. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າໄດ້ພັດທະນາວິທີແກ້ໄຂໃຫມ່ໆສໍາລັບບັນຫາທົ່ວໄປໃນຂະນະທີ່ເຮັດວຽກຢູ່ໃນໂຄງການຂອງລູກຄ້າທີ່ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບ biz ໂດຍສະເພາະຂອງເຂົາເຈົ້າແລະບໍ່ໄດ້ເປັນຕົວແທນຂອງສ່ວນທີ່ສໍາຄັນຂອງການແກ້ໄຂໂດຍລວມ.
ຕົວຢ່າງ:
ລູກຄ້າຕ້ອງການລະດັບຫນ້າແລະການຄວບຄຸມລະດັບພາກສະຫນາມທີ່ກ່ຽວຂ້ອງກັບບົດບາດຂອງຜູ້ໃຊ້. ຟັງຊັນ "ອອກຈາກກ່ອງ" ສໍາລັບ ASP.Net ເຮັດການອະນຸຍາດລະດັບໂຟນເດີ. ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ຂະຫຍາຍການອະນຸຍາດພື້ນເມືອງສໍາລັບ .Net ແລະສົ່ງການແກ້ໄຂເປັນສ່ວນຫນຶ່ງຂອງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ໂດຍລວມ.
ຂ້າພະເຈົ້າເຊື່ອວ່າພວກເຂົາມີສິດໄດ້ຮັບ codebase ທັງຫມົດ (ຕາມທີ່ໄດ້ກໍານົດໄວ້ໃນສັນຍາ) ແຕ່ຂ້າພະເຈົ້າຮູ້ສຶກສົມເຫດສົມຜົນໃນການນໍາໃຊ້ວິທີການດຽວກັນແລະ chunks ຂອງລະຫັດເພື່ອເຮັດສໍາເລັດການຂະຫຍາຍນີ້ໃນໂຄງການໃນອະນາຄົດ.
ຮອຍຫ່ຽວອື່ນ:
ຂ້າພະເຈົ້າໄດ້ເຮັດສິ່ງນີ້ໃນຂະນະທີ່ໄດ້ຮັບການກະສິກໍາອອກໂດຍບໍລິສັດທີ່ປຶກສາ. ບໍລິສັດທີ່ປຶກສາມີສິດໃນຄວາມຄິດເຫັນຂອງເຈົ້າທີ່ຈະກັບຄືນໄປບ່ອນແລະສໍາເນົາການແກ້ໄຂນັ້ນ, ການຕະຫຼາດມັນເປັນຂອງຕົນເອງບໍ?
ແທ້ຈິງແລ້ວ,
ຂ້າພະເຈົ້າຄິດວ່າພວກເຮົາຕົກລົງເຫັນດີ. ຈຸດຂອງຂ້ອຍໃນເລື່ອງນີ້ແມ່ນເພື່ອໃຫ້ແນ່ໃຈວ່າເຈົ້າມີລະຫັດແລະສາມາດຍ່າງອອກຈາກປະຕູກັບມັນ. ຖ້າຜູ້ພັດທະນາຂອງເຈົ້າກໍາລັງລວບລວມລະຫັດສໍາລັບທ່ານແລະຍູ້ມັນອອກໄປຫາເວັບໄຊຂອງເຈົ້າ - ເຈົ້າບໍ່ມີລະຫັດ. ຂ້າພະເຈົ້າໄດ້ເຫັນສິ່ງນີ້ເກີດຂຶ້ນກັບທຸກສິ່ງທຸກຢ່າງຈາກຮູບພາບ, Flash, .NET, Java… ສິ່ງໃດກໍຕາມທີ່ຮຽກຮ້ອງໃຫ້ມີໄຟລ໌ແຫຼ່ງແລະໄດ້ຮັບການ outputted.
Doug
ຂ້ອຍເຫັນວ່າເຈົ້າມາຈາກໃສແລະໃນຂະນະທີ່ຂ້ອຍບໍ່ເຫັນດີກັບທຸກສິ່ງທຸກຢ່າງ 100% (ຂ້ອຍມີຂໍ້ຄວນລະວັງ), ບໍລິສັດຄວນຮັກສາເລື່ອງນີ້ຢູ່ໃນໃຈສະເຫມີ.
1. ຢ່າງແທ້ຈິງ. ບໍ່ສາມາດເນັ້ນນີ້ພຽງພໍ. ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກສໍາລັບບໍລິສັດຂະຫນາດນ້ອຍທີ່ເຮັດສິ່ງນີ້ແລະຂ້າພະເຈົ້າຮູ້ສຶກຜິດທີ່ crushing ມີສ່ວນຮ່ວມ. ຂ້ອຍດີໃຈຫຼາຍທີ່ຂ້ອຍສາມາດອອກຈາກບ່ອນນັ້ນໄດ້. ລູກຄ້າຄວນຈະຮັກສາການຄວບຄຸມໂດເມນຂອງເຂົາເຈົ້າຢ່າງແທ້ຈິງ. ຖ້າພວກເຂົາມີຄົນເຂົ້າໃຈພຽງພໍ, ຢ່າໃຫ້ຜູ້ພັດທະນາເຂົ້າເຖິງສິ່ງນີ້. ຖ້າບໍ່, ໃຫ້ແນ່ໃຈວ່າຜູ້ພັດທະນາມີວິທີໃຫ້ທ່ານປ່ຽນຂໍ້ມູນ / ໂອນໂດເມນຜ່ານທາງຕິດຕໍ່ຜູ້ຂາຍໃນບາງປະເພດຢ່າງຫນ້ອຍ.
2. ຂ້ອຍເຫັນດີບາງສ່ວນກັບເລື່ອງນີ້ ແຕ່ຫຼັງຈາກນັ້ນມັນຂຶ້ນກັບສະຖານະການ. ຖ້າທ່ານກໍາລັງໃຊ້ແອັບຯ PHP ງ່າຍໆແລະຕ້ອງການໂຮດຕິ້ງທີ່ມີຄ່າໃຊ້ຈ່າຍຕ່ໍາ, ໂດຍວິທີການທັງຫມົດ, ເອົາບັນຊີ LunarPages ຫຼື DreamHost ຫຼືບາງສິ່ງບາງຢ່າງແລະຖິ້ມມັນຢູ່ທີ່ນັ້ນ. ໃຫ້ຜູ້ພັດທະນາເຂົ້າເຖິງ. ຢ່າງໃດກໍຕາມ, ການແບ່ງປັນ hosting ລາຄາຖືກແນ່ນອນມີຂໍ້ບົກຜ່ອງຂອງມັນ ... ໂດຍສະເພາະສໍາລັບສິ່ງທີ່ໃຫຍ່ກວ່າ. ແຕ່ຖ້າທ່ານໃຫຍ່ພໍທີ່ຈະກັງວົນວ່າທ່ານຄວນມີພະນັກງານດ້ານວິຊາການທີ່ສາມາດຈັດການກັບມັນໄດ້. ຫຼາຍໆຢ່າງແມ່ນເຫັນໄດ້ຊັດເຈນກ່ຽວກັບຄວາມໄວ້ວາງໃຈ. ໃຫ້ແນ່ໃຈວ່າເປັນ hell ເອົາບາງສິ່ງບາງຢ່າງໃນສັນຍາຖ້າຫາກວ່າທ່ານສາມາດກ່ຽວກັບປະເພດນີ້ (ຂໍ້ຈໍາກັດແລະອື່ນໆ). ການເປັນເຈົ້າພາບຂອງພາກສ່ວນທີສາມແມ່ນດີຫຼາຍຖ້າຜູ້ພັດທະນາບໍ່ຈໍາເປັນຕ້ອງເຮັດຫຍັງທີ່ແປກປະຫຼາດ. ຂ້າພະເຈົ້າຍອມຮັບວ່າຂ້າພະເຈົ້າໄດ້ຖືກຈີກເພາະວ່າມັນເປັນສະຖານະການ. ມັນຍັງຂຶ້ນກັບຂະຫນາດຂອງສະຖານທີ່, ອາເລຂອງເຕັກໂນໂລຢີທີ່ໃຊ້. ຖ້າມັນຈະໃຫຍ່, ພິຈາລະນາຈ້າງຄົນກ່ຽວກັບພະນັກງານ. ບໍ່ແມ່ນທາງເລືອກສະເໝີໄປ, ແຕ່ປອດໄພກວ່າສຳລັບເລື່ອງໃຫຍ່.
3. ນີ້ແມ່ນສິ່ງທີ່ບໍລິສັດໃນອະດີດຂອງຂ້ອຍໄດ້ເຮັດ. ເຈົ້າສາມາດອອກໄປໄດ້, ພວກເຂົາຈະໃຫ້ HTML, ຮູບພາບຕ່າງໆແກ່ເຈົ້າ. ແຕ່ບໍ່ມີລະຫັດ. ລະຫັດແມ່ນການບໍລິການເຊົ່າໂດຍພື້ນຖານ. ວ່າໄດ້ຖືກກ່າວວ່າ, ມີການເປັນເຈົ້າຂອງແລະເປັນເຈົ້າຂອງ. ຂ້ອຍເຄີຍເຮັດການຂາຍແບບບໍ່ສະເພາະ. ໂດຍພື້ນຖານແລ້ວ, ຂ້ອຍຈໍາເປັນຕ້ອງສາມາດນໍາໃຊ້ອົງປະກອບຂອງຂ້ອຍຄືນໃຫມ່. ຂ້າພະເຈົ້າບໍ່ມີບັນຫາທີ່ລູກຄ້າເປັນເຈົ້າຂອງມັນ, ເຮັດສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການກັບມັນແລະມີຄົນອື່ນເຮັດວຽກກ່ຽວກັບມັນຕາມເສັ້ນທາງ… ແຕ່ຂ້າພະເຈົ້າຈະບໍ່ຈໍານອງດ້ວຍຕົນເອງແລະມີການ reinvent ລໍ້ທຸກຄັ້ງ.
4. ສະເໝີ. ສະເໝີ. ສະເໝີ.
ໂພສງາມ... ເຮັດໄດ້ດີ ເຖິງແມ່ນວ່າຂ້ອຍບໍ່ເຫັນດີກັບໜຶ່ງລາຍການ (#2):
"ມັນດີຫຼາຍທີ່ນັກພັດທະນາຂອງເຈົ້າອາດຈະມີບໍລິສັດໂຮດຕິ້ງແລະສາມາດເປັນເຈົ້າພາບເວັບໄຊທ໌ຂອງທ່ານສໍາລັບທ່ານ, ແຕ່ຢ່າເຮັດມັນ."
ເຖິງແມ່ນວ່າຂ້ອຍເຂົ້າໃຈເຫດຜົນທາງຫລັງຂອງເລື່ອງນີ້, ມັນສາມາດເປັນຜົນຕອບແທນໃນບາງກໍລະນີທີ່ຈະສັ່ງໃຫ້ໂຄງການຂອງເຈົ້າເປັນເຈົ້າພາບບ່ອນອື່ນ. ຖ້າບໍລິສັດທີ່ພັດທະນາເວັບໄຊທ໌ຫຼືແອັບຯຂອງເຈົ້າມີເວທີໂຮດຕິ້ງທີ່ພວກເຂົາມັກໃຊ້, ໂອກາດທີ່ມັນຈະມີປະສິດທິພາບແລະຜົນດີສໍາລັບພວກເຂົາທີ່ຈະໃຊ້ມັນ.
ນອກຈາກນັ້ນ, ຈາກທັດສະນະທາງ philosophical, ຖ້າທ່ານປະຕິເສດທີ່ຈະນໍາໃຊ້ເວທີການໂຮດຕິ້ງຂອງຜູ້ພັດທະນາຂອງທ່ານເພາະວ່າທ່ານບໍ່ຕ້ອງການ "ຖືກຈັບເປັນຕົວປະກັນ", ນີ້ຈະເຮັດໃຫ້ເກີດຄວາມບໍ່ໄວ້ວາງໃຈຕັ້ງແຕ່ເລີ່ມຕົ້ນ. ຖ້າທ່ານບໍ່ໄວ້ວາງໃຈນັກພັດທະນາຂອງທ່ານພຽງພໍທີ່ຈະເປັນເຈົ້າພາບກັບພວກເຂົາ, ທ່ານຕ້ອງການເຮັດວຽກກັບພວກເຂົາໃນຄັ້ງທໍາອິດບໍ?
ຂ້ອຍຮູ້ວ່າມີເລື່ອງທີ່ຫນ້າຢ້ານຫຼາຍກ່ຽວກັບສະຖານະການແບບນີ້, ແຕ່ໂດຍທົ່ວໄປແລ້ວຂ້ອຍຈະແນະນໍາໃຫ້ເຈົ້າສຸມໃສ່ການຊອກຫານັກພັດທະນາທີ່ທ່ານໄວ້ວາງໃຈ. ທ່ານສາມາດນໍາໃຊ້ hosting ຂອງຜູ້ພັດທະນາຂອງທ່ານແລະຍັງປົກປ້ອງຕົວທ່ານເອງໂດຍການຮ້ອງຂໍການເຂົ້າເຖິງການບໍລິຫານແລະເຮັດການສໍາຮອງຂໍ້ມູນຂອງທ່ານເອງ.
ອີກເທື່ອຫນຶ່ງ, ຂໍ້ຄວາມທີ່ດີແລະຂໍ້ມູນທີ່ເປັນປະໂຫຍດຫຼາຍ.
ຂໍຂອບໃຈ!
Michael Reynolds
ສະບາຍດີ Michael,
ມັນອາດຈະເບິ່ງຄືວ່າເປັນບັນຫາຄວາມໄວ້ວາງໃຈ ແຕ່ຂ້ອຍບໍ່ຄິດວ່າມັນເປັນ – ມັນເປັນເລື່ອງການຄວບຄຸມ ແລະຄວາມຮັບຜິດຊອບຢ່າງແທ້ຈິງ. ຖ້າທ່ານກໍາລັງຈະລົງທຶນຢ່າງຫຼວງຫຼາຍໃນການພັດທະນາເວັບໄຊທ໌ຂອງເຈົ້າ, ເຈົ້າຕ້ອງແນ່ໃຈວ່າເຈົ້າສາມາດຄວບຄຸມສະພາບແວດລ້ອມຂອງມັນໄດ້.
ສິ່ງທີ່ເກີດຂື້ນໃນທຸລະກິດທີ່ທໍາລາຍຄວາມສໍາພັນແລະພວກເຂົາບໍ່ຈໍາເປັນຕ້ອງເປັນທາງລົບ. ບາງທີຜູ້ພັດທະນາ / ບໍລິສັດຂອງທ່ານໄດ້ຮັບລູກຄ້າຂະຫນາດໃຫຍ່ແລະບໍ່ສາມາດໃຊ້ເວລາໃຫ້ທ່ານໄດ້. ບາງທີພວກເຂົາປ່ຽນຈຸດປະສົງທາງທຸລະກິດ. ບາງຄັ້ງບໍລິສັດໂຮດຕິ້ງຂອງພວກເຂົາສາມາດມີບັນຫາ.
ຂ້ອຍຮຽກຮ້ອງໃຫ້ເຈົ້າຄວບຄຸມ ແລະຮັບຜິດຊອບການເປັນເຈົ້າພາບຂອງເຈົ້າ ເພື່ອໃຫ້ເຈົ້າສາມາດຂຶ້ນກັບນັກພັດທະນາຂອງເຈົ້າສຳລັບສິ່ງທີ່ລາວເກັ່ງໄດ້ - ພັດທະນາ!
ຂ້າພະເຈົ້າຮູ້ຈັກການຊຸກຍູ້ກັບຄືນໄປບ່ອນ, Michael.
ຂ້ອຍຍັງເປັນນັກພັດທະນາແອັບຯເວັບ, ແລະຂ້ອຍຄິດວ່າເຈົ້າໄດ້ຕີເລັບໃສ່ຫົວ. ຄວາມຄິດບາງຢ່າງ:
ຂ້າພະເຈົ້າຄິດວ່າທຸກຄົນສ່ວນໃຫຍ່ຈະເຫັນດີ (ແລະໄດ້ອີງໃສ່ຄໍາເຫັນຂ້າງລຸ່ມນີ້) #1 ແມ່ນຢ່າງແທ້ຈິງ. ບໍ່ເຄີຍ, ເຄີຍເຮັດມັນ. ເຄີຍ. ພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມ.
ຂ້ອຍມີຄວາມແຕກຕ່າງອັນດັບ 2 ຫຼາຍກວ່າບາງນັກພັດທະນາອື່ນໆຂອງຂ້ອຍ: ພວກເຮົາປະຕິເສດການເປັນເຈົ້າພາບຜະລິດຕະພັນສຸດທ້າຍສໍາລັບລູກຄ້າຂອງພວກເຮົາ (ແນ່ນອນ, ພວກເຮົາເປັນເຈົ້າພາບເຊີຟເວີທົດສອບສໍາລັບລູກຄ້າເພື່ອທົດສອບການຜະລິດຜະລິດຕະພັນໃນລະຫວ່າງການພັດທະນາ). ພວກເຮົາຍິນດີທີ່ຈະຊ່ວຍໃຫ້ລູກຄ້າສາມາດຕັ້ງຄ່າເພື່ອເປັນເຈົ້າພາບມັນເອງ ຫຼືຊອກຫາຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງ. ພວກເຮົາພຽງແຕ່ບໍ່ຕ້ອງການທີ່ຈະເຂົ້າໄປໃນທຸລະກິດຂອງການເປັນເຈົ້າພາບ. ຖ້ານັ້ນຫມາຍເຖິງການຫັນຫນ້າໄປ, ດັ່ງນັ້ນມັນ. ມີຫຼາຍບໍລິສັດໂຮດຕິ້ງ ຫຼືບໍລິສັດພື້ນຖານໂຄງລ່າງທີ່ດີຫຼາຍຢູ່ທີ່ນັ້ນກ່ວາສາມາດໃຫ້ບໍລິການນີ້ໃນລາຄາທີ່ຖືກກວ່າຫຼາຍ. ພວກເຮົາຊຸກຍູ້ໃຫ້ມີການເຄື່ອນທີ່ຂອງວຽກງານຂອງພວກເຮົາ, ແລະຈະເຮັດທຸກສິ່ງທີ່ພວກເຮົາສາມາດເຮັດໄດ້ເພື່ອຊ່ວຍໃຫ້ມັນເປັນເຈົ້າພາບ, ເຖິງແມ່ນວ່າລູກຄ້າຈະປ່ຽນຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງມາຫຼາຍປີ.
ສໍາລັບ #3, ລູກຄ້າຂອງພວກເຮົາໄດ້ຮັບລະຫັດແຫຼ່ງທັງຫມົດຂອງຜະລິດຕະພັນສຸດທ້າຍດ້ວຍຄໍາເຕືອນຫນຶ່ງ: ສໍາລັບຜະລິດຕະພັນພາກສ່ວນທີສາມທີ່ຖືກນໍາໃຊ້ໃນການແກ້ໄຂ (ເຊັ່ນ: ການຄວບຄຸມເວັບໄຊຕ໌ຈາກ Telerik ຫຼືອົງປະກອບຫນຶ່ງ), ພວກເຮົາສາມາດໃຫ້ລູກຄ້າໄດ້ລວບລວມ dll ສໍາລັບ. ການຄວບຄຸມພາກສ່ວນທີສາມ (ເວົ້າວ່າຕາຂ່າຍໄຟຟ້າ). ຂໍ້ຕົກລົງການອະນຸຍາດຂອງພວກເຮົາກັບບໍລິສັດພາກສ່ວນທີສາມເຫຼົ່ານັ້ນ (ທີ່ພວກເຮົາໃຫ້ລູກຄ້າ) ຫ້າມພວກເຮົາຈາກການແຈກຢາຍລະຫັດແຫຼ່ງສໍາລັບປະເພດການຄວບຄຸມເຫຼົ່ານັ້ນ, ເພາະວ່າມັນເປັນຊັບສິນທາງປັນຍາຂອງພາກສ່ວນທີສາມ, ບໍ່ແມ່ນຂອງພວກເຮົາ. ການນໍາໃຊ້ປະເພດຜະລິດຕະພັນເຫຼົ່ານີ້ປະຫຍັດເວລາໃນການພັດທະນາສໍາລັບລູກຄ້າແລະມີລາຄາຖືກກວ່າການກໍ່ສ້າງຫນ້າທີ່ດຽວກັນຈາກ scratch. ພວກເຮົາມີຄວາມມຸ່ງຫວັງກ່ຽວກັບນະໂຍບາຍນີ້ກ່ອນທີ່ຈະເຮັດວຽກໃດໆ. ແນ່ນອນ, ຖ້າລູກຄ້າຕ້ອງການຈ່າຍເງິນສໍາລັບການພັດທະນາການຄວບຄຸມທີ່ກໍາຫນົດເອງ (ແທນທີ່ຈະໃຊ້ຜະລິດຕະພັນທີ່ສ້າງຂຶ້ນກ່ອນຈາກພາກສ່ວນທີສາມ) ພວກເຮົາໃຫ້ລະຫັດແຫຼ່ງສໍາລັບການຄວບຄຸມທີ່ກໍາຫນົດເອງນັ້ນພ້ອມກັບສິ່ງອື່ນ.
ເມື່ອເວົ້າເຖິງການໃຊ້ລະຫັດຄືນໃຫມ່, ພວກເຮົາມີຄວາມມຸ່ງຫວັງກ່ຽວກັບຄວາມຈິງທີ່ວ່າພວກເຮົາອາດຈະໃຊ້ບາງສ່ວນຂອງລະຫັດຄືນໃຫມ່ເວັ້ນເສຍແຕ່ວ່າມັນໄດ້ຖືກພັດທະນາຢ່າງຈະແຈ້ງສະເພາະສໍາລັບການນໍາໃຊ້ຂອງລູກຄ້າ (ເວົ້າວ່າສໍາລັບຂະບວນການທຸລະກິດທີ່ເປັນເຈົ້າຂອງ) ກ່ອນທີ່ຈະເຮັດວຽກໃດໆ. ຖ້າລູກຄ້າຕ້ອງການມີລະຫັດສະເພາະທີ່ພັດທະນາແນ່ນອນ, ມັນມີຢູ່ກັບພວກເຂົາ.
ດັ່ງທີ່ຄົນອື່ນເວົ້າ, #4 ແມ່ນແນະນໍາສະເຫມີ. ສະເໝີ!
Regards,
ທິມໜຸ່ມ