ผู้จัดการที่ไม่ใช่ด้านเทคนิคจะเพิ่มคุณค่าให้กับทีมนักพัฒนาซอฟต์แวร์ที่สร้างแรงจูงใจด้วยตนเองได้อย่างไร?


63

ฉันเห็นโปรแกรมเมอร์จำนวนมากหันหน้าหนีจากบทบาทการจัดการและการบริหาร พวกเขาต้องการสร้างสิ่งต่าง ๆ และเป็นผลให้ตำแหน่งเหล่านี้จำนวนมากเต็มไปด้วยคนที่ไม่ใช่ด้านเทคนิค ฉันไม่เห็นว่าพวกเขาเพิ่มคุณค่าอย่างไร การกำหนดตารางการประชุมการจองนอกสถานที่และงานธุรการอื่น ๆ เพียงพอที่จะพิสูจน์บทบาทของพวกเขาได้หรือไม่?


10
คุณคิดว่าเปอร์เซ็นต์ของทีมซอฟต์แวร์ทั้งหมดสามารถทำงานแบบนั้นได้โดยไม่ต้องมี egos และวาระที่จะเข้ามา?
ozz

30
จากTao of Programming : สามเณรถามว่า: "ในภาคตะวันออกมีโครงสร้างต้นไม้ที่ยอดเยี่ยมที่ผู้ชายเรียกว่า 'Corporate Headquarters' มันมีรูปร่างที่แตกต่างจากรองประธานาธิบดีและนักบัญชีมันออกบันทึกจำนวนมาก ... สิ่งที่ผิดธรรมชาตินั้นจะเป็นเช่นไร? " / อาจารย์ตอบว่า: "คุณเห็นโครงสร้างอันยิ่งใหญ่นี้และถูกรบกวนว่ามันไม่มีจุดประสงค์ที่เป็นเหตุเป็นผล ... คุณไม่สนุกกับการเขียนโปรแกรมที่สะดวกสบายภายใต้กิ่งก้านที่กำบังของมันทำไมคุณไม่ใส่ใจกับความไร้ประโยชน์?"
apsillers


2
การเขียนโดย Rands ค่อนข้างจะหมุนรอบปัญหาเหล่านี้บางส่วน ฉันให้มันตราการแนะนำ (ไม่พูดถึงเขามีงานเขียนที่ยอดเยี่ยมอื่น ๆ อีกมากมายเช่นกัน!)
Jari Keinänen

คำตอบ:


112

ฉันล้มเหลวที่จะเห็นว่าพวกเขาเพิ่มมูลค่าในปัจจุบันและกำหนดเวลาการประชุมจองไซต์และการบริหารอื่น ๆ ทำงานได้ดีพอสำหรับบทบาทของพวกเขาหรือไม่

อย่าประมาทจำนวนการโต้ตอบที่ผู้จัดการของคุณทำกับแผนกอื่น ๆ พวกเขาจัดการงบประมาณแผนการฝึกอบรมเอกสาร HR พวกเขาปกป้องนักพัฒนาจากการถูกดูดเข้าร่วมการประชุมกับแผนกอื่น ๆ และให้แนวร่วมสำหรับกลุ่มของคุณ

ในระยะสั้นงานของพวกเขาคือการปกป้องนักพัฒนาที่มีแรงจูงใจในตนเองจากสิ่งอื่น ๆ ทั้งหมดที่มีในธุรกิจ demotivating


4
และพวกเขาจะทำงานที่ดีขึ้นมากเพื่อปกป้องเงินเดือน / เพิ่ม
JeffO

20
+1 มาก บางครั้งเราอาจ "รั่ว" ผ่านระบบและความคิดเล็ก ๆ ของสิ่งที่ผู้จัดการของเราและโดยเฉพาะอย่างยิ่งเจ้าของผลิตภัณฑ์ของเราผ่านไป ฉันไม่ต้องการที่จะจัดการกับทุกวัน
Izkata

1
ฉันรู้ว่าสิ่งเหล่านี้มีความสำคัญ แต่ฉันไม่ได้รับความสำคัญสัมพัทธ์ในทีมพัฒนาซอฟต์แวร์และคุณค่าของสิ่งเหล่านี้
Senthil Kumaran

17
@SenthilKumaran ในฐานะนักพัฒนาคุณควรจะใช้เวลาสองชั่วโมงกับผู้จัดการจากแผนกอื่นเพื่อพูดถึงว่าทำไมซอฟต์แวร์ถึงไม่สมบูรณ์หรือคุณอยากจะใช้โค้ดสองชั่วโมงนี้แทนหรือเปล่า? คุณรู้ว่ามันยากเพียงใดที่จะอธิบายปัญหาทางเทคนิคให้กับผู้จัดการของคุณ ลองนึกภาพพยายามอธิบายให้คนที่รู้น้อยกว่าผู้จัดการที่ไม่ใช่ด้านเทคนิคของคุณ ผู้จัดการที่ไม่ใช่ด้านเทคนิคที่ดีที่สุดป้องกันนักพัฒนาของพวกเขาจากทุกสิ่งที่จะทำให้เสียเวลาของนักพัฒนาที่ใช้การเข้ารหัสและการทดสอบที่ดีขึ้น
David Navarre

5
นี้ซ้ำแล้วซ้ำอีก แม้แต่ผู้จัดการด้านเทคนิคนี่ก็ยังเป็นงานที่ใหญ่ที่สุดของพวกเขา
Earlz

36

ผู้จัดการที่ดีที่สุดคือนักมายากล พวกเขาทำให้ส่วนที่เหลือของ บริษัท หายไปสำหรับนักพัฒนาของพวกเขา ฉันจำคำพูดที่ไม่ถูกต้องจาก Joel ได้แต่มันเป็นงานที่ผู้บริหารต้องทำเพื่อให้แน่ใจว่ามี Internet Pipe ที่อ้วนสัตว์ร้ายของเครื่องจักรและคาเฟอีนมากมายดังนั้นนักพัฒนาทั้งหมดต้องกังวลเกี่ยวกับสิ่งที่ พวกเขาทำดีที่สุด

ผู้จัดการที่ดีคือเสียงของกลุ่มคุณต่อ บริษัท อื่น ๆ



29

เนื่องจากมีการใช้งานเฉพาะกับการพัฒนาซอฟต์แวร์มีบทบาทเพิ่มมูลค่าสองประเภทสำหรับผู้จัดการ: การจัดการโครงการและการเป็นผู้นำทีม

ผู้จัดการโครงการติดต่อกับลูกค้าและผู้บริหารระดับกลางซึ่งเป็นเวลาที่ประหยัดสำหรับนักพัฒนา บ่อยครั้งที่มีการชี้แจงหรือเปลี่ยนแปลงขอบเขตที่เกิดขึ้นในโครงการและเป็นประโยชน์ต่อลูกค้าและผู้จัดการระดับกลางที่จะมีจุดติดต่อเพียงจุดเดียว การพยายามตอบคำถามจากสมาชิกทุกคนของทีมพัฒนานำไปสู่การตัดสินใจโครงการที่ไม่ได้บันทึกไว้และภาระผูกพันที่ไม่มีเอกสารซึ่งเป็นข้อ จำกัด ของการจัดการขอบเขต

ในอีกด้านหนึ่งหัวหน้าทีมมีส่วนเกี่ยวข้องกับการพัฒนาอาชีพ / ทักษะตรวจสอบให้แน่ใจว่ามีการกระจายภาระงานอย่างเหมาะสมระหว่างสมาชิกในทีมและจัดหาทรัพยากรและผลตอบแทนที่สอดคล้องกับการช่วยเหลือและความต้องการส่วนบุคคล

บทบาทเหล่านี้ไม่จำเป็นต้องมีหัวเขียนโปรแกรม แต่จริงๆแล้วมันค่อนข้างตรงกันข้าม โปรแกรมเมอร์มักจะข้ามไปที่งานเขียนโค้ดซึ่งเป็นการตอบคำถามหรือวิกฤตครั้งแรกและเป็นประโยชน์กับคนที่มีหน้าที่ถามว่างานนั้นต้องทำจริงหรือไม่


6
นักพัฒนาเห็นต้นไม้ ผู้จัดการของพวกเขาเห็นป่า
David Navarre

9
@DavidNavarre - ผู้จัดการที่ไม่ใช่ด้านเทคนิคของ IMO มีปัญหาในการมองเห็นอะไร ...
Vector

13
@Vector: สิ่งที่คุณอ้างถึงไม่ใช่ผู้จัดการที่ไม่ใช่ด้านเทคนิค แต่เป็นผู้จัดการที่ไร้ความสามารถ
โกหกไรอัน

@Vector: มันทำให้นึกถึงPHB ของ Dilbertแต่ฉันไม่คิดว่ามันจะเหมือนกับผู้จัดการที่ไม่ใช่ด้านเทคนิค
hardmath

@hardmath - ฉันเข้าใจ :-) คำตอบของคุณรวมอยู่ในสิ่งที่ OP ได้รับตามการแก้ไข ประเด็นที่ฉันพยายามทำคือสิ่งที่เกี่ยวข้องกับด้านเทคนิคพวกเขาจำเป็นต้องพูดออกมา ฉันมีประสบการณ์ที่ขมขื่นในเรื่องเหล่านี้ ... "ความรู้เล็ก ๆ น้อย ๆ เป็นสิ่งที่อันตราย" - ฉันแน่ใจว่าคุณได้รับการดริฟท์ของฉัน ดูคำตอบของฉัน
เวกเตอร์

12

นอกเหนือจากผลประโยชน์อื่น ๆ ที่กล่าวถึงผู้จัดการที่ไม่ใช่ด้านเทคนิคอาจทำการตัดสินใจขั้นสุดท้ายได้ดีขึ้นเมื่อผู้เชี่ยวชาญมีปัญหา ฉันรู้ว่าสิ่งนี้ฟังดูง่าย แต่ผู้จัดการที่ไม่ใช่ช่างเทคนิคที่ดีเข้าใจถึงจุดแข็งและจุดอ่อนของพนักงาน

ตัวอย่าง: โปรแกรมเมอร์สองคนถกเถียงกันว่าควรใช้เซิร์ฟเวอร์ใดกับแอปพลิเคชัน ในระบอบประชาธิปไตยที่ทำให้เชื่อพวกเขาทั้งสองได้รับหนึ่งเสียงดังนั้นจึงไม่มีการตัดสินใจใด ๆ สงครามครั้งนี้อาจดำเนินต่อไปตลอดกาล (และสำหรับคนช่างเทคนิค) บางคนต้องก้าวเข้ามาและไกล่เกลี่ยข้อขัดแย้งนี้และทำให้โครงการดำเนินต่อไป ผู้ตัดสินที่ดีจะพึ่งพาความเห็นของผู้ที่มีความเชี่ยวชาญมากที่สุดในด้านนี้

เพียงเพราะใครบางคนขาดความสามารถทักษะหรือความรู้ในพื้นที่ไม่ได้หมายความว่าพวกเขาไม่สามารถระบุผู้ที่ทำ การยอมรับพรสวรรค์เป็นพรสวรรค์


1
นอกจากนี้ผู้จัดการที่ไม่ใช่ด้านเทคนิคพร้อมที่จะตอบสนองความต้องการของทีมแทนที่จะเขียนโค้ด
JeffO

1
"นอกเหนือจากผลประโยชน์อื่น ๆ ที่กล่าวถึงผู้จัดการที่ไม่ใช่ด้านเทคนิคอาจทำงานได้ดีขึ้นในการตัดสินใจขั้นสุดท้ายเมื่อมีข้อบกพร่องในหมู่ผู้เชี่ยวชาญ" ผู้ที่ไม่ใช่ผู้เชี่ยวชาญมีข้อมูลน้อยที่สุดเกี่ยวกับหัวข้อเฉพาะ เขาสามารถ "เข้าข้าง" กับฝ่ายที่มีความเชี่ยวชาญมากที่สุดในพื้นที่นี้เท่านั้น (หรือเลือกวิธีแก้ปัญหาที่เขาคิดว่าดีที่สุด) แต่นั่นไม่ได้หมายความว่าการตัดสินใจของเขาถูกต้อง การแก้ปัญหาจากโปรแกรมเมอร์ที่มีประสบการณ์น้อยอาจดีกว่า แต่ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็ไม่สามารถรู้ได้ joelonsoftware.com/items/2006/08/08.html
คริสเตียน

ในสถานการณ์เช่นนี้ส่วนหนึ่งของการจัดการที่ถูกประเมินต่ำมักจะไม่ได้รับอนุญาตให้คนที่ดีที่สุดเข้ามามีส่วนร่วม ผู้จัดการที่ดีจะอ่านสถานการณ์ได้ดีและจะทำให้การตัดสินที่อาจไม่ถูกต้องทางเทคนิค แต่จะถูกต้องทางการเมือง หากการโต้แย้งไม่ผ่านสิ่งที่สำคัญผู้จัดการอาจต้องการคนที่ต้องการกำลังใจมากกว่าหรือถูกรังแกจากผู้พัฒนารายอื่น บางครั้งมันก็เป็นการเรียกการตัดสินและเป็นเรื่องยาก แต่นั่นเป็นเหตุผลว่าทำไมพวกเขาถึงได้จ่ายเงินจำนวนมาก
สตีเฟ่น

@ สตีเฟ่นเห็นด้วย - ผู้จัดการที่ดีจะรู้วิธีการจัดการคนของเขา (เช่นที่คุณบอกว่าให้กำลังใจกับคนอื่น ๆ ) แต่ถ้าเราพูดอย่างเคร่งครัดเกี่ยวกับการตัดสินใจ (สำคัญ) ผู้จัดการการตัดสินใจทางเทคนิคมีข้อมูลจำนวนน้อยที่สุดเกี่ยวกับปัญหา อาจเป็นคนผิดในการตัดสินใจ
คริสเตียน P

@ สตีเฟ่น: แต่จะถูกต้องทางการเมือง - ซึ่งมักจะเป็นวิธีที่ดีมากสำหรับผู้จัดการที่ไม่ใช่ด้านเทคนิคที่จะสูญเสียความน่าเชื่อถือทั้งหมดกับเจ้าหน้าที่ด้านเทคนิค IMO ที่มีความเสี่ยงสูง
เวกเตอร์

2

การกำหนดตารางการประชุมการจองนอกสถานที่และการบริหารอื่น ๆ นั้นเพียงพอสำหรับบทบาทของพวกเขาหรือไม่?

ใช่. เพียงพออย่างสมบูรณ์แบบ พวกเขายังดีสำหรับการเรียกการจัดการอาคารเมื่อมีปัญหากับความร้อน AC ฯลฯ ทำให้แน่ใจว่าตู้หยอดเหรียญและเครื่องทำน้ำเย็นมีการเก็บรักษาและบำรุงรักษาอย่างดี นำสารพัดพิเศษมาให้ ทำให้สำนักงานสะอาดและเป็นระเบียบ ...

พยายามอย่างดีที่สุดที่จะคิดถึงงานอื่น ๆ เพื่อให้พวกเขายุ่งและไร้ปัญหา ...

บทบาทที่สำคัญที่สุดของพวกเขา อยู่ห่างจากทางและไม่ได้ปะปนกับโปรแกรมเมอร์และทำให้แน่ใจว่าคนอื่น ๆ

พิจารณาทีมพัฒนาเช่น MLB ballclub (การเปรียบเทียบค่อนข้างดีทีเดียว IMO): ผู้จัดการมักจะเป็นผู้เล่นเก่า - พวกเขาเท่านั้นที่รู้วิธีจัดการ 'การจัดการ' ของทีมที่มีทักษะสูง, โง่เง่า, มีนิสัยคล้ายมืออาชีพ ใครทำสิ่งที่ 'คนธรรมดา' ส่วนใหญ่ไม่สามารถทำได้


นอกจากนี้คุณยังได้รับผู้จัดการด้านกีฬามากมายที่ไม่ใช่อดีตผู้เล่นหรือไม่เคยเป็นอดีตผู้เล่นที่ดีมาก - Arsene Wenger, Jose Mourinho, Andre Villas-Boas ทุกคน? ที่กลายเป็นผู้จัดการที่ยอดเยี่ยม คุณต้องมีทักษะการสื่อสารระหว่างบุคคลและองค์กรที่แข็งแกร่งเพื่อเป็น PM ที่ดีซึ่งไม่ได้เข้ารหัส
bobo2000

@ bobo2000 - ฉันพูดถึงMLBไม่ใช่กีฬาโดยทั่วไป
เวกเตอร์

-1

ในประสบการณ์ของผู้จัดการไม่ใช่ทางด้านเทคนิคของฉันมีความเหมาะสมที่สุดสำหรับบทบาทนี้นอกเหนือจากการเพิ่มมูลค่าโดยการหลีกเลี่ยงสิ่งที่ บริษัท ยุ่งกับนักพัฒนาทำงานพวกเขาปลุกระดมความร่วมมือระหว่างนักพัฒนา (สาเหตุก็รู้ดีว่านักพัฒนาจะ introverts http://www.unwesen.de/ 2012/03/16 / introversion-Productivity-work-environment / ) คนดีปล่อยให้ทีมทำงานตามจังหวะของพวกเขา แต่ใส่ใจเกี่ยวกับการมองเห็น


2
คำตอบของคุณจะแข็งแกร่งขึ้นถ้าคุณอ้างถึงการอ้างอิงภายนอกหรือขยายความเชื่อของคุณ การระบุcause it's well know[n]เป็นหลักฐานที่อ่อนแอ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.