มีอะไรบ้างที่ควรพิจารณาเมื่อสร้างแอปสำหรับธุรกิจ/องค์กร?

คำถามจาก HN และคำตอบที่ได้รับคำแนะนำจำนวนมาก

คำตอบ 1

• ผู้ซื้อคือใคร? โดยทั่วไปมักต่างจากผู้ใช้ผลิตภัณฑ์ และต้องทำความเข้าใจว่าพวกเขาต้องการอะไร
• รองรับ SSO, SAML
• ด้านความปลอดภัยควรครอบคลุม OWASP top-10 และ app-sec (ความปลอดภัยของแอป)
• ทำ RBAC ให้ดี ผู้ดูแลระบบควรเพิ่ม/จัดการผู้ใช้ได้ง่าย
• ทำบัญชีเดโมแบบแซนด์บ็อกซ์และเติมข้อมูลที่ใกล้เคียงกับข้อมูลจริง ทำให้ใช้ง่ายมากตอนพรีเซนต์ขาย ให้ตัวผลิตภัณฑ์พูดแทนคุณ
• คิดเรื่อง multi-tenancy ตั้งแต่แรก เพราะจะมาเพิ่มทีหลังได้ยาก
• สร้างตามข้อกำหนดด้าน compliance เฉพาะโดเมนตั้งแต่แรก เรื่องอย่าง SOC 2 ไม่ได้ยากเกินไป ระหว่างนั้นให้หาผู้ให้บริการด้านความปลอดภัยที่ดีเพื่อทดสอบ แก้ปัญหาที่มีลำดับความสำคัญสูงหรือกลาง และขอใบรับรอง สิ่งนี้ช่วยสร้างความเชื่อมั่นกับลูกค้า
• รายงาน โดยปกติผู้ดูแลระบบต้องการรายงานหลากหลายแบบ ควรให้ดาวน์โหลดเป็น CSV/Excel และทำให้สามารถนำไปใช้ต่อในซอฟต์แวร์สเปรดชีตของพวกเขาได้ง่าย
• ผู้ใช้อาจทำผิดพลาดได้ ดังนั้นควรใช้ soft-delete เสมอ และค่อย hard-delete ได้หลังจากผ่านไปหลายเดือน

คำตอบ 2

• ในฐานะวิศวกรคนแรกของบริษัท ฉันได้สร้างแอปองค์กรที่ประสบความสำเร็จ 2 ตัว (ตัวหนึ่งขายไปแล้ว อีกตัวหนึ่งตอนนี้มีมูลค่าเกิน 100M)
• สิ่งเดียวที่ต้องกังวลคือ "ลูกค้าต้องการและจำเป็นต้องใช้แอปของคุณจริงหรือไม่" ผลิตภัณฑ์ Enterprise SaaS 99% ล้มเหลวเพราะเรื่องนี้ ไม่ใช่เพราะขาดฟีเจอร์
• ฟีเจอร์องค์กรอย่าง SSO, Integration, Audit Trail สามารถสร้างได้เมื่อลูกค้าร้องขอ
  สิ่งเหล่านี้ส่วนใหญ่เป็นปัญหาที่มีคำตอบอยู่แล้ว แต่เพราะคุณเป็นวิศวกรจึงอาจมองว่ามันเป็นปัญหาที่น่าดึงดูด
• มองข้ามเรื่องเหล่านี้ไปก่อน แล้วโฟกัสเฉพาะปัญหาทางธุรกิจว่า "แอปของฉันแก้ pain point ที่เร่งด่วนของลูกค้าได้หรือไม่"
  ถ้าจะมี mindset ที่ตอบคำถามนี้ได้ ให้ไปอ่าน "The Mom Test" นี่คือสิ่งสำคัญที่สุดในตอนนี้

คำตอบ 3

• ถ้าเป็นฉัน ฉันจะเก็บเรื่องเทคนิคของผลิตภัณฑ์ B2B/องค์กรไว้คิดทีหลัง
• ปัญหาหลักคือการหา sales process/GTM (Go To Market) strategy ให้เจอ อย่างที่คนอื่นพูดไว้ การจับมือกับคนที่รู้จักปัญหา/อุตสาหกรรมและเคยขายให้บริษัทมาก่อนจะช่วยได้ จำไว้ว่านี่จะกลายเป็น core competency ของบริษัท (ถ้าคุณอยากทำเงินเยอะ) ในฐานะผู้นำด้านเทคนิค งานจะใกล้เคียงกับการให้คำปรึกษามากกว่าการแค่สร้างและส่งมอบผลิตภัณฑ์
• ถ้าทำคนเดียว ให้คุยกับคนจำนวนมากที่เกี่ยวข้องกับ business process และดูว่าทำไมตอนนี้พวกเขาถึงแก้ปัญหาที่คุณพยายามจะแก้ด้วยวิธีแบบนั้น บ่อยครั้งเราในฐานะนักพัฒนามองปัญหาเป็นปัญหาทางเทคนิค แต่จริง ๆ แล้วมันอาจเป็นปัญหาด้านองค์กร/การเมือง/สังคม อย่าเพิ่งสร้างเยอะในช่วงแรก ให้ทำ visual prototype ที่เอาไว้เดโมและพรีเซนต์ได้ก่อน แล้วเปิดให้ผู้ใช้ทดลองเอง

คำตอบ 4

• หลายอย่างจะแตกต่างกันมากตามประเภทธุรกิจที่คุณมุ่งไป ถ้าเล็งหน่วยงานรัฐหรือองค์กรการเงิน ข้อกำหนดจะมากกว่าบริษัทซอฟต์แวร์ทั่วไปมาก
• สำหรับองค์กรขนาดใหญ่ รอบการขายอาจยาวมาก แต่ชดเชยด้วยขนาดดีลที่ใหญ่มากเช่นกัน
• คำแนะนำที่ดีที่สุดจากฉันซึ่งขายให้ลูกค้าองค์กรมาเป็นเวลาหลายปีคือ "จงเข้าใจลูกค้าเป้าหมาย" ไม่ใช่แค่ตัวบริษัท แต่รวมถึงคนจริง ๆ ที่คุณจะขายซอฟต์แวร์ให้ ก่อนเริ่มสร้าง ให้คุยกับลูกค้าเป้าหมายเพื่อยืนยันว่าพวกเขาต้องการอะไรกันแน่ (และตรวจสอบด้วยว่าตรงกับที่คุณคิดหรือไม่) รวมถึงดูว่ามีอุปสรรคอะไรบ้างในการซื้อซอฟต์แวร์ของคุณ ถ้ารู้ข้อกำหนดล่วงหน้า คุณจะไม่ต้องเจอเรื่องไม่คาดคิดระหว่างกระบวนการขาย
• หนังสือที่ฉันแนะนำคือ The Mom Test คุณจะได้เรียนรู้วิธีตั้งคำถามที่ถูกต้องเพื่อรับ feedback จากลูกค้าเป้าหมาย

คำตอบ 5

• สร้างแอปให้เปิด API และให้เว็บไคลเอนต์เรนเดอร์ผ่าน API นั้น ในตลาดองค์กรไม่จำเป็นต้องทำ server-side rendering เพื่อ SEO
• บ่อยครั้งหลังจากที่คนในองค์กรใช้แอปของคุณแล้ว พวกเขาจะอยากทำ automation เองหรือรวมแอปเข้ากับระบบอื่น ถ้ามี API คุณก็ไม่ต้องทำงานเพิ่ม สิ่งใดก็ตามที่พวกเขาทำในแอปได้ ก็สามารถทำให้เป็นอัตโนมัติได้
• ถ้ามีฐานข้อมูลเกี่ยวข้อง การมี read-only replica ที่ผู้ใช้ของคุณสามารถอ่านได้จะช่วยให้ตอบทุกคำถามทางธุรกิจได้อย่างรวดเร็ว นักธุรกิจ คนทำรายงาน และวิศวกรจำนวนมากเชี่ยวชาญ SQL มาก

คำตอบ 6

• สิ่งสำคัญที่สุดคือ "หาปัญหาที่องค์กรยินดีจ่ายเงินเพื่อแก้" ตั้ง MVP แบบง่าย ๆ ขึ้นมา แล้วค่อยเติบโตจากจุดนั้น

คำตอบ 7

• ออกแบบและสร้างเพื่อรองรับ multi-tenancy ตั้งแต่ระดับสคีมา
• แยก ID ออกจากกลไกการล็อกอิน วางแผนรองรับกลไกการล็อกอินหลายแบบต่อผู้ใช้ (อีเมล/รหัสผ่าน, SAML, OpenID Connect, Google) และพิจารณา multi-factor authentication ด้วย (TOTP, Duo, ..) ระวังเรื่องวิธีแยกแยะผู้ใช้ที่ยืนยันตัวตนแล้ว และวิธีตรวจสอบที่อยู่อีเมล
• ใช้ TLS กับการเชื่อมต่อฐานข้อมูลด้วย ควรใช้การเข้ารหัส ทำ backup แบบอัตโนมัติ และทำให้สามารถกู้คืน/ส่งออกข้อมูลรายลูกค้าได้ ไม่ใช่ทั้งแอปพลิเคชัน
• ใช้ฐานข้อมูล time-series หรือระบบ event logging และสร้าง Audit Trail สำหรับทุกการกระทำที่ผู้ใช้ซึ่งมีสิทธิ์ทำในระบบ การเปลี่ยนแปลงบัญชีหรือสิทธิ์ และการกระทำที่มีผลทำลายล้าง

[bus710]

ฟังดูมีมุมมองเชิงลึกนะ

[wicksome]

https://tkim.co/2020/02/12/the-mom-test/

[xguru]

เคล็ดลับของบริษัท SaaS: ทำไมมัลติเทนเนนซีจึงสำคัญ