ความท้าทาย 5 อันดับแรกในกระบวนการพัฒนาผลิตภัณฑ์โครงสร้างพื้นฐานอีเมล

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

เมื่อทราบแล้ว Radicati Group Inc. ประมาณการว่าจำนวนอีเมลที่ส่งทั้งหมดจะเข้าใกล้ 400 พันล้านในปี 2570 และคาดว่าจำนวนผู้ใช้ทั่วโลกจะสูงถึง 5 พันล้านในปีเดียวกัน

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

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

1: ความสามารถในการปรับขนาด

ความท้าทาย

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

การระดมสมองมาตรการควบคู่ไปกับการพัฒนาแนวคิดเป็นสิ่งที่ดี หากไม่เป็นเช่นนั้น นักพัฒนาจำเป็นต้องดำเนินการด้วยการเปิดตัว MVP มิฉะนั้นพวกเขาอาจเสี่ยงต่อสิ่งต่อไปนี้:

• สูญเสียผลผลิต
• ความพึงพอใจของลูกค้าลดลง
• การสูญเสียทางการเงินที่อาจเกิดขึ้น
• ลดระดับการให้คะแนนโดเมน
• ชื่อเสียงของผู้ส่งลดลง

โซลูชั่น:

• โครงสร้างพื้นฐานบนคลาวด์
• โหลดบาลานซ์

การใช้โครงสร้างพื้นฐานบนคลาวด์

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

ฟังดูดี แต่มันใช้งานจริงได้อย่างไร?

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

1. วิธีการนี้ช่วยลดต้นทุนการดำเนินงานได้อย่างมาก
2. นอกจากนี้ยังมอบโซลูชันที่ปรับขนาดได้เพื่อตอบสนองความต้องการที่เพิ่มขึ้นขององค์กร

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

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

การดำเนินการโหลดบาลานซ์

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

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

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

ยังดีกว่า สามารถใช้อัลกอริทึมการจัดสรรภาระงานเพื่อปรับการกระจายของปริมาณงานแบบไดนามิก โดยทั่วไปจะขึ้นอยู่กับปัจจัยสองประการ:

1. จำนวนคำขอ
2. พลังการประมวลผลของแต่ละเซิร์ฟเวอร์

สร้างแพลตฟอร์มที่พักแห่งหนึ่ง

ย้อนกลับไปในปี 2012 กระบวนการพัฒนาผลิตภัณฑ์ของ Airbnb อยู่ในขั้นตอนสำคัญ

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

Airbnb กำลังเผชิญกับทางเลือกที่เสี่ยง – จ้างพนักงานมากกว่า 1,000 คนภายในหนึ่งปีหรือสร้างกรอบงานอัตโนมัติเพื่อจัดการกับกรณีขอบ

ใช่ พวกเขาเลือกอย่างหลัง

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

ด้วยกรอบการทำงาน Airbnb ได้รับการปลดบล็อกอย่างรวดเร็วและปรับขนาดอย่างต่อเนื่องที่ 300% ถึง 600% ต่อปี โปรดทราบว่าเปอร์เซ็นต์เหล่านี้อ้างอิงถึงการเติบโตอย่างรวดเร็วแบบก้าวกระโดดของ Airbnb

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

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

2: ความปลอดภัย

ความท้าทาย

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

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

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

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

โซลูชั่น:

• การเข้ารหัส
• โปรโตคอลที่ปลอดภัย
• อัปเดตมาตรการรักษาความปลอดภัยเป็นประจำ

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

ยังไง?

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

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

ก่อนหน้านี้เราได้กล่าวถึง SSL และ TLS ซึ่งเข้ารหัสข้อมูลที่เคลื่อนไหว แต่บริษัทต่างๆ ยังต้องพิจารณาถึงการเข้ารหัสข้อมูลที่ไม่ได้ใช้งาน และสร้างระดับการเข้าถึงที่แตกต่างกันสำหรับข้อมูลนั้น

“พิ้งกี้สัญญา เราจะไม่แฮกคุณ!”

กรณีนี้ค่อนข้างเป็นกรณีธุรกิจเชิงลบ แต่แสดงให้เห็นอย่างชัดเจนว่าการรักษาความปลอดภัยมีสองด้านเสมอ นั่นคือซอฟต์แวร์และบุคลากร

ในเดือนมกราคม 2023 Mailchimp ประสบปัญหาการละเมิดความปลอดภัย (ครั้งที่สามภายใน 12 เดือน) ซึ่งเปิดเผยข้อมูลที่ละเอียดอ่อนของลูกค้า 133 ราย และวิศวกรรมสังคมเป็นกลยุทธ์ที่นักต้มตุ๋นใช้เพื่อเข้าถึงข้อมูลที่ละเอียดอ่อน

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

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

3: ความน่าเชื่อถือ

ความท้าทาย

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

ทำไม

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

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

การแก้ไขปัญหา:

• การนำระบบสำรองและระบบสำรองมาใช้
• การตรวจสอบโครงสร้างพื้นฐานเป็นประจำ

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

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

พูดถึงการมอนิเตอร์ จะเป็นการดีที่สุดหากนักพัฒนาสร้างการเตือนที่เหนือกว่าการมอนิเตอร์ ตัวอย่างเช่น ควรตั้งค่าการเตือนสำหรับสถานการณ์ต่อไปนี้:

1. หากกระบวนการเริ่มใช้หน่วยความจำมากขึ้น
2. หากมีปัญหาเฉพาะในการประมวลผล/คอมพิวเตอร์
3. ในกรณีที่มีการตอบกลับ 500 รหัส

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

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

พวกยักษ์ทำได้อย่างไร

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

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

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

4: การทำงานร่วมกัน

ความท้าทาย

ความสามารถในการทำงานร่วมกันบ่งบอกถึงความสามารถของโครงสร้างพื้นฐานอีเมลหรือบริการ SaaS ใดๆ ในการผสานรวมและทำงานได้ดีกับแอปพลิเคชันอื่นๆ

โดยทั่วไปแล้ว การผสานรวมควรรวมถึง:

1. การบริหารลูกค้าสัมพันธ์ (CRM)
2. การวางแผนทรัพยากรองค์กร (ERP)
3. การจัดเก็บข้อมูล

มีประโยชน์อย่างไร?

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

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

การแก้ไขปัญหา:

• เปิดมาตรฐาน
• ความเข้ากันได้ข้ามแพลตฟอร์ม

มาตรฐานเปิดเป็นข้อกำหนดที่เปิดเผยต่อสาธารณะซึ่งอนุญาตให้ระบบต่างๆ ทำงานร่วมกันได้

มาตรฐานเปิดที่สำคัญพร้อมโครงสร้างพื้นฐานของอีเมล ได้แก่ Simple Mail Transfer Protocol (SMTP), Post Office Protocol รุ่น 3 (POP3) และ Internet Message Access Protocol (IMAP)

สำหรับความเข้ากันได้ โครงสร้างพื้นฐานของอีเมลต้องได้รับการออกแบบให้ทำงานร่วมกับระบบปฏิบัติการที่แตกต่างกัน (Windows, macOS และ Linux) รวมถึงเว็บเบราว์เซอร์ที่แตกต่างกัน (Google Chrome, Mozilla Firefox, Safari เป็นต้น)

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

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

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

ลดหย่อนให้เราบ้าง

หากคุณเชื่อว่า Slack สามารถสร้างสรรค์วิธีการทำงานร่วมกันของเราขึ้นมาใหม่ได้ คุณก็ไม่ผิด แต่คำถามคือพวกเขาทำได้อย่างไร

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

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

ขึ้นอยู่กับขนาดและขอบเขตของธุรกิจของคุณ คุณสามารถเชื่อมต่อ Jira, Notion, Coda, Google Apps และอื่นๆ เพื่อให้มีการแจ้งเตือนและช่องข้อมูลทั้งหมดภายใต้หลังคาเดียวกัน ทั้งหมดนั้นภายในเวลาไม่กี่วันหรือหลายชั่วโมง

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

5: การจัดการความคาดหวังด้านประสิทธิภาพ

ความท้าทาย

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

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

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

• ง่ายต่อการใช้
• เข้าถึงได้จากหลายอุปกรณ์
• สามารถจัดการทราฟฟิกอีเมลตามขนาด

การแก้ไขปัญหา:

• การทดสอบ
• การเพิ่มประสิทธิภาพ
• การสื่อสารที่ชัดเจน
• ข้อเสนอแนะลูป

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

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

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

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

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

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

การต่อสู้ของยักษ์

ดังที่ได้กล่าวไว้ก่อนหน้านี้ ส่วนนี้จะสำรวจพื้นที่ที่ Microsoft อาจล้มเหลวในด้านประสิทธิภาพที่คาดหวัง ซึ่งเปิดโอกาสให้คู่แข่งเติบโตได้ มีเรื่องราวเล็กน้อยที่เกี่ยวข้องกับทั้ง Apple และ Google

เมื่อถึงเวลาที่เปิดตัว MPP (Mail Privacy Protection) ในเดือนกันยายน 2021 Apple ก็ได้เอาชนะ Google ไปแล้วสำหรับส่วนแบ่งการตลาดไคลเอนต์อีเมล ในขณะนั้น ส่วนแบ่งของ Apple อยู่ที่ 59% ส่วน Google อยู่ที่ประมาณ 28% แต่ Outlook ของ Microsoft ตามหลังอยู่ประมาณ 5%

ตอนนี้อะไรคือสาเหตุที่ Microsoft พ่ายแพ้ต่อหมัด?

เพื่อหาคำตอบ เราควรมองย้อนกลับไปในอดีตอีกสักหน่อย

Google เปิดตัว Gmail เมื่อวันที่ 1 เมษายน เมื่อเกือบสองทศวรรษที่แล้ว และใช้เวลาไม่นาน Microsoft ก็ตระหนักว่านั่นไม่ใช่เรื่องตลกของวันเอพริลฟูล บิดาแห่งวินโดวส์ผลักดันอย่างหนักเพื่อให้ครองอำนาจเป็นเวลาประมาณสิบปี แต่เมื่อ Gmail เข้าครอบครองตลาดในปี 2558 Outlook ก็เป็นขาลงเป็นส่วนใหญ่

แต่ทำไม?

ปลอดภัยที่จะโต้แย้งเหตุผลที่ไม่คาดหวังประสิทธิภาพการทำงาน โดยพื้นฐานแล้ว Gmail นั้นเร็วกว่าและใช้งานง่ายกว่า และมีอินเทอร์เฟซที่คล่องตัวกว่ามาก เมื่อรวมกับคุณสมบัติที่มากขึ้นและพื้นที่เก็บข้อมูลที่มากขึ้น (มากกว่า Outlook ถึง 1GB – 500 เท่าในขณะนั้น) จึงไม่น่าแปลกใจที่ Gmail จะได้รับรางวัล

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

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

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

สร้างผลิตภัณฑ์ที่ดี

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

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

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