ทุ่มเทให้กับผู้จัดการโครงการ (และผู้ที่ฝันอยากเป็นเจ้านาย)
การเขียนโค้ดจำนวนมากนั้นยาก แต่การจัดการคนนั้นยากยิ่งกว่า! ดังนั้นคุณเพียงแค่ต้องมีหนังสือเล่มนี้เพื่อเรียนรู้วิธีทำทั้งสองอย่าง
เป็นไปได้ไหมที่จะรวมเรื่องตลกและบทเรียนที่จริงจังเข้าด้วยกัน? Michael Lopp (หรือที่รู้จักกันในชื่อ Rands) ประสบความสำเร็จ คุณจะพบกับเรื่องราวสมมติเกี่ยวกับผู้คนในนิยายที่มีประสบการณ์อันน่าเหลือเชื่อ (แม้ว่าจะเป็นเรื่องแต่งก็ตาม) นี่คือวิธีที่ Rands แบ่งปันประสบการณ์ที่หลากหลายและบางครั้งก็แปลกประหลาดที่ได้รับตลอดหลายปีที่ผ่านมาในการทำงานในบริษัทไอทีขนาดใหญ่ เช่น Apple, Pinterest, Palantir, Netscape, Symantec ฯลฯ
คุณเป็นผู้จัดการโครงการหรือไม่? หรือต้องการที่จะเข้าใจว่าเจ้านายเจ้ากรรมของคุณทำอะไรตลอดทั้งวัน? Rands จะสอนวิธีเอาตัวรอดในโลกที่เป็นพิษของไก่งวงที่พองตัว และเติบโตท่ามกลางความบ้าคลั่งของผู้คนที่มีสีสันสดใสผิดปกติ ในชุมชนอัจฉริยะผู้คลั่งไคล้ที่แปลกประหลาดแห่งนี้ ยังมีสิ่งมีชีวิตแปลกหน้าอีกด้วย ผู้จัดการที่ได้รับอำนาจเหนือแผน ความคิด และบัญชีธนาคารของผู้คนจำนวนมากผ่านพิธีกรรมลึกลับขององค์กร
หนังสือเล่มนี้ไม่เหมือนกับต้นฉบับด้านการจัดการหรือความเป็นผู้นำ Michael Lopp ไม่ได้ปิดบังอะไรเลย เขาแค่บอกตามที่เป็นอยู่ (บางทีเรื่องราวทั้งหมดไม่ควรเปิดเผยต่อสาธารณะ: P) แต่ด้วยวิธีนี้เท่านั้น คุณจะเข้าใจวิธีการเอาตัวรอดกับเจ้านายแบบนี้ วิธีจัดการพวกเกินบรรยายและพวกเนิร์ด และวิธีทำให้ "โปรเจ็กต์เวรนั่น" จบลงอย่างมีความสุข!
ข้อความที่ตัดตอนมา ความคิดทางวิศวกรรม
ความคิดเห็นเกี่ยวกับ : คุณควรเขียนโค้ดต่อหรือไม่?
หนังสือเกี่ยวกับกฎสำหรับผู้จัดการของ Rands มีรายการสั้นๆ เกี่ยวกับ "สิ่งที่ต้องทำ" ของการบริหารจัดการยุคใหม่ ความพูดน้อยของรายการนี้เกิดจากการที่แนวคิดเรื่อง "ต้อง" เป็นแบบสัมบูรณ์ และเมื่อพูดถึงผู้คน มีแนวคิดที่สมบูรณ์น้อยมาก วิธีการจัดการที่ประสบความสำเร็จสำหรับพนักงานคนหนึ่งจะเป็นหายนะที่แท้จริงสำหรับอีกคนหนึ่ง ความคิดนี้เป็นรายการแรกในรายการ “ต้องทำ” ของผู้จัดการ:
คงความยืดหยุ่น!
การคิดว่าคุณรู้ทุกอย่างอยู่แล้วเป็นความคิดที่แย่มาก ในสถานการณ์ที่ข้อเท็จจริงคงที่เพียงอย่างเดียวคือโลกมีการเปลี่ยนแปลงอยู่ตลอดเวลา ความยืดหยุ่นจะกลายเป็นตำแหน่งเดียวที่ถูกต้อง
ขัดแย้งกันที่รายการที่สองในรายการไม่ยืดหยุ่นอย่างน่าประหลาดใจ อย่างไรก็ตาม ประเด็นนี้เป็นประเด็นที่ฉันชอบเป็นการส่วนตัวเพราะฉันเชื่อว่าจะช่วยสร้างรากฐานสำหรับการเติบโตของผู้บริหาร ย่อหน้านี้อ่านว่า:
หยุดเขียนโค้ด!
ตามทฤษฎีแล้ว หากคุณต้องการเป็นผู้จัดการ คุณต้องเรียนรู้ที่จะไว้วางใจผู้ที่ทำงานให้กับคุณ และมอบโค้ดทั้งหมดให้กับพวกเขา คำแนะนำนี้มักจะเข้าใจได้ยาก โดยเฉพาะอย่างยิ่งสำหรับผู้จัดการที่เพิ่งก่อตั้งใหม่ อาจเป็นหนึ่งในเหตุผลที่พวกเขามาเป็นผู้จัดการก็เนื่องมาจากประสิทธิภาพการทำงานในการพัฒนา และเมื่อมีสิ่งผิดปกติเกิดขึ้น ปฏิกิริยาแรกของพวกเขาคือการถอยกลับไปใช้ทักษะที่พวกเขามีความมั่นใจอย่างเต็มที่ ซึ่งก็คือความสามารถในการเขียนโค้ด
เมื่อฉันเห็นว่าผู้จัดการที่เพิ่งก่อตั้งใหม่ “สนใจ” ในการเขียนโค้ด ฉันบอกเขาว่า: “เรารู้ว่าคุณสามารถเขียนโค้ดได้ คำถามคือ: คุณสามารถเป็นผู้นำได้หรือไม่? คุณไม่รับผิดชอบต่อตัวเองเพียงลำพังอีกต่อไป คุณต้องรับผิดชอบต่อทั้งทีม และฉันต้องการให้แน่ใจว่าคุณจะทำให้ทีมของคุณแก้ไขปัญหาได้ด้วยตัวเองโดยที่คุณไม่ต้องเขียนโค้ดด้วยตัวเอง งานของคุณคือการหาวิธีขยายขนาดตัวเอง ฉันไม่อยากให้คุณเป็นแค่คนเดียว ฉันอยากให้มีหลายคนเหมือนคุณ”
คำแนะนำที่ดีใช่ไหม? มาตราส่วน. การจัดการ. ความรับผิดชอบ. ศัพท์ธรรมดาๆ แบบนี้ น่าเสียดายที่คำแนะนำไม่ถูกต้อง
ไม่ถูกต้อง?
ใช่. คำแนะนำไม่ถูกต้อง! ไม่ผิดทั้งหมด แต่ผิดมากพอที่ฉันต้องโทรหาอดีตเพื่อนร่วมงานและขอโทษ: “จำคำพูดที่ฉันชื่นชอบเกี่ยวกับวิธีที่คุณควรหยุดเขียนโค้ดได้ไหม? มันผิด! ใช่... เริ่มเขียนโปรแกรมอีกครั้ง เริ่มต้นด้วย Python และ Ruby ใช่ ฉันจริงจัง! อาชีพของคุณขึ้นอยู่กับมัน!”
เมื่อฉันเริ่มต้นอาชีพในฐานะนักพัฒนาซอฟต์แวร์ที่ Borland ฉันทำงานในทีม Paradox Windows ซึ่งเป็นทีมขนาดใหญ่ มีนักพัฒนาแอปพลิเคชันเพียง 13 คนเท่านั้น หากคุณเพิ่มบุคคลจากทีมอื่นๆ ที่ทำงานอย่างต่อเนื่องเกี่ยวกับเทคโนโลยีหลักสำหรับโปรเจ็กต์นี้ เช่น โปรแกรมฐานข้อมูลหลักและบริการแอปพลิเคชันหลัก คุณจะมีวิศวกร 50 คนที่เกี่ยวข้องโดยตรงในการพัฒนาผลิตภัณฑ์นี้
ไม่มีทีมอื่นใดที่ฉันเคยทำงานด้วยที่จะมีขนาดใกล้เคียงกันขนาดนี้ ในความเป็นจริง ในแต่ละปีที่ผ่านมา จำนวนคนในทีมที่ฉันทำงานอยู่ก็ค่อยๆ ลดลง เกิดอะไรขึ้น? เราเป็นนักพัฒนาที่ฉลาดขึ้นและฉลาดขึ้นโดยรวมหรือไม่? ไม่ เราแค่แบ่งเบาภาระเท่านั้น
นักพัฒนาซอฟต์แวร์ทำอะไรในช่วง 20 ปีที่ผ่านมา? ในช่วงเวลานี้เราเขียนโค้ดจำนวนมหาศาล ทะเลแห่งรหัส! เราเขียนโค้ดมากมายจนตัดสินใจว่าจะเป็นความคิดที่ดีที่จะลดความซับซ้อนของทุกอย่างและหันมาใช้โอเพ่นซอร์ส
โชคดีที่มีอินเทอร์เน็ต กระบวนการนี้จึงกลายเป็นเรื่องง่ายที่สุดเท่าที่จะเป็นไปได้ หากคุณเป็นนักพัฒนาซอฟต์แวร์ คุณสามารถตรวจสอบได้เลย! ค้นหาชื่อของคุณบน Google หรือ Github แล้วคุณจะเห็นโค้ดที่คุณลืมไปนานแล้ว แต่ใครๆ ก็ค้นพบได้ น่ากลัวใช่มั้ย? คุณไม่รู้เหรอว่าโค้ดนั้นคงอยู่ตลอดไป? ใช่แล้ว เขามีชีวิตอยู่ตลอดไป
รหัสจะคงอยู่ตลอดไป และโค้ดที่ดีไม่เพียงแต่จะคงอยู่ตลอดไปเท่านั้น แต่ยังเติบโตเพราะผู้ที่ให้ความสำคัญกับมันอย่างต่อเนื่องจะทำให้มั่นใจว่ามันยังคงความสดใหม่อยู่เสมอ กองโค้ดคุณภาพสูงและได้รับการดูแลอย่างดีนี้จะช่วยลดขนาดทีมวิศวกรโดยเฉลี่ย เนื่องจากช่วยให้เรามุ่งเน้นไปที่โค้ดที่มีอยู่แทนที่จะเขียนโค้ดใหม่ และทำงานได้สำเร็จโดยใช้คนน้อยลงและในกรอบเวลาที่สั้นลง
การให้เหตุผลแนวนี้ฟังดูน่าหดหู่ แต่แนวคิดก็คือเราทุกคนเป็นเพียงกลุ่มออโตมาตะบูรณาการโดยใช้เทปพันท่อเพื่อเชื่อมต่อส่วนต่างๆ ของสิ่งที่มีอยู่เข้าด้วยกันเพื่อสร้างสิ่งเดียวกันในเวอร์ชันที่แตกต่างออกไปเล็กน้อย นี่เป็นแนวความคิดแบบคลาสสิกในหมู่ผู้บริหารระดับสูงที่รักการเอาท์ซอร์ส “ใครก็ตามที่รู้วิธีใช้ Google และมีเทปพันสายไฟก็สามารถทำได้! แล้วทำไมเราถึงต้องจ่ายเงินจำนวนมากให้กับเครื่องจักรของเราล่ะ?”
เราจ่ายเงินให้ผู้บริหารเหล่านี้เป็นจำนวนมาก แต่พวกเขากลับคิดว่าไร้สาระเช่นนั้น ประเด็นสำคัญของฉันอีกครั้งคือมีนักพัฒนาที่เก่งและทำงานหนักมากมายบนโลกของเรา พวกเขาเก่งและขยันอย่างแท้จริง แม้ว่าพวกเขาจะไม่ได้ใช้เวลาแม้แต่นาทีเดียวในการนั่งอยู่ในมหาวิทยาลัยที่ได้รับการรับรองก็ตาม โอ้ใช่แล้ว ตอนนี้มีพวกมันเพิ่มมากขึ้นเรื่อยๆ!
ฉันไม่แนะนำให้คุณเริ่มกังวลเกี่ยวกับสถานที่ของคุณเพียงเพราะว่าสหายที่เก่งบางคนกำลังตามล่าหามัน ฉันขอแนะนำให้คุณเริ่มกังวลเรื่องนี้เพราะวิวัฒนาการของการพัฒนาซอฟต์แวร์น่าจะดำเนินไปเร็วกว่าที่คุณเป็น คุณทำงานมาสิบปีแล้ว โดยห้าปีเป็นผู้จัดการ และคุณคิดว่า: "ฉันรู้แล้วว่าซอฟต์แวร์ได้รับการพัฒนาอย่างไร" ใช่คุณรู้. ลาก่อน…
หยุดเขียนโค้ด แต่...
หากคุณปฏิบัติตามคำแนะนำเดิมของฉันและหยุดเขียนโค้ด คุณจะหยุดเข้าร่วมในกระบวนการสร้างโดยสมัครใจด้วย ด้วยเหตุนี้ฉันจึงไม่ได้ใช้บริการเอาท์ซอร์สอย่างจริงจัง ออโตมาตะไม่ได้สร้าง แต่พวกมันผลิต กระบวนการที่ออกแบบมาอย่างดีช่วยประหยัดเงินได้มาก แต่ไม่ได้นำสิ่งใหม่มาสู่โลกของเรา
หากคุณมีทีมเล็กๆ ที่ทำเงินได้มากแต่น้อย ความคิดในการหยุดเขียนโค้ดก็ดูเหมือนเป็นการตัดสินใจทางอาชีพที่ไม่ดีสำหรับฉัน แม้แต่ในบริษัทยักษ์ใหญ่ที่มีกฎระเบียบ กระบวนการ และนโยบายที่ไม่มีที่สิ้นสุด คุณไม่มีสิทธิ์ลืมวิธีพัฒนาซอฟต์แวร์ด้วยตัวเอง และการพัฒนาซอฟต์แวร์ก็เปลี่ยนแปลงอยู่ตลอดเวลา มันกำลังเปลี่ยนแปลงอยู่ในขณะนี้ ใต้ฝ่าเท้าของคุณ! ในวินาทีนี้เอง!
คุณมีข้อโต้แย้ง เข้าใจ. มาฟังกันดีกว่า
“แรนด์ส ฉันกำลังจะไปนั่งเก้าอี้ผู้กำกับแล้ว! ถ้าฉันเขียนโค้ดต่อไป จะไม่มีใครเชื่อว่าฉันสามารถเติบโตได้”
ฉันอยากจะถามคุณว่า เนื่องจากคุณนั่งเก้าอี้ “ฉันกำลังจะเป็น CEO!” คุณสังเกตไหมว่าภาพรวมการพัฒนาซอฟต์แวร์กำลังเปลี่ยนแปลง แม้แต่ภายในบริษัทของคุณ หากคำตอบของคุณคือใช่ ฉันจะถามคำถามอื่นกับคุณ: มีการเปลี่ยนแปลงอย่างไร และคุณจะทำอย่างไรกับการเปลี่ยนแปลงเหล่านี้ หากคุณตอบว่า "ไม่" ในคำถามแรกของฉัน คุณจะต้องย้ายไปที่เก้าอี้ตัวอื่น เพราะ (ฉันพนันได้เลยว่า!) ขอบเขตการพัฒนาซอฟต์แวร์กำลังเปลี่ยนแปลงไปในวินาทีนี้ คุณจะเติบโตได้อย่างไรถ้าคุณลืมวิธีพัฒนาซอฟต์แวร์อย่างช้าๆ แต่ชัวร์?
คำแนะนำของฉันคืออย่าให้คำมั่นสัญญากับตัวเองในการใช้ฟีเจอร์มากมายสำหรับผลิตภัณฑ์ถัดไปของคุณ คุณต้องดำเนินการอย่างต่อเนื่องเพื่อติดตามวิธีที่ทีมของคุณสร้างซอฟต์แวร์ คุณสามารถทำเช่นนี้ได้ทั้งในฐานะผู้อำนวยการและรองประธาน อื่น ๆ อีก?
“เอ่อ แรนด์ส! แต่ก็ต้องมีคนตัดสิน! บางคนต้องเห็นภาพใหญ่ ถ้าฉันเขียนโค้ด ฉันจะสูญเสียมุมมอง"
คุณยังต้องเป็นผู้ตัดสิน คุณยังต้องออกอากาศการตัดสิน และคุณยังต้องเดินไปรอบ ๆ อาคารสี่ครั้งทุกเช้าวันจันทร์กับวิศวกรของคุณเพื่อฟังคำพูดโวยวาย "เราทุกคนถึงวาระ" รายสัปดาห์ของเขาในราคา 30 นาที. ! แต่เหนือสิ่งอื่นใด คุณต้องรักษากรอบความคิดทางวิศวกรรม และคุณไม่จำเป็นต้องเป็นโปรแกรมเมอร์เต็มเวลาเพื่อที่จะทำเช่นนั้น
เคล็ดลับของฉันในการรักษาความคิดทางวิศวกรรม:
- ใช้สภาพแวดล้อมการพัฒนา ซึ่งหมายความว่าคุณควรคุ้นเคยกับเครื่องมือของทีม รวมถึงระบบการสร้างโค้ด การควบคุมเวอร์ชัน และภาษาการเขียนโปรแกรม ผลลัพธ์ก็คือ คุณจะคล่องแคล่วในภาษาที่ทีมของคุณใช้เมื่อพูดถึงการพัฒนาผลิตภัณฑ์ นอกจากนี้ยังช่วยให้คุณใช้โปรแกรมแก้ไขข้อความที่คุณชื่นชอบต่อไปได้ ซึ่งทำงานได้อย่างสมบูรณ์
- คุณต้องสามารถวาดแผนภาพสถาปัตยกรรมโดยละเอียดเพื่ออธิบายผลิตภัณฑ์ของคุณบนพื้นผิวใดๆ ได้ตลอดเวลา ตอนนี้ฉันไม่ได้หมายถึงเวอร์ชันที่เรียบง่ายที่มีสามเซลล์และลูกศรสองอัน คุณต้องทราบแผนภาพโดยละเอียดของผลิตภัณฑ์ อันที่ยากที่สุด ไม่ใช่แค่ไดอะแกรมที่น่ารัก แต่เป็นไดอะแกรมที่อธิบายได้ยาก ควรเป็นแผนที่ที่เหมาะสมต่อการทำความเข้าใจผลิตภัณฑ์ให้ครบถ้วน มันเปลี่ยนแปลงอยู่ตลอดเวลา และคุณควรรู้เสมอว่าเหตุใดจึงเกิดการเปลี่ยนแปลงบางอย่าง
- เข้ามารับหน้าที่ดำเนินการอย่างใดอย่างหนึ่ง ฉันรู้สึกสะดุ้งขณะเขียนสิ่งนี้เพราะประเด็นนี้มีอันตรายซ่อนเร้นอยู่มากมาย แต่ฉันไม่แน่ใจจริงๆ ว่าคุณจะทำจุดที่ 1 และจุดที่ 2 ให้สำเร็จได้โดยไม่ต้องดำเนินการติดตั้งฟีเจอร์อย่างน้อยหนึ่งรายการ ด้วยการใช้คุณสมบัติอย่างใดอย่างหนึ่งด้วยตัวคุณเอง ไม่เพียงแต่คุณจะมีส่วนร่วมอย่างแข็งขันในกระบวนการพัฒนาเท่านั้น แต่ยังช่วยให้คุณเปลี่ยนจากบทบาทของ "ผู้จัดการที่รับผิดชอบทุกอย่าง" เป็นระยะ ๆ เป็นบทบาทของ "คนที่รับผิดชอบในการดำเนินการอย่างใดอย่างหนึ่ง ของฟังก์ชัน” ทัศนคติที่ถ่อมตัวและไม่สุภาพนี้จะเตือนคุณถึงความสำคัญของการตัดสินใจเล็กๆ น้อยๆ
- ฉันยังคงสั่นไปทั้งตัว ดูเหมือนว่ามีคนตะโกนใส่ฉันแล้ว: “ผู้จัดการที่รับหน้าที่นี้เองเหรอ! (และฉันเห็นด้วยกับเขา!) ใช่ คุณยังคงเป็นผู้จัดการ ซึ่งหมายความว่ามันควรจะเป็นงานเล็กๆ น้อยๆ โอเคไหม? ใช่ คุณยังมีอีกมากที่ต้องทำ หากคุณไม่สามารถใช้งานฟังก์ชันนี้ได้ ฉันมีคำแนะนำสำรองสำหรับคุณ: แก้ไขข้อบกพร่องบางอย่าง ในกรณีนี้ คุณจะไม่รู้สึกถึงความสุขในการสร้างสรรค์ แต่คุณจะมีความเข้าใจว่าผลิตภัณฑ์ถูกสร้างขึ้นมาอย่างไร ซึ่งหมายความว่าคุณจะไม่มีวันถูกทิ้งงาน
- เขียนการทดสอบหน่วย ฉันยังคงทำสิ่งนี้ในช่วงปลายของวงจรการผลิต เมื่อผู้คนเริ่มคลั่งไคล้ ให้คิดว่าเป็นรายการตรวจสอบสุขภาพสำหรับผลิตภัณฑ์ของคุณ ทำเช่นนี้บ่อยๆ
ค้านอีกแล้วเหรอ?
“แรนด์ ถ้าฉันเขียนโค้ด ฉันจะทำให้ทีมของฉันสับสน พวกเขาจะไม่รู้ว่าฉันเป็นใคร ทั้งเป็นผู้จัดการหรือนักพัฒนา”
ทั้งหมดขวา
ใช่ ฉันพูดว่า "โอเค!" ฉันดีใจที่คุณคิดว่าคุณสามารถสร้างความสับสนให้ทีมของคุณเพียงแค่ว่ายน้ำในบ่อนักพัฒนา ง่ายมาก: ขอบเขตระหว่างบทบาทที่แตกต่างกันในการพัฒนาซอฟต์แวร์ในปัจจุบันยังไม่ชัดเจนนัก พวก UI ทำสิ่งที่เรียกกันทั่วไปว่าการเขียนโปรแกรม JavaScript และ CSS นักพัฒนาซอฟต์แวร์กำลังเรียนรู้เกี่ยวกับการออกแบบประสบการณ์ผู้ใช้มากขึ้นเรื่อยๆ ผู้คนสื่อสารกันและเรียนรู้เกี่ยวกับจุดบกพร่อง เกี่ยวกับการขโมยรหัสของผู้อื่น และข้อเท็จจริงที่ว่าไม่มีเหตุผลที่ดีสำหรับผู้จัดการที่จะไม่เข้าร่วมในข้อมูลแบ็คชานาเลียที่ผสมเกสรข้ามโลกจำนวนมหาศาลนี้
นอกจากนี้ คุณต้องการเป็นส่วนหนึ่งของทีมที่ประกอบด้วยส่วนประกอบที่เปลี่ยนได้ง่ายหรือไม่? สิ่งนี้ไม่เพียงแค่ทำให้ทีมของคุณคล่องตัวมากขึ้น แต่ยังเปิดโอกาสให้สมาชิกในทีมแต่ละคนได้เห็นผลิตภัณฑ์และบริษัทจากมุมมองที่หลากหลาย คุณจะให้ความเคารพ Frank ชายผู้ใจเย็นที่ดูแลงานสร้างได้อย่างไร นอกเหนือจากการได้เห็นความสง่างามที่เรียบง่ายของสคริปต์งานสร้างของเขาแล้ว
ฉันไม่ต้องการให้ทีมของคุณสับสนและวุ่นวาย ในทางตรงกันข้าม ฉันต้องการให้ทีมของคุณสื่อสารได้อย่างมีประสิทธิภาพมากขึ้น ฉันเชื่อว่าหากคุณมีส่วนร่วมในการสร้างผลิตภัณฑ์และการทำงานเกี่ยวกับคุณสมบัติต่างๆ คุณจะใกล้ชิดกับทีมของคุณมากขึ้น และที่สำคัญกว่านั้น คุณจะใกล้ชิดกับการเปลี่ยนแปลงกระบวนการพัฒนาซอฟต์แวร์ภายในองค์กรของคุณอย่างต่อเนื่อง
อย่าหยุดพัฒนา
เพื่อนร่วมงานของฉันที่ Borland เคยโจมตีฉันด้วยวาจาที่เรียกเธอว่า "ผู้เขียนโค้ด"
“แรนด์ คนเขียนโค้ดเป็นเครื่องจักรที่ไร้เหตุผล! ลิง! ผู้เขียนโค้ดไม่ได้ทำอะไรที่สำคัญนอกจากเขียนโค้ดที่น่าเบื่อและไร้ประโยชน์ ฉันไม่ใช่ผู้เขียนโค้ด ฉันเป็นนักพัฒนาซอฟต์แวร์!”
เธอพูดถูก เธอคงเกลียดคำแนะนำเริ่มแรกของฉันที่ให้กับซีอีโอคนใหม่: “หยุดเขียนโค้ดซะ!” ไม่ใช่เพราะฉันกำลังแนะนำว่าพวกเขาเป็นผู้เขียนโค้ด แต่เป็นเพราะฉันแนะนำเชิงรุกว่าพวกเขาเริ่มเพิกเฉยต่อส่วนที่สำคัญที่สุดอย่างหนึ่งในงานของพวกเขา: การพัฒนาซอฟต์แวร์
ดังนั้นฉันจึงได้ปรับปรุงคำแนะนำของฉัน อยากเป็นผู้นำที่ดีก็เลิกเขียนโค้ดได้ แต่...
มีความยืดหยุ่น จำไว้ว่าการเป็นวิศวกรหมายความว่าอย่างไร และอย่าหยุดพัฒนาซอฟต์แวร์
เกี่ยวกับผู้แต่ง
Michael Lopp เป็นนักพัฒนาซอฟต์แวร์รุ่นเก๋าที่ยังไม่ออกจาก Silicon Valley ในช่วง 20 ปีที่ผ่านมา Michael ทำงานให้กับบริษัทนวัตกรรมต่างๆ มากมาย รวมถึง Apple, Netscape, Symantec, Borland, Palantir, Pinterest และยังได้มีส่วนร่วมในสตาร์ทอัพที่ค่อย ๆ ลอยไปสู่การลืมเลือน
นอกเหนือจากงาน Michael ยังจัดทำบล็อกยอดนิยมเกี่ยวกับเทคโนโลยีและการจัดการภายใต้นามแฝง Rands ซึ่งเขาอภิปรายแนวคิดในด้านการจัดการกับผู้อ่าน แสดงความกังวลเกี่ยวกับความจำเป็นอย่างต่อเนื่องที่ต้องจับตาดู และอธิบายว่าแม้ว่า รางวัลมากมายสำหรับการสร้างผลิตภัณฑ์ ความสำเร็จของคุณเกิดขึ้นได้ก็ต่อเมื่อต้องอาศัยทีมงานของคุณ สามารถพบได้ที่นี่บล็อก .
Michael อาศัยอยู่กับครอบครัวของเขาในเรดวูด แคลิฟอร์เนีย เขามักจะหาเวลาไปปั่นจักรยานเสือภูเขา เล่นฮอกกี้ และดื่มไวน์แดงอยู่เสมอ เนื่องจากการมีสุขภาพดีมีความสำคัญมากกว่าการมีงานยุ่ง
» ดูรายละเอียดหนังสือเพิ่มเติมได้ที่
»
»
สำหรับ Khabrozhiteley ส่วนลด 20% โดยใช้คูปอง - การจัดการคน
เมื่อชำระค่าหนังสือฉบับกระดาษแล้ว หนังสือฉบับอิเล็กทรอนิกส์จะถูกส่งทางอีเมล
ป.ล. 7% ของราคาหนังสือจะเป็นค่าแปลหนังสือคอมพิวเตอร์ใหม่รายชื่อหนังสือที่ส่งมอบให้โรงพิมพ์ .
ที่มา: will.com