โปรแกรมเมอร์ควร“ คิด” สำหรับลูกค้าหรือไม่

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

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

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

เราจะจัดการกับปัญหาของ "การคิดเพื่อลูกค้า" ได้อย่างไรโดยไม่ต้องโกรธด้วยคำถามมากเกินไป?

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

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

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

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

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

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

หากคุณ 'ฉี่พวกเขาออก' จากคำถามมากเกินไปให้รับลูกค้าที่ดีขึ้น

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

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

อ่านข้อมูลนี้เพิ่มเติมได้ที่: http://www.joelonsoftware.com/articles/fog0000000356.html

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

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

หากคุณต้องการรวบรวมจากนั้นก็เป็นหน้าที่ของคุณที่จะถามคำถามเหล่านี้

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

ผลข้างเคียงของสิ่งนี้คือคุณควรจะช่วยลูกค้าปรับแต่งความต้องการของพวกเขา

สิ่งนี้ใช้ไม่ว่าคุณจะทำ Big Design Up Front หรือ Agile

น่าเศร้าที่มันเป็นหน้าที่ของคุณที่จะคิดถึงลูกค้าถ้าเขาทำไม่ได้หรือไม่ทำเอง

ฉันมีผลลัพธ์ที่เป็นไปได้ทั้งสอง:

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

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

การพัฒนาแอปพลิเคชันอย่างรวดเร็ว (RAD)แก้ปัญหานี้ได้ดี

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

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

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

หากลูกค้าไม่พอใจกับสิ่งที่ส่งมอบนั่นเป็นเพียงชัยชนะของ Pyrrhic

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

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