การแตกงาน
(jacobian.org)- การประเมินโปรเจกต์หรือการมอบหมายงานเริ่มต้นจากการเปลี่ยนคำขอขนาดใหญ่อย่าง “สร้างสิ่งนี้” ให้เป็น รายการงานที่ชัดเจน โดยแต่ละรายการต้องบอกให้เห็นการเปลี่ยนแปลงที่ต้องการและสภาพเมื่อทำเสร็จแล้ว
- กระบวนการแตกงานคือการจดขั้นตอนที่จำเป็นจากไอเดีย สเก็ตช์ หรือรายการเริ่มต้น แล้ว แยกย่อยแบบเวียนซ้ำ จนกว่าแต่ละรายการจะถูกนิยามได้ชัดเจนพอ
- ตัวอย่าง streak tracker สำหรับกิจกรรมกลางแจ้งค่อย ๆ ถูกแยกออกเป็น data model, มุมมองปฏิทิน, การบันทึกกิจกรรม, การคำนวณ streak และ streak freeze พร้อมเผยให้เห็นจุดที่ยังไม่แน่ชัดไปด้วย
- “งานที่ถูกนิยามชัดเจนพอ” คือสถานะที่สามารถตอบ ใช่ ได้กับคำถามว่ารู้การเปลี่ยนแปลงที่ต้องการ รู้ว่าความเสร็จสมบูรณ์หน้าตาเป็นอย่างไร รู้ทุกขั้นตอนจนเสร็จ และมีข้อมูลพอจะเริ่มได้ทันที
- การแตกงานเป็นทักษะที่ต้องอาศัย pattern matching จากประสบการณ์ ดังนั้นทีมมือใหม่จึงต้องมีโอกาสฝึกวางแผนและรับฟีดแบ็กในสภาพแวดล้อมที่ปลอดภัย
เปลี่ยนโปรเจกต์ใหญ่ให้เป็นรายการงาน
- การพูดคุยเรื่องการประเมินโปรเจกต์ก่อนหน้านี้มักสมมติว่ามี รายการงานที่ชัดเจน อยู่แล้ว แต่ในงานจริงอาจต้องมีขั้นตอนก่อนหน้านั้นคือการแตกงานก่อน
- การแตกงานคือกระบวนการแบ่งโปรเจกต์ใหญ่ให้เป็นงานย่อย และถ้าจะประเมินหรือนำไปมอบหมาย เราต้องมีหน่วยงานที่ละเอียดกว่างานเดียวอย่าง “ทำภาพนี้ขึ้นมา”
- ถ้าเป็นโปรเจกต์ส่วนตัวที่ทำคนเดียว แค่สเก็ตช์ก็อาจพอแล้ว แต่ถ้าจะให้คนอื่นทำต่อหรือจะประเมินระยะเวลา ก็ต้องเพิ่ม ความละเอียด ให้มากขึ้น
ตัวอย่าง: streak tracker ส่วนตัว
- ใช้ streak tracker ส่วนตัวสำหรับติดตามวันที่ทำกิจกรรมกลางแจ้งเป็นตัวอย่าง
- ต้องการรูปแบบคล้ายแอป Streaks
- อยากมีตัวเลือกกิจกรรมกลางแจ้ง เช่น วิ่ง ปั่นจักรยาน เล่นสกี
- ต้องการรวม ฟังก์ชัน streak freeze ของ Duolingo ด้วย
-
รอบแรก: เริ่มจากสเก็ตช์
- visual mockup เป็นจุดเริ่มต้นที่ดีเพราะช่วยให้เข้าใจฟีเจอร์ที่จะสร้างได้ง่าย
- ถ้าเป็นโปรเจกต์ที่ทำคนเดียว แค่สเก็ตช์ระดับนี้ก็อาจเริ่มเขียนโค้ดได้เลย
- แต่ถ้าจุดประสงค์คือการประเมินหรือมอบหมายงาน ก็ต้องมีรายการงานที่ละเอียดกว่าคำว่า “สร้างภาพนี้”
-
รอบที่สอง: แยกเป็นฟีเจอร์ใหญ่
- การแตกครั้งแรกคือแบ่งโปรเจกต์ออกเป็นองค์ประกอบหลักแบบคร่าว ๆ
- การทำ data modeling
- มุมมองปฏิทินที่แสดงวันที่ของสัปดาห์ปัจจุบัน
- ปฏิทินแบบโต้ตอบที่คลิกไอคอนเพื่อบันทึกกิจกรรมและทำเครื่องหมายว่าวันนั้นเสร็จแล้วในตัวติดตาม streak
- การคำนวณและแสดงความยาวของ streak ปัจจุบัน
- การทำ streak freeze
- เพื่อให้ตัวอย่างง่ายขึ้น จึงไม่นับงานเชิงปฏิบัติการอย่างการ deploy หรือการตั้งค่าฐานข้อมูล
- ในโปรเจกต์จริง โดยเฉพาะโปรเจกต์ที่มีหลายคนร่วมงาน มักเหมาะกว่าหากแยกงาน deploy, frontend, backend เป็นคนละรายการ
- แค่ระดับนี้ก็พอประเมินได้บ้างแล้ว แต่ยังมี ความไม่แน่นอน เหลืออยู่ เช่น วิธีสะสมและติดตาม freeze, การแก้ไขข้อมูลย้อนหลัง, การเพิ่มหรือลบประเภทกิจกรรม
-
รอบที่สาม: แยกต่อจนเห็นเกณฑ์ความเสร็จ
- data model แบ่งออกเป็นประเภทกิจกรรม, กิจกรรมที่บันทึกไว้, freeze และ streak
- ประเภทกิจกรรมอาจพอใช้เป็นรายการ hardcode เช่น run/bike/ski/climb
- กิจกรรมที่บันทึกไว้มีวันที่และประเภท
- freeze มีวันที่ได้รับและวันที่ใช้งาน
- streak มีวันเริ่ม วันสิ้นสุด และข้อมูลสรุปแยกตามประเภทกิจกรรม
- มุมมองปฏิทินแบบคงที่แบ่งเป็นมุมมองรายสัปดาห์, หน้าหลัก, มุมมองรายเดือน, การนำทาง และช่องป้อนเพื่อย้ายวันที่
- การย้ายวันที่สามารถใช้ widget วันที่ของ HTML5 ได้ โดยไม่ต้องมี fuzzy date input ที่ซับซ้อน
- ปฏิทินรายสัปดาห์แบบ dynamic จะไม่ใส่อินพุตแบบ dynamic ลงในมุมมองรายเดือน แต่บันทึกสถานะเสร็จผ่านการคลิกประเภทกิจกรรมของวันที่ที่กำหนด
- การคำนวณและแสดง streak คือการไล่ดูบันทึกกิจกรรมเพื่อคำนวณ streak, แสดง streak ปัจจุบันใน UI และคำนวณ streak ใหม่เมื่อมีการบันทึกกิจกรรมจาก UI
- streak freeze รวมถึงการสะสม การป้องกันการสะสมซ้ำ และการแสดงการใช้งานกับจำนวนคงเหลือใน UI
- เกณฑ์จำนวนวัน X สำหรับการได้ freeze อาจ hardcode ไว้ก่อนได้
- freeze สามารถยกยอดไป streak ถัดไปได้
- เมื่อต้องคำนวณ streak ใหม่หลังแก้ไขกิจกรรมย้อนหลัง ต้องป้องกัน การสะสมซ้ำ ของ freeze ที่ได้มาอีกครั้ง
ขั้นตอนการแตกงานที่ใช้ซ้ำเป็นรอบ ๆ
- การแตกงานไม่ใช่งานออกแบบที่ทำครั้งเดียวจบ แต่เป็นกระบวนการแบบวนซ้ำ
- เริ่มจากรายการงานหรือโปรเจกต์ใหญ่หนึ่งชิ้น
- คิดและจดขั้นตอนที่ต้องมีเพื่อให้งานนั้นเสร็จ
- ตรวจดูว่าแต่ละขั้นตอนถูกนิยามชัดเจนพอหรือยัง
- ถ้ายังไม่พอ ก็แตกหัวข้อนั้นลงไปอีก
- ในแต่ละรอบไม่จำเป็นต้องครบหรือถูกต้องสมบูรณ์ ขอแค่ขยายจากรายการก่อนหน้าได้อีกนิดก็พอ
- ทำขั้นตอนเดิมซ้ำไปเรื่อย ๆ จนกว่างานทุกชิ้นจะถูกนิยามชัดเจนพอ
เกณฑ์ของ “งาน” และ “ถูกนิยามชัดเจนพอ”
- ในการพัฒนาซอฟต์แวร์และการประเมินโปรเจกต์ งานคือหน่วยของการทำงานที่ ถูกนิยามชัดเจนพอ สมบูรณ์ และสื่อถึงการเปลี่ยนแปลง
- “ไปทำอะไรสักอย่าง” ไม่ใช่งาน เพราะยังไม่มีเค้าโครงของข้อกำหนด
- “ตัดต้นไม้” ก็ยังไม่ใช่งานที่สมบูรณ์ ถ้าคุณเอาไปแค่เลื่อยยนต์
- ในบริบทของงาน งานจะมีความหมายก็ต่อเมื่อหลังทำเสร็จแล้วมีบางอย่างเปลี่ยนไป
- จะตัดสินว่างานถูกนิยามชัดเจนพอหรือไม่ โดยดูว่าผู้ลงมือทำตอบ “ใช่” ได้ครบทุกคำถามต่อไปนี้หรือไม่
- เข้าใจหรือไม่ว่าการเปลี่ยนแปลงที่ต้องการคืออะไร
- เข้าใจหรือไม่ว่า “เสร็จแล้ว” จะมีหน้าตาอย่างไร
- สามารถนิยามทุกขั้นตอนที่ต้องใช้จนเสร็จได้หรือไม่
- หากไม่มีตัวขวางหรือ dependency ค้างอยู่ มีข้อมูลครบพอที่จะเริ่มทำได้ทันทีหรือไม่
- ตามบริบทขององค์กร ผู้สังเกตการณ์อย่าง project manager, ผู้มีส่วนได้ส่วนเสียหลัก หรือผู้ตรวจสอบ อาจต้องสามารถตอบ “ใช่” กับคำถามเหล่านี้ได้เช่นกัน
- ยังมีงานบางประเภทที่มี สิ่งไม่รู้ ซึ่งทำให้แยกย่อยต่อได้ยาก เช่น การแก้บั๊ก
- ในกรณีแบบนี้อาจใช้เทคนิคอย่าง timeboxing
สัญชาตญาณในการแตกงานที่สร้างจากประสบการณ์
- การแตกงานเป็นทักษะที่ต้องฝึก และเป็นเรื่องปกติถ้ามันยังไม่รู้สึกง่ายในช่วงแรก
- เหตุผลที่ยก data modeling มาก่อนในตัวอย่าง ไม่ได้มาจากอัลกอริทึมที่ตายตัว แต่เป็น สัญชาตญาณ จากประสบการณ์
- เคยพบว่าการเริ่มจาก data model ก่อนช่วยให้งานลื่นไหลขึ้นเวลาเขียนเครื่องมือคล้าย ๆ กัน
- Django มี affordance ที่เหมาะกับแนวทางที่ให้ข้อมูลใน model มาก่อนมากกว่า
- หากยังมีประสบการณ์ดูหรือทำโปรเจกต์ไม่มาก อาจตัดสินใจได้ยากว่าจะเริ่มตรงไหนดี
- ถ้าทีมต้องการพัฒนาความสามารถนี้ ก็ต้องได้วางแผนโปรเจกต์ ลองแตกงาน และรับฟีดแบ็กในสภาพแวดล้อมที่ปลอดภัย
- หากไม่ลงโทษแม้แผนแรกจะผิดพลาดมาก ความผิดพลาดเหล่านั้นก็จะกลายเป็นข้อมูลประสบการณ์สำหรับ pattern matching ในครั้งถัดไป
ผลการประเมินของโปรเจกต์ตัวอย่าง
- ในการประเมินแบบโบนัส หลังแยกงานย่อยแล้วจะใส่ระดับความซับซ้อน ความไม่แน่นอน จำนวนวันที่คาดไว้ และจำนวนวันในกรณีเลวร้ายที่สุด
- ค่าประมาณรวมคำนวณได้ที่ 15.5 วัน และกรณีเลวร้ายที่สุดคือ 23.5 วัน
- ในบรรดารายการหลัก การคำนวณ streak และการสะสม freeze ถูกจัดเป็นความซับซ้อนระดับ medium และความไม่แน่นอนระดับ moderate โดยคาดไว้รายการละ 3 วัน และกรณีเลวร้ายที่สุด 4.5 วัน
- การป้องกันการสะสม freeze ซ้ำแม้มีความซับซ้อนระดับ small แต่มีความไม่แน่นอนระดับ extreme จึงประเมินไว้ 1 วัน และกรณีเลวร้ายที่สุด 5 วัน
- ในความเป็นจริง งานนี้เสร็จด้วยการทำประมาณสิบสองช่วงเย็นกับเที่ยวบินยาวหนึ่งครั้ง แต่มีการตัดทอนงานออกแบบไปมาก และอัลกอริทึมของ freeze ก็อาจยังมีบั๊กที่เพิ่งจะไปเจอในภายหลัง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
อย่างแรก แทบไม่เคยทำขั้นตอนจริง ๆ ไปจนจบตามที่วางแผนไว้เลย ผ่านไปแค่ไม่กี่ขั้นก็ได้รู้อะไรใหม่ ๆ เจอสิ่งที่ตกหล่น หรือเห็นวิธีที่ง่ายกว่า จน ไม่ทำตามแผนต่อ
อย่างที่สอง ผมไม่ชอบทำงานแบบนี้ เพราะรู้สึกว่า ความพยายามเชิงสร้างสรรค์ในการคิดว่าจะสร้างอย่างไรถูกอัดไว้ทั้งหมดในช่วงต้น ส่วนที่เหลือยังคงเป็นงานส่วนใหญ่ แต่เหลือไว้แค่ส่วนที่น่าเบื่อที่สุด ผมชอบให้ความสร้างสรรค์กับความน่าเบื่อกระจายปนกันอย่างสม่ำเสมอกว่า แบบนั้นสนุกกว่า จึงเร็วกว่า และผลลัพธ์ก็ดีกว่า
สองข้อนี้อาจเกี่ยวข้องกัน และก็ใช่ว่าผมจะไม่มีโอกาสเป็น ADHD
ถ้าคุณกำลังสำรวจหรือสร้างโปรเจกต์ของตัวเอง และไม่มีโครงสร้างความรับผิดชอบอะไรมากนัก ก็ไม่จำเป็นต้องวางแผนถึงขนาดนั้น เว้นแต่คุณจะชอบการวางแผนอยู่แล้ว
แต่ทันทีที่หัวหน้าถามว่า “ใช้เวลานานแค่ไหน? ใครทำอะไร? เริ่มตรงไหน?” คุณก็ต้องมีกรอบบางอย่าง
ผมเองก็ไม่ชอบการปรับตัวให้เข้ากับระบบที่กำหนดขึ้นเองหรือแข็งตัวเกินไป แต่ระบบควรเรียบง่ายและยืดหยุ่น และระบบเพิ่มผลิตภาพมีไว้เพื่อช่วยคน
ผมคิดว่าผู้เขียนไม่ได้ตั้งใจให้สิ่งนี้เป็นสูตรอาหารละเอียด ๆ แต่คงต้องการแสดงแนวทางของตัวเอง เพื่อให้คนอื่นได้ไอเดียไปสร้างวิธีของตัวเอง
บางทีก็แย่กว่าคำว่า “แผนไม่มีวันถูกทำตามเป๊ะ ๆ” อีก หากระหว่างลงมือทำคุณเพิ่มงานเข้าไปเรื่อย ๆ ตอนท้ายรายการงานที่ยังไม่เสร็จซึ่งไม่จำเป็นอีกแล้วจะปะปนยุ่งเหยิงกับงานที่สร้างไว้ตอนวางแผน
เพราะงานเหล่านั้นถูกสร้างขึ้นโดยไม่มี บริบททั้งหมด ที่จะเกิดขึ้นก็ต่อเมื่ออยู่ระหว่างลงมือทำเท่านั้น
ความสนุกของการเขียนโปรแกรมอยู่ที่มันเป็นกิจกรรมสร้างสรรค์ที่ยืดหยุ่นและไหลลื่น คุณสร้างมันไปตามทาง และสัมผัสมันแบบเป็นธรรมชาติ
ในสภาพแวดล้อมการทำงาน ความเป็นธรรมชาติแบบนี้มักถูกตัดออกไป เพราะต้องมีการเฝ้าติดตามและการระบุความรับผิดชอบ
ครั้งหน้าที่ต้องวางแผนงานเดิมหรืองานคล้ายกัน แผนในอนาคตก็จะดีขึ้น
ผู้จัดการโครงการก็มีคำขวัญว่า “ถ้าล้มเหลวในการวางแผน ก็คือวางแผนที่จะล้มเหลว”
เพราะผมมักรู้ตัวว่าพลาดหลายอย่างท่ามกลางสิ่งมากมายที่ต้องจำ
แผนเป็นเพียงวิธีเตือนตัวผมในอนาคตถึงผลลัพธ์ในอุดมคติที่ตัวผมในอดีตเคยคิดไว้ แทนที่จะเปลี่ยนแผนไม่รู้จบแล้วไล่ตามหิ่งห้อย
“การแตกงาน” เป็นหัวข้อใหญ่พอจะกลายเป็นประเภทหนังสือหรือพอดแคสต์ได้เลย หนังสือด้านพัฒนาตนเองหรือการจัดระเบียบหลายเล่มมักสมมติว่ากิจกรรมการแตกงานเป็นความสามารถพื้นฐานของมนุษย์ที่ผู้อ่านมีอยู่แล้ว
แต่จากประสบการณ์ของผมและเรื่องที่ได้ยินในเซสชันกลุ่ม การแตกงานเป็นเรื่องยากมาก และอาจก่อให้เกิดความรู้สึกอยากหลีกเลี่ยงหรือสิ้นหวังได้
คำแนะนำที่ใช้ได้กว้างที่สุดเท่าที่ผมเคยเห็นคือ ให้แตกงานให้ย่อยลงไปเรื่อย ๆ จนกว่าคุณจะมั่นใจ 90% ว่าคุณทำงานนั้นให้สำเร็จได้ ระดับความมั่นใจนี้ขึ้นอยู่กับความเชื่อมั่นในตัวเองและแนวโน้มการรับความเสี่ยง บางคนอาจแตกงานจนถึงระดับที่มีโอกาสสำเร็จราว 70%
เวลาที่ใช้ได้ในหนึ่งวันอยู่ราว 6 ชั่วโมง แต่ถ้ามีคนพูดอย่างมั่นใจว่าใช้ “ครึ่งวัน” ก็พอ แล้วคุณชี้ให้เห็นว่านั่นคือประมาณ 3 ชั่วโมง เขาจะมั่นใจน้อยลงมากอย่างกะทันหันหรือไม่ก็หงุดหงิด และอีก 3 วันต่อมาก็ยังทำงานนั้นอยู่
วิธีนี้แม่นยำอย่างน่าทึ่งในการประเมินเวลา เมื่อมอง โดยรวม ส่วนการประเมินรายชิ้นนั้นคลาดเคลื่อนไปมาก
สุดท้ายมันจึงเป็นการประเมินเชิงความน่าจะเป็น เมื่อผ่านเหตุการณ์จำนวนมาก ก็จะลู่เข้าหาค่าเฉลี่ย
ปัญหาที่คนส่วนใหญ่ไม่รู้คือ การพัฒนาซอฟต์แวร์มีลักษณะใกล้เคียงกับ กิจกรรมเชิงสร้างสรรค์ มากกว่าอะไรทั้งหมด แน่นอนว่ามีแง่มุมทางเทคนิคที่จริงจัง แต่ปัญหาเองเป็นสิ่งเสมือน และไม่ได้ผูกกับข้อจำกัดของโลกจริงเหมือนวิศวกรรมโยธา จึงไม่มีคำตอบที่เหมาะที่สุดเพียงหนึ่งเดียว
หากพยายามนิยามวิธีแก้ก่อนจะพิจารณาปัญหาอย่างถี่ถ้วน ก็จะเป็นการจำกัดผลลัพธ์สุดท้ายเท่านั้น การสำรวจส่วนใหญ่เกิดขึ้นจริงก็ต่อเมื่อเริ่มเขียนโค้ดแล้ว
ในซอฟต์แวร์ การที่ผลลัพธ์สุดท้ายและเวลาไม่ได้ถูกนิยามอย่างชัดเจนไม่ใช่เรื่องสำคัญนัก เพราะไม่มีต้นทุนต่อหน่วย ผู้จัดการที่ไม่มีพื้นฐานด้านวิศวกรรมซอฟต์แวร์มักไม่เข้าใจเรื่องนี้
ผลิตภัณฑ์ที่ใช้งานได้ทั่วไปสามารถขายให้ลูกค้าหลายรายได้โดยไม่มีต้นทุนการพัฒนาเพิ่มเติม
แต่เพราะบริษัทส่วนใหญ่ดำเนินงานเหมือนโรงงาน กระบวนการทั้งหมดจึงลงเอยด้วยการสร้างผลิตภัณฑ์ที่จำกัดมากและมุ่งเป้าไปยังลูกค้ารายใดรายหนึ่ง นี่คือสิ่งที่บริษัทเทคโนโลยีขนาดใหญ่หลีกเลี่ยงได้
ดูเหมือนทั้งอุตสาหกรรมจะยอมรับแพตเทิร์นนี้ไปแล้ว
แต่พูดตรง ๆ ผมคิดว่าสิ่งที่ขวางพวกเราส่วนใหญ่กลับเป็นการที่เราขาด ความสามารถในการไม่ทำสิ่งนั้น มากกว่า ถ้าคุณมีสิ่งที่อยากสร้าง ก็อย่าวางแผนทุกชิ้นส่วน แค่สร้างสิ่งที่เล็กที่สุดที่อาจมีคุณค่าขึ้นมาก็พอ
ถ้าเป็นตัวอย่างนี้ ก็เริ่มจากหน้าจอ “วันนี้” กับปุ่ม 4 ปุ่มได้เลย วันนี้คุณน่าจะสร้างสิ่งที่แสดงปุ่มออกกำลังกาย 4 ปุ่มให้กดทุกวันได้ ไม่ต้องมีสถิติต่อเนื่อง การหยุดนับชั่วคราว หรือมุมมองปฏิทินก็ได้
ไอเดียเหล่านั้นล้วนดีและเดี๋ยวก็ได้ทำภายหลัง แต่ก่อนอื่นต้องมีแรงส่งก่อน อีกไม่กี่วันต่อมา คุณอาจตัดสินใจว่าคุณไม่ชอบมุมมองปฏิทินนั้นก็ได้
หลายโปรเจกต์ต้องการแรงผลักแบบ “แค่ทำไปเถอะ แม้จะเล็กน้อยก็ตาม” ทำให้เสร็จวันนี้ แล้วค่อยดูว่าจากจุดนั้น งานถัดไปคืออะไร มีโอกาสสูงที่จะต่างจากที่คิดไว้ตอนวางแผน
แน่นอนว่านี่ก็ไม่ง่ายเช่นกัน การหาสิ่งที่เล็กที่สุด และตั้งใจจะปล่อยออกไปโดยไม่วอกแวก ต้องใช้ทั้งความคิดและวินัย ถึงอย่างนั้นก็ยังคุ้มที่จะฝึก
เป็นหลักการที่ว่าเมื่อเผชิญกับความไม่แน่นอน เราควรโฟกัสที่ “สิ่งที่ถูกต้องถัดไปที่ต้องทำ” [0]
ไม่ได้หมายความว่าจะมองเรื่องนี้เป็นเรื่องเล็กน้อย การรู้ให้ได้ว่าสิ่งที่ถูกต้องถัดไปที่ต้องทำคืออะไรนั้นยาก และจากมุมมองของผม นั่นคือส่วนที่มีค่าที่สุดของการวางแผน
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
เช่น คนหนึ่งสร้างวิธีเปรียบเทียบสำหรับการทดสอบ อีกคนลองแนวทางหนึ่ง อีกคนลองอีกแนวทาง และคนที่สามลองอีกแนวทางหนึ่ง แล้วหลังจากระยะเวลาที่กำหนดก็นำทั้งหมดมาประเมิน
แน่นอนว่าวิธีนี้มีความหมายเฉพาะเมื่อยังไม่มีแนวทางที่ชอบเป็นพิเศษอยู่แล้ว หรือไม่มีแนวทางที่เหนือกว่าอย่างชัดเจน
ในการพัฒนาจริง การทำให้เป็นโมดูลอาจเป็นวิธีทำงานแบบขนานได้ โดยให้แต่ละคนหรือแต่ละทีมรับผิดชอบคอมโพเนนต์หนึ่ง
ในงานของผม โดยเฉพาะตอนที่ยังพยายามหาทิศทางอยู่ ผมชอบสลับไปมาระหว่างส่วนที่ผู้ใช้ต้องเจอกับกลไกทางเทคนิคภายใน ถ้าพัฒนาแต่เทคโนโลยีโดยไม่รู้ว่าจะถูกใช้อย่างไร วิธีการใช้งานที่เป็นไปได้จะถูกบังคับไปในทิศทางหนึ่ง และการออกแบบแต่อินเทอร์เฟซโดยไม่รู้เทคโนโลยีก็มีหลุมพรางเช่นกัน
แต่ในงานที่ต้องใช้การทดลองเชิงสร้างสรรค์และ การพิสูจน์แนวคิด เพื่อตรวจสอบสิ่งที่ไม่อาจรู้ล่วงหน้าได้ เช่น งานวิจัย การแบ่งงานเองก็พังลง
ดังนั้นผมจึงติดนิสัยทำ งานพิสูจน์แนวคิด ส่วนใหญ่แบบไม่เปิดเผย และไม่บอกใคร
ถ้ามันไปได้ดีค่อยเปิดเผยก็ได้ ถ้าไม่ไปได้ดี ก็ทิ้งและเดินหน้าต่อได้โดยไม่เสียหน้า หรือไม่ต้องถูกบอกให้ทำให้มันสำเร็จให้ได้ ทั้งที่ตรวจสอบแล้วว่าไม่ควรทำต่อ
แค่พูดว่า “ใช้เวลา 3 ชั่วโมงตรวจสอบ X, 3 ชั่วโมงกับ Y, 3 ชั่วโมงกับ Z แล้วค่อยมาประชุมวางแผนว่าจะทำอะไรต่อ”
ผลลัพธ์มีสี่แบบ คือ อย่างแรกแก้ได้ อย่างที่สองแก้ได้ อย่างที่สามแก้ได้ หรือไม่มีอะไรแก้ได้เลย
ถ้าเป็นปัญหาที่แก้ได้ด้วยความพยายามเล็กน้อย โอกาสจะแก้ได้ในการลองครั้งที่สอง หรือภายใน 6 ชั่วโมง คือ 50%
และเมื่อถึงจุดหนึ่ง ก็ต้องลงมือทำอยู่ดี
การแบ่งงานกับการประเมินแทบจะเป็นเรื่องเดียวกัน เมื่อแบ่งงานเสร็จ คนที่มีประสบการณ์ไม่กี่ปีก็มักมีค่าประเมินมาตรฐานสำหรับงานย่อย ๆ อยู่แล้ว จึงใช้เวลาเพียงไม่กี่นาทีในการใส่ค่าประเมินให้แต่ละชิ้น
ในกรณีของผม ผมจะแบ่งงานออกเป็นก้อนที่ตัวเองประเมินได้ และส่วนที่ประเมินไม่ได้ก็ไปขอความเห็นจากคนอื่น
แต่ผมไม่คิดว่าเส้นทางที่แท้จริงสู่ความเชี่ยวชาญคือการแบ่งงาน ใคร ๆ ก็ทำแผนแบ่งงานแย่ ๆ ได้
ความเชี่ยวชาญที่แท้จริงอยู่ที่การสังเกตได้เมื่อหลักฐานชี้ว่าการแบ่งงานนั้นผิดจนก่อปัญหา และสามารถสื่อสารเรื่องนั้นหรือ ประเมินใหม่ ได้ [0]
อีกทั้งยังสำคัญที่จะยอมรับอย่างสบายใจว่าสิ่งแบบนั้นจะเกิดขึ้น เพื่อจะไม่เครียดตั้งแต่แรกเมื่อต้องนำเสนอตารางเวลาที่มีโอกาสเปลี่ยนสูง
ผู้จัดการมักต้องการโรดแมปที่แม่นยำตั้งแต่ต้น แต่นั่นคือการเรียกร้องสิ่งที่เป็นไปไม่ได้ ผมมองว่าการจัดการที่ดีอยู่ที่ความยืดหยุ่น และการเข้าใจว่าเมื่อเวลาผ่านไป เมื่อนักพัฒนาได้เรียนรู้ ลักษณะของงานที่คาดไว้ก็จะเปลี่ยนไป
ตัวอย่างเล็ก ๆ ท้ายบทความก็น่าคิดเช่นกัน ต่อให้มีคนให้ค่าประเมินที่แม่นยำว่า “ทำเสร็จได้ด้วยมื้อเย็นไม่กี่ครั้งระหว่างเดินทางด้วยเครื่องบิน” เขาก็คงปฏิเสธเพราะเสี่ยงเกินไป
สิ่งนี้แสดงให้เห็นว่าการประเมินไม่ใช่แค่เรื่องความแม่นยำเท่านั้น ยังมีองค์ประกอบที่คำอย่างการจัดการความเสี่ยง การจัดการความคาดหวัง และความคุ้นเคยกับงานไม่สามารถอธิบายได้หมดอยู่มาก
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - มีบทความเกี่ยวกับหัวข้อนี้ด้วย
พวกเขาเป็นบุคลากรซอฟต์แวร์หน้าใหม่ที่ดี แต่บางครั้งเมื่อโดเมนยังใหม่ พวกเขาไม่รู้จริง ๆ ว่าจะวางฟังก์ชันพื้นฐานอย่างไร จากประสบการณ์ของผม พวกเขาต้องการงานที่สามารถเรียนรู้และทำได้ดี และนั่นนำไปสู่การเติบโต
สิ่งที่ต้องจำไว้ให้ดีคือ ต้นทุนของกระบวนการเป็นสเปกตรัมที่ต้องปรับให้เข้ากับทีม ผู้เล่น NBA ไม่ได้เรียนวิธีขว้างบอลในวงล้อมระหว่างเกม แต่เด็กประถมสามเรียน
การวางแผนและการโค้ชทั้งสองแบบจะเหมาะสมเมื่อเข้ากับแต่ละทีม
นั่นอาจเป็นความจริงแก่นกลางของวิศวกรรมซอฟต์แวร์ก็ได้ อาจมีเวอร์ชันโอเพนซอร์สของแอป Streak ที่ผู้เขียนพยายามสร้างอยู่แล้ว และเขาอาจกำลังประดิษฐ์ล้อใหม่
สมองดูเหมือนไม่ชอบรายการงาน การทำรายการอาจสนุก แต่ส่วนใหญ่ของการทำสตาร์ทอัพหรือการเขียนโค้ดคือ การสำรวจ
และรายการงานขัดขวางการสำรวจ
ถ้าไม่ แล้วอะไรที่ต่างออกไปในการพัฒนาซอฟต์แวร์ จนทำให้ในอาชีพของเรา “ไม่ทราบครับ” กลายเป็นคำตอบที่สมเหตุสมผล?
บางครั้งมันก็ถูกต้อง แต่บางครั้งก็ไม่ “แผนที่ไม่ใช่ดินแดน”
การจะแบ่งงานเป็นงานย่อยลงไปอีกต้องทำ งานซ้ำซ้อน และเคล็ดลับคือทำให้น้อยที่สุด
หากพยายามไม่ทำงานที่ไม่จำเป็นเลย สุดท้ายก็ต้องทำทุกอย่างพร้อมกัน
ตัวอย่างเช่น สมมติว่าจะรีแฟกเตอร์โปรแกรมที่มีโมดูล A และ B โดยที่ B พึ่งพา A วิธีที่สิ้นเปลืองน้อยที่สุดคือรีแฟกเตอร์ทั้งสองโมดูลพร้อมกัน แต่นั่นก็เสี่ยงที่สุดและประเมินได้ยากที่สุด
วิธีที่แบ่งงานคือรีแฟกเตอร์ A แล้วปรับ B ให้ทำงานกับ A ที่ถูกรีแฟกเตอร์แล้ว จากนั้นถ้ารีแฟกเตอร์ A อีกครั้ง งานปรับตัวที่ทำไปก่อนหน้าก็เสี่ยงจะถูกทิ้งอย่างรวดเร็ว
ถ้าอยากทำให้งานที่จะถูกทิ้งเป็น 0 หลายครั้งก็จะแยกงานไม่ได้ แม้จะมีประสบการณ์ 20 ปี ผมก็ยังลังเลอยู่บ่อย ๆ เวลาต้องทำงานชั่วคราวที่จะถูกทิ้งเพื่อแบ่งงาน
แทนที่จะเป็นแบบนั้น มักกลายเป็นว่าทำงานที่ใช้เวลาหลายสัปดาห์ แล้วโกนขนจามรีที่ค้างไว้ทั้งหมดจนไม่เหลือสักเส้น
การคิดถึงปัญหาที่จะพยายามแก้ก่อนเริ่มงานนั้นสมเหตุสมผล และ milestone คร่าว ๆ ก็สำคัญ แต่ส่วนใหญ่มี unknown unknowns มากเกินไป การแบ่งให้หมดจดจึงไม่มีประโยชน์เลยหรือเป็นไปไม่ได้
ถ้าเอาเวลาที่ใช้แบ่งโปรเจกต์ไปใช้ค้นหาหรือสร้างวิธีแก้ น่าจะเสร็จเร็วกว่ามาก อย่างน้อยก็รู้สึกแบบนั้น
ปกติผมใช้แนวทางต่างออกไป จุดประสงค์คือประเมิน effort ที่ต้องลงไป เพื่อจะตัดสินตั้งแต่แรกว่าควรสร้างหรือไม่ พูดอีกอย่าง เหตุผลแรกคือเพื่อช่วยทำ การตัดสินใจด้านต้นทุน-ประโยชน์
มันมีประโยชน์กับทีมมากได้ด้วย โดยเฉพาะเมื่อต้องทำงานกับคนที่มีประสบการณ์น้อยกว่า ก็สามารถแบ่งงานออกไปได้มากและทำแบบขนานได้
ผมเดาว่า Jacob เองตอน implement แอป Streak ของตัวเองก็คงไม่ได้ทำการแยกย่อยแบบนี้มากนัก และจึงยกตัวอย่างแบบ recursive เพื่ออธิบาย
ในช่วงแบบนั้น การแบ่งเป็นงานเล็กลงแล้วทำให้เสร็จทีละอย่างมีประโยชน์ เพราะแม้อยู่ในภาวะติดขัดหรือไม่อยากทำงาน ก็ยังเกิดความคืบหน้า และความคืบหน้านั้นก็สร้าง แรงส่ง ให้ทำต่อไปได้
การที่ผู้จัดการสามารถประเมินความเร็วได้ก็มีคุณค่าแน่นอน เพียงแต่ปัญหาคือพอได้ลองแล้ว ก็จะเริ่มไม่เข้าใจจริง ๆ เวลามีคนบอกว่า “ยังไม่แน่ใจ”
ผมเองก็เป็นคอนซัลแตนต์ ดังนั้นแม้เราจะทำงานแบบ “Agile” การพูดว่า “เราจะส่งมอบสิ่งนี้ภายในเวลานี้” ก็สำคัญมาก