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

อาการเหล่านี้มีคำอธิบายอยู่ในบทความของ Sean Goedecke คนเขียนบล็อกเรื่องงานสายซอฟต์แวร์ บทความชื่อ «กัดฟันแล้วส่งมันออกไป» ของเขาเปิดเรื่องไว้ว่า "ทักษะการสร้างงานกับทักษะการส่งงานเป็นคนละเรื่องกัน และในระยะสั้น สองทักษะนี้สวนทางกันด้วย คนที่มีพรสวรรค์ในการสร้างงาน มีแนวโน้มจะส่งงานได้แย่กว่า"

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

รสนิยมมาก่อนฝีมือ

บทความยกคำพูดคลาสสิกของ Ira Glass มาอธิบายเรื่องนี้ไว้ว่า

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

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

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

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

นิสัยที่ทำให้เก่ง คือนิสัยที่ทำให้ไม่ยอมส่งงาน

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

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

ถ้านั่งเขียนโค้ดอยู่คนเดียว นิสัยแบบนี้แค่น่ารำคาญ แต่ถ้าทำงานในบริษัทเทคโนโลยี นิสัยนี้คือหายนะ เพราะระบบซอฟต์แวร์ขนาดใหญ่ทุกแห่งล้วนเต็มไปด้วยจุดบกพร่อง บางจุดเกิดจากเวลาที่กระชั้นชิด บางจุดเกิดจากคนเขียนโค้ดยังมีประสบการณ์น้อย หรือบางจุดก็เกิดจากฟีเจอร์ประเภทที่ผู้เขียนบทความเรียกว่า wicked features การทำงานกับระบบขนาดใหญ่จึงต้องยอมประนีประนอม คือหาทางออกที่ดีที่สุดเท่าที่จะทำได้ ภายใต้ข้อจำกัดและความไม่สมบูรณ์แบบที่มีอยู่เดิมใน codebase

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

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

หนีไปเกลาเรื่องเล็ก แทนที่จะส่งงานจริง

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

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

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

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

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

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

เรามองว่าหลักการนี้ใช้ได้กับงานสร้างสรรค์แบบอื่นด้วย ร่างบทความที่ยังเขียนได้ไม่ดี เรายังนำมาขัดเกลาต่อได้ งานออกแบบที่ยังไม่ลงตัว เรายังนำมาปรับแก้ต่อได้ แต่งานที่ไม่เคยส่งออกไปเลย ไม่มีอะไรให้ปรับแก้ต่อ

ความรู้สึกตอนเขียนเชื่อถือไม่ได้

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

บทความที่เขาเขียนร่างเสร็จมากกว่าครึ่ง พออ่านทบทวนแล้วเขากลับรู้สึกว่ายังไม่ดีพอ แต่ส่วนใหญ่แล้วเขาก็ยังกัดฟันกดเผยแพร่อยู่ดี เพราะเขาถือว่าต้องเน้นส่งงานไว้ก่อน

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

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

ชิ้นที่ไม่ชอบตอนเขียน แต่คนอ่านชอบ

• ทำสิ่งที่ง่ายที่สุดที่น่าจะใช้ได้ (Do the simplest thing that could possibly work)
• งานวิศวกรรมซอฟต์แวร์อาจไม่ใช่อาชีพตลอดชีวิตอีกต่อไป (Software engineering may no longer be a lifetime career)
• วิศวกรซอฟต์แวร์ควรมองโลกในแง่ร้ายไว้บ้าง (Software engineers should be a little bit cynical)

ชิ้นที่คิดว่าดี แต่ผลตอบรับกลับเงียบ

• หัวหน้าทีมวิศวกรที่อ่อนแอ (Weak engineering managers)
• เส้นทางท่ามกลางทางออกที่เป็นไปได้ทั้งหมด (Paths through the space of all possible solutions)
• การพยายามสร้างความประทับใจให้คนที่เราไม่ได้นับถือ (Trying to impress people you don't respect)

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

ในเมื่อคาดเดาไม่ได้ ก็ต้องเน้นทำให้เยอะ

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

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

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

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

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

5 ข้อที่นำไปใช้กับงานที่ค้างอยู่ได้ทันที

จากบทความของเขา เราสรุปออกมาเป็น 5 ข้อปฏิบัติที่คุณนำไปใช้กับงานที่กำลังค้างอยู่ได้ทันที ไม่ว่าจะงานเขียนโค้ด งานเขียนบทความ หรืองานออกแบบ:

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

ชื่อบทความของเขาคือคำตอบในประโยคเดียว ต้องกัดฟัน แล้วส่งมันออกไป

งานที่ส่งแล้วแย่ยังแก้ได้ งานที่ไม่เคยส่งไม่มีใครได้ใช้

แล้วตอนนี้ คุณมีงานชิ้นไหนที่ทำเสร็จแล้ว แต่ยังไม่กล้ากดส่งอยู่บ้างหรือเปล่า?

---

ที่มา: บทความ Grit your teeth and ship it จาก Sean Goedecke