ทำได้เร็ว

ทีมงานของเรา มักจะได้รับ Feedback ว่า "ทำงานเร็ว" เป็นสิ่งที่ผู้เขียนเองก็ภูมิใจอยู่เหมือนกัน อย่างเอนจิ้นที่ใช้รันเว็บนี้ ก็ใช้เวลาเขียนเพียง 3-4 วัน ก็อยู่ในระดับที่ เปิดใช้งานได้แล้ว (สามารถเช็คดูได้จาก History บน GitHub ได้)

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

สิ่งที่ควรจะตั้งคำถามขึ้นมาก่อนเลย คือ ทำไมเราจึงได้รับ Feedback ว่า ทำได้เร็ว

ความเร็วที่แท้จริง?

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

อย่างที่เกริ่นไปว่า ผู้เขียนพัฒนาระบบ Web Engine นี้ขึ้นมาในเวลาไม่กี่วันช่วงวันหยุด ถ้าถามว่า ทำไมถึงทำได้เร็วขนาดนั้น ก็อาจบอกได้ว่า ครั้งนี้ น่าจะเป็นครั้งที่ 5 หรือ 6 แล้ว ที่ผมลงมือสร้าง Web Engine ทำ CMS ใช้เองแบบนี้ 

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

อาจจะบอกได้ว่า เป็นเพราะประสบการณ์นั่นเอง จึงสามารถ ทำได้เร็ว ในมุมมองของลูกค้า

ข้อเสียของการ ทำได้เร็ว

สิ่งนี้ต้องบอกว่า เป็นเรื่องที่เจอกับตัวผู้เขียนบ่อยๆ

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

จึงไม่ใช่เรื่องแปลกอะไร ที่จะเกิดผลด้านลบ จากการที่ทำได้เร็ว 

• ไม่เชื่อว่า ทำงานเสร็จ ครอบคลุม - ด้วยความที่บางครั้ง ที่ทำออกมาได้เร็ว นั่นก็เพราะว่าเป็นการกินบุญเก่า เป็นอะไรที่เคย ทำมาแล้วบ่อยๆ หรือ เคยหาข้อมูลรอไว้แล้วพอดี พอทำอีก ก็รู้แล้วว่าต้องทำยังไง มันเลยเร็วมาก จนทีมอื่น หรือแม้แต่หัวหน้า หรือลูกค้าเอง ไม่ค่อยเชื่อ และเกิดการตั้งคำถามว่า มันเสร็จจริงใช่ไหม เก็บ Requirement ได้ครบไหม มันแค่ "Demo Quality" หรือเปล่า
• เกิดข้อกังขาในเรื่องคุณภาพของโค๊ด (เพราะว่า ทำได้เร็ว แปลว่ามันก็ใช้งานได้ด้วย) - "ทำเสร็จเร็วจริง แต่โค๊ดอ่านยาก" หรือ "เขียนอะไรไม่รู้มั่วไปหมด" เป็น Feedback เชิงลบ ที่ได้รับกลับมาบ้างเหมือนกัน แต่นำมาพิจารณาแล้ว ให้คะแนนตัวเองว่าไม่เป็นแบบนั้น
  
• เกิดการนั่งว่าง หรือ กลับได้งานรับผิดชอบเยอะขึ้น - เป็นเรื่องปกติที่ ทีมจะมีการประเมิน Resource Utilization หรือแพลนงานไว้ล่วงหน้า พอได้ผลงานเร็วเกินไป ก็ไม่มีงานให้ทำ และถ้าในทีมที่มีการบริหารจัดการที่ดี ผมก็จะมีโอกาสได้ไปเรียนรู้งานอย่างอื่นเพิ่มเติม เพิ่มอีก เลยกลายเป็น Loop เพราะต่อไป ก็จะทำได้เร็วขึ้นอีก

ทำอย่างไร จึงจะทำได้เร็ว?

ในมุมมองของการที่เคยเป็น Software Engineer และคนที่ทำธุรกิจ การที่จะทำงานออกมาได้เร็ว ผู้เขียนเสนอแนวคิด แบบนี้ครับ

• อย่ารับงานที่เราจะทำได้ช้า : เพราะว่าการที่งานออกมาเร็ว ไม่ได้มีแค่ตัวคนที่ลงมือเขียนโค๊ดเท่านั้น ส่วนประกอบ อื่นๆ ของโครงการ ก็คือตัวแปรสำคัญ ที่งานออกมาเร็วด้วยเหมือนกัน ก่อนจะรับงานอะไรมา เราก็ต้องพิจารณาจากความสามารถของทีมงาน และการให้ความร่วมมือของลูกค้าด้วย อยากให้ระลึกไว้ว่า สุขภาพ เวลา และอีกส่วนที่สำคัญก็คือเงินทุนสำรองเรานั้นมีจำกัด เราควรจะใช้มันกับสิ่งที่เกิดประโยชน์สูงสุดต่อทุกฝ่ายมากทีุ่สด
  
  ถึงตรงนี้ คุณก็อาจจะรู้สึกว่า ผู้เขียนจะโลกสวยไปหรือเปล่านะ หล่อเลือกงานได้ ซะขนาดนั้น อยากให้ดูอีกมุมเหมือนกันว่า การที่เราไม่มี Lead รอไว้ให้เลือกบ้างเลย ทำงานชนงานตลอด เราอาจจะต้องพิจารณาหา Business Development มาช่วยสร้าง Lead เพิ่ม หรืออาจต้องพิจารณาว่าเรายังสามารถมีกำไรอยู่รอดต่อไปได้จริงหรือเปล่า ก็ได้นะ
• อย่าทำให้เราทำงานช้า : ผมเชื่อว่า หลายๆ ท่านน่าจะเคยได้ยินแนวคิดสวยๆ เช่น SOLID, Dependency Injection (ที่ต้องมีเพราะ SOLID), State Management หรือ Design Pattern ที่ดูน่าสนใจ และพยายามเอามาปรับใช้งาน แต่ส่วนมากแล้ว แนวคิดสวยๆ พวกนี้ จะมาพร้อมกับ Boilerplate code คือ โค๊ดที่ไม่เกี่ยวกับความสามารถในการส่งมอบงานของระบบมาด้วย
  
  บางที แนวคิดที่เขานำเสนอให้เราฟัง หรือเราไปอ่านเจอแล้วดูว่ามันเจ๋งดี ก็เป็นแนวคิดที่เกิดจากข้อจำกัดของเทคโนโลยี หรือภาษาที่เขาใช้ ซึ่งอาจจะไม่มีความจำเป็นสำหรับใช้งานกับเทคโนโลยีหรือภาษาที่เราใช้ก็ได้ หรือมันอาจจะมีทางทำแบบเดียวกัน เพื่อจุดประสงค์เดียวกันได้ ในภาษา หรือเทคโนโลยีที่เราใช้ก็ได้  (ความเห็นส่วนตัวคือ แนวคิดเหล่านี้มักจะเกิดมาจากการใช้ JavaScript หรือ ภาษาบางภาษาที่ยังไม่ Mature) 
  
  ตรงนี้ หลายท่านอาจจะมีข้อโต้แย้งว่า เราใช้แนวคิดหรือหลักการเหล่านั้น ให้ผลงานออกมาดี ทดสอบง่าย แยกชิ้นทดสอบได้ Mock ได้ ซึ่งเป็นเรื่องที่จริงอยู่เหมือนกัน ดังนั้น จึงเป็นเรื่องของการ Balance ระหว่าง ทำได้เร็ว กับหลักการ หรือ Design Pattern ที่เราต้องการ หรืออยากใช้ พวกนี้ และมันต่อเนื่องถึงข้อถีดไปด้วย
  
• นึกถึง เวอร์ชั่นแรก ก่อนจะคิดไปเวอร์ชั่นต่อไป : ผมมองเห็นหลายท่าน ที่คิดถึงเรื่อง Extensibility คิดว่าตัองเผื่อต่อยอด ต้องรองรับการเปลี่ยนแปลงได้ ผมเห็นบางโปรเจคที่ได้มีโอกาสเข้าไปร่วมงานได้ สามารถ Configure ระบบบเป็นชิ้นๆ ได้เลย ทุกอย่างถูก Abstract เป็น Interface หมดอยากจะถอดเปลี่ยนอย่างไรก็ได้ แต่ก็หลายครั้งเหมือนกัน ที่โปรเจคโครงสร้างสวยงามนี้ ก็ไม่เคยถูก Configure หรือมีแค่ Class เดียว ที่ Implement ทุก Interface หรือไม่เคยถูกเขียน Unit Test เพื่อที่จะได้ใช้การแยกชิ้นเหล่านั้นให้เกิดประโยชน์ ที่น่าเศร้ากว่า คือบางครั้งตัวระบบสวยงามนี้ กลับไม่ได้ถูก Release ออกมาให้สร้างรายได้ เพื่อเอาทุนจากการสร้างคืนมาอีกต่างหาก
  
  ในมุมมองของผู้เขียนนั้น การที่เราได้มีโอกาสจะเปลี่ยนสิ่งที่เราเขียน นั่นก็คือ ได้รับการต่อสัญญา MA หรือได้รับการจ้างงานให้ปรับปรุงมันต่อ ถือเป็นเรื่องที่น่ายินดีที่สุด แต่ถ้าจะให้เกิดเหตุการณ์นี้ได้ ก็จะต้องมีเวอร์ชั้นแรก ที่ดี มีคุณภาพ และทันเวลา รวมถึงสามารถนำให้ลูกค้าเอาไปสร้างรายได้ ออกมาให้ได้เสียก่อน เพื่อจะมีงบประมาณมาจ้างเราต่อ
  
  ขอลองให้คิดมุมนี้บ้างว่า ไม่ว่าเราจะใช้การออกแบบดี หรือไม่ดี แค่ไหน ก็จะเกิดเป็น Technical Debt รูปแบบใดรูปแบบหนึ่งขึ้นมา ดังนั้น ถ้าจะใช้หนี้ (Debt) ได้ ก็ต้องมี Revenue มาเสียก่อนนะ
  
• เน้นที่ผลลัพธ์ ที่จับต้องได้ และ จัดลำดับความสำคัญ : อีก Pattern ที่ผู้เขียนพบ ก็คือ มีหลายทีม ที่ทำงานไปตาม User Journey หรือ Screen flow อย่างเดียว โดยไม่ได้คำนึงถึงความสำคัญที่แท้จริงที่โครงการนั้นคาดหวังไว้
  
  สิ่งที่เห็นได้บ่อยมาก ก็คือ ทีมไปให้ความสำคัญกับการ Login หรือ การจัดการ User ก่อน เป็นอันดับแรก เพราะมันดันมักจะเป็นหน้าแรกของ Flow การใช้งาน แต่ที่จริงแล้ว ลูกค้าอยากเห็น Return on Investment ของเขา หรือก็คือส่วนที่สามารถสร้างรายได้ของตัวโครงการ มากที่สุด ดังนั้น ถ้าเราสามารถส่งส่วนที่เป็น Value นี้ได้ก่อน ในความรู้สึกของเจ้าของเงินและเวลา ก็จะรู้สึกพอใจมากกว่า เหมือนว่า ได้ของเร็ว
• เข้าใจเรื่องการลงทุน : ส่วนมากแล้ว ในบริษัทใหญ่ๆ มักจะมีขั้นตอนยุ่งยาก ในการขอ Server ขอ Cloud ขอพื้นที่ติดตั้งระบบของเรา และมันมักจะกลายเป็น blocker ของงานที่เราจะต้องส่งมอบ ถ้าเราจะเก็บเงินได้ มีผลงานออกมาเร็ว ก็ต้องมีงบประมาณเพื่อลงทุนเผื่อไว้บ้าง
  
  สิ่งที่ผู้เขียนคิดว่า มีส่วนสำคัญมากต่อการส่งมอบงาน คือ ทีมของเรา ควรจะมี Environment ของตัวเองภายใน เพื่อใช้ในการติดตั้งระบบไปพร้อมกันเลย ระหว่างการพัฒนา  ยิ่งมี CI/CD Pipeline เซ็ตไว้ด้วย จะยิ่งดีมาก และใช้ Test Environment นี้เอง เป็นพื้นที่ เพื่อแสดง Demo นอกจากนี้ การได้ Deploy บ่อยๆ ก็ช่วยเพิ่มความมั่นใจว่า ตอนที่ส่งมอบ final จริงๆ ทุกอย่างจะราบรื่นอีกด้วย
  
  สำหรับท่านที่อยู่ในบทบาทของพนักงาน การมี Server ของตัวเองไว้ เพื่อใช้ สำหรับ "โชว์ผลงาน" ยิ่งเป็นเรื่องที่ควรพิจารณามีไว้อย่างมาก เดี๋ยวนี้ด้วยบริการที่ฟรีอย่าง CloudFlare Tunnel (Argo Tunnel), Ngrok หรือ Dynamic DNS ต่างๆ เราก็สามารถมีเครื่องเล็กๆ สักเครื่อง เป็น Server ในบ้านได้แบบไม่ลำบากเลย และเป็นการขยายความเข้าใจของเรา ไปถึงเรื่อง Infrastructure ด้วย

เร็วแล้วอย่าหยุดเร่ง

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

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

หวังว่าบทความนี้จะเป็นประโยชน์ พบกันอีกครั้ง โอกาสต่อไปครับ