ฉันเป็นผู้จัดการ ฉันจะปรับปรุงความสัมพันธ์ในการทำงานและการสื่อสารกับโปรแกรมเมอร์ได้อย่างไร [ปิด]

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

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

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

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

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

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

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

• ทำไม? เป็นคำถามที่สำคัญมาก - คำตอบที่เป็นจริงเกือบทั้งหมดมี "ทำไม" อยู่ข้างหลังและ "ทำไม" อาจมีความสำคัญมากกว่าคำถามจริง มีการเสียบ้างเล็กน้อยของสิ่งนี้:
  • ทำไมผู้พัฒนา - นักพัฒนาจะมีคำตอบมากมายที่ไม่สมเหตุสมผลกับการจัดการ ฉันทำอย่างแน่นอนและหนึ่งในวิธีที่ฉันได้รับในการจัดการคือการอธิบายทีม "whys" ได้ดีในแง่การจัดการที่สามารถเข้าใจได้ หากคุณไม่มี "ลำโพงสำหรับคนที่ชอบพูดเกินจริง" คุณสามารถเรียนรู้ที่จะพูดอย่างเปิดเผยได้โดยปรับคำตอบของพวกเขากลับคืนสู่คำถามที่ว่าทำไมในอุปมาอุปมัยที่เข้าใจกันมากกว่าปกติ เก็บไว้จนกว่าคุณจะเข้าใจและยอมรับในสิ่งที่เกิดขึ้น
  • การจัดการทำไม- "ทำไม" ของคุณก็สำคัญพอ ๆ ทำไมคุณถึงต้องการเวลาประมาณ คุณจะใช้อะไร เราจะเมาได้อย่างไรในฐานะ บริษัท ถ้าพวกเขาสูงหรือต่ำเกินไป นี่คือสิ่งที่คุณในฐานะผู้จัดการอาจมีความเข้าใจอย่างถ่องแท้ แต่ทั้งหมดนี้เป็นของนักพัฒนา เคล็ดลับคือนักพัฒนาอาจไม่ถาม ฝ่ายบริหารขอให้เขาทำอะไรสักอย่างแล้วเขาจะพยายามอย่างดีที่สุดที่จะทำได้อย่างถูกต้องทันเวลาและมีน้ำใจ แต่ถ้าเขาไม่รู้ว่า "ทำไม" เขาอาจปรับให้เหมาะสมในแบบที่คุณต้องการ เสนอสาเหตุของคุณและขอให้เขาทำสิ่งเดียวกัน - ตอบคำตอบในข้อตกลงของเขา

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

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

• ฟังเสียงโดยรอบการเลือกคำและช่องว่างระหว่างคำ - นี่คือสิ่งที่ฉันชอบและถูกขโมยเพื่อใช้ตัวเอง:

  • ออกไปเที่ยวในพื้นที่ทำงานทำสิ่งที่มีประโยชน์ด้วยตัวคุณเอง (อย่าพยายามทำงานนักพัฒนาพวกเขารู้ว่าคุณไม่ใช่นักพัฒนา) และแค่ฟัง ทีมแก้ไขปัญหาได้อย่างไร ปัญหาใหญ่ของพวกเขาคืออะไร? คุณจะไม่เคยได้ยินเสียงผอมจริง ๆ จากการประเมินโดยตรงของคุณหรือผู้บริหารที่มีขนาดใหญ่ แต่คุณอาจได้รับความรู้สึกที่ดีว่าพื้นที่ที่มีปัญหานั้นเป็นอย่างไร ตรวจสอบให้แน่ใจว่าคุณกำลังทำบางสิ่งด้วยตัวคุณเองที่มีประสิทธิผล ไม่มีใครชอบสอดแนม แต่ถ้าไม่มีกำลังใจต่ำจนคุณไม่สามารถอยู่ใกล้พวกเขาได้โดยที่ทุกคนอพยพไม่ได้ผลผลิตที่อยู่ในบริเวณใกล้เคียงควรจะทนได้
  • มองหาตัวเลือกคำ - พวกเขามักจะมีความสำคัญเท่ากับคำว่าตัวเอง เมื่อฉันใช้คำที่เป็นบวกหรือเชิงลบผู้บริหารของฉันมักถามฉันว่าทำไมฉันถึงเลือกคำเหล่านั้นเมื่อเป็นสถานการณ์ที่ไม่คุ้นเคย
  • มองหาช่องว่างหยุดชั่วคราวและภาษากาย หากมีระยะห่างระหว่างตัวคุณกับนักพัฒนา (และดูเหมือนว่ามี) พวกเขาอาจไม่ต้องการขัดแย้งหรือเผชิญหน้ากับคุณ แต่สัญชาตญาณพื้นฐานที่จะพูดว่า "เฮ้คุณผิด" มักจะปรากฏตัวที่ใดที่หนึ่ง

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

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

และนี่คือหนึ่งที่ไม่น่าเชื่อยากสำหรับผม แต่ได้ทำงานที่ดีเมื่อฉันสามารถทำมัน - จะตระหนักถึงความแตกต่างระหว่าง introverts และ extroverts โอกาสที่คุณจะเป็นคนพาหิรวัฒน์ - นั่นเป็นสาเหตุที่งานของคุณดูดีและตำแหน่งการพัฒนาไม่ได้ นักพัฒนาส่วนใหญ่จะเป็นคนเก็บตัว "Introvert" ไม่ได้หมายความว่า "ไม่สามารถสื่อสารได้" แต่หมายความว่ารูปแบบกระบวนการและความเร็วของพวกเขานั้นแตกต่างกันอย่างมีนัยสำคัญและความต้องการในการสื่อสารไม่หยุดหย่อนนั้นแทบจะไม่มีอยู่จริง วางแผนในเวลาและพื้นที่ที่เงียบสงบ (แต่จัดวาง) เพื่อให้ความคิดที่เก็บตัวตามมานั้นออกมา เพื่อนเก็บตัวของฉันหลายคนบอกฉันว่าพวกเขากำลังรอให้ฉัน "หุบปากอย่างเช่น 5 นาที" เพื่อให้พวกเขาสามารถคิดและตอบกลับมาได้ นี่'5 สิ่งที่ extroverts ควรรู้เกี่ยวกับ introvertsและRands ใน Repose บน Nerd Cave - ตัวอย่างโดยเฉพาะอย่างยิ่งสำหรับนักพัฒนา tastic ของสิ่งที่ยิ่งใหญ่สำหรับ introverts Rands นั้นยอดเยี่ยมมากทีเดียว เขาเป็นคนที่เกินจริงดังนั้นเขาจึงมาจากจุดสนใจของนักพัฒนาซึ่งสามารถเลิกได้ถ้าไม่ใช่สไตล์ของคุณ แต่เขาก็ตลกและมีความเข้าใจที่ดีเกี่ยวกับการพัฒนาทีม

ฉันคิดว่าสิ่งที่ # 1 ที่ฉันรักเกี่ยวกับผู้จัดการคนโปรดของฉันคือ:

• พวกเขามีความมุ่งมั่นอย่างลึกซึ้งและตื่นเต้นเกี่ยวกับโครงการเช่นเดียวกับฉัน (ถ้าไม่มาก)

• ฉันไม่เคยสงสัยเลยว่าพวกเขามีหลังของฉัน - ฉันรู้ด้วยความมั่นใจว่าเมื่อพวกเขาอยู่ต่อหน้าผู้มีอำนาจในระดับต่อไปที่ฉัน (หรือเพื่อนร่วมงานของฉัน) จะไม่เคยเป็นแพะภูมิประเทศ มันจะเป็นความล้มเหลวของกลุ่มเสมอหากมีความล้มเหลว

• ฉันได้รับกรรมสิทธิ์ในสิ่งที่สำคัญและเหมาะสมกับทักษะของฉันในเวลานั้น แต่มีทรัพยากรเพียงพอที่จะขยายทักษะของฉันและทำงานให้สำเร็จลุล่วง

• พวกเขาเห็นฉันเป็นทั้งรายบุคคลและเป็นส่วนหนึ่งของทีม - พวกเขามีส่วนร่วมอย่างแข็งขันในการรู้จักจุดแข็งและจุดอ่อนของฉันและการทำงานเพื่อช่วยให้ฉันเล่นกับจุดแข็งของฉันและเพิ่มจุดอ่อนของฉัน

• พวกเขาตระหนักถึงเป้าหมายส่วนบุคคลของฉันและสนใจรวมพวกเขาให้มากที่สุด

• พวกเขาล่วงหน้าเมื่อทำให้ฉันมีความสุขไม่สามารถและจะไม่ให้ความสำคัญ มีคุณค่าอย่างแท้จริงในการได้ยิน "ฉันรู้ว่าคุณเกลียดงานประเภทนี้ แต่ฉันต้องการให้คุณทำ - นี่คือวิธีที่มันจะไม่อยู่ตลอดไป ... "

• มีเวลาเสมอในหนึ่งสัปดาห์ (อาจจะไม่ใช่ในทันที) เพื่ออธิบายภาพรวม

• มีข้อเสนอแนะและสถานะใกล้คงที่โดยไม่มีการชี้นิ้ว

• มีความจริงเสมอ หากสิ่งที่ละเอียดอ่อนและไม่สามารถพูดคุยพวกเขากล่าวว่าจุดว่าง หากมีอะไรไม่แน่นอนพวกเขาก็ให้ความมั่นใจในระดับหนึ่ง

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

อย่างไรก็ตามฉัน 100% เห็นด้วยกับคุณเกี่ยวกับความยากลำบากในการสื่อสารกับนักพัฒนา ฉันมีการเปิดเผยเมื่อหลายปีก่อนในฐานะนักพัฒนาในการฝึกอบรมการจัดการโครงการ ฉันเห็นนักพัฒนาเพื่อนของฉันหลายคนมีความรู้สึกต่อต้านการจัดการอย่างแท้จริงหลังจากที่มีการสร้างบรรยากาศของการอภิปรายขึ้นมา ทุกสิ่งที่ผิดคือความผิดของผู้จัดการในสายตาของนักพัฒนา นักเตะคือฝ่ายบริหารไม่มีความรู้เกี่ยวกับประเด็นใหญ่ ๆ ที่เกิดขึ้นในวันนั้น นักพัฒนาสมมติว่าทุกอย่างชัดเจนว่าฝ่ายบริหารไม่ควรพลาดและฝ่ายบริหารสันนิษฐานว่านักพัฒนาจะบอกสิ่งที่ต้องการ

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

และไม่ว่าคุณจะทำอะไรอย่าถามคำถามที่คุณไม่ต้องการรู้คำตอบโดยอ้างถึง "การประมาณการที่ผิดพลาด" ด้านบน ;-) นั่นคือ kryptonite ของนักพัฒนา

มีหลายสิ่งที่ดีอยู่ที่นี่ แต่ฉันรู้สึกว่าจำเป็นต้องพูดต่อไปนี้ .. ต้องเข้มงวดมาก .. แต่ต้องบอกว่า:

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

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

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

นี่จะเปิดตาของคุณให้เห็นถึงพลวัตของทีมพัฒนาเพราะตอนนี้คุณยังไม่ได้เป็นส่วนหนึ่งของทีมคุณเป็นคนนอก ความจริงที่ว่า dev ของคุณออกมาทำให้คุณตกใจจริงๆ ทุกคนในทีมรู้ว่าเขาไม่มีความสุข และไม่มีใครบอกคุณ:

"เราจะสูญเสียผู้ชายที่ดีที่สุดของเราหากคุณไม่ทำอะไร"

นั่นควรเป็นธงสีแดง # 2

ในฐานะที่เป็นผู้จัดการฉันแน่ใจว่าคุณเคยได้ยินเกี่ยวกับไคเซ็นซึ่งเป็นหนึ่งในหลักการของระบบการผลิตของโตโยต้าหมายปรับปรุงอย่างต่อเนื่อง

คุณยอมรับว่าคุณมีปัญหาดังนั้นนั่นเป็นการเริ่มต้นที่ดี

Kaizenมีองค์ประกอบหลักห้าประการ:

• กลุ่มคุณภาพ : กลุ่มที่พบเพื่อหารือเกี่ยวกับระดับคุณภาพที่เกี่ยวข้องกับทุกด้านของการดำเนินงานของ บริษัท

• Improved ขวัญกำลังใจ : ขวัญกำลังใจที่แข็งแกร่งในหมู่พนักงานเป็นขั้นตอนสำคัญในการบรรลุประสิทธิภาพและประสิทธิผลในระยะยาวและ kaizen กำหนดให้เป็นภารกิจพื้นฐานในการติดต่อกับขวัญกำลังใจของพนักงานอย่างต่อเนื่อง

• การทำงานเป็นทีม : บริษัท ที่แข็งแกร่งเป็น บริษัท ที่รวมตัวกันทุกขั้นตอน Kaizen มุ่งหวังที่จะช่วยให้พนักงานและผู้บริหารมองตัวเองในฐานะสมาชิกของทีมมากกว่าเป็นคู่แข่ง

• วินัยส่วนบุคคล : ทีมไม่สามารถประสบความสำเร็จได้หากไม่มีสมาชิกแต่ละคนในทีมที่แข็งแกร่งในตัวเอง ความมุ่งมั่นในการสร้างวินัยส่วนบุคคลโดยพนักงานแต่ละคนทำให้มั่นใจได้ว่าทีมจะยังคงแข็งแกร่ง

• ข้อเสนอแนะเพื่อการปรับปรุง : โดยการขอความคิดเห็นจากสมาชิกแต่ละคนในทีมฝ่ายบริหารทำให้มั่นใจได้ว่าปัญหาทั้งหมดจะได้รับการพิจารณาและแก้ไขก่อนที่พวกเขาจะกลายเป็นสิ่งสำคัญ

( ที่มา )

หากคุณมองไปที่สิ่งนี้อย่างสม่ำเสมอค่าคงที่ขององค์ประกอบเหล่านั้นคือการเน้นการทำงานเป็นทีมและข้อเสนอแนะ

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

ดังนั้นคำแนะนำแรกของฉัน:

ฟัง : เริ่มต้นด้วยอีเมลง่ายๆไปยังทีม: "วิธีที่ดีที่สุดสำหรับทีมพัฒนาเพื่อให้ข้อเสนอแนะกับผู้บริหารเกี่ยวกับประสิทธิภาพการจัดการคืออะไร" พูดซ้ำกับทีมและทำตามฉันทามติ งานของคุณคืออนุญาตให้ทีมพัฒนาซอฟต์แวร์ที่ยอดเยี่ยมไม่ใช่เพื่อฝูงพวกเขา จำไว้ในใจ

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

และที่ผ่านมาถึงแม้ว่าฉันเคยเห็นวิพากษ์วิจารณ์บางอย่างเกี่ยวกับที่นี่ผมอยากจะแนะนำให้คุณอ่านหนังสือที่เรียกว่ากับ myth Man-เดือน: บทความเกี่ยวกับวิศวกรรมซอฟต์แวร์ หนังสือเล่มนี้เกี่ยวกับประสบการณ์ Fred Brooks ที่ IBM ในขณะที่จัดการการพัฒนา OS / 360 ในขณะที่บางสิ่งที่นี่และอาจมีวันที่มันเป็นขั้นตอนเริ่มต้นที่จะเข้าใจว่ากระบวนการพัฒนาซอฟต์แวร์ที่ซับซ้อนทำงานอย่างไร S.Lott อ้างอิงAgile Manifestoซึ่งฉันไม่ได้สนใจเป็นพิเศษ แต่ก็คุ้มค่าที่จะอ่าน

อ่านนี่:

http://agilemanifesto.org/

• บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

• ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม

• การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

• ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

ในหลายกรณีองค์กร (เช่นเจ้านายของคุณ) ต้องการให้คุณ

• ทำตามกระบวนการที่แตกหักอย่างชัดเจนว่าเป็นข้อสรุปเชิงตรรกะที่นำไปสู่ ​​"การเดินขบวน" สิ่งนี้นำไปสู่ข้อโต้แย้งและการลาออก

• สร้างเอกสารที่ไม่ได้ใช้มากเกินไปมูลค่าต่ำ

• มีส่วนร่วมในการควบคุมการเปลี่ยนแปลงที่ซับซ้อน a / k / a การเจรจาต่อรองสัญญา การเปลี่ยนแปลงของผู้ใช้ทุกครั้งจะต้องมีพิธีกรรมอย่างละเอียดเพื่อ "คุณภาพ" และ "จัดลำดับความสำคัญ" การเปลี่ยนแปลง จริงๆแล้วมันคือทั้งหมดที่เกี่ยวกับ "หยุด" - ป้องกันการเปลี่ยนแปลง

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

อาจเป็นได้ว่าปัญหาไม่ใช่ทักษะการสื่อสารส่วนบุคคลของคุณ

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

สำหรับฉันแล้วดูเหมือนว่าคุณไม่เคยคุยกับบรรดา devs ในบรรยากาศที่ง่าย การพูดคุยของคุณกับพวกเขาเป็นเพียงลักษณะทางการ มันแย่มาก

ทำไมคุณไม่รู้จักพวกเขาเป็นการส่วนตัวและทำความรู้จักกับสิ่งที่ดีและสิ่งที่ไม่ดีเกี่ยวกับ บริษัท ที่ทำงานและโครงการของพวกเขา เคารพพวกเขาและได้รับความเคารพโดยแสดงความสนใจอย่างจริงใจและขอบคุณสำหรับการทำงานของพวกเขา

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

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

Clap! Clap! Clap! แน่นอนคุณควรเป็นคนดีเพราะคุณได้ออกมาเปิดเพื่อดูสิ่งที่สามารถทำได้เพื่อให้ดีขึ้นในงานของคุณ

โปรดดูสิ่งที่ฉันได้เห็นด้านล่างในผู้จัดการที่ยอดเยี่ยมและมีบุญธรรมส่วนตัวเมื่อฉันนำทีมในฐานะสมาชิกอาวุโส

• Mมีส่วนร่วมมากกว่าจัดการ
• สมาชิกในทีมที่มีชื่อเสียงเพื่อแสดงความคิดเห็นและข้อกังวล เป็นหูของทุกคนไป นำสิ่งที่สร้างสรรค์
• ยังไม่มีข้อความที่เคยทรยศสมาชิกในทีมโดยการเล่นการเมืองแตกแยก ไฟแบ็คอัพนี้ไม่ช้าก็เร็ว
• nger ไม่ ไม่เคยมีคำสบถบนใบหน้าของคุณเมื่อคุณอยู่กับทีมของคุณมาสิ่งที่อาจ อันนี้ยากจริงๆ
• G อย่างแท้จริงและเปิดเผยต่อผู้ชนะสำหรับผลงานที่ดีของเขา / เธอ ในความกว้างเดียวกันอย่างนุ่มนวลและมีไหวพริบในการไตร่ตรองถึงการทำงานไม่ใช่คนที่ทำผิดใด ๆ กับคนที่รับผิดชอบแยกและไม่เปิด
• Eเจ้าของ ncourage และความเป็นผู้นำในทุกราย สิ่งนี้ช่วยเพิ่มขวัญและความมุ่งมั่นของบุคคลเพราะเขาจะรู้สึกเคารพ
• R OAM รอบกับทีมงานของคุณครั้งในขณะที่ สิ่งนี้ทำให้เกิด / เพิ่มความผูกพันภายในสมาชิกในทีม

ขอให้คุณโชคดีในความพยายามอย่างจริงใจ :)

โดยทั่วไปแล้วคนที่อยู่ในสนามเพลาะจะเริ่มรู้สึกท้อแท้เมื่อพวกเขารู้สึกว่ามือของพวกเขาไม่ได้รับการได้ยินจากคนที่สามารถและจะแก้ไขสถานการณ์ เมื่อพวกเขาไม่รู้สึกว่าสามารถจับตัวได้โดยไม่เสี่ยงต่อการยืนอยู่ใน บริษัท

ฉันเป็นคนประเภททฤษฎี - Y และส่วนใหญ่ "คนทำงานด้วยความรู้" มีแนวโน้มที่จะเป็น ได้รับโอกาสเราชอบงานของเราและต้องการทำมันให้ดี อย่างไรก็ตามข้อเสียของสถานที่ทำงานทฤษฎี - Y ก็คือมันอาจจะไม่ชัดเจนในทันทีว่ามีปัญหาเพราะคนต้องการทำดีและไม่ต้องการสร้างคลื่นจะหาวิธีแก้ไขปัญหานั้นหรือเพียงแค่เพิกเฉย สิ่งนี้นำไปสู่ความหงุดหงิดที่ถูกคุมขังซึ่งในที่สุดก็ระเบิดขึ้นต่อหน้าทั้งทีม ร้านค้าที่ดำเนินการโดยผู้จัดการ Theory-X น่าจะมีพวกที่บ่นมาเร็วกว่านี้ พนักงานอยู่ในนั้นเพื่อเงินดังนั้นถ้างานดูดมากกว่าปกติพวกเขาจะจับ

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

ใน Agile ในตอนท้ายของแต่ละ "sprint" หรือ "iteration" (ซึ่งเป็นหน่วยของการพัฒนามักจะใช้งานได้ยาวนานระหว่างหนึ่งถึงสามสัปดาห์) ทั้งทีมตั้งแต่สมาชิกรุ่นจูเนียร์มากที่สุดจนถึง PM มี "ย้อนหลัง" " พวกเขามองย้อนกลับไปในสิ่งที่พวกเขาทำสิ่งที่ถูกต้องสิ่งที่ไม่ทำและระบุสิ่งที่ต้องทำต่อไปและสิ่งที่จะเปลี่ยนแปลง มีหลายรูปแบบและคุณสามารถประดิษฐ์ของคุณเองได้ แต่ผลลัพธ์ของเรโทรควรเป็นที่ผู้คนรู้สึกว่าได้ยินเสียงของพวกเขาและสิ่งต่าง ๆ จะเปลี่ยนไปตามผลลัพธ์

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

ฉันออกจาก บริษัท นั้นและเริ่มทำงานกับ บริษัท อื่นที่ทำสิ่งต่าง ๆ แตกต่างกันมาก พวกเขาฝึกฝนวิธีการขั้นพื้นฐานของ SCRUM Agile โดยมี standups รายวัน, โปรแกรมคู่, ทีมวิ่งและย้อนหลัง สำหรับหนึ่งวันทุกสองสัปดาห์ที่จุดเริ่มต้นของการวิ่งแต่ละครั้งเราไม่ได้ทำอะไรนอกจากวางแผนงานสองสัปดาห์ถัดไป สำหรับกลุ่มก้อนใหญ่อีกวันเราไม่ได้ทำอะไรนอกจากมองย้อนกลับไปในสิ่งที่เราทำและหาวิธีปรับปรุงทีม มีนักพัฒนานั่งถัดจากฉันซึ่งเป็น Microsoft MVPs ทำงานให้เสร็จและสนับสนุนและเสริมสิ่งที่ฉันทำ

กลางคืน. และ. วัน. ความแตกต่างหลัก? ครั้งแรกฉันไม่รู้สึกว่าฉันคาดว่าจะฆ่าตัวตายเพื่อโครงการ; หลักการพื้นฐานของ Agile คือก้าวแห่งการพัฒนาที่ยั่งยืน ประการที่สองฉันมีเสียงในการตัดสินใจว่าจะทำงานของฉันอย่างไร ฉันต้องทำงาน แต่ถ้าฉันมี "อิจฉาริษยา" มากกว่าสิ่งที่ฉันคาดว่าจะดึงออกมาในการวิ่งครั้งต่อไปฉันสามารถฟังความเห็นนั้นและมันจะได้ยินและรับน้ำหนัก ถ้าฉันรู้สึกว่ามีวิธีที่ดีกว่าฉันสามารถพูดได้และมันจะได้รับความบันเทิง

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

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

และสำหรับความรักของพระเจ้าให้พยายามทำงานสัปดาห์ละ 40 ชั่วโมง นอกจากนี้ flextime Flextime สามารถชดเชยโลกทั้งโลกที่ไร้สาระได้ อย่างน้อยสำหรับฉัน

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

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

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

โชคดี.

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

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

• ฉันไม่ต้องเสียเวลามากเกินไปในการพิสูจน์ว่าทำไมการเปลี่ยนแปลงจึงใช้เวลานานหรือไม่สามารถใช้งานได้ ในทางเทคนิคแล้วการเปลี่ยนแปลงใด ๆ สามารถนำไปปฏิบัติได้และผู้บริหารระดับสูงมักต้องการการดำเนินการใด ๆ แต่อย่างน้อยในสถานการณ์เช่นนี้ผู้จัดการโดยตรงของคุณจะอยู่เคียงข้างคุณเพื่อขอเวลาเพิ่ม (แทนที่จะผลักคุณออกไป
• ฉันรู้ว่าฉันมีโอกาสที่ดีกว่าที่จะได้รับการสนับสนุนในกรณีที่มีสถานการณ์ไม่ดี (แฮ็ค WTF ปัญหาการผลิต ฯลฯ ) โดยทั่วไปแล้วคนที่ไม่ใช่ด้านเทคนิคมักจะตำหนินักพัฒนาสำหรับสถานการณ์เช่นนี้ในขณะที่ผู้จัดการที่ดีเข้าใจสิ่งที่เกิดขึ้นจริงและสนับสนุน / นักพัฒนาของเขา / เธอ (ไม่เพียง แต่รู้หรือเต็มใจที่จะเป็นอย่างดี)
• ฉันรู้ว่างานและการปฏิบัติงานของฉันจะต้องถูกประเมินโดยบุคคลที่เหมาะสม

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

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

สิ่งที่ฉันเห็นบ่อยมากคือความแตกต่างอย่างมากในระบบค่านิยมและวิธีการปฏิบัติ / วิธีการระหว่างผู้บริหารและผู้พัฒนา

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

ในเวลาเดียวกันคุณต้องปฏิบัติตัวเองดังนั้นคุณต้องหาวิธีสื่อสารกับผู้บริหารระดับสูงในภาษาที่พวกเขาเข้าใจและเล่นเกม นั่นคือความท้าทายที่แท้จริงของผู้บริหารระดับกลาง

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

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

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

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

ประการที่สามพิจารณาทักษะความฉลาดทางอารมณ์แบบใดที่คุณมี ความฉลาดทางอารมณ์สำหรับผู้จัดการโครงการ: ทักษะผู้คนที่คุณต้องการเพื่อให้ได้ผลลัพธ์ที่โดดเด่นโดย Anthony Mersino จะเป็นหนังสือแนะนำที่ฉันได้รับเมื่อวานนี้จากมื้อกลางวันและเรียนรู้เกี่ยวกับ EQ หากคุณต้องการลึกลงไปในจิตวิทยาที่นี่จริงๆมีเครื่องมือโปรไฟล์บุคลิกภาพต่างๆที่สามารถใช้ได้เช่น Enneagram, รูปแบบทางสังคมและ MBTI

สุดท้ายพิจารณาสิ่งที่เป็นวัฒนธรรมใน บริษัท ของคุณ ความผิดพลาดบางอย่างเกิดขึ้นภายใต้พรมปูพื้นหรือไม่? ข้อร้องเรียนใหญ่หรือไม่ที่สามารถทำให้ใครบางคนมีปัญหาได้อย่างง่ายดายหรือไม่? พฤติกรรมใดบ้างที่ได้รับการตอบแทนหรือสนับสนุนและสิ่งใดบ้างที่สามารถยอมรับและยอมรับได้ ในขณะที่บางสิ่งนี้เป็นข้อสังเกตบางอย่างก็อาจจำเป็นต้องมีการสนทนาบางอย่างที่ควรจะอยู่ห่างจากสำนักงานหรือในห้องที่ไม่มีแนวโน้มที่จะแอบฟัง คุณอาจจะซ้ำ ๆ ในการพยายามใช้สิ่งนี้ในการเริ่มต้น นั่นไม่ใช่เรื่องเลวร้ายถ้าคุณพยายามสร้างแนวปฏิบัติใหม่และทำให้ผู้คนบนกระดานพูดได้ถ้าวัฒนธรรมเป็นสิ่งที่ทุกคนเพิ่งรู้จักเพื่อ "ดูดมัน" นี่อาจจะงี่เง่ากว่าคำตอบอื่น ๆ แต่นี่จะเป็นสิ่งที่ฉัน '

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

หากพวกเขารู้สึกชื่นชมคุณอาจจะมีการสื่อสารที่ดีขึ้น

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

ฉันรู้ว่านักพัฒนาบางคนฉลาดหลักแหลมทางสังคม แต่ฉันคิดว่าค่ามัธยฐานโน้มเอียงไปสู่คนเก็บตัว

เมื่อมีคนร้องขอให้ฉันทำบางสิ่งบางอย่างฉันจะไม่ทำการอนุมานและทำสิ่งที่ร้องขอ ดูเหมือนว่ามีผู้จัดการโครงการบางคนที่ฉันมักจะเจอปัญหาเพราะพวกเขาคาดหวังให้ฉันทำการอนุมานเกี่ยวกับโครงการของพวกเขาซึ่งฉันจะไม่ทำอย่างแน่นอนดังนั้นบางครั้งสิ่งต่างๆก็ไม่ปรากฏตามที่พวกเขาคาดหวังแม้ว่าพวกเขาจะเป็นอะไรก็ตาม พวกเขาได้ร้องขอ ฉันคิดว่าเหตุผลที่สิ่งนี้เกิดขึ้นกับผู้จัดการโครงการบางคนเพราะพวกเขาไม่ได้ส่งมอบ HLD คุณภาพสูง BRDs และให้คุณค่าในด้านสังคมของการจัดการโครงการมากกว่าที่เป็นขาวดำ

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

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

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

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

คำตอบอื่น ๆ มากมายดีมาก - คุณควรพิจารณาการพัฒนาที่คล่องตัว คุณต้องการนักพัฒนาของคุณเพื่อเรียนรู้และเติบโตในบทบาทของพวกเขา แต่ถ้าคุณไม่ได้ฟังสิ่งที่นักพัฒนาของคุณพูด (หรือไม่ใช่!) คุณต้องดูแลก่อน

อ้างอิงที่ดีสำหรับตัวต่อตัว - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

สั้นและหวาน Excel ในสิ่งที่คุณทำ - สิ่งนี้จะทำให้เกิดการสื่อสาร

การพัฒนาที่ยอดเยี่ยมมีความหมายต่อนักพัฒนาของคุณอย่างไร .. อ่านอ่านใหม่ใช่แม้กระทั่งศึกษาPeopleWare

ความคิดและข้อคิดเห็นที่ยอดเยี่ยมทั้งหมดในโพสต์ด้านบน!

นี่คือแนวคิด: ส่งเจ้าหน้าที่ไอทีของคุณไปยังการประชุมเชิงปฏิบัติการการสื่อสารที่วิทยาลัยชุมชนในพื้นที่ของคุณ - แน่นอนว่าจ่ายโดย บริษัท

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

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

ความคิดนี้ไม่ได้เป็นสัญลักษณ์แสดงเวทย์มนตร์ แต่มันเป็นพื้นฐานที่ดีของปริศนา เพื่อนร่วมงานของคุณจะไม่เพียง แต่เรียนรู้ที่จะสื่อสารกันได้ดีขึ้น แต่จะได้รับโบนัสว่าพวกเขาจะเริ่มเข้าใจและเคารพงานของคุณได้ดีขึ้นเช่นกัน (การสื่อสารเป็นหัวใจหลักของ PM)

แค่ 2 บิตของฉัน :)

เพียงเพื่อให้ได้คำตอบจากคำแนะนำที่มีมาในคำตอบไม่กี่ คำแล้ว Michael Lopp (อาคาแรนด์ ) เขียนเกี่ยวกับการจัดการนักพัฒนาและ "เข้าหัว" ในบล็อกของเขาRands in Reposeและในหนังสือผู้จัดการมนุษย์ ( แหล่งที่มาของหนังสือ ) หนังสือเล่มนี้มีเนื้อหาที่ถูกแก้ไขส่วนใหญ่จากโพสต์ของเขาก่อนปี 2007 และเป็นวิธีที่ดีในการติดตามส่วนที่เกี่ยวข้องกับการจัดการของบล็อกของเขา (เขายังพูดถึงเรื่องการพนันเช่นและไม่ว่าคุณต้องการอ่าน โดยทั่วไปงานเขียนของเขานั้นยอดเยี่ยมและมักจะมีอารมณ์ขันดังนั้นจึงมีความเสี่ยงเพียงเล็กน้อยในการอ่านเขา

พาทีมออกไปดื่มเบียร์ (และคุณกำลังซื้อ)

ฉันไปงานปาร์ตี้สาย แต่เพิ่งเห็นคำถามนี้

สิ่งหนึ่งที่ฉันไม่เห็นดีมากคือ:

คำรามไม่เคยบอกความจริงทั้งหมดกับชุดสูท Rands กล่าวสิ่งนี้ในDNAแต่ไม่ได้พูดถึงเรื่องนี้อย่างจริงจังเขาอยู่ในหัวข้อที่ต่างออกไป

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

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

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

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

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

• การสนทนาที่ยากลำบาก: วิธีพูดคุยถึงสิ่งที่สำคัญที่สุด
• การสนทนาที่สำคัญ: เครื่องมือสำหรับการพูดคุยเมื่อเงินเดิมพันสูง
• การเผชิญหน้าที่สำคัญ: เครื่องมือสำหรับการแก้ไขสัญญาที่ไม่สมบูรณ์การละเมิดที่คาดหวังและพฤติกรรมที่ไม่ดี

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

อ่านนวนิยายที่ยอดเยี่ยมสองสามเรื่องซึ่งให้ข้อมูลเชิงลึกเกี่ยวกับมุมมองของบุคลากรด้านเทคนิค:

• แฮกเกอร์, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• มหาวิหารและตลาดนัด, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

สิ่งเหล่านี้มีความสำคัญเท่ากับ memoir ทั่วไปใด ๆ เกี่ยวกับการจัดการ (Drucker et al)

ฉันได้ทำหน้าที่หลากหลายในช่วงหลายปีที่ผ่านมา - นักพัฒนานักพัฒนาอาวุโสฝ่ายเทคนิค ฯลฯ

จากคำถามของคุณ - ค่อนข้างชัดเจนว่านักพัฒนาของคุณไม่ได้บอกอะไรคุณเพราะพวกเขาคิดว่าคุณไม่สามารถช่วยได้

อาจเป็นเพราะ 2 สาเหตุ

1. พวกเขาไม่คิดว่าคุณมีอำนาจในการแก้ไขปัญหา อย่างไรก็ตามฉันคิดว่ามันไม่น่าเป็นไปเพราะคุณอาจจะรู้และนักพัฒนาก็จะคร่ำครวญเรื่องนี้กับคุณ
2. คุณเป็นคนประเภทที่เมื่อนักพัฒนาซอฟต์แวร์มาหาคุณด้วยปัญหาทำสิ่งต่อไปนี้อย่างน้อยหนึ่งอย่าง
   • เมื่อพวกเขามาถึงคุณด้วยปัญหาคุณบอกพวกเขา - ฉันชอบการแก้ปัญหาไม่ใช่ปัญหา
   • คุณฟังพวกเขาอย่างดีและมอบหมายให้พวกเขาพร้อมแก้ไขปัญหา คุณให้พวกเขาพูดคุยเกี่ยวกับสิ่งที่เป็นเกียรติแก่พวกเขาจะได้รับความรับผิดชอบในการแก้ไขปัญหา เมื่อเวลาผ่านไปคนของคุณเข้าใจว่าเมื่อพวกเขาไปหาคุณพวกเขาจะจบลงด้วยการทำงานพิเศษดังนั้นพวกเขาจะไม่มาหาคุณด้วยปัญหา
   • คุณปฏิเสธว่าเป็นปัญหา คุณให้เหตุผลที่น่าเชื่อถือสำหรับเรื่องนี้ แต่เมื่อสิ่งนี้ยังคงเกิดขึ้นเมื่อเวลาผ่านไปคนของคุณจะรู้ว่าไม่มีประเด็นใดที่จะเข้าใกล้คุณด้วยปัญหา
   • คุณพูดว่า "ใช่ฉันเข้าใจ" คุณบอกว่าเรื่องแบบนี้เกิดขึ้นเป็นครั้งคราว & ไม่มีอะไรทำ ถ้านี่เป็นรูปแบบแล้วพวกคุณก็เข้าใจอีกครั้ง

หากเป็นข้อใดข้อหนึ่งหรือทั้งหมดข้างต้นคุณต้องแก้ไขให้ถูกต้อง

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

การปฏิบัติที่เลวร้ายที่สุดสำหรับฉันมักจะแต่งตัวเป็น "ดี" - โดยปกติแล้วผู้จัดการมีตัวเองหรือปริญญาตรีหรือใครบางคนเขียนรายละเอียดที่ develoeprs จะต้องตีความและนำไปใช้กับ timescales ตกลงไว้ล่วงหน้า

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

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

มันง่ายมากที่จะทำให้ทีมมีความสุข

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

การออกนอกทีมเป็นความคิดที่ดี (อาจเป็นแผนเกม)

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

ทำ 1: 1 ทุกๆ 2 เดือนกับสมาชิกในทีมทุกคนเพื่อให้แน่ใจว่าพวกเขาสบายใจ

ท้ายสุด แต่ไม่ท้ายสุดมันอาจเป็นความคิดที่ดีที่คุณจะเข้าใจโครงงานและใช้งานได้ดี

โปรดแจ้งให้เราทราบหากคุณมีคำถามเพิ่มเติม

ฉันยังเป็นผู้จัดการซอฟท์แวร์ภาษาฝรั่งเศสที่ให้อภัยด้วยพื้นฐานทางวิทยาศาสตร์ ดังนั้นฉันจึงไม่มีความเกี่ยวข้องเป็นพิเศษกับการเขียนโค้ดที่จุดเริ่มต้น แต่ฉันเป็นวิศวกรที่มีคุณภาพทางสถิติจากโรงเรียนเดมิงซึ่งมีการสอนที่แตกต่างกันอย่างมากสำหรับโรงเรียน "ทันสมัย" ทุกแห่งที่ตามมาแม้ว่าพวกเขาจะแกล้งสืบทอดจากเดมิง ที่แย่ที่สุดคือ 6 ซิกม่า, ลีนดีขึ้น แต่น่าเสียดายที่สิ่งที่เกิดขึ้นคือhttp://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“ เดิม Six Sigma นั้นได้มาจากการจัดการคุณภาพของโตโยต้า (Motorola) โดย Motorola เพื่อให้ได้คุณภาพซิกซิกมาถึงหกระดับและจาก Allied Signal และ GE มันได้ปรับเปลี่ยนไปสู่โครงการต่างๆโดย Black Belts ตามสถิติเพื่อเป็นโครงการลดต้นทุน - ทุกโครงการ ต้องการ ROI ที่ชัดเจน กล่าวอีกนัยหนึ่งเราปฏิเสธโครงการจากปรัชญาความเป็นผู้นำไปสู่โครงการหนึ่งครั้งเพื่อลดต้นทุน มันเป็นการทำให้สมบูรณ์แบบดั้งเดิมและไม่ค่อยนำไปสู่การเปลี่ยนแปลงที่ยั่งยืนและยั่งยืนเพราะผู้นำและวัฒนธรรมหายไป

“ สิ่งที่คล้ายกันเกิดขึ้นเมื่อมันลดลงเป็นชุดเครื่องมือ (เช่นการจับคู่ค่ากระแส, บอร์ด KPI, เซลล์, kanban)

“ Lean และ Six Sigma ไม่เคยสะท้อนความคิดดั้งเดิมของ บริษัท ญี่ปุ่นที่ยอดเยี่ยมหรือครูของพวกเขาอย่าง Deming”

วันนี้ขบวนการเปรียวก็เหมือนลีน (ดูหลักสูตรของ Jeff Sutherland และการให้เกียรติ Deming ของเขาhttp://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ) ดีกว่า Waterfall แต่ก็ยังห่างไกลจากคำสอนดั้งเดิมของ Deming เพราะแทนที่จะอ่าน Deming ในเนื้อความเดิมของเขา gurus เพิ่งบรรจุเขาใหม่โดยไม่ต้องอ้างหลักการจัดการทั้ง 14 ข้อของเขา และขายเครื่องมือและงานสัมมนาที่มีค่าเพียงเล็กน้อย

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

ดังนั้นสำหรับฉันผู้จัดการโครงการซอฟต์แวร์ควรใช้ความพยายามอย่างเต็มที่ในการปฏิบัติงานประจำวันของการเขียนโปรแกรมซอฟต์แวร์ไม่ใช่แค่การวางแผนในโครงการ Microsoft (หรือแผนภูมิ Burdown กับ Agile) หรือการนำเสนอที่ดีใน Powerpoint ไปจนถึงการจัดการด้านบน ทีมนักพัฒนา เมื่อทีมนักพัฒนาซอฟต์แวร์มีปัญหาแม้ว่าจะเป็นปัญหาทางเทคนิคผู้จัดการโครงการสามารถช่วยปรับทิศทางการวินิจฉัยด้วยสายตาภายนอก เขาสามารถดูรหัสได้แม้ว่าเขาจะไม่เข้าใจรายละเอียดเล็ก ๆ น้อย ๆ เขาสามารถถามคำถามที่ไร้เดียงสาซึ่งอาจทำให้นักพัฒนาตระหนักว่าพวกเขาไม่ได้คิดถึงเบาะแสนั้น (ฉันมีตัวอย่างส่วนตัวมากมาย แต่ยาวเกินไปดังนั้นฉันจะ ค่อนข้างเขียนบทความในบล็อกของฉัน)

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

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

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