ก่อนจะเริ่มเขียนโค้ด: 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["เชื่อมฮาร์ดแวร์เฉพาะจุดที่เพิ่มคุณค่า"]

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

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

---

แล้วเมื่อไหร่ควรเริ่มคุยกับเรา?

ถ้าคุณกำลังคิดว่า

• “รู้ว่ามีปัญหา แต่ยังอธิบายไม่ชัด”
• “มีคนเสนอระบบมาแล้ว แต่รู้สึกว่าหนักและซับซ้อนเกินไป”
• “อยากเชื่อมซอฟต์แวร์กับฮาร์ดแวร์ แต่กลัวระบบเปราะในระยะยาว”

นั่นมักเป็นจังหวะที่เหมาะสมที่สุดในการเริ่มคุย

คุณยังไม่ต้องมี requirement
ยังไม่ต้องมี TOR
บางครั้ง แค่เริ่มจากคำถามที่ถูก ก็เพียงพอแล้ว