ปัญหาการบริหารความต้องการในหลายองค์กร

เรื่องตลกแต่จริง ของการ transform requirement สู่ product ในวงการไอที

ปัญหาในการบริหารความต้องการที่ผมพบเจอในหลายองค์กรทั้งภาครัฐ เอกชน บริษัทไอที ทั้งขนาดเล็ก กลาง ใหญ่ มากว่า 15 ปีที่ผ่านมา มีมากมายมหาศาล จึงมานั่งสรุปหลักๆ ที่พบเห็นได้บ่อยครั้ง อาทิ ความชอบทำเอกสารกันแบบบ้าระห่ำ, การใช้คนไม่เหมาะสมกับงาน requirement, การเอาคนที่ทำงานหลายอย่างมาทำ requirement ด้วย, การทำนักไอทีไปเก็บ business requirement, การสร้างความร่วมมือกับลูกค้าไม่มีประสิทธิภาพ, การชอบทำงาน requirement analysis กับ system analysis ซ้อนทับกัน ทั้งที่มันคนละเรื่องกัน, การไม่ยอมทำ business modeling หรือวิเคราะห์ business process ก่อนทำ requirement ทั้งๆ ที่ทีมไม่มีความรู้ในระบบงานด้านนั้นๆ มาก่อนเลย, การตะบี้ตะบันเก็บแต่ functional requirement กันจนกองพะเนิน ขณะที่ไม่ค่อยจะเก็บพวก business requirement กับ non-functional requirement กันเลย, การวัดระดับความสำคัญของความต้องการโดยใช้ความรู้สึกส่วนตัวผสมกับอีโก้, การไม่ยอมเก็บรวบรวมคำศัพท์เฉพาะให้ทีมงาน (คำศัพท์สำคัญมากนะ) เคยเสียเวลาตั้งชื่อหัวข้อหรือฟังก์ชั่นเป็นสิบนาทีกันไหมล่ะ?, การเอานักไอทีที่มีทักษะการสื่อสารแย่พูดไม่รู้เรื่องไปเก็บความต้องการ, การยกยอสรรเสริญและให้น้ำหนัก ‘user’ จนเว่อร์, การมีช่องว่างระหว่างวัยและความรู้และทักษะระหว่าง system analyst (ที่แก่เอาๆ ขณะที่อ่านหนังสือและตามโลกน้อยลง) กับ programmer/developer (ที่เด็กลงๆ ขณะที่พูดจาไม่รู้เรื่องมากขึ้น อีโก้สูงปรี๊ด เป็นนักเทคนิคจัดจ้าน ระดับเทพแต่กลับเพิ่งอาบน้ำร้อนมาไม่กี่ขัน ความรอบรู้ระบบงานมีหยิบมือ), การพึ่ง MS Word กับ Excel เป็นเครื่องมือหากิน แต่กลับใช้มันแค่พิมพ์งาน, การไปนั่งถาม user ว่าอยากได้อะไร? มีความต้องการอะไร? มีปัญหาอะไร? แล้วจดๆๆๆ แล้วกลับมาพิมพ์ๆๆๆ แล้วส่งต่อๆๆๆ แค่นี้เองหรือ? งาน requirement เอ้อ ดันไปถามเขาว่าอยากให้ระบบทำอะไรได้บ้าง ดีนะที่ user ไม่ตอบกลับมาว่า ‘จะให้กูช่วยออกแบบระบบให้เลยมั้ย’ ฯลฯ

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

  • เน้นการเก็บ requirements มากไป และสร้าง output ที่ไม่สมบูรณ์พอ
    หลายองค์กรทำในส่วน requirement analysis กันน้อยไปหน่อย ทั้งที่สำคัญมาก พอเจอ change request ก็หน้าเหยเกแทนที่จะยิ้มสู้ เพราะทุกสิ่งบนโลกมันเปลี่ยนแปลงกันได้ และในอนาคตใครจะไปรู้ว่าจะเกิดอะไรขึ้น
  • เน้นงานสร้างเอกสารมากกว่าให้ความสำคัญกับการสร้าง output ที่จำเป็นจริงๆ
    ซึ่งคนไอทีก็ขึ้นชื่ออยู่แล้วว่าคุยไม่ค่อยรู้เรื่อง พูดยังไม่ค่อยจะรู้เรื่อง นับประสาอะไรจะเขียนให้คนอื่นอ่านได้เข้าใจง่ายๆ และบ้านเราเป็นอะไรไม่ทราบบ้าทำเอกสารกันเหลือเกิน ถึงขั้นที่ผมเคยเจอบางองค์กร หากทำเอกสารน้อยไปบางไปจะโดนมองหน้าโดนตำหนิ งานถ่ายทอด requirement ควรฝึกการสื่อสาร การสื่อสาร requirement ที่ดีที่สุดคือสื่อสารด้วย ‘ปาก’ ถ้าพูดแล้วไม่รู้เรื่องค่อยทำเอกสาร หรือทำเอกสารเพื่อกันลืม เพื่อเป็นหลักฐานหรือเอาไว้เก็บ
  • การสร้างความร่วมมือจากลูกค้าไม่มีประสิทธิภาพ
    ซึ่งต้องดึงผู้ใช้หรือลูกค้าให้ร่วมมือ เพราะถ้าพัฒนาระบบผิด เขาก็ต้องร่วมรับผิดชอบด้วย
  • ถูกแทรกแซงโดยปัญหาการเมืองภายในและภายนอก และการทุจริตคอร์รัปชั่น
    ประเด็นนี้เป็นกันหลายองค์กร ทั้งภาครัฐ ภาคเอกชน อย่าคิดว่าเอกชนไม่มี ขนาดองค์กรธนาคาร โทรคมนาคม บริษัทไอที โรงงาน ฯลฯ ก็มีเยอะแยะไป งาน requirement คืองานหนึ่งที่มักได้รับผลกระทบ
  • การซ้อนทับกันระหว่าง requirements analysis กับ system analysis
    requirement analysis เน้นวิเคราะห์ความต้องการเพื่อทำความเข้าใจ สิ่งที่ได้คือเอกสารหรือการสื่อสารให้ทีมงาน ส่วน system analysis เน้นวิเคราะห์ระบบเพื่อหา candidate solution แต่ชอบทำซ้อนกัน ทำพร้อมกัน หากสมาธิไม่ดีก็จะทำให้ทำสองอย่างนี้ปนกันตีกัน ดูได้จากเอกสาร มันจะสะท้อนให้เห็นเลยว่ามีสองเรื่องปนอยู่ในหัวข้อหรือย่อหน้าเดียวกัน งาน requirement เน้นที่ปัญหาและความต้องการ ส่วนงาน system analysis & design เน้นที่โซลูชั่น
  • การซ้อนทับกันระหว่างเฟส business modeling กับ requirements
    หลายคนชอบเริ่มโครงการด้วยการเรียนรู้หรือศึกษางานของลูกค้าหรือผู้ใช้ แต่แค่เรียนรู้ไม่พอ มันต้องวิเคราะห์พวก business process และประเด็นด้าน business ด้วย รวมถึงการเก็บพวก business rule, business goal/business requirement, การพิจารณาทำ business process reengineering หรือ business process improvement และยังต้องเก็บพวก business data หรือโครงการใหญ่ๆ อาจถึงขั้นต้องวิเคราะห์ทำความเข้าใจกับ business plan, business strategy, business case, business scenario กันทีเดียว เดี๋ยวนี้หลายองค์กรเลยมีตำแหน่งใหม่คือ business analyst แต่ปัญหาคือ ชอบเอาคนไอทีมาเป็น business anlayst ซึ่งไม่เวิร์ก คนไอทีที่ความรู้และประสบการณ์ยังไม่แตกฉานมักไม่เข้าใจ business aspect และไม่มี business sense ให้ไปคุยเรื่อง business แต่ในหัวก็คิดแบบคนไอที คนไอทีชอบคิดเชิงคุณภาพ แต่คุยเรื่อง business ต้องคิดเชิงปริมาณเป็น โครงการไหนทีมงานไม่มีความชำนาญหรือไม่มีความรู้ในงานที่จะทำ ก็ควรทำ business modeling ก่อน โครงการใหญ่อาจถึงขั้นต้องทำ business architecture เช่น จะพัฒนาระบบบัญชี ทีมงานไม่รู้เรื่องบัญชีเลย ก็ควรทำ business modeling ก่อน แต่ถ้ารู้เรื่องบัญชีกันดี ก็ตะลุยเริ่มเก็บความต้องการกันเลย แต่อย่าทำ business modeling กับ requirement ปนกัน หากไม่ชำนาญ
  • ขาดการวิเคราะห์ความต้องการเชิงธุรกิจ (business goals) และการทำ business model อย่างมีประสิทธิภาพ
    อย่างที่กล่าวถึงก่อนหน้า เราต้องเข้าใจเป้าหมายธุรกิจของลูกค้า เป้าหมายของโครงการ เข้าใจประเด็นต่างๆ ด้านธุรกิจ ไม่ใช่ไม่รู้เรื่องอะไรของเขาเลย อยู่ๆ ก็ตะลุยไปเก็บความต้องการ หลายองค์กรเลยที่ทีมพัฒนาพัฒนาระบบไป โดยไม่รู้เรื่องเลยว่าทำไปเพื่ออะไร ทำไมลูกค้าอยากได้ ระบบนี้จะช่วยผู้ใช้ได้อย่างไร ดีขึ้นแค่ไหน อย่างนี้ก็จะทำให้ทีมงานไม่มี ‘inner’ ไม่เกิดประสบการณ์ร่วมที่ดีในงานที่ทำ เหมือนทำๆ ไปงั้นๆ ทำงานตาม spec
  • เน้น requirements ด้าน functional มากไปโดยข้ามหรือไม่เน้น requirements ประเภทอื่นและมิติอื่น
    ความต้องการมีหลายประเภท คนส่วนใหญ่สนใจฟังก์ชั่นเป็นหลัก เพราะได้ใช้ และจับต้องได้ง่าย แต่ต้องเก็บความและบริหารความต้องการประเภทอื่นๆ ด้วยโดยเฉพาะ business goal และ non-functional requirement
  • ไม่มีการทำแบบสอบถาม หรือการสืบค้นความต้องการที่แท้จริงอย่างถูกต้อง
    ความเก็บต้องการบางประเภทหรือบางครั้งอาจต้องทำแบบสอบถาม การเก็บหรือสำรวจข้อมูลมีหลายวิธี เช่น สัมภาษณ์ ทำแบบสอบถาม ฯลฯ การเก็บความต้องการไม่ใช่ง่ายๆ แค่ไปนั่งคุยกัน ถามว่าอยากได้อะไร มีปัญหาอะไร แล้วจดๆๆๆ แล้วส่งๆๆๆ ต่อไปให้ทีมงาน ไม่ได้ อย่างนี้ไม่ได้
  • ขาดกระบวนการและการจัดการที่ดี ไม่สอดคล้องกับการทำ software architecture, การวางแผนโครงการ และอื่น ๆ
    software process และ software development lifecycle (SDLC) สำคัญมาก หลายองค์กรอุตส่าห์ทำ CMMI บ้าง ทำ Agile บ้าง หลายรายก็ประสบความสำเร็จดี แต่ส่วนใหญ่ไปติดแหงกกับกรอบวิธีการ กลายเป็นเอางานมาเป็นหนูทดลอง หรือมัวแต่ทำงานที่มันไม่ได้งาน เช่น มัวแต่ทำเอกสารเยอะแยะมากมาย การบริหารความต้องการควรสอดคล้องกับแนวทางออกแบบและสร้าง software architecture และแผนโครงการ
  • ไม่สามารถวิเคราะห์แบบย้อนกลับ (traceability) ระหว่าง software artifact ต่าง ๆ กับ requirements ได้
    ความต้องการต่างๆ ที่เก็บมาต้องสามารถเชื่อมโยงไปยัง software artifact ต่างๆ ได้ เช่น source code, screen, test case, design solution, function, mechanism, database table, system feature ฯลฯ เห็นหลายองค์กรที่ทำ CMMI ทำ traceability แบบขอไปที ใช้ Excel ทำ แต่ไม่ค่อยได้เอามาใช้ประโยชน์ ทำแค่เพื่อให้ได้ทำจะได้ประเมินผ่าน ทั้งที่ traceability สามารถช่วยบริหาร change, risk, impact ได้ดีมาก และช่วยทำ defect management ได้ดีมาก
  • การวัด (measure) requirements ขาดการวิเคราะห์อย่างมีประสิทธิภาพ
    เวลาคุยกันถามกันว่าความต้องการตัวไหนสำคัญมากสำคัญน้อยกว่ากัน ส่วนมากมักใช้ความคิดเห็นส่วนตัว หรืออาศัยประสบการณ์ส่วนตัว หรืออีโก้ แต่มันมีหลักการอยู่ เช่นการทำ requirement measurement, requirement prioritization ซึ่งควรทำให้สอดคล้องกับ software architecture ใน process แบบ Unified Process หรือใน process แบบ Agile บางกรณีต้องให้ architect เป็นคนจัดลำดับความสำคัญ คนเก็บก็เก็บไป ส่วนคนจัดลำดับความสำคัญให้เป็น architect ทำ เพราะ architect ต้องมองความเสี่ยงของระบบโดยรวมออก ต้องมองเห็นแก่นของระบบ และความสำคัญของความต้องการแบ่งออกได้เป็นหลายมิติ อาทิ ระดับการส่งผลกระทบต่อธุรกิจ, ระดับการส่งผลกระทบสถาปัตยกรรม, ระดับความจำเป็นเร่งด่วน, ระดับความยากง่าย, ระดับความเสี่ยง, ระดับความเสถียรหรือความนิ่ง (ไอ้ที่ชอบถามๆ กันไง ว่า requirement ตัวนี้นิ่งหรือยัง?) เป็นต้น
  • ขาดการรวบรวมและกำหนดคำศัพท์สำคัญ (vocabulary / key abstraction / domain object)
    คำศัพท์ ก็คือความต้องการชนิดหนึ่งนะ ต้องให้ความสำคัญกับการรวบรวมคำศัพท์ด้วย ไม่ใช่โยนภาระนี้ให้โปรแกรมเมอร์คิด บ่อยครั้งที่ผมเจอโปรแกรมเมอร์หลายองค์กรที่เขียนโปรแกรมไป คิดคำศัพท์ไป เปิด dictionary ไป นั่งผสมคำสร้างคำกันเองเลย ถูกบ้างผิดบ้าง ปกติต้องสร้างเอกสาร Glossary Document เพื่อรวบรวมคำศัพท์ เป็นเหมือน dictionary หรือพจนานุกรม และไหนๆ ก็ทำแล้ว ควรระบุไปด้วยเลย ว่าคำศัพท์แต่ละคำมีรายละเอียดอะไรบ้าง อาทิ data type, format, data constraint, คำย่อ, คำอธิบาย, คำภาษาไทย, คำภาษาอังกฤษ (อย่าลืม เรายังต้องเขียนโปรแกรมด้วยภาษาอังกฤษอยู่)
  • เน้นการออกแบบฐานข้อมูล (ER diagram และ schema) โดยมีทัศนคติและแนวคิดแบบ ‘Database Driven Design’ มากไป
    หากคนทำ requirement เป็นคนเดียวกับคนออกแบบระบบ เช่น system analyst ก็มักชอบออกแบบ ER data model ก่อนออกแบบระบบ และเอางานออกแบบ data model มาปนกับงาน requirement โดยเฉพาะในการหาคำศัพท์ การรวมรวมข้อมูล บ่อยครั้งเตลิดไปจนถึงเผลอคิดหา primary key, foreign key, โครงสร้างข้อมูล เร็วเกินไป ซึ่งจริงๆ แล้วควรออกแบบระบบในระดับภาพรวมหรือระดับสถาปัตยกรรมก่อน ไม่ใช่ออกแบบ ER data model ก่อนแล้วค่อยไปออกแบบระบบ จะทำให้กลายเป็นไปออกแบบระบบภายใต้กรอบของ ER data model และหากอยากเก็บข้อมูลเพื่อไปประกอบการออกแบบระบบ ควรเน้นไปที่การเก็บพวก business rule, data constraint หรือพวก data characteristic อาทิ data security, data confidentiality, data flexibility, data connection, data operation, data pool, data replication ฯ พวกนี้มีผลต่อการทำงานของระบบมากกว่า data structure มากนะ
  • ผู้รับผิดชอบมีทัศนคติและแนวคิดเชิงเทคนิคมากไป, ขาดทักษะภาษาและการสื่อสารที่ดี และมักใช้คนที่มีวุฒิภาวะไม่เหมาะสม
    โดยทั่วไปคนทำ requirement มักเป็นคนเดียวกับคนออกแบบระบบ เช่น system analyst คราวนี้ถ้าแบ่งสมาธิในการทำงานไม่ดี ก็มักคิดปนกันในหัว ไม่รู้ว่าตอนนี้กำลังสวมหมวกเป็นคนทำ requirement หรือเป็นคนออกแบบระบบ ทำให้ความคิดเชิงเทคนิคเข้ามาแทรก และการทำงานด้านนี้ต้องมี soft skill โดยเฉพาะความสามารถด้านการสื่อสารที่ดีมากๆ ทั้ง พูด ฟัง อ่าน เขียน รวมถึงภาษากาย เช่น บุคลิกภาพ การแต่งตัว หรือแม้แต่ลายมือ และทักษะการวาดภาพกรอบ นอกจากนี้หลายองค์กรชอบส่งเด็กๆ ไปเก็บความต้องการ ไม่ดีไม่ได้อย่างทำ คนที่ไม่มีวุฒิภาวะหรือมีน้อย คือ คนที่ไม่รู้ว่าอะไรควรถาม อะไรควรพูด มักจับประเด็นไม่เก่ง และที่สำคัญ มักไม่รู้จักกาลเทศะ ซึ่งสำคัญมากในงานที่ซีเรียส
  • ผู้รับผิดชอบต้องรับผิดชอบภาระมากหลายด้าน
    หลายองค์กรชอบจัดสรรทีมงานในแบบ vertical เพราะง่ายและประหยัด และอีกสาเหตุคือหัวหน้าในองค์กรในบ้านเรามักไม่เก่งหรือบริหารคน โดยเฉพาะเรื่อง ‘put the right man on the right job’ ที่เจอได้บ่อยเลยคือ คนหนึ่งทำหลายอย่าง หลายองค์กรเลยที่คนทำ requirement ต้องออกแบบระบบด้วย เขียนโปรแกรมด้วย บางทีต้องบริหารโครงการอีก และบ่อยครั้งต้องทดสอบระบบเองด้วย พอทำหลายอย่าง และไม่ได้ฝึกสมาธิมาดีพอ ก็จะจับจด ไม่สามารถแบ่งแยกการทำงานและบริหารเวลาและบริหารตัวเองได้ดีพอ จนมั่วกันไปหมด
  • ผู้รับผิดชอบขาดทักษะเชิงธุรกิจและการจัดการ
    ดังที่กล่าวไปก่อนหน้า การทำงานด้าน requirement ควรมีความเข้าใจด้านการตลาดและธุรกิจพอสมควร ต้องรู้เชิงปริมาณ เพราะงาน requirement ในมิติหนึ่งคืองานขายโซลูชั่น ดังนั้นต้องขายของเป็น ไม่ไปเก็บๆๆๆ แล้วจดๆๆๆ แล้วส่งต่อๆๆๆ คนทำงานด้านนี้ต้องมีความสามารถด้านการบริหารจัดการสูง บ่อยครั้งผมมักแนะนำองค์กรต่างๆ ว่ารับคนจบบริหารมาทำดีกว่า แล้วฝึกอบรมด้านไอทีเสริมเข้าไป เวิร์กกว่าเอาคนไอทีมาทำด้านนี้เยอะ ค่าจ้างถูกกว่าด้วยนะเออ เพราะคนไอทีบริหารจัดการและสื่อสารไม่เก่ง น้องๆ หมอและพอๆ กับวิศวกรน่ะ
  • ขาดการกำหนดบทบาทของบุคลากรสำคัญ เช่น domain expert, stakeholder และให้ความสำคัญกับ ‘USER’ มากไป
    user ไม่ใช่พระเข้า และ user ไม่ใช่ทุกสิ่งทุกอย่างของโครงการ user เป็นแค่ผู้ใช้งานระบบ ซึ่ง user เป็นเพียง stakeholder ประเภทหนึ่งเท่านั้น ในโครงการยังมี stakeholder อีกหลายประเภท ที่เราต้องไปเก็บรวบรวมความต้องการ นอกจากนี้ user โดยทั่วไปมักมีนิสัยเหมือนเด็ก คือ ชอบเอาแต่ใจตัวเอง ยิ่งอายุยิ่งมากยิ่งงอแงเหมือนเด็ก ธรรมชาติของ user มักชำนาญในงานที่ตนรับผิดชอบ แต่มักไม่ชำนาญไม่เข้าใจในภาพรวม และคนสมัยใหม่ไม่ค่อยคิดถึงประโยชน์ส่วนรวมเท่าไหร่ เป้าหมายการพัฒนาซอฟต์แวร์ไม่ใช่เพื่อเอาใจ user แต่เพื่อเอาใจองค์กร เพื่อให้องค์กรมีศักยภาพยิ่งขึ้น
  • มีช่องว่างระหว่างผู้รับผิดชอบ (system analyst) กับโปรแกรมเมอร์มากไป
    สมัยนี้มีเรื่องน่าตลกคือ system analyst (โดยเฉพาะองค์กรภาครัฐ รัฐวิสาหกิจ และ บริษัทไอทีขนาดใหญ่) มักมีอายุเยอะขึ้นทุกทีๆ (เกิน 35 ปี) ขณะที่โปรแกรมเมอร์ก็เด็กลงๆ ทุกทีๆ ซึ่ง system analyst ยิ่งอายุเยอะ ยิ่งอ่านหนังสือน้อย ตามเทคโนโลยีไม่ทัน คุยกับเด็กเทคนิคไม่รู้เรื่อง แต่…ลูกค้าชอบ เพราะ system analyst อายุเยอะ ผ่านโลกมามาก เลยพูดคุยง่ายกว่านักไอทีเด็กๆ ใช้เวลาเข้าใจระบบลูกค้าเร็ว แต่พอไม่เอาเทคนิคแล้วไม่ตามแล้ว ทำให้ประสานงานกับโปรแกรมเมอร์เด็กเทคนิคติดขัด ขณะที่โปรแกรมเมอร์เด็กเทคนิคยิ่งพวกเจเนอเรชั่นใหม่ ยิ่งพูดจาไม่รู้เรื่อง คุยยาก มีมุมมองและภาษาแบบตัวเอง เลยทำให้เกิดช่องว่างระหว่างกันมาก สิ่งสะท้อนที่เห็นได้ชัดเจนคือ งานเอกสารที่ system analyst ทำ มีแต่สาระ ‘เมฆๆ’ มีเนื้อหาเบาหวิว หนักไปทาง business และความต้องการที่มีประเด็นเทคนิคน้อยนิด และ system analyst ประเภทนี้ก็มักออกแบบระบบแบบกว้างเป็นทะเล มีแค่ ER data model สไตล์โบราณๆ, data flow โบราณๆ, สเป๊กหน้าจอ, คำบรรยายอธิบายหน้าจอว่าต้องทำอะไรได้บ้าง, สรุปฟังก์ชั่นระบบออกมา แล้วเรียกทั้งหมดว่า design spec บ้าง functional spec บ้าง สุดท้าย system analyst ประเภทนี้จริงๆ ไม่ได้ออกแบบระบบเลย หรือออกแบบเป็น conceptual design มากๆ คนออกแบบระบบจริงๆ คือโปรแกรมเมอร์ ถ้าเก่งก็โชคดีไป ถ้าโครงการไม่ใหญ่มากก็โชคดีไป ถ้าไม่เก่งแล้วโครงการใหญ่มากมีโปรแกรมเมอร์หลายคนมาก ความบรรลัยและมั่วซั่วจะบังเกิด ที่น่าปวดร้าวใจสำหรับผมที่เจอมาเลยก็คือ system analyst หลายองค์กร ไม่ตามภาษาโปรแกรมแล้ว ระบบที่ตัวเองออกแบบต้องใช้ภาษาโปรแกรมนั้นเขียน เช่น VB .NET แต่ตนเองกลับไม่รู้เรื่อง VB .NET สักกระผีก พวก data type, data structure, algorithm ลืมหมดแล้ว ฝังลงหลุมไปหมดแล้ว แต่ดันมารับผิดชอบงานออกแบบระบบ และยังทำหน้าที่เก็บและบริหารความต้องการอีก โอละพ่อ ไปกันใหญ่ ส่วนโปรแกรมเมอร์เด็กนักเทคนิคจัดจ้านเดี๋ยวนี้ก็อีโก้เยอะ ความอดทนน้อย มีอะไรกระทบจิตใจหน่อยไม่ได้ ไม่งั้นออก เฮ้อ… วิธีแก้มีครับ ผมให้คำแนะนำหลายองค์กรไปบ่อยๆ ไว้จะมาเล่าสู่กันในบทความแยกต่างหากนะครับ ใบ้ให้ง่ายๆ คือ ให้ system analyst ลงมาหน่อย ให้โปรแกรมเมอร์ขึ้นไปนิด แล้วไปเจอกันตรงกลาง
  • การจัดการองค์ความภายรู้ภายในองค์กรและทีมไม่มีประสิทธิภาพ
    อันนี้เรื่องใหญ่ การฝึกอบรมและพัฒนาความสามารถของทีมงานอย่าต่อเนื่องเป็นสิ่งสำคัญ พอทำเอกสาร requirement ออกมา มักมีคนเข้าใจบ้าง ไม่เข้าใจบ้าง แต่ร้อยละร้อยคนที่ไม่เข้าใจมักตอบว่าเข้าใจเมื่อถามว่าเข้าใจไหม? แล้วความเป็นจริงก็ค่อยมาโผล่ตอนทำงาน หลายองค์กรในบ้านเรามักมีคนเก่งน้อยกว่าคนไม่เก่ง คนเก่งหลายคนมักมีอีโก้ และไม่รอเพื่อน ทำให้การทำงานไม่สมดุลย์ งาน requirement เป็นงานที่ต้องทำให้ทุกคนในทีมเข้าใจเป็นไปในทิศทางเดียวกัน ช่วยกันพัฒนาระบบจนเสร็จตามที่กำหนด สิ่งหนึ่งที่จะช่วยได้คือการฝึกทีมเวิร์ก
  • ขาดการใช้เครื่องมือ (tool) ที่มีประสิทธิภาพในการจัดการ requirements
    เห็นใช้ MS Work, Excel กันส่วนมาก แต่ใช้แค่บันทึกความต้องการเฉยๆ ควรประยุกต์ tool กับงาน ส่วน tool ด้าน requirement โดยเฉพาะก็มี ช่วยผ่อนแรงได้เยอะ เช่น ช่วยทำ traceability, document generating, impact analysis, measurement เป็นต้น ถ้าไม่มีหรือไม่ซื้อ ก็ใช้ MS Excel นั่นล่ะ เอามาเขียนสูตรเขียน Macro ใส่เข้าไป ก็ช่วยได้เยอะ ไม่ใช่แค่เอาไว้พิมพ์ลงตาราง และอย่างที่กล่าวข้างต้นที่หลายองค์กรมัวแต่ทำเอกสาร ผมสอนและให้คำปรึกษาด้านนี้ทีไรเจอคำถามเรื่อง template เป็นประจำ ทำเอกสาร requirement specification ไม่ต้องมี template ก็ได้ แค่ให้รู้หัวข้อที่ต้องอธิบายก็พอแล้ว พอมี template ก็ชอบไปนั่งเทียนพยายามเขียนโน่นนี่นั่นลงไปในหัวข้อ ไม่ให้มันว่างเปล่า ได้ออกมาเป็นเอกสาร requirement specification ที่ดูดีมีชาติตระกูล หลายองค์กรถึงกับได้มาตรฐาน CMMI Level 3, 4, 5 ซึ่งอาจใช้หลอกลูกค้า แต่หลอกผมยาก ไม่ใช่ว่าโม้ว่าตัวเองเก่ง แต่เพราะผมทำงานด้านนี้อยู่ เป็นอาจารย์ เป็นที่ปรึกษา ทำงานสายพัฒนาซอฟต์แวร์มาทุกบทบาท และเป็นนักเขียนและบรรณาธิการสารคดีนิตยสารรายหนึ่งอยู่ ดังนั้นจะทำเอกสารมาหลอกผม…ยากกก…

ใส่ความเห็น

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