DeMarco และ Lister (Peopleware) แนะนำให้คุณสร้าง "ลัทธิคุณภาพ" ภายในทีมการเขียนโปรแกรมของคุณ เฉื่อยชาพวกเขาไม่แนะนำให้คุณทำอย่างนั้น!
ใครมีความคิดเห็นเกี่ยวกับวิธีการทำสิ่งนี้ให้สำเร็จ
DeMarco และ Lister (Peopleware) แนะนำให้คุณสร้าง "ลัทธิคุณภาพ" ภายในทีมการเขียนโปรแกรมของคุณ เฉื่อยชาพวกเขาไม่แนะนำให้คุณทำอย่างนั้น!
ใครมีความคิดเห็นเกี่ยวกับวิธีการทำสิ่งนี้ให้สำเร็จ
คำตอบ:
ประสบการณ์ของฉันคือทีมพัฒนา (แต่โดยทั่วไปแล้วทีมใด ๆ ) ประกอบด้วย 3 คน:
กลุ่มสุดท้ายมีขนาดใหญ่ที่สุดและพวกเขามีแนวโน้มที่จะติดตามพรรคผู้ปกครอง หากมีคนที่มีคุณภาพเพียงพอในทีมพวกเขาสามารถดึงเสียงข้างมากด้วยตัวเองสร้างเกลียวขึ้นแข็งแกร่งในจิตวิญญาณของทีมและแรงจูงใจ อย่างไรก็ตามหากมีคนหย่อนมากเกินไปพวกเขาสามารถสร้างเอฟเฟกต์ตรงกันข้ามซึ่งเป็นเกลียวแห่งความตายได้อย่างง่ายดาย
ดังนั้นงานที่สำคัญสำหรับผู้จัดการที่จะเลือกและให้คนที่เหมาะสมและกำจัดคนไม่ดีโดยเร็ว ไม่ใช่ "คนธรรมดา" - พวกเขาอาจได้รับอิทธิพลจากการเริ่มต้นปรับปรุงเพื่อให้การสนับสนุนความคิดที่ดีของผู้อื่นและในที่สุดบางคนก็อาจกลายเป็นผู้กำหนดแนวโน้มในเชิงบวกด้วยตนเอง
[Update2]สะท้อนคำตอบของ Alb : IMO ไม่จำเป็นที่นักพัฒนาคุณภาพจะต้องเป็นคนส่วนใหญ่ในทีม (แม้ว่ามันจะไม่เจ็บ :-) มี"เกณฑ์การตั้งค่าแนวโน้ม"ด้านบนซึ่งมุมมองและพฤติกรรมของกลุ่มย่อยสามารถกลายเป็น "กระแสหลัก" ในชุมชนได้อย่างรวดเร็วดังนั้นคนอื่นจะสังเกตเห็นและเริ่มติดตาม คุณสามารถเห็นสิ่งนี้ในการทำงานในสังคมขนาดใหญ่ตลอดเวลา (เช่น (ไม่)) นิสัยการสูบบุหรี่, สุขภาพและอาหาร, ป๊อปแฟชั่น, อาหารออร์แกนิก) การประมาณคร่าวๆของฉันคือมันสามารถอยู่ที่ไหนสักแห่งประมาณ 25-30% แต่ขึ้นอยู่กับปัจจัยหลายอย่าง นี่คือที่คนเลวสามารถทำร้ายได้มาก แม้แต่คนไม่ดีสองคนในทีมของคุณก็สามารถเพิ่มขีด จำกัด นั้นได้อย่างมาก [/ Update2]
แน่นอนว่ามันเป็นไปไม่ได้เสมอที่จะจ้างคนชั้นนำมากพอ ดังนั้นเมื่อฝ่ายแรกไม่แข็งแรงพอที่จะขับเคลื่อนสิ่งต่าง ๆ ด้วยตัวเองฝ่ายบริหารจำเป็นต้องช่วยเหลือพวกเขา คู่ของความคิดเกี่ยวกับเรื่องนี้:
ฉันคิดว่า Scrum มีความคิดที่ดีสำหรับเรื่องนี้ด้วยการสาธิตผลิตภัณฑ์ แสดงให้เห็นถึงคุณลักษณะที่คุณใช้งานต่อหน้าผู้ชมซึ่งไม่เพียง แต่เป็นเพื่อนร่วมทีมของคุณ แต่อาจเป็นนักพัฒนาจากทีมอื่นการจัดการหรือแม้แต่ผู้ใช้แอปอาจเป็นแหล่งความภาคภูมิใจขนาดใหญ่และเป็นปัจจัยที่แข็งแกร่ง
อีกสิ่งหนึ่งสำหรับการจัดการเพื่อฟังอย่างจริงจังกับทีมพัฒนาเกี่ยวกับคุณภาพ DeMarco และ Lister ยังพูดถึงว่ามี บริษัท / แผนกต่างๆที่ทีมงาน dev มีส่วนร่วมในการยับยั้งการผลิต หากพวกเขารู้สึกว่าแอพยังไม่พร้อมสำหรับช่วงเวลาสำคัญพวกเขาสามารถเลื่อนการเปิดตัวโดยไม่คำนึงถึงสิ่งที่ผู้บริหารต้องการ ตอนนี้มันเป็นเรื่องยากสำหรับการจัดการ แต่ฉันสามารถจินตนาการได้ว่ามันสร้างจิตวิญญาณของทีมและสื่อสารอย่างจริงจังกับข้อความว่าคุณภาพมีความสำคัญจริงๆที่นี่ไม่ใช่แค่ในระดับของคำ
สิ่งนี้นำไปสู่ประเด็นต่อไป: ในการสร้าง "ลัทธิของคุณภาพ" การจัดการต้องเข้าใจอย่างถ่องแท้ว่านักพัฒนาที่มีประสบการณ์ส่วนใหญ่รู้อยู่แล้ว: คุณภาพนั้นไม่ได้เป็นสิ่งที่ต้องทำในภายหลัง ดังนั้นทุกคนควรจะได้รับการสนับสนุน (และได้รับรางวัลสำหรับ!) คิดเกี่ยวกับการบำรุงรักษาระยะยาวที่มุ่งมั่นในการที่ดีการแก้ปัญหาแทนการอย่างรวดเร็วคน
@Machado ในความคิดเห็นของเขาให้บิดใหม่กับคำถาม (กับฉันอย่างน้อย):
ฉันในฐานะสมาชิกในทีมไม่ใช่ผู้จัดการสามารถปรับปรุงคุณภาพรหัสของทีมได้อย่างไร
ความคิดเล็กน้อย:
และสุดท้าย แต่ไม่น้อย: หาสถานที่ที่คุณสามารถจะเป็น "คนด้านบนเป็น" หากคุณอยู่ในกลุ่ม "ปานกลาง" ตอนนี้พยายามพัฒนาตัวเองหวังว่าแนวคิดข้างต้นจะช่วยได้ แต่ถ้าคุณอยู่ใน "ระดับล่าง" ในทีมปัจจุบันของคุณฉันขอแนะนำให้คุณวิเคราะห์เหตุผล อะไรที่ทำให้คุณลดระดับลง สภาพการทำงานไม่ดี? เพื่อนร่วมทีม? การบริหารจัดการ? ประเภทของงาน? และอะไรที่ทำให้คุณตื่นเต้นและสนใจ? คุณอาจต้องคุยกับเพื่อนร่วมงานและ / หรือเจ้านายเกี่ยวกับเรื่องนี้ หรือคุณอาจต้องมองหางานที่ดีกว่า - หรือแม้กระทั่งอาชีพใหม่ - ซึ่งคุณสามารถเริ่มส่องแสง มันไม่คุ้มค่าที่จะใช้จ่ายส่วนสำคัญของชีวิตด้วยกิจกรรมที่ไม่น่าพอใจหรือหดหู่
อาจเป็นเพราะคุณถูกบังคับให้ทำงานในปัจจุบันของคุณต่อเนื่องเนื่องจากปัจจัยภายนอก (ขาดโอกาสในการทำงานที่ดีกว่าต้องจ่ายบิล ฯลฯ ) - มันเกิดขึ้นทุก ๆ ครั้ง แม้ในกรณีนี้พยายามทำให้ดีที่สุด การผลิตงานที่มีคุณภาพ (เท่าที่สถานการณ์เอื้ออำนวย) เป็นรางวัลในตัวเองซึ่งจะช่วยให้คุณรู้สึกภาคภูมิใจในตนเองและทำให้ตัวเองมีสติและเปิดกว้างในระยะยาว ดังนั้นเมื่อมีโอกาสสำหรับสิ่งที่ดีกว่าปรากฏขึ้นคุณก็พร้อมที่จะรับมันไป
คำตอบที่ยอดเยี่ยมโดยPéterTörökเพื่อเน้นว่าคุณจะจัดการสิ่งนี้กับคนดีส่วนใหญ่เท่านั้น เมื่อคุณมีคนดีแล้วคุณต้องตั้งเป้าหมายแครอทให้มากกว่าที่จะทำ ให้อำนาจผู้พัฒนาปล่อยให้พวกเขาเป็นเจ้าของโครงการ / งานและส่งเสริมการแข่งขันในด้านคุณภาพบางทีอาจมีคนเสนองานสั้น ๆ เกี่ยวกับวิธีที่พวกเขาปรับปรุงคุณภาพในโครงการ นักพัฒนาที่ดีจะมีแรงจูงใจในการสร้างความประทับใจให้กับเพื่อนร่วมงาน
นอกเหนือจากความเห็นของปีเตอร์ (ซึ่งเป็นประเด็นหลัก) คุณต้องตรวจสอบให้แน่ใจว่าคุณภาพไม่ใช่คุณสมบัติที่เพิ่มเข้ามาในภายหลัง
โดยเฉพาะอย่างยิ่ง:
ฉันจะบอกว่าวิธีที่ดีที่สุดคือการส่งเสริมคุณภาพมากกว่าผลผลิต นี่คือหนึ่งในสถานที่ของการเคลื่อนไหวของซอฟต์แวร์ลีน (อิงจากการผลิตแบบลีน) ผมเคยเขียนบล็อกโพสต์ยาวถกสิ่งลีนเป็นข้อมูลเกี่ยวกับ ฉันบอกวิธีสร้างลัทธิคุณภาพ ลงทุนในพนักงานของคุณและให้พวกเขาลงทุนใน บริษัท ของคุณ (ไม่ใช่การลงทุนทางการเงิน แต่เป็นการลงทุนส่วนตัว)
แดนพิ้งค์ได้พูดคุยกับTED อย่างมากเกี่ยวกับสิ่งที่กระตุ้นเรา ในขณะที่เขาไม่ได้อ้างอิงโดยเฉพาะ ลำดับขั้นของความต้องการของมาสโลว์อธิบายปรากฏการณ์ที่สังเกตได้อย่างสมบูรณ์แบบ ตราบใดที่นายจ้างจัดการกับความต้องการสองประการแรก (เช่นจ่ายเงินให้เพียงพอเพื่อที่เงินจะไม่เป็นปัญหา) สิ่งที่เหลืออยู่คือการมีค่านิยมและการทำให้เป็นจริงด้วยตนเอง
คุณภาพไม่ใช่สิ่งที่สามารถกำหนดได้ ... แต่มันเปิดใช้งานอยู่ ให้ความไว้วางใจพนักงานของคุณเพื่อทำสิ่งที่ดีที่สุด ในที่สุดคุณจะต้องบอกพวกเขาว่าพวกเขาต้องจากไป แทนที่จะขอให้พวกเขาวางในอีกหลายชั่วโมง