วิธีการขายการพัฒนา Agile ให้กับลูกค้า (น้ำตก)

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

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

กุญแจสำคัญในการทำสิ่งนี้ให้ดีคือการใช้สัญญาการสนับสนุน

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

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

หากมีการเปลี่ยนแปลงใด ๆ เกิดขึ้นในระหว่างโครงการให้เลื่อนไปที่การจัดการภายใต้ฝ่ายสนับสนุน (สมมติว่าการเปลี่ยนแปลงนี้จะทำให้เกิดการหยุดชะงักอย่างร้ายแรงต่อโครงการ)

เงื่อนไขของการติดต่อฝ่ายสนับสนุนมีดังนี้“ งานที่ต้องทำในแต่ละชั่วโมงตามที่ลูกค้าร้องขอสามารถใช้สำหรับคำขอเปลี่ยนแปลงหรือสนับสนุนระบบทั่วไปและการบำรุงรักษา ” BAM! คุณอยู่ในเปรียว

จากนั้นคุณสามารถขยายการติดต่อการสนับสนุนและใช้การติดต่อการสนับสนุนเป็นวิธีการเรียกใช้โครงการใหม่ นอกจากนี้หากมีการซื้อและชำระเงินล่วงหน้าสำหรับเวลาเหล่านี้เรามักจะให้ส่วนลดแก่ลูกค้า 15% มันคือวิน - วิน

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

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

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

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

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

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

สิ่งที่อาจเป็นไปได้ในสถานการณ์ดังกล่าวกำลังแสดงให้พนักงานขายเห็นว่าการขับรถผ่านหุบเขานั้นเป็นอย่างไร ทุกเทิร์นมีเซอร์ไพรส์ มันเป็นไปไม่ได้ที่จะเห็นมากกว่าสามเดือนแล้วดังนั้นหากลูกค้าขอโครงการ 18 เดือนมันจะไม่สามารถจดจำได้เมื่อคุณใกล้จะเสร็จ ดังนั้นตัวแทนฝ่ายขายของคุณต้องเริ่มต้นด้วยการค้นหาผลตอบแทนทางการเงินของโครงการ นี่จะเพิ่มยอดขาย 10 ล้านเหรียญหรือไม่ ถ้าเป็นเช่นนั้นจะมีมูลค่าการลงทุน 2,000,000 เหรียญเพื่อสร้างรายได้เพิ่มอีก $ 10 ล้านหรือไม่ หากลูกค้าและตัวแทนฝ่ายขายกำลังมารวมกันที่ความมุ่งมั่น $ 500,000 สิ่งที่อาจผิดและไม่มีใครสามารถบอกได้ว่ามันคืออะไร - มันแค่รู้สึกไม่ถูกต้อง สิ่งที่ 'รู้สึกไม่ถูกต้อง' คือความมุ่งมั่นที่จะทำสิ่งที่เสี่ยงต่อการไร้ประโยชน์

เครื่องบินเจ็ทสายการบิน Jet ทั้งสองรุ่นล่าสุดมีประวัติ Snafus Healthcare.gov ไม่จำเป็นต้องมีการอภิปราย หากคุณสามารถหาหนังสือหรือเรื่องราวการค้าขายกับสายการบินคุณสามารถแสดงให้เห็นว่าสมมติฐานบางอย่างได้รับการพิสูจน์แล้วว่าเป็นแง่ดี บ่อยครั้งนี้เกิดจากการประเมินความซับซ้อนต่ำเกินไป หากคุณไม่สามารถเข้าใจได้ว่ามันซับซ้อนแค่ไหนจนกระทั่งคุณเริ่มเขียนโค้ดคุณจะต้องมี 'รอบแรก' เพื่อให้ได้แนวคิดที่ดีขึ้นเกี่ยวกับปัญหาจริง การตัดงบประมาณควรเป็นเศษส่วนของกำไรเพิ่มเติมทั้งหมด (หรือรายได้ในบางกรณี) และจำนวนนั้นจะต้องมากกว่าที่ทุกคนคิดว่าโครงการปัจจุบันจะมีค่าใช้จ่าย หากคุณสามารถแสดงให้เห็นว่าการก้าวครั้งสุดท้ายสามารถทำได้โดยไม่เกิน 'ขีด จำกัด การจ่ายผลตอบแทน'

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

ข้อกำหนดเบื้องต้นขององค์กรทั่วไปสี่ประการดังแสดงด้านล่าง:

• บริษัท ยักษ์ใหญ่ระดับโลก - ในองค์กรเมทริกซ์ลำดับชั้นเหล่านี้การควบคุมพอร์ตโฟลิโอจากบนลงล่างคือกฎประจำวัน วิธีเปรียวอิสระมีช่วงเวลาที่ยากลำบากในการปรับให้เข้ากับการควบคุมที่เข้มงวด โดยเฉพาะอย่างยิ่งแนวคิดปลอดแผน Agile โดยธรรมชาติทำให้ Agile-Scrum ยากสำหรับองค์กรที่จะกลืน

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

• ผลิตภัณฑ์ที่กำหนดไว้ล่วงหน้าที่ซับซ้อน - ผลิตภัณฑ์แบบครบวงจรบางอย่างซึ่งรวมถึงฮาร์ดแวร์ซอฟต์แวร์ฝังและอื่น ๆ ได้รับการพัฒนาเป็นสัญญากับลูกค้าปลายทางภายใต้ข้อกำหนดที่กำหนดไว้ล่วงหน้า ในกรณีเหล่านี้ระดับความยืดหยุ่นของข้อกำหนดนั้นเล็ก แต่ก็ใหญ่กว่าที่คาดไว้ในตอนแรก แนวคิดของ backlog ที่มีความยืดหยุ่นอย่างเต็มที่ของ Agile-Scrum มีความทุกข์ทรมานอย่างมากในกรณีเหล่านี้

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

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

จากประสบการณ์จริงวิธีที่แนะนำในการแก้ไขสถานการณ์เหล่านี้และอื่น ๆ คือการเพิ่มขีดความสามารถของ PMO Agile ให้ทำหน้าที่เป็นตัวขับเคลื่อนคนขับและนักแปลระหว่างทีม Agile-Scrum ที่เกิดขึ้นใหม่และองค์ประกอบน้ำตกเชิงเส้น

อ้างถึงตารางด้านล่างสำหรับแนวทางเฉพาะ

แหล่งที่มา - การเชื่อมต่อระหว่างน้ำตกเชิงเส้นและแนวทางความคล่องตัวโดย Michael Nir

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

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

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

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

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

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

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

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

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

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

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

การพยายามใช้วิธี Agile ในสภาพแวดล้อมการให้คำปรึกษา / การเสนอราคาเป็นเรื่องยากมากเมื่อลูกค้าไม่ได้อยู่บนเรือ

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

Agile มีข้อได้เปรียบ (และข้อเสียแน่นอน) แต่ค่อนข้างตรงไปตรงมาลูกค้ามักจะไม่ทราบหรือใส่ใจในรายละเอียดเบื้องหลัง

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

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

พวกเขาไม่ได้สร้างซอฟต์แวร์พวกเขาส่วนใหญ่ไม่รู้ว่ามันทำงานผ่านคำพูดปากต่อปากได้อย่างไร

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

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

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

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

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

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

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

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

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

ติดต่อลูกค้าก่อนหน้าซึ่งมีความสุขกับงานของคุณ โดยเฉพาะถ้าพวกเขาเป็น Waterfall to Agile จะเปลี่ยน อย่างน้อยที่สุด Conversion ที่ไม่ใช่ลูกค้าของคุณ

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

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