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