บทที่ 4 Project Management

ในการพัฒนาระบบหรือพัฒนา SW เราทำงานเป็นทีมเพราะเป็นโปรแกรม Application ที่มีขนาดใหญ่ที่มีความสามารถสูงๆ เช่น ระบบงานบัญชี , ระบบสินค้าคงคลัง , งานเกี่ยวกับการขาย เป็นต้น เพราะฉะนั้นการพัฒนา SW ขึ้นมา เรามักจะต้องทำงานเป็นทีม ประกอบด้วยคนหลายๆคน ดังนั้นต้องมีการแบ่งงานออกเป็นส่วนๆและดูว่าจะทำงานไหนก่อนหลังยังไงและก็จะจัดงานให้กับโปรแกรมมอร์ของเราว่าทำอะไรบ้าง < โดยบทนี้อาจารย์จะไม่พูดทุก Slide นะ จะดูแต่ที่สำคัญ >

จะว่าด้วยการแบ่งงานออกเป็นส่วนๆและกำหนดว่าส่วนไหนต้องทำตอนไหนและต้องทำอะไรบ้าง กล่าวคือจุดประสงค์ที่สำคัญก็คือต้องให้แน่ใจว่า SW ของเราต้องเสร็จให้ทันตามเวลาและก็เสร็จตามกำหนดโดยให้ได้ตาม Requirement ที่User ต้องการด้วย

เสร็จทันเวลากับเสร็จตามกำหนดไม่เหมือนกัน คือ
- เสร็จทันเวลาหมายถึงว่า Project มีการกำหนดไว้ว่าใช้เวลาเท่าไรแล้วเราทำ SW เสร็จทั้งระบบทันถือว่าเสร็จทันเวลา
- แต่ เสร็จตามกำหนดหมายความว่าเรามีการกำหนดว่าจะส่งงานเป็นส่วนๆตามที่ตั้งไว้ เพราะบางครั้ง user อาจต้องมีการนำโปรแกรมบางส่วนไปใช้ก่อน เพราะการพัฒนางานจะใช้ระยะเวลายาว เช่น ต้องการส่วนของการใส่ข้อมูลลูกค้าลงใน Database มาใช้ก่อน เพราะการใส่ข้อมูลต้องใช้เวลาในการ key ลงในเครื่อง

Management Activities ( สิ่งที่ Project Manager ต้องรับผิดชอบ , ต้องทำ )

- เขียน Proposal ก่อน โดยระบุว่าระบบที่พัฒนาขึ้นมามีคุณสมบัติอย่างไร มีความเป็นมาอย่างไร ทำประโยชน์อะไรให้องค์กรได้บ้าง เอามาแก้ปัญหาอะไร และ Feasibility Study ( การศึกษาความเป็นไปได้ ดูว่าคุ้มค่าไหมที่จะทำ )
- เขียนแผนที่ใช้ในการพัฒนาระบบ
- มีการประเมินต้นทุนของการพัฒนาระบบ
- มีการติดตามดูการพัฒนาว่าเป็นไปตามที่กำหนดไว้หรือเปล่าตรงตาม Requirement หรือไม่ มีการตรวจสอบสิ่งที่พัฒนาขึ้นมา ( ในกรณีที่ผ่านการอนุมัติให้พัฒนาแล้ว )
- มีการคัดสรรคนเข้าร่วมทีม , จัดสรรตำแหน่ง และมีการประเมินผลลูกทีม
- มี report นำเสนอผลงานโดยจะทำในทุกๆช่วงของ Milestone ( จะกล่าวในภายหลัง )

มีอยู่ 2 สิ่งที่สำคัญและเป็นเรื่องใหญ่สำหรับการดูแลพัฒนา SW นั่นก็คือ

1. เรื่องของ Staff ( Project Staff )
- จัดหาคนที่เหมาะสม
- มอบหมายงานที่เหมาะสมให้กับคนเหล่านี้
- พัฒนาคนเหล่านี้

2. เรื่องของการวางแผน Project ( Project Planning )
- สำคัญที่สุดและใช้เวลามากที่สุด ในกระบวนการที่ต้องทำ
- การวางแผนไม่ได้ทำเฉพาะตอนแรกเท่านั้น การวางแผนจะทำตลอดโครงการตั้งแต่เริ่มต้นจนปิดโครงการ จะมีการปรับเปลี่ยนตลอดเวลา ( Tool ที่อาจนำมาใช้คือ Microsoft Project )
- ในการวางแผนของ Project ไม่ได้มองแค่แง่มุมเดียว กล่าวคือไม่ใช่แค่ทำงานให้เสร็จอย่างเดียว แต่จะมองไปในหลายๆแง่มุม

Type of Project Plan

Project Planning Process ( ไม่ค่อยสำคัญ อาจารย์ไม่สอน ให้ไปอ่านเอง )

Activity Organization ( Slide 12 Milestones in the RE process บทที่ 4)

ในการวางแผนพัฒนา SW เรามักจะแบ่งงานออกเป็น Activity โดยองค์ประกอบที่เราจะต้องมีคือ
1. กำหนดเป็นกิจกรรมหลักๆที่ทีมงานจะต้องทำ (รูปวงรี)
2. จัดทำ Milestone (รูปสี่เหลี่ยม) โดยที่ Milestone คือ หลักชัยของงานเป็นจุดที่บอกว่างานย่อยที่ทำนั้นเสร็จแล้ว หรือบอกว่างานทั้งระบบทำไปถึงไหนแล้ว

The Project Scheduling ( การกำหนดตารางการทำงาน )
- แบ่ง Project ออกเป็นงานย่อยๆ มีการประมาณเวลาและทรัพยากรที่ต้องใช้ในแต่ละงานย่อย
- พยายามจัดแต่ละงานย่อยให้ทำงานพร้อมกันให้มากที่สุด (อยู่ที่ความสามารถของ Project Manager)
- พยายามทำให้งานขึ้นต่อกันให้น้อยที่สุด กล่าวคือให้แต่ละงานทำงานเป็นอิสระต่อกัน

อธิบายตารางข้างบน ( Slide 17 )
มี 12 งานย่อย (T1 - T12)




T1 , T2 ,T4 สามารถทำได้เลยเพราะไม่ขึ้นต่อใครเลย ส่วนงานที่เหลืออิ่นๆจะขึ้นกับกิจกรรมอื่นๆ เช่น งาน T3 จะทำได้ก็ต่อเมื่อ T1 ทำเสร็จ โดยที่ T1 ใช้เวลา 8 วันส่วน T3 ใช้เวลา 15 วัน เพราะฉะนั้น T3 จะใช้เวลาน้อยที่สุด 23 วัน ( ในการประมาณจริง จะมีการประมาณเวลาเผื่อเอาไว้ด้วย ) เป็นต้น

หลังจากเรากำหนดอะไรเรียบร้อยแล้ว เราจะนำมาเขียนเป็น Diagram ( Slide 18 รูปข้างล่าง )ที่เราเรียกว่า Critical Path โดยที่จากภาพ Critical Path จะเป็นเส้นทึบโดยเริ่มจาก Start -> T1 -> M1 -> T3 -> M4 -> T9 -> M6 -> T11 -> M8 -> T12 -> Finish

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

Risk Management ( การบริหารความเสี่ยง )

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

Risk	Risk type	Description
Staff turnover	Project	Experienced staff will leave the project before it is finished.
Management change	Project	There will be a change of organisational management with different priorities.
Hardware unavailability	Project	Hardware which is essential for the project will not be delivered on schedule.
Requirements change	Project and product	There will be a larger number of changes to the requirements than anticipated.
Specification delays	Project and product	Specifications of essential interfaces are not available on schedule
Size underestimate	Project and product	The size of the system has been underestimated.
CASE tool under-performance	Product	CASE tools which support the project do not perform as anticipated
Technology change	Business	The underlying technology on which the system is built is superseded by new technology.
Product competition	Business	A competitive product is marketed before the system is completed.

The Risk Management Process ( ขบวนการในการบริหารความเสี่ยง )
1. Risk Identification - บอกให้ได้ว่าอะไรบ้างที่เป็นความเสี่ยง
2. Risk Analysis - วิเคราะห์ความเสี่ยง คือวิเคราะห์โอกาสที่เป็นไปได้ที่จะเกิดมากน้อยแค่ไหน , ผลลัพธ์ที่เกิดขึ้นรุนแรงแค่ไหน
3. Risk Planning - วางแผนรับมือว่าถ้าเกิดขึ้นแล้วจะแก้ไขยังไง
4. Risk Monitoring – ติดตามดูว่าความเสี่ยงที่วิเคราะห็ไว้เกิดขึ้นหรือยัง และถ้าเกิดขึ้นแล้วการแก้ไขที่วางแผนไว้ได้ผลดังที่คาดไว้หรือไม่

1. Risk Identification

พยายามแบ่งเป็นหมวดหมู่ตามประเภทของความเสี่ยง ( Slide 25 ) เพราะการแก้ปัญหาแต่ละหมวดหมู่ไม่เหมือนกัน โดยเราจะจัดสรรคนให้แก้ปัญหา ในแต่ละหมวดหมู่ในด้านที่เขาถนัดและรับผิดชอบได้ ( Slide 26 ) ตย.เช่น ถ้าตอนเลือกใช้ Database มีการระบุว่า Database นี้สามารถรองรับข้อมูลได้ 1,000,000 record แต่พอใช้งานจริงกลับรองรับได้ไม่ถึง มันก็คือความเสี่ยงที่เกิดขึ้นที่เราต้องแก้ไข

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

ในการวางแผนที่จะแก้ปัญหาความเสี่ยงที่จะเกิดขึ้น มี 3 วิธี
1. Avoidance Strategies – วางแผนทุกวิถีทางเพื่อพยายามหลีกเลี่ยงไม่ให้ความเสี่ยงนั้นเกิดขึ้น
2. Minimization Strategies – พยายามทำให้เกิดขึ้นให้น้อยที่สุดเท่าที่จะเป็นไปได้
3. Contingency Plans – พอแค่รู้ว่าจะเกิดอะไรขึ้นบ้าง มากน้อยแค่ไหนเท่านั้น และเตรียมการรองรับไว้ ซึ่งเป็นวิธีที่นิยมใช้มากที่สุดเพราะจะทำให้ Project สั้นและต้นทุนต่ำ แต่ก็มีข้อเสียคือ อาจเกิดเหตุการณ์ขึ้นจริงได้( ซึ่งก็มีการเตรียมรองรับไว้แล้ว )

4. Risk Monitoring

การติดตามแผนที่เราได้วางเอาไว้ โดยถ้าเราติดตามการเกิดความเสี่ยงอย่างรัดกุมก็เท่ากับเรา Monitor Risk เรียบร้อยแล้ว โดยดูว่าถ้าเกิดปัญหาเราก็แก้ปัญหาตามที่ได้วางแผนไว้ และดูผลว่าเป็นอย่างไร

Risk Factor ( ปัจจัยที่ทำให้เกิดความเสี่ยง ) ไม่เน้นเท่าไหร่ อ่านเอง

งาน : อาจารย์พูดคร่าวๆว่าจะให้วางแผนงาน , เขียน Feasibility โดยละเอียด แต่ยังไม่ได้บอกอะไรมากนัก

บรรยายเมื่อ 27 ธค. 2544 เทอม 2/44