อินเตอร์คอมนำเสนอ แชทวิศวกร

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

หลายปีที่ผ่านมา เราได้กล่าวถึงพอดคาสต์ของเรามากมาย เราให้ข้อมูลเชิงลึกแก่คุณเกี่ยวกับโลกของการจัดการผลิตภัณฑ์ การออกแบบ การสนับสนุนและการตลาดด้วย Inside Intercom ทุกสัปดาห์ สำรวจว่าผู้นำในอุตสาหกรรมใช้ CX เพื่อขยายธุรกิจด้วย Scale อย่างไร และแสดงให้คุณเห็นโลกของ Des Traynor ผู้ร่วมก่อตั้ง Intercom และ Paul Adams รองประธานอาวุโสฝ่ายผลิตภัณฑ์ของ Intercom ขณะที่พวกเขาแบ่งปันความคิดล่าสุดเกี่ยวกับวิธีสร้างผลิตภัณฑ์ที่ยอดเยี่ยม

และตอนนี้สำหรับบางสิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิง เป็นครั้งแรกที่เราเปิดตัว Engineer Chats ซึ่งเป็นพอดคาสต์ภายในที่ Intercom เกี่ยวกับวิศวกรรมทุกอย่าง ก่อนหน้านี้ Jamie Osler วิศวกรผลิตภัณฑ์อาวุโสของ Intercom เป็นเจ้าภาพมานานกว่าเจ็ดปี ตอนนี้ Brian Scanlan หัวหน้าวิศวกรระบบจะหยิบกระบองและสนทนาต่อไป

สัปดาห์นี้ นอกจากเจมี่และไบรอัน คุณจะได้ยินจาก:

• Mike Stewart อดีตหัวหน้าวิศวกรอาวุโสของ Intercom
• Patrick O'Doherty อดีตวิศวกรความปลอดภัยอาวุโสที่ Intercom และปัจจุบันเป็นวิศวกรที่ Oso
• Ciaran Lee ผู้ร่วมก่อตั้งอินเตอร์คอม
• Meena Polich ที่ปรึกษาอาวุโสของ Intercom ที่สนับสนุน R&D

จากกระบวนการแก้ความกำกวมและการหยุดทำงานที่เลวร้ายที่สุดที่เราเคยมี ไปจนถึงความหลงใหลในความเร็ว และวิธีที่ทีมกฎหมายและวิศวกรรมสามารถทำงานร่วมกันได้ดียิ่งขึ้น Engineer Chats จะให้ข้อมูลเบื้องหลังกระบวนการทางวิศวกรรมที่ Intercom แก่คุณ

หากคุณมีเวลาไม่มากพอ ต่อไปนี้คือคำแนะนำสั้นๆ สองสามข้อ:

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

หากคุณชอบการสนทนาของเรา โปรดดูตอนอื่นๆ ของพอดคาสต์ของเรา คุณสามารถติดตามบน iTunes, Spotify หรือรับฟีด RSS ในเครื่องเล่นที่คุณเลือก ต่อไปนี้คือการถอดเสียงของตอนที่มีการแก้ไขเล็กน้อย

Liam Geraghty: สวัสดี ยินดีต้อนรับสู่ Inside Intercom ฉันชื่อเลียม เจอราห์ตี้ หากคุณเป็นผู้ฟังเป็นประจำ คุณจะรู้ว่าเราสัมภาษณ์ผู้สร้างและผู้ปฏิบัติงานจากโลกแห่งการจัดการผลิตภัณฑ์ การออกแบบ การเริ่มต้นธุรกิจ และการตลาด เรายังมีพอดแคสต์อื่นๆ อีก 2 รายการ ได้แก่ Intercom on Product ซึ่ง Des Traynor ผู้ร่วมก่อตั้ง Intercom และ Intercom SVP of Product อย่าง Paul Adams ได้พูดคุยถึงความคิดล่าสุดของพวกเขาเกี่ยวกับวิธีสร้างผลิตภัณฑ์ที่ประสบความสำเร็จตามขนาดและขนาดโดย Intercom ซึ่งเราจะสำรวจว่าธุรกิจเป็นอย่างไร ขับเคลื่อนการเติบโตผ่านความสัมพันธ์กับลูกค้า

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

วันนี้ เราขอนำเสนอหน้าต่างเสียงเกี่ยวกับวิศวกรรมทุกอย่างที่ Intercom เราได้นำส่วนที่ดีที่สุดมาจากการแสดง ตั้งแต่เรื่องราวการหยุดชะงักที่เลวร้ายที่สุดที่เราเคยมี ไปจนถึงการที่ทีมกฎหมายและวิศวกรจะทำงานร่วมกันได้ดียิ่งขึ้น ขั้นแรก แก้ความกำกวม: การกระทำหรือกระบวนการแยกแยะระหว่างสิ่งที่คล้ายคลึงกันและความหมายเพื่อทำให้ความหมายหรือการตีความชัดเจนหรือแน่นอนมากขึ้น Mike Stewart อดีตหัวหน้าวิศวกรอาวุโสของ Intercom นั่งคุยกับ Jamie ในเดือนตุลาคม 2020 เกี่ยวกับคำนั้นและเหตุผลที่เขาใช้คำนี้มากในที่ทำงาน นี่ เจมี่

แก้ความกำกวมจนหมด

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

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

“คุณมีพื้นที่โซลูชันที่กว้างขวาง… เป็นกระบวนการที่คดเคี้ยวไปตามหลักฐาน การตัดสินใจ และการเรียกร้อง”

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

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

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

Jamie Osler: คุณแคบลงเช่นกัน บางทีคุณอาจแก้ความกำกวมได้นิดหน่อย

Liam Geraghty: ไมค์มีวิธีที่ยอดเยี่ยมในการแสดงภาพกระบวนการแก้ความกำกวม

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

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

เป็นหนึ่งเดียวกับตัวแบบข้อมูล

Liam Geraghty: เพื่อเชื่อมโยงทั้งหมดนี้กับตัวอย่างที่เป็นรูปธรรม Jamie นำเสนอสิ่งนี้

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

ไมค์ สจ๊วร์ต: ใช่ แน่นอน ในแง่ของระดับการซูมที่เรากำลังพูดถึงก่อนหน้านี้ สำหรับฉัน ระดับการซูมการออกแบบเทคโนโลยีระดับสูงนั้นเหมาะสม โดยสรุป ในการเรียกเก็บเงิน เราอยู่ในจุดที่ "เฮ้ เราค่อนข้างเข้าใจดีว่าเรามีสองระบบนี้ เรามีแอพ Rails ของเราเอง และเรามีระบบ Zuora ภายนอกนี้ เรารู้ว่าอย่างน้อยสำหรับอนาคตที่ดี เราจะมีสองระบบนี้ เราจะไม่เปลี่ยนข้อจำกัดนั้น เรามีหลายอย่างที่สร้างขึ้นจากพวกเขาสองคน ดังนั้นจึงเป็นไปไม่ได้ที่จะย้ายออกไป เราจำเป็นต้องมีทั้งสองระบบที่ประสานกัน และเราต้องการให้ทั้งสองระบบเห็นพ้องต้องกัน และปัญหาทั้งหมดเหล่านี้เกิดจากการที่เราไม่สามารถทำให้ระบบทั้งสองสอดคล้องกันได้ เราต้องการให้ปัญหาเหล่านั้นหายไป เราเข้าใจดีว่าเป็นภารกิจ

“คุณไม่สามารถคิดค้นอัลกอริทึมที่ไม่ขึ้นกับตัวแบบข้อมูลได้ และฉันคิดว่ามันก็เหมือนกันเมื่อคุณเริ่มพูดถึงระบบและคุณลักษณะของผลิตภัณฑ์”

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

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

“ฉันไม่เคยสบายใจที่จะก้าวไปข้างหน้าด้วยการออกแบบทางเทคนิค เว้นแต่ฉันจะเข้าใจโมเดลข้อมูลอย่างถ่องแท้”

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

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

Jamie Osler: นั่นมีประโยชน์มาก นั่นเป็นการสนทนาที่ยอดเยี่ยมเกี่ยวกับวิธีการที่คุณแยกแยะโปรเจ็กต์

Mike Stewart: ฉันหวังว่ามันจะเป็นการสนทนาที่ดีนะ Jamie และฉันหวังว่าเราจะได้เนื้อหาที่มีประโยชน์ที่นี่

Jamie Osler: เนื้อหาแฮชแท็ก

ด้านสว่างของการหยุดทำงานที่ไม่ดีรุ่งโรจน์

Liam Geraghty: เมื่อต้นปีนี้ หากคุณเป็นผู้ใช้ Facebook, WhatsApp หรือ Instagram คุณจะจำการหยุดทำงานนั้นในเดือนตุลาคมได้อย่างไม่ต้องสงสัย เป็นการหยุดทำงานทั่วโลกที่ยาวนานที่สุดของ Facebook ในประวัติศาสตร์ ทั้งหมดนี้เกิดจากการเปลี่ยนแปลงการกำหนดค่าที่ผิดพลาดในตอนท้าย ดังนั้นการหยุดทำงานจึงไม่สนุกสำหรับทุกคน คนที่ไม่ชอบพวกเขาเป็นพิเศษคือ Brian Scanlan หัวหน้าวิศวกรระบบอินเตอร์คอม

Brian Scanlan: ฉันเกลียดการหยุดทำงาน ซึ่งเป็นเหตุผลที่ฉันอุทิศอาชีพเพื่อต่อสู้กับปัญหาเหล่านี้

Liam Geraghty: Brian นั่งคุยกับ Jamie เกี่ยวกับพวกเขาในเดือนพฤศจิกายน 2020

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

Liam Geraghty: Brian นึกถึงเหตุขัดข้องบางประการที่ Intercom

“ฉันจำได้ว่าอยากป่วยในถังขยะเมื่อรู้ว่า Elasticsearch ว่างเปล่า ฉันชอบ 'โอ้ นี่มันแย่มาก'”

Brian Scanlan: หนึ่งในปัญหาที่กระทบกระเทือนจิตใจมากที่สุดที่ฉันเผชิญ แม้ว่าจริงๆ แล้วฉันไม่ได้อยู่ที่นั่นในช่วงที่ไฟฟ้าดับ ก็คือการหยุดทำงานของ Elasticsearch ครั้งใหญ่ในเดือนมกราคม 2019

Liam Geraghty: คนที่อยู่ที่นั่นคือ Patrick O'Doherty ซึ่งเป็นวิศวกรความปลอดภัยอาวุโสในตอนนั้น

Patrick O'Doherty: ฉันจำได้ว่าฉันอยากป่วยในถังขยะ เมื่อรู้ว่า Elasticsearch ว่างเปล่า ฉันก็แบบ “โอ้ นี่มันแย่จริงๆ”

Brian Scanlan: นี่เป็นงานที่น่าตื่นเต้นเป็นพิเศษ ฉันไม่ได้อยู่ที่นั่นเพราะฉันไปดื่มฉลองวันเกิดครบรอบ 40 ปีกับเพื่อนบางคน มันเป็นเหมือนเย็นวันศุกร์ และเนื่องจากเราไม่กลัวรหัสการจัดส่งสำหรับการผลิตในวันศุกร์ ฉันจึงอนุมัติคำขอดึงที่เพิ่มซับเน็ตใน VPC AWS ของเราในเย็นวันศุกร์

Jamie Osler: ระหว่างดื่ม?

Brian Scanlan: ไม่ จริงๆ แล้วมันอยู่ระหว่างทาง ตอนนั้นฉันมีสติสัมปชัญญะ เมื่อมีการพยายามเพิ่มซับเน็ตนั้นลงในเครือข่ายของเราภายใน Amazon ระบบอัตโนมัติที่เราเขียน... เราใช้เครื่องมือที่เรียกว่า Terraform เพื่อจัดการโครงสร้างพื้นฐานระดับต่ำของเราภายใน AWS และเรามีโมดูลทีมจำนวนมาก ลองนึกถึง เป็นโค้ดแบบใช้ซ้ำได้ที่เราเขียนขึ้นเพื่อพยายามลดความซับซ้อนของโครงสร้างพื้นฐานจำนวนมากภายใน AWS ด้วยการตั้งค่าและสิ่งต่างๆ ทั้งหมดที่เราต้องการนำไปใช้

“ในตอนนั้น เมื่อใช้การกำหนดค่า เครือข่ายของเราได้ทำลายหรือออฟไลน์โดยสิ้นเชิง”

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

Jamie Osler: ฉันหมายความว่ามันแย่ใช่มั้ย ที่ไม่ดี

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

“การค้นหาว่าเกิดอะไรขึ้นบนโลกและข้อมูลนั้นไปที่ไหนก็ใช้เวลานานเช่นกัน เรากำลังพูดถึงการหยุดทำงานแปดชั่วโมงที่นี่”

แต่น่าเสียดาย ในระหว่างนี้ ระบบอัตโนมัติอื่นๆ เริ่มเข้ามา คราวนี้ ระบบอัตโนมัติบางอย่างที่ AWS เป็นเจ้าของ เราใช้เทคโนโลยีนี้เรียกว่า OpsWorks ซึ่งเป็นเวอร์ชันที่ได้รับการจัดการของ Chef เพื่อจัดการโฮสต์ Elasticsearch ของเรา มีฟังก์ชันที่เรียกว่าการรักษาอัตโนมัติในตัว ซึ่งเราได้เปิดใช้งานโดยค่าเริ่มต้นในการกำหนดค่าระดับโฮสต์ของเรา และถ้าแบ็กเอนด์ OpsWorks ไม่สามารถติดต่อโฮสต์ได้ ระบบเวิร์กโฟลว์ของ OpsWorks จะพยายามรักษาโฮสต์ที่เป็นปัญหาโดยอัตโนมัติ เนื่องจากพบว่ามีบางอย่างผิดพลาดอยู่ที่นั่น ระบบปฏิบัติการไม่ทำงาน หน่วยความจำอาจไม่เพียงพอ มีสิ่งเลวร้ายเกิดขึ้น มาลองแก้ไขกัน ดังนั้น ส่วนควบคุมของ OpsWorks นี้จึงตัดสินใจแก้ไขโครงสร้างพื้นฐานทั้งหมดของเราโดยแทนที่โฮสต์

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

“เราไม่ได้แค่พูดว่า 'ตอนนี้เรารู้ปัญหาสองข้อนี้แล้ว มาแก้ปัญหากัน' เราออกไปและมองหาส่วนอื่นๆ ของระบบอัตโนมัติที่อาจกัดเราในสถานการณ์ที่แปลกประหลาด”

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

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

Patrick O'Doherty: ฉันจำไม่ได้ว่าเป็นใคร แต่ประมาณหนึ่งชั่วโมงต่อมา มีคนขอบคุณฉันที่ทำให้เกิดเหตุการณ์นี้เพราะพวกเขาแบบว่า “ว้าว คุณเขย่าของหลายอย่างจากต้นไม้ที่นี่จริงๆ นี่จะเป็นการตอบสนองเหตุการณ์ที่สนุกจริงๆ” นั่นเป็นพื้นฐานของมัน มันเหมือนกับว่า “โอ้ ว้าว เรากำลังขุดของที่นี่” และมันก็เป็น. การใช้ Terraform ของเราและวุฒิภาวะโดยทั่วไปของเราในการใช้เครื่องมือโดยตระหนักว่าเครื่องมือสามารถทำร้ายเราได้เช่นกัน เคารพเครื่องมือไฟฟ้า เช่นเดียวกับโครงสร้างพื้นฐาน เครื่องมือไฟฟ้าเป็นสิ่งที่อันตราย พวกเขาสามารถเคลื่อนไหวได้อย่างรวดเร็วและจับคุณด้วยความประหลาดใจ และฉันคิดว่าเราได้เรียนรู้บทเรียนของเราในวันนั้น

Brian Scanlan: ฉันยังชอบ Inside Intercom ที่พูดถึงเรื่องนี้ นอกจากนี้ ฉันไม่ได้อยู่ที่เกิดเหตุเพราะฉันอยู่ที่ผับในวันเกิดของฉัน มันดีมาก. มันเป็นเหตุการณ์ที่สมบูรณ์แบบ

ด้วยความเร็วแสง

Liam Geraghty: ในเดือนธันวาคม 2020 คริสต์มาส ฉันแน่ใจว่าเราจะไม่มีวันลืม Ciaran Lee ผู้ร่วมก่อตั้ง Intercom เข้าร่วมกับ Jamie เพื่อพูดคุยเกี่ยวกับความเร็ว และเหตุผลที่ Ciaran ใส่ใจเกี่ยวกับการเคลื่อนไหวอย่างรวดเร็ว

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

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

“มันเยี่ยมมากถ้าเรามีความพร้อม 100 เปอร์เซ็นต์ในแต่ละไตรมาส แต่บางทีเราควรถามตัวเองว่า 'เฮ้ เราไม่เสี่ยงพอเหรอ'”

Jamie Osler: หากคุณให้ความสำคัญกับบริษัทของคุณอย่างรวดเร็ว และมันเป็นสิ่งที่คุณทำอยู่ตลอดเวลา คุณมักจะแตกหักน้อยลง

Ciaran Lee: ใช่ เคลื่อนไหวอย่างรวดเร็วและทำลายสิ่งต่าง ๆ ภายในพารามิเตอร์ที่ยอมรับได้ เป็นเรื่องปกติที่จะมีไฟดับ การมีจุดบกพร่องเป็นเรื่องปกติ – แน่นอนว่ามีข้อบกพร่องบางประเภทที่คุณต้องการให้มีน้อยกว่าประเภทอื่นๆ แต่เรามีงบประมาณด้านความพร้อมใช้งาน คงจะดีถ้าเรามีห้องว่างเต็มร้อยเปอร์เซ็นต์ในหนึ่งไตรมาส แต่บางทีเราควรถามตัวเองว่า “เฮ้ เรายังเสี่ยงไม่พอเหรอ? เราขอเสี่ยงอีกหน่อยเพื่อก้าวให้เร็วขึ้นได้ไหม?” คุณควรจะอยู่ในจุดที่จงใจในสเปกตรัม และแน่นอนว่าเรามีความรับผิดชอบสูง เรามีลูกค้าจำนวนมาก ผู้คนหลายแสนคนที่เข้าสู่ระบบซึ่งมีหน้าที่ในการใช้กล่องจดหมายของเรา เพื่อพูดคุยกับลูกค้าในแต่ละวัน เราไม่สามารถเป็นเหมือนการทำลายสิ่งของด้วยการเคลื่อนไหวเร็วเกินไปหรือเปลี่ยนแปลงอย่างรวดเร็วจนพวกเขาไม่รู้วิธีใช้งานอีกต่อไป นั่นจะผิด เรามีข้อจำกัด แต่ภายในข้อจำกัดเหล่านั้น เราควรดำเนินการอย่างรวดเร็วที่สุดเท่าที่จะทำได้

ที่กฎหมายเข้ามา

Liam Geraghty: และเรากำลังดำเนินการให้เร็วที่สุดเท่าที่จะทำได้ในตอนนี้ ต่อไป อินเตอร์คอม ที่ปรึกษาอาวุโส มีนา โพลิช มีนาอยู่ในทีมกฎหมายของเราโดยมุ่งเน้นที่ผลิตภัณฑ์และวิศวกรรม ในเดือนมกราคม 2564 มีนาและเจมี่คุยกันถึงวิธีที่ทีมกฎหมายและวิศวกรรมสามารถทำงานร่วมกันได้

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

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

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

“สิ่งสำคัญอันดับแรกของฉันคือการช่วยให้ R&D เข้าใจว่าฉันไม่ได้มาเพื่อทำลายความก้าวหน้าอันน่าทึ่งที่เรากำลังดำเนินการอยู่”

Jamie Osler: ฉันเดาว่ามันใช้ได้ทั้งสองทางใช่ไหม หาก R&D มีความเข้าใจที่ดีขึ้นเกี่ยวกับประเภทของภาพรวมทางกฎหมายระดับสูงว่าประเด็นที่น่ากังวลอยู่ที่ใด จะช่วยให้พวกเขาหลีกเลี่ยงการทำสิ่งต่าง ๆ หรือสร้างผลิตภัณฑ์ที่อาจมีความเสี่ยงหรือละเมิดกฎหมายเหล่านั้นโดยไม่ได้ตั้งใจ

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

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

Liam Geraghty: ขอบคุณ Jamie Osler ผู้สร้าง Engineer Chats โฮสต์ใหม่ Brian Scanlan และแขกทุกคนที่กรุณาให้เราใส่การแชทภายในของพวกเขาภายนอก หากคุณชอบการแสดงของวันนี้ ทำไมไม่เขียนรีวิวให้เราหรือบอกพวกเราบนโซเชียล เราชอบที่จะเห็นและได้ยินสิ่งที่คุณคิด นั่นคือทั้งหมดสำหรับวันนี้ เราจะกลับมาในสัปดาห์หน้าพร้อมตอนอื่นของ Inside Intercom