Project Management and Software Development Blog for Thais

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

รวมข้อมูลจาก risk management เข้ามาใน project plan

การทำ project plan ที่ดีควรจะมีข้อมูลเกี่ยวกับ risk ที่เกี่ยวข้องกับ project เช่น potential risk (ความเสี่ยง), mitigation (แนวทางป้องกัน) และ contingency plan (แผนสำรองเมื่อเกิดปัญหา) มาพิจารณาด้วยนะครับ ตรงนี้จะมีผลกับความถูกต้องแม่นยำของ project plan อย่างมาก ข้อแนะนำของผมก็คือเราควรจะเอาข้อมูลตรงนั้นมาิพิจารณาสร้างเป็น task ของ project plan เราด้วย ตัวอย่างเช่น

Risk: requirement ลำดับที่ 3 ไม่มีความชัดเจนเพีียงพอที่จะำทำงานได้
Mitigation: เก็บข้อมูลเพิ่มเติมจากลูกค้าก่อนเริ่ม implement ตอนต้นเดือนเมษายน
Contingency Plan: เลื่อนการ implement ไปก่อนจนกว่าจะเก็บข้อมูลเพิ่มเติมได้

ผมคิดว่า project plan ที่ดีนั้นควรจะเตรียม task ไว้สำหรับ mitigation plan ด้วยครับ เพราะว่าการเก็บข้อมูลเพิ่มเติมจากลูกค้าเป็นงานที่ต้องใช้เวลาและคนลงไปทำจริงๆ ถ้าเราไม่มี task นี้ใน project plan ก็อาจจะเกิดปัญหาตามมาหลายเรื่องอยู่ เช่น ลืมทำ !!! (น่ากลัวสุดอันนี้) ไม่มีการเตรียมคนไว้เพื่อทำงานนี้โดยเฉพาะ (ก็ไม่มี task นี่แล้วจะ assign คนลงไปทำได้ยังไงหละ?) หรือตามงานไม่ได้ว่าตอนนี้ทำถึงไหนแล้วติดปัญหาอะไรอีกบ้างมั้ย เป็นต้นครับ

กำหนด milestone ไว้ให้ชัดเจน

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

ดังนั้นทุกครั้งที่ทำ project plan เพื่อนๆอย่าลืมที่จะใส่ milestone ไว้ด้วยนะครับ สำหรับตัวเองผมจะใส่ milestone ไว้หลังจากที่ทำงานสำคัญๆเสร็จครับ เช่น ทำ functional spec document เสร็จ implement feature หลักเสร็จ หรือว่าถึงวัน beta release ที่สำคัญต้องมั่นใจว่าไม่มากไป ไม่น้อยไปนะ แบบที่จะใส่ milestone กันทุกวันหรือทุกอาทิตย์ผมมองว่าจะมากไปหน่อยฮะ ส่วนใหญ่แล้วผมจะใส่ไว้อย่างมากก็เดือนละครั้งพอครับ

เตรียม buffer ไว้สำหรับ changes และ admin process

จากประสบการณ์ที่ผ่านมาเป็นเรื่องสำคัญมากที่ต้องเตรียม buffer ไว้ให้กับ project plan ของเราด้วยครับ buffer นี้เอาไว้สำหรับความเปลี่ยนแปลงที่จะเกิดขึ้นกับ project ของเรา (มันมาแน่ๆครับ) ยกตัวอย่างเช่น requirements changes, requirement adds, design changes และอื่นๆอีกมากมาย อีกหนึ่งปัจจัยที่ทำให้ buffer สำคัญก็คือกิจกรรมทั้งหลายที่เกี่ยวกับ process ครับ ยิ่งใครต้องทำงานกับ CMMi แล้วด้วย ยิ่งต้องเตรียมให้เยอะๆหน่อย เพื่อนๆคงมีประสบการณ์กันมาบ้างนะครับว่างานที่เกี่ยวกับเอกสาร (create, review, fix, approve, issue, …) นี่มันกินเวลาอย่างบ้าเลือดเลยหละ ไหนยังจะมีเรื่องที่เกี่ยวกับ SCM (Software Configuration Management) อีกบานตะไท สรุปได้สั้นๆเลยว่า buffer ยิ่งมากยิ่งดีครับ

สำหรับตัวเองแล้วผมมีหลักการในการประมาณ buffer ที่จะใช้ไว้ว่าบวก 20% ให้กับ changes แล้วก็อีก 10% สำหรับงาน process ครับ การใส่ buffer เข้าไปใน project plan เนี่ยะถ้าจะไปทำเป็นช่องว่างแบบโจ่งแจ้งมันจะดูไม่งามนะ ลองทำแบบนี้ดูครับ หลังจากที่ estimate เวลาของแต่ละ task มาแล้ว เราก็บวก 20% ให้กับ changes แล้วอีก 10% ให้กับ process ไปโลด ตัวอย่างเช่น

Estimation for Task1: 25 man/day
Buffer for Changes (20%): 25 x 1.2 = 30 man/day
Buffer for Process (10%): 30 x 1.1 = 33 man/day

หลังจากรวมเวลาที่จะใช้กับทุก task แล้วก็ส่งไปเป็น project plan first draft เลยครับ ถ้าหัวหน้ายอมรับได้กับเวลาที่เราเสนอไป เราก็สบายเพราะได้ buffer มาใช้ แต่ถ้าหัวหน้ามองว่าใช้เวลาเยอะไป เราค่อยมาปรับลด buffer เอาทีหลัง อย่างน้อยๆเราก็เตรียมทางหนีทีไล่ไว้บ้างแล้วหละน่า

อย่าลืมคิดถึงเรื่องวันหยุด-วันลา

เราเตรียมการวางแผนไว้อย่างดิบดี มีทั้ง task ที่จัดการ risk มี milestone แล้วก็เตรียม buffer ไว้แล้วอย่างสวยงาม แต่ดันลืมรวมวันหยุดราชการกับวันลาพักร้อนของคนในทีมเข้าไปใน project plan เป็นเรื่องเลยหละครับทีนี้ ก็เพราะว่าเวลาที่ใช้ทำงาน (man/day) กับระยะเวลาที่ใช้ทำงาน (duration) มันไม่เหมือนกันครับ ตัวอย่างเช่น เราคิดว่าจะใช้เวลาทำงานนี้ 4 วันเสร็จ แต่เอาเข้าจริงพอทำไปได้ 3 วันดันมีวันหยุดมาคั่น 1 วัน สุดท้ายแล้วก็คือเราต้องใช้ระยะเวลาทำงานนี้ 5 วันปฏิทิน (4 วันทำงาน + 1 วันหยุด) ครับ ถ้าเหตุการณ์แบบนี้เกิดขึ้นบ่อยๆหละก็จะมีผลต่อ project ของเราแน่นอนเพราะว่าระยะเวลาที่ใช้ทำงานจริงๆจะยาวขึ้นเนื่องจากวันหยุดที่เพิ่มเข้ามานั่นเอง

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

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

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

Related posts:

1. บทเริ่มต้นของการวางแผนโครงการ (project planning)
2. Buffer Management ที่ถูกต้องเพื่อ Project Plan ที่สมบูรณ์
3. แจก Ebook Project Planning … ฟรี!!!
4. Chapterpiece.Meeting.2: Project Planning — How To
5. Project Planning — How To Videos