ให้ผู้ใช้ได้รับความต้องการร่วมกันด้วยตนเองหรือแนะนำพวกเขาไปพร้อมกัน?


16

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

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

2) พบกับผู้ใช้สองสามครั้งและช่วยให้พวกเขาค้นหาสิ่งที่พวกเขาต้องการโดยชี้แนะพวกเขาผ่านวิธีการโสคราตีสที่ดี "คุณต้องการติดตาม X หรือไม่", "แล้ว Y ล่ะ", "คุณต้องการฟังก์ชัน Z หรือไม่"

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

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


คำถามอยากรู้: ทำไมคุณถึงคิดว่าการวิเคราะห์ความต้องการเป็นงานของคนอื่น?
Steven A. Lowe

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

1
ขอบคุณสำหรับบริบทคำถามของคุณเหมาะสมกว่านี้มาก ในอีกด้านหนึ่งดูเหมือนว่านักวิเคราะห์ธุรกิจภายในของคุณจะไม่ทำงานของพวกเขาในทางกลับกันหากพวกเขาไม่ใช่นักพัฒนาฉันไม่เชื่อว่าการวิเคราะห์ของพวกเขาจะเสร็จสมบูรณ์หรือถูกต้อง - แต่นั่นเป็นเพียงฉัน ;-)
Steven A. Lowe

คำตอบ:


9

ฉันต้องยอมรับว่าบางครั้งฉันเลือกตัวเลือก 3)

3) ฟังความคิดเห็นที่คลุมเครือของลูกค้าลวกความคิดในการใช้เวลาหลายสัปดาห์เพื่อช่วยให้พวกเขารู้ว่าสิ่งที่พวกเขาต้องการคืออะไร ... ดังนั้นให้คิดออกว่าพวกเขาต้องการอะไรสร้างแบบนั้นและ refactor ตามที่ต้องการ

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

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

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

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

ปัญหาเดียวกันมากที่กล่าวถึงข้างต้น (# 3) และปัญหาที่ทำให้คุณต้อง # 2 อยู่ดี


1
+1: การพูดถึงสมมุติฐานเกี่ยวกับ "จำเป็น", "เป็นที่ต้องการ" และ "ไม่จำเป็น" นั้นเป็นไปไม่ได้สำหรับคนจำนวนมาก การพูดเกี่ยวกับการนำไปปฏิบัติที่เป็นรูปธรรมนั้นง่ายกว่ามาก
S.Lott

ฉันพบว่าการใส่ตัวเลข $ (หรือเวลา) ที่ไม่สามารถตกลงกันได้จริงกับ "จำเป็น", "ต้องการ" และ "ตัวเลือก" เป็นความช่วยเหลือที่ดี ......
mattnz

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

27

ถ้าคุณต้องการที่จะเป็นโปรแกรมเมอร์คุณจะต้องรอจนกว่าจะมีคนอื่นรู้ว่าไคลเอ็นต์ต้องการอะไรจากนั้นจึงเขียนโค้ดที่

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

ภาคผนวก: กระบวนการนี้เรียกว่า "การวิเคราะห์และออกแบบระบบ" หรือที่เรียกว่าการให้คำปรึกษาและไม่ควรทำฟรี


1
+1 สำหรับ bit ฟรี :) ไม่เคยถูกทำให้หลงไหลในการทำรูปแบบเว็บไซต์สองสามชั่วโมงสำหรับคู่ ...
Errant

1
"ไม่ควรทำฟรี" นั้นคุ้มค่าที่จะขยายไปสู่คำถามอื่น IMO
Endy Tjahjono

7

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

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

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

ทักษะที่แท้จริงคือการเลือกวิธีการที่เหมาะสมในเวลาที่เหมาะสม

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

นี่อาจถูกมองว่าเป็นความพยายาม "พิเศษ" ที่ไม่จ่ายคืน - แต่ฉันชอบที่จะมองว่าเป็นการลงทุนด้วยสองเหตุผล:

  • มันช่วยให้ฉันมอบโซลูชั่นที่ดีซึ่งในระยะยาวจะเพิ่มมูลค่าทางการตลาดของฉันในฐานะนักพัฒนาและ
  • โดเมนที่แตกต่างกันจะไม่แตกต่างกันอย่างสมบูรณ์ดังนั้นอย่างน้อยส่วนหนึ่งของความรู้โดเมนนั้นอาจจะนำมาใช้ซ้ำในกิ๊กในอนาคต

3

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

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

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

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

ไม่ว่าในกรณีใด: การเขียนชิ้นส่วนของรหัสใหม่จะไม่เกินความจำเป็นในการเขียนชิ้นส่วนใหม่

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


2

ตัวเลือกที่แน่นอน 2 ยกเว้นว่าผู้ใช้ของคุณเป็นนักพัฒนาซอฟต์แวร์ (อาจจำเป็นต้องใช้ตัวเลือกที่ 2)

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


2

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

คุณไม่ต้องการที่จะข้ามไปที่ตัวเลือก # 2 เมื่อพวกเขาสามารถแยกแยะสิ่งที่พวกเขาต้องการเพราะมันจะทำให้กระบวนการทั้งหมดช้าลงและน่าผิดหวังมากขึ้น (เว้นแต่พวกเขาจะมีความคิดที่ชัดเจนเกี่ยวกับสิ่งที่พวกเขาต้องการเมื่อพวกเขามาหาคุณ จากประสบการณ์ของฉันนี้หายากมาก) ทำให้พวกเขาได้ความคิดร่วมกัน ให้พวกเขาเขียนบางสิ่งลงบนกระดาษอธิบายสิ่งที่พวกเขาต้องการในแง่ของระบบที่มีอยู่ถ้าเป็นไปได้ (เช่น "เราต้องการเว็บไซต์เช่น blahblah.com แต่ด้วยความแตกต่างเหล่านี้ ... เราต้องการเครื่องมือที่ทำงานเช่น Product X แต่ UI ต้องทำภารกิจ B ... ") จากนั้นเป็นเวลาที่ดีในการเริ่มต้นปรับแต่งสิ่งที่พวกเขาต้องการให้เป็นข้อกำหนดเฉพาะที่คุณสามารถใช้เพื่อสร้างระบบ


2

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

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

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

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


2

ตัวเลือกที่ 1 เป็นวิธีที่ยอดเยี่ยมในการหลีกเลี่ยงการทำงาน ฉันใช้มันเมื่อฉันเชื่อว่างานจะไม่จำเป็นหรือฉันมีสิ่งที่สำคัญมากกว่าที่จะทำ

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

ประการที่สองผู้ใช้ไม่จำเป็นต้องรู้สิ่งที่พวกเขาต้องการและมักจะไม่รู้ว่าพวกเขาต้องการอะไรในแง่ที่สามารถกระทำได้

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

วิธีเดียวที่จะให้สิ่งที่ผู้ใช้ทำในสิ่งที่พวกเขาต้องการในแบบที่พวกเขาต้องการคือการทำงานกับพวกเขาเอง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.