- จ้างทำแอปมีเจ็ดขั้น งานตัดสินใจของคุณหนักที่สุดในสามขั้นแรก ก่อนจะมีโค้ดบรรทัดแรก
- ระหว่างสร้าง ขอดูแอปจริงบนมือถือทุกสัปดาห์ และตรวจรับด้วยเครื่องกับงานจริงของคุณเอง
- สมัครบัญชี Store ในชื่อบริษัทตั้งแต่ต้น และรับโค้ด เอกสาร กับรหัสผ่านให้ครบก่อนจ่ายงวดสุดท้าย
- ถ้าตอบไม่ได้ว่าขั้นนี้ตัดสินใจอะไรไปแล้ว อย่าเพิ่งอนุมัติขั้นถัดไป
ขั้นตอนการพัฒนาแอปพลิเคชัน มองจากฝั่งคนจ้าง
การจ้างทำแอปคล้ายการต่อเติมร้าน ช่างเป็นคนก่ออิฐ ส่วนคุณบอกว่าใครใช้พื้นที่ไหน อนุมัติแบบก่อนลงเสาเข็ม และแวะดูหน้างานทุกสัปดาห์ แต่ละขั้นข้างล่างบอกว่าคุณตัดสินใจอะไร เตรียมอะไร ควรได้เห็นอะไร และโครงการมักพังตรงไหน ผู้พัฒนาบางรายเรียกชื่อขั้นต่างไป งานข้างในเหมือนกัน
ขั้นที่ 1 นิยามปัญหาและผู้ใช้
ขั้นแรกยังไม่มีหน้าจอ มีแต่คำถามว่าแอปแก้ปัญหาอะไร ของใคร และรู้ได้อย่างไรว่าแก้ได้แล้ว คำตอบเป็นของคุณ ผู้พัฒนาช่วยถามให้คมขึ้น
คุณเลือกปัญหาหนึ่งเรื่อง ผู้ใช้หลักหนึ่งกลุ่ม และตัวเลขที่จะวัด เช่น สัดส่วนการจองผ่านแอปหลังสามเดือน แล้วเตรียมคนจริงสามถึงห้าคนให้ผู้พัฒนาคุยด้วย ผู้พัฒนาที่ดีกลับมาพร้อมสรุปหนึ่งหน้าว่างานของแต่ละคนผ่านแอปอย่างไร ถ้าได้รายการฟีเจอร์ยาวสองหน้ามาแทน ให้ระวัง โครงการที่เริ่มจากฟีเจอร์มักมีขอบเขตบวม ถ้ายังไม่แน่ใจว่ามีคนอยากได้จริง ลองวิธีใน จากไอเดียสู่สินค้าทดลองภายใน 7 วัน ก่อน
ขั้นที่ 2 กำหนดขอบเขตและใบเสนอราคา
ขอบเขต คือรายการว่าเวอร์ชันแรกทำอะไรและไม่ทำอะไร สิ่งที่ไม่ได้เขียนไว้จะกลายเป็นเรื่องถกเถียงกลางทาง
คุณเลือกฟีเจอร์ชุดเล็กที่สุดที่ยังแก้ปัญหาได้ หรือ MVP เลือกว่าจะทำ iOS กับ Android หรือระบบเดียวก่อน ระบุระบบที่ต้องเชื่อม เช่น LINE Login หรือการรับเงินผ่าน PromptPay และชื่อคนเดียวที่อนุมัติขอบเขตได้ ใบเสนอราคาที่ดีแนบขอบเขต ราคาคงที่ก่อนเริ่มงาน กำหนดส่งเป็นวันที่ บอกว่าขอเพิ่มกลางทางแล้วเกิดอะไร และระบุว่า Source Code เป็นของใคร จุดที่มักพังคือราคาถูกเพราะตีความขอบเขตแคบกว่าที่คุณคิด ของที่ควรเตรียมก่อนคุยอยู่ใน ก่อนจ้างบริษัทพัฒนา AI ต้องเตรียมอะไรบ้าง
ขั้นที่ 3 Prototype ที่กดได้จริง
Prototype คือหน้าจอทุกหน้าที่กดไปมาได้บนมือถือ ข้างหลังยังไม่มีระบบจริง ย้ายปุ่มตอนนี้ใช้เวลาเป็นชั่วโมง ย้ายในขั้นที่ 5 ใช้เวลาเป็นวัน
คุณอนุมัติ Prototype เป็นแบบที่จะสร้างจริง หลังให้พนักงานหน้างานสองสามคนลองทำงานจริงหนึ่งรอบ เช่น สมัครสมาชิกแล้วสั่งซื้อครั้งแรกให้จบ ผู้พัฒนาที่ดียื่นมือถือให้คุณกดเอง และจดทุกจุดที่คุณชะงัก จุดที่มักพังคืออนุมัติเพราะสวย แล้วมาพบตอนทดสอบว่าลำดับหน้าจอไม่ตรงกับงานจริง ระยะห่างระหว่างของที่กดได้กับระบบที่ลูกค้าพึ่งได้ อยู่ใน จากต้นแบบ Vibe Code สู่ระบบ Production
ขั้นที่ 4 พัฒนาเป็นสปรินต์ มีเดโมทุกสัปดาห์
ขั้นนี้ยาวที่สุด ทางกันไม่ให้ทีมหายไปสองเดือนแล้วกลับมาพร้อมของที่คุณไม่เคยเห็น คือแบ่งงานเป็นรอบสั้น ๆ ที่เรียกว่าสปรินต์ และดูของจริงทุกสัปดาห์
คุณกำหนดให้ส่วนที่เสี่ยงที่สุดมาก่อน เช่น การเชื่อมระบบสมาชิกเดิม และเมื่อมีคำขอใหม่ คุณเลือกว่าจะแลกกับอะไรในขอบเขตเดิม ของที่ต้องเตรียมคือหนึ่งชั่วโมงต่อสัปดาห์ของคนที่ตัดสินใจได้ ทุกสัปดาห์คุณควรเห็นแอปบนมือถือจริงที่ทำงานได้มากขึ้น สัญญาณอันตรายคือเดโมเลื่อนสองครั้งติด และคำขอเล็ก ๆ ที่สะสมจนกำหนดส่งเลื่อนโดยไม่มีใครเซ็น
ขั้นที่ 5 ทดสอบและตรวจรับ
ทีมพัฒนาทดสอบมาตลอดทาง ขั้นนี้คือรอบที่คุณและพนักงานลงมือเอง บนเครื่องของคุณ ด้วยงานจริงของคุณ
คุณตกลงเกณฑ์ตรวจรับก่อนเริ่มทดสอบ ว่าอะไรต้องผ่าน และข้อบกพร่องแบบไหนรอแก้หลังเปิดตัวได้ ถ้าตกลงหลังเจอปัญหาจะกลายเป็นการต่อรอง แล้วเตรียมมือถือรุ่นที่ลูกค้าใช้จริง รวมเครื่องเก่า ผู้พัฒนาที่ดีส่งผลทดสอบการทำงาน ความเร็ว และความปลอดภัยมาก่อน พร้อมช่องแจ้งปัญหาที่ตามสถานะได้ จุดที่มักพังคือทดสอบเฉพาะทางที่ราบรื่น แล้วข้ามกรณีสัญญาณหลุด จ่ายเงินซ้ำ หรือผู้ใช้เปลี่ยนเครื่อง ถ้าแอปเก็บข้อมูลลูกค้า อ่านต่อใน Cybersecurity ของแอปยุค Vibe Code
ขั้นที่ 6 ส่งขึ้น Store และเปิดตัว
แอปขึ้น App Store และ Google Play ผ่านบัญชีนักพัฒนา บัญชีนั้นควรเป็นชื่อบริษัทคุณ เพราะเป็นชื่อที่ลูกค้าเห็นใต้แอป
คุณเลือกวันเปิดตัว และจะเปิดให้ทุกคนหรือกลุ่มเล็กก่อน ของที่ต้องเตรียมควรเริ่มตั้งแต่ขั้นที่ 2 คือบัญชีนักพัฒนาแบบนิติบุคคลของทั้งสอง Store ซึ่งใช้เอกสารและเวลาหลายวัน นโยบายความเป็นส่วนตัวที่ตรงกับข้อมูลที่แอปเก็บจริงตาม PDPA และบัญชีทดลองให้ผู้ตรวจของ Store ผู้พัฒนาที่ดีมีรายการตรวจก่อนส่ง จุดที่มักพังคือรู้ตัววันส่งว่าบัญชียังไม่มี หรือผู้ตรวจล็อกอินไม่ได้ ถ้าลูกค้าของคุณอยู่ใน LINE อยู่แล้ว LINE Mini App เปิดใช้ได้โดยไม่ต้องขึ้นทั้งสอง Store
ขั้นที่ 7 ดูแลและเวอร์ชันถัดไป
วันเปิดตัวคือวันแรกที่คุณรู้ว่าสมมติฐานในขั้นที่ 1 ข้อไหนถูก งานหลังจากนี้คือดูแลให้แอปทำงานต่อ และเลือกว่าเวอร์ชันถัดไปทำอะไร
คุณตัดสินใจว่าใครในบริษัทเป็นเจ้าของแอป และจะต่อแผนดูแลรายเดือนหรือให้ทีมภายในรับไป ตอนส่งมอบ คุณควรได้ Source Code เอกสารระบบ และสิทธิ์ทุกบัญชีครบตามขอบเขต พร้อม Analytics ที่วัดตัวเลขจากขั้นที่ 1 ตั้งแต่วันแรก ระบบปฏิบัติการมือถือออกรุ่นใหม่ทุกปี แอปที่ไม่มีคนดูแลจะเริ่มพัง จุดที่มักพังคือจ่ายงวดสุดท้ายก่อนได้รหัสผ่านครบ แล้วต้องพึ่งผู้พัฒนารายเดิมทุกเรื่อง หรือ Vendor Lock-in
| ขั้น | คุณตัดสินใจ | คุณได้เห็น | มักพังตรงไหน |
|---|---|---|---|
| 1 ปัญหาและผู้ใช้ | ปัญหา ผู้ใช้ ตัวเลขที่วัด | สรุปหนึ่งหน้า | เริ่มจากรายการฟีเจอร์ |
| 2 ขอบเขตและราคา | ทำอะไร ไม่ทำอะไร เชื่อมระบบไหน | ใบเสนอราคาแนบขอบเขต | ตีความขอบเขตแคบ |
| 3 Prototype | อนุมัติแบบ | หน้าจอที่กดได้บนมือถือ | อนุมัติเพราะสวย |
| 4 สปรินต์ | ลำดับงาน การแลกคำขอใหม่ | แอปจริงทุกสัปดาห์ | เดโมเลื่อน คำขอสะสม |
| 5 ทดสอบ | เกณฑ์ตรวจรับ | ผลทดสอบ ช่องแจ้งปัญหา | ทดสอบแต่ทางราบรื่น |
| 6 ขึ้น Store | กลุ่มแรก วันเปิดตัว | รายการตรวจก่อนส่ง | บัญชีไม่พร้อมวันส่ง |
| 7 ดูแล | เจ้าของแอป แผนดูแล | โค้ด เอกสาร บัญชี ตัวเลข | จ่ายก่อนได้ของครบ |
กรณีจำลอง
โรงพยาบาลสัตว์สี่สาขาในนนทบุรี (ชื่อและรายละเอียดสมมติ) อยากได้แอปให้เจ้าของสัตว์จองคิวและรับแจ้งเตือนวัคซีน ในขั้นที่ 1 ผู้พัฒนาคุยกับพนักงานต้อนรับ และพบว่าคิวจริงอยู่ในสมุดของแต่ละสาขา หน้าจัดคิวของพนักงานจึงต้องมาก่อน เจ้าของตัดระบบสะสมแต้มไปไว้เวอร์ชันสอง และสมัครบัญชีนักพัฒนาในชื่อบริษัททันที พอพนักงานลองกด Prototype ก็พบว่าลูกค้าหลายคนมีสัตว์มากกว่าหนึ่งตัว
เดโมสัปดาห์ที่สามเผยว่าการแจ้งเตือนนับจากวันฉีดล่าสุดโดยไม่ดูชนิดวัคซีน และแก้ได้ในสัปดาห์นั้น ตอนทดสอบ สัตวแพทย์ใช้เครื่องรุ่นเก่าของสาขาที่สี่ และหน้าคิวโหลดช้าเกินใช้ แอปเปิดที่สาขาเดียวก่อนสองสัปดาห์ คำขอที่เข้ามามากที่สุดในเดือนแรกคือจ่ายมัดจำผ่าน PromptPay จึงกลายเป็นงานแรกของเวอร์ชันสอง
สามคำถามที่ถามซ้ำทุกขั้น
คุณคุมโครงการได้โดยไม่ต้องอ่านโค้ด ถามคำถามเดิมสามข้อตอนจบทุกขั้น และไปขั้นถัดไปเมื่อตอบได้ครบ
สามคำถามต่อขั้นตอน
- ข้อ 1 เราตัดสินใจอะไรไปแล้ว และบันทึกไว้ที่ไหน คำตอบควรเป็นเอกสารที่ทั้งสองฝ่ายถือฉบับเดียวกัน
- ข้อ 2 ที่เห็นวันนี้ใช้ข้อมูลจริงหรือข้อมูลตัวอย่าง ยิ่งใกล้วันเปิดตัว ข้อมูลจริงต้องยิ่งมาก
- ข้อ 3 ถ้าหยุดวันนี้ เราได้อะไรกลับมา คำตอบที่ดีคือของที่ทีมอื่นรับไปทำต่อได้
กฎ: ตอบไม่ได้ข้อใด ขอประชุมเพิ่มก่อนอนุมัติงวดถัดไป
ใบเตรียมตัวก่อนคุยกับผู้พัฒนา
ของเจ็ดอย่างนี้ทำให้การประชุมครั้งแรกใช้เวลาไปกับปัญหาของคุณ
- โจทย์หนึ่งย่อหน้า ปัญหาอะไร ของใคร วัดผลอย่างไร
- ลูกค้าและพนักงานสามถึงห้าคนที่ยอมให้สัมภาษณ์
- ระบบเดิมที่ต้องเชื่อม พร้อมชื่อคนดูแล
- ตัวอย่างข้อมูลจริงที่ปิดชื่อลูกค้าแล้ว
- ชื่อคนเดียวที่อนุมัติขอบเขตและแบบ
- เอกสารนิติบุคคลสำหรับบัญชีนักพัฒนาทั้งสอง Store
- นโยบายความเป็นส่วนตัว หรือชื่อคนที่จะเขียน
สำหรับทีมพัฒนา · บัญชี Store การเซ็นแอป และเวลาตรวจ
Apple Developer Program แบบองค์กรต้องเป็นนิติบุคคล มี D-U-N-S Number และผู้สมัครต้องมีอำนาจผูกพันบริษัท บัญชี Google Play แบบบุคคลที่สร้างหลัง 13 พฤศจิกายน 2023 ต้องทำ Closed Testing กับผู้ทดสอบอย่างน้อย 12 คนต่อเนื่อง 14 วันก่อนเผยแพร่ จึงควรใช้บัญชีองค์กรในชื่อลูกค้า Apple ระบุว่าปกติตรวจงานที่ส่งอย่างน้อย 50% ภายใน 24 ชั่วโมง และ 90% ภายใน 48 ชั่วโมง ส่วน Google ระบุว่าบางบัญชีอาจใช้เวลาถึง 7 วันหรือนานกว่าในกรณีพิเศษ เก็บ Signing Certificate และ Upload Key ในที่ที่ลูกค้าเข้าถึงได้ ทดสอบผ่าน TestFlight และ Internal Testing และให้ Privacy Policy กับฟอร์ม Data Safety ตรงกับ SDK ที่ใช้จริง
วิธีที่เราเดินเจ็ดขั้นนี้ไปกับคุณ
กฎของการจองคิวหรือการสั่งซื้อ อยู่กับพนักงานที่ทำงานนั้นทุกวัน DNA Maker จึงเริ่มขั้นที่ 1 ด้วยการนั่งฟังพวกเขา แล้วเขียนเป็นแผนผังงานและตัวเลขที่จะวัด ขอบเขตและราคาคงที่ก่อนเริ่มงาน คุณได้ลอง Prototype ที่กดได้ก่อนอนุมัติ และถ้าโจทย์เหมาะกับ LINE Mini App มากกว่า เราบอกตั้งแต่ตอนนั้น
ทีมของ DNA Maker สร้างแอปเองทั้งหมด ไม่มีการจ้างช่วง เราพัฒนาเป็นสปรินต์ที่เร่งด้วย AI มีเดโมบนมือถือจริงทุกสัปดาห์ วิศวกรอาวุโสตรวจโค้ด ทดสอบเทียบกับขอบเขต ส่งขึ้น Store อบรมทีมของคุณ ส่งมอบ Source Code ตามขอบเขต และดูแลต่อเป็นรายเดือน เราทำงานแบบนี้ให้ธนาคาร โรงพยาบาล และกลุ่มบริษัทขนาดใหญ่ของไทย เล่าโจทย์ให้ Dream ในหน้าแชตฟัง แล้วรับราคาประเมินในไม่กี่นาที หรือดูที่หน้า พัฒนาแอปพลิเคชัน AI
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| Scope | สิ่งที่เวอร์ชันนี้ทำและไม่ทำ | จองคิวอยู่ในขอบเขต สะสมแต้มไม่อยู่ | ขอเพิ่มหนึ่งหน้าจอกลางทาง ราคาและกำหนดส่งเปลี่ยนอย่างไร? |
| Prototype | หน้าจอที่กดได้ ยังไม่มีระบบข้างหลัง | พนักงานลองจองแล้วพบว่าต้องเลือกสัตว์ได้หลายตัว | ผู้ใช้จริงกี่คนลองก่อนเราอนุมัติ? |
| Sprint | รอบพัฒนาสั้น ๆ ที่จบด้วยเดโม | สปรินต์ที่สามส่งหน้าจัดคิว | เดโมสัปดาห์นี้ใช้ข้อมูลจริงหรือไม่? |
| Acceptance Criteria | เกณฑ์ที่ตกลงก่อนทดสอบ | หน้าจองเปิดบนเครื่องรุ่นเก่าภายในสามวินาที | เกณฑ์เขียนไว้ที่ไหน ใครเซ็น? |
| Source Code Ownership | ข้อตกลงว่าโค้ดและเอกสารเป็นของใครหลังส่งมอบ | ทีมอื่นรับโค้ดไปดูแลต่อได้ | หลังงวดสุดท้าย เราได้โค้ด เอกสาร และบัญชีอะไรบ้าง? |