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

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

แก้ไข:

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

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

สองคำ: เรื่องราวของผู้ใช้

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

1. พวกเขาต้องคิดเกี่ยวกับสิ่งที่หน้า / คุณสมบัติที่ควรทำ
2. เมื่อคุณขอรายละเอียดเพิ่มเติม ("แล้ว? ... และจากนั้น ... ... ") พวกเขาเริ่มเข้าใจว่าสิ่งทั้งหมดจะไม่เกิดขึ้นโดยการมี Magic Space Monkeys ™บินเข้ามาและทำ มันมากกว่าวันหยุดสุดสัปดาห์
3. พวกเขากลายเป็นหุ้นส่วนที่แท้จริงในกระบวนการสร้าง ซึ่งหมายความว่าพวกเขาจะเข้าใจว่าทำไมการเปลี่ยนใจเกี่ยวกับบางสิ่งที่สมบูรณ์แล้ว 80% จะทำให้ a) การเลื่อนกำหนดการล่าช้าและ b) การเพิ่มต้นทุน

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

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

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

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

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

นี่ไม่ใช่ปัญหาเสมอไป

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

เกิดอะไรขึ้นถ้ามันเป็นปัญหา

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

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

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

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

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

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

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

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

ฉันเคยเห็นงาน "ฉันต้องได้ทั้งหมด" ใน 2 กรณี หนึ่งในลูกค้าทางการเงินขนาดใหญ่ (ใช้น้ำตกของทุกสิ่ง) มี 40 ระบบที่แตกต่างกัน (บริษัท ของเราทำให้หนึ่งใน 40) ได้รับการแทนที่และทำให้การดำเนินงานในหนึ่งก้ม การทดสอบบูรณาการและการสื่อสารเป็นปัญหาใหญ่ ประมาณการของฉันคือพวกเขาเผาประมาณ $ 100k / วันในการประชุมทางโทรศัพท์ (เมื่อคุณนับอัตราการเรียกเก็บเงินของทุกคนในการโทร) ในทั้งสองกรณีมันต้องใช้การเจรจาอย่างหนักแน่นเพื่อจัดทำรายการสิ่งที่จะส่งมอบและจากนั้นตอกเท้าของทุกคนลงไปที่พื้น ไม่มีการเคลื่อนไหวของเสาประตูไม่มีการเจรจาใหม่ ทั้งสองงานจบลงตรงเวลาและตามข้อกำหนด หนึ่งคือวิธีที่เกินงบประมาณอื่น ๆ คือในงบประมาณ สำหรับสิ่งนี้คุณต้องการผู้จัดการโครงการที่ดีมากที่รู้ว่าทีมของพวกเขาสามารถส่งมอบได้อย่างไร (ประเภทที่สามารถพูดได้ว่าฟีเจอร์ Q ใช้เวลา 3

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

คำตอบสั้น ๆ :ฉันจะฟังลูกค้าของฉันและหาทางเข้าใกล้พวกเขา

ฉันขอแนะนำให้ฟังลูกค้าและขึ้นอยู่กับงบประมาณและเวลาของพวกเขาแบ่งโครงการออกเป็นเฟส (รีลีสรีลีส 2 ฯลฯ )

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

ดังนั้นการกำหนดขอบเขตของงานและสิ่งที่ส่งมอบเป็นวิธีที่จะไป :)

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

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

• ไปทั่วโลกผ่านคุณสมบัติและกลั่นหมวดหมู่จากพวกเขา
• จัดลำดับความสำคัญ (ใช้ MoSCoW) หมวดหมู่และอาจกำหนดลำดับชั้น (หมวดหมู่พื้นฐานหนึ่งหมวดที่มีคุณสมบัติเริ่มต้นหมวดหมู่สำหรับวิชาหลักหมวดหมู่สำหรับรูปแบบเฉพาะของหัวข้อหลัก) สิ่งนี้อาจเปลี่ยนหมวดหมู่ที่คุณกำหนดไว้ในขั้นตอนก่อนหน้า (ขอบคุณข้อมูลเชิงลึกใหม่)
• ผ่านแต่ละคุณสมบัติหนึ่งและกำหนดให้หมวดหมู่
• จัดลำดับความสำคัญ (ใช้ MoSCoW) รายการในหมวดหมู่ top-x

นี่จะให้มุมมองจากบนลงล่างที่ดีและย่อของคุณสมบัติที่คุณต้องการและจะให้แฮนด์บาร์เพื่อกำหนดการวนซ้ำที่แตกต่างกันเพื่อเริ่มต้นด้วยฐานและขยายด้วยคุณสมบัติอื่น ๆ