ປຶ້ມ “ວິທີການຄຸ້ມຄອງປັນຍາຊົນ. ຂ້ອຍ, nerds ແລະ geeks"

ອຸທິດຕົນໃຫ້ແກ່ຜູ້ຈັດການໂຄງການ (ແລະຜູ້ທີ່ຝັນຢາກເປັນນາຍຈ້າງ).

ການ​ຂຽນ​ລະ​ຫັດ​ຫຼາຍ​ໂຕນ​ແມ່ນ​ຍາກ​, ແຕ່​ການ​ຄຸ້ມ​ຄອງ​ຄົນ​ແມ່ນ​ຍາກ​ກວ່າ​! ສະນັ້ນທ່ານພຽງແຕ່ຕ້ອງການປື້ມນີ້ເພື່ອຮຽນຮູ້ວິທີການເຮັດທັງສອງ.

ມັນເປັນໄປໄດ້ທີ່ຈະສົມທົບເລື່ອງຕະຫລົກແລະບົດຮຽນທີ່ຮ້າຍແຮງ? Michael Lopp (ເອີ້ນກັນວ່າໃນວົງແຄບເປັນ Rands) ປະສົບຜົນສໍາເລັດ. ເຈົ້າຈະພົບເຫັນເລື່ອງນິຍາຍກ່ຽວກັບຄົນສົມມຸດດ້ວຍປະສົບການທີ່ໃຫ້ລາງວັນຢ່າງບໍ່ໜ້າເຊື່ອ (ເຖິງແມ່ນວ່າຈະສົມມຸດ). ນີ້ແມ່ນວິທີທີ່ Rands ແບ່ງປັນປະສົບການທີ່ຫຼາກຫຼາຍຂອງລາວ, ບາງຄັ້ງທີ່ແປກປະຫຼາດທີ່ໄດ້ຮັບໃນໄລຍະປີຂອງການເຮັດວຽກໃນບໍລິສັດ IT ຂະຫນາດໃຫຍ່: Apple, Pinterest, Palantir, Netscape, Symantec, ແລະອື່ນໆ.

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

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

ຫຍໍ້ມາຈາກ. ຈິດ​ໃຈ​ວິ​ສະ​ວະ​ກໍາ​

ຄວາມຄິດກ່ຽວກັບ: ເຈົ້າຄວນສືບຕໍ່ຂຽນລະຫັດບໍ?

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

ຢູ່ປ່ຽນແປງໄດ້!

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

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

ຢຸດຂຽນລະຫັດ!

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

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

ຄໍາແນະນໍາທີ່ດີ, ບໍ່ແມ່ນບໍ? ຂະໜາດ. ການຄຸ້ມຄອງ. ຄວາມຮັບຜິດຊອບ. buzzwords ທົ່ວໄປດັ່ງກ່າວ. ມັນເປັນການເສຍໃຈທີ່ຄໍາແນະນໍາແມ່ນຜິດພາດ.

ບໍ່ຖືກຕ້ອງ?

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

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

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

ນັກພັດທະນາໄດ້ເຮັດຫຍັງໃນ 20 ປີທີ່ຜ່ານມາ? ໃນລະຫວ່າງເວລານີ້ພວກເຮົາຂຽນລະຫັດ shitload. ທະເລຂອງລະຫັດ! ພວກເຮົາຂຽນລະຫັດຫຼາຍດັ່ງນັ້ນພວກເຮົາຕັດສິນໃຈວ່າມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະເຮັດໃຫ້ທຸກສິ່ງທຸກຢ່າງງ່າຍດາຍແລະໄປ open source.

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

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

ເສັ້ນຂອງເຫດຜົນນີ້ສຽງທີ່ຫນ້າເສົ້າໃຈ, ແຕ່ຄວາມຄິດແມ່ນວ່າພວກເຮົາທັງຫມົດແມ່ນພຽງແຕ່ຊໍ່ຂອງ automata ປະສົມປະສານໂດຍໃຊ້ tape duct ເພື່ອເຊື່ອມຕໍ່ bits ທີ່ແຕກຕ່າງກັນຂອງສິ່ງທີ່ມີຢູ່ແລ້ວຮ່ວມກັນເພື່ອສ້າງສະບັບທີ່ແຕກຕ່າງກັນເລັກນ້ອຍຂອງສິ່ງດຽວກັນ. ນີ້ແມ່ນແນວຄິດແບບຄລາສສິກໃນບັນດາຜູ້ບໍລິຫານລະດັບສູງທີ່ມັກການຈ້າງງານ. “ໃຜກໍຕາມທີ່ຮູ້ວິທີການໃຊ້ Google ແລະມີ tape duct ສາມາດເຮັດໄດ້! ແລ້ວເປັນຫຍັງພວກເຮົາຈຶ່ງຈ່າຍເງິນຫຼາຍໃຫ້ກັບເຄື່ອງຈັກຂອງພວກເຮົາ?”

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

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

ຢຸດການຂຽນລະຫັດ, ແຕ່ ...

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

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

ທ່ານ​ມີ​ການ​ຄັດ​ຄ້ານ​. ເຂົ້າໃຈ. ເຊີນຟັງ.

“Rands, ຂ້ອຍ ກຳ ລັງເດີນທາງໄປຫາປະທານຂອງຜູ້ອໍານວຍການ! ຖ້າຂ້ອຍສືບຕໍ່ຂຽນລະຫັດ, ບໍ່ມີໃຜຈະເຊື່ອວ່າຂ້ອຍສາມາດເຕີບໃຫຍ່ໄດ້.”

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

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

“ເອີ, Rands! ແຕ່​ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ​ຕ້ອງ​ເປັນ​ຜູ້​ຕັດ​ສິນ​! ບາງຄົນຕ້ອງເບິ່ງຮູບໃຫຍ່. ຖ້າຂ້ອຍຂຽນລະຫັດ, ຂ້ອຍຈະສູນເສຍທັດສະນະ."

ເຈົ້າຍັງຕ້ອງເປັນຜູ້ຕັດສິນ, ເຈົ້າຍັງຕ້ອງອອກອາກາດຄຳຕັດສິນ, ແລະເຈົ້າຍັງຕ້ອງຍ່າງອ້ອມຕຶກສີ່ເທື່ອໃນທຸກໆຕອນເຊົ້າວັນຈັນກັບນັກວິສະວະກອນຂອງເຈົ້າເພື່ອຟັງສຽງຮ້ອງທຸກອາທິດວ່າ "We're all doomed" ລາວ 30 ເທື່ອ. ນາທີ.! ແຕ່ນອກເຫນືອຈາກນັ້ນ, ທ່ານຕ້ອງຮັກສາແນວຄວາມຄິດດ້ານວິສະວະກໍາ, ແລະທ່ານບໍ່ຈໍາເປັນຕ້ອງເປັນນັກຂຽນໂປລແກລມເຕັມເວລາເພື່ອເຮັດສິ່ງນັ້ນ.

ຄໍາແນະນໍາຂອງຂ້ອຍສໍາລັບການຮັກສາຈິດໃຈທາງວິສະວະກໍາ:

1. ໃຊ້ສະພາບແວດລ້ອມການພັດທະນາ. ນີ້ຫມາຍຄວາມວ່າທ່ານຄວນຄຸ້ນເຄີຍກັບເຄື່ອງມືຂອງທີມງານຂອງທ່ານ, ລວມທັງລະບົບການສ້າງລະຫັດ, ການຄວບຄຸມເວີຊັນ, ແລະພາສາການຂຽນໂປຼແກຼມ. ດັ່ງນັ້ນ, ທ່ານຈະກາຍເປັນຄວາມຊໍານານໃນພາສາທີ່ທີມງານຂອງທ່ານໃຊ້ໃນເວລາທີ່ເວົ້າກ່ຽວກັບການພັດທະນາຜະລິດຕະພັນ. ນີ້ຍັງຈະຊ່ວຍໃຫ້ທ່ານສາມາດສືບຕໍ່ໃຊ້ຕົວແກ້ໄຂຂໍ້ຄວາມທີ່ທ່ານມັກ, ເຊິ່ງເຮັດວຽກຢ່າງສົມບູນ.
2. ເຈົ້າຕ້ອງສາມາດແຕ້ມແຜນວາດສະຖາປັດຕະຍະກຳລະອຽດທີ່ອະທິບາຍຜະລິດຕະພັນຂອງເຈົ້າຢູ່ເທິງພື້ນຜິວໄດ້ທຸກເວລາ. ຕອນນີ້ຂ້ອຍບໍ່ໄດ້ຫມາຍຄວາມວ່າສະບັບທີ່ງ່າຍດາຍທີ່ມີສາມຈຸລັງແລະສອງລູກສອນ. ທ່ານຕ້ອງຮູ້ແຜນວາດລາຍລະອຽດຂອງຜະລິດຕະພັນ. ຄວາມຫຍຸ້ງຍາກທີ່ສຸດ. ບໍ່​ພຽງ​ແຕ່​ແຜນ​ວາດ​ທີ່​ໜ້າ​ຮັກ​ເທົ່າ​ນັ້ນ, ແຕ່​ເປັນ​ແຜນ​ວາດ​ທີ່​ຍາກ​ທີ່​ຈະ​ອະ​ທິ​ບາຍ. ມັນຄວນຈະເປັນແຜນທີ່ທີ່ເຫມາະສົມສໍາລັບຄວາມເຂົ້າໃຈຢ່າງສົມບູນກ່ຽວກັບຜະລິດຕະພັນ. ມັນມີການປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງ, ແລະທ່ານສະເຫມີຄວນຮູ້ວ່າເປັນຫຍັງການປ່ຽນແປງບາງຢ່າງເກີດຂຶ້ນ.
3. ຍຶດ​ເອົາ​ການ​ປະ​ຕິ​ບັດ​ຫນ້າ​ທີ່​ຫນຶ່ງ​. ຂ້າ​ພະ​ເຈົ້າ​ຮູ້​ສຶກ​ຕື່ນ​ເຕັ້ນ​ທີ່​ຂຽນ​ນີ້​ເນື່ອງ​ຈາກ​ວ່າ​ຈຸດ​ນີ້​ມີ​ຫຼາຍ​ອັນ​ຕະ​ລາຍ​ທີ່​ເຊື່ອງ​ໄວ້​, ແຕ່​ຂ້າ​ພະ​ເຈົ້າ​ກໍ່​ບໍ່​ແນ່​ໃຈວ່​າ​ທ່ານ​ສາ​ມາດ​ເຮັດ​ໄດ້​ຈຸດ #1 ແລະ​ຈຸດ #2 ໂດຍ​ບໍ່​ມີ​ການ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ໃນ​ການ​ປະ​ຕິ​ບັດ​ຢ່າງ​ຫນ້ອຍ​ຫນຶ່ງ​ຄຸນ​ສົມ​ບັດ​. ໂດຍການປະຕິບັດຫນຶ່ງໃນລັກສະນະຕົວທ່ານເອງ, ບໍ່ພຽງແຕ່ທ່ານຈະມີສ່ວນຮ່ວມຢ່າງຫ້າວຫັນໃນຂະບວນການພັດທະນາ, ມັນຍັງຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນຈາກບົດບາດຂອງ "ຜູ້ຈັດການທີ່ຮັບຜິດຊອບທຸກຢ່າງ" ໄປສູ່ບົດບາດຂອງ "ຜູ້ຊາຍທີ່ຮັບຜິດຊອບໃນການປະຕິບັດຫນຶ່ງ. ຂອງ​ໜ້າ​ທີ່.” ທັດສະນະຄະຕິທີ່ຖ່ອມຕົວແລະບໍ່ຕັ້ງໃຈນີ້ຈະເຕືອນເຈົ້າກ່ຽວກັບຄວາມສໍາຄັນຂອງການຕັດສິນໃຈຂະຫນາດນ້ອຍ.
4. ຂ້ອຍຍັງສັ່ນຢູ່ຕະຫຼອດ. ເບິ່ງຄືວ່າມີຄົນຮ້ອງໃສ່ຂ້ອຍຢູ່ແລ້ວວ່າ: "ຜູ້ຈັດການທີ່ເອົາຕົວເອງປະຕິບັດຫນ້າທີ່?! (ແລະຂ້ອຍເຫັນດີກັບລາວ!) ແມ່ນແລ້ວ, ເຈົ້າຍັງເປັນຜູ້ຈັດການ, ຊຶ່ງຫມາຍຄວາມວ່າມັນຄວນຈະເປັນບາງຫນ້າທີ່ນ້ອຍໆ, ໂອເຄ? ແມ່ນແລ້ວ, ເຈົ້າຍັງມີຫຼາຍຢ່າງທີ່ຕ້ອງເຮັດ. ຖ້າທ່ານບໍ່ສາມາດປະຕິບັດຫນ້າທີ່ໄດ້, ຂ້ອຍມີຄໍາແນະນໍາສໍາຮອງສໍາລັບທ່ານ: ແກ້ໄຂບາງຂໍ້ບົກພ່ອງ. ໃນກໍລະນີນີ້, ທ່ານຈະບໍ່ຮູ້ສຶກເຖິງຄວາມສຸກຂອງການສ້າງ, ແຕ່ທ່ານຈະມີຄວາມເຂົ້າໃຈກ່ຽວກັບວິທີການສ້າງຜະລິດຕະພັນ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານຈະບໍ່ຖືກປະຖິ້ມຈາກການເຮັດວຽກ.
5. ຂຽນ​ບົດ​ທົດ​ສອບ​ຫົວ​ຫນ່ວຍ​. ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ເຮັດ​ແນວ​ນີ້​ຊັກ​ຊ້າ​ໃນ​ວົງ​ຈອນ​ການ​ຜະ​ລິດ​ໃນ​ເວ​ລາ​ທີ່​ປະ​ຊາ​ຊົນ​ເລີ່ມ​ເປັນ​ບ້າ. ຄິດວ່າມັນເປັນລາຍການກວດສຸຂະພາບສໍາລັບຜະລິດຕະພັນຂອງທ່ານ. ເຮັດແບບນີ້ເລື້ອຍໆ.

ຄັດຄ້ານອີກບໍ?

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

ດີ.

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

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

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

ຢ່າຢຸດການພັດທະນາ

ເພື່ອນຮ່ວມງານຂອງຂ້ອຍຢູ່ Borland ຄັ້ງຫນຶ່ງໄດ້ໂຈມຕີຂ້ອຍດ້ວຍຄໍາເວົ້າທີ່ເອີ້ນນາງວ່າ "ນັກຂຽນລະຫັດ."

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

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

ສະນັ້ນຂ້ອຍໄດ້ປັບປຸງຄໍາແນະນໍາຂອງຂ້ອຍ. ຖ້າທ່ານຕ້ອງການເປັນຜູ້ນໍາທີ່ດີ, ທ່ານສາມາດຢຸດການຂຽນລະຫັດ, ແຕ່ ...

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

ກ່ຽວກັບຜູ້ຂຽນ

Michael Lopp ເປັນນັກພັດທະນາຊໍແວທີ່ເປັນນັກຮົບເກົ່າທີ່ຍັງບໍ່ອອກຈາກ Silicon Valley. ໃນໄລຍະ 20 ປີທີ່ຜ່ານມາ, Michael ໄດ້ເຮັດວຽກໃຫ້ກັບບໍລິສັດທີ່ມີນະວັດຕະກໍາທີ່ຫຼາກຫຼາຍ, ລວມທັງ Apple, Netscape, Symantec, Borland, Palantir, Pinterest, ແລະຍັງໄດ້ເຂົ້າຮ່ວມໃນການເລີ່ມຕົ້ນທີ່ຄ່ອຍໆເລື່ອນລົງໄປ.

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

Michael ອາໄສຢູ່ກັບຄອບຄົວຂອງລາວໃນ Redwood, California. ລາວມັກຈະຊອກຫາເວລາຂີ່ລົດຖີບພູເຂົາ, ຫຼີ້ນຮອກກີ້ ແລະດື່ມເຫຼົ້າແວງແດງ, ເພາະວ່າການມີສຸຂະພາບດີແມ່ນສຳຄັນກວ່າການຫຍຸ້ງຢູ່.

» ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບປຶ້ມສາມາດເຂົ້າໄປເບິ່ງໄດ້ທີ່ ເວັບໄຊທ໌ຂອງຜູ້ເຜີຍແຜ່
» ຕາຕະລາງເນື້ອຫາ
» ບົດຄັດຫຍໍ້

ສໍາລັບ Khabrozhiteley ສ່ວນລົດ 20% ການນໍາໃຊ້ຄູປອງ - ການຄຸ້ມຄອງຄົນ

ເມື່ອຈ່າຍເງິນສໍາລັບສະບັບຂອງຫນັງສື, ສະບັບເອເລັກໂຕຣນິກຂອງຫນັງສືຈະຖືກສົ່ງໄປທາງອີເມລ.

PS: 7% ຂອງລາຄາປື້ມຈະໄປການແປພາສາປື້ມຄອມພິວເຕີໃຫມ່, ບັນຊີລາຍຊື່ຂອງປື້ມທີ່ມອບໃຫ້ໂຮງພິມ ທີ່ນີ້.

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