System Stakeholder

Influence_Analyst

System stakeholder

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

ตามมาตรฐาน ANSI/IEEE 1471  (เวอร์ชั่นล่าสุดคือ ISO/IEC/IEEE 42010) ในโครงการต้องระบุ stakeholder อย่างน้อยดังนี้

  • Acquirer หมายถึง ผู้ที่ถือลิขสิทธิ์ของระบบเมื่อระบบพัฒนาหรือติดตั้งเสร็จแล้ว
  • Maintainer หมายถึง ผู้ที่ดูแลระบบภายหลังติดตั้งและเริ่มใช้งานแล้ว
  • End User หมายถึง ผู้ใช้ระบบ
  • Developer หมายถึง ผู้พัฒนาระบบ ซึ่งรวมถึงที่ปรึกษาด้วย

นอกจากนี้อาจมี stakeholder ประเภทอื่นเพิ่มเติมได้ เช่น system owner หมายถึง เจ้าของระบบ ซึ่งอาจเป็นบุคคลหรือกลุ่มเดียวกันกับ acquirer ก็ได้, domain expert หมายถึง ผู้เชี่ยวชาญในสาขาหรือโดเมนนั้นๆ นอกจากนี้ในบ้านเรามักมี stakeholder แปลกๆ ผมชอบเรียกว่า ‘hidden stakeholder’ หรือพวกมือที่มองไม่เห็น มักเป็นบุคคลหรือกลุ่มบุคคลที่มีอิทธิพลต่อโครงการ สั่งซ้ายหันขวาหัน สั่งหยุด สั่งตัดงบฯ สั่งเปลี่ยนนู่นนี่นั่นได้ แต่มักไม่มีชื่ออยู่รายชื่อคณะทำงาน คณะกรรมการ สัญญา หรือในเอกสารใดๆ เลย ตรงนี้แหละที่ตอนรวบรวมความต้องการเราต้องสืบหาด้วยว่าโครงการนี้มี stakeholder ประเภทนี้บ้างไหม เพราะมักเป็นตัวเจ้าปัญหาเลยล่ะ

Domain Expert หรือบางทีก็เรียกว่า Subject Matter Expert (SME) มีแยกย่อยได้หลายประเภทแล้วแต่องค์กรนั้นๆ เช่น

  • ผู้เชี่ยวชาญด้านระบบงาน เช่น ระบบบัญชี
  • ผู้เชี่ยวชาญด้านความปลอดภัย
  • ผู้เชี่ยวชาญด้านฮาร์ดแวร์
  • ผู้เชี่ยวชาญด้านเน็ตเวิร์ก
  • ผู้เชี่ยวชาญด้าน software architecture
  • ผู้เชี่ยวชาญด้านวิเคราะห์ธุรกิจ

ดังนั้นในโครงการจึงควรมีการกำหนดว่าในโครงการมีโดเมนใดเกี่ยวข้องบ้าง แล้วจึงกำหนดผู้เชี่ยวชาญให้เหมาะสมในแต่ละโดเมน  การกำหนดโดเมนอาจไม่ได้ทำครั้งเดียว แต่ทำให้สอดคล้องกับแต่ละเฟสในโครงการไป แต่ถ้าเป็นไปได้รีบกำหนดให้เร็วและครอบคลุมที่สุดเท่าไหร่ยิ่งดี มีเทคนิคง่ายๆ (รึเปล่า?) แนะนำคือ การพิจารณาดูว่าในโครงการนี้มีองค์ความรู้หลักสำคัญอะไรที่เกี่ยวข้องบ้าง แล้วแบ่งแยกองค์ความรู้เหล่านั้นออกเป็นโดเมนๆ เช่น โดเมนระดับธุรกิจ ระบบงาน กระบวนการทางธุรกิจ แอพพลิเคชั่น ข้อมูล เทคโนโลยี ฮาร์ดแวร์ เน็ตเวิร์ก คุณภาพระบบ ซอฟต์แวร์ เวนเดอร์ กฎหมาย ความเสี่ยง เป็นต้น แล้วค่อยจำแนกเป็นโดเมนย่อยๆ ออกไปอีกที แล้วระบุว่าในฝั่งลูกค้าและฝั่งเรามีใครเชี่ยวชาญในโดเมนต่างๆ ที่ระบุไปบ้าง หากโดเมนใดไม่มี domain expert อาจต้องพิจารณาหาที่ปรึกษา หรือบุคคลภายนอก หรือพัฒนาบุคลากรที่มีอยู่ขึ้นมาเป็น domain expert สำหรับ domain expert ด้านระบบงานหรือระบบการทำงาน (ไม่ใช่ระบบไอที) ควรเป็นคนของฝั่งลูกค้า เพราะสมมติฐานง่ายๆ คือ ไม่มีใครเข้าใจงานของลูกค้าไปกว่าคนของลูกค้าเอง ไม่ว่าจะเป็นเรื่องโครงสร้างองค์กร วัฒนธรรม บุคลากร ความขัดแย้ง ลักษณะงาน ฯลฯ คนในย่อมรู้ดีกว่าคนนอก ดังนั้นให้พึงระลึกไว้เสมอว่า…เราคือคนนอก! ยกเว้นกรณีที่เราทำงานกับลูกค้ารายนี้มานานจนคุ้นเคยกันแล้ว

ใส่ความเห็น

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 / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s