ฉันใช้เวลา 3 เดือนในช่วงเวลาที่ครบถ้วนและหมดแรง - การรวบรวมความต้องการของโครงการสำคัญและได้เรียนรู้เหนือสิ่งอื่นใดแล้วว่าไม่มีวิธีแก้ปัญหาที่เหมาะกับทุกขนาด ไม่มีกระบวนการไม่มีความลับที่จะทำงานในทุกกรณี การวิเคราะห์ความต้องการเป็นทักษะที่แท้จริงและเมื่อคุณคิดว่าในที่สุดคุณก็ค้นพบมันทั้งหมดคุณจะได้สัมผัสกับกลุ่มคนที่แตกต่างกันโดยสิ้นเชิงและต้องทิ้งทุกสิ่งที่คุณรู้ออกไปนอกหน้าต่าง
ผู้มีส่วนได้เสียที่แตกต่างกันคิดในระดับที่แตกต่าง
มันง่ายที่จะพูดว่า "พูดคุยในระดับธุรกิจไม่ใช่ด้านเทคนิค" แต่ก็ไม่จำเป็นว่าจะต้องทำง่าย ระบบการออกแบบกำลังคุณเป็นช้างและผู้มีส่วนได้เสียของคุณเป็นคนตาบอดตรวจสอบมัน บางคนจึงแช่ลึกในกระบวนการและกิจวัตรประจำวันที่พวกเขาไม่ได้ตระหนักว่ามีเป็นธุรกิจ คนอื่นอาจทำงานในระดับที่คุณต้องการ แต่มีแนวโน้มที่จะทำการอ้างสิทธิ์เกินจริงหรือเท็จหรือมีส่วนร่วมในการคิดอย่างปรารถนา
น่าเสียดายที่คุณต้องรู้จักคนทุกคนในฐานะปัจเจกบุคคลและเข้าใจว่าพวกเขาคิดอย่างไรเรียนรู้วิธีตีความสิ่งที่พวกเขาพูดและตัดสินใจว่าจะเพิกเฉย
หารและพิชิต
หากคุณไม่ต้องการทำอะไรให้ส่งไปยังคณะกรรมการ
ไม่พบกับคณะกรรมการ ทำให้การประชุมเหล่านั้นมีขนาดเล็กที่สุดเท่าที่จะทำได้ YMMV แต่จากประสบการณ์ของฉันขนาดที่เหมาะคือ 3-4 คน (รวมถึงตัวคุณเอง) สำหรับช่วงเปิดและ 2-3 คนสำหรับช่วงปิด (เช่นเมื่อคุณต้องการคำตอบสำหรับคำถามเฉพาะ)
ฉันพยายามพบปะกับผู้ที่มีหน้าที่คล้ายกันในธุรกิจ มีน้อยมากที่จะได้รับและเสียอย่างมากจากการโยนคนทำตลาดในห้องด้วยเคาน์เตอร์ถั่ว หาคนที่เป็นผู้เชี่ยวชาญในเรื่องหนึ่งและให้พวกเขาพูดถึงเรื่องนั้น
การประชุมที่ไม่มีการเตรียมการเป็นการประชุมที่ไม่มีวัตถุประสงค์
สองคำตอบ / ความคิดเห็นอื่น ๆ ได้ทำการอ้างอิงถึงเทคนิคฟางชายซึ่งเป็นวิธีที่ยอดเยี่ยมสำหรับคนที่มีปัญหาที่คุณไม่สามารถหาคำตอบได้ แต่อย่าพึ่งคนฟางมากเกินไปมิฉะนั้นคนอื่นจะเริ่มรู้สึกว่าคุณกำลังฝึกฝนพวกเขา คุณต้องสะกิดผู้คนเบา ๆ ในทิศทางที่ถูกต้องและปล่อยให้พวกเขาคิดเฉพาะเพื่อให้พวกเขารู้สึกว่าพวกเขาเป็นเจ้าของพวกเขา (และในแง่หนึ่งพวกเขาก็เป็นเจ้าของพวกเขา)
สิ่งที่คุณต้องมีก็คือแบบจำลองทางจิตที่คุณคิดว่าธุรกิจทำงานอย่างไรและระบบควรทำงานอย่างไร คุณต้องเป็นผู้เชี่ยวชาญด้านโดเมนแม้ว่าคุณจะไม่ใช่ผู้เชี่ยวชาญใน บริษัท นั้น ๆ ก็ตาม ทำวิจัยให้มากที่สุดเท่าที่จะทำได้ในธุรกิจคู่แข่งระบบที่มีอยู่ในตลาดและสิ่งอื่น ๆ ที่อาจเกี่ยวข้องกับระยะไกล
เมื่อถึงจุดนั้นฉันพบว่ามีประสิทธิภาพมากที่สุดในการทำงานกับงานสร้างระดับสูงเช่น Use Cases ซึ่งมีแนวโน้มที่จะเห็นด้วยกับทุกคน แต่ก็ยังสำคัญที่จะต้องถามคำถามเฉพาะ หากคุณเริ่มต้นด้วย"คุณจะเรียกเก็บเงินลูกค้าของคุณอย่างไร" คุณอยู่ในการประชุมที่ยาวนานมาก ถามคำถามที่บอกเป็นนัยถึงกระบวนการแทนที่จะบอกให้ทราบถึงกระบวนการในการไป: รายการโฆษณาคืออะไร พวกเขาคำนวณอย่างไร พวกเขาเปลี่ยนบ่อยแค่ไหน? มีการขายหรือสัญญาหลายประเภทแตกต่างกันอย่างไร พวกเขาจะพิมพ์ที่ไหน? คุณได้รับความคิด
หากคุณพลาดขั้นตอนบางคนมักจะบอกคุณ หากไม่มีใครบ่นก็ให้ตบหลังตัวเองเพราะคุณเพิ่งยืนยันกระบวนการโดยปริยาย
เลื่อนการอภิปรายนอกเรื่อง
ในฐานะนักวิเคราะห์ข้อกำหนดคุณยังมีบทบาทเป็นผู้อำนวยความสะดวกด้วยและถ้าคุณไม่สนุกกับการใช้เวลาทั้งหมดในการประชุมคุณจำเป็นต้องหาวิธีในการติดตามสิ่งต่างๆ กระแทกแดกดันปัญหานี้จะกลายเป็นอันตรายมากที่สุดเมื่อคุณจนไม่รับคนพูด หากคุณไม่ระวังมันอาจทำให้รถไฟตกรางที่คุณใช้เวลามากมายในการวางราง
อย่างไรก็ตาม - และฉันนี้ได้เรียนรู้วิธีที่ยากนานแล้ว - คุณก็ไม่สามารถบอกคนอื่นว่าเป็นปัญหาที่ไม่เกี่ยวข้อง เห็นได้ชัดว่าเกี่ยวข้องกับพวกเขาไม่เช่นนั้นพวกเขาจะไม่พูดถึงมัน งานของคุณคือการให้คนพูดว่า "ใช่" มากที่สุดเท่าที่จะเป็นไปได้และวางสิ่งกีดขวางเช่นนั้นเพียงแค่เคาะคุณเข้าสู่ดินแดน "ไม่"
นี่คือสมดุลที่ละเอียดอ่อนที่หลาย ๆ คนสามารถรักษาด้วย "รายการการกระทำ" - โดยทั่วไปเป็นคิวการสนทนาทั่วไปที่คุณสัญญาว่าจะกลับมาในบางครั้งโดยปกติจะติดแท็กชื่อของผู้มีส่วนได้เสียที่คิดว่าสำคัญมาก นี่ไม่ได้เป็นเพียงเพื่อประโยชน์ทางการทูตเท่านั้น แต่ยังเป็นเครื่องมือที่มีค่าสำหรับช่วยให้คุณจดจำสิ่งที่เกิดขึ้นในระหว่างการประชุมและใครที่จะพูดคุยหากคุณต้องการคำชี้แจงเพิ่มเติมในภายหลัง
นักวิเคราะห์หลายคนจัดการเรื่องนี้ด้วยวิธีที่ต่างกัน บางอย่างเช่นไวท์บอร์ดสาธารณะหรือบันทึกฟลิปชาร์ทคนอื่น ๆ ก็แตะมันลงในแล็ปท็อปของพวกเขาอย่างเงียบ ๆ และค่อยๆแบ่งออกเป็นหัวข้ออื่น ๆ อะไรก็ตามที่คุณรู้สึกสบายใจ
คุณต้องมีวาระการประชุม
นี่อาจเป็นจริงสำหรับการประชุมเกือบทุกประเภท แต่มันเป็นความจริงเป็นสองเท่าสำหรับการประชุมตามข้อกำหนด เมื่อการอภิปรายเริ่มขึ้นจิตใจของผู้คนก็เริ่มเลือนหายไปและพวกเขาก็เริ่มสงสัยว่าเมื่อไหร่ที่คุณจะไปถึงสิ่งที่พวกเขาสนใจ การมีวาระการประชุมมีโครงสร้างบางส่วนและยังช่วยให้คุณกำหนดได้ตามที่กล่าวไว้ข้างต้นเมื่อคุณต้องการเลื่อนการสนทนาที่ทำให้เกิดหัวข้อนอก
อย่าเดินเข้าไปข้างในโดยปราศจากความคิดที่ชัดเจนว่าคุณต้องการครอบคลุมและเวลาใด หากไม่มีสิ่งนั้นคุณจะไม่มีทางประเมินความคืบหน้าของคุณเองและผู้ใช้จะเกลียดคุณเพราะใช้เวลานาน (สมมติว่าพวกเขาไม่ได้เกลียดคุณด้วยเหตุผลอื่น ๆ )
เยาะเย้ยมัน
ถ้าคุณใช้ PowerPoint หรือ Visio เป็นเครื่องมือจำลองขึ้นคุณจะต้องทนทุกข์ทรมานจากปัญหาของมันที่กำลังมองหาขัดมากเกินไป มันเกือบจะเป็นส่วนติดต่อผู้ใช้ที่แปลกประหลาด ผู้คนจะรู้สึกสะดวกสบายกับภาพวาดผ้าเช็ดปาก (หรือภาพวาดที่สร้างจากคอมพิวเตอร์ที่ดูเหมือนภาพวาดผ้าเช็ดปากโดยใช้เครื่องมือเช่นBalsamiqหรือSketchflow ) เพราะพวกเขารู้ว่ามันไม่ใช่ของจริง - เหตุผลเดียวกันที่ผู้คนสามารถดูตัวการ์ตูนได้ แต่ยิ่งเริ่มดูเหมือน UI จริงผู้คนจำนวนมากจะต้องการเลือกและอุ้งเท้ามันและยิ่งพวกเขาใช้เวลาพิจารณาเรื่องรายละเอียดที่ไม่มีนัยสำคัญในท้ายที่สุด
ดังนั้นแน่นอนทำการจำลองเพื่อทดสอบความเข้าใจของคุณเกี่ยวกับข้อกำหนด ( หลังจากขั้นตอนการวิเคราะห์เบื้องต้น) - เป็นวิธีที่ดีในการรับข้อเสนอแนะที่รวดเร็วและมีรายละเอียดมาก - แต่ให้พวกเขา lo-fi และไม่รีบเยาะเย้ยจนกว่าคุณจะ ค่อนข้างแน่ใจว่าคุณกำลังเห็นผู้ใช้ของคุณแบบตาต่อตา
โปรดจำไว้ว่าการเยาะเย้ยนั้นไม่ใช่สิ่งที่ส่งมอบได้มันเป็นเครื่องมือที่ช่วยในการทำความเข้าใจ เช่นเดียวกับที่คุณไม่คาดว่าจะถูกกักตัวไว้กับการเยาะเย้ยของคุณเมื่อทำการออกแบบ UI คุณไม่สามารถสรุปได้ว่าการออกแบบนั้นก็โอเคเพียงเพราะพวกเขาทำให้การเยาะเย้ยของคุณเป็นเรื่องง่าย ฉันเคยเห็น mocks ใช้เป็นไม้ยันรักแร้หรือแย่กว่านั้นเป็นข้อแก้ตัวที่จะข้ามข้อกำหนดทั้งหมด; ตรวจสอบให้แน่ใจว่าคุณไม่ได้ทำเช่นนั้น ย้อนกลับไปและเปลี่ยนการจำลองให้เป็นข้อกำหนดที่แท้จริง
ใจเย็น ๆ
นี่เป็นเรื่องยากสำหรับโปรแกรมเมอร์จำนวนมากที่จะเชื่อ แต่สำหรับโครงการที่ไม่สำคัญคุณไม่สามารถนั่งลงได้เพียงครั้งเดียว ฉันไม่เพียง แต่พูดถึงความอดทนในระหว่างการประชุมครั้งเดียวเท่านั้น การวิเคราะห์ความต้องการซ้ำ ๆ ในลักษณะเดียวกับที่รหัสคือ กลุ่ม A พูดอะไรแล้วก็กลุ่ม B พูดถึงสิ่งที่ขัดแย้งกับสิ่งที่คุณได้ยินจากกลุ่ม A โดยสิ้นเชิงกลุ่ม A อธิบายถึงความไม่สอดคล้องกันและกลายเป็นสิ่งที่กลุ่ม C ลืมพูดถึง ทำซ้ำ 500 ครั้งและคุณมีบางสิ่งบางอย่างประมาณคล้ายจริง
ถ้าคุณไม่พัฒนาแอพพลิเคชั่น CRUD ตัวเล็ก ๆ (ในกรณีนี้ทำไมต้องกังวลกับข้อกำหนดเลย?) อย่าคาดหวังว่าจะได้ทุกอย่างที่คุณต้องการในการประชุมครั้งเดียวหรือสองครั้งหรือห้าครั้ง คุณกำลังจะฟังมากและพูดมากและทำซ้ำตัวเองมาก ซึ่งไม่ได้เป็นสิ่งที่น่ากลัวใจคุณ; มันเป็นโอกาสที่จะสร้างสายสัมพันธ์กับคนที่หลีกเลี่ยงไม่ได้ที่จะออกจากระบบของคุณ
อย่ากลัวที่จะเปลี่ยนเทคนิคหรือกลอนสดของคุณ
แง่มุมต่าง ๆ ของโครงการอาจใช้เทคนิคการวิเคราะห์ที่แตกต่างกัน ในบางกรณี UML แบบคลาสสิก (ใช้ Case / Activity diagram) ใช้งานได้ดี ในกรณีอื่น ๆ คุณอาจเริ่มต้นด้วยธุรกิจ KSI หรือระดมความคิดด้วยแผนที่ความคิดหรือดำดิ่งสู่จำลองโดยไม่ต้องแจ้งให้ทราบล่วงหน้า
บรรทัดล่างคือคุณต้องเข้าใจโดเมนด้วยตัวคุณเองและทำการบ้านก่อนที่จะเสียเวลาของคนอื่น หากคุณรู้ว่าแผนกหรือส่วนประกอบเฉพาะมีกรณีการใช้งานเพียงกรณีเดียว แต่เป็นกรณีที่ซับซ้อนอย่างไม่น่าเชื่อดังนั้นให้ข้ามการวิเคราะห์กรณีการใช้งานและเริ่มพูดคุยเกี่ยวกับเวิร์กโฟลว์หรือกระแสข้อมูล หากคุณไม่ใช้เครื่องมือเดียวกันสำหรับทุกส่วนของการติดตั้งแอพทำไมคุณจะใช้เครื่องมือเดียวกันกับทุกส่วนของข้อกำหนด
วางหูของคุณลงกับพื้น
จากคำแนะนำและเคล็ดลับทั้งหมดที่ฉันได้อ่านสำหรับการวิเคราะห์ความต้องการนี่อาจเป็นสิ่งที่ถูกมองข้ามบ่อยที่สุด ฉันคิดอย่างสุจริตว่าฉันได้เรียนรู้เพิ่มเติมเกี่ยวกับการดักฟังและการขัดจังหวะการสนทนาด้วยน้ำเย็นกว่าที่ฉันเคยได้รับจากการประชุมที่กำหนดไว้เป็นครั้งคราว
หากคุณคุ้นเคยกับการทำงานโดดเดี่ยวพยายามหาจุดที่มีการกระทำเพื่อให้คุณได้ยินเสียงพูดคุย หากคุณทำไม่ได้ให้ทำรอบบ่อยๆไปที่ห้องครัวหรือห้องน้ำหรือที่ไหนก็ได้ คุณจะพบทุกชนิดของสิ่งที่น่าสนใจเกี่ยวกับวิธีการที่ธุรกิจจริงๆดำเนินงานจากการฟังสิ่งที่ผู้คนโม้หรือบ่นเกี่ยวกับระหว่างกาแฟและควันพักของพวกเขา
สุดท้ายอ่านระหว่างบรรทัด
หนึ่งในความผิดพลาดครั้งใหญ่ที่สุดของฉันในอดีตคือการมุ่งเน้นไปที่ผลลัพธ์สุดท้ายที่ฉันไม่ได้ใช้เวลาในการได้ยินสิ่งที่ผู้คนพูดจริง ๆ บางครั้ง - เป็นจำนวนมากเวลา - มันอาจเสียงเหมือนคนกำลังพูดพล่อยเกี่ยวกับอะไรหรือ harping เกี่ยวกับขั้นตอนบางอย่างที่เสียงอย่างเต็มที่ไม่มีจุดหมายที่คุณ แต่ถ้าคุณจริงๆมีสมาธิกับสิ่งที่พวกเขากำลังจะบอกว่าคุณจะรู้ว่ามีจริงๆ ข้อกำหนดที่ฝังอยู่ในนั้น - หรือหลายอย่าง
ในฐานะที่เป็นซ้ำซากและจืดชืดตามที่ฟังFive Whysเป็นเทคนิคที่มีประโยชน์จริงๆที่นี่ เมื่อใดก็ตามที่คุณมีอาการกระตุกหัวเข่า "นั่นเป็นปฏิกิริยาที่โง่" (ไม่ใช่ว่าคุณจะพูดออกมาดัง ๆ ) หยุดตัวเองแล้วเปลี่ยนเป็นคำถาม: ทำไม? เหตุใดข้อมูลนี้จึงถูกพิมพ์ซ้ำสี่ครั้งจากนั้นพิมพ์ถ่ายสำเนาสแกนพิมพ์อีกครั้งตรึงไว้ที่บอร์ดอนุภาคถ่ายด้วยกล้องดิจิทัลและส่งอีเมลถึงผู้จัดการฝ่ายขายในที่สุด มีเป็นเหตุผลและพวกเขาอาจไม่ทราบว่ามันคืออะไร แต่มันเป็นงานของคุณที่จะหา ขอให้โชคดี ;)