Negotiation and Facilitation (การเจรจาต่อรองและการอำนวยความสะดวก)

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

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

Negotiating with Business Stakeholders (การเจรจาต่อรองกับผู้มีส่วนได้ส่วนเสียทางธุรกิจ)

ลองพิจารณาสถานการณ์ต่อไปนี้ ซึ่งคุณในฐานะหัวหน้าสถาปนิกต้องเจรจาต่อรองกับผู้มีส่วนได้ส่วนเสียทางธุรกิจคนสำคัญ:

Scenario 1 (สถานการณ์ที่ 1)

Parker รองประธานอาวุโสและผู้สนับสนุนโครงการนี้ ยืนกรานว่าระบบซื้อขายทั่วโลกแห่งใหม่ต้องรองรับความพร้อมใช้งานระดับ "five nines" (99.999%) อย่างไรก็ตาม จากช่วงเวลาที่ตลาดโลกไม่มีการซื้อขาย (สองชั่วโมง) คุณรู้ว่าความพร้อมใช้งานระดับ three nines (99.9%) ก็เพียงพอแล้วต่อความต้องการของโครงการ ปัญหาคือ คุณเคยเห็นแล้วว่า Parker ไม่ชอบทำผิดและไม่ตอบสนองดีนักเมื่อถูกแก้ไข โดยเฉพาะถ้ารู้สึกว่าถูกดูถูก Parker ไม่มีความรู้ทางเทคนิคจริงๆ แต่คิดว่าตัวเองมี จึงมักเข้ามายุ่งเกี่ยวกับด้าน non-functional ของโครงการ ในฐานะสถาปนิก เป้าหมายของคุณคือการโน้มน้าว Parker ผ่านการเจรจาต่อรองว่า three nines (99.9%) ก็เพียงพอแล้ว

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

Tip (เคล็ดลับ)

ให้ความสนใจกับคำศัพท์เก๋ๆ และศัพท์เฉพาะที่ผู้คนใช้ แม้จะดูไม่มีความหมายก็ตาม บ่อยครั้งมันแฝงเบาะแสที่ช่วยให้คุณเข้าใจและเจรจา สถานการณ์ได้ดีขึ้น

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

Tip (เคล็ดลับ)

รวบรวมข้อมูลให้ได้มากที่สุดเท่าที่จะทำได้ ก่อน เข้าสู่การเจรจาต่อรอง

การที่ Parker ใช้คำว่า "five nines" บ่งบอกว่าเขาต้องการให้ระบบมีความพร้อมใช้งานสูง (โดยเฉพาะ 99.999% ของเวลาที่ระบบทำงาน) อย่างไรก็ตาม อาจเป็นไปได้ว่า Parker ไม่ทราบว่าความพร้อมใช้งานระดับ "five nines" นั้นแปลว่าอะไรจริงๆ ในแง่ของปริมาณดาวน์ไทม์ต่อปี Table 25-1 แสดงดาวน์ไทม์ตามจำนวนเลข 9 ของความพร้อมใช้งาน

Table 25-1. ระดับความพร้อมใช้งานแบบ "nines" | เปอร์เซ็นต์เวลาทำงาน | ดาวน์ไทม์ต่อปี (ต่อวัน) | | --- | --- | | 90.0% (หนึ่ง nine) | 36 วัน 12 ชม. (2.4 ชม.) | | 99.0% (สอง nines) | 87 ชม. 46 นาที (14 นาที) | | 99.9% (สาม nines) | 8 ชม. 46 นาที (86 วินาที) | | 99.99% (สี่ nines) | 52 นาที 33 วินาที (7 วินาที) | | 99.999% (ห้า nines) | 5 นาที 35 วินาที (1 วินาที) | | 99.9999% (หก nines) | 31.5 วินาที (86 มิลลิวินาที) |

ความพร้อมใช้งานระดับ "five nines" คิดออกมาเป็นดาวน์ไทม์ 5 นาที 35 วินาทีต่อปี หรือเฉลี่ยดาวน์ไทม์ที่ไม่ได้วางแผนไว้ 1 วินาที ต่อวัน นั่นเป็นเป้าหมายที่ทะเยอทะยาน มีค่าใช้จ่ายสูง และเมื่อพิจารณาแล้วก็ไม่จำเป็นสำหรับ Scenario 1 เนื่องจากช่วงเวลาที่ตลาดโลก ไม่มีการซื้อขาย การระบุเป้าหมายเหล่านี้เป็นชั่วโมงและนาที (หรือในกรณีนี้คือวินาที) เป็นวิธีที่ดีกว่ามากในการพูดคุย มากกว่าการยึดติดกับศัพท์แบบ "nines" เพราะมันนำตัวชี้วัดและตัวเลขที่จับต้องได้จริงเข้ามาในการสนทนา

การเจรจาต่อรอง Scenario 1 จะรวมถึงการยืนยันความกังวลของ Parker ("ผมเข้าใจว่าความพร้อมใช้งานสำคัญมากสำหรับระบบนี้") จากนั้นจึงค่อยๆ นำการเจรจาจากศัพท์แบบ nines ไปสู่ตัวเลขชั่วโมงและนาทีของดาวน์ไทม์ที่ไม่ได้วางแผนไว้ที่สมเหตุสมผล three nines (ซึ่งคุณคิดว่าเพียงพอแล้ว) คิดเป็นดาวน์ไทม์ที่ไม่ได้วางแผนไว้เฉลี่ย 86 วินาทีต่อวัน ซึ่งแน่นอนว่าเป็นตัวเลขที่สมเหตุสมผล เมื่อพิจารณาบริบทของระบบซื้อขายทั่วโลกนี้ การพูดแบบนี้อาจเพียงพอที่จะโน้มน้าว Parker ว่าปริมาณดาวน์ไทม์ที่ไม่ได้วางแผนไว้นี้ เป็นที่น่าพอใจแล้ว แต่ถ้าไม่ได้ผล นี่คือเคล็ดลับอีกข้อ:

Tip (เคล็ดลับ)

เมื่อวิธีอื่นๆ ไม่ได้ผลทั้งหมด ให้พูดในแง่ของต้นทุนและเวลาที่ มีเงื่อนไข

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

อีกเทคนิคการเจรจาต่อรองที่สำคัญสำหรับสถานการณ์แบบนี้:

Tip (เคล็ดลับ)

เมื่อคุณต้องการจำกัดขอบเขตข้อเรียกร้องหรือความต้องการ ให้ใช้วิธี "แบ่งแยกแล้วปกครอง" (divide and conquer)

ใน The Art of War ซุนวู นักรบจีนโบราณเขียนถึงคู่ต่อสู้ของตัวเองว่า "ถ้ากำลังของเขารวมกันเป็นหนึ่ง จงแยกพวกเขาออกจากกัน" คุณสามารถใช้กลยุทธ์ แบ่งแยกแล้วปกครองนี้ในการเจรจาต่อรองได้เช่นกัน ใน Scenario 1 Parker ยืนกรานเรื่องความพร้อมใช้งานระดับ five nines (99.999%) สำหรับระบบซื้อขายใหม่ แต่ ทั้งระบบ จำเป็นต้องมี five nines จริงหรือ? คุณสามารถจำกัดขอบเขตของความต้องการนี้ให้แคบลง เหลือเฉพาะส่วนใดส่วนหนึ่งของระบบที่จำเป็นต้องมี five nines จริงๆ วิธีนี้ช่วยลดขอบเขตของความต้องการที่ยากและมีค่าใช้จ่ายสูง รวมถึงลดขอบเขตของการเจรจาด้วย

Negotiating with Other Architects (การเจรจาต่อรองกับสถาปนิกคนอื่น)

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

Scenario 2 (สถานการณ์ที่ 2)

คุณเป็นสถาปนิกอาวุโสในบรรดาสถาปนิกสองคนในโครงการหนึ่ง และคุณเชื่อว่า asynchronous messaging เป็นแนวทางที่ถูกต้อง สำหรับการสื่อสารระหว่างกลุ่มเซอร์วิส เพื่อเพิ่มทั้งประสิทธิภาพและความสามารถในการสเกล อย่างไรก็ตาม Addison สถาปนิกอีกคนในโครงการไม่เห็นด้วยอย่างมาก เขายืนกรานว่า REST เป็นตัวเลือกที่ดีกว่า เพราะมันเร็วกว่า messaging เสมอ และสเกลได้ดีพอกัน เขาอ้างอิงงานวิจัยของตัวเอง ซึ่งประกอบด้วยการค้นหาใน Google และผลลัพธ์จากการป้อนพรอมต์ให้เครื่องมือ generative AI ยอดนิยม นี่ไม่ใช่การถกเถียงที่ดุเดือดครั้งแรกที่คุณมีกับ Addison และก็คงไม่ใช่ครั้งสุดท้ายด้วย คุณต้องการโน้มน้าว เขาว่า messaging เป็นโซลูชันที่ถูกต้อง

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

Tip (เคล็ดลับ)

จำไว้เสมอว่า การสาธิตให้เห็นจริงชนะการถกเถียง

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

Tip (เคล็ดลับ)

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

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

Negotiating with Developers (การเจรจาต่อรองกับนักพัฒนา)

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

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

Tip (เคล็ดลับ)

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

ถ้าคุณให้เหตุผลว่า ทำไม สิ่งหนึ่งจึงจำเป็นต้องทำ นักพัฒนาก็มีแนวโน้มจะเห็นด้วยมากขึ้น ตัวอย่างเช่น ลองพิจารณาบทสนทนาต่อไปนี้ระหว่างสถาปนิกกับนักพัฒนา เกี่ยวกับการทำ query ง่ายๆ ภายในสถาปัตยกรรมแบบ n-tiered layered แบบดั้งเดิม:

สถาปนิก : "คุณต้องเรียกผ่าน Business layer เท่านั้นสำหรับการเรียกนั้น"
นักพัฒนา : "ผมไม่เห็นด้วย มันเร็วกว่ามากถ้าเรียกฐานข้อมูลโดยตรง"

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

ทีนี้ลองพิจารณาแนวทางอื่น:

สถาปนิก : "เนื่องจากการควบคุมการเปลี่ยนแปลงสำคัญที่สุดสำหรับเรา เราจึงออกแบบสถาปัตยกรรมแบบ closed-layered ขึ้นมา ซึ่งหมายความว่าการเรียกฐานข้อมูลทั้งหมดต้องมาจาก Business layer เท่านั้น"
นักพัฒนา : "โอเค ผมเข้าใจแล้ว แต่ถ้าอย่างนั้นผมจะจัดการกับปัญหาประสิทธิภาพสำหรับ query ง่ายๆ พวกนี้ยังไงดี?"

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

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

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

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

Tip (เคล็ดลับ)

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

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