ເປັນຫຍັງການສື່ສານທີມຈຶ່ງມີຄວາມ ສຳ ຄັນຫຼາຍກ່ວາ Stack Martech ຂອງທ່ານ

ການສື່ສານແລະການວິເຄາະຂອງທີມງານການຕະຫຼາດ

ມຸມມອງ atypical ຂອງ Simo Ahava ກ່ຽວກັບຄຸນນະພາບຂອງຂໍ້ມູນແລະໂຄງສ້າງການສື່ສານໄດ້ພັດທະນາຫ້ອງຮັບແຂກທັງ ໝົດ ໄປວິເຄາະ! ກອງປະຊຸມ. OWOX, ຜູ້ ນຳ MarTech ໃນພາກພື້ນ CIS, ໄດ້ຕ້ອນຮັບຜູ້ຊ່ຽວຊານຫລາຍພັນຄົນເຂົ້າຮ່ວມການຊຸມນຸມນີ້ເພື່ອແບ່ງປັນຄວາມຮູ້ແລະຄວາມຄິດຂອງພວກເຂົາ.

ທີມ OWOX BI ຢາກໃຫ້ທ່ານຄິດກ່ຽວກັບແນວຄິດທີ່ສະ ເໜີ ໂດຍ Simo Ahava, ເຊິ່ງແນ່ນອນວ່າມັນມີທ່າແຮງທີ່ຈະເຮັດໃຫ້ທຸລະກິດຂອງທ່ານເຕີບໃຫຍ່. 

ຄຸນະພາບຂອງຂໍ້ມູນແລະຄຸນນະພາບຂອງອົງກອນ

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

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

ບໍລິສັດແລະໂຄງສ້າງການສື່ສານຂອງພວກເຂົາ

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

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

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

ນີ້, ທີ່ນີ້, ແລະຢູ່ທີ່ນັ້ນ! ນຳ ໃຊ້ກົນລະຍຸດທຸລະກິດ ໃໝ່ ນີ້ແລະທ່ານຈະດີ!

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

ສະນັ້ນປະໂຫຍດຂອງບໍລິສັດເຫຼົ່ານີ້ດ້ວຍຕົນເອງແມ່ນ ຈຳ ກັດ. 

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

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

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

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

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

ກົດ ໝາຍ Conway ນຳ ໃຊ້ກັບບໍລິສັດວິເຄາະ

ຂໍ້ມູນທີ່ມີຄວາມ ໝາຍ - ກົດ ໝາຍ ຂອງ Conway

ເມື່ອຫ້າສິບປີກ່ອນ, ນັກຂຽນໂປລແກລມທີ່ຍິ່ງໃຫຍ່ຊື່ວ່າ Melvin Conway ໄດ້ໃຫ້ ຄຳ ແນະ ນຳ ວ່າຕໍ່ມາໄດ້ກາຍເປັນທີ່ຮູ້ຈັກກັນໃນນາມກົດ ໝາຍ ຂອງ Conway: 

ອົງກອນທີ່ອອກແບບລະບົບ. . . ມີຂໍ້ ຈຳ ກັດໃນການຜະລິດອອກແບບເຊິ່ງເປັນ ສຳ ເນົາຂອງໂຄງສ້າງການສື່ສານຂອງອົງກອນເຫຼົ່ານີ້.

Melvin Conway, ກົດ ໝາຍ ຂອງ Conway

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

ໝາຍ ເຫດຂອງຜູ້ຂຽນ:

ທິດສະດີນີ້ໄດ້ຖືກທົດສອບມາຫຼາຍຮ້ອຍຄັ້ງແລ້ວໃນໂລກພັດທະນາແລະໄດ້ມີການປຶກສາຫາລືຫຼາຍຢ່າງ. ນິຍາມທີ່ແນ່ນອນທີ່ສຸດຂອງກົດ ໝາຍ ຂອງ Conway ຖືກສ້າງຂື້ນໂດຍ Pieter Hintjens, ໜຶ່ງ ໃນນັກຂຽນໂປແກຼມທີ່ມີອິດທິພົນທີ່ສຸດໃນຕົ້ນຊຸມປີ 2000, ເຊິ່ງກ່າວວ່າ "ຖ້າທ່ານຢູ່ໃນອົງກອນທີ່ບໍ່ມີປະໂຫຍດ, ທ່ານຈະສ້າງໂປແກຼມໂປຼແກຼມ shitty." (Amdahl ເຖິງ Zipf: ກົດ ໝາຍ ຟີຊິກສາດ XNUMX ປະການ)

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

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

ນັ້ນແມ່ນເຫດຜົນທີ່ລະບົບການແລກປ່ຽນຂໍ້ມູນເປີດເຜີຍຄວາມບໍ່ສົມບູນຂອງພວກເຮົາຢ່າງສົມບູນ.

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

ໂຄງສ້າງການສື່ສານທີ່ດີທີ່ສຸດແລະຮ້າຍແຮງທີ່ສຸດ ສຳ ລັບຫລາຍໆທີມ

ທີມງານໂຄງການ ທຳ ມະດາໃນບໍລິສັດ MarTech ຫລືບໍລິສັດວິເຄາະດ້ານການຕະຫຼາດປະກອບດ້ວຍຊ່ຽວຊານດ້ານຄວາມສະຫຼາດ (BI), ນັກວິທະຍາສາດຂໍ້ມູນ, ນັກອອກແບບ, ນັກກາລະຕະຫຼາດ, ນັກວິເຄາະແລະນັກຂຽນໂປແກຼມຕ່າງໆ (ໂດຍລວມ).

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

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

ຊຸກຍູ້ໃຫ້ທີມງານມີຫຼາຍວິຊາ

ລັກສະນະທີ່ບໍ່ດີທີ່ສຸດຂອງສະຖານະການນີ້:

  • ການມີສ່ວນຮ່ວມບໍ່ພຽງພໍ
  • ການມີສ່ວນຮ່ວມບໍ່ພຽງພໍ
  • ຂາດການຮ່ວມມື
  • ຂາດຄວາມໄວ້ວາງໃຈ

ພວກເຮົາສາມາດແກ້ໄຂໄດ້ແນວໃດ? ຮູ້ຫນັງສືໂດຍການເຮັດໃຫ້ຄົນສົນທະນາ. 

ຊຸກຍູ້ໃຫ້ມີທີມງານຫຼາຍພາກວິຊາ

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

ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າການປະຊຸມແມ່ນພຽງແຕ່ຂັ້ນຕອນ ທຳ ອິດເທົ່ານັ້ນ. ພວກເຮົາຍັງມີບັນຫາບາງຢ່າງ:

  • ການສື່ສານທີ່ບໍ່ດີ
  • ຂາດຈຸດປະສົງເຊິ່ງກັນແລະກັນ
  • ການມີສ່ວນຮ່ວມບໍ່ພຽງພໍ

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

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

ນຳ ພາທຸກຄົນຕິດຕໍ່ສື່ສານກ່ຽວກັບໂຄງການ. 

ການສື່ສານຫຼາຍວິຊາໃນທີມ

ຄຸນລັກສະນະທີ່ດີທີ່ສຸດຂອງວິທີການນີ້:

  • ຄວາມ​ໂປ່ງ​ໃສ
  • ການມີສ່ວນຮ່ວມ
  • ການແລກປ່ຽນຄວາມຮູ້ແລະທັກສະ
  • ການສຶກສາແບບບໍ່ຢຸດຢັ້ງ

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

ນັ້ນແມ່ນເຫດຜົນທີ່ຂ້ອຍມັກ Agile ຫຼາຍ, ເພາະວ່າມັນລວມເອົາຄວາມ ສຳ ຄັນຂອງການສື່ສານເປັນເງື່ອນໄຂເບື້ອງຕົ້ນ ສຳ ລັບຄວາມຢູ່ລອດຂອງໂຄງການ.

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

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

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

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

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

ຈ້າງນັກກາລະຕະຫຼາດເພື່ອການສຶກສາ, ບໍ່ແມ່ນຄະນະຜູ້ແທນ

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

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

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

ໃຫ້ເຮົາເບິ່ງວ່າທັງ ໝົດ ນັ້ນມີອິດທິພົນຕໍ່ພາກສ່ວນທີ່ສັບສົນທີ່ສຸດຂອງວຽກການວິເຄາະດ້ານການຕະຫຼາດຄື: ກຳ ນົດການໄຫລຂອງຂໍ້ມູນແລະການລວມຂໍ້ມູນ.

ໂຄງສ້າງການສື່ສານໄດ້ສະທ້ອນແນວໃດໃນການຖ່າຍໂອນຂໍ້ມູນແລະການປຸງແຕ່ງ?

ໃຫ້ສົມມຸດວ່າພວກເຮົາມີສາມແຫລ່ງຂໍ້ມູນໃຫ້ພວກເຮົາຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້: ຂໍ້ມູນການຈະລາຈອນ, ຂໍ້ມູນຜະລິດຕະພັນການຄ້າ e-commerce / ຂໍ້ມູນຊື້ຈາກໂປແກຼມຄວາມສັດຊື່, ແລະຂໍ້ມູນການວິເຄາະທາງມືຖື. ພວກເຮົາຈະຜ່ານຂັ້ນຕອນການປະມວນຜົນຂໍ້ມູນແຕ່ລະອັນ, ຈາກການສົ່ງຂໍ້ມູນທັງ ໝົດ ໄປທີ່ Google Cloud ເພື່ອສົ່ງທຸກຢ່າງເພື່ອເບິ່ງໃນ Google Data Studio ໂດຍການຊ່ວຍເຫຼືອຂອງ Google BigQuery

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

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

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

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

  • ການເບິ່ງເຫັນ
    ນີ້ແມ່ນເວທີ CEO. ທ່ານອາດຈະໄດ້ຍິນກ່ຽວກັບສະຖານະການໃນເວລາທີ່ຊີອີໂອເບິ່ງຕົວເລກຢູ່ໃນ dashboard ແລະເວົ້າວ່າ:“ ໂອເຄ, ປີນີ້ພວກເຮົາໄດ້ ກຳ ໄລຫຼາຍ, ແມ່ນຫຼາຍກ່ວາກ່ອນ ໜ້າ ນີ້, ແຕ່ເປັນຫຍັງບັນດາຕົວ ກຳ ນົດການເງິນທັງ ໝົດ ຢູ່ໃນເຂດສີແດງ ?” ແລະໃນເວລານີ້, ມັນຊ້າເກີນໄປທີ່ຈະຊອກຫາຄວາມຜິດພາດ, ຍ້ອນວ່າພວກເຂົາຄວນຈະຖືກຈັບມາດົນແລ້ວ.

ທຸກສິ່ງທຸກຢ່າງແມ່ນອີງໃສ່ການສື່ສານ. ແລະໃນຫົວຂໍ້ຂອງການສົນທະນາ. ນີ້ແມ່ນຕົວຢ່າງຂອງສິ່ງທີ່ຄວນສົນທະນາໃນຂະນະທີ່ກະກຽມ Yandex streaming:

ການຕະຫຼາດ BI: Snowplow, Google Analytics, Yandex

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

ສະລັບສັບຊ້ອນແມ່ນມີຢູ່ທົ່ວທຸກແຫ່ງ, ເຖິງແມ່ນວ່າໃນສະຖານທີ່ທີ່ງ່າຍທີ່ສຸດ.

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

ສອງບອກວ່າພວກເຮົາບໍ່ສາມາດອອກຈາກສະຖານະການແບບນັ້ນໄດ້.

ພວກເຮົາສາມາດຄິດໄລ່ CPM ໄດ້ແນວໃດຖ້າພວກເຮົາບໍ່ແນ່ໃຈວ່າຜະລິດຕະພັນຖືກສະແດງ? CTR ທີ່ມີຄຸນວຸດທິ ສຳ ລັບຮູບນັ້ນແມ່ນຫຍັງ?

ນັກກາລະຕະຫຼາດຕອບວ່າ:

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

ແລະຫຼັງຈາກນັ້ນນັກພັດທະນາຈະເວົ້າວ່າ:

ແມ່ນແລ້ວ, ພວກເຮົາສາມາດແກ້ໄຂບັນຫານີ້ໄດ້ໂດຍການຊ່ວຍເຫຼືອຂອງການເຊື່ອມໂຍງແບບ ໃໝ່ ຂອງພວກເຮົາ ສຳ ລັບການຕິດຕາມການເລື່ອນພາບແລະການກວດສອບການເບິ່ງເຫັນຫົວຂໍ້.

ສຸດທ້າຍ, ນັກອອກແບບ UI / UX ກ່າວວ່າ:

ເອີ້! ພວກເຮົາສາມາດເລືອກໄດ້ຖ້າຫາກວ່າພວກເຮົາຕ້ອງການເລື່ອນຫລືການເລື່ອນຊັ້ນໃນທີ່ສຸດ!

ນີ້ແມ່ນບາດກ້າວທີ່ທີມນ້ອຍໆນີ້ໄດ້ຜ່ານ:

  1. ກຳ ນົດບັນຫາ
  2. ນຳ ສະ ເໜີ ຜົນສະທ້ອນທາງທຸລະກິດຂອງບັນຫາ
  3. ການວັດແທກຜົນກະທົບຂອງການປ່ຽນແປງ
  4. ນຳ ສະ ເໜີ ການຕັດສິນໃຈດ້ານເຕັກນິກ
  5. ຄົ້ນພົບຜົນ ກຳ ໄລທີ່ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ

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

align ປັບການອອກແບບ

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

ທ່ານຄິດແນວໃດ?

ເວັບໄຊທ໌ນີ້ໃຊ້ Akismet ເພື່ອຫຼຸດຜ່ອນການຂີ້ເຫຍື້ອ. ຮຽນຮູ້ວິທີທີ່ຂໍ້ມູນຂອງທ່ານຖືກປະຕິບັດ.