Home > การบริหารโครงการ > 7 วิธีปฏิบัติเพื่อความสำเร็จในการบริหารโครงการพัฒนาซอฟท์แวร์

7 วิธีปฏิบัติเพื่อความสำเร็จในการบริหารโครงการพัฒนาซอฟท์แวร์

สวัสดีครับ วันนี้ผมมีบทความดีๆเกี่ยวกับเคล็ดลับ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 ไม่ตรงกับสิ่งที่ดีเวลลอปเปอร์ทำไว้ เป็นต้น

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


หวังว่าบทความนี้จะมีประโยชน์กับเพื่อนๆบ้างนะครับ

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: