สัญญาณเหล่านี้ของผู้พัฒนาที่ไม่ดีหรือไม่? [ปิด]

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

แต่ตอนนี้ฉันเห็น 'whinges' อื่น ๆ ในตัวฉัน ไม่กี่ครั้งเมื่อเร็ว ๆ นี้ฉันพบว่าตัวเองกำลังพูดว่า 'มันเหมือนกับพยายามที่จะใส่หมุดสี่เหลี่ยมในรูกลม' และฉันก็พบว่าตัวเองกำลังตำหนิลูกค้าที่ไม่แน่ใจในโครงการที่ไม่คืบหน้า

มีสัญญาณใดบ้างที่ฉันควรระวังในการเปลี่ยนทัศนคติของฉัน ไคลเอนต์ถูกต้องเสมอหรือบางครั้งฉันเป็นธรรมในการผิดหวัง?

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

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

การคงความเป็นจริงของสเป็คดั้งเดิมไม่เป็นจริง ยังไม่เป็นจริงคือการเปลี่ยนแปลงข้อกำหนดตลอดเวลา

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

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

มีหลายกรณีที่เป็นลูกค้า แต่นั่นก็เป็นปัญหาของคุณเช่นกัน

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

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

จิตใจแบบเซน: อย่าตัดสินเพียงแค่เห็นมันเป็นอย่างนั้น

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

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

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

ความต้องการที่เปลี่ยนแปลงนั้นเป็นความจริงของชีวิต แต่รหัสเน่าไม่ได้เกิดจากการที่

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

ใช่มันเป็นความผิดของคุณและไม่ใช่ของผู้ใช้

ทางออกที่แท้จริง? ทดสอบทุกรหัสของคุณบ่อย แน่นอนวิธีที่ดีที่สุดคือการทดสอบอัตโนมัติที่มีความครอบคลุมที่ดี

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

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

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

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

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

เมื่อคุณโต้ตอบกับลูกค้าคุณไม่ได้เขียนโปรแกรม คุณกำลังเรียนและสอน

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

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

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

เมื่อคุณอยู่กับลูกค้าให้ความสนใจกับพวกเขามากกว่าใครหรือสิ่งอื่นใดในห้อง สุนัขในบ้านเป็นอัจฉริยะในเรื่องนี้ โดยเฉพาะถ้าคุณมีอาหาร

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

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

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

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

(แน่นอนว่านี่เป็นข้อแก้ตัวในกรณีที่คุณต้องการคุณควรวางแผนให้พวกเขาเปลี่ยนแปลงบางอย่างเสมอ )

ในใบเสนอราคาของ Emerson "ความสอดคล้องโง่หลอกเด็กของจิตใจของเล็ก ๆ น้อย ๆ ..." ส่วนใหญ่มักจะมองข้ามคำว่าโง่ ความสอดคล้องไม่สามารถต่อรองได้ในการตั้งค่าบางอย่าง แต่มันมักจะทดแทนสำหรับความคิดที่สำคัญและการวิเคราะห์

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

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