จากความไม่สะดวกของลูกค้าสู่การเป็นผลิตภัณฑ์ - กระบวนการพัฒนาของทีม API ของ Airbridge
(engineering.ab180.co)บทความแนะนำว่าทีม API สร้าง Airbridge ซึ่งเป็นเครื่องมือการตลาดแบบ B2B ด้วยกระบวนการอย่างไร
- รวบรวมคำขอและไอเดียจากลูกค้า
- คัดเลือกปัญหาที่ต้องแก้ตามลำดับความสำคัญ
- ดำเนินการ Kick off
- ทำความเข้าใจว่าเป็นงานลักษณะใดและทำให้สถานการณ์การใช้งานของผู้ใช้ชัดเจนขึ้น
- นักพัฒนาก็เข้าร่วมตั้งแต่ขั้นตอนนี้และเสนอความเห็นด้านเทคนิคอย่างเชิงรุก
- เขียน Tech spec
- เขียนสรุป ที่มา เป้าหมาย สิ่งที่ไม่ใช่เป้าหมาย แผนงาน Q&A ที่คาดไว้ ประเด็นที่ต้องพิจารณา และไมล์สโตน
- ทดลองเขียนโค้ดของงานที่จะทำล่วงหน้าประมาณ 30% เพื่อวางแผนที่ทำได้จริง
- รีวิวร่วมกับ counterpart
- ลงมือเขียนโค้ด
- โค้ดทั้งหมดจำเป็นต้องมี test code ที่สอดคล้องกัน
- QA & Code Review
- สร้าง QA Endpoint โดยอัตโนมัติผ่าน feature branch
- เพื่อช่วยในการ Code Review มีการทำ automation สำหรับการรันเทสต์และการใช้เครื่องมือ static analysis
- Release
- ฉลองร่วมกับเพื่อนร่วมงานที่ผลิตภัณฑ์ดีขึ้นกว่าเดิม
ผ่านกระบวนการนี้ทำให้วงจรฟีดแบ็กสั้นลง ทำให้ขั้นตอนการพัฒนาโปร่งใสจนสามารถคาดการณ์กำหนดการได้มากขึ้น และลดโอกาสที่ฟังก์ชันจะเกิดข้อผิดพลาด
- ข้อผิดพลาดจากการปล่อยฟีเจอร์ใหม่ลดลง 18% เมื่อเทียบกับช่วงเวลาเดียวกัน และตั๋วงานขนาดเล็กก็ยังสามารถปล่อยได้ภายใน 5 วันแม้จะผ่านกระบวนการนี้
1 ความคิดเห็น
เมื่อเรียนวิชาวิศวกรรมซอฟต์แวร์ในมหาวิทยาลัย มีสิ่งหนึ่งที่ต้องได้เรียนรู้อย่างแน่นอน คือ “การแก้ไขในขั้นวางแผนมีต้นทุนต่ำที่สุด และการแก้ไขหลังพัฒนาเสร็จมีต้นทุนสูงที่สุด” เป็นหลักการที่แม้จะรู้ แต่ก็ทำให้เกิดขึ้นจริงได้ยาก โดยเฉพาะในสตาร์ทอัปที่ต้องเคลื่อนไหวอย่างรวดเร็วยิ่งเป็นเช่นนั้น
ทีมพัฒนาของ Airbridge พยายามเดินไปในทิศทางที่เชื่อว่าถูกต้อง แม้จะเป็นเรื่องยากก็ตาม