นามธรรม
หนังสือเล่มนี้เป็นอัลกอริธึมแบบบรรยายสำหรับดำเนินกระบวนการพัฒนาจากแนวคิดไปสู่การนำไปปฏิบัติโดยใช้เทคนิคที่คล่องตัว กระบวนการถูกจัดวางเป็นขั้นตอน และในแต่ละขั้นตอนจะมีการระบุวิธีการสำหรับขั้นตอนกระบวนการ ผู้เขียนชี้ให้เห็นว่าวิธีการส่วนใหญ่ไม่ใช่วิธีการดั้งเดิม โดยไม่อ้างว่าเป็นวิธีการดั้งเดิม แต่รูปแบบการเขียนที่ดีและกระบวนการที่สมบูรณ์ทำให้หนังสือเล่มนี้มีประโยชน์มาก
เทคนิคสำคัญของการแมปเรื่องราวของผู้ใช้คือการจัดโครงสร้างแนวคิดและประสิทธิภาพในขณะที่ผู้ใช้ดำเนินการตามกระบวนการ
ในขณะเดียวกันก็สามารถอธิบายกระบวนการนี้ได้หลายวิธี คุณสามารถสร้างขั้นตอนเมื่อคุณบรรลุค่าคีย์ หรือคุณสามารถจินตนาการถึงวันทำงานของผู้ใช้ในขณะที่ใช้งานระบบ ผู้เขียนมุ่งเน้นไปที่ความจริงที่ว่ากระบวนการจำเป็นต้องได้รับการสรุป โดยพูดในรูปแบบของเรื่องราวของผู้ใช้บนแผนผังกระบวนการ ซึ่งเป็นสิ่งที่ให้ชื่อแผนผังเรื่องราวของผู้ใช้แก่เรา
ใครต้องการมัน
สำหรับนักวิเคราะห์ไอทีและผู้จัดการโครงการ ต้องอ่าน เล่มขนาดกลางอ่านง่ายอ่านเพลิน
จำ
ในรูปแบบที่ง่ายที่สุด นี่คือวิธีการทำงาน
ผู้เยี่ยมชมมาที่ร้านกาแฟ เลือกอาหาร สั่งซื้อ รับอาหาร รับประทานอาหาร และจ่ายเงิน
เราสามารถเขียนข้อกำหนดสำหรับสิ่งที่เราต้องการจากระบบในแต่ละขั้นตอนได้
ระบบควรแสดงรายการอาหาร โดยแต่ละจาน มีส่วนประกอบ น้ำหนัก และราคา และสามารถหยิบลงตะกร้าได้ เหตุใดเราจึงมั่นใจในข้อกำหนดเหล่านี้ สิ่งนี้ไม่ได้อธิบายไว้ในคำอธิบายข้อกำหนด “มาตรฐาน” และทำให้เกิดความเสี่ยง
นักแสดงที่ไม่เข้าใจว่าทำไมถึงจำเป็นมักจะทำสิ่งที่ผิด นักแสดงที่ไม่เกี่ยวข้องกับกระบวนการสร้างไอเดียจะไม่เกี่ยวข้องกับผลลัพธ์ Agile กล่าวว่า เราไม่ได้มุ่งเน้นไปที่ระบบเป็นหลัก แต่มุ่งเน้นไปที่ผู้คน ผู้บริโภค งาน และเป้าหมายของพวกเขา
เราสร้างบุคลิก ให้รายละเอียดเกี่ยวกับความเห็นอกเห็นใจ และเริ่มเล่าเรื่องราวจากด้านบุคลิก
Zakhar พนักงานออฟฟิศไปรับประทานอาหารกลางวันและต้องการทานของว่างง่ายๆ เขาต้องการอะไร? แนวคิดก็คือเขาอาจต้องการอาหารกลางวันเพื่อธุรกิจ อีกแนวคิดหนึ่งคือเขาต้องการให้ระบบจดจำความชอบของเขา เพราะเขากำลังควบคุมอาหาร อีกหนึ่งความคิด เขาต้องการให้นำกาแฟมาให้ทันทีเพราะเขาคุ้นเคยกับการดื่มกาแฟก่อนอาหารกลางวัน
และยังมีธุรกิจด้วย (ลักษณะองค์กร คือ ลักษณะที่แสดงถึงผลประโยชน์ขององค์กร) ธุรกิจต้องการเพิ่มเช็คเฉลี่ย เพิ่มความถี่ในการซื้อ และเพิ่มผลกำไร แนวคิดก็คือ - มานำเสนออาหารแปลกๆ บ้างดีกว่า อีกหนึ่งไอเดีย - มาแนะนำอาหารเช้ากันดีกว่า
แนวคิดสามารถและควรได้รับการทำให้เป็นรูปธรรม เปลี่ยนแปลง และนำเสนอในรูปแบบของเรื่องราวของผู้ใช้ ในฐานะพนักงานของศูนย์ธุรกิจ Zakhar ฉันต้องการให้ระบบจดจำฉันเพื่อที่ฉันจะได้รับเมนูตามความต้องการของฉัน ในฐานะพนักงานเสิร์ฟ ฉันต้องการให้ระบบแจ้งเตือนเมื่อถึงโต๊ะเพื่อให้ลูกค้าพึงพอใจกับบริการที่รวดเร็ว และอื่นๆ
เรื่องราวมากมาย ถัดไปคือการจัดลำดับความสำคัญและงานที่ค้างอยู่? Jeff ชี้ให้เห็นถึงปัญหาที่เกิดขึ้น: การจมอยู่กับรายละเอียดเล็กๆ น้อยๆ และการสูญเสียความเข้าใจเชิงแนวคิด บวกกับการจัดลำดับความสำคัญของฟังก์ชันการทำงานทำให้เกิดภาพที่ขาดหายเนื่องจากความไม่สอดคล้องกับเป้าหมาย
เส้นทางของผู้เขียน: เราไม่ได้จัดลำดับความสำคัญของฟังก์ชันการทำงาน แต่ผลลัพธ์ = สิ่งที่ผู้ใช้จะได้รับในที่สุด
จุดที่เห็นได้ชัดไม่ชัดเจน: เซสชันการจัดลำดับความสำคัญไม่ได้ดำเนินการโดยทั้งทีม เนื่องจากไม่ได้ผล แต่ดำเนินการโดยคนสามคน ฝ่ายแรกรับผิดชอบด้านธุรกิจ ฝ่ายที่สองเกี่ยวกับประสบการณ์ผู้ใช้ และฝ่ายที่สามรับผิดชอบในการนำไปปฏิบัติ
ให้เราเลือกขั้นต่ำสำหรับการแก้ปัญหาผู้ใช้หนึ่งราย (วิธีแก้ปัญหาขั้นต่ำที่เป็นไปได้)
เราให้รายละเอียดเกี่ยวกับแนวคิดที่มีลำดับความสำคัญเป็นลำดับแรกโดยใช้เรื่องราวของผู้ใช้ ภาพร่างการออกแบบ ข้อจำกัด และกฎเกณฑ์ทางธุรกิจบนแผนที่เรื่องราวของผู้ใช้ โดยการบอกและหารือกับทีมว่าผู้คนและผู้มีส่วนได้ส่วนเสียต้องการอะไรในแต่ละขั้นตอนของกระบวนการ เราปล่อยให้แนวคิดที่เหลือไม่ถูกตรวจสอบเป็นโอกาสที่ค้างอยู่
กระบวนการนี้เขียนบนการ์ดจากซ้ายไปขวา โดยมีแนวคิดอยู่บนการ์ดด้านล่างขั้นตอนกระบวนการ จำเป็นอย่างยิ่งที่จะต้องมีการหารือเกี่ยวกับเส้นทางตลอดเรื่องราวทั้งหมดร่วมกับสมาชิกในทีมเพื่อให้แน่ใจว่ามีความเข้าใจร่วมกัน
การอธิบายอย่างละเอียดในลักษณะนี้จะสร้างความสมบูรณ์ตามกระบวนการ
แนวคิดที่ได้รับจำเป็นต้องได้รับการทดสอบ สมาชิกที่ไม่ใช่สมาชิกในทีมสวมหมวกของบุคคลนั้นและใช้ชีวิตของบุคคลนั้นในหัวของเขาเพื่อแก้ไขปัญหาของเขา เป็นไปได้ว่าเขาไม่เห็นการพัฒนา การสร้างการ์ดขึ้นมาอีกครั้ง และทีมก็ค้นพบทางเลือกอื่นสำหรับตัวมันเอง
จากนั้นจะมีรายละเอียดสำหรับการประเมินผล สามคนก็พอแล้วสำหรับเรื่องนี้ รับผิดชอบประสบการณ์ผู้ใช้ นักพัฒนา ผู้ทดสอบ โดยถามคำถามยอดนิยม: "จะเกิดอะไรขึ้นถ้า..."
ในแต่ละขั้นตอน การอภิปรายจะเป็นไปตามแผนผังกระบวนการของประวัติของผู้ใช้ ซึ่งช่วยให้คำนึงถึงงานของผู้ใช้เพื่อสร้างความเข้าใจที่สอดคล้องกัน
เอกสารจำเป็นตามความเห็นของผู้เขียนหรือไม่? ใช่ ฉันต้องการมัน แต่เป็นบันทึกที่ช่วยให้คุณจดจำสิ่งที่คุณตกลงไว้ได้ การมีส่วนร่วมกับคนนอกอีกครั้งต้องมีการอภิปราย
ผู้เขียนไม่ได้เจาะลึกหัวข้อความเพียงพอของเอกสารโดยเน้นไปที่ความจำเป็นในการอภิปราย (ใช่ จำเป็นต้องมีเอกสาร ไม่ว่าผู้ที่ไม่มีความเข้าใจอย่างลึกซึ้งเกี่ยวกับ Agile จะอ้างสิทธิ์ในเอกสารนั้นได้อย่างไร) นอกจากนี้ การปรับปรุงความสามารถเพียงบางส่วนอาจนำไปสู่ความจำเป็นในการปรับปรุงระบบทั้งหมดใหม่ทั้งหมด ผู้เขียนชี้ให้เห็นถึงความเสี่ยงของการอธิบายรายละเอียดมากเกินไปในกรณีที่แนวคิดนั้นผิด
เพื่อขจัดความเสี่ยง จำเป็นต้องรับผลตอบรับอย่างรวดเร็วเกี่ยวกับผลิตภัณฑ์ที่สร้างขึ้นเพื่อลดความเสียหายจากการสร้างผลิตภัณฑ์ที่ "ผิด" เราร่างแนวคิด - ตรวจสอบความถูกต้องกับผู้ใช้ ร่างต้นแบบอินเทอร์เฟซ - ตรวจสอบความถูกต้องกับผู้ใช้ ฯลฯ (แยกกันมีข้อมูลเล็กน้อยเกี่ยวกับวิธีการตรวจสอบต้นแบบโปรแกรม) เป้าหมายของการสร้างซอฟต์แวร์โดยเฉพาะอย่างยิ่งในระยะเริ่มแรกคือการเรียนรู้ผ่านการตอบรับอย่างรวดเร็ว ดังนั้น ผลิตภัณฑ์แรกที่สร้างขึ้นจึงเป็นภาพร่างที่สามารถพิสูจน์หรือหักล้างสมมติฐานได้ (ผู้เขียนอาศัยผลงานของ Eric Ries เรื่อง “Startup with Lean methodology”)
แผนที่เรื่องราวช่วยปรับปรุงการสื่อสารเมื่อมีการดำเนินการกับหลายทีม สิ่งที่ควรอยู่บนแผนที่? สิ่งที่คุณต้องการเพื่อให้การสนทนาดำเนินไป ไม่ใช่แค่เรื่องราวของผู้ใช้ (ใคร อะไร ทำไม) แต่รวมถึงแนวคิด ข้อเท็จจริง ภาพร่างอินเทอร์เฟซ ฯลฯ...
ด้วยการแบ่งการ์ดบนแผนที่ประวัติศาสตร์ออกเป็นเส้นแนวนอนหลายเส้นคุณสามารถแบ่งงานออกเป็นรุ่นต่างๆ - เน้นขั้นต่ำเปล่าซึ่งเป็นชั้นของฟังก์ชันที่เพิ่มขึ้นและคันธนู
เราบอกเล่าเรื่องราวบนแผนที่กระบวนการ
มีพนักงานมารับประทานอาหารกลางวัน
เขาต้องการอะไร? ความเร็วในการให้บริการ เพื่อให้อาหารกลางวันของเขารอเขาอยู่บนโต๊ะหรืออย่างน้อยก็บนถาด อ๊ะ - ขั้นตอนที่พลาด: พนักงานอยากกิน เขาเข้าสู่ระบบและเลือกตัวเลือกอาหารกลางวันเพื่อธุรกิจ เขามองเห็นปริมาณแคลอรี่และคุณค่าทางโภชนาการเพื่อช่วยให้เขาควบคุมอาหารและไม่ทำให้น้ำหนักเพิ่มขึ้น เขาเห็นภาพจานนั้นเพื่อตัดสินใจว่าจะไปทานอาหารที่นั่นหรือไม่
ต่อไปเขาจะไปกินข้าวเที่ยงและมื้อเย็นไหม? หรือบางทีอาหารกลางวันจะถูกส่งไปที่ออฟฟิศของเขา? จากนั้นขั้นตอนคือการเลือกสถานที่รับประทานอาหาร เขาต้องการดูว่าสินค้าจะถูกส่งถึงมือเมื่อใดและมีค่าใช้จ่ายเท่าไร เพื่อที่เขาจะได้เลือกได้ว่าจะใช้เวลาและกำลังไปที่ไหน จะลงไปชั้นล่างหรือไปทำงาน เขาอยากเห็นว่าร้านกาแฟจะยุ่งแค่ไหนเพื่อไม่ให้คิววุ่นวาย
จากนั้นพนักงานก็มาที่ร้านกาแฟ เขาต้องการเห็นถาดของเขาเพื่อที่เขาจะได้หยิบไปทานอาหารเย็นได้โดยตรง คาเฟ่ต้องการรับเงินเพื่อสร้างรายได้ในการบริการ พนักงานต้องการเสียเวลาขั้นต่ำในการตั้งถิ่นฐานกับร้านกาแฟเพื่อไม่ให้เสียเวลาอันมีค่าไปอย่างไร้ประโยชน์ ทำอย่างไร? ชำระเงินล่วงหน้าหรือกลับกันหลังรับบริการจากระยะไกล หรือชำระเงิน ณ จุดเกิดเหตุโดยใช้ตู้คีออสก์ สิ่งที่สำคัญที่สุดเกี่ยวกับเรื่องนี้คืออะไร? มีกี่คนที่ยินดีจ่ายค่าอาหารกลางวันด้วยบัตรธนาคาร? มีกี่คนที่ไว้วางใจโรงอาหารแห่งนี้ให้เก็บหมายเลขบัตรไว้เพื่อชำระเงินซ้ำ หากไม่มีการวิจัยภาคสนาม ก็ไม่ชัดเจน จำเป็นต้องมีการทดสอบ
ในแต่ละขั้นตอนของกระบวนการคุณจะต้องมีฟังก์ชันการทำงานบางอย่างเพื่อสิ่งนี้คุณต้องใช้บุคคลเป็นพื้นฐานและเลือกสิ่งที่สำคัญกว่าสำหรับเขา (ตัวเลือกสามคนเดียวกัน) ติดตามเรื่องให้จบ = ทำทางออกได้จริง
ถัดมาเป็นรายละเอียด ลูกค้าต้องการทราบว่าร้านกาแฟมีความพลุกพล่านแค่ไหน จะได้ไม่รบกวนคิว เขาต้องการอะไรกันแน่?
ดูพยากรณ์ว่าจะมีคนมากี่คนใน 15 นาทีเมื่อเขาไปถึง
ดูเวลาให้บริการโดยเฉลี่ยในร้านกาแฟและการเปลี่ยนแปลงของร้านกาแฟล่วงหน้าครึ่งชั่วโมง
ดูสถานการณ์และการเปลี่ยนแปลงของการเข้าใช้โต๊ะ
จะเกิดอะไรขึ้นหากระบบพยากรณ์ให้ผลลัพธ์ที่ไม่ชัดเจนหรือหยุดทำงาน?
ชมวิดีโอคิวในร้านกาแฟตลอดจนจำนวนโต๊ะ อืม ทำไมไม่ทำแบบนั้นก่อนล่ะ!
ผู้เขียนชี้ให้เห็นแบบฝึกหัดเล็กๆ น้อยๆ ที่ควรฝึกฝน ลองจินตนาการว่าคุณทำอะไรในตอนเช้าหลังตื่นนอน ไพ่หนึ่งใบ = หนึ่งการกระทำ ขยายไพ่ (แทนที่จะบดกาแฟ ให้ดื่มเครื่องดื่มที่เติมพลัง) เพื่อลบรายละเอียดส่วนบุคคลออก โดยไม่เน้นไปที่วิธีการดำเนินการ แต่อยู่ที่เป้าหมาย
หนังสือเล่มนี้เหมาะสำหรับใคร: นักวิเคราะห์ไอทีและผู้จัดการโครงการ ต้องอ่าน
ปพลิเคชัน
การอภิปรายและการตัดสินใจมีประสิทธิภาพในกลุ่มละ 3 ถึง 5 คน
เขียนลงในการ์ดใบแรกถึงสิ่งที่ต้องพัฒนา การ์ดใบที่สอง - แก้ไขสิ่งที่คุณทำในการ์ดใบแรก การ์ดใบที่สาม - แก้ไขสิ่งที่คุณทำในการ์ดใบแรกและใบที่สอง
เตรียมเรื่องราวต่างๆ เช่น เค้ก ไม่ใช่โดยการเขียนสูตร แต่โดยการค้นหาว่าเค้กนี้สำหรับใคร สำหรับโอกาสไหน และสำหรับกี่คน ถ้าเราแจกแจงยอดขายคงไม่เกี่ยวกับการผลิตเค้ก ครีม ฯลฯ แต่เป็นการผลิตเค้กสำเร็จรูปขนาดเล็ก
การพัฒนาซอฟต์แวร์นั้นคล้ายคลึงกับการสร้างภาพยนตร์ เมื่อคุณจำเป็นต้องพัฒนาและขัดเกลาสคริปต์อย่างรอบคอบ จัดฉาก นักแสดง ฯลฯ ก่อนเริ่มการถ่ายทำ
จะเกิดการขาดแคลนทรัพยากรอยู่เสมอ
ความพยายาม 20% ก่อให้เกิดผลลัพธ์ที่จับต้องได้ 60% ให้ผลลัพธ์ที่ไม่อาจเข้าใจได้ 20% ของความพยายามนั้นเป็นอันตราย นั่นคือเหตุผลว่าทำไมการมุ่งเน้นไปที่การเรียนรู้จึงเป็นสิ่งสำคัญ และไม่สิ้นหวังในกรณีที่ผลลัพธ์เชิงลบ
สื่อสารโดยตรงกับผู้ใช้ รู้สึกเหมือนตัวเองอยู่ในบทบาทของเขา มุ่งเน้นไปที่ปัญหาบางอย่าง
การลงรายละเอียดและพัฒนาเรื่องราวเพื่อการประเมินผลเป็นส่วนที่น่าเบื่อที่สุดของการต่อสู้ ทำให้การอภิปรายยืนหยัดในโหมดอควาเรียม (คน 3-4 คนพูดคุยกันที่กระดาน หากใครต้องการเข้าร่วม เขาจะเข้ามาแทนที่ใครบางคน)
ที่มา: will.com