ส่วนไหนของซอฟต์แวร์ที่กินเวลาในการพัฒนามากที่สุด … ผมขอโหวตว่ายูไอ
ประสบการณ์ที่ผ่านมายูไองานเยอะและยาวนานเสมอ แทบจำไม่ได้แล้วว่าครั้งสุดท้ายที่อยู่ในสถานการณ์ที่ยูไอเสร็จก่อนส่วนอื่นคือเมื่อไร อาจจะไม่เคยเลย
ตอนนี้ก็เช่นกันครับ ยูไอคือคอขวด ยูไอกำลังกรีดร้องขอความช่วยเหลืออีกครั้ง … ทำไมถึงเป็นแบบนี้?
1️⃣ เพราะยูไอมีรายละเอียดเยอะที่สุด
มันชัดเจนเลยสำหรับข้อนี้ คงไม่ต้องอธิบายอะไรกันมากเพราะยูไอเป็นตัวแทนของการติดต่อสื่อสารกับผู้ใช้ ทั้งรับคำสั่งและแสดงผลลัพธ์ รายละเอียดยิบย่อยจึงมากมาย รูปแบบองค์ประกอบ เลย์เอ้าท์ สไตล์ สี ฟ้อนท์ ขนาด
ยิ่งรายละเอียดมากยิ่งมีความซับซ้อนในงานมากขึ้น
2️⃣ เพราะยูไอต้องเกี่ยวข้องกับคนหลายกลุ่ม
ในขณะที่งานฝั่งเซิร์ฟเวอร์หรืออินฟราหรือเดต้าเบสนั้นสามารถตีสโคปให้แคบด้วยผู้เชี่ยวชาญเพียงกลุ่มเล็กๆ แต่ยูไอนั้นไม่ได้ ยูไอต้องการผู้เชี่ยวชาญเฉพาะด้านหลายกลุ่มมาก … เราต้องมีคนที่ออกแบบและดูแลความเชื่อมโยงลื่นไหลของยูไอที่เหมาะสมกับผู้ใช้ (ยูเอ็กซ์) … อย่างน้อยๆเราต้องมีคนออกแบบความสวยงามและวาดรูปไอค่อนปุ่มและอะนิเมชั่น (ยูไอและกราฟฟิคดีไซเนอร์) ทำไมเราต้องมีคนเขียนโค๊ดให้ออกมาเป็นยูไอ (ดีเวลลอปเปอร์)
ยิ่งคนมากก็ยิ่งกินเวลาในการทำงานมากตามไปด้วย ยิ่งคนมากการส่งต่อข้อมูลและการสื่อสารจึงเป็นปัจจัยที่ทำให้งานยูไอช้าลง
3️⃣ เพราะยูไอเป็นส่วนที่ง่ายที่สุดที่จะถูกสั่งให้แก้ไข
ไม่ใช่เป็นเรื่องทางเทคนิคแต่เป็นเรื่องความต้องการและรสนิยมล้วนๆ การตัดสินใจและเปลี่ยนใจในยูไอเป็นเรื่องที่เกิดขึ้นง่ายมาก (มากเกินไป) ตอนเช้าอยากได้กราฟเส้นนี้ตอนสายขอเปลี่ยนใหม่เป็นกราฟแท่ง … ตกเย็นขอแก้เป็นกราฟวงกลม
เมื่อยูไอเริ่มเห็นเป็นรูปเป็นร่างในเวอร์ชั่น (หรือสปริ้นท์) แรกๆของการพัฒนา … จินตนาการจะมาเต็ม กลายเป็นว่างานที่ออกแบบและทำไว้ตอนแรกมันไม่เป็นไปตามความคาดหวังซะแล้วและมันก็ต้องเปลี่ยน
ยิ่งเปลี่ยนบ่อยก็ยิ่งช้า
4️⃣ เพราะยูไอแตกหักได้ง่ายที่สุด
มันเปราะบางมากๆ จริงอยู่อาจจะไม่ใช่บั๊กใหญ่โตซีเรียสแต่มันเป็นบั๊กเล็กบั๊กน้อยจำนวนมหาศาลที่เราตรวจพบ ที่เพื่อนเราตรวจพบ ที่ผู้ใช้ตรวจพบ และมันก็เป็นเรื่องน่ารำคาญถ้าเราไม่แก้ไขมันให้หมด แบบนี้ แบบนี้ และแบบนี้
5️⃣ เพราะยูไอเป็นส่วนที่ดึงดูดคอมเม้นท์มากที่สุด
ใครๆก็เป็นยูไอเทสเตอร์ได้ ไม่ต้องมีพื้นฐานความเข้าใจเรื่องเทคนิคคอมพิวเตอร์หรือการเขียนโปรแกรมอะไรทั้งสิ้น
“ผมว่าปุ่มมันไม่น่าจะอยู่ตรงนี้นะ แต่ก็ไม่รู้ว่าควรอยู่ตรงไหน” — จากทีมซัพพอร์ต
“หนูว่าต้องหาช่องใส่วิดีโอเข้าไปด้วยนะคะ ไม่งั้นลูกค้าคงไม่ติดใจ” — จากทีมมาร์เก็ตติ้ง
“ผมว่าไอค่อนมันเชยไปหน่อยนะ” — จากผู้จัดการฝ่ายบัญชี
“พี่ว่ามันไม่ควรจะเก็บข้อมูลแค่นี้นะ ต้องขอที่อยู่ เบอร์โทร ชื่อญาติใกล้ชิดมาด้วยซิ” — จากผู้อำนวยการฝ่ายปฏิบัติการ
“ผมว่าสีไม่สวย ฟ้อนท์ก็เล็กไป” — จากทีมไฟแนนซ์
“ขอภาษาไทยด้วยได้มั้ยคะ?” — จากผู้ใช้
จากหกคนนี้ … จะมีใครบ้างที่สามารถให้คอมเม้นท์ในงานส่วนแบ็คเอ็น? ไม่มีมั้ง แต่ถ้าเป็นยูไอหละก็อย่างที่เห็น
ผมไม่ได้บอกว่าเราต้องตอบตกลงยอมรับกับทุกคำติชม แต่ยิ่งได้ฟังมากมันก็ยิ่งไขว้เขวไม่มากก็น้อย จริงมั้ย?
6️⃣ เพราะยูไอเทสยากที่สุด
โอเค ผมอาจจะพูดเกินจริงไปนิดเมื่อเทียบกับการเทสระดับลึกของงานประสิทธิภาพของระบบและพวกนอนฟังชั่นนอลเทสต่างๆ แต่ยูไอก็ยากจริงๆนั่นแหละ ในขณะที่ฝั่งเซิร์ฟเวอร์แบคเอ็นเอพีไอนั้นสามารถทำเทสแบบเดี่ยวๆได้ด้วยคอมมานไลน์ โดยที่ผลลัพธ์จากการเทสนั้นค่อนข้างเชื่อถือได้ว่าโค๊ดของเราจะทำงานถูกต้อง แต่ยูไอนั้นไม่ใช่
ยูไออยู่เหนือสุดและยูไอจะอยู่เดี่ยวๆไม่ได้ถ้าไม่มีฝั่งแบคเอ็นมาซัพพอร์ต ใช่ เราอาจจะทำม๊อกเดต้าหรือม๊อกรีเครสเพื่อเทสยูไอแบบสแตนอะโลน แต่ผลลัพธ์นั้นเชื่อถืออะไรไม่ได้อยู่ดีจนกระทั่งเราได้ทำอินทิเกรชั่นเทสกับส่วนอื่นๆ
ที่น่าสนใจคือในขณะที่การเทสแบคเอ็นนั้นแทบไม่ช่วยตรวจจับบั๊กฝั่งยูไอ ในทางกลับกันการเทสยูไอนั้นหลายครั้งจะเป็นการเปิดเผยให้เห็นบั๊กฝั่งแบคเอ็น มันเลยเหมือนว่าเรารับงานเทสสองฝั่งนะไปโดยปริยาย
นี่ยังไม่นับว่ายูไอถูกแก้ไขได้ง่ายที่สุดอีกต่างหาก ยิ่งแก้บ่อยการเทสก็ต้องเปลี่ยนแปลงไปเรื่อยๆ ทำให้การลงทุนในออโตเมสเทสยิ่งไม่คุ้มค่า กลายเป็นต้องใช้พลังงานนิ้วในการไล่กดเทสกันอย่างขยันขันแข็ง … และน่าเบื่อหน่าย
เป็นแค่หกสาเหตุที่ผมคิดออกว่าทำไมยูไอถึงใช้เวลานานที่สุดในการพัฒนา เห้อ … ก็ต้องทำใจยอมรับสภาพกันต่อไปสักพักครับ หวังว่าจบเวอร์ชั่นแรกนี้แล้วอะไรๆจะไปได้เร็วขึ้นกว่าเดิม มันจะเป็นแบบนั้นมั้ยนะ? 🤔