ການຈັດຕັ້ງຂະບວນການເຮັດວຽກໃນທີມງານກ່ຽວກັບໂຄງການ IT

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

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

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

ໃນເວລາຫນຶ່ງ, ຂ້າພະເຈົ້າພຽງແຕ່ໄດ້ຮັບໂຄງການດັ່ງກ່າວ, ບ່ອນທີ່ມີທັງຫມົດເຫຼົ່ານີ້ delights.

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

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

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

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

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

ຂະບວນການເຮັດວຽກຂອງທີມງານກ່ຽວກັບໂຄງການ "ໂຄງການທີ່ຂ້ອຍມັກ"

a) ໃນ​ຂະ​ບວນ​ການ​ທີມ​ງານ (ລະ​ຫວ່າງ​ຜູ້​ພັດ​ທະ​ນາ​)

• ວຽກງານທັງໝົດແມ່ນສ້າງຢູ່ໃນລະບົບ Jira
• ແຕ່ລະວຽກງານຄວນໄດ້ຮັບການອະທິບາຍຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, ແລະປະຕິບັດຢ່າງເຂັ້ມງວດຫນຶ່ງການປະຕິບັດ.
• ລັກສະນະໃດກໍ່ຕາມ, ຖ້າມັນມີຄວາມຊັບຊ້ອນພຽງພໍ, ຖືກແບ່ງອອກເປັນວຽກງານຂະຫນາດນ້ອຍຫຼາຍ
• ທີມງານເຮັດວຽກກ່ຽວກັບລັກສະນະເປັນວຽກງານດຽວ. ທໍາອິດ, ພວກເຮົາເຮັດລັກສະນະຫນຶ່ງຮ່ວມກັນ, ໃຫ້ມັນສໍາລັບການທົດສອບ, ຫຼັງຈາກນັ້ນເອົາອັນຕໍ່ໄປ.
• ແຕ່ລະໜ້າວຽກຖືກຕິດສະຫຼາກສຳລັບ backend ຫຼື frontend
• ມີປະເພດຂອງວຽກງານແລະແມງໄມ້. ທ່ານຈໍາເປັນຕ້ອງລະບຸພວກມັນຢ່າງຖືກຕ້ອງ.
• ຫຼັງຈາກວຽກງານສໍາເລັດແລ້ວ, ມັນຖືກໂອນໄປຫາສະຖານະການທົບທວນລະຫັດ (ຄໍາຮ້ອງຂໍດຶງແມ່ນສ້າງສໍາລັບເພື່ອນຮ່ວມງານຂອງຕົນ)
• ຜູ້ທີ່ສໍາເລັດວຽກງານທັນທີຕິດຕາມເວລາຂອງລາວສໍາລັບວຽກງານນີ້
• ຫຼັງຈາກການກວດສອບລະຫັດ, PR ໄດ້ຖືກອະນຸມັດແລະຫຼັງຈາກນັ້ນ, ຜູ້ທີ່ປະຕິບັດວຽກງານນີ້ຢ່າງເປັນເອກະລາດລວມມັນເຂົ້າໄປໃນສາຂາຕົ້ນສະບັບ, ຫຼັງຈາກນັ້ນມັນປ່ຽນສະຖານະຂອງຕົນເພື່ອກຽມພ້ອມສໍາລັບການນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍຂອງ dev.
• ວຽກງານທັງຫມົດທີ່ພ້ອມທີ່ຈະຖືກນໍາໄປໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍຂອງ dev ໄດ້ຖືກນໍາໄປໃຊ້ໂດຍຫົວຫນ້າທີມ (ພື້ນທີ່ຄວາມຮັບຜິດຊອບຂອງລາວ), ບາງຄັ້ງສະມາຊິກໃນທີມ, ຖ້າບາງສິ່ງບາງຢ່າງຮີບດ່ວນ. ຫຼັງ​ຈາກ​ການ​ນໍາ​ໃຊ້​, ວຽກ​ງານ​ທັງ​ຫມົດ​ຈາກ​ການ​ກຽມ​ພ້ອມ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ກັບ dev ແມ່ນ​ໄດ້​ຍົກ​ຍ້າຍ​ກັບ​ສະ​ຖາ​ນະ​ພາບ - ພ້ອມ​ສໍາ​ລັບ​ການ​ທົດ​ສອບ​ໃນ dev
• ວຽກງານທັງຫມົດແມ່ນການທົດສອບໂດຍລູກຄ້າ
• ເມື່ອລູກຄ້າໄດ້ທົດສອບວຽກງານໃນ dev, ລາວໂອນມັນໄປສູ່ສະຖານະທີ່ກຽມພ້ອມສໍາລັບການນໍາໃຊ້ໃນການຜະລິດ.
• ສໍາລັບການນໍາໄປໃຊ້ໃນການຜະລິດ, ພວກເຮົາມີສາຂາແຍກຕ່າງຫາກບ່ອນທີ່ພວກເຮົາລວມແມ່ບົດກ່ອນການປະຕິບັດ
• ຖ້າໃນລະຫວ່າງການທົດສອບລູກຄ້າພົບຂໍ້ບົກພ່ອງ, ຫຼັງຈາກນັ້ນລາວຈະສົ່ງຄືນວຽກງານສໍາລັບການແກ້ໄຂ, ກໍານົດສະຖານະພາບຂອງມັນກັບຄືນສໍາລັບການແກ້ໄຂ. ນີ້ແມ່ນວິທີທີ່ພວກເຮົາແຍກວຽກງານໃຫມ່ຈາກສິ່ງທີ່ບໍ່ໄດ້ທົດສອບ.
• ດັ່ງນັ້ນ, ວຽກງານທັງໝົດຈຶ່ງໄປຈາກການສ້າງຈົນສຳເລັດ: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (ກັບຄືນຫາ dev) → Ready deploy to prod → QA on prod → Done
• ນັກພັດທະນາແຕ່ລະຄົນທົດສອບລະຫັດຂອງລາວຢ່າງເປັນເອກະລາດ, ລວມທັງເປັນຜູ້ໃຊ້ຂອງເວັບໄຊທ໌. ມັນບໍ່ໄດ້ຖືກອະນຸຍາດໃຫ້ລວມສາຂາກັບສາຂາຕົ້ນຕໍ, ເວັ້ນເສຍແຕ່ວ່າມັນເປັນທີ່ຮູ້ຈັກຢ່າງແນ່ນອນວ່າລະຫັດເຮັດວຽກ.
• ທຸກໆວຽກງານມີບູລິມະສິດ. ບູລິມະສິດແມ່ນຖືກກໍານົດໂດຍລູກຄ້າຫຼືຫົວຫນ້າທີມ.
• ນັກພັດທະນາເຮັດຫນ້າທີ່ບູລິມະສິດກ່ອນ.
• ນັກພັດທະນາສາມາດມອບຫມາຍວຽກງານໃຫ້ກັນແລະກັນຖ້າພົບຂໍ້ບົກພ່ອງທີ່ແຕກຕ່າງກັນໃນລະບົບຫຼືວຽກງານຫນຶ່ງປະກອບດ້ວຍການເຮັດວຽກຂອງຜູ້ຊ່ຽວຊານຫລາຍຄົນ.
• ວຽກງານທັງຫມົດທີ່ລູກຄ້າສ້າງແມ່ນຖືກສົ່ງໄປຫາຫົວຫນ້າທີມ, ຜູ້ທີ່ປະເມີນພວກເຂົາແລະຂໍໃຫ້ລູກຄ້າເຮັດສໍາເລັດພວກເຂົາຫຼືມອບໃຫ້ພວກເຂົາຫນຶ່ງໃນສະມາຊິກທີມ.
• ວຽກງານທັງໝົດທີ່ພ້ອມທີ່ຈະຖືກນຳໃຊ້ກັບ dev ຫຼື prod ຍັງໄປຫາຫົວໜ້າທີມ, ຜູ້ທີ່ກຳນົດຢ່າງເປັນອິດສະຫຼະໃນເວລາ ແລະ ວິທີການນຳໃຊ້. ຫຼັງຈາກການປະຕິບັດແຕ່ລະຄັ້ງ, ຫົວຫນ້າທີມ (ຫຼືສະມາຊິກທີມ) ຕ້ອງແຈ້ງໃຫ້ລູກຄ້າຮູ້ກ່ຽວກັບເລື່ອງນີ້. ແລະຍັງປ່ຽນສະຖານະສໍາລັບວຽກງານເພື່ອກຽມພ້ອມສໍາລັບການທົດສອບໃນ dev / prod.
• ທຸກໆມື້ໃນເວລາດຽວກັນ (ພວກເຮົາມີມັນຢູ່ທີ່ 12.00) ພວກເຮົາຈັດການຊຸມນຸມລະຫວ່າງສະມາຊິກທີມງານທັງຫມົດ.
• ທຸກຄົນຢູ່ໃນການຊຸມນຸມລາຍງານ, ລວມທັງຫົວຫນ້າທີມງານ, ສິ່ງທີ່ລາວໄດ້ເຮັດໃນມື້ວານນີ້, ສິ່ງທີ່ລາວວາງແຜນທີ່ຈະເຮັດໃນມື້ນີ້. ສິ່ງທີ່ບໍ່ເຮັດວຽກແລະເປັນຫຍັງ. ດັ່ງນັ້ນ, ທີມງານທັງຫມົດແມ່ນຮູ້ວ່າໃຜກໍາລັງເຮັດຫຍັງແລະຢູ່ໃນຂັ້ນຕອນໃດຂອງໂຄງການ. ນີ້ເຮັດໃຫ້ພວກເຮົາມີໂອກາດທີ່ຈະຄາດຄະເນແລະປັບຕົວ, ຖ້າຈໍາເປັນ, ການຄາດຄະເນແລະກໍານົດເວລາຂອງພວກເຮົາ.
• ໃນກອງປະຊຸມ, ຫົວຫນ້າທີມຍັງປະກາດການປ່ຽນແປງທັງຫມົດຂອງໂຄງການແລະລະດັບຂອງແມງໄມ້ໃນປະຈຸບັນທີ່ລູກຄ້າບໍ່ພົບ. ແມງໄມ້ທັງໝົດຖືກຈັດຮຽງອອກ ແລະມອບໝາຍໃຫ້ສະມາຊິກທີມແຕ່ລະຄົນເພື່ອແກ້ໄຂພວກມັນ.
• ໃນກອງປະຊຸມ, ຫົວຫນ້າທີມງານມອບຫມາຍວຽກງານສໍາລັບແຕ່ລະຄົນ, ຄໍານຶງເຖິງວຽກງານໃນປະຈຸບັນຂອງນັກພັດທະນາ, ລະດັບການຝຶກອົບຮົມວິຊາຊີບຂອງເຂົາເຈົ້າ, ແລະຍັງຄໍານຶງເຖິງຄວາມໃກ້ຊິດຂອງວຽກງານສະເພາະໃດຫນຶ່ງກັບສິ່ງທີ່ນັກພັດທະນາກໍາລັງເຮັດ.
• ໃນກອງປະຊຸມ, ຫົວຫນ້າທີມພັດທະນາຍຸດທະສາດທົ່ວໄປສໍາລັບຖາປັດຕະຍະແລະເຫດຜົນທາງທຸລະກິດ. ຫຼັງຈາກນັ້ນ, ທີມງານທັງຫມົດປຶກສາຫາລືກ່ຽວກັບເລື່ອງນີ້ແລະຕັດສິນໃຈວ່າຈະປັບຕົວຫຼືຮັບຮອງເອົາຍຸດທະສາດນີ້.
• ນັກພັດທະນາແຕ່ລະຄົນຂຽນລະຫັດແລະສ້າງ algorithms ເປັນເອກະລາດພາຍໃນສະຖາປັດຕະຍະກໍາດຽວແລະເຫດຜົນທາງທຸລະກິດ. ທຸກໆຄົນສາມາດສະແດງວິໄສທັດຂອງພວກເຂົາໃນການປະຕິບັດ, ແຕ່ບໍ່ມີໃຜບັງຄັບໃຫ້ຜູ້ໃດເຮັດມັນດ້ວຍວິທີນີ້ແລະບໍ່ແມ່ນຢ່າງອື່ນ. ທຸກໆການຕັດສິນໃຈແມ່ນຖືກຕ້ອງ. ຖ້າມີການແກ້ໄຂທີ່ດີກວ່າ, ແຕ່ໃນປັດຈຸບັນບໍ່ມີເວລາສໍາລັບມັນ, ຫຼັງຈາກນັ້ນ, ວຽກງານທີ່ຖືກສ້າງຂື້ນໃນໄຂມັນ, ສໍາລັບການ refactoring ໃນອະນາຄົດຂອງບາງສ່ວນຂອງລະຫັດ.
• ເມື່ອຜູ້ພັດທະນາປະຕິບັດວຽກງານ, ລາວຍ້າຍມັນໄປສູ່ສະຖານະການພັດທະນາ. ການສື່ສານທັງຫມົດກ່ຽວກັບການຊີ້ແຈງຂອງວຽກງານກັບລູກຄ້າຕົກຢູ່ໃນບ່າຂອງຜູ້ພັດທະນາ. ຄໍາຖາມດ້ານວິຊາການສາມາດຖືກຖາມກັບຫົວຫນ້າທີມຫຼືເພື່ອນຮ່ວມງານ.
• ຖ້ານັກພັດທະນາບໍ່ເຂົ້າໃຈຄວາມສໍາຄັນຂອງວຽກງານ, ແລະລູກຄ້າບໍ່ສາມາດອະທິບາຍມັນຢ່າງມີສະຕິ, ຫຼັງຈາກນັ້ນລາວດໍາເນີນການຕໍ່ໄປ. ແລະຜູ້ນໍາທີມໃຊ້ເວລາປະຈຸບັນແລະປຶກສາຫາລືກັບລູກຄ້າ.
• ທຸກໆມື້, ນັກພັດທະນາຄວນຂຽນໃນການສົນທະນາຂອງລູກຄ້າກ່ຽວກັບວຽກງານທີ່ລາວເຮັດວຽກໃນມື້ວານນີ້ແລະວຽກງານໃດທີ່ລາວຈະເຮັດວຽກໃນມື້ນີ້.
• ຂະບວນການເຮັດວຽກແມ່ນອີງໃສ່ Scrum. ທຸກສິ່ງທຸກຢ່າງແມ່ນແບ່ງອອກເປັນ sprints. ການແລ່ນແຕ່ລະຄັ້ງໃຊ້ເວລາສອງອາທິດ.
• Sprints ຖືກສ້າງຂຶ້ນ, ເຕັມໄປແລະປິດໂດຍຫົວຫນ້າທີມ.
• ຖ້າໂຄງການມີກໍານົດເວລາຢ່າງເຂັ້ມງວດ, ພວກເຮົາພະຍາຍາມປະມານປະມານວຽກງານທັງຫມົດ. ແລະພວກເຮົາເກັບກໍາຈາກພວກເຂົາ sprint ເປັນ. ຖ້າລູກຄ້າພະຍາຍາມເພີ່ມຫນ້າວຽກເພີ່ມເຕີມຕໍ່ກັບ sprint, ຫຼັງຈາກນັ້ນພວກເຮົາກໍານົດບູລິມະສິດ, ແລະໂອນບາງວຽກງານອື່ນໆໃຫ້ກັບ sprint ຕໍ່ໄປ.

b) ຂະບວນການເຮັດວຽກກັບລູກຄ້າ

• ນັກພັດທະນາແຕ່ລະຄົນສາມາດແລະຄວນຕິດຕໍ່ສື່ສານກັບລູກຄ້າ
• ທ່ານບໍ່ສາມາດອະນຸຍາດໃຫ້ລູກຄ້າບັງຄັບໃຊ້ກົດລະບຽບຂອງຕົນເອງຂອງເກມ. ມັນເປັນສິ່ງຈໍາເປັນໃນລັກສະນະທີ່ສຸພາບແລະເປັນມິດທີ່ຈະເຮັດໃຫ້ລູກຄ້າຊັດເຈນວ່າພວກເຮົາເປັນຜູ້ຊ່ຽວຊານໃນດ້ານຂອງພວກເຮົາ, ແລະພຽງແຕ່ພວກເຮົາຄວນຈະສ້າງຂະບວນການເຮັດວຽກແລະມີສ່ວນຮ່ວມກັບລູກຄ້າໃນພວກເຂົາ.
• ມັນເປັນສິ່ງຈໍາເປັນ, ໂດຍສະເພາະ, ກ່ອນທີ່ຈະດໍາເນີນການປະຕິບັດຫນ້າທີ່ໃດຫນຶ່ງ, ເພື່ອສ້າງຕາຕະລາງການໄຫຼເຂົ້າຂອງຂະບວນການຢ່າງມີເຫດຜົນທັງຫມົດສໍາລັບຄຸນສົມບັດ (ຂະບວນການເຮັດວຽກ). ແລະສົ່ງໃຫ້ລູກຄ້າສໍາລັບການຢືນຢັນ. ນີ້ໃຊ້ກັບການເຮັດວຽກທີ່ສັບສົນແລະບໍ່ຊັດເຈນ, ຕົວຢ່າງ, ລະບົບການຈ່າຍເງິນ, ລະບົບການແຈ້ງເຕືອນ, ແລະອື່ນໆ. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈໄດ້ຢ່າງຖືກຕ້ອງກ່ຽວກັບສິ່ງທີ່ລູກຄ້າຕ້ອງການ, ບັນທຶກເອກະສານສໍາລັບຄຸນນະສົມບັດ, ແລະຍັງຮັບປະກັນຕົວເອງຕໍ່ກັບຄວາມຈິງທີ່ວ່າລູກຄ້າອາດຈະເວົ້າໃນອະນາຄົດທີ່ພວກເຮົາບໍ່ໄດ້ເຮັດສິ່ງທີ່ລາວຮ້ອງຂໍ.
• ແຜນວາດທັງໝົດ/ແຜນຜັງຂັ້ນຕອນ/ເຫດຜົນ ແລະ ອື່ນໆ. ພວກເຮົາປະຫຍັດໃນ Confluence / Fat, ບ່ອນທີ່ພວກເຮົາຂໍໃຫ້ລູກຄ້າໃນຄໍາເຫັນເພື່ອຢືນຢັນຄວາມຖືກຕ້ອງຂອງການປະຕິບັດໃນອະນາຄົດ.
• ພວກເຮົາພະຍາຍາມບໍ່ໃຫ້ພາລະລູກຄ້າດ້ວຍລາຍລະອຽດດ້ານວິຊາການ. ຖ້າພວກເຮົາຕ້ອງການຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີທີ່ລູກຄ້າຕ້ອງການ, ຫຼັງຈາກນັ້ນພວກເຮົາແຕ້ມ algorithms primitive ໃນຮູບແບບຂອງ flowchart ທີ່ລູກຄ້າສາມາດເຂົ້າໃຈແລະແກ້ໄຂ / ດັດແປງທຸກຢ່າງດ້ວຍຕົນເອງ.
• ຖ້າລູກຄ້າພົບຂໍ້ບົກພ່ອງໃນໂຄງການ, ຫຼັງຈາກນັ້ນພວກເຮົາຂໍໃຫ້ເຈົ້າອະທິບາຍລາຍລະອຽດໃນ Fat. ພາຍໃຕ້ສະຖານະການໃດທີ່ມັນເກີດຂຶ້ນ, ເວລາໃດ, ລໍາດັບການປະຕິບັດໂດຍລູກຄ້າໃນລະຫວ່າງການທົດສອບ. ກະລຸນາແນບຮູບໜ້າຈໍ.
• ພວກເຮົາພະຍາຍາມທຸກໆມື້, ສູງສຸດໃນມື້ອື່ນ, ເພື່ອນໍາໃຊ້ກັບເຄື່ອງແມ່ຂ່າຍຂອງ dev. ຫຼັງຈາກນັ້ນ, ລູກຄ້າຈະເລີ່ມທົດສອບການທໍາງານແລະໂຄງການບໍ່ໄດ້ຢູ່ຊື່ໆ. ໃນເວລາດຽວກັນ, ນີ້ແມ່ນເຄື່ອງຫມາຍສໍາລັບລູກຄ້າວ່າໂຄງການແມ່ນຢູ່ໃນການພັດທະນາຢ່າງເຕັມທີ່ແລະບໍ່ມີໃຜບອກລາວ tales fairy.
• ມັນມັກຈະເກີດຂື້ນວ່າລູກຄ້າບໍ່ເຂົ້າໃຈຢ່າງເຕັມສ່ວນກ່ຽວກັບສິ່ງທີ່ລາວຕ້ອງການ. ນັບຕັ້ງແຕ່ລາວສ້າງທຸລະກິດໃຫມ່ສໍາລັບຕົນເອງ, ດ້ວຍຂະບວນການທີ່ຍັງບໍ່ທັນໄດ້ debugged. ດັ່ງນັ້ນ, ກໍລະນີທີ່ພົບເລື້ອຍທີ່ສຸດແມ່ນເມື່ອພວກເຮົາຖິ້ມລະຫັດທັງຫມົດເຂົ້າໄປໃນຖັງຂີ້ເຫຍື້ອແລະປ່ຽນຮູບແບບຂອງເຫດຜົນຂອງແອັບພລິເຄຊັນ. ມັນປະຕິບັດຕາມນີ້ວ່າມັນບໍ່ຈໍາເປັນທີ່ຈະກວມເອົາທຸກສິ່ງທຸກຢ່າງຢ່າງແທ້ຈິງດ້ວຍການທົດສອບ. ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ຈະກວມເອົາພຽງແຕ່ຫນ້າທີ່ທີ່ສໍາຄັນກັບການທົດສອບ, ແລະຫຼັງຈາກນັ້ນດ້ວຍການຈອງ.
• ມີສະຖານະການໃນເວລາທີ່ທີມງານຮັບຮູ້ວ່າພວກເຮົາບໍ່ເຫມາະກັບກໍານົດເວລາ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາດໍາເນີນການກວດສອບວຽກງານຢ່າງໄວວາ, ແລະແຈ້ງໃຫ້ລູກຄ້າຮູ້ທັນທີ. ເປັນວິທີທາງອອກຈາກສະຖານະການ, ພວກເຮົາແນະນໍາໃຫ້ເປີດຕົວຫນ້າທີ່ທີ່ສໍາຄັນແລະສໍາຄັນຕາມເວລາ, ແລະປ່ອຍໃຫ້ສ່ວນທີ່ເຫຼືອສໍາລັບການປ່ອຍຕົວ.
• ຖ້າລູກຄ້າເລີ່ມມີວຽກທີ່ແຕກຕ່າງຈາກຫົວຂອງລາວ, ເລີ່ມຕົ້ນຈິນຕະນາການແລະອະທິບາຍດ້ວຍນິ້ວມືຂອງລາວ, ຫຼັງຈາກນັ້ນພວກເຮົາຂໍໃຫ້ລາວຈັດວາງຫນ້າແລະໄຫຼກັບເຫດຜົນທີ່ຄວນອະທິບາຍຢ່າງເຕັມສ່ວນກ່ຽວກັບພຶດຕິກໍາຂອງຮູບແບບທັງຫມົດແລະມັນ. ອົງປະກອບ.
• ກ່ອນທີ່ພວກເຮົາຈະປະຕິບັດວຽກງານໃດກໍ່ຕາມ, ພວກເຮົາຕ້ອງໃຫ້ແນ່ໃຈວ່າຄຸນສົມບັດນີ້ຖືກລວມຢູ່ໃນເງື່ອນໄຂຂອງສັນຍາ / ສັນຍາຂອງພວກເຮົາ. ຖ້ານີ້ແມ່ນຄຸນສົມບັດໃຫມ່ທີ່ເກີນກວ່າຂໍ້ຕົກລົງເບື້ອງຕົ້ນຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງຄາດຄະເນຄຸນສົມບັດນີ້ຢ່າງແນ່ນອນ ((ເວລານໍາໂດຍປະມານ + 30%) x 2) ແລະຊີ້ບອກກັບລູກຄ້າວ່າມັນຈະໃຊ້ເວລາຫຼາຍເພື່ອເຮັດມັນ, ບວກກັບ ເສັ້ນຕາຍແມ່ນປ່ຽນເວລາປະມານການຄູນດ້ວຍສອງ. ຂໍໃຫ້ວຽກງານໄວຂຶ້ນ - ຍິ່ງໃຫຍ່, ທຸກຄົນຈະໄດ້ຮັບຜົນປະໂຫຍດຈາກນີ້ເທົ່ານັ້ນ. ຖ້າບໍ່, ຫຼັງຈາກນັ້ນພວກເຮົາປະກັນໄພ.

c) ສິ່ງທີ່ພວກເຮົາບໍ່ຍອມຮັບໃນທີມງານ:

• ຄວາມບໍ່ສອດຄ່ອງ, ຄວາມບໍ່ສອດຄ່ອງ, ລືມ
• "ການໃຫ້ອາຫານເຊົ້າ". ຖ້າທ່ານບໍ່ສາມາດເຮັດສໍາເລັດວຽກງານ, ທ່ານບໍ່ຮູ້ວິທີ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງແຈ້ງໃຫ້ຫົວຫນ້າທີມທັນທີທັນໃດ, ແລະຢ່າລໍຖ້າຈົນກ່ວາສຸດທ້າຍ.
• Brovadas ແລະໂອ້ອວດຈາກຜູ້ຊາຍທີ່ຍັງບໍ່ທັນໄດ້ພິສູດຄວາມສາມາດແລະເປັນມືອາຊີບຂອງຕົນໂດຍການກະທໍາ. ຖ້າພິສູດແລ້ວ, ມັນເປັນໄປໄດ້, ຢູ່ໃນຂອບເຂດຂອງຄວາມທ່ຽງທໍາ🙂
• ການສໍ້ໂກງໃນທຸກການສະແດງຂອງມັນ. ຖ້າວຽກງານບໍ່ສໍາເລັດ, ຫຼັງຈາກນັ້ນທ່ານບໍ່ຄວນປ່ຽນສະຖານະພາບຂອງມັນເພື່ອໃຫ້ສໍາເລັດແລະຂຽນໃນການສົນທະນາຂອງລູກຄ້າວ່າມັນພ້ອມແລ້ວ. ຄອມພີວເຕີ crashed, ລະບົບ crashed, ຫມາ chewed ສຸດ laptop - ທັງຫມົດນີ້ແມ່ນຍອມຮັບບໍ່ໄດ້. ຖ້າເກີດເຫດບັງເອີນແທ້, ຫົວໜ້າທີມຄວນແຈ້ງໃຫ້ຊາບທັນທີ.
• ໃນເວລາທີ່ຜູ້ຊ່ຽວຊານ offline ຕະຫຼອດເວລາແລະມັນຍາກທີ່ຈະເຂົ້າຫາລາວໃນເວລາເຮັດວຽກ.
• ສານພິດໃນທີມແມ່ນບໍ່ອະນຸຍາດໃຫ້! ຖ້າໃຜຜູ້ຫນຶ່ງບໍ່ເຫັນດີກັບບາງສິ່ງບາງຢ່າງ, ຫຼັງຈາກນັ້ນທຸກຄົນເຕົ້າໂຮມກັນສໍາລັບການຊຸມນຸມແລະປຶກສາຫາລືແລະຕັດສິນໃຈ.

ແລະຈໍານວນຄໍາຖາມ / ເຫຼົ່ານີ້ບາງຄັ້ງຂ້ອຍຂໍໃຫ້ລູກຄ້າຂອງຂ້ອຍເອົາຄວາມເຂົ້າໃຈຜິດທັງຫມົດ:

1. ເງື່ອນໄຂຄຸນນະພາບຂອງເຈົ້າແມ່ນຫຍັງ?
2. ທ່ານກໍານົດແນວໃດວ່າໂຄງການໃດຫນຶ່ງມີບັນຫາຫຼືບໍ່?
3. ການລະເມີດຄໍາແນະນໍາແລະຄໍາແນະນໍາທັງຫມົດຂອງພວກເຮົາກ່ຽວກັບການປ່ຽນແປງ / ປັບປຸງລະບົບ, ຄວາມສ່ຽງທັງຫມົດແມ່ນເກີດມາຈາກທ່ານເທົ່ານັ້ນ
4. ການປ່ຽນແປງໂຄງການທີ່ສໍາຄັນໃດໆ ​​(ຕົວຢ່າງ, ທຸກປະເພດຂອງການໄຫຼພິເສດ) ຈະນໍາໄປສູ່ການປະກົດຕົວທີ່ເປັນໄປໄດ້ຂອງແມງໄມ້ (ຊຶ່ງແນ່ນອນ, ພວກເຮົາຈະແກ້ໄຂ)
5. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າໃຈພາຍໃນສອງສາມນາທີວ່າບັນຫາປະເພດໃດເກີດຂື້ນໃນໂຄງການ, ແລະຍິ່ງໄປກວ່ານັ້ນເພື່ອແກ້ໄຂມັນຢູ່ບ່ອນນັ້ນ.
6. ພວກເຮົາເຮັດວຽກກ່ຽວກັບການໄຫລຂອງຜະລິດຕະພັນສະເພາະ (ວຽກງານໃນ Zhira - ການພັດທະນາ - ການທົດສອບ - ນໍາໃຊ້). ນີ້ຫມາຍຄວາມວ່າພວກເຮົາບໍ່ສາມາດຕອບສະຫນອງຕໍ່ການຮຽກຮ້ອງແລະການຮ້ອງທຸກທັງຫມົດໃນການສົນທະນາ.
7. ຜູ້ຂຽນໂປລແກລມແມ່ນພຽງແຕ່ນັກຂຽນໂປລແກລມ, ບໍ່ແມ່ນນັກທົດສອບມືອາຊີບ, ແລະບໍ່ສາມາດຮັບປະກັນຄຸນນະພາບທີ່ເຫມາະສົມຂອງການທົດສອບໂຄງການ
8. ຄວາມຮັບຜິດຊອບສໍາລັບການທົດສອບສຸດທ້າຍແລະການຍອມຮັບວຽກງານກ່ຽວກັບການຂາຍແມ່ນຂຶ້ນກັບທ່ານທັງຫມົດ
9. ຖ້າພວກເຮົາໄດ້ປະຕິບັດວຽກງານໃດຫນຶ່ງແລ້ວ, ພວກເຮົາບໍ່ສາມາດປ່ຽນໄປຫາຜູ້ອື່ນໄດ້ທັນທີຈົນກ່ວາພວກເຮົາເຮັດສໍາເລັດໃນປັດຈຸບັນ (ຖ້າບໍ່ດັ່ງນັ້ນນີ້ເຮັດໃຫ້ແມງໄມ້ຫຼາຍຂື້ນແລະເວລາພັດທະນາເພີ່ມຂຶ້ນ)
10. ມີຄົນຢູ່ໃນທີມຫນ້ອຍ (ເນື່ອງມາຈາກການພັກຜ່ອນຫຼືການເຈັບປ່ວຍ), ແລະມີວຽກຫຼາຍແລະພວກເຮົາຈະບໍ່ມີເວລາທາງດ້ານຮ່າງກາຍເພື່ອຕອບສະຫນອງທຸກສິ່ງທີ່ທ່ານຕ້ອງການ.
11. ການຂໍໃຫ້ທ່ານນໍາໄປໃຊ້ໃນການຜະລິດໂດຍບໍ່ມີການທົດສອບໃນ dev ແມ່ນພຽງແຕ່ຄວາມສ່ຽງຂອງທ່ານ, ບໍ່ແມ່ນຜູ້ພັດທະນາ
12. ໃນເວລາທີ່ທ່ານກໍານົດວຽກງານທີ່ສັບສົນ, ໂດຍບໍ່ມີການໄຫຼທີ່ຖືກຕ້ອງ, ໂດຍບໍ່ມີຮູບແບບການອອກແບບ, ນີ້ຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມແລະເວລາການປະຕິບັດຫຼາຍຈາກພວກເຮົາ, ເພາະວ່າພວກເຮົາຕ້ອງເຮັດຈໍານວນວຽກເພີ່ມເຕີມແທນທ່ານ.
13. ວຽກງານໃດໆກໍຕາມກ່ຽວກັບແມງໄມ້, ໂດຍບໍ່ມີການລາຍລະອຽດຂອງການປະກົດຕົວ ແລະພາບໜ້າຈໍຂອງພວກມັນ, ບໍ່ໃຫ້ໂອກາດພວກເຮົາເຂົ້າໃຈສິ່ງທີ່ຜິດພາດ ແລະພວກເຮົາຈະປ່ອຍແມງໄມ້ນີ້ແນວໃດ.
14. ໂຄງການດັ່ງກ່າວຮຽກຮ້ອງໃຫ້ມີການປັບປຸງແລະການປັບປຸງຢ່າງຕໍ່ເນື່ອງເພື່ອປັບປຸງການປະຕິບັດແລະຄວາມປອດໄພ. ດັ່ງນັ້ນ, ທີມງານໃຊ້ເວລາບາງສ່ວນຂອງການປັບປຸງເຫຼົ່ານີ້.
15. ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າພວກເຮົາມີຊົ່ວໂມງເຮັດວຽກລ່ວງເວລາ (ການແກ້ໄຂດ່ວນ), ພວກເຮົາຕ້ອງຊົດເຊີຍໃຫ້ເຂົາເຈົ້າໃນມື້ອື່ນ

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

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

PS ຂ້າພະເຈົ້າຕ້ອງການໃຫ້ຄວາມກະຈ່າງແຈ້ງວ່າບໍ່ມີຜູ້ຈັດການໂຄງການຢູ່ຝ່າຍພວກເຮົາ. ມັນແມ່ນຢູ່ຂ້າງລູກຄ້າ. ບໍ່ແມ່ນເທັກນິກເລີຍ. ໂຄງການເອີຣົບ. ການສື່ສານທັງໝົດເປັນພາສາອັງກິດເທົ່ານັ້ນ.

ໂຊກດີກັບທຸກຄົນໃນໂຄງການຂອງທ່ານ. ຢ່າເຜົາໄຫມ້ແລະພະຍາຍາມປັບປຸງຂະບວນການຂອງທ່ານ.

ແຫຼ່ງໃນຂອງຂ້ອຍ blog post.

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