ขั้นตอนในการพัฒนาแอพพลิเคชั่นมีความสำคัญอย่างไร

ในยุคเทคโนโลยีแบบนี้ จะเห็นได้ว่ามี การพัฒนาแอปพลิเคชัน เกิดขึ้นมากมาย หลาย ๆ ธุรกิจหันมาสร้างแอปพลิเคชัน เพื่อบริการลูกค้าให้ใช้งานสะดวกขึ้น ในบทความนี้ Hatyai Application จะมาอธิบายว่า ในการพัฒนา แอปพลิเคชันมีขั้นตอนอย่างไรบ้าง ก่อนอื่น ต้องขอขอบคุณข้อมูลจาก medium.com/@pichayas ด้วยนะคะ

5 ขั้นตอน กระบวนการพัฒนาแอปพลิเคชัน สร้าง Mobile Application

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

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

1.วางแผน

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

• วางแผนคู่แข่ง
  หลังจากได้ไอเดียแล้ว เราก็ต้องมาวางแผน เพื่อให้ แอปพลิเคชัน ของเราประสบความสำเร็จ อย่างแรกสุดที่เราควรเริ่ม คือ การวิเคราะห์คู่แข่ง หา แอปพลิเคชัน ที่มีจุดมุ่งหมายคล้ายคลึงกัน และดูข้อมูลเกี่ยวกับยอดดาวน์โหลด ดูว่ามีคนใช้ แอปพลิเคชัน ของเขามากน้อยแค่ไหน มียอดดาวน์โหลดเท่าไร ดูรีวิวและเรทติ้ง ว่ามีคนชอบ แอปพลิเคชัน แบบนี้ไหม มีส่วนไหนบ้างที่ผู้ใช้ ใช้แล้วไม่ชอบ หรือการใช้งานค่อนข้างซับซ้อน ดูประวัติบริษัท ว่าบริษัทที่ทำ แอปพลิเคชัน นั้นเป็นอย่างไร ผลงานมากน้อยแค่ไหน แล้วเจอปัญหาอะไรบ้างระหว่างทาง และดูว่าเขามีวิธีสร้างฐานผู้ใช้ยังไง ศึกษาข้อมูลคู่แข่งให้ได้มากที่สุด เพราะความผิดพลาดมีราคาของมัน ไม่ว่าจะเป็นเวลา ความเครียด หรือเงิน ปกติคุณจะต้องลองผิดลองถูกหลายครั้ง กว่าจะเจอจุดที่ใช่จริงๆ การเรียนรู้จากคู่แข่ง ช่วยประหยัดเวลาไปได้เยอะมาก และที่สำคัญ คุณต้องเรียนรู้ว่า การจะเข้าไปแทรกในตลาด แอปพลิเคชัน ยากง่ายแค่ไหน ผู้คนอยากได้วิธีใหม่ในการแก้ปัญหานี้แค่ไหน มีคนมากน้อยแค่ไหนที่ไม่ได้รับความพึงพอใจกับวิธีเดิม เข้าใจช่องว่างนี้ และปรับไอเดียของเราให้เหมาะกับช่องว่างตรงนั้น
• วางแผนการหารายได้
  วิธีหารายได้มีหลายแบบ เช่น in-app purchases, subscription รายเดือน, freemium/premium feature, ติดโฆษณา, ขายข้อมูล หรือโมเดลสามัญคือเป็น paid app จ่ายก่อนโหลด วิธีเลือกคือดูว่าตลาดอยากจะจ่ายแบบไหน และตอนนี้เค้าจ่ายกันแบบไหนอยู่กับบริการที่คล้ายๆกัน อีกอย่างที่ต้องคิดก็คือ เมื่อไหร่ที่เราจะเริ่มเก็บตัง เพราะหลายๆแอปโดยเฉพาะ startup ข้ามขั้นตอนนี้ พอจะกลับมาคิดตังอีกทีก็ไม่ทันแล้ว ไม่สามารถทำกำไรได้
• วางแผนการตลาด
  ขั้นตอนนี้ คือ การระบุออกมาว่าเราจะทำการตลาด แอปพลิเคชัน เราได้ยังไง อะไรคืออุปสรรคที่ใหญ่ที่สุด สมมุติว่าคุณมีทีมดีไซน์ และ ทีมพัฒนาที่สร้าง แอปพลิเคชัน ขั้นเทพออกมาได้ อุปสรรคขั้นต่อไปก็ คือ ทำอย่างไรให้คนดาวน์โหลด แอปพลิเคชัน ของคุณ มีบา แอปพลิเคชัน ที่ออกแบบสวยงามและใช้งานได้ดี แต่ไม่มีคนดาวน์โหลด เพราะฉนั้น คุณต้องรู้งบประมาณของคุณ และวิธีการทำการตลาดของคุณ และเขียนออกมาให้ได้
• วางแผน Road Map
  ขั้นตอนสุดท้ายของการวางแผน ก็คือการวาง Roadmap ขั้นตอนนี้คือการทำให้ทุกคนในทีมเข้าใจว่า แอปพลิเคชัน ที่สร้างเสร็จจะเป็นแบบไหน และต้องการอะไรบ้างเพื่อที่จะประสบความสำเร็จในวันแรกของการปล่อย product ซึ่งเราเรียก product เวอร์ชั่นแรกนี้ว่า Minimum Viable Product (MVP) ในขั้นตอนนี้เราจะเขียนทุกสิ่งที่เราอยากให้แอปทำได้ แล้วเอามาเรียงลำดับความสำคัญ ดูว่าอะไรคือหัวใจหลัก อะไรทำให้ดูดผู้ใช้งานมาเริ่มใช้ของเราได้ และอะไรไว้เพิ่มที่หลังก็ได้ ถ้าบางอย่างเราคิดว่าผู้ใช้น่าจะอยากได้ พวกนั้นสมควรเอาไปทำหลังๆได้เลย เพราะหลังจากเราได้ผู้ใช้มาระดับนึงกับ MVP เราสามารถรู้ได้ดีขึ้นว่า feature ต่อไปควรทำอะไรจาก feedback ว่าผู้ใช้อยากได้จริงๆ และพวก analytics ที่เราติดไว้ก็มีส่วนช่วยมากๆ

2.ออกแบบ (Design)

• ออกแบบ UX
  ออกแบบโครงสร้างข้อมูล เป็นขั้นตอนที่เราตัดสินใจว่าแอปเราต้องแสดงข้อมูลอะไรบ้าง และทำงานอะไรได้บ้าง ปกติเราจะลิสต์มาว่าแอปมี feature อะไร ทำอะไรได้บ้าง และต้องแสดงข้อมูลอะไรที่หน้าไหนของแอป จากนั้นเราก็มาสร้างเป็น wireframe
  • Wireframe
    ขั้นต่อไป เราจะเริ่มสร้างแต่ละ screen และกำหนดการทำงานและข้อมูลที่จะแสดง ต้องทำให้มั่นใจว่าข้อมูลที่จะแสดงต้องมีที่อยู่ของมัน ควรเริ่มต้นในกระดาษเพราะมันจะแก้เยอะ และแก้บ่อย จะได้แก้ง่ายๆ ดีกว่าไปแก้ใน process หลังๆ แล้วก็มาทำต่อด้วยพวกแอปแบบ Sketch หรือแอปสร้าง wireframe ที่เราถนัด พอเรามี screen ครบแล้ว เราก็จะมาสร้างแอป workflow กัน
  • Workflows
    Workflow คือเส้นทางที่ user สามารถท่องไปในแอปของเราได้ ทุกๆอย่างที่เราอยากให้ user ทำและเห็นได้ ต้องใช้กี่คลิกเพื่อที่จะทำมันได้สำเร็จ ต้องทำให้มั่นใจว่าทุกคลิกนั้นเข้าใจได้อย่างง่ายดาย โดยผู้ใช้ไม่งง ถ้าบางอย่างใหญ่ๆ ใช้ไม่กี่คลิกเพื่อทำจนสำเร็จก็ยังถือว่าดี แต่บางอย่างง่ายๆก็ไม่ควรต้องใช้หลายคลิกเกิน พอเราเจอปัญหาใน workflow เราก็ต้องกลับไปอัพเดท wireframe และก็ลองใหม่ด้วยการเทสทุก flow ตั้งแต่ต้น เพื่อให้มั่นใจว่าการแก้ flow นี้ให้ง่ายขึ้น ไม่ได้ทำให้อีก flow ยากขึ้นแทน
  • Click-through model
    Click-through model ช่วยให้เราทดสอบ wireframe และ workflow โดยการให้ user ได้ทดลองเหมือนเล่นจริง โดย user จะได้รับ link อันนึง เมืองเปิดบนมือถือ user จะสามารถคลิกที่ปุ่มต่างๆ และเปิดไปยังหน้า wireframe ต่างๆ ตาม workflow ได้เหมือนแอปจริงๆ ในขั้นตอนนี้จะยังไม่มีการทำงานใดๆทั้งสิ้น เป็นแค่รูปภาพของแต่ละหน้าเพื่อทดสอบ navigation ของแอป เมื่อเราเจอปัญหาที่หน้าไหน ก็แก้ wireframe หน้านั้น และทดลองใหม่จนกว่าจะพอใจ tools ที่ใช้ได้ก็มี invision, sketch, adobe xd
• ออกแบบ UI
  • Style guide
    Style guide หรือ UI Kit เป็นเหมือนต้นแบบของสิ่งต่างๆในแอป การมี style ที่ชัดเจนจะช่วยให้ user ไม่งงกับการใช้งานแอปเรา เราไม่อยากจะให้แอปเรา หน้านึงมีปุ่ม ok สีฟ้าอยู่ข้างล่าง อีกหน้านึงเป็นสีเขียวตรง header หรอก การมี style ที่จัดเจนและตรงกันทั้งแอปจะทำให้ user ใช้งานได้ลื่นขึ้น
    การกำหนด Style guide ก็ต้องดูด้วยว่าลูกค้าและผู้ใช้เราเป็นใคร แอปจะใช้เวลาไหน ถ้าใช้กลางคืนก็อาจจะต้องทำสีให้ dark หน่อย ถ้าถูกใช้โดยพนักงานบริษัทที่งานยุ่งมากๆ ก็อาจจะต้องลดขั้นตอนยุ่งยาก และทำให้งานสำเร็จได้โดยไว designer ที่มีประสบการณ์จะต้องสามารถออกแบบผลงานออกมาให้เหมาะกับผู้ใช้ให้มากที่สุด ผลลัพธ์ของขั้นตอนนี้ เราจะได้สี, fonts, และ widget เช่น ปุ่ม, ฟอร์ม, label ที่จะเอามาใช้ในแอปเราทั้งหมด
  • Rendered design
    ขั้นนี้คือการเปลี่ยน wireframe สีขาวดำของเราให้กลายเป็นหน้าตาแอปจริงๆ โดยใช้ Style guide ที่สร้างขั้นเมื่อขั้นตอนที่แล้ว พยายามอิงกับ Style guide ในทุกจุด แต่ถ้ามีจุดไหนต้องอัพเดทหรือเพิ่ม Style guide ก็สามารถกลับไปอัพเดทได้ แต่ต้องให้มั่นใจว่าผลลัพ์ออกมามีความสอดคล้องกันทั้งแอป
  • Rendered click-through model
    หลังได้หน้าตาแอปจริงทั้งหมดมาแล้ว ให้เรากลับมาทำ click-through model อีกรอบ ในขั้นตอนนี้อาจจะต้องใช้เวลามากหน่อย เพื่อให้มั่นใจว่าจะไม่มีการแก้ไขใหญ่ๆอีกแล้ว เพราะหลังจากขั้นตอนนี้ การเปลี่ยนอะไรบางอย่างจะมีราคาแพงและใช้เวลานานขึ้น ให้คิดว่าขั้นตอนนี้คือการเช็คพื้นครั้งสุดท้ายก่อนที่จะเริ่มเทปูนซีเมน แน่นอนว่าหลังจากนี้ไม่ใช่ว่าจะเปลี่ยนอะไรไม่ได้เลย แต่การเปลี่ยนแต่ละครั้งจะมีราคาสูงขึ้นมาก
  • การส่งไม้ต่อจาก Design ไปยัง Development
    หลังจากใช้พลังงานอย่างมากไปในการออกแบบว่าแอปจะมีหน้าตายังไงและทำอะไรได้บ้าง มันจำเป็นอย่างมากที่จะทำให้ dev team เข้าใจใน vision ตรงกัน หลายๆองค์กร ทำตรงนี้ได้แย่เพราะเหตุผลหลายๆอย่าง designer และ developer คล้ายๆกับอยู่กันคนละโลก บางที่อาจจะสื่อสารกันไม่เข้าใจเพราะแต่ละคนก็มองจากมุมตัวเอง ถ้าในองค์กร ทีม designer เข้าใจ technical ขึ้นนิดหน่อย และ dev team ก็ทำความเข้าใจกับมุมมองของ designer ขึ้นอีกนิด จะทำให้การทำงานราบรื่นขึ้นเยอะมาก Tool ที่แนะนำให้ใช้ก็คือ Zeplin (ที่ GetLinks ก็ใช้อยู่) Designer จะเป็นคนอัพโหลด design ขึ้นไป แล้ว dev สามารถเอา Style guide มาใช้ได้เลย dev ไม่ต้องเดา dimension ค่าสี hex และตำแหน่งที่แน่นอนบนหน้าจอ dev สามารถพัฒนา pixel-perfect แอปจาก design ได้ทันที

3. เขียน code

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

• ฝั่ง Front-end
  ในการทำ mobile app มี 3 ทางเลือก
  • – Native ทำแอปแยกแต่ละ platform ไม่สามารถ reuse code ระหว่างกันได้ วิธีนี้ทำให้ปรับแต่งได้สูงสุด UI เป็นของ platform 100% แอปเร็วและมีประสิทธิภาพสูง เป็นวิธีที่แพงที่สุด เพราะต้องทำแต่ละ platform ใหม่ทั้งหมด
  • – Cross-platform เป็นเทคโนโลยีที่มี code บางส่วนหรือทั้งหมดแชร์กัน แต่ก็ยัง build ไปรันเป็น Native เช่น React Native, Xamarin อันนี้เป็นวิธีสายกลางที่ประหยัดเงินและเวลา ถ้าเราไม่ต้องการ performance สูงสุดขนาดแบบแรก
  • – Hybrid เป็นวิธีที่ใช้เทคโนโลยีของ web (HTML, CSS, Javascript) และ install ผ่าน native wrapper เช่น Cordova, Phone Gap, Ionic วิธีนี้อาจจะราคาถูกสุด แต่แอปออกมาคุณภาพค่อนข้างต่ำ และช้ามาก
• ฝั่ง Back-end (Web API & Server)
  Server มีผลอย่างมากกับประสิทธิภาพของแอป และการขยายจำนวนผู้ใช้ที่แอปรองรับได้ มีสิ่งที่ต้องตัดสินใจก่อนจะเริ่มเขียน code ดังนี้
  • – ภาษา Java, C#, Go-lang, Javascript, PHP, Python, Ruby แต่ละภาษาก็จะมี framework ที่ช่วยในการเขียนของตัวเอง
  • – Database มี 2 ประเภทหลักๆ SQL และ noSQL SQL เป็นของดั้งเดิมที่มักจะเป็นทางเลือกที่ดีที่สุดในแทบทุกกรณี มีหลายยี่ห้อให้เลือก เช่น MSSQL, MySQL, PostgreSQL เป็นต้น noSQL ใช้ในสถานการณ์ที่ต้องการเก็บข้อมูลปริมาณมหาศาลหรือไม่มีการแก้ไขข้อมูลเดิมบ่อยๆ นอกจากการเลือก database แล้วยังมีเรื่องของการออกแบบ schema ว่าจะเก็บข้อมูลยังไง การออกแบบที่ดีจะส่งผลต่อความสำเร็จในระยะยาว ดังนั้นในขั้นตอนนี้ต้องมั่นใจว่า database ได้ออกแบบไว้อย่างดี และรองรับอนาคต
  • – Hosting environment (Infrastructure) เลือกว่าจะ host server เราไว้ที่ไหน ตัดสินใจจากราคา ความสามารถในการขยายสเกล ความสามารถที่ทำได้ บริการเสริม การใช้งานง่าย ประสิทธิภาพ และความสเถียร มีหลายเจ้า เช่น AWS, Google Cloud, Heroku, Azure นอกเหนือจากนั้นเรายังต้องวางแผนเผื่อการสเกล เมื่อจำนวนผู้ใช้เพิ่มมากขั้น Cloud-base ทำให้เราสามารถจ่ายเงินเพื่อเพิ่มหรือลดได้ตามความจำเป็น นอกจากนี้ยังมีบริการเสริม เช่น backup database, server uptime, update os และอีกมากมาย
  • – Agile development process
  • คือการแตกย่อยงานที่ต้องพัฒนาทั้งหมดออกมาเป็น milestone ที่เล็กลง และเริ่มพัฒนาแอปเราเป็นรอบๆ วนลูปไปเรื่อยๆ ในแต่ละรอบจะมีการวางแผน, การพัฒนา, การเทส, และการรีวิว เรื่อง Agile เป็นเรื่องที่มีการเผยแพร่เยอะ และมีรายละเอียดเยอะ แต่ในบทความนี้จะเล่าแค่คร่าวๆ ในระดับที่เพียงพอต่อการทำงานในแต่ละ step ก็พอ
• การวางแผน
  การวางแผนคือการแบ่งงานออกเป็นลิสต์ของ task ที่จะ code ในรอบ iteration นี้ แต่ละ task จะต้องมี requirement ที่ชัดเจน หลังจากที่ developer เข้าใจ requirement ดีแล้ว developer ก็จะประเมินเวลาที่ต้องใช้ในการทำแต่ละ task เพื่อที่จะกระจายงานกันไปทำได้อย่างสมดุลกับปริมาณงานที่ทีมทำได้ในแต่ละ sprint
  Developer จะเริ่มวางแผนว่าจะเขียน solution ยังไงเพื่อมาแก้ปัญหาในแต่ละ task developer เก่งๆจะหาทาง reuse code ทั้งแอปให้มากที่สุด เช่นพวก style หรือ function ที่ใช้ร่วมกันได้ ถ้าต้องเปลี่ยน design ก็แค่ไปอัพเดทที่เดียวก็จะเปลี่ยนทั้งหมด ไม่ต้องไปนั่งไล่อัพเดททุกๆที่
• การพัฒนา
  Developer จะเริ่ม code ตาม requirement ใน task ที่ได้รับมอบหมาย developer ต้องเข้าใจเป้าหมายสูงสุดของแอป และเจตนาของแต่ละ task ถ้าบางอย่างมันทำไปแล้วดูไม่ถูกต้อง developer ต้องรีบมาบอก PM เพื่อจะได้หาทางออกกัน เมื่อ task นั้นๆ เสร็จก็จะ deploy ขึ้น development version ให้ tester เทสได้
• การ Test
  การเทสควรทำโดยคนที่ไม่ใช่ developer ที่ code แอปนี้ขึ้นมา เพราะ developer จะรู้อยู่แล้วว่าตรงไหนทำอะไรได้ บางทีก็จะไม่เจอสิ่งที่ user ที่ใช้งานจริงจะเจอเมื่อใช้งานทั่วไป การเทสมีหลายประเภทในแต่ละความคืบหน้าของการพัฒนา
  • – Functional Test การเทสว่า feature นี้ทำงานได้ถูกต้องตาม requirement หรือไม่ ทีม QA จะมี test case, action step และผลลัพธ์ที่คาดหวังว่าจะให้มันเกิด
  • – Usability Testing เทสว่าผู้ใช้ไม่งง และใช้งานง่ายพอมั้ย ตอนเทสควรเอาคนที่เคยเห็นแอปเป็นครั้งแรกมาเทส เพื่อจำลองว่าเค้าเป็นคนที่เพิ่งเริ่มใช้จริงๆ โดยกำหนด target group เพื่อนำมาเทส สัมภาษณ์ว่าเค้ามี background ยังไง จากนั้นก็ให้เค้าใช้แอปเหมือนคนเพิ่งเห็นแอปนี้ครั้งแรกใน store ไม่ต้องแนะนำวิธีใช้ ดูว่าเค้าใช้แอปเรายังไง ติดตรงไหน หลังจากเสร็จก็ถาม feedback และนำมาปรับปรุงแอปต่อไป
  • – Performance Testing ถ้าแอปใช้เวลา 20 วิในการเปิด ต่อให้ทำงานถูกต้องก็คงไม่มีใครใช้ Performance Testing ต้องทำก่อนปล่อยให้ user จริงใช้ แต่ถ้าเทสเจอตั้งแต่แรกๆ ก็อาจจะทำให้แก้ไขได้ง่ายกว่าไปแก้ตอนท้าย
  • – Regression Testing เทส feature ที่เคยทำเสร็จและเทสผ่านไปใน sprint ก่อนๆ เพราะการทำงานใน sprint นี้อาจส่งผลกระทบกับ feature เก่าทำให้ทำงานผิดพลาดได้ tester ที่ดีควรจะมี list ของ test case เพื่อมาเทสของ sprint ที่ผ่านไปแล้วด้วย
  • – Device-Specific Testing เทสบนหลายๆ screen size และ OS version หรือ browser มีหลาย tool ที่ช่วยจำลองเครื่องหลายๆรุ่นได้ แต่ก็ต้องเทสบนเครื่องจริงจำนวนนึง เพื่อให้มั่นใจว่ามันทำงานได้แน่ๆบนเครื่องส่วนใหญ่
  • – User Acceptance Testing ให้ user จริงๆ เทส และเก็บ feedback จริงเ
• เมื่อเจอบัคก็ต้องสร้าง task ให้ developer ไปแก้ไขและปิด issue task นี้
  • – sprint รีวิว/retrospective
  • ตอนท้ายของทุก sprint จะมีประชุมเพื่อคุยกับทุกคนที่เกี่ยวข้องว่า sprint ที่ผ่านมาเป็นยังไงบ้าง อะไรดี อะไรไม่ดี ถ้ามีปัญหาอะไรก็จะได้พยายามแก้ไขไม่ให้เกิดอีกใน sprint หน้า ถ้าบางอย่างมันดีในส่วนไหน ก็นำมาใช้กับส่วนอื่นๆ พอจบ sprint review ก็จะต้องวนกลับไป ขั้นตอนการวางแผน และทำวนไปเรื่อยๆ จนแอปเสร็จ
  • – Beta testing
  • เมื่อแอปเราเสร็จเรียบร้อย เราอาจจะทำ beta launch อีกรอบ beta launch คือการให้ผู้ใช้งานกลุ่มเล็กๆ ใช้งานจริงในสถานการณ์จริงเหมือนกับแอปเรา launch ไปแล้ว ส่วนใหญ่กลุ่มนี้จะเป็น power user, early adopter หรือลูกค้าที่ชอบเราเป็นทุนเดิม ในขั้นตอนนี้เราจะได้ข้อมูลที่หลากหลายขึ้นอย่างมาก เราอาจจะเจอปัญหาที่ไม่เคยเทสเจอมาก่อนมากมาย ซึ่งดีกว่าปล่อยแอปและทำการตลาดแล้วเพิ่งมาเจอปัญหาทีหลังหลังจาก Beta testing แล้วแก้ปัญหาที่พบไปจนหมด และไม่มีปัญหาใหม่ๆ รายงานมาอีกแล้ว ก็เริ่ม step ต่อไปได้

4.ปล่อยแอปพลิเคชัน

แอปทั่วไปจะมี 2 ส่วนที่สำคัญที่เราต้อง deploy ก็คือ web server กับ client ที่ไว้บน Google Play หรือ Apple Store

• Web API (Server)
  ส่วนนี้คือการรับส่งและเก็บข้อมูลของ mobile app ถ้า server โดนใช้งานหนักเกิน หรือล่ม แอปก็ทำงานไม่ได้ไปด้วย server ต้องสามารถ scale ได้เมื่อเกิดเหตุการณ์ไม่คาดฝันหรือแอปเกิดบูมขึ้นมา เทคโนโลยีฝั่ง server ก็มีหลากหลาย ตั้งแต่ Infra ไปจนถึง programming ยกตัวอย่างเช่น AWS, Google Cloud, Kubernetes, Docker, Node.js, RoR, etc.
• App Store
  การอัพแอปขึ้น store เราต้องมั่นใจว่าแอปได้ config ถูกต้องสำหรับ production มีขั้นตอนหลายขั้นตอนในการทำ มีฟอร์มหลายอันที่ต้องกรอก ต้องทำ screenshot และเนื้อหาสำหรับ marketing ต้องเขียนคำอธิบาย และเราก็ submit ขึ้นไป ฝั่ง Apple จะมีการตรวจที่ละเอียดกว่า Google Play ฝั่ง Apple จะใช้เวลา 2–3 วัน ส่วน Google Play จะได้ในไม่กี่ชั่วโมงเลย
  

5.สังเกตการณ์ และวัดผล

เมื่อ submit app ขึ้นไปแล้ว งานของเรายังไม่จบ จะเห็นได้ว่าแอปดังๆทุกแอปมีลิสต์ของอัพเดทยาวเป็นหางว่าว ไม่ว่าจะเป็น แก้บัค, เปลี่ยน เพิ่มฟีเจอร์ การสังเกตการณ์สำคัญมากๆ เพื่อเราจะได้รู้ว่าต้องอัพเดทอะไร นี่คือสิ่งที่ต้องสังเกตการณ์

• Crashes
  มีหลายเจ้าที่ track app crash ได้ Sentry, HockeyApp, Rollbar, Fabric ฯลฯ มันสามารถดูได้ด้วยว่าก่อน crash user ทำอะไรอยู่หน้าไหน เครื่องรุ่นอะไร และข้อมูลแวดล้อมอื่นๆ และสามารถแจ้งเตือนแบบ realtime ผ่าน email/sms ได้ทันทีที่ crash
• Analytics
  analytics ใหม่ๆสามารถ track ข้อมูลได้แทบทุกอย่างของ user ทำให้คุณเข้าใจว่า user คือใคร อายุ เพศ สถานที่ ภาษา และเค้าใช้งานแอปเรายังไง เวลาที่เล่น เวลาที่ใช้ในแอป หน้าที่ดู และไปจนถึงพฤติกรรมเช่น heatmap หรือปุ่มไหนโดนคลิกเยอะสุด ใช้ข้อมูลตรงนี้ทำความเข้าใจ user ให้มากที่สุด และดูว่าตรงไหนควรลงทุนลงแรงในอนาคต อย่าไปลงแรงกับส่วนที่ไม่ค่อยมีคนใช้ แต่ลงในส่วนที่มีความเป็นไปได้ว่าจะเกิดการเติบโตสูงที่สุด tool ที่ใช้ Facebook Analytics, Apptentive, Google Analytics, Appsee
• Performance
  แอปเปิดได้ไวแค่ไหน ทำงานได้ไวแค่ไหน เราจะดูได้ว่า action ไหนใช้เวลาเท่าไหร่ แล้วเราจะเจอจุดที่ต้องปรับปรุงที่นั่น เราสามารถตั้งให้ alert เมื่อเกิดเหตุการณ์ที่บาง action ใช้เวลานานผิดปกติ เราจะได้เข้าไปดูว่าเกิดปัญหาอะไรขึ้นหรือไม่ tool ที่ใช้ Prometheus, New Relic
• App Store Management
  Rating และ Review ใน Store เป็นสิ่งสำคัญมากๆ ทุกครั้งที่มี review ใหม่ ต้องมั่นใจว่าเราได้เข้าไปดูคนรีวิว ขอบคุณ หรือพยายามช่วยเหลือในสิ่งที่ทำให้เค้าโมโหจนให้ 1 ดาว ซึ่งหลายครั้งที่การ customer support แค่เล็กน้อยทำให้เค้าเปลี่ยนจาก 1 ดาวเป็น 5 ดาวได้ และบริการที่ดีก็ทำให้ชื่อเสียงเราดีตามไปด้วย
• Further Iteration and Improvement
  เป้าหมายของการสังเกตการณ์คือจะได้รู้ว่าเราควรทำอะไรเป็นสิ่งต่อไป เพราะถ้าเราเปิดให้คนใช้ และดูแลแอปนี้ไปสักพัก มันก็จะต้องมี feature ใหม่ๆเพิ่มเข้ามาเพื่อปรับปรุงให้ดีขึ้นไปเรื่อยๆ ใช้ข้อมูลจากผู้ใช้ และการ monitor แล้วเอาไปเข้า development process loop เพิ่ม conversion rate, install number, และรายได้ไปเรื่อยๆ

ขอบคุณข้อมูลจาก medium.com/@pichayas