ปัญหาและวิธีแก้ไข ของการบริการโครงการ software ขนาดใหญ่

Posted by on August 7, 2014

ช่วงที่ผ่านมา ได้มีโอกาสไปสัมมนาหัวข้อเกี่ยวกับ ปัญหาและวิธีแก้ไข การบริการโครงการ software ขนาดใหญ่ ซึ่งเป็นหัวข้อที่น่าสนใจสำหรับผม ลักษณะจะเป็นพิธิกร 1 คน และตัวแทนจากองกรณ์ต่างๆอีก 4 คน พูดคุยถามตอบกัน ซึ่งเป็นลักษณะดังนี้

คนที่ 1 มาจาก Software House ซึ่งรับงานโดยตรงจากลูกค้า

คนที่ 2 มาจาก บริษัทเอกชนที่ทำ Software ใช้เองภายใน

คนที่ 3 มาจาก ธนาคารแห่งหนึ่ง ที่ทำ Software ใช้เอง ภายใน

คนที่ 4 เป็นตัวแทนจากสถาคมด้านการบริหารโครงการ แห่งหนึ่ง

การ Initial Project

คนที่ 1 – Presale กับ Developer เป็นคนละคน เวลาไปรับปากอะไรแล้ว บางทีทีมพัฒนาทำไม่ได้ ก็ต้องมีการต่อรอง แต่ถ้าต่อรองไม่ได้ ก็ต้องยอมขาดทุนเพื่อรักษาชื่อเสียง

คนที่ 2 – ถ้าเป็นการรับงานที่มาจากหลายหน่วยงาน แต่เป็นงานเดียวกัน ให้จัดลำดับความสำคัญของ Requirement ว่าอันไหนจะทำก่อนหรือหลัง

คนที่ 3 – ก่อนจะรับงาน ต้องดูว่า requirement clear แค่ไหน เงิน+เวลา+คนทำ สัมพันธ์กันไหม

คนที่ 4 – ถ้าบริหารหลายโครงการ ให้เลือกโครงการที่มีแนวโน้มจะสำเร็จได้ มาทำก่อน โดยดูว่า requirement clear แค่ไหน

สรุป – ฟังๆประสบการณ์ดูแล้ว เข้าใจว่า ทุกโครงการ ต้องมีการต่อรองกับลูกค้าเสมอ แต่รูปแบบนั้นจะไม่เหมือนกัน ขึ้นอยู่กับสภาพแวดล้อมของโครงการนั้นๆ มันเป็นธรรมชาติของการบริหารโครงการ

การทำ Planning

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

คนที่ 2 – เป็นคนที่ใช้ Agile + คันบัน ในการบริหารโครงการ (ยังไม่รู้ว่า คันบัน คืออะไร รอศึกษาเพิ่มเติม) อยากรู้เมื่อไรเสร็จ ไปดู history งานที่เคยทำ ว่าใช้นานแค่ไหน

คนที่ 3 – เน้นการวางแผนโดยใช้ Waterfall เพราะทั่วโลกยอมรับ และคุยกันง่าย

คนที่ 4 – จากสถิติทั่วโลก โครงการขนาดใหญ่ เผื่อเวลา+เงินไว้ 4 เท่า โครงการขนาดเล็ก เผื่อไว้ 2 เท่า

Activity ที่สำคัญ

คนที่ 1 – การ Confirm Requirement สำคัญมาก คนส่วนใหญ่ไม่อยากเซ็นเอกสาร ถ้าไม่ยอมนัดประชุม ให้ส่งเอกสารไปให้เซ็น แล้วลูกค้าจะมานั่งประชุมเอง

คนที่2 – เอา post-it ติดชื่อของงานเอาไว้ แบ่งเป็น 2 ฝั่ง ซ้ายกับขวา ถ้างานไหนเสร็จแล้ว ให้ย้ายจากซ้ายไปขวา งานที่ยังไม่เสร็จ ให้โยกคนที่ทำเสร็จแล้วไปช่วย

คนที่ 3 – เครื่องมือหลักที่ใช้ในการติดตามงานได้แก่ Meeting และ Gantt Chart ลองเอา Gantt Chart ไปติดไว้ตามข้างฝา จะกระตุ้นการทำงาน

คนที่ 4 – จดไม่ทัน

KPI เกณฑ์การวัดความสำเร็จ

คนที่ 1 – Exit Criteria ต้องชัดเจน และมองให้ถูกเรื่อง ยกตัวอย่างเช่น SA รับความต้องการจากลูกค้า แล้วสั่งให้ทีม Dev ทำ ถ้า Dev ทำและสามารถทำสอบจนผ่าน Testing ไปแล้ว แต่ว่าลูกค้าไม่ยอมรับ เพราะยังขาด Feature ดังนั้น จะต้องมองว่า Dev ทำงานเรียบร้อยแล้ว คือผ่าน Exit Criteria แต่ SA นั้นยังไม่ผ่าน Exit Criteria

คนที่ 2 – ใช้จีร่า (J2) ในการตามงาน (ไม่เข้าใจว่า J2 คืออะไร แต่ฟังคล้ายๆกับเครื่องมือทำ Scenario และติดตามงานของระบบ Agile คงต้องไปลองศึกษาเพิ่มเติม)

คนที่ 3 – นอกเหนือจากการผ่าน UAT แล้ว ยังต้องมองในเรื่อง ความพึงพอใจของลูกค้าด้วย คือผ่านตาม Feature แต่ลูกค้าพึงพอใจหรือไม่

คนที่ 4 – รายละเอียดคล้ายๆกับคนที่ 1 – 3

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