ก่อนจะเริ่มเขียนโค้ด: 5 คำถามที่เราถามลูกค้าทุกครั้ง

หลายโปรเจกต์เริ่มต้นด้วยคำตอบทันที

“อยากได้ระบบ”
“อยากได้แดชบอร์ด”
“อยากให้ซอฟต์แวร์เชื่อมกับเครื่องจักรได้”

ที่ Simplico เรามักจะชะลอจุดนี้ไว้ก่อนเล็กน้อย

ไม่ใช่เพราะเราไม่อยากพัฒนาระบบ — ตรงกันข้าม เราทำสิ่งนี้เป็นงานหลัก
แต่เพราะประสบการณ์สอนเราว่า

การเริ่มเขียนโค้ดเร็วเกินไป คือหนึ่งในความผิดพลาดที่แพงที่สุดของการพัฒนาระบบ

ก่อนจะพูดถึงสถาปัตยกรรม ระบบฐานข้อมูล หรือการเชื่อมต่อฮาร์ดแวร์
เราจะเริ่มจาก 5 คำถามพื้นฐาน เสมอ

คำถามเหล่านี้ไม่ใช่คำถามเชิงเทคนิค
แต่เป็นคำถามเพื่อ ทำให้เรื่องชัด

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

คำถามที่ 1: ระบบนี้ควรช่วยให้ “การตัดสินใจหรือการลงมือทำ” ง่ายขึ้นอย่างไร?

ลูกค้าส่วนใหญ่มักพูดถึง ฟีเจอร์
แต่เราจะโฟกัสที่ การตัดสินใจ

แดชบอร์ดไม่ใช่เป้าหมาย
API ไม่ใช่เป้าหมาย
แม้แต่ Automation ก็ไม่ใช่เป้าหมาย

คำถามที่สำคัญจริง ๆ คือ

ตอนนี้มีการตัดสินใจอะไรที่ช้า เสี่ยง หรือไม่ชัด?
ใครเป็นคนตัดสินใจเรื่องนั้น?
ถ้าตัดสินใจช้าหรือผิด จะเกิดผลกระทบอะไร?

ระบบที่ดีจะทำให้การตัดสินใจง่ายขึ้น
ระบบที่ไม่ดี จะเพิ่มหน้าจอ แต่เพิ่มความสับสนไปพร้อมกัน

คำถามที่ 2: ถ้าไม่มีซอฟต์แวร์เลย ปัญหานี้ยังอยู่ไหม?

คำถามนี้มักทำให้บรรยากาศเงียบไปครู่หนึ่ง — และนั่นเป็นสัญญาณที่ดี

ถ้าวันหนึ่งไม่มีระบบ ไม่มีโปรแกรมเลย

ปัญหานี้ยังอยู่ไหม?
เป็นปัญหากระบวนการ การสื่อสาร หรือความรับผิดชอบหรือเปล่า?

เหตุผลที่เราถาม เพราะ ซอฟต์แวร์จะขยายสิ่งที่มีอยู่แล้ว

กระบวนการที่ชัด → เร็วขึ้น
กระบวนการที่พัง → พังเร็วขึ้นหลายเท่า

การเข้าใจปัญหาโดยไม่พึ่งซอฟต์แวร์
ช่วยให้เราสร้างระบบที่ ทำให้งานนิ่งขึ้น ไม่ใช่ปวดหัวมากขึ้น

คำถามที่ 3: ข้อมูลเริ่มจากตรงไหน และจบที่ตรงไหน?

ในงาน System Integration โดยเฉพาะที่เกี่ยวข้องกับ

โรงงาน
เครื่องจักร
หลายแผนก
หลายบริษัท

ปัญหาส่วนใหญ่มักไม่ได้มาจากโค้ด
แต่มาจาก ขอบเขตที่ไม่ชัด

เราจะช่วยกันไล่ดูว่า

ข้อมูลถูกสร้างจากใคร (คน / เครื่องจักร / ระบบอื่น)
ระหว่างทางมีการเปลี่ยนแปลงอะไรบ้าง
จุดไหนคือการตัดสินใจ จุดไหนคือรายงาน

สิ่งนี้ช่วยให้ตัดสินใจได้ว่า

อะไรควรทำอัตโนมัติ
อะไรควรให้คนทำ
ตรงไหนควร (หรือไม่ควร) เชื่อมฮาร์ดแวร์เข้ามา

ระบบที่ดีเคารพขอบเขต
ระบบที่แย่จะพยายามรวมทุกอย่างเข้าด้วยกัน

คำถามที่ 4: ในอีก 2–3 ปี อะไร “ต้องเปลี่ยน” แน่นอน?

ระบบส่วนใหญ่ไม่ได้พังตั้งแต่วันแรก
แต่มักพัง เงียบ ๆ ตอนธุรกิจเปลี่ยน

เราจะคุยกันตรงไปตรงมาว่า

ส่วนไหนของธุรกิจค่อนข้างนิ่ง
ส่วนไหนมีโอกาสเปลี่ยน (ปริมาณงาน กฎหมาย คู่ค้า เครื่องจักร ตลาด)

สิ่งนี้ส่งผลโดยตรงต่อการออกแบบ

ตรงไหนไม่ควร hard-code
ตรงไหนควรทำเป็น configuration
จะออกแบบอย่างไรให้เปลี่ยนเครื่องจักรได้โดยไม่ต้องรื้อระบบ

ความยืดหยุ่นไม่ใช่การเตรียมทุกอย่าง
แต่คือการเลือกให้ถูกว่า ตรงไหนต้องยืดหยุ่น

คำถามที่ 5: เราจะรู้ได้อย่างไรว่าระบบนี้ “ใช้ได้จริง”?

ไม่ใช่ในเอกสาร
ไม่ใช่ใน KPI สวย ๆ

แต่ในชีวิตจริง

อะไรที่รู้สึกง่ายขึ้น?
อะไรที่ไม่ต้องคอยอธิบายซ้ำ?
ปัญหาอะไรที่หายไปจากการทำงานประจำวัน?

ถ้าความสำเร็จอธิบายไม่ได้ง่าย ๆ
มักแปลว่าระบบนั้นซับซ้อนเกินจำเป็น

แผนภาพการตัดสินใจที่เราใช้ในการคุยกับลูกค้า

คำถามทั้ง 5 ข้อนี้ไม่ได้มีไว้คุยเฉย ๆ
แต่ช่วยนำไปสู่การตัดสินใจว่า ควรทำอะไร / ไม่ควรทำอะไร / ควรรออะไรไว้ก่อน

flowchart TD
  A["ปัญหาหรือเป้าหมายทางธุรกิจ"] --> B{"เป็นปัญหาการตัดสินใจหรือไม่?"}

  B -- "ใช่" --> C["ใครเป็นผู้ตัดสินใจ?"]
  B -- "ไม่ใช่" --> D["แก้กระบวนการ / ความรับผิดชอบก่อน"]

  C --> E["ขาดข้อมูลอะไร?"]
  E --> F{"แก้ได้โดยไม่ใช้ซอฟต์แวร์หรือไม่?"}

  F -- "ได้" --> G["ปรับกระบวนการ / นโยบาย"]
  F -- "ไม่ได้" --> H["ออกแบบขอบเขตของระบบ"]

  H --> I["ออกแบบระบบโดยเน้นซอฟต์แวร์ก่อน"]
  I --> J["เชื่อมฮาร์ดแวร์เฉพาะจุดที่เพิ่มคุณค่า"]

แผนภาพนี้ช่วยให้ทุกฝ่ายเข้าใจตรงกันตั้งแต่ต้นว่า