มีบล็อคในสต็อคอยากอัพเป็นสิบเลยตอนนี้ แต่ไม่ค่อยจะมีเวลาเลย ทยอยปล่อยทีละนิดๆละกันเนอะ

หลังจากบล็อคเรื่อง Big-O กับต้นทุนที่ต่างกัน ถูกปล่อยไป ก็ได้รับความนิยมอย่างมากอย่างไม่น่าเชื่อ จากเดิมมีคนเข้าวันละ 3 คน ก็พุ่งขึ้นมาเป็น 4 คนทันที ... ไม่ใช่ละ ก็เอาเป็นว่าวันนี้เลยขอมาต่อกับเรื่องของ "ต้นทุน" อีกเช่นกัน แต่คราวนี้เป็น "ต้นทุนแฝง" ที่เกิดจากการทำอะไรโดยไม่ยอมออกแบบให้ดีก่อน และถึงมันจะ Apply ไปใช้ได้กับทุกเรื่องในชีวิต แต่ขอยกตัวอย่างเรื่องราวจากงานที่ตัวเองถนัดที่สุดอย่างการเขียนโปรแกรมละกัน

แต่ก่อนสมัยเขียนโปรแกรมใหม่ๆ วิถีของชีวิตเวลาจะทำอะไรคือ "ลุยแม่มเลย" ก็มันเป็นงานปฏิบัติหนิครับ ก็เริ่มลุยเริ่มเขียนไปเลยเซ่

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

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

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

อะไรเล่าดลใจให้เกิดการเปลี่ยนแปลงวิถีการรทำงานแบบนี้ ...​ ก็เพราะเจ็บมาเยอะฮะ เจ็บมาเยอะ เจ็บจน Realize ได้ว่า งานของโปรแกรมเมอร์ในการเขียนงานขึ้นมาชิ้นนึงตั้งแต่เริ่มต้นจน Deploy ได้นั้น จะประกอบด้วยสี่ส่วนด้วยกัน คือ (1) Research (2) Design (3) Programming (4) Testing & Fixing

สำหรับคนที่เริ่มต้นงานด้านนี้แบบใหม่มากๆ ไม่รู้เรื่องรู้ราว จะมองเห็นแค่ส่วนเดียวคือส่วนที่ 3 "Programming" (ก็มันงานเขียนโปรแกรมหนิ!) แต่กลับไม่เห็นอีกสามส่วนที่เหลือ จึงคำนวณต้นทุนตามเวลาที่จะใช้ในส่วนที่ 3 เท่านั้น หารู้ไม่ว่าส่วนที่ 4 ก็ใหญ่พอๆกับ Programming เลย และยิ่งถ้าไม่ได้ออกแบบหรือวางแผนแล้วเริ่มลุยเลย ส่วนที่ 4 จะใหญ่กว่าส่วนที่ 3 เสียอีก และถ้าเลวร้ายก็อาจจะใหญ่กว่าเป็นสิบเท่าเลย และนี่เองคือ "ต้นทุนแฝง" ที่ทุกคนต้องเรียนรู้ไว้ว่ามันมีอยู่ ไม่ว่าจะเป็นนายจ้าง หรือโปรแกรมเมอร์เอง ซึ่งต้นทุนแฝงนี้ไม่ใช่เล่นๆ ไม่ใช่แค่เพิ่ม 10% หรือ 20% แต่การที่ไม่รู้ตรงนี้อาจจะทำให้เสียต้นทุนไปเกิน 500% หรือ 5 เท่าได้เลยนะ และโดยปกติงานพวกนี้ก็ไม่ได้กัน Margin ไว้สูงขนาดนั้น หรือง่ายๆก็คือ ขาดทุนนั่นเอง ...

ในงานปกติ ไม่มีทางเลยที่เขียนโปรแกรมครั้งแรกแล้วมันจะรันผ่านหรือใช้งานจริงได้ เมื่อเขียนเสร็จมันจะอุดมไปด้วยบั๊ก จำเป็นต้อง Test และนำผลกลับมาแก้ไข หรือบางทีก็ไม่ตรงกับ Requirement ก็ต้องรับมาแก้ไข เวลาที่ดีที่สุดในการ Balance Man-Hour ของส่วน (Programming) และ (Testing & Fixing) คือ 1:1 หรือ 1+:1 ถ้าเกินนั้นขอให้เรียกว่า "ล้มเหลว" ได้เลย

ฟังดู ​Make Sense นะ ... แต่เอาเข้าจริงโปรแกรมเมอร์ 90% เจอปัญหาว่า เวลาที่ใช้ Testing และ Fixing สูงกว่า Programming หลายเท่า เกิดจากสองปัจจัยหลักๆ

ปัจจัยแรกเป็นเรื่องของตัวโปรแกรมเมอร์เองที่ทำแบบลุยๆไป แล้วค่อยมาแก้ทีหลังละกัน ขาดการออกแบบและวางแผนก่อนเริ่มทำ ส่งผลให้โครงของโค้ดไม่ Flexible เพียงพอที่จะรับโค้ดที่ถูกสร้างขึ้นมาเพิ่มเรื่อยๆ ดั่งตอกเสาเข็มเล็กเท่าขา แต่จะสร้างตึก 50 ชั้น เมื่อสร้างได้ห้าชั้นมันก็พังครืนมาแล้ว ... ต้องเขียนใหม่แต่ต้น เกิดเป็นอีกขั้นตอนที่ไม่ควรจะเกิดขึ้นคือ (3.5) Rewrite หรือถ้าขาดการ Research ความเป็นไปได้ แล้วลุยดุ่ยๆไปเลย หากเขียนโปรแกรมไปได้ครึ่งนึงแล้วเพิ่งมาพบว่าติดปัญหาทางเทคนิค ไม่สามารถทำต่อได้ ก็ต้องทำใหม่อีกเช่น และเสียเวลา Programming ไปฟรีๆ ถ้าโชคดีหน่อย ทำไปแค่นิดเดียวแล้ว Rewrite ก็ดีไป แต่ถ้าทำไปจะเสร็จแล้วต้อง Rewrite เนี่ย ...​ ขอให้โชคดี

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

ด้วยเหตุฉะนี้โปรแกรมเมอร์ทั้งหลายจึงจำเป็นต้องศึกษา 2 ส่วนก่อนเริ่มต้นการเขียนโปรแกรม คือ Research และ Design

Research - โปรแกรมเมอร์ไม่ใช่พ่อมด ไม่ใช่ทุกสิ่งจะเสกให้เป็นไปได้หรอกนะในโลกนี้ บางอย่างมันก็เป็นไปไม่ได้ ให้ตายยังไงก็ทำไม่ได้ จงค้นคว้าหาความเป็นไปได้และความเหมาะสมของเทคโนโลยีที่จะใช้กับงานนั้นๆ ยกตัวอย่างเช่นมีงานโปรแกรมแต่งรูปมา ก็ต้อง Research ก่อนว่า Platform ที่จะทำนั้นมี Resource เพียงพอที่จะทำได้หรือเปล่า มีแรมเท่าไหร่ CPU ไหวมั้ย หรือใช้ GPU ในการช่วยแต่งภาพได้หรือเปล่า ฯลฯ หากยังศึกษาความเป็นไปได้ยังไม่ครบ อย่าเริ่มทำเป็นอันขาด ยกเว้นเป็นการเริ่มทำเพื่อทดลองหาความเป็นไปได้ เพราะสิ่งที่เป็นไปไม่ได้แค่อันเดียวก็ทำให้โปรเจคล่มได้แล้ว

Design - ดีไซน์ไม่ใช่การออกแบบทางด้าน UI หรือ UX แต่อย่างใด แต่เป็นการออกแบบในเชิงโปรแกรมมิ่ง รู้หรือไม่ว่าจริงๆการโค้ดดิ้งเป็นศิลปะแขนงหนึ่ง เป็นศิลปะที่ต้องแยกโค้ดให้ดูรู้เรื่อง มีโครงสร้างที่สวยงาม เพื่อให้สะดวกต่อการทำงาน เมื่อโปรแกรมเมอร์ได้โจทย์ของแอพฯหรือเว็บมา ก็ต้องมาย่อย Requirement ออกเป็นส่วนๆ แยกโค้ดเป็น MVC หรือแบบไหนก็แล้วแต่ตามที่สะดวกและเหมาะสม เพื่ออะไร? ประโยชน์ของการ Design โค้ดที่ดีคือ 1) สะดวกต่อการต่อเติม 2) การแยกโค้ดเป็นส่วนๆทำให้ทีมสามารถทำงานร่วมกันได้โดยไม่ต้องรอกัน 3) เมื่อมีการเปลี่ยนแปลงอะไรแบบไม่คาดฝัน โครงที่ดีต้องรองรับการเปลี่ยนแปลงได้ในระดับที่พอสมควร 4) ลดเวลาการ Fixing โค้ดในช่วงเทสต์

และบอกได้เลย การที่ไม่ได้ทำ Research และ Design ก่อนเริ่มโปรเจค จะเป็นปัจจัยหลักที่ทำให้เกิดปัญหาตามที่ได้พูดไว้ด้านบนนี้ทั้งหมด ไม่ว่าจะเป็น Testing & Fixing ไม่เสร็จสักที หรือต้อง Rewrite หรือปัญหาอีกมากมายที่ไม่ได้เมนชั่นไว้ตรงนี้ แต่สุดท้ายจะโยงไปยังปัญหาเดียวกันคือ "ต้นทุนแฝงสูงขึ้นหลายเท่า" และมันไม่ดีต่อธุรกิจคุณแน่นอนครับ

คนที่คิดจะแก้ปัญหาด้วยการชาร์จเงินเพิ่มจากระยะเวลา Testing และ Fixing ที่เพิ่มขึ้นถือเป็นวิธีที่ผิดอย่างมหันต์ เพราะต้นทุนที่เพิ่มขึ้นนี้ไม่ได้เกิดจาก Requirement หรือความผิดใดๆของคนจ้างทำ แต่เป็นความกากของตัวโปรแกรมเมอร์เอง โปรแกรมเมอร์ที่ดีจำต้องฝึกฝนพัฒนาความสามารถตรงนี้เพื่อลด Cost ของโปรเจคลง นี่คือวิธีแก้ปัญหาที่แท้จริงครับ และเป็นอีกเรื่องที่แยก "คนเขียนโปรแกรมได้" กับ "คนเขียนโปรแกรมเป็น" ออกจากกัน

แล้วการคิดเงิน man-hour ปกติควรจะคิดส่วนไหนบ้าง? ก็ตอบว่าควรจะคิด (Design + Programming) + (Testing & Fixing) โดยก้อนแรกจับรวม Design และ Programming เข้าด้วยกันเพราะความจริงมันเป็นส่วนเดียวกัน ส่วน Testing & Fixing ให้คิดเงินเพดานมากสุดเท่ากับเวลาที่ใช้ Programming หากใช้เวลาเกินนั้นโดยไม่มี Requirement ที่เปลี่ยนไป ถือเป็นความผิดของโปรแกรมเมอร์เอง ต้องรองรับค่าใช้จ่ายตรงนี้เอง

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

ทั้งหมดนี้ก็เป็นแค่ Case Study นึง เพื่อเป็น Guideline ให้เห็นคร่าวๆว่าถ้าจะเขียนแอพฯมือถือขึ้นมาสักโปรเจค ถ้าย่อยเป็นเวลาที่ใช้แล้ว จะประกอบด้วยส่วนไหนบ้าง เพื่อให้ง่ายต่อการตีเวลาที่ใช้และจะช่วยลดเวลาที่ใช้ด้วย แต่สุดท้ายชีวิตก็ไม่ได้มี Pattern เดียวหรอก ถ้าเป็นเว็บก็จะเป็นอีกรูปแบบนึง จะ Agile ได้ง่ายกว่านี้ เพราะเทคโนโลยีบนเว็บมัน Flexible กว่ามือถือมาก ยังมีอีกเยอะให้ศึกษาค้นคว้า ไว้จะยก Case Study อื่นมาให้ดูอีก

บทความนี้ Apply ไปทั้ง Waterfall, Agile, TDD ฯลฯ เพียงแต่ต้นทุนแฝงจากการไม่ออกแบบจะอยู่ที่ไหนใน 4 ข้อเท่านั้นเอง เช่นถ้าทำ TDD ก็จะลดต้นทุนการ Testing & Fixing ไปได้ระดับหนึ่ง (ละลายรวมไปกับ Programming) แต่หากไม่ Research และ Design ก่อน ก็เตรียมเขียนใหม่อยู่ดี ...

สวัสดีวันศุกร์จ๊ะ