- การทำ โปรเจ็กต์เทคนิคขนาดใหญ่ ให้รักษาแรงจูงใจและทำจนจบได้ จำเป็นต้องมี ผลลัพธ์ที่มองเห็นได้ ในชีวิตประจำวัน
- ผมเลือกแยกโปรเจ็กต์ออกเป็น หน่วยเล็ก ๆ ที่มองเห็นได้ แทนที่จะเป็นงานก้อนใหญ่ที่คลุมเครือ และในแต่ละขั้นต้องมีวิธีตรวจสอบความคืบหน้าที่จับต้องได้
- ในช่วงเริ่มต้น การทำเดโมให้ได้เร็วด้วย วงจรฟีดแบ็ก ที่กระชับ ช่วยให้จดจ่อและสร้างแรงขับให้ตัวเองได้มาก
- การพัฒนาโดยเริ่มจากฟีเจอร์ที่จำเป็นสำหรับตัวเองก่อน แล้วค่อยปรับปรุงต่อผ่าน การใช้งานจริง เป็นวิธีที่ได้ผล
- ให้ความสำคัญกับความก้าวหน้ามากกว่าความสมบูรณ์แบบ และการได้ ประสบการณ์ความสำเร็จเล็ก ๆ ซ้ำ ๆ คือสิ่งที่พาไปสู่การทำโปรเจ็กต์ยาว ๆ จนจบ
ที่จุดเริ่มต้น
- เวลาจะเริ่มโปรเจ็กต์ขนาดใหญ่ อุปสรรคใหญ่ที่สุดคือการตัดสินใจว่า จะเริ่มจากตรงไหน
- ถ้าพยายามคิดทุกองค์ประกอบพร้อมกัน ความสนใจมักหายไปได้ง่ายเพราะมันคลุมเครือเกินไป
- สิ่งสำคัญคือเริ่มจาก หน่วยเล็ก ๆ ที่เห็นผลได้เร็ว ก่อน
- แต่ละซับโปรเจ็กต์ควรเป็นอิสระจากกัน และต้องมี สัญญาณของความเสร็จสมบูรณ์ ที่ชัดเจน
- ยิ่งมีประสบการณ์มาก ก็ยิ่งมองเห็น ภาพรวมและซับคอมโพเนนต์ ของโปรเจ็กต์ได้ดีขึ้น
การสร้างผลลัพธ์ตั้งแต่ช่วงแรก
- งานช่วงแรกอาจ มีส่วนที่มองเห็นจากภายนอกน้อย จนทำให้ดูเหมือนไม่คืบหน้า
- ในกรณีแบบนี้ การใช้ การทดสอบอัตโนมัติ (เช่น unit test) อย่างเหมาะสมเพื่อสร้างผลลัพธ์ที่มองเห็นได้เป็นเรื่องสำคัญ
- ตัวอย่างเช่น เวลาสร้าง terminal parser ก็ตรวจผลลัพธ์การพาร์สจากสตริงอินพุตได้ทันทีผ่านเทสต์
- การได้ เห็นเทสต์ผ่านซ้ำ ๆ เองก็สร้างความรู้สึกสำเร็จได้
- ความสำเร็จเล็ก ๆ เหล่านี้ช่วยสะสม หลักฐานเชิงวัตถุวิสัย ว่าโปรเจ็กต์ทั้งหมดยังคืบหน้าอยู่
ทำเดโมให้เร็ว
- เป้าหมายในช่วงแรกไม่ใช่ ซับคอมโพเนนต์ที่สมบูรณ์แบบ แต่คือ การทำให้พอสำหรับเดโม
- ความซับซ้อนที่จำเป็นในระยะยาว (เช่น ฐานข้อมูล, โครงสร้างข้อมูลขั้นสูง ฯลฯ) ให้พักไว้ก่อน และให้ความสำคัญสูงสุดกับ การทำแบบง่าย ๆ เพื่อเดินหน้าให้เร็ว
- ควรจำไว้เสมอว่า 'ความสมบูรณ์แบบอาจกลายเป็นศัตรูของความก้าวหน้า'
- ตั้งเป้าทำ เดโมแบบง่าย ๆ สัปดาห์ละหนึ่งหรือสองครั้ง
- ถึงจะเป็นเดโมที่ยังไม่สมบูรณ์ ก็ยังช่วยให้ตรวจดูได้ด้วยตัวเองและรับ ฟีดแบ็กเชิงสัญชาตญาณ ซึ่งช่วยเรื่องแรงจูงใจอย่างมาก
พัฒนาเพื่อตัวเอง
- โดยเฉพาะใน โปรเจ็กต์ส่วนตัว ควรเริ่มจากฟีเจอร์ที่ตัวเองต้องใช้ก่อน และให้ความสำคัญกับกระบวนการ นำมาใช้เองจริง
- เมื่อได้ใช้งานโดยตรง จะสัมผัสจุดที่ยังขาดได้ชัดขึ้น และสามารถปรับปรุงโดย โฟกัสกับฟีเจอร์ที่จำเป็นจริง ๆ พร้อมพัฒนาโปรเจ็กต์จากมุมมองของผู้ใช้จริง
- ในช่วงแรกของการใช้งาน ความไม่สะดวกหรือบั๊กจะเริ่มปรากฏ แต่สิ่งเหล่านี้เองที่บอกได้ชัดว่าควรทำอะไรต่อ
- ความ ภูมิใจ ที่ได้ใช้งานซอฟต์แวร์ที่ตัวเองเขียนขึ้นมา เป็นปัจจัยที่ช่วยให้ทำโปรเจ็กต์ต่อเนื่องได้
- ตอนแรกผมตัดฟีเจอร์ที่ยังไม่จำเป็นทั้งหมดออกไป (scroll, การเลือกด้วยเมาส์, tab ฯลฯ)
วิธีแพ็กเกจภาพรวมของโปรเจ็กต์
- แยก ปัญหาใหญ่ทั้งก้อนออกเป็นปัญหาเล็ก ๆ ที่มองเห็นได้ โดยแต่ละปัญหาต้องสามารถตรวจสอบผลลัพธ์ที่จับต้องได้
- แต่ละปัญหาเล็กให้แก้เพียง ในระดับที่พอสำหรับการทำเดโม แล้วค่อยไปยังปัญหาถัดไป
- ทำ เดโมที่ใช้งานได้จริง ให้เร็วที่สุด แล้วค่อยเพิ่มฟีเจอร์แบบวนซ้ำหลังจากนั้น
- ให้ความสำคัญก่อนกับ ฟีเจอร์ที่มีความหมายต่อการใช้งานของตัวเอง
- หากจำเป็น ก็ค่อยปรับปรุงแต่ละคอมโพเนนต์แบบวนซ้ำ และหมุนกระบวนการนี้ต่อไป
บทสรุป
- ด้วยวิธีนี้ ผมสามารถ สร้างแรงจูงใจให้ตัวเอง และทำโปรเจ็กต์หลากหลายรูปแบบให้จบได้ ไม่ว่าจะเป็นงานส่วนตัว งานกลุ่ม งานอาชีพ หรือการเรียน
- จุดสนใจไม่ใช่เรื่อง การ deploy หรือ tooling แต่คือวิธีการที่ทำให้รักษาแรงจูงใจได้อย่างต่อเนื่องในทางปฏิบัติ
- แม้วิธีเดียวกันจะใช้ไม่ได้กับทุกคน แต่ ผลลัพธ์ความคืบหน้าที่มองเห็นได้ คือแรงผลักสำคัญที่สุดในการพาโปรเจ็กต์ระยะยาวไปจนจบ
- สิ่งสำคัญคือการเข้าใจความสนใจและรูปแบบแรงจูงใจของตัวเอง แล้วสร้าง กระบวนการทำงาน ที่เหมาะกับสิ่งนั้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เห็นด้วยกับทุกความเห็นที่เสนอไว้ในบทความ และอยากเสริมอีกข้อหนึ่ง: ความสำคัญของวงจรป้อนกลับที่รวดเร็ว
ถ้าคุณเปลี่ยนอะไรบางอย่างแล้วเห็นผลทันที มันสร้างแรงจูงใจได้มาก
พอลองแก้โค้ดแบบสนุก ๆ แล้วคอยสังเกตผล ก็จะพบว่าปัญหาหลายอย่างหายไปหรือเปลี่ยนเป็นรูปแบบที่แก้ง่ายขึ้น
ในโปรเจ็กต์ขนาดใหญ่ ความง่ายในการตั้งค่าและรันมีความสัมพันธ์ชัดเจนกับปริมาณปัญหาในโปรเจ็กต์นั้น ๆ (บั๊ก ส่งงานไม่ทัน ฯลฯ)
บรรยายนี้พูดถึงวงจรป้อนกลับ
ลิงก์ YouTube
กำลังคิดว่าจะใส่ e2e test สำหรับบั๊กที่เจอ เพื่อยืนยันว่าแก้หายแล้วจริง ๆ
เวลาที่อยากลองหรืออยากแก้อะไรสักอย่าง แต่แค่การเซ็ตอัปเองก็กินเวลาไปหลายชั่วโมง แรงใจก็หายและสุดท้ายก็ผัดวันไป
เพราะแบบนี้ฉันเลยชอบภาษาที่มี REPL ใช้งานดี ๆ อย่าง lisp
มันให้ความพึงพอใจแบบทันทีทันใด เพราะเห็นผลได้เลยตรงนั้น
พอเสียแรงจูงใจเมื่อไร โปรเจ็กต์นั้นก็สลายหายไปเลย
เพราะงั้นการทำให้การพัฒนาเป็นประสบการณ์ที่สนุกจึงแทบจะเป็นปัจจัยที่สำคัญที่สุด
มองว่าบางทีประสบการณ์กลับกลายเป็นตัวถ่วง
เห็นวิศวกรอาวุโสจำนวนมากจมลึกกับการทำให้ทุกอย่างสมบูรณ์แบบ แต่พอถึงเวลาจะเดโม ผลลัพธ์กลับไม่น่าประทับใจ
ถึง implementation จะทำได้ดี แต่ฟีเจอร์หรือสินค้าตัวนั้นกลับไม่น่าสนใจเอาเสียเลย
บางทีก็อยากปิดสมองแล้วเขียนโค้ดกาก ๆ แบบไม่คิดมาก
เมื่อก่อนเคยทำโปรเจ็กต์เล่น ๆ เยอะมาก และบางทีก็ยัด source code ทั้งหมดไว้ในไฟล์เดียว
ไม่สน modularization อะไรทั้งนั้น แต่ก็สนุกและมันก็ทำงานได้
แต่ตอนนี้แค่จะทำโปรเจ็กต์เล่น ๆ ให้เสร็จสักอันกลับยากมาก
เพราะเคยทำมาแล้วครั้งหนึ่ง ก็เลยมีแนวโน้มจะยัดฟีเจอร์ส่วนเกินที่ไม่จำเป็นเข้าไปหมด
เช่น เข้าร่วม coding challenge อย่าง Advent of Code พอทำไปจะเห็นว่าช่วงแรก ๆ ปัญหาง่าย และจะต้องใช้การ optimize หรืออัลกอริทึมซับซ้อนจริง ๆ แค่ช่วงหลัง
หรือใช้สภาพแวดล้อมที่จำกัดอย่าง pico-8 ซึ่งทำให้โค้ดแบบยืดยาวไม่ได้
หรือจะลองในสภาพแวดล้อมที่มีเวลาจำกัดอย่าง hackathon หรือ game jam ก็ช่วยได้
เพราะคนที่ยังมีประสบการณ์ไม่มากสามารถลืม 'best practices' ที่น่าเบื่อจากภาษาเก่า ๆ ไป แล้วลองอะไรใหม่ ๆ ได้อย่างอิสระ
ฉันออกแบบตาราง DB เอง แล้วปล่อยให้ LLM รับช่วง implementation ไปแบบค่อนข้างอิสระ
ชอบประเด็นที่ว่า เป้าหมายของ sub-project ระยะแรกไม่ใช่การสร้าง 'sub-component ที่เสร็จสมบูรณ์' แต่คือการสร้าง sub-component ที่ 'ดีพอ' ให้ขยับไปขั้นถัดไปได้
พอจะทำแบบนี้จริงก็ต้องตระหนักว่าคุณจำเป็นต้อง 'ละบางอย่างออก'
คนอื่นพูดถึงการละเลยการ modularize โค้ดในโหมดนี้ แต่สำหรับฉัน การจัดโค้ดให้เรียบร้อยกลับเป็นสิ่งที่ให้ทั้งความพอใจและแรงจูงใจ
เพราะงั้นสิ่งที่ฉันจะ 'ละ' คือเรื่องอัลกอริทึม โครงสร้างข้อมูล และประสิทธิภาพ
สรุปคือ ต้องมีบางอย่างที่ข้ามไปแน่ ๆ แต่ถ้าสิ่งนั้นเป็นองค์ประกอบที่ให้แรงจูงใจกับตัวเรา ก็ไม่ควรละมันทิ้ง
เดโมทำหน้าที่เป็นขั้นกลางระหว่างการพัฒนาซอฟต์แวร์ (programming) กับการอธิบายเป็นลายลักษณ์อักษร (documentation)
ผ่านเดโม เราสามารถตรวจสอบสมมติฐานของตัวเองได้ต่อเนื่องว่าโปรเจ็กต์นี้ควรทำอะไร และมันก็กลายเป็นกลไกป้อนกลับอย่างหนึ่ง
เดโมคงอยู่ได้นาน ทำให้เมื่อมีการทำฟีเจอร์พัง ก็ตรวจพบและวนลูปแก้ไขต่อได้ทันที
ฉันกำลังทำงานกับ game engine ที่พัฒนาเองในลักษณะนี้
ลิงก์ GitHub ตัวอย่างเดโม
อยากให้วิธีคิดแบบนี้กลายเป็นสามัญสำนึกทั่วไป
ให้ความรู้สึกว่าโฟกัสไปที่โปรเจ็กต์ส่วนตัว
ฉันสนใจว่ามีวิธีที่ดีอย่างไรในการทำโปรเจ็กต์ทีมเชิงเทคนิคขนาดใหญ่ ที่ทุกคนทำงานไปในทิศทางเดียวกันและปิดงานกันได้อย่างเหมาะสม
ทำงานมาเกือบ 15 ปีแล้ว ยังไม่เคยเห็นโปรเจ็กต์เทคนิคที่ไม่มีงบบานปลาย ส่งช้า ฟีเจอร์ไม่ครบ หรือ burnout เลย
ในทางกลับกัน ถ้าใครมีกรณีศึกษาของโปรเจ็กต์ใหญ่ที่พาไปได้สวยจริง ๆ ก็อยากให้แชร์ลิงก์หรือแหล่งอ่านเพิ่มเติม
งบบานปลายเป็นเรื่องที่เกิดขึ้นบ่อย ตราบใดที่เงินยังไม่หมดจริง
ส่วนใหญ่ก็แค่มีใครสักคนบ่นว่าประมาณการพลาด
เรื่องกำหนดการก็เหมือนกัน ถ้าไม่ใช่เดดไลน์ที่จำเป็นต้องรักษาจริง ๆ ก็ไม่ใช่ปัญหาร้ายแรง
อันที่จริง เหตุการณ์ที่ต้องผูกกับตารางเวลา เช่นแคมเปญโปรโมตใหญ่ ๆ ควรถูกวางแผนก็ต่อเมื่อโปรเจ็กต์ใกล้เสร็จมากแล้ว
ส่วนฟีเจอร์ไม่ครบก็สุดท้ายขึ้นอยู่กับความคาดหวัง
ปัญหาที่แท้จริงคือ 'การสูบพลังจนคนหมดไฟกันไปหมด'
อย่างน้อยเรื่องนี้เป็นสิ่งที่ต้องพยายามหลีกเลี่ยงให้ได้แน่ ๆ
ส่วนตัวฉันเริ่มชอบ Scaled Agile Framework มากขึ้นเรื่อย ๆ
ฉันใช้มันเป็น framework หรือก็คือเป็นเหมือน 'หุ่นฟาง' ที่เอาไว้ดัดแปลงตามสถานการณ์
มันช่วยให้ฉันไปสำรวจต้นฉบับที่ลึกกว่านั้นและสรุปข้อคิดด้วยตัวเอง
ฉันได้เรียนรู้ว่าความสำเร็จที่แท้จริงเริ่มจาก 'การเข้าใจให้ชัดว่าทำไมเราถึงสร้างสิ่งนี้'
ถ้าเป้าหมายไม่ชัด คุณจะจัดลำดับความสำคัญไม่ได้ และไม่รู้ด้วยซ้ำว่าควรเริ่มตรงไหน
ความชัดเจนแบบนี้ช่วยมากกับการตัดสินใจว่า 'จะสร้างอะไร เมื่อไร' และบางครั้งก็ทำให้ตัดสินใจได้ด้วยว่า 'ไม่ต้องสร้างเลย'
สิ่งสำคัญถัดมาคือ 'ความเห็นอกเห็นใจ'
คุณต้องเข้าใจปัญหาของลูกค้าจากมุมของเขาอย่างแท้จริง และนำเสนอทางแก้ที่ตอบโจทย์
ไม่ใช่แค่ทำทุกอย่างที่ลูกค้าขอ แต่ต้องเข้าใจความเจ็บปวดหลักให้แม่น แล้วส่งมอบสิ่งที่มีคุณค่าจริง
เหตุผลแท้จริงที่โปรเจ็กต์ส่วนใหญ่ล้มเหลว คือทีมใช้เวลาไปมากเกินไปกับการสร้าง 'สิ่งที่ผิด'
ถ้ามุ่งไปที่สิ่งที่จำเป็นจริง ๆ อย่างต่อเนื่อง คือฟีเจอร์ที่คนต้องการจริงหรือมีคุณค่าพอจะยอมจ่าย โอกาสที่โปรเจ็กต์จะสำเร็จก็จะสูงขึ้นมาก
มีคนมากมายที่มองโปรเจ็กต์ใหญ่แล้วติดอยู่ในภาวะวิเคราะห์จนไปต่อไม่ได้
สิ่งที่ยากจริง ๆ คือการทำให้จบ
ถ้าคุณสร้างซอฟต์แวร์ที่ตัวเองจะใช้ คุณก็แก้ปัญหาของตัวเองได้
และเพราะคุณใช้งานมันเอง คุณก็จะเจอบั๊กของซอฟต์แวร์ได้ด้วย
ฉันเคยเจอบั๊กหลายตัวจากการสร้างและใช้งานเว็บเซิร์ฟเวอร์ด้วยตัวเองจริง ๆ
เป็นวัฒนธรรมการพัฒนาที่มีสมาธิ ทำซ้ำได้ และมุ่งไปที่ผลลัพธ์ที่ใช้งานได้เสมอ