สวัสดีครับ วันนี้ผมมีบทความดีๆเกี่ยวกับเคล็ดลับ 7 ข้อที่จะช่วยปรับปรุงประสิทธิภาพในการบริหารจัดการโครงการพัฒนาซอฟท์แวร์ ให้ดีขึ้นมาฝากกัน คำแนะนำนี้มาจาก Robert E. Bone,ผู้เชียวชาญการบริหารโครงการ ในบางข้อผมเพิ่มเติมความคิดเห็นและประสบการณ์ตรงของผมเข้าไปด้วยครับ
1. งานเอกสารและการจัดการกับความต้องการของลูกค้า
ไม่น่าเชื่อก็ต้องเชื่อหละครับว่าส่วนใหญ่แล้วลูกค้ากับดีเวลลอปเปอร์มีอะไร คล้ายๆกัน เพื่อนๆอาจจะนึกไม่ออก ผมขอเฉลยเลยครับว่าความเหมือนกันของกลุ่มคนสองกลุ่มนี้ก็คือทั้งสองฝ่ายมัก จะมองข้ามความสำคัญของการจัดการกับความต้องการของลูกค้า (requirement) อย่างเหมาะสม ตัวอย่างเช่น ลูกค้าต้องการให้งานเสร็จก่อนเวลาและค่าใช้จ่ายอยู่ภายในงบประมาณแต่ไม่เคย หยุดเพิ่มหรือเปลี่ยนความต้องการ ในขณะเดียวกันฝั่งดีเวลลอปเปอร์เองก็มีการเพิ่มเติมความสามารถ (feature) อื่นๆเข้าไปในซอฟท์แวร์โดยไม่ได้รับการอนุมัติเพียงเพราะคิดว่าสิ่งเหล่า นั้นน่าจะเป็นสิ่งที่ลูกค้าต้องการหรือเป็นเพราะคิดว่าเทคโนโลยีเอื้ออำนวย
ต่อการใส่ลูกเล่นต่างๆเพิ่มเติมเข้าไป สถานการณ์ตัวอย่างเหล่านี้เป็นตัวการสำคัญในการสร้างความลำบากให้กับเราเป็นอย่างยิ่ง
เพื่อป้องกันเสียแต่เนิ่นๆ เป็นเรื่องสำคัญมากที่จะต้องสร้างเอกสารตัวหนึ่งที่เรียกว่า Traceability Matrix ซึ่งจะทำการเชื่อมความสัมพันธ์ไปและกลับระหว่างโค๊ดที่เขียนกับความต้องการ แต่ละตัวของลูกค้า ทำไมเอกสารนี้ถึงสำคัญ? ก็เพราะว่าเมื่อเรามีเอกสารนี้อยู่ในมือ(สำคัญว่าต้องใช้มันอย่างสม่ำเสมอ ด้วยนะครับ) ก่อนที่โค๊ดจะถูกเขียนดีเวลลอปเปอร์ต้องมั่นใจว่าสิ่งที่ทำอยู่นั้นมีระบุ ไว้ใน Traceability Matrix อย่างชัดเจน จุดนี้จะช่วยป้องกันไม่ให้มีอะไรนอกเหนือความต้องการที่แท้จริงของลูกค้าถูก เพิ่มเติมเข้ามา อีกมุมหนึ่งเราในฐานะผู้จัดการโครงการก็จะสามารถใช้เอกสารนี้ในการพูดคุยต่อ รองเมื่อมีประเด็นที่เกี่ยวกับความต้องการ ประโยชน์อีกอย่างหนึ่งของเอกสารฉบับนี้ก็คือเป็นเอกสารอ้างอิงในการติดตาม ความก้าวหน้าของโครงการด้วย
2. เพีย รีวิว (Peer Review) นั้นสำคัญ
สิ่งที่เราไม่ควรทำนั่นก็คือการอนุมัติเพีย รีวิวไปตามพิธีโดยไม่ได้พิจารณาอย่างจริงจังเสียก่อน จากประสบการณ์ของผมเองนั้นเพีย รีวิวเป็นกระบวนการที่มีประสิทธิภาพมากในการตรวจจับข้อบกพร่องของงานไม่ว่า จะเป็นงานเอกสารหรืองานโค๊ดก็ตาม ข้อแม้คือต้องทำอย่างจริงจัง โครงการใดๆที่ไม่มีกระบวนการเพีย รีวิวมีโอกาสสูงที่จะต้องใช้เวลามากเพื่อแก้ไขปัญหาในช่วงสุดท้ายของโครงการ
3. ทำเฉพาะงานที่ได้รับอนุมัติแล้ว
สำหรับดีเวลลอปเปอร์นอกจากต้องมั่นใจว่าโค๊ดที่แก้ไขหรือเพิ่มเติมนั้นทำงาน ได้ถูกต้องแล้ว สิ่งที่สำคัญมากอีกอย่างหนึ่งก็คือต้องมั่นใจด้วยว่าโค๊ดที่แก้ไขหรือเพิ่ม เติมทั้งหมดนั้นได้รับการอนุมัติจากผู้จัดการโครงการแล้ว เป็นหน้าที่โดยตรงของผู้จัดการโครงการที่ควบคุมดูแลให้การแก้ไขหรือเพิ่ม เติมต่างๆนั้นเชื่อมโยงกลับไปยังความต้องการของลูกค้าได้อย่างถูกต้องซึ่ง จุดนี้แสดงให้เห็นถึงความสำคัญของ Traceability Matrix นั่นเอง
4. แบ่งปันและสร้างพลังที่ยิ่งใหญ่ให้กับความรู้
บริษัทบางแห่งทำการตัดแบ่งทีมงานออกเป็นส่วนๆซึ่งแต่ละทีมงานไม่รู้ว่าทีมอื่นๆทำ อะไรกันอยู่ ข้อเสียที่ชัดเจนก็คือทีมต่างๆนั้นทำงานคล้ายๆกันหรือแย่กว่านั้นอีกก็ทำงาน ซ้ำกันเลย การตัดแบ่งทีมงานนั้นเป็นเรื่องที่เข้าใจและสามารถทำได้ แต่คำแนะนำที่มีก็คือควรจะมีการแต่งตั้งคณะกรรมการกลางขึ้นมาหนึ่งชุดเรียก ว่า Technical Review Board ซึ่งจะทำหน้าที่ในการแบ่งปันและสร้างพลังจากคลังความรู้จากทุกๆทีมงานเพื่อ ลดความซ้ำซ้อน ลดเวลาและงบประมาณที่ใช้ในการทำโครงการต่างๆ
5. ลดคุณภาพเมื่อจำเป็น
หลายๆครั้งการลดคุณภาพของงานเพื่อที่จะส่งงานได้ทันตามเวลาที่กำหนดเป็นสิ่งที่ทำ ได้ (ถ้าไม่มีทางเลือกอื่นๆนะครับ) การลดคุณภาพที่ว่าก็ทำได้ทั้งงานที่เกี่ยวข้องกับซอฟท์แวร์โดยตรงและงาน เอกสาร แต่ต้องจำขึ้นใจไว้เลยนะครับว่าการลดคุณภาพหมายถึงเราทำงานนั้นแต่ไม่เสร็จ สมบูรณ์ ไม่ใช่ไม่ทำเลย! จากประสบการณ์ตรงของผมเองนั้นการลดคุณภาพของงานอาจจะทำได้ที่การเทสเช่นกัน ตัวอย่างเช่นการ optimize การทำ platform crossing สำหรับเทส หรือลดจำนวน platform ไปเลยก็ได้เช่นกัน
6. การแย่งคนเก่งกัน
เป็นเรื่องปกติที่ในบริษัทจะมีการทำโครงการมากกว่าหนึ่งโครงการพร้อมๆกันและก็ เป็นปกติเช่นกันที่พนักงานหนึ่งคนทำงานมากกว่าหนึ่งโครงการพร้อมๆกัน ตรงนี้เป็นหน้าที่ของเราในฐานะผู้จัดการโครงการที่จะต้องเตรียมการและ ป้องกันความเสียหายที่อาจจะเกิดขึ้นได้จากเหตุการณ์นี้
7. ข้ามาคนเดียว
การอนุญาตให้พนักงานทำงานคนเดียวนั้นเป็นเรื่องที่เสี่ยงอย่างมาก เพราะอะไร? ก็เพราะว่าการทำงานคนเดียวนั่นจะเป็นอุปสรรคต่อการตรวจสอบ สอบถามและติดตามงานนั้นๆ ปัญหาที่จะตามมาก็คือเมื่อมีการนำงานของพนักงานคนนั้นมาเชื่อมต่อกับงาน อื่นๆแล้วอาจจะเกิดปัญหาใหญ่ขึ้นมาได้ ตัวอย่างเช่นถ้าพนักงานคนนั้นเป็นดีเวลลอปเปอร์ การออกแบบ interface นั้นไม่ตรงกับความต้องการลูกค้าหรือไม่ตรงกับมาตรฐานของทีม หรือถ้าพนักงงานคนนั้นเป็นเทสเตอร์ การออบแบบ test case ไม่ตรงกับสิ่งที่ดีเวลลอปเปอร์ทำไว้ เป็นต้น
เป็นหน้าที่โดยตรงของ ผู้จัดการโครงการที่จะต้องไม่ปล่อยให้เหตุการณ์เช่นนี้เกิดขึ้นระหว่างการ ดำเนินโครงการ ซึ่งคำแนะนำเพื่อป้องกันเหตุการณ์นี้ก็คือผู้จัดการควรจะมีการพูดคุยกับ พนักงานทุกคนเพื่อที่จะประเมินความสมัครใจในการทำงานเป็นทีมด้วยตัวเองเพื่อ ที่จะคัดกรองพนักงานได้อย่างมีประสิทธิภาพสูงสุด
หวังว่าบทความนี้จะมีประโยชน์กับเพื่อนๆบ้างนะครับ
ที่มา: http://www.projectsmart.co.uk Technology Management Academy for Thais | Chapterpiece.com
Better Managing, Better Living
7 วิธีเพื่อความสำเร็จในการบริหารโครงการพัฒนาซอฟท์แวร์ขนาดใหญ่
1. งานเอกสารและการจัดการกับความต้องการของลูกค้า
ไม่น่าเชื่อก็ต้องเชื่อหละครับว่าส่วนใหญ่แล้วลูกค้ากับดีเวลลอปเปอร์มีอะไร คล้ายๆกัน เพื่อนๆอาจจะนึกไม่ออก ผมขอเฉลยเลยครับว่าความเหมือนกันของกลุ่มคนสองกลุ่มนี้ก็คือทั้งสองฝ่ายมัก จะมองข้ามความสำคัญของการจัดการกับความต้องการของลูกค้า (requirement) อย่างเหมาะสม ตัวอย่างเช่น ลูกค้าต้องการให้งานเสร็จก่อนเวลาและค่าใช้จ่ายอยู่ภายในงบประมาณแต่ไม่เคย หยุดเพิ่มหรือเปลี่ยนความต้องการ ในขณะเดียวกันฝั่งดีเวลลอปเปอร์เองก็มีการเพิ่มเติมความสามารถ (feature) อื่นๆเข้าไปในซอฟท์แวร์โดยไม่ได้รับการอนุมัติเพียงเพราะคิดว่าสิ่งเหล่า นั้นน่าจะเป็นสิ่งที่ลูกค้าต้องการหรือเป็นเพราะคิดว่าเทคโนโลยีเอื้ออำนวย
ต่อการใส่ลูกเล่นต่างๆเพิ่มเติมเข้าไป สถานการณ์ตัวอย่างเหล่านี้เป็นตัวการสำคัญในการสร้างความลำบากให้กับเราเป็นอย่างยิ่ง
เพื่อป้องกันเสียแต่เนิ่นๆ เป็นเรื่องสำคัญมากที่จะต้องสร้างเอกสารตัวหนึ่งที่เรียกว่า Traceability Matrix ซึ่งจะทำการเชื่อมความสัมพันธ์ไปและกลับระหว่างโค๊ดที่เขียนกับความต้องการ แต่ละตัวของลูกค้า ทำไมเอกสารนี้ถึงสำคัญ? ก็เพราะว่าเมื่อเรามีเอกสารนี้อยู่ในมือ(สำคัญว่าต้องใช้มันอย่างสม่ำเสมอ ด้วยนะครับ) ก่อนที่โค๊ดจะถูกเขียนดีเวลลอปเปอร์ต้องมั่นใจว่าสิ่งที่ทำอยู่นั้นมีระบุ ไว้ใน Traceability Matrix อย่างชัดเจน จุดนี้จะช่วยป้องกันไม่ให้มีอะไรนอกเหนือความต้องการที่แท้จริงของลูกค้าถูก เพิ่มเติมเข้ามา อีกมุมหนึ่งเราในฐานะผู้จัดการโครงการก็จะสามารถใช้เอกสารนี้ในการพูดคุยต่อ รองเมื่อมีประเด็นที่เกี่ยวกับความต้องการ ประโยชน์อีกอย่างหนึ่งของเอกสารฉบับนี้ก็คือเป็นเอกสารอ้างอิงในการติดตาม ความก้าวหน้าของโครงการด้วย
2. เพีย รีวิว (Peer Review) นั้นสำคัญ
สิ่งที่เราไม่ควรทำนั่นก็คือการอนุมัติเพีย รีวิวไปตามพิธีโดยไม่ได้พิจารณาอย่างจริงจังเสียก่อน จากประสบการณ์ของผมเองนั้นเพีย รีวิวเป็นกระบวนการที่มีประสิทธิภาพมากในการตรวจจับข้อบกพร่องของงานไม่ว่า จะเป็นงานเอกสารหรืองานโค๊ดก็ตาม ข้อแม้คือต้องทำอย่างจริงจัง โครงการใดๆที่ไม่มีกระบวนการเพีย รีวิวมีโอกาสสูงที่จะต้องใช้เวลามากเพื่อแก้ไขปัญหาในช่วงสุดท้ายของโครงการ
3. ทำเฉพาะงานที่ได้รับอนุมัติแล้ว
สำหรับดีเวลลอปเปอร์นอกจากต้องมั่นใจว่าโค๊ดที่แก้ไขหรือเพิ่มเติมนั้นทำงาน ได้ถูกต้องแล้ว สิ่งที่สำคัญมากอีกอย่างหนึ่งก็คือต้องมั่นใจด้วยว่าโค๊ดที่แก้ไขหรือเพิ่ม เติมทั้งหมดนั้นได้รับการอนุมัติจากผู้จัดการโครงการแล้ว เป็นหน้าที่โดยตรงของผู้จัดการโครงการที่ควบคุมดูแลให้การแก้ไขหรือเพิ่ม เติมต่างๆนั้นเชื่อมโยงกลับไปยังความต้องการของลูกค้าได้อย่างถูกต้องซึ่ง จุดนี้แสดงให้เห็นถึงความสำคัญของ Traceability Matrix นั่นเอง
4. แบ่งปันและสร้างพลังที่ยิ่งใหญ่ให้กับความรู้
บริษัทบางแห่งทำการตัดแบ่งทีมงานออกเป็นส่วนๆซึ่งแต่ละทีมงานไม่รู้ว่าทีมอื่นๆทำ อะไรกันอยู่ ข้อเสียที่ชัดเจนก็คือทีมต่างๆนั้นทำงานคล้ายๆกันหรือแย่กว่านั้นอีกก็ทำงาน ซ้ำกันเลย การตัดแบ่งทีมงานนั้นเป็นเรื่องที่เข้าใจและสามารถทำได้ แต่คำแนะนำที่มีก็คือควรจะมีการแต่งตั้งคณะกรรมการกลางขึ้นมาหนึ่งชุดเรียก ว่า Technical Review Board ซึ่งจะทำหน้าที่ในการแบ่งปันและสร้างพลังจากคลังความรู้จากทุกๆทีมงานเพื่อ ลดความซ้ำซ้อน ลดเวลาและงบประมาณที่ใช้ในการทำโครงการต่างๆ
5. ลดคุณภาพเมื่อจำเป็น
หลายๆครั้งการลดคุณภาพของงานเพื่อที่จะส่งงานได้ทันตามเวลาที่กำหนดเป็นสิ่งที่ทำ ได้ (ถ้าไม่มีทางเลือกอื่นๆนะครับ) การลดคุณภาพที่ว่าก็ทำได้ทั้งงานที่เกี่ยวข้องกับซอฟท์แวร์โดยตรงและงาน เอกสาร แต่ต้องจำขึ้นใจไว้เลยนะครับว่าการลดคุณภาพหมายถึงเราทำงานนั้นแต่ไม่เสร็จ สมบูรณ์ ไม่ใช่ไม่ทำเลย! จากประสบการณ์ตรงของผมเองนั้นการลดคุณภาพของงานอาจจะทำได้ที่การเทสเช่นกัน ตัวอย่างเช่นการ optimize การทำ platform crossing สำหรับเทส หรือลดจำนวน platform ไปเลยก็ได้เช่นกัน
6. การแย่งคนเก่งกัน
เป็นเรื่องปกติที่ในบริษัทจะมีการทำโครงการมากกว่าหนึ่งโครงการพร้อมๆกันและก็ เป็นปกติเช่นกันที่พนักงานหนึ่งคนทำงานมากกว่าหนึ่งโครงการพร้อมๆกัน ตรงนี้เป็นหน้าที่ของเราในฐานะผู้จัดการโครงการที่จะต้องเตรียมการและ ป้องกันความเสียหายที่อาจจะเกิดขึ้นได้จากเหตุการณ์นี้
7. ข้ามาคนเดียว
การอนุญาตให้พนักงานทำงานคนเดียวนั้นเป็นเรื่องที่เสี่ยงอย่างมาก เพราะอะไร? ก็เพราะว่าการทำงานคนเดียวนั่นจะเป็นอุปสรรคต่อการตรวจสอบ สอบถามและติดตามงานนั้นๆ ปัญหาที่จะตามมาก็คือเมื่อมีการนำงานของพนักงานคนนั้นมาเชื่อมต่อกับงาน อื่นๆแล้วอาจจะเกิดปัญหาใหญ่ขึ้นมาได้ ตัวอย่างเช่นถ้าพนักงานคนนั้นเป็นดีเวลลอปเปอร์ การออกแบบ interface นั้นไม่ตรงกับความต้องการลูกค้าหรือไม่ตรงกับมาตรฐานของทีม หรือถ้าพนักงงานคนนั้นเป็นเทสเตอร์ การออบแบบ test case ไม่ตรงกับสิ่งที่ดีเวลลอปเปอร์ทำไว้ เป็นต้น
เป็นหน้าที่โดยตรงของ ผู้จัดการโครงการที่จะต้องไม่ปล่อยให้เหตุการณ์เช่นนี้เกิดขึ้นระหว่างการ ดำเนินโครงการ ซึ่งคำแนะนำเพื่อป้องกันเหตุการณ์นี้ก็คือผู้จัดการควรจะมีการพูดคุยกับ พนักงานทุกคนเพื่อที่จะประเมินความสมัครใจในการทำงานเป็นทีมด้วยตัวเองเพื่อ ที่จะคัดกรองพนักงานได้อย่างมีประสิทธิภาพสูงสุด
หวังว่าบทความนี้จะมีประโยชน์กับเพื่อนๆบ้างนะครับ
ที่มา: http://www.projectsmart.co.uk
Technology Management Academy for Thais | Chapterpiece.com
Better Managing, Better Living