คุณเป็น Software Developer ที่สื่อสารแบบไหน

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

ปัญหานี้ไม่ได้แก้ด้วย Hard Skill แต่ต้องใช้ ทักษะการสื่อสารสำหรับ Software Developer ซึ่งเป็น Soft Skill ที่สำคัญอย่างมาก ผมขอยกตัวอย่างเหตุการณ์สมมติเพื่อให้เห็นภาพตรงกันแบบง่ายๆ

คุณอยู่ใน Cross-Functional Team ที่มี Developer, QA, BA, Project Manager, Product Owner ซึ่งกำลังช่วยกันพัฒนา Feature ระบบแชทคล้าย Facebook Messenger

โอเค… ผมตั้งโจทย์แบบนี้ Developer หลายๆ คนที่มีประสบการณ์มาบ้างคงนึกออกว่าระบบ Realtime chat ต้องคิดหลายอย่างเช่น

ต้องใช้ service อะไรบ้างเพื่อให้ข้อมูลอัพเดท realtime
Server ต้องรองรับ workload แค่ไหน
จะออกแบบ Pagination อย่างไรให้ทำงานร่วมกับระบบ Realtime ได้ถูกต้อง?
ระบบ Search ที่ต้องค้นหาคำที่คล้ายกัน (Fuzzy Search) จะทำอย่างไรให้เร็ว?

แต่กลับกันในมุมมองของ Business อาจมองเป็นแค่ระบบง่ายๆ เพราะพวกเขาก็ใช้การรับ-ส่งข้อความอยู่ทุกวันใน Facebook Messenger เมื่อ Developer แบบเราฟังก็อาจปวดหัว (😂) และต้องพยายามอธิบายหลายๆ อย่างเพื่อให้ Product เกิดขึ้นจริง

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

ข้อมูลจาก Requiment.com ชี้ให้เห็นว่าสาเหตุที่โปรเจกต์ซอฟต์แวร์ล้มเหลวเกิดจาก

Requirement ไม่ชัดเจนหรือเปลี่ยนแปลงบ่อย (48%)
งบประมานหรือทรัพยากรไม่เพียงพอ (40%)
การจัดการทีมหรือองค์การไม่มีประสิทธิภาพ (37%)
เวลาในการ Test ไม่เพียงพอ (32%)
ส่งงานไม่ตรง Expectation (22%)
ข้อจำกัดด้านเวลาและการปล่อย Software ที่ยังไม่สมบูรณ์ (21%)

ต้นเหตุที่โปรเจกต์ Software ส่วนใหญ่ล้มเหลว

ปัญหานี้เกิดจากความช่องว่างและความเข้าใจที่ไม่ตรงกันของ Stakeholders และ Development Team

Stakeholders

บ่อยครั้งมากที่ Stakeholders มีความตั้งใจที่ดีแต่...

ขาดความเข้าใจกระบวนการพัฒนาซอฟต์แวร์
ขาดความชัดเจนในเป้าหมาย
ขาดความแน่นอนและขอเปลี่ยน Requirement ในภายหลัง

มีใครเคยคุยกับ Stakeholders ตรงๆ แล้วเขาบอกแค่ว่า "พี่อยากได้แอพเหมือน Shopee อ่ะ" ไหมครับ 😝

Development Team

ในทางกลับกันทีมพัฒนาก็มีส่วนผิดถ้า...

การสื่อสารไม่ชัดเจน
การขาดกระบวนการเก็บ Requirement ที่ดี
การขาดเอกสารที่ชัดเจนทำให้เห็นภาพสุดท้ายไม่ตรงกัน

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

Developer สามารถช่วยอย่างไรได้บ้าง

สามารถช่วยได้โดย ปรับการสื่อสารและโน้มน้าว (Influence) ให้ชัดเจนขึ้นครับ

หากเราสามารถอธิบายสิ่งที่ขาดไปใน Requirement ได้
หากเราสามารถอธิบายว่าสิ่งที่เห็นนั้นไม่ง่าย ทำตาม Deadline ไม่ได้
หากเราสามารถอธิบายว่ามี Solution ที่ทำตามจริงยังไงได้บ้าง

กลับไปที่ผมเกริ่นไว้ตอนแรกเกี่ยวกับระบบ Realtime Chat ถ้าหากว่าเราสื่อสารได้ตั้งแต่ตอนแรกว่ามันมีความยากอย่างไรและโน้มน้าวให้ทีมพัฒนาตำแหน่งอื่นๆ (PM, etc.) รวมถึง Stakeholder เข้าใจได้ น่าจะช่วยให้ทีมมีเวลาทำงานตามจริงมากขึ้นไหมครับ?

แล้วเราจะพัฒนาทักษะ Influence ได้อย่างไร?

เพื่อให้เราสามารถพัฒนาทักษะนี้ได้อย่างมีทิศทาง ผมขอแบ่งระดับทักษะ Stakeholder Influent Skills ออกเป็น 3 ระดับคือ

The Implementer (ลงมือทำตามคำสั่ง)
The Informer (ผู้ให้คำปรึกษา)
The Influencer (ผู้นำทางความคิด)

ซึ่งคุณสามารถใช้วัดระดับของตัวเองและวางแผน การเติบโตในสายงาน Developer ต่อไปได้

วัดระดับของตัวเองได้ที่นี่ (Stakeholder Influence Scorecard)

The Implementer (ลงมือทำตามคำสั่ง)

ทุกครั้งที่มีการ Grooming/Planning จะค่อนข้างเงียบและสื่อสารน้อยมาก ถึงแม้จะเจอปัญหาที่อาจจะปิด Project ไม่ได้หรือเมื่อทีมมีการเสนอ Solution และต้องจำสร้างความมั่นใจให้ทีม Business ก็ไม่สามารถช่วยโน้มน้าวได้

ถึงแม้จะสามารถแก้ปัญหาด้าน Technical ได้มากแค่ไหนแต่สุดท้ายจะติดปัญหาตั้งแต่ต้นน้ำหากไม่สามารถอธิบายได้

ในระยะยาวอาจพลาดโอกาสในการมีส่วนร่วมในการกำหนดทิศทางทำให้ไม่สามารถสร้าง impact ได้มากพอและถูกแทนที่ได้ง่าย

คำแนะนำในการพัฒนา:

ฝึกตั้งคำถามถึง Requirement ที่ยังไม่ชัดเจน
ฝึกอธิบายข้อดี-ข้อเสียของ Library, Framework, หรือ Tool ที่เลือกใช้

Key สำคัญ: ต้องทำให้คนอื่นเปลี่ยนมุมมองที่มองจาก “คนสร้าง” เป็น “คนแก้ปัญหา” คนสร้างคือคนที่ทำตามคำสั่งอย่างเดียว แต่คนแก้ปัญหาจะช่วยเข้าใจปัญหาและหาวิธีแก้ได้เหมาะสมครับ

The Informer (ผู้ให้คำปรึกษา)

The Informer ไม่ได้เป็นเพียงแค่คนลงมือทำงานแต่ยังสามารถอธิบายเรื่องซับซ้อนได้ดีทำให้ทีม Business และ Management มักจะนึกถึงเมื่อมีคำถาม

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

แต่บางครั้งการรอให้คนมาถามก็อาจสายเกินไป เพราะการตัดสินใจสำคัญๆ เกิดขึ้นไปแล้ว...

คำแนะนำในการพัฒนา:

นำปัญหาหรือความเสี่ยงที่เจอไปคุยกับ Manager ก่อนโดยไม่ต้องรอให้มีการประชุม
เสนอ Solution ที่หลากหลายขึ้น (Option A, B, C) พร้อมข้อดี-ข้อเสีย เพื่อให้ทีมมีทางเลือก

Key สำคัญ: ต้องเปลี่ยนมุมมองจากการเป็น “ที่ปรึกษา” (ถูกนึกถึงเมื่อมีปัญหา) ให้เป็น “พาร์ทเนอร์” (ถูกนึกถึงตั้งแต่เริ่มคิด) ให้ได้

The Influencer (ผู้นำทางความคิด)

The Influencer ไม่ได้แค่แนะนำแต่ “ชี้นำ” ให้ทุกคนเห็นถึงความสำคัญและการตัดสินใจที่ถูกต้อง เรียกได้ว่าเป็นผู้กำหนดทิศทางของ Product เลยก็ว่าได้เพราะสิ่งที่นำเสนอไม่ใช่แค่ข้อมูลแต่คือ Insight ที่ตอบโจทย์เป้าหมายทางธุรกิจทำให้ Stakeholder ทุกคนให้ความสำคัญกับความคิดเห็นของเขาเสมอ

คนที่มีทักษะระดับนี้จะสามารถสร้าง Impact ให้กับองค์กรได้อย่างมหาศาลและยากที่จะหาใครมาทดแทน ซึ่งเป็นคุณสมบัติสำคัญของตำแหน่งระดับ Dev Lead หรือ Dev Manager

Key สำคัญ: คือการขยายขอบเขตของ Impact ให้กว้างขึ้นอย่างต่อเนื่อง ไม่หยุดแค่ในทีมของตัวเอง

ตอนนี้ถึงตาคุณแล้ว ที่จะกำหนดเส้นทางการเติบโตของตัวเอง

การยกระดับ Soft Skill จาก Implementer สู่ Influencer ไม่ใช่เรื่องของพรสวรรค์แต่คือการฝึกฝนและเปลี่ยนมุมมอง จากที่โฟกัสแค่ Code มาเป็นการทำความเข้าใจ Context ทางธุรกิจรอบตัวให้มากขึ้น

บทความนี้เกิดจากประสบการณ์ที่ผมเคยหลงทางและไม่รู้ว่าจะพัฒนาตัวเองอย่างไร หวังว่า Framework นี้จะช่วยให้คุณเห็น เส้นทางการเติบโตในสายงาน Developer ของตัวเองได้ชัดเจนขึ้นครับ :)