วิธีค้นหาการตัดสินใจเก่าใน Slack (เมื่อการค้นหาไม่เพียงพอ)
วิธีค้นหาการตัดสินใจเก่าใน Slack เมื่อการค้นหาคำสำคัญล้มเหลว เหตุใดการตัดสินใจหายไป บันทึกการตัดสินใจไม่ได้ผล และระบบที่รับรู้การตัดสินใจควรเป็นอย่างไร
By Ellis Keane · 2026-03-14
ลองนึกดู: ทีมของคุณตัดสินใจใช้ webhooks แทน polling ที่ไหน? ไม่ใช่ สิ่งที่ คุณตัดสินใจ – แต่การตัดสินใจนั้นถูกบันทึกไว้ที่ไหนในตอนนี้ ในที่ที่คนที่เข้าร่วมทีมเดือนหน้าจะหาพบ?
ถ้าคุณเหมือนพวกเรา คำตอบที่ซื่อสัตย์อยู่ที่ไหนสักแห่งระหว่าง "น่าจะเป็น Slack thread" และ "ฉันคิดว่ามันอยู่ใน #eng-backend บางทีสามสัปดาห์ที่แล้ว และฉันค่อนข้างแน่ใจว่ามีคนสองสามคนเกี่ยวข้อง แต่จำไม่ได้จริงๆ ว่าเป็นใครบ้าง" ซึ่งเป็นสถานการณ์ที่น่าสนใจ เพราะการตัดสินใจนั้นสำคัญพอที่จะเปลี่ยนวิธีที่ระบบทั้งหมดทำงาน แต่ดูเหมือนจะไม่สำคัญพอที่ใครจะบันทึกไว้ในที่ที่ไม่ใช่กระแสความคิดที่จัดระเบียบตามเวลา และนั่นคือแก่นของปัญหาในการค้นหาการตัดสินใจเก่าใน Slack – ข้อมูลทั้งหมดมีอยู่ แต่ไม่ได้จัดระเบียบในแบบที่ให้คุณดึงมาในฐานะ "การตัดสินใจ" ได้
ฉันศึกษาวิธีค้นหาการตัดสินใจเก่าใน Slack มาสักพักแล้ว และยิ่งขุดลึก ยิ่งเชื่อว่าปัญหาหลักไม่ใช่วินัยหรือนิสัยหรืออะไรที่คนอื่นมักโทษ แต่มันเป็นเรื่องสถาปัตยกรรม การค้นหาของ Slack ถูกสร้างมาเพื่อค้นหาข้อความ และการตัดสินใจไม่ใช่ข้อความ – มันคือความหมายที่บังเอิญถูกแสดงออกผ่านข้อความ ซึ่งฟังดูเล็กน้อยจนกว่าคุณจะใช้เวลายี่สิบนาทีเลื่อนดูผลการค้นหาเพื่อหาว่า webhook ที่กล่าวถึง 17 ครั้งนั้น ครั้งไหนที่ทีมของคุณตัดสินใจจริงๆ ว่าจะใช้มัน
การค้นหาของ Slack ทำงานอย่างไร (และอะไรที่ทำให้มันพัง)
มาพูดให้ชัดเจน เพราะ "การค้นหาของ Slack แย่" ไม่ใช่การวินิจฉัยที่ถูกต้อง – การค้นหาของ Slack ทำสิ่งที่มันทำได้ดีมาก ปัญหาคือสิ่งที่มันทำและสิ่งที่คุณต้องการให้มันทำเมื่อคุณมองหาการตัดสินใจนั้นเป็นสองสิ่งที่แตกต่างกันโดยพื้นฐาน
Slack จัดทำดัชนีข้อความเป็นข้อความพร้อมข้อมูลเมตา: เวลา ผู้ส่ง ช่องทาง และ (ถ้าคุณใช้แผนแบบชำระเงิน) บริบท thread ทั้งหมด เมื่อคุณค้นหา "webhook" Slack จะส่งคืนข้อความทุกข้อความที่มีคำนั้น จัดอันดับตามความใหม่และความเกี่ยวข้อง คุณสามารถจำกัดขอบเขตด้วย ตัวดำเนินการค้นหา – in:#eng-backend from:@sarah before:2026-02-15 – แต่สิ่งที่คุณทำคือกรองรายการข้อความแบบแบนเดียวกันตามข้อมูลเมตา นี่คือการดึงข้อมูลด้วยคำสำคัญ และสำหรับการค้นหาข้อความเฉพาะที่คุณจำได้คร่าวๆ มันทำงานได้ดี
แต่การตัดสินใจไม่ใช่คำสำคัญ การตัดสินใจคือความสัมพันธ์ระหว่างคำถาม ชุดตัวเลือก ชุดผู้คน และช่วงเวลาที่กลุ่มตกลงเลือกตัวเลือกหนึ่ง ข้อความจริงของการตัดสินใจอาจเป็น "โอเค ทำ webhooks เลยดีกว่า วิธี polling กิน rate limit ของเราหมด" – ซึ่งเป็นภาษาสนทนา มีบริบท และมีความหมายก็ต่อเมื่อคุณรู้ thread ที่มันปรากฏอยู่ หรืออาจเป็น "ได้เลย ลอง prototype ดูก่อน" ซึ่งไม่มีคำสำคัญใดที่เกี่ยวข้องกับการตัดสินใจทางเทคนิคที่มันแทนอยู่เลย
นี่คือความไม่ตรงกันทางสถาปัตยกรรม: Slack จัดเก็บข้อความตามลำดับเวลาและดึงข้อมูลด้วยคำสำคัญ การตัดสินใจเป็นเรื่องความหมาย (มันเกี่ยวกับ ความหมาย) และเชิงสัมพันธ์ (มันเชื่อมต่อกับงาน ผู้คน และผลลัพธ์) คุณกำลังขอให้ระบบจัดเก็บแบบลำดับเวลาทำการดึงข้อมูลเชิงความหมาย และมันทำไม่ได้ เพราะไม่เคยถูกออกแบบมาเพื่อสิ่งนั้น ช่องว่างระหว่าง "ค้นหาได้" และ "หาพบ" กลายเป็นเรื่องมหาศาล – ทุกข้อความในประวัติ Slack ของคุณสามารถค้นหาได้ในทางเทคนิค แต่นั่นไม่ได้หมายความว่าการตัดสินใจที่คุณต้องการจะหาพบได้ในทางปฏิบัติ
"Slack ได้สร้างที่เก็บการตัดสินใจขององค์กรที่ใหญ่ที่สุดแห่งหนึ่งในประวัติศาสตร์ และแทบไม่มีสิ่งใดที่ดึงกลับมาเป็น 'การตัดสินใจ' ได้ – ทุกคำถูกเก็บรักษาไว้อย่างสมบูรณ์แต่แทบหาไม่พบ" – Ellis Keane
สิ่งที่เกิดขึ้นเมื่อคุณพยายามค้นหาการตัดสินใจเก่าใน Slack
นี่คือลักษณะของความไม่ตรงกันในทางปฏิบัติ สมมติว่าทีมของคุณตัดสินใจสามสัปดาห์ที่แล้วว่าจะเปลี่ยนจาก polling เป็น webhooks สำหรับการเชื่อมต่อ GitHub คุณจำได้ว่าการสนทนาเกิดขึ้นใน #eng-backend และมีวิศวกรหลายคนเกี่ยวข้อง คุณจึงค้นหา "webhook" ในช่องนั้น
สิ่งที่กลับมา: ทุกข้อความที่เคยกล่าวถึง webhooks ใน #eng-backend รายงานบักจากหกเดือนที่แล้ว คนที่ถามเรื่อง webhook retry logic ในบริบทที่ต่างออกไปโดยสิ้นเชิง ลิงก์ที่ใครบางคนแชร์ไปยังบล็อกโพสต์เกี่ยวกับ webhook best practices (ซึ่งโดยความย้อนแย้งอย่างสวยงาม น่าจะอยู่สูงกว่าในผลการค้นหามากกว่าการตัดสินใจจริงๆ ที่มันอยู่ติดกัน) การตัดสินใจเอง – การตอบกลับใน thread ที่มีคนพูดว่าวิธี polling ติด rate limit – ถูกฝังอยู่ที่ไหนสักแห่งในหน้าสาม มีลักษณะเหมือนกับทุกข้อความรอบๆ
และนั่นคือสถานการณ์ที่คุณจำได้คร่าวๆ ว่าใช้คำอะไร ครึ่งหนึ่งของเวลา การตัดสินใจใช้ภาษาที่มีบริบทมากจนเหมือนถูกเข้ารหัส "ไปกับตัวเลือก B เลย" ไม่มีคำว่า "webhook" เลย แม้ว่าตัวเลือก B คือ webhooks "ได้เลย ลอง prototype" แม้แต่คำว่า "ตัวเลือก" ก็ไม่มี ช่วงเวลาจริงของการตัดสินใจมักเป็นข้อความที่สั้นที่สุดและมีคำสำคัญน้อยที่สุดในทั้ง thread เพราะ ณ จุดนั้น ทุกคนในการสนทนาเข้าใจบริบทแล้วและกำลังแค่ยืนยันความเห็นพ้อง
ฉันพบว่านี่น่าสนใจจริงๆ ในฐานะปัญหาสถาปัตยกรรมข้อมูล (น่าสนใจและน่าหงุดหนิดเล็กน้อยเมื่อคุณเป็นคนที่กำลังค้นหา) Slack ได้สร้างที่เก็บการตัดสินใจขององค์กรที่ใหญ่ที่สุดแห่งหนึ่งในประวัติศาสตร์ และแทบไม่มีสิ่งใดที่ดึงกลับมาเป็น "การตัดสินใจ" ได้ – ทุกคำถูกเก็บรักษาไว้อย่างสมบูรณ์ และแทบหาไม่พบ
เหตุใดบันทึกการตัดสินใจจึงเหมือนสุสานที่มีป้ายบอกทางที่ดีขึ้น
คำแนะนำมาตรฐาน ถ้าคุณมองหาวิธีแก้ปัญหา คือเก็บบันทึกการตัดสินใจ ฐานข้อมูล Notion ช่อง Slack เฉพาะ (ความย้อนแย้งซึ่งดูเหมือนจะหลุดลอยจากคนที่แนะนำ) หน้า wiki – ที่เดียวที่การตัดสินใจจะถูกบันทึกเมื่อเกิดขึ้น
เราลองแล้ว มันอยู่ได้ประมาณหกสัปดาห์ สองสัปดาห์แรกยอดเยี่ยม – ทุกคนทุ่มเท รายการมีรายละเอียด บันทึกมีประโยชน์จริงๆ พอถึงสัปดาห์ที่สาม รายการเริ่มขาดหาย พอถึงสัปดาห์ที่ห้า มีคนเดียวที่ยังอัปเดต เขียนสิ่งต่างๆ เช่น "ตัดสินใจเรื่อง auth" โดยไม่มีลิงก์ ไม่มีบริบท และไม่มีการระบุว่าใครเกี่ยวข้องหรือทางเลือกอื่นคืออะไร พอถึงสัปดาห์ที่หกเราก็เลิกแสร้งทำเป็นอย่างเงียบๆ
ปัญหาไม่ใช่ว่าทีมของเราขาดวินัย (อาจจะนะ แต่นั่นไม่ใช่ปัญหาหลัก) ปัญหาคือการบันทึกการตัดสินใจเรียกเก็บ "ภาษี" ในช่วงเวลาที่ผิดอย่างแม่นยำ คุณเพิ่งมีการสนทนาที่มีประสิทธิผล คุณตกลงกันได้แล้ว มีคนพร้อมเริ่มสร้าง – และตอนนี้คุณต้องหยุด เปิดเครื่องมืออื่น เขียนสรุป แท็กคนที่เกี่ยวข้อง และลิงก์กลับไปยังการสนทนาเดิม นั่นคือสามถึงห้านาทีต่อการตัดสินใจ และสำหรับทีมที่ตัดสินใจสำคัญห้าถึงสิบครั้งต่อวันข้ามช่องและ threads ค่าใช้จ่ายสะสมจนกลายเป็นสิ่งที่ไม่มีใครอยากเป็นเจ้าของ
และระบบทำงานได้เฉพาะเมื่อปฏิบัติตาม 100% เท่านั้น บันทึกการตัดสินใจที่มีการตัดสินใจ 70% แย่กว่าไม่มีบันทึกเลยในบางแง่ เพราะตอนนี้คุณตรวจสองที่และไม่เชื่อทั้งคู่ คุณดูในบันทึก การตัดสินใจไม่อยู่ที่นั่น คุณก็ไปค้นหาใน Slack อยู่ดี – และคุณกลับมาที่จุดเริ่มต้น ยกเว้นตอนนี้คุณเสียเวลาสองนาทีกับการตรวจบันทึกก่อนด้วย
การตัดสินใจไม่ใช่เหตุการณ์ – แต่เป็นการไล่ระดับ
ส่วนหนึ่งที่ทำให้การบันทึกด้วยตนเองล้มเหลวคือมันสันนิษฐานว่าการตัดสินใจเป็นช่วงเวลาที่แยกชัดเจนและระบุได้ ในความเป็นจริง การตัดสินใจส่วนใหญ่ค่อยๆ เกิดขึ้นผ่านการสนทนา และ "ช่วงเวลาของการตัดสินใจ" มักไม่ชัดเจนจริงๆ
ลองพิจารณาว่าการตัดสินใจทางวิศวกรรมทั่วไปเกิดขึ้นอย่างไร มีคนหยิบยกข้อกังวลใน Figma comment: "รูปแบบการโต้ตอบนี้อาจใช้งานบนมือถือไม่ได้" วิศวกรตอบกลับใน Slack thread โดยแท็ก comment เดิม: "ใช่ ฉันดูแล้ว – component library ไม่รองรับ" นักออกแบบเสนอวิธีการทางเลือกใน thread เดียวกัน วิศวกรพูดว่า "ได้เลย ลอง prototype ดู" สองวันต่อมา PR ถูกส่งขึ้นพร้อม implement ทางเลือก และ Linear issue ถูกอัปเดต
การตัดสินใจเกิดขึ้นที่ไหน? เป็น Figma comment ที่หยิบยกปัญหาไหม? Slack thread ที่เสนอทางเลือกไหม? ช่วงเวลาที่วิศวกรพูดว่า "ได้เลย"? PR ที่ implement ไหม? ในทางปฏิบัติ การตัดสินใจกระจายออกไปในสี่ช่วงเวลาเหล่านั้น ครอบคลุมสองเครื่องมือและสามวัน มันไม่ใช่เหตุการณ์ที่คุณจะบันทึกได้ – มันเป็นการไล่ระดับที่แก้ไขเป็นผลลัพธ์ และเหตุผลเดียวที่เราทราบว่ามีการตัดสินใจคือโค้ดเปลี่ยนไป
ฉันคิดว่านี่คือส่วนที่คำแนะนำ "การติดตามการตัดสินใจ" ส่วนใหญ่เข้าใจผิด มันปฏิบัติกับการตัดสินใจเหมือนสิ่งที่คุณจับได้ เหมือนการเขียนหมายเลขโทรศัพท์ลง แต่การตัดสินใจจริงๆ ส่วนใหญ่คือสิ่งที่คุณสร้างขึ้นใหม่ – คุณมองว่าอะไรเปลี่ยนไป ย้อนรอยผ่านการสนทนาที่นำไปสู่นั้น และรวบรวมเหตุผลหลังจากนั้น ซึ่งหมายความว่าระบบที่คุณต้องการไม่ใช่บันทึก แต่เป็นกราฟ
สิ่งที่กราฟให้คุณที่บันทึกไม่สามารถให้ได้
กราฟเชื่อมโยงสัญญาณข้ามเครื่องมือและเวลา แทนที่ใครบางคนจะเขียนด้วยตนเองว่า "เราตัดสินใจใช้ webhooks เพราะ rate limit" กราฟจะเชื่อมโยง Slack thread ที่พูดถึง rate limit, Linear issue ที่ติดตามงานการเชื่อมต่อ, PR ที่ implement webhooks และผู้คนที่เกี่ยวข้องในการสนทนา การตัดสินใจไม่ได้ถูกบันทึก – มันสามารถสร้างใหม่ได้จากการเชื่อมต่อระหว่างสิ่งที่เกิดขึ้นอยู่แล้ว
ความแตกต่างในทางปฏิบัติปรากฏในสถานการณ์เฉพาะ สามสัปดาห์หลังการตัดสินใจเรื่อง webhook วิศวกรใหม่เข้าร่วมและถามว่า "ทำไมเราใช้ webhooks แทน polling สำหรับ GitHub? Polling ดูง่ายกว่า" หากไม่มีระบบที่เชื่อมต่อ มีคนพูดว่า "โอ้ เราตัดสินใจเรื่องนั้นนานแล้ว" ไม่มีใครจำได้ว่าช่องไหน มีคนใช้เวลาสิบห้านาทีค้นหาใน Slack และพวกเขาอาจพบหรือ (ส่วนใหญ่แล้ว) สร้างเหตุผลขึ้นจากความจำ ซึ่งเสี่ยงเพราะความจำไม่น่าเชื่อถือและเหตุผลเดิมน่าจะละเอียดกว่าที่ใครจำได้สามสัปดาห์ต่อมา
ด้วยกราฟ วิศวกรดูที่ GitHub integration task ทุกสัญญาณที่แตะงานนั้นถูกเชื่อมโยง: การสนทนาเดิมเรื่อง rate limit, thread ที่ประเมิน polling กับ webhooks, PR ที่ implement การเปลี่ยนแปลง เส้นทางการตัดสินใจทั้งหมด ตั้งแต่ต้นจนจบ โดยไม่มีใครต้องค้นหาอะไรและโดยไม่มีใครต้องบันทึกอะไร
ช่องว่างไม่ได้อยู่ระหว่าง "การค้นหาที่ดี" และ "การค้นหาที่แย่" – มันอยู่ระหว่างการดึงข้อมูลด้วยคำสำคัญและการดึงข้อมูลด้วยความสัมพันธ์ การตัดสินใจถูกกำหนดโดยการเชื่อมต่อกับงาน ผู้คน และผลลัพธ์ ไม่ใช่โดยคำที่ใช้แสดงออก
ต้นทุนที่ไม่ปรากฏในแดชบอร์ดใดๆ
ฉันไม่ค่อยเชื่อตัวเลขที่แม่นยำสำหรับต้นทุนที่จับต้องได้ยาก (สถิติแนว "ทีมเสียเวลา X ชั่วโมงต่อสัปดาห์" มักรู้สึกเหมือนย้อนกลับมาจากข้อสรุปที่ต้องการ) แต่นี่คือสิ่งที่เราสังเกตเห็นในทีมของเราเอง
ต้นทุนที่เห็นชัดที่สุดคือการเปิดประเด็นซ้ำ – เมื่อไม่มีใครหาการตัดสินใจเดิมพบ ทีมก็เปิดประเด็นนั้นใหม่ บางครั้งเพราะผู้คนจำไม่ได้จริงๆ และบางครั้งเพราะสมาชิกทีมใหม่มีคำถามที่ถูกต้องที่ไม่มีใครสามารถตอบได้ด้วยข้อมูลเฉพาะเจาะจง เราเปิดประเด็นที่แก้ไขแล้วซ้ำๆ อยู่เสมอก่อนที่เราจะมีวิธีย้อนรอยการตัดสินใจกลับสู่แหล่งที่มา และการเปิดประเด็นซ้ำแต่ละครั้งก็มีค่าใช้จ่ายของตัวเอง: เวลาในการประชุม ความเหนื่อยล้าทางอารมณ์จากการโต้เถียงเรื่องที่คุณค่อนข้างมั่นใจว่าแก้ไขแล้ว ความสงสัยที่รบกวนว่าเหตุผลเดิมละเอียดกว่าที่ใครจำได้
ต้นทุนที่ละเอียดกว่าคือสิ่งที่เกิดขึ้นระหว่างการ onboarding ทุกคำถาม "ทำไมถึงทำแบบนี้?" จากสมาชิกทีมใหม่ขัดจังหวะคนที่อยู่ในการตัดสินใจเดิม และคำตอบถูกสร้างขึ้นจากความจำทุกครั้งที่มีคนถาม เบี่ยงเบนออกจากเหตุผลเดิมเล็กน้อยในแต่ละครั้ง เหมือนเกมโทรศัพท์ที่โทรศัพท์คือซอฟต์แวร์องค์กรและข้อความคือ "ทำไมสถาปัตยกรรมถึงทำงานแบบนี้" และมีช่องว่างความน่าเชื่อถือที่สะสมตามเวลา: "เราใช้ webhooks" มีน้ำหนักน้อยกว่า "เราใช้ webhooks เพราะ polling กิน GitHub API rate limit ของเรา 40% และเราติด throttling ในชั่วโมงเร่งด่วน" เหตุผลคือสิ่งที่ช่วยให้วิศวกรในอนาคตประเมินว่าการตัดสินใจยังคงใช้ได้ภายใต้สถานการณ์ที่เปลี่ยนไป และเหตุผลนั้นอยู่ใน Slack thread ที่ไหนสักแห่ง ถูกเก็บรักษาไว้อย่างสมบูรณ์แต่แทบมองไม่เห็น
หยุดสูญเสียการตัดสินใจใน Slack scroll Sugarbug ติดตามเส้นทางการตัดสินใจทั้งหมด – จาก Slack thread ไปยัง Linear issue ไปยัง PR – โดยอัตโนมัติ
Q: เหตุใดการค้นหาการตัดสินใจเก่าใน Slack จึงยากมาก? A: Slack จัดเก็บข้อความตามลำดับเวลา ไม่ใช่ตามความหมาย การตัดสินใจที่ฝังอยู่ใน thread มีลักษณะเหมือนกับการตอบกลับทั่วไปทุกประการ – การค้นหาของ Slack สามารถจับคู่คำสำคัญได้ แต่ไม่สามารถแยกแยะ "เราตัดสินใจใช้ Redis" จาก "เราควรใช้ Redis ไหม?" โดยไม่อ่านบริบทการสนทนาเต็มๆ ยิ่งเวลาผ่านไปยิ่งยากขึ้น เพราะคุณสูญเสียสัญญาณบริบท (ใครเกี่ยวข้อง ช่องไหน สัปดาห์ไหน) ที่ทำให้การค้นหาใช้ได้ผลตั้งแต่แรก
Q: Sugarbug ติดตามการตัดสินใจที่เกิดใน Slack โดยอัตโนมัติหรือไม่? A: ใช่ Sugarbug จำแนกสัญญาณที่เข้ามาจาก Slack และเครื่องมือที่เชื่อมต่ออื่นๆ โดยระบุรูปแบบที่คล้ายการตัดสินใจ – threads ที่อ้างถึงงาน เกี่ยวข้องกับผู้คนที่ได้รับมอบหมาย และส่งผลให้เกิดการเปลี่ยนแปลงสถานะหรือ PRs สิ่งเหล่านี้ถูกเชื่อมโยงกับงานที่เกี่ยวข้องในกราฟความรู้ ดังนั้นคุณสามารถย้อนรอยเส้นทางการตัดสินใจจากงานแทนที่จะค้นหาผ่านประวัติ Slack
Q: อะไรคือความแตกต่างระหว่างบันทึกการตัดสินใจและกราฟความรู้สำหรับการตัดสินใจ? A: บันทึกการตัดสินใจต้องให้คนบันทึกแต่ละครั้งด้วยตนเองเมื่อเกิดขึ้น – สังเกตมัน หยุด สรุป แท็ก ลิงก์ กราฟความรู้อนุมานการตัดสินใจจากสัญญาณที่ไหลผ่านเครื่องมือของคุณและเชื่อมโยงกับงาน ผู้คน และบทสนทนาโดยอัตโนมัติ อย่างหนึ่งต้องอาศัยวินัยที่สม่ำเสมอจากสมาชิกทีมทุกคน อีกอย่างทำงานในเบื้องหลังจากกิจกรรมที่เกิดขึ้นอยู่แล้ว
Q: Sugarbug สามารถดึงการตัดสินใจจากเครื่องมืออื่นนอกจาก Slack ได้หรือไม่? A: Sugarbug เชื่อมต่อกับ Slack, GitHub, Figma, Linear, Notion, อีเมล และปฏิทิน การตัดสินใจมักครอบคลุมหลายเครื่องมือ (Figma comment นำไปสู่ Slack thread นำไปสู่ PR) และกราฟความรู้เชื่อมโยงสัญญาณข้ามพื้นผิวที่เชื่อมต่อทั้งหมด คุณเห็นเส้นทางทั้งหมดไม่ว่าการสนทนาจะเริ่มต้นที่เครื่องมือใด
Q: สิ่งนี้แตกต่างจากการใช้การค้นหาในตัวของ Slack อย่างไร? A: การค้นหาของ Slack ค้นหาข้อความที่มีคำสำคัญเฉพาะ กราฟความรู้ค้นหาความสัมพันธ์ระหว่างข้อความ งาน และผู้คน เมื่อคุณมองหาการตัดสินใจ คุณไม่ค่อยได้ค้นหาคำ – คุณค้นหาช่วงเวลาที่ทีมเลือกวิธีหนึ่งแทนอีกวิธี และช่วงเวลานั้นถูกกำหนดโดยการเชื่อมต่อกับสัญญาณอื่นๆ ไม่ใช่โดยคำที่ใช้แสดงออก
---
หากการตัดสินใจยังคงหายไปใน Slack ของคุณ ปัญหาไม่ใช่ Slack – มันคือไม่มีระบบใดที่คอยดูช่วงเวลาที่สำคัญและเชื่อมโยงกับงานที่มันสร้างขึ้น นั่นคือช่องว่างที่เรากำลังสร้าง Sugarbug เพื่อเติมเต็ม