จ้างเขียนปลั๊กอิน WordPress ต้องเตรียมโจทย์อะไรบ้าง?

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

ทำไมงานเพิ่มความสามารถถึงควรทำเป็นปลั๊กอิน

คู่มือนักพัฒนาของ WordPress วางกฎพื้นฐานไว้ว่า อย่าไปแก้ไฟล์แกนของ WordPress เพราะเมื่อมีการอัปเดตเวอร์ชัน ไฟล์แกนจะถูกเขียนทับ สิ่งที่แก้ไว้ก็หายไปด้วย ความสามารถที่อยากเพิ่มจึงควรทำผ่านปลั๊กอิน ซึ่งจะเล็กแค่ไฟล์ PHP ไฟล์เดียว หรือใหญ่เป็นระบบก็ได้ ขึ้นอยู่กับโจทย์ อ่านภาพรวมอย่างเป็นทางการได้ที่ Introduction to Plugin Development

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

ห้าเรื่องที่ควรเตรียมก่อนคุยกับผู้พัฒนา

1. ข้อมูลรับเข้า

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

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

2. ขั้นตอนการทำงาน

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

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

3. ผู้ใช้และสิทธิ์

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

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

4. ผลลัพธ์ที่ต้องได้

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

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

5. เกณฑ์ตรวจรับ

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

ตัวอย่างการเขียนเกณฑ์:

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

ตัวอย่างสมมติ: ระบบรับคำขอใบเสนอราคา

ตัวอย่างต่อไปนี้เป็นตัวอย่างสมมติเพื่อประกอบความเข้าใจ ไม่ใช่งานจริงของลูกค้ารายใด

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

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

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

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

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

เกณฑ์ตรวจรับ: ทดลองส่งคำขอ 5 รายการที่มีเงื่อนไขต่างกัน แล้วผลลัพธ์ตรงกับที่ระบุไว้ทุกข้อ

เรื่องข้อมูลระหว่างคุยงาน

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

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

ข้อควรตัดสินใจก่อนเริ่มงาน

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

คำถามที่พบบ่อย

เขียนโจทย์เองไม่เป็น ต้องทำอย่างไร

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

จำเป็นต้องรู้ว่าอยากได้หน้าตาแบบไหนตั้งแต่แรกหรือไม่

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

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