"ບົດລາຍງານບໍ່ມີສິດທີ່ຈະຫນ້າເບື່ອ": ການສໍາພາດກັບ Baruch Sadogursky ກ່ຽວກັບຄໍາເວົ້າໃນກອງປະຊຸມ

Baruch Sadogursky - ຜູ້ສະຫນັບສະຫນູນຜູ້ພັດທະນາຂອງ JFrog, ຜູ້ຮ່ວມຂຽນຫນັງສື "Liquid Software", ລໍາໂພງ IT ທີ່ມີຊື່ສຽງ.

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

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍງ່າຍດາຍທີ່ສຸດ. ເປັນຫຍັງເຈົ້າຄິດວ່າເວົ້າຢູ່ໃນກອງປະຊຸມທັງຫມົດ?

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

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

ກະລຸນາບອກພວກເຮົາວ່າທ່ານກະກຽມສໍາລັບການສະແດງແນວໃດ? ມີວິທີການກະກຽມບາງປະເພດບໍ?

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

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

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

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

ທ່ານເຂົ້າໃຈແນວໃດວ່າ "ຫົວຂໍ້ນີ້" ຕ້ອງໄດ້ຮັບການແກ້ໄຂ? ແລະທ່ານຈະເກັບກໍາເອກະສານສໍາລັບບົດລາຍງານແນວໃດ?

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

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

ຄໍາປາໄສຂອງ Baruch ໃນກອງປະຊຸມ DevOps Summit Amsterdam 2019 ທີ່ຜ່ານມາ

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

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

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

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

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

ທ່ານເວົ້າຫຼາຍຢູ່ໃນກອງປະຊຸມລັດເຊຍແລະສາກົນ. ເຈົ້າເຫັນຄວາມແຕກຕ່າງລະຫວ່າງບົດລາຍງານຢູ່ໃນກອງປະຊຸມລັດເຊຍແລະຕ່າງປະເທດບໍ? ມີຄວາມແຕກຕ່າງກັນໃນຜູ້ຊົມບໍ? ໃນ​ອົງ​ການ​ຈັດ​ຕັ້ງ​?

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

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

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

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

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

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

ນີ້ແມ່ນສອງຄວາມແຕກຕ່າງ.

ທ່ານໄດ້ໄປ DevOpsDays ໃນປະເທດອື່ນບໍ? ທ່ານຄິດວ່າພວກເຂົາແຕກຕ່າງຈາກກອງປະຊຸມອື່ນໆແນວໃດ? ມີຄຸນສົມບັດພິເສດບໍ?

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

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

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

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

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

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

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

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

ທ່ານມັກຄຳປາໄສຈາກສາຂາ IT ຂອງໃຜ? ມີລໍາໂພງດັ່ງກ່າວບໍ? ແລະ​ເປັນ​ຫຍັງ​ຈຶ່ງ?

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

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

ຂອງຊື່ໃນປະເພດທີສອງ, ນີ້ແມ່ນ Alexey Shepelev, ຜູ້ທີ່ເວົ້າກ່ຽວກັບການເກັບຂີ້ເຫຍື້ອທີ່ມີການປະຕິບັດຢ່າງເລິກເຊິ່ງແລະພາຍໃນຂອງເຄື່ອງ virtual java ໃນທາງທີ່ຫນ້າສົນໃຈແລະເປັນເລື່ອງຕະຫລົກ. ການຄົ້ນພົບອີກອັນຫນຶ່ງຂອງ DevOops ຫລ້າສຸດແມ່ນ Sergey Fedorov ຈາກ Netflix. ລາວບອກສິ່ງດ້ານວິຊາການອັນບໍລິສຸດກ່ຽວກັບວິທີການທີ່ພວກເຂົາເພີ່ມປະສິດທິພາບເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາຂອງພວກເຂົາ, ແລະລາວບອກມັນໃນທາງທີ່ຫນ້າສົນໃຈຫຼາຍ.

ຈາກປະເພດທໍາອິດ - ເຫຼົ່ານີ້ແມ່ນ Jessica Deen, Anton Weiss, Roman Shaposhnik. ເຫຼົ່ານີ້ແມ່ນຜູ້ເວົ້າທີ່ເວົ້າທີ່ຫນ້າສົນໃຈ, ມີຕະຫລົກ, ແລະສົມຄວນໄດ້ຮັບການຈັດອັນດັບສູງ.

ເຈົ້າອາດມີການເຊື້ອເຊີນໃຫ້ເວົ້າໃນກອງປະຊຸມຫຼາຍກວ່າເວລາທີ່ຈະເຮັດເຊັ່ນນັ້ນ. ເຈົ້າ​ເລືອກ​ບ່ອນ​ທີ່​ເຈົ້າ​ຈະ​ໄປ​ແນວ​ໃດ ແລະ​ບໍ່​ຢູ່​ໃສ?

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

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

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

ພູມສາດທີ່ດີ, ປະຊາກອນທີ່ດີ, ການພົວພັນທີ່ມີທ່າແຮງທີ່ດີ, ການສື່ສານແມ່ນການຮັບປະກັນວ່າກອງປະຊຸມຈະຫນ້າສົນໃຈກັບຂ້ອຍ.

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

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

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

ຫນຶ່ງໃນບົດລາຍງານຂອງ Baruch ແມ່ນ "ພວກເຮົາມີ DevOps. ຂໍໃຫ້ຍິງນັກທົດສອບທຸກຄົນ."

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

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

ແນ່ນອນ, ມັນອາດຈະເປັນໄປບໍ່ໄດ້ທີ່ຈະເວົ້າວ່າຂ້ອຍເປັນ coder hardcore ດຽວກັນກັບຂ້ອຍ 7 ປີກ່ອນ. ບໍ່ແນ່ໃຈວ່ານັ້ນເປັນສິ່ງທີ່ບໍ່ດີ. ນີ້ແມ່ນບາງປະເພດຂອງການວິວັດທະນາການທໍາມະຊາດ. ນີ້ເປັນສິ່ງທີ່ຫນ້າສົນໃຈຫນ້ອຍສໍາລັບຂ້ອຍ, ແລະຂ້ອຍມີເວລາຫນ້ອຍ, ດັ່ງນັ້ນ, ອາດຈະເປັນ, ພຣະເຈົ້າອວຍພອນລາວ.

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

ກະລຸນາບອກພວກເຮົາບາງເລື່ອງຕະຫລົກ ຫຼື ສະຖານະການຮ້າຍແຮງທີ່ເກີດຂຶ້ນກັບເຈົ້າ: ພາດຍົນໄປ/ລຶບການນຳສະເໜີ/ໄຟຟ້າຖືກຕັດໃນລະຫວ່າງທີ່ລາຍງານ/ກະເປົາບໍ່ມາຮອດບໍ?

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

ຂ້ອຍມີ “ໜ້າຈໍສີຟ້າແຫ່ງຄວາມຕາຍ” ຢູ່ທັງ Windows ແລະ Mac ໃນລະຫວ່າງການສົນທະນາ. ໃນ Windows ມັນ​ເກີດ​ຂຶ້ນ​ຄັ້ງ​ດຽວ​, ໃນ Mac ສອງ​ສາມ​ຄັ້ງ​. ນີ້ແມ່ນ, ແນ່ນອນ, ຄວາມກົດດັນ, ແຕ່ພວກເຮົາແກ້ໄຂບັນຫານີ້ somehow, ຄອມພິວເຕີ restarts, ຂ້າພະເຈົ້າສືບຕໍ່ບອກບາງສິ່ງບາງຢ່າງໃນເວລານີ້, ແຕ່ຄວາມກົດດັນແມ່ນ enormous.

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

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

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

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

ຫລາຍ​ຄົນ​ຄິດ​ແບບ​ນີ້: “ເປັນ​ຫຍັງ​ຈຶ່ງ​ໄປ​ປະຊຸມ? ທ່ານສາມາດເບິ່ງວິດີໂອໃນ YouTube, ແລະທ່ານສາມາດສົນທະນາອອນໄລນ໌ໄດ້ຕະຫຼອດເວລາ." ເປັນຫຍັງເຈົ້າຄິດວ່າຜູ້ເຂົ້າຮ່ວມຈໍາເປັນຕ້ອງໄປປະຊຸມ?

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

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

ແລະຂ້າພະເຈົ້າເວົ້າອີກເທື່ອຫນຶ່ງ: ເຄືອຂ່າຍແລະການສື່ສານບໍ່ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ທ່ານສາມາດເອົາຈາກ YouTube.

ບົດລາຍງານຮ່ວມກັບ Leonid Igolnik ຢູ່ DevOpsCon

ກະລຸນາໃຫ້ຄໍາເວົ້າບາງສ່ວນກັບຜູ້ທີ່ກໍາລັງວາງແຜນທີ່ຈະເປັນຜູ້ເວົ້າຫຼືຫາກໍເລີ່ມເວົ້າບໍ?

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

ນອກຈາກນີ້, ລະດັບຄວາມກົດດັນແມ່ນແຕກຕ່າງກັນຫມົດ. ເມື່ອ 10-15-30 ຄົນມາ, ມັນບໍ່ຄືກັນກັບເວລາທີ່ 150-200-300 ຄົນຢູ່ໃນຫ້ອງໂຖງ, ສະນັ້ນມັນງ່າຍຂຶ້ນຫຼາຍ.

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

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

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

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

Baruch ຈະ​ກ່າວ​ຄຳ​ປາ​ໄສ​ໃນ​ກອງ​ປະ​ຊຸມ​ໃນ​ວັນ​ທີ 7 ທັນ​ວາ​ນີ້ DevOpsDays Moscow. ໃນບົດລາຍງານຂອງລາວ, Baruch ຈະວິເຄາະຄວາມລົ້ມເຫລວທີ່ແທ້ຈິງທີ່ເກີດຂຶ້ນທຸກໆມື້ແລະຢູ່ທົ່ວທຸກແຫ່ງໃນເວລາທີ່ການປັບປຸງຊອບແວ. ມັນຈະສະແດງໃຫ້ເຫັນວ່າຮູບແບບ DevOps ທຸກຊະນິດເຂົ້າກັນໄດ້ກັບສະຖານະການຕ່າງໆແນວໃດ ແລະວິທີການນຳໃຊ້ພວກມັນຢ່າງຖືກຕ້ອງສາມາດຊ່ວຍທ່ານປະຫຍັດໄດ້.

ນອກຈາກນີ້ໃນໂຄງການ: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (ທີ່ປຶກສາ DevOps).

ມາຮູ້ຈັກ!

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