เหตุใดจึงไม่มีอะไรชัดเจน: ศิลปะแห่งการสื่อสารในการพัฒนาซอฟต์แวร์

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

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

ปัญหาที่พบบ่อยที่สุดประการหนึ่งที่เราทุกคนมีคือการสันนิษฐานว่าบุคคลอื่นสามารถอ่านใจเราได้ เราทุกคนมีความผิดในบางครั้ง คุณเคยได้ยินวลีนี้: 'มันชัดเจน!' หรือไม่? ฉันพนันได้เลยว่าคุณมี

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

ทำไมพูดง่ายกว่าทำ? มาวิเคราะห์กระบวนการสื่อสารกันก่อน

องค์ประกอบของการสื่อสาร

กว่า 50 ปีที่แล้ว Roman Jakobson นำเสนอรูปแบบการสื่อสารที่มีประโยชน์มากในการวิเคราะห์ปัญหาด้วยการทำความเข้าใจซึ่งกันและกัน ลองดูที่ไดอะแกรม:

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

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

ให้บริบทเสมอ

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

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

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

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

ใช้ช่องอย่างชาญฉลาด

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

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

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

เคล็ดลับสำหรับการสื่อสารทางไกลที่มีประสิทธิภาพ

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

การตรวจสอบรหัสการสื่อสาร

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

อืม… แล้วตอนเช้าหมายความว่าอย่างไรในฟีเจอร์นี้ ตอนเช้าเริ่มเมื่อไหร่? เมื่อดวงอาทิตย์ขึ้นหรือในเวลาที่แน่นอนคือ 07.00 น. ถ้าเวลา 07.00 น. คุณนึกถึงโซนเวลาไหน?

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

แนวทางปฏิบัติที่ดีที่สุดของรหัสการสื่อสารทั่วไป

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

ปัญหาความเชี่ยวชาญ

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

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

วิธีหลีกเลี่ยงปัญหาความเชี่ยวชาญ

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

วิธีการสื่อสารอย่างมีประสิทธิภาพในทีมวิศวกรรมซอฟต์แวร์

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

เปลี่ยนความคิดของคุณให้เป็นผลิตภัณฑ์ดิจิทัลที่โดดเด่น

ขอทำงานร่วมกัน

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

หากคุณกำลังมองหาซอฟต์แวร์เฮาส์ที่เชี่ยวชาญทั้งด้านการพัฒนาแอปและการสื่อสาร ไม่ต้องมองหาที่ไหนอีกแล้ว!

เพียงพูดคุยกับผู้เชี่ยวชาญของ Miquido แล้วทำให้ความคิดของคุณเป็นจริง!