จัดการงานให้เสร็จ – ตอนที่ 1

เนื่องจากเป็นพวกเจ้าโปรเจ็ค ชอบหาเรื่องหางาน เลยต้องหาวิธีจัดการมันไปด้วย ทั้งด้วยเฟรมเวิร์ค (กรอบแนวทาง) ใหม่ๆ หรือลองใช้เครื่องมือชนิดใหม่ๆ

ล่าสุดย้ายมาใช้เครื่องมือใหม่ในการทำงานร่วมกับทีม เลยคิดว่าน่าบันทึกไว้ซักหน่อย ถือว่าเป็นภาคต่อของบันทึก เครื่องมือช่วย “ทำงานให้เสร็จ” เมื่อ 8 ปีก่อนละกันฮะ ?

ส่วนคนที่เริ่มงง ผมขอเล่าพื้นฐานในการจัดการงานก่อนนะครับ ซึ่งมี 2 ระดับคือ

1. จัดการงานส่วนตัว – จัดการ Task/Todo แนวทางที่นิยมคือ Getting Things Done
2. จัดการงานส่วนรวม – จัดการโครงการ (Project Management) ซึ่งต้องทำงานร่วมกันหลายคน ต้องคำนึงถึงเวลาและงบประมาณ รวมทั้งปัจจัยอื่นๆ ที่เปลี่ยนแปลงไปตลอดงาน

จัดการงานส่วนตัว

เมื่อมีหลายงานมาทับถม สิ่งที่เราควรจัดการคือ แยกประเภทงาน ยาก/ง่าย, ด่วน/ไม่ด่วน, สำคัญ/ไม่สำคัญ, ต้องทำเอง/ให้คนอื่นทำได้ แล้วกำหนดว่าเราจะทำยังไงกับมัน หากงานไหนใช้เวลาน้อยก็ควรทำเลย แนวทางที่นิยมคือ Getting Things Done (GTD) หรือการจัดการให้งานเสร็จ

ปัจจุบันมีเครื่องมือจำนวนมากที่ช่วยจัดการ สามารถใส่แท็ก (Tag) ต่างๆ ได้อิสระ เช่น

• Upcoming สำหรับงานสำคัญ เร่งด่วน เอาไปต่อคิวไว้
• Anytime งานสำคัญ ไม่เร่งด่วน
• Someday งานไม่สำคัญ ไม่เร่งด่วน

ซึ่งนอกจากการแปะแท็ก เรายังตั้งแจ้งเตือนได้ด้วย เมื่อยังไม่ถึงกำหนด ระบบก็เก็บไว้ในกรุ (Archive / Snooze) ก่อน ทำให้เรายังไม่ต้องเอางานในอนาคต มากังวลในปัจจุบัน

โปรแกรมที่ช่วยจัดการ ส่วนตัวเป็นสายเปย์ เลยชอบใช้แอพ Things แต่ว่าตัวอื่นซึ่งฟรีก็มี ลองดูที่ Alternatives to Things

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

---

จัดการงานส่วนรวม

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

1. ของที่ถูก และ ดี – มันก็ไม่เร็ว เป็นงานทำด้วยใจ มักจะส่งงานสายเสมอ
2. ของที่ถูก และ เร็ว – มันก็ไม่ดี เป็นงานเผา ตลาดล่าง
3. ของที่ดี และ เร็ว – มันก็ไม่ถูก เป็นงานพรีเมียม ต้องยอมจ่ายแล้วจบ
4. ส่วนของที่มีครบทั้ง ถูก เร็ว และ ดี – มันไม่มีหรอก (โว้ย)

---

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

เครื่องมือที่เป็นที่นิยมกันก็คือแผนภูมิแกนต์ (Gant Chart) ตามแบบในรูป ที่ท่าน Henry Gantt คิดขึ้นเมื่อ 115 ปีก่อน ซึ่งจะทำให้เราเห็นว่ามีงานอะไรบ้าง งานไหนขึ้นกับงานไหน ขณะนี้ทำอะไรไปถึงไหนแล้ว

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

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

---

อะไรคือการบริหารโครงการที่มีปัญหา?

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

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

เพราะการตรวจคุณภาพต่างๆ มันตรวจยาก คนเลยตรวจรับกันที่

1. ขั้นตอนและเครื่องมือ – ทำตามที่ระบุไว้หรือเปล่า? ทำผิดขั้นตอนหรือเปล่า?
2. เอกสารที่ครบถ้วนสมบูรณ์ – อยากได้คู่มือหนาๆ แม้ไม่มีใครสนใจอ่าน
3. ทำตามสัญญา หรือ TOR (Term of Reference • ข้อกําหนดของผู้ว่าจ้าง) หรือเปล่า? – ถ้าไม่ครบ ก็ไม่ผ่าน โดนปรับด้วยนะ
4. ทำตามแผนที่วางไว้หรือเปล่า? – เปรียบเทียบเช่นตอนนั้นหนังออเจ้า (บุพเพสันนิวาส) กำลังดัง เลยคิดจะเปิดตัวพร้อมกับเทรนด์นี้ แต่พอโปรเจ็คล่าช้า เกิดเปิดตัวตอนนี้ มันก็ย่อมผิดที่ผิดทางไปหมด – ฟังแล้วเหมือนเรื่องตลกที่เป็นไปไม่ได้ แต่โครงการขนาดใหญ่จำนวนมากกลับเป็นอย่างนั้น ไม่ปรับแผน เพราะไม่มีใครอยากตัดสินใจแล้วต้องรับผิดชอบมัน

ทางออกในยุคปัจจุบัน

17 ปีที่แล้ว เทพโปรแกรมเมอร์ 17 คน พบว่าเรากำลังหลงทางในการบริหารโครงการซอฟต์แวร์กันอยู่ เลยร่วมกันออก คำแถลงอุดมการณ์แห่งอไจล์ ว่า จริงๆ เราควรโฟกัสที่…

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

ผมปรับคำเล็กน้อย ใส่ไว้ตามรูป

ซึ่ง อไจล์ (Agile – แปลว่าคล่องแคล่ว ปราดเปรียว) นั้นเป็น ค่านิยม (Value) และ หลักการ (Principle) ไม่ใช่ ระเบียบวิธีปฏิบัติ (Methodology) ดังนั้น หากใช้วิธีแบบที่เค้าว่าเป็นอไจล์ (เช่น Scrum) แต่กลับไม่ให้คุณค่ากับ 4 ข้อด้านบน งานนั้นย่อมไม่เป็นอไจล์

การพัฒนาแบบ Iterative & Incremental

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

แล้วคิดเงินหรือส่งมอบงานกันยังไง?

ที่ผมเคยเจอ คือกันทีมงานไว้ทำงานนี้งานเดียว แล้วคิดเงินกันตามรอบ (Iterative หรือ Sprint) เหล่านี้เลย เช่น วางแผนส่งมอบงานกันทุก 2 สัปดาห์ มีทีมขนาดเล็กที่ทำ (เช่น 2-3 คน) คิดเงินไม่มาก (เช่น 5 หมื่น – แสน ต่อรอบ) ประชุมร่วมกันบ่อยๆ (เช่น ทุกวัน วันละ 15 นาที) แล้วก็มาดูกันทุก 2 สัปดาห์ว่าได้อย่างที่คิดมั้ย

ถ้าเชื่อใจกัน ก็ช่วยกันหาทางแก้/ปรับปรุง แล้วเริ่มงานในรอบต่อไป

ถ้าไม่เชื่อใจกัน ก็จบ เลิกรากันไป

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

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

แล้วเมื่อไหร่งานเสร็จ?

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

องค์กรขนาดใหญ่จำนวนมากที่ใช้แนวทางนี้ จะสร้างนวัตกรรมใหม่ๆ ได้ต่อเนื่อง อาจจะทุก 2 สัปดาห์ หรือทุกเดือน (ส่วนของเว็บ Facebook นั้นโหดกว่า คือออกรุ่นใหม่ทุกวัน! และเวอร์ชั่นหลักในวันอังคารบ่าย ทุกสัปดาห์! สนใจลองอ่าน Exclusive: a behind-the-scenes look at Facebook release engineering)

ส่วนถ้าคิดว่า จะพัฒนาให้เสร็จสมบูรณ์ ไม่มีอะไรต้องทำต่ออีกแล้ว – มันไม่มีหรอก

Art is never finished only abandoned.

Leonardo da Vinci

ลีโอนาโด ดาวินชี กล่าวว่า ศิลปะนั้นเป็นสิ่งที่ไม่มีวันสร้างเสร็จ เราแค่เลิกทำไปก่อน

ส่วนในแวดวงไอที เราก็พูดเช่นกันว่า

ซอฟต์แวร์หรือเว็บไซต์นั้นเป็นสิ่งที่ไม่มีวันสร้างเสร็จ
เราแค่เลิกทำ (หรือหมดเงิน) ไปก่อน

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

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

 

ขอขอบคุณ : https://menn.blog/agile-project-management/