ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์
PM และวิศวกรใช้เครื่องมือ ภาษา และไทม์ไลน์ที่แตกต่างกัน นี่คือวิธีที่ไซโลก่อตัว – และสิ่งที่แก้ไขได้จริง
By Ellis Keane · 2026-03-16
ในบางช่วง "การจัดแนวผลิตภัณฑ์และวิศวกรรม" กลายเป็นตำแหน่งงานแทนที่จะเป็นสิ่งที่เกิดขึ้นเองเมื่อผู้มีความสามารถทำงานร่วมกัน บริษัทต่างๆ ตอนนี้จ้างคนที่มีหน้าที่เพียงอย่างเดียวคือทำให้แน่ใจว่าสองกลุ่มที่ฉลาด – ซึ่งนั่งอยู่ใน Slack workspace เดียวกัน เข้าร่วม standup เดียวกัน และในทางทฤษฎีมุ่งสู่เป้าหมายเดียวกัน – สามารถเข้าใจได้จริงว่ากลุ่มอื่นกำลังทำอะไรอยู่ ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์ที่ทำให้สิ่งนี้จำเป็นไม่ใช่ปัญหาของคน แต่เป็นปัญหาของเครื่องมือ
PM และวิศวกรสื่อสารกันเพียงพออยู่แล้ว ปัญหาคือพวกเขาทำงานในระบบที่แตกต่างกันโดยสิ้นเชิง และไซโลที่ก่อตัวขึ้นระหว่างระบบเหล่านั้นมีลักษณะเชิงโครงสร้าง – ฝังอยู่ในสถาปัตยกรรมของวิธีที่ทีมสมัยใหม่เลือกเครื่องมือของตน การบอกว่า "มาจัดแนวกันบ่อยขึ้น" ไม่ช่วยแก้ปัญหาที่เครื่องมือเองไม่มีความตระหนักซึ่งกันและกัน
ความเป็นจริงสองประการ
ฉันอ้างอิงจากประสบการณ์ของเราเองในการสร้าง Sugarbug เพราะเราใช้ชีวิตกับสิ่งนี้ทุกวัน และฉันคิดว่ารายละเอียดเฉพาะเจาะจงมีประโยชน์มากกว่าเวอร์ชันที่เป็นนามธรรม
ฝั่ง PM (ซึ่งส่วนใหญ่คือฉัน ในกรณีของเรา) อยู่ใน Notion สเปคถูกเขียนที่นั่น ลำดับความสำคัญถูกติดตาม บทสนทนากับลูกค้าถูกบันทึก คำขอฟีเจอร์ถูกจัดหมวดหมู่ในรายการต่อเนื่องที่เพิ่มขึ้นทุกสัปดาห์ Notion คือที่ที่ "ทำไม" อาศัยอยู่ – ทำไมเราถึงสร้างบางอย่าง สิ่งที่ลูกค้าพูดจริงๆ บริบทเชิงกลยุทธ์ที่อยู่เบื้องหลังการตัดสินใจที่กำหนด มันรก กว้างขวาง และเป็นที่ที่การคิดสำคัญส่วนใหญ่เกิดขึ้นก่อนที่จะมีการเขียนโค้ดแม้แต่บรรทัดเดียว
ในขณะเดียวกัน วิศวกรของเราอยู่ใน Linear และ GitHub Linear มีงาน รอบ sprint ห่วงโซ่การพึ่งพา และ issues ที่บล็อก GitHub มีโค้ด pull requests เธรดรีวิวที่ผู้คนถกเถียงกันอย่างสร้างสรรค์ (หวังว่า) เกี่ยวกับรายละเอียดการนำไปใช้งาน นั่นคือที่ที่ "อย่างไร" และ "เมื่อไร" อยู่ – สิ่งนั้นกำลังถูกสร้างอย่างไร เมื่อไรที่จะส่งมอบ อะไรที่ขวางกั้น
ทั้งสองความเป็นจริงถูกต้อง ทั้งสองจำเป็น และพวกมันแยกออกจากกันโดยสิ้นเชิง ช่องว่างระหว่างพวกมันคือที่ที่ความต้องการล้าสมัยและงานแก้ไขเริ่มสะสม
ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์ก่อตัวขึ้นอย่างไรในความเป็นจริง
เป็นเรื่องดึงดูดที่จะคิดว่านี่เป็นการเลือกโดยเจตนา – ว่ามีคนตัดสินใจแยกข้อมูลไว้ ในทางปฏิบัติ ไซโลก่อตัวขึ้นผ่านพฤติกรรมที่สมเหตุสมผลโดยสมบูรณ์ซึ่งไม่มีใครตั้งใจให้เป็นอันตราย
PM เขียนสเปคใน Notion ลิงก์ไปยังช่อง engineering ใน Slack และถือว่าการส่งมอบเสร็จสิ้น วิศวกรอ่านสเปค สร้าง Linear issues สามรายการจากมัน และเริ่มสร้าง จนถึงตอนนี้ทุกอย่างทำงานได้
แต่แล้วสเปคก็เปลี่ยนแปลง – บทสนทนากับลูกค้าเปลี่ยนลำดับความสำคัญ หรือบริบทธุรกิจพัฒนาไป PM อัปเดตเอกสาร Notion และทิ้งโน้ตใน Slack เกี่ยวกับการเปลี่ยนแปลง วิศวกรที่กำลังเข้าสู่เซสชันการเขียนโค้ดอย่างลึกซึ้งไม่เห็นข้อความ Slack เป็นเวลาหลายชั่วโมง ตอนนั้นพวกเขาได้สร้างสองในสามฟีเจอร์ตามสเปคเก่า และ issue ที่สามใน Linear ยังคงอ้างอิงความต้องการที่ไม่มีอยู่อีกต่อไป
ไม่มีใครที่นี่ประมาท ไม่มีใคร "ล้มเหลวในการสื่อสาร" ข้อมูลอยู่ในระบบหนึ่งและงานเกิดขึ้นในอีกระบบหนึ่ง และเนื้อเยื่อเชื่อมต่อระหว่างพวกมันคือข้อความ Slack ที่ถูกฝังอยู่ใต้เธรดอื่นก่อนที่คนที่ถูกต้องจะเห็น
สิ่งนี้เกิดขึ้นซ้ำๆ – ในทุกสเปค ทุก sprint ทุกไตรมาส – และการเบี่ยงเบนก็สะสม ช่องว่างระหว่างสิ่งที่ผลิตภัณฑ์คิดว่าเกิดขึ้นและสิ่งที่วิศวกรรมกำลังสร้างจริงขยายกว้างขึ้นกับทุกการส่งมอบที่พึ่งพาให้มนุษย์สังเกตเห็นข้อความในเวลาที่เหมาะสม
ทำไม "การสื่อสารที่ดีกว่า" ถึงไม่แก้ปัญหาได้
ฉันเคยนั่งในการประชุมย้อนหลังที่รายการดำเนินการคือ "สื่อสารการเปลี่ยนแปลงเชิงรุกมากขึ้น" และ (ด้วยความรัก) นั่นเทียบเท่ากับการบอกให้ใครสักคนจัดระเบียบมากขึ้นในระดับองค์กร ฟังดูดำเนินการได้ ทำให้หน้า Confluence ดูมีประสิทธิผล และไม่เปลี่ยนแปลงอะไรเลยเกี่ยวกับระบบที่ก่อให้เกิดปัญหา เราดำเนินการรายการ retro เดิมสามครั้งแล้ว – ฉันตรวจสอบแล้ว
เหตุผลที่การสื่อสารที่ดีกว่าไม่สามารถแก้ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์ได้คือการสื่อสารเกิดขึ้นอยู่แล้ว – ข้อมูลมีอยู่ การตัดสินใจกำลังถูกตัดสินใจและบันทึก แค่บันทึกอยู่ในเครื่องมือที่ไม่มีความตระหนักซึ่งกันและกัน
Notion ไม่รู้ว่าสเปคถูกแยกออกเป็น Linear issues สามรายการ Linear ไม่รู้ว่าความต้องการเบื้องหลัง issue เปลี่ยนแปลงไปใน Notion เมื่อสองชั่วโมงที่แล้ว GitHub ไม่มีทางรู้ว่า PR ที่กำลังรีวิวอยู่นั้นนำไปใช้งานฟีเจอร์ที่เพิ่งถูกลดลำดับความสำคัญในบอร์ด Notion ของ PM เครื่องมือแต่ละตัวทำงานตามที่ออกแบบมาอย่างแน่นอน – แค่ไม่ได้ออกแบบมาให้ทำงานร่วมกัน
"มีความตลกร้ายบางอย่างในการใช้เวลาเช้าวันจันทร์เพื่อยืนยันว่าเครื่องมือที่คุณจ่ายเงินไปนั้นไม่ได้เบี่ยงเบนจากความเป็นจริงอย่างเงียบๆ ตลอดสุดสัปดาห์" attribution: Ellis Keane
ดังนั้นสิ่งที่เกิดขึ้นคือ PM มิเรอร์การเปลี่ยนแปลงจาก Notion ไปยัง Linear ด้วยตนเองเมื่อสเปคเปลี่ยน วิศวกร ping PM บน Slack เพื่อถามว่า "นี่ยังเป็นแผนอยู่ไหม?" และหัวหน้าใช้เวลาเช้าวันจันทร์ในการอ้างอิงไขว้บอร์ดเพื่อตรวจสอบการเบี่ยงเบน เราได้เห็นตัวเองใช้เวลาหลายชั่วโมงต่อสัปดาห์กับสิ่งที่เทียบเท่ากับการซิงโครไนซ์ข้อมูลด้วยตนเองระหว่างเครื่องมือที่ควรรู้จักกันอยู่แล้วในทางทฤษฎี
การแก้ไขเชิงระบบที่แท้จริงมีลักษณะอย่างไร
สัญชาตญาณเมื่อเห็นช่องว่างระหว่างเครื่องมือสองตัวคือการสร้างสะพาน – Zapier automation, webhook, สคริปต์ซิงค์ สำหรับเวิร์กโฟลว์ที่เรียบง่ายและคาดเดาได้ (เมื่อ Linear issue ย้ายไป "Done" อัปเดตสถานะ Notion) สิ่งนั้นใช้งานได้ดี
แต่ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์เกี่ยวข้องกับบริบท ไม่ใช่แค่สถานะ PM ไม่ได้แค่เปลี่ยนฟิลด์สถานะ พวกเขาเขียนย่อหน้าในสเปคใหม่ที่เปลี่ยนความหมายของ "done" สำหรับสองใน three Linear issues webhooks สถานะง่ายๆ พลาดการเปลี่ยนแปลงระดับความต้องการ เว้นแต่คุณจะเพิ่ม logic สำหรับ diff และการแมปความหมายบนนั้น ซึ่งทีมส่วนใหญ่ไม่เคยได้รับโอกาสสร้าง
สิ่งที่คุณต้องการจริงๆ คือบางอย่างที่เข้าใจความสัมพันธ์ระหว่างข้อมูลข้ามเครื่องมือ – ไม่ใช่แค่ "หน้า Notion นี้เชื่อมโยงกับ Linear issue นี้" แต่ "ส่วนนี้ของสเปคอธิบายความต้องการสำหรับ issue นี้ และส่วนนั้นเพิ่งเปลี่ยนแปลง" เป้าหมายคือการแมปการแก้ไขสเปคกับ issues ที่ได้รับผลกระทบโดยอัตโนมัติ แทนที่จะพึ่งพาให้ใครสักคนสังเกตเห็นและแพร่กระจายการเปลี่ยนแปลง
นั่นคือความแตกต่างระหว่างชั้นซิงค์และกราฟความรู้ ชั้นซิงค์คัดลอกข้อมูลระหว่างเครื่องมือ กราฟความรู้ติดตามว่าข้อมูลเกี่ยวข้องกันอย่างไร ตรวจจับเมื่อความสัมพันธ์เหล่านั้นเปลี่ยนแปลง และนำเสนอการเปลี่ยนแปลงต่อคนที่ต้องการรู้
เรากำลังสร้าง Sugarbug ให้ทำงานด้วยวิธีนี้ – เชื่อมต่อเครื่องมือที่ PM และวิศวกรใช้อยู่แล้ว (Notion, Linear, GitHub, Slack, Figma) เข้าสู่กราฟความรู้ที่รักษาความสัมพันธ์ระหว่างสเปค งาน โค้ด และการสนทนา เรายังอยู่ในช่วงเริ่มต้น (ตามจริงแล้ว มีหลายอย่างที่เราไม่ได้คิดออกเกี่ยวกับวิธีทำให้การตรวจจับ semantic diff เชื่อถือได้ในระดับขนาดใหญ่) แต่กราฟหลักกำลังทำงานอยู่และมันจับสถานการณ์ spec-drift ที่จะกลายเป็นงานแก้ไขแล้ว
ไซโลข้อมูลระหว่างวิศวกรรมและผลิตภัณฑ์ก่อตัวขึ้นเพราะเครื่องมือแยกออกจากกันในเชิงโครงสร้าง ไม่ใช่เพราะผู้คนสื่อสารไม่ดี การแก้ไขคือการเชื่อมต่อข้อมูลในระดับความสัมพันธ์ ไม่ใช่การเพิ่มช่องทางการสื่อสารมากขึ้น
สิ่งที่คุณทำได้ในสัปดาห์นี้
ฉันจะไม่แกล้งทำเป็นว่าคำตอบเดียวคือ "ใช้ Sugarbug" มีสิ่งที่คุณทำได้ตอนนี้ ด้วยเครื่องมือที่คุณใช้อยู่แล้ว เพื่อลดผลกระทบที่เลวร้ายที่สุดของไซโลข้อมูลผลิตภัณฑ์และวิศวกรรม
ทำการอ้างอิงไขว้ให้ชัดเจน สองทิศทาง และมีผู้รับผิดชอบ ทุก Notion spec ควรมีส่วน "Linear Issues" ที่ด้านล่างซึ่งลิงก์ไปยัง issues ที่มันสร้างขึ้น และทุก Linear issue ควรลิงก์กลับไปยังสเปคต้นทาง มอบหมายให้หนึ่งคนต่อสเปคเป็นเจ้าของการอ้างอิงไขว้ – ไม่ใช่ทั้งทีม หนึ่งคน พร้อมชื่อของพวกเขา เราลองเวอร์ชัน "ทุกคนรับผิดชอบ" แล้วและ (ตามที่คาดเดาได้) ไม่มีใครเลย ลิงก์จะเบี่ยงเบนเมื่อเวลาผ่านไปอยู่ดี แต่การมีเจ้าของที่มีชื่อหมายความว่ามีคนที่จะ ping เมื่อพบการเบี่ยงเบน
สร้างพิธีกรรม "การเปลี่ยนแปลงสเปค" พร้อมตัวกระตุ้น ไม่ใช่การเตือนความจำ เมื่อสเปคเปลี่ยนแปลงอย่างมีนัยสำคัญ (ไม่ใช่การพิมพ์ผิด – การเปลี่ยนแปลงความต้องการจริง) PM จะอัปเดต Linear issues ที่ลิงก์ก่อนปิดแท็บ Notion ไม่ใช่ทีหลัง ไม่ใช่ "เมื่อมีโอกาส" – ก่อนที่แท็บจะปิด คอมเมนต์บน issues ที่ได้รับผลกระทบแต่ละรายการควรเป็นหนึ่งบรรทัด: สิ่งที่เปลี่ยนแปลง ลิงก์ไปยังส่วนที่อัปเดต และว่าเกณฑ์การยอมรับของ issue ยังถูกต้องหรือไม่ เราพบว่าการผูกการอัปเดตกับการกระทำทางกายภาพ (การปิดแท็บ) ใช้งานได้ดีกว่าการพึ่งพาความจำของใคร เพราะความจำคือสิ่งที่ทำให้ไซโลก่อตัวขึ้นตั้งแต่แรก
รันการตรวจสอบความสอดคล้องลำดับความสำคัญ 15 นาทีทุกวันศุกร์ หนึ่งคน (สลับทุกสัปดาห์) ดึงลำดับความสำคัญ 5 อันดับแรกของ PM ใน Notion และ 5 อันดับแรกของ engineering sprint ใน Linear เคียงกัน คำถามไม่ใช่ "สิ่งเหล่านี้เหมือนกันหรือเปล่า?" – พวกมันจะไม่เหมือน และนั่นก็ไม่เป็นไร คำถามคือ "มีอันใดในสิ่งเหล่านี้ที่ขัดแย้งกันอย่างแข็งขันหรือไม่?" ถ้าลำดับความสำคัญ #1 ของ PM ไม่อยู่ใน sprint เลย นั่นคือบทสนทนาที่ต้องทำในวันจันทร์ ไม่ใช่การอัปเดตสถานะ
กระบวนการเหล่านี้เป็นกระบวนการด้วยตนเองและมีอายุขัยที่จำกัด ที่วิศวกรห้าคนและ PM สองคน มันน่าเบื่อแต่ใช้งานได้ ที่วิศวกรสิบห้าคน PM สามคน และทีมออกแบบที่เพิ่ม Figma เข้ามา ความสัมพันธ์ข้ามเครื่องมือก็เพิ่มขึ้นเร็วกว่าที่ใครจะติดตามด้วยมือได้ แต่พวกมันจะสอนคุณว่าช่องว่างการจัดแนวผลิตภัณฑ์และวิศวกรรมที่แย่ที่สุดของคุณอยู่ที่ไหนจริงๆ – และคุณค่าในการวินิจฉัยนั้นคุ้มค่าความพยายามแม้ว่าคุณจะทำให้ทุกอย่างเป็นอัตโนมัติในที่สุด
ไม่ว่าการแก้ไขระยะยาวจะเป็น Sugarbug หรืออย่างอื่น (เราคิดอย่างชัดเจนว่าเรากำลังสร้างสิ่งที่ถูกต้อง แต่ฉันมีอคติ) ปัญหาการทำงานร่วมกันด้านการจัดการผลิตภัณฑ์และวิศวกรรมจะแก้ไขได้ก็ต่อเมื่อเครื่องมือเองเชื่อมต่อกันในระดับความหมาย และมนุษย์สามารถมุ่งเน้นไปที่การตัดสินใจแทนที่จะขนส่งบริบทระหว่างแอป
ถ้าการอ้างอิงไขว้ด้วยตนเองของคุณยังคงสมบูรณ์ ก็ใช้มันต่อไปให้นานที่สุด ถ้าคุณยังคงมีรายการดำเนินการ retrospective เดิมเกี่ยวกับการสื่อสาร ปัญหาไม่ใช่คนของคุณ มันคือสถาปัตยกรรมข้อมูลของคุณ
เชื่อมต่อ Notion, Linear, GitHub และ Slack เข้าสู่กราฟความรู้เดียว – เพื่อให้การเปลี่ยนแปลงสเปคปรากฏแก่วิศวกรที่ถูกต้องโดยอัตโนมัติ
Q: ใช้เวลานานเท่าใดในการตั้งค่า Sugarbug สำหรับทีมผลิตภัณฑ์และวิศวกรรม? A: การเชื่อมต่อครั้งแรกใช้เวลาไม่กี่นาทีต่อเครื่องมือ – คุณยืนยันตัวตน Linear, GitHub, Notion, Slack และ Figma ผ่าน OAuth และ Sugarbug จะเริ่มสร้างกราฟความรู้ทันที กราฟจะมีประโยชน์อย่างมีนัยสำคัญภายในหนึ่งหรือสองวันเมื่อมันรับข้อมูลที่มีอยู่ของคุณและเริ่มแมปความสัมพันธ์ระหว่างสเปค issues และการสนทนา เรายังปรับปรุงขั้นตอนการ onboarding อยู่ แต่เป้าหมายคือคุณไม่ควรต้องกำหนดค่าอะไรนอกจากการเชื่อมต่อบัญชีของคุณ
Q: Sugarbug แทนที่ Linear, Notion หรือเครื่องมือที่มีอยู่ของเราหรือไม่? A: ไม่ Sugarbug ทำงานควบคู่กับเครื่องมือที่มีอยู่ของคุณและเชื่อมต่อพวกมัน – ไม่ได้แทนที่อันใดเลย PM ของคุณยังคงเขียนสเปคใน Notion วิศวกรของคุณยังคงทำงานใน Linear และ GitHub และ Sugarbug รักษาความสัมพันธ์ระหว่างพวกมันเพื่อให้บริบทไม่สูญหายระหว่างทาง คิดว่ามันเป็นเนื้อเยื่อเชื่อมต่อระหว่างเครื่องมือที่คุณใช้อยู่แล้ว
Q: Sugarbug ตรวจจับได้เมื่อสเปค Notion เปลี่ยนแปลงและแจ้งเตือนวิศวกรที่ถูกต้องได้หรือไม่? A: นั่นคือส่วนหลักของสิ่งที่เรากำลังสร้าง เมื่อสเปคเปลี่ยนแปลงใน Notion Sugarbug จะระบุว่า Linear issues ใดที่เชื่อมโยงกับมันและนำเสนอการเปลี่ยนแปลงต่อวิศวกรที่ทำงานกับ issues เหล่านั้น เรายังทำซ้ำในส่วนการตรวจจับความหมาย (หาว่าการเปลี่ยนแปลงใดมีนัยสำคัญเทียบกับรูปแบบเท่านั้น) แต่การเชื่อมต่อข้ามเครื่องมือและการตรวจจับการเปลี่ยนแปลงพื้นฐานกำลังทำงานอยู่
Q: ความแตกต่างระหว่างเครื่องมือซิงค์และกราฟความรู้สำหรับปัญหานี้คืออะไร? A: เครื่องมือซิงค์คัดลอกการเปลี่ยนแปลงสถานะระหว่างแอป – เมื่อ Linear issue ย้ายไป "Done" อัปเดต Notion checkbox กราฟความรู้ติดตามว่าข้อมูลเกี่ยวข้องกันอย่างไร: สเปคนี้อธิบายความต้องการสำหรับ three issues เหล่านี้ และเกณฑ์การยอมรับเปลี่ยนแปลง ซึ่งส่งผลต่อสอง issues ที่ยังไม่ได้ส่งมอบ ความแตกต่างมีความสำคัญมากที่สุดเมื่อการเปลี่ยนแปลงเป็นเชิงความหมาย ไม่ใช่แค่ระดับสถานะ
Q: การจัดแนวผลิตภัณฑ์และวิศวกรรมเป็นปัญหาการสื่อสารหรือปัญหาข้อมูล? A: จากประสบการณ์ของเรา มักเป็นปัญหาข้อมูลที่ถูกวินิจฉัยผิดว่าเป็นปัญหาการสื่อสาร ทีมกำลังสื่อสาร – แค่ทำผ่านเครื่องมือที่ไม่มีความตระหนักซึ่งกันและกัน การแก้ไขการไหลของข้อมูลระหว่างเครื่องมือเหล่านั้นมักจะแก้ปัญหาการจัดแนวที่การประชุมย้อนหลังหรือ sync meetings จำนวนมากไม่สามารถแก้ได้