ການ​ຄຸ້ມ​ຄອງ​ຄວາມ​ຂັດ​ແຍ່ງ​ໃນ​ທີມ​ງານ – ເປັນ​ການ​ດຸ່ນ​ດ່ຽງ​ຫຼື​ຄວາມ​ຈໍາ​ເປັນ​ທີ່​ສໍາ​ຄັນ​?

Epigraph:
ມີຄັ້ງໜຶ່ງ, ເໝັ້ນ ແລະໝີນ້ອຍພົບກັນໃນປ່າ.
- ສະບາຍດີ, Hedgehog!
- ສະບາຍດີ, ຫມີນ້ອຍ!
ດັ່ງນັ້ນ, ຄໍາເວົ້າເປັນຄໍາເວົ້າ, ຕະຫລົກໂດຍຕະຫລົກ, Hedgehog ໄດ້ຖືກຕີໃບຫນ້າໂດຍຫມີນ້ອຍ ...

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

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

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

ແມ່ນຫຍັງທີ່ພົບເລື້ອຍໃນທຸກສະຖານະການທີ່ສາມາດຖືກກໍານົດວ່າເປັນສະຖານະການຂັດແຍ້ງໃນການເຮັດວຽກ?



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

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

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

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

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

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

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

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

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

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

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

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

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

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

ຂໍ​ໃຫ້​ພິຈາລະນາ​ສະຖານະການ​ຂັດ​ແຍ່ງ​ແບບ​ປົກກະຕິ​ຫຼາຍ​ຢ່າງ, ຈາກ​ງ່າຍ​ຫາ​ຊັບຊ້ອນ:

ການຂັດແຍ້ງທີ່ບໍ່ກ່ຽວຂ້ອງກັບບັນຫາການເຮັດວຽກ

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

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

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

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

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

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

ຂໍ້ຂັດແຍ່ງທີ່ກ່ຽວຂ້ອງກັບບັນຫາການເຮັດວຽກ:

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

ຂ້ອຍຈະຍົກໃຫ້ເຫັນສອງກໍລະນີທົ່ວໄປຢູ່ທີ່ນີ້:

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

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

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

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

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

ການສົນທະນາຂອງພວກເຮົາເບິ່ງຄືແນວນີ້ (ແນ່ນອນ, ການສົນທະນາໄດ້ແກ່ຍາວເປັນເວລາເຄິ່ງຊົ່ວໂມງ):

- Pasha, ພວກເຮົາມີຄຸນສົມບັດ freeze ໃນສອງສາມມື້. ມັນເປັນສິ່ງສໍາຄັນທີ່ພວກເຮົາໄດ້ຮັບທຸກສິ່ງທຸກຢ່າງຮ່ວມກັນແລະເລີ່ມຕົ້ນການທົດສອບໄວເທົ່າທີ່ເປັນໄປໄດ້. ພວກເຮົາສາມາດຜ່ານ Igor ໄດ້ແນວໃດ?
— ລາວ​ຕ້ອງ​ການ​ຕັ້ງ​ຄ່າ​ການ​ບໍ​ລິ​ການ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​, ລາວ​ຕິດ​ຄໍາ​ເຫັນ​ທີ່​ນັ້ນ​ສໍາ​ລັບ​ຂ້າ​ພະ​ເຈົ້າ ...
- ແລະສິ່ງທີ່ມີ, ການປ່ຽນແປງອັນໃຫຍ່ຫຼວງ, fuss ຫຼາຍ?
- ບໍ່, ມີການເຮັດວຽກສໍາລັບສອງສາມຊົ່ວໂມງ, ແຕ່ສຸດທ້າຍບໍ່ມີຄວາມແຕກຕ່າງ, ມັນຈະເຮັດວຽກທັງສອງທາງ, ເປັນຫຍັງມັນຈຶ່ງຈໍາເປັນ? ຂ້າພະເຈົ້າໄດ້ເຮັດບາງສິ່ງບາງຢ່າງທີ່ເຮັດວຽກ, ໃຫ້ຍອມຮັບມັນ.
- ຟັງ, ທ່ານໄດ້ສົນທະນາທັງຫມົດນີ້ດົນປານໃດ?
- ແມ່ນແລ້ວ, ພວກເຮົາໄດ້ກໍານົດເວລາສໍາລັບອາທິດແລະເຄິ່ງຫນຶ່ງໃນປັດຈຸບັນ.
- ເອີ ... ພວກເຮົາສາມາດແກ້ໄຂບັນຫາໃນສອງສາມຊົ່ວໂມງທີ່ໄດ້ໃຊ້ເວລາຫນຶ່ງອາທິດແລະເຄິ່ງຫນຶ່ງ, ແລະບໍ່ໄດ້ເຮັດມັນບໍ?
- ແມ່ນແລ້ວ, ແຕ່ຂ້ອຍບໍ່ຢາກໃຫ້ Igor ຄິດວ່າຂ້ອຍເຂົ້າໄປໃນ ...
- ຟັງ, ສິ່ງທີ່ສໍາຄັນກວ່າສໍາລັບທ່ານ, ການອອກການປ່ອຍຕົວ, ພ້ອມກັບການຕັດສິນໃຈຂອງເຈົ້າພາຍໃນ, ຫຼືການຂ້າ Igor? ພວກເຮົາສາມາດສະກັດມັນ, ຢ່າງໃດກໍຕາມ, ມີໂອກາດທີ່ດີທີ່ຈະບິນຜ່ານກັບການປ່ອຍ.
- ແນ່ນອນ, ມັນຈະເປັນການເຢັນ, ເຊັດດັງ Igor, ແຕ່ຕົກລົງ, ການປ່ອຍແມ່ນສໍາຄັນກວ່າ, ຂ້ອຍເຫັນດີ.
- ມັນສໍາຄັນແທ້ໆກັບເຈົ້າສິ່ງທີ່ Igor ຄິດບໍ? ດ້ວຍຄວາມຊື່ສັດ, ລາວບໍ່ໄດ້ເວົ້າເຍາະເຍີ້ຍເລີຍ, ລາວພຽງແຕ່ຕ້ອງການວິທີການທີ່ເປັນເອກະພາບໃນສະຖານທີ່ທີ່ແຕກຕ່າງກັນຂອງສິ່ງທີ່ລາວຮັບຜິດຊອບ.
- ແລ້ວ, ໂອເຄ, ໃຫ້ຂ້ອຍເຮັດຕາມທີ່ລາວຖາມໃນຄໍາເຫັນແລະໃຫ້ເລີ່ມຕົ້ນການທົດສອບ.
- ຂອບໃຈ, Pasha! ຂ້ອຍແນ່ໃຈວ່າເຈົ້າທັງສອງເຈົ້າຈະເປັນຜູ້ໃຫຍ່ກວ່າ, ເຖິງແມ່ນວ່າ Igorek ມີອາຍຸຫຼາຍກວ່າເຈົ້າ :)

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

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

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

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

ຈາກທັດສະນະຂອງຂະບວນການເຮັດວຽກ, ໃນກໍລະນີນີ້, ມັນຈະຊ່ວຍໃຫ້ມີຄໍາອະທິບາຍກ່ຽວກັບເຄື່ອງມືທີ່ໃຊ້, ຄວາມຕ້ອງການສໍາລັບພວກເຂົາ, ຂໍ້ຈໍາກັດກ່ຽວກັບການເພີ່ມໃຫມ່, ແລະເຫດຜົນສໍາລັບຂໍ້ຈໍາກັດດັ່ງກ່າວ. ເອກະສານດັ່ງກ່າວປະມານປະມານທີ່ອະທິບາຍໄວ້ໃນວັກ Reuse Strategy and Development Environment of the Manager's Handbook for Software Development, ພັດທະນາໃນ ອົງການ NASA. ເຖິງວ່າຈະມີອາຍຸຂອງມັນ, ມັນໄດ້ອະທິບາຍຢ່າງສົມບູນທຸກກິດຈະກໍາຕົ້ນຕໍແລະຂັ້ນຕອນການວາງແຜນຂອງການພັດທະນາຊອບແວຂອງປະເພດນີ້. ການມີເອກະສານແບບນີ້ເຮັດໃຫ້ມັນງ່າຍຫຼາຍທີ່ຈະປຶກສາຫາລືກ່ຽວກັບອົງປະກອບແລະວິທີການທີ່ສາມາດນໍາໃຊ້ໃນຜະລິດຕະພັນໃດຫນຶ່ງ, ແລະເປັນຫຍັງ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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