Agile สามารถทำได้โดยไม่ต้องมีส่วนร่วมของลูกค้า?

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

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

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

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

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

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

เนื่องจากลูกค้าต้องการ "Big Design Up Front" ช่วยให้พวกเขาเข้าใจว่าจะต้องใช้เวลาและความพยายามในส่วนของพวกเขาเพื่อให้ได้การออกแบบที่ถูกต้องในครั้งแรก

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

จากประสบการณ์ของฉันน้ำตกไม่ทำงาน

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

ลูกค้าไม่ทราบว่าสิ่งที่พวกเขาต้องการจนกว่าพวกเขาจะเห็นมัน

นี่คือตำนาน ตัวใหญ่เช่นกัน นี่อาจเป็นกรณีในการออกแบบ / เลย์เอาต์หน้าเว็บ แต่สำหรับการประมวลผลข้อมูลทางธุรกิจผู้ใช้ส่วนใหญ่ต้องการบางสิ่งที่ใช้งานได้ ผู้ใช้เหล่านั้นบางส่วนยังคงใช้หน้าจอ AS / 400 และ 3270 CICS มอนิเตอร์ที่มี RGB และพวกเขาสามารถทำธุรกิจของพวกเขาด้วยเครื่องมือเหล่านั้น นอกจากนี้ผู้ใช้เหล่านั้นก็ยอมรับระบบ SAP และ ORACLE ERP โดยไม่ต้องมีคำพูดใด ๆ ในการออกแบบส่วนต่อประสาน (และบางครั้งในการใช้งาน) ผู้ใช้ทางธุรกิจส่วนใหญ่จะปรับเปลี่ยนนิสัยการทำงานและการไหลหากระบบกำลังผลิตฟังก์ชั่นที่ถูกต้อง ความเครียดที่นี่อยู่ในฟังก์ชั่นไม่ได้ดู นักธุรกิจเข้าใจว่าพวกเขาทำงานได้ดีเพียงใด 90%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

แต่ในบางจุดคุณจะต้องแสดงซอฟต์แวร์ให้กับลูกค้า 'ของจริง' ...

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

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

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

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

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

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

กำหนดลูกค้า

เป็น บริษัท อื่นหรือไม่ อีกคน?

เป็นทีมอื่นใน บริษัท ของคุณหรือไม่

เป็นแชมป์ผลิตภัณฑ์ใน บริษัท ของคุณหรือไม่?

ที่เป็นคุณ?

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

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

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

ฉันเป็นลูกค้าของความตั้งใจและวัตถุประสงค์ทั้งหมดสำหรับโครงการเดี่ยวของฉัน ฉันยังสวมหมวกจริงบางครั้งเมื่อฉันต้องการจริงๆที่จะทำให้เกิดการเปลี่ยนแปลงทางจิตโดดเด่นในของฉันบทบาทของลูกค้า สิ่งนี้ทำให้ฉันมีความคล่องตัวไม่น้อยไปกว่าตอนที่ฉันทำงาน สำหรับทุกสิ่งที่ฉันสนใจแมวของฉันสามารถเป็นผู้จัดการได้. เขาทำให้แน่ใจว่าฉันได้พักบ้างทุกครั้งและเตือนฉันให้หลีกเลี่ยงการทำงานหนักเกินไป คุณอาจต้องการใช้ "Pomadoro Technique" แฟนซีของฉัน แต่ฉันชอบตัวจับเวลา "Rascal" !! สิ่งนี้คือฉันทำงานในกระบวนการ Agile อย่างเคร่งครัดทุกครั้งที่ฉันเขียนโค้ดด้วยตัวเอง ฉันไม่ได้เป็นคาวบอยแฮ็กเกอร์มาซึ่งมีชีวิตอยู่กับการพัฒนาที่ไม่มีที่สิ้นสุดและไม่ทำอะไรเลย ฉันชอบสร้างซอฟต์แวร์กำหนดเวลาการพัฒนารอบการทำงานและชีวิตส่วนตัวของฉันและทำให้เสร็จในลักษณะที่ฉันคาดว่าจะทำหากฉันทำงานให้กับลูกค้าจริง เมื่อสิ่งต่าง ๆ ขัดจังหวะกำหนดเวลาของฉันฉันปรับและจัดลำดับความสำคัญโครงการของฉันทำงานตาม ฉันใช้วิธีปฏิบัติและเทคนิค Agile มาตรฐานทั้งหมดที่ฉันสามารถใช้โซโลและฉัน "ส่ง" รหัสการทำงานให้กับตัวเอง (หรือเพื่อนหรือเพื่อนร่วมงานเพื่อทดสอบ) บ่อยเท่าที่ฉันสามารถ หากทั้งหมดนี้ไม่ใช่ Agile ฉันถามคุณว่าอะไร

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

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