การจัดการกับวัฒนธรรมลูกค้า / นักพัฒนาที่ไม่ตรงกันในโครงการเปรียว

หนึ่งในหลักการของความคล่องตัวคือ ...

ความร่วมมือกับลูกค้าในการเจรจาต่อรองสัญญา

... อีกอันคือ ...

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

แต่วิธีที่ฉันเห็นมันอย่างน้อยก็เมื่อพูดถึงการมีปฏิสัมพันธ์กับลูกค้ามีปัญหาพื้นฐาน:

ความคิดเห็นของลูกค้าแตกต่างจากที่วิศวกรคิดอย่างไร

นั่นอาจเป็นเรื่องทั่วๆไปใช่ เนื้อหาที่มีอยู่โดเมนธุรกิจที่นี้ไม่จำเป็นจริง --- เหล่านี้มีน้อยและไกลระหว่างแม้ว่า ในหลาย ๆ โดเมนลูกค้าทั่วไปคือ:

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

ในทางตรงกันข้ามในอุดมคติวิศวกรซอฟต์แวร์ที่ฝึกฝนความคล่องตัวคือ:

1. คนที่คิดมากเกี่ยวกับคุณภาพ
2. บุคคลที่ชื่นชมว่าการทำงานตรงไปตรงมาเล็กน้อยสามารถประหยัดตันได้อย่างง่ายดาย
3. นักคิดวิเคราะห์ที่มีประสบการณ์

ดูเหมือนว่าจะมีความแตกต่างทางวัฒนธรรมที่มีแนวโน้มที่จะยับยั้ง "การทำงานร่วมกันของลูกค้า"

วิธีที่ดีที่สุดในการแก้ไขปัญหานี้คืออะไร

ในหลาย ๆ โดเมนลูกค้าทั่วไปคือ:

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

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

ดังนั้นคำตอบคือ - แทบจะไม่น่าแปลกใจ - การสื่อสาร

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

• ถ้าคุณบอกว่า"นี้จะเป็นสับซึ่งทำให้โค้ดอ่านน้อยและขยาย"พวกเขากล่าวว่า"ใช่สิ่งที่"
• ถ้าคุณบอกว่า"นี้จะมีการแก้ไขในระยะสั้นซึ่งจะทำให้การพัฒนาในระยะยาวและการบำรุงรักษาค่าใช้จ่ายมากขึ้นและเพิ่มความเสี่ยงของการแนะนำข้อบกพร่อง"พวกเขากล่าวว่า"ฮ่าขอพิจารณา"
• และถ้าคุณพูดว่า"วิธีนี้จะทำให้คุณเสียค่าใช้จ่าย $ 100 ในขณะนี้ แต่แนะนำหนี้ทางเทคนิค $ 500 ซึ่งคุณต้องจ่ายคืนพร้อมดอกเบี้ยไม่ช้าก็เร็ว OTOH โซลูชันอื่นนี้มีค่าใช้จ่ายคุณ $ 400 ในขณะนี้ ต้องการ "พวกเขาพูดว่า" ตอนนี้เรากำลังพูดถึง! " .

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

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

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

ลูกค้าของคุณดูตัวเองอย่างไร:

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

ในทางกลับกันพวกเขาเห็นกลุ่มของคุณเป็น:

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

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

ก่อนอื่นAgile ไม่ใช่วิธีแก้ปัญหาทั้งหมดที่คุณมีในโครงการ

ความคิดเห็นของลูกค้าแตกต่างกันอย่างไรกับความคิดของวิศวกรซอฟต์แวร์

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

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

วิธีที่ดีที่สุดในการแก้ไขปัญหานี้คืออะไร

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

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

หากคุณไม่ได้ซื้อจากลูกค้า Agile อาจเป็นไปไม่ได้เกือบ

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

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

ดังนั้นการได้รับข้อตกลงจากฝ่ายบริหารในด้านลูกค้าเป็นกุญแจสำคัญของปัญหานี้

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

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

Agile ช่วยให้คุณและลูกค้าตอบคำถามเหล่านั้น