ขอบเขตงานพัฒนาแอป เขียนมาห้าบรรทัดก็พอ

แต่ละเจ้าคำนวณคนละแอป

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

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

เริ่มจากนับหน้าจอ

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

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

ลงสโตร์ไหน และเริ่มเมื่อไร

จะลงทั้ง iOS และ Android วิธีทำก็แยกทางกันตั้งแต่ต้น เขียนเนทีฟแยกสองฝั่งเท่ากับทำแอปเดียวกันสองรอบ ปริมาณงานพุ่งขึ้นทันที เฟรมเวิร์กครอสแพลตฟอร์มใช้โค้ดชุดเดียวครอบทั้งสองสโตร์ แต่ฟีเจอร์ที่ลงลึกถึงตัวเครื่องอย่างกล้องหรือการแจ้งเตือน ยังต้องเก็บงานแยกตามแพลตฟอร์มอยู่ดี WebView คือการเอาเว็บไซต์ใส่เปลือกแอป เบาที่สุดในสามแบบ แต่แอปที่เป็นเว็บห่อเปลือกเฉย ๆ อาจไม่ผ่านการรีวิวของ App Store ต่อให้บริการเน้นคอนเทนต์ ก็ควรคิดเผื่อว่าจะใส่ฟีเจอร์ที่ทำได้เฉพาะในแอปสักอย่าง

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

ของที่พ่วงมากับล็อกอิน การชำระเงิน และพุช

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

ตอนที่ข้อมูลออกนอกเครื่อง

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

หน้าจอที่ผู้ใช้ไม่มีวันเห็น

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

ห้าบรรทัดยังไม่ครบก็คุยได้

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