Project Management and Software Development Blog for Thais

ความเดิม

ความเดิมจากบทความที่ผมขอให้เพื่อนๆร่วมแชร์ประสบการณ์ว่าทำไม Automated Testing ล้มเหลวนั้น ต้องขอบคุณคุณ AMp และคุณ zyracuze ที่ช่วยออกความคิดเห็นที่ผมก็เห็นด้วยว่าเป็นสาเหตุที่สำคัญของความล้มเหลวที่เกิดขึ้นเลยหละครับ ผมเองก็รวบรวมข้อมูลจากแหล่งอื่นๆด้วยก่อนสรุปมาเป็น 4 สาเหตุสำคัญที่ทำให้ Automated Testing ล้มเหลวพร้อมทั้งแนวทางป้องกันปัญหา

1. หนุ่ม-สาว QA ไม่ใช่ Developer

คงไม่ใช่เรื่องยากเท่าไรที่จะเขียน Test Script ที่สั่งให้โปรแกรมเปลี่ยนจากหน้าหนึ่งไปอีกหน้าหนึ่ง หรือตรวจสอบดูว่ามีข้อความนี้อยู่บนหน้าจอหรือไม่ แต่มันไม่ง่ายเท่าไรครับในการที่จะเขียน Test Script ที่ฉลาดพอที่จะทดสอบ input ได้ทุกรูปแบบและวนไปทุก field ที่มีบนหน้านั้นๆ รวมไปถึงการเขียน Test Script ที่เื้อื้อต่อการ reuse และ maintenance ครับ

ซึ่งคุณ zyracuze ก็ได้แสดงความเห็นไว้อย่างชัดเจนครับว่า Programming Skills เป็นปัจจัยสำคัญที่จะช่วยให้ QA ทำ Automated Testing ได้สำเร็จครับ

แนวทางป้องกันปัญหา:

• หา Developer จริงๆมาเป็นพี่เลี้ยงในช่วงแรกๆเพื่อแนะนำให้ QA วางโครงสร้างของ Test Script ได้อย่างถูกต้อง (reusability และ maintainability)
• QA ที่รับผิดชอบ Test Script ควรจะมี Programming Skills ด้วย
• จัดเวลาให้ QA หาความรู้เิพิ่มเติมเกี่ยวกับ Programming Practices

2. Automated Test นั้นเปราะบาง

การดูแลรักษา (maintenance) Test Script นั้นเป็นงานที่เสียเวลามากเพราะว่า Automated Test Script นั้น “เปราะบาง” และ “โง่” ครับ การแก้ User Interface นิดเดียว เช่น ชื่อปุ่ม หรือ warning message อาจจะทำให้ Test ทั้งหมดของเรา Fail ได้เลยครับ ถ้าอยากจะใช้งานมันได้ต่อไป เราก็ต้องมาคอยแก้ Test Script เรื่อยๆ

นึกภาพว่า QA ต้องสร้าง Test Cases, เตรียม Test Scripts, ตรวจสอบผลการ Test, และแก้ Test Scripts ทุกครั้งที่ระบบมีการเปลี่ยนแปลง กระบวนการตรงนี้เสียเวลามากกว่าทำ Manual Testing แน่ๆครับ

แนวทางป้องกันปัญหา:

• แก้ไข Test Script ให้ตรงกับการทำงานจริงๆของระบบอยู่เรื่อยๆ พยายามฝึกให้เป็นนิสัยครับ มันง่ายกว่ามากที่เราจะแก้วันละ 1 Test เมื่อเทียบกับการรอให้เวลาผ่านไป 1 สัปดาห์แล้วค่อยมานั่งแก้ทีเดียวเป็น 10-20 Test ครับ
• ตกลงกับ Developer ว่ากรุณาอย่าแก้ Interface (ไม่ว่าจะเป็น User Interface หรือ API Interface) ทุกๆวัน … หรือถ้าจะแก้จริงๆก็ให้บอกกันก่อนครับ

3. Automated Test ที่ซับซ้อนและเกี่ยวพันกันมากเกินไป

เป็นเรื่องง่ายครับที่จะเขียนให้ 1 Automated Test Case สามารถตรวจสอบได้หลายๆ Feature ของระบบ แต่แย่หน่อยครับ…ทำไมหนะหรอ? หนึ่งเป็นเรื่องยากมากๆเลยที่จะดูแลรักษา Test Case ที่ว่านี้ถ้าระบบมีการเปลี่ยนแปลงบ่อยๆ สองถ้า Test Case นี้ fail มันจะยากมากขึ้นในการหาสาเหตุว่าทำไมถึง fail ครับ และสามมันจะกลายเป็นฝันร้ายเลยครับถ้าเราเขียน Automated Test Case ไปขึ้นกับ Test Case ก่อนหน้าและก่อนหน้าครับ

เหตุผลที่จุดนี้เป็นปัจจัยอีกอย่างที่ทำให้ Automated Testing ล้มเหลวก็เพราะว่าเราต้องเสียเวลาอย่างมากในการทำ maintenance, และการหา reproducing steps เมื่อ fail จนสุดท้ายกลับกลายเป็นว่าทำ Manual Testing คุ้มค่ากว่าครับ ดังนั้นเราจึงควรทำให้ Automated Test Case นั้นไม่ซับซ้อนและเป็นอิสระต่อกันให้มากที่สุดครับ มีคนพูดไว้ว่า “ถ้าคุณไม่สามารถอธิบายจุดประสงค์ของ Test Case ได้ด้วยคำ 5 คำหละก็ Test Case ของคุณซับซ้อนเกินไปแล้ว” Test Case ของเพื่อนๆตอนนี้ซับซ้อนเกินไปรึเปล่าครับ?

แนวทางป้องกันปัญหา:

• เขียน 1 Automated Test Case เพื่องาน 1 งานเท่านั้น ห้ามขาดห้ามเกิน
• เขียน Automated Test Case ให้เป็นอิสระต่อกัน นั่นจะทำใ้ห้เราสามารถ Run Test Case ไหนก็ได้และเมื่อไรก็ได้ ผลจะออกมา Pass หรือ Fail ก็จะไม่ขึ้นกับ Test Case อื่นๆด้วย
• แตก Feature ให้ย่อยๆลงมาเพื่อง่ายต่อการเขียน Test Case และเตรียม Test Data ไว้ให้แต่ละ Test Case เลย

4. Automated Test ที่ไม่ค่อยมีประโยชน์

ทั้งคุณ AMp และคุณ zyracuze มีความเห็นตรงกันว่าปัจจัยนี้เป็นหนึ่งในสาเหตุสำคัญที่ทำให้ Automated Testing ของเราล้มเหลวครับ ผมขอขยายความนิดนึงเกี่ยวกับคำว่า “ไม่่ค่อยมีประโยชน์” นั้นหมายถึงว่า เราไปทำ Automated Test Case สำหรับส่วนงานที่ไม่สำคัญ และไม่ถูก Retest บ่อยๆนั่นเองครับ

แนวทางป้องกันปัญหา:

• เลือก Test ในส่วนที่สำคัญก่อน ถ้ามีเวลาเหลือจริงๆค่อยมาพิจารณาส่วนอื่นๆ
• ต้องเตรียมแผนที่ชัดเจนเกี่ยวกับ Test Coverage

สรุป

ทั้ง 4 ข้อนี้คือสาเหตุหลักๆที่ทำให้ Automated Testing ล้มเหลวหรือไม่ประสบความสำเร็จตามที่เราคาดหวังไว้ครับ หวังว่าจะเป็นประโยชน์กับเพื่อนๆทุกคนที่สนใจหรือประยุกต์ใช้ Automated Testing อยู่นะครับ

เหตุการณ์ที่เกิด

หนึ่งในปัญหาที่ท้าทายของ Project Manager ส่วนใหญ่ก็คือการที่ไม่สามารถจะพูดว่า “ไม่” นั่นเองครับ (ใจดี ปฏิเสธใครไม่เป็น) ลองพิจารณาจากตัวอย่างนี้นะครับ ลูกน้องเดินเข้ามาหาเราพร้อมกับปัญหาของเขา

ที่พูด: “หัวหน้าครับผมมีปัญหาแบบนี้ครับ ผมอยากจะได้คำแนะนำจากหัวหน้าอะครับ”

แต่ที่คิด: “หัวหน้าครับผมมีปัญหาแบบนี้ครับ ช่วยแก้ปัญหานี้ให้ผมหน่อยซิครับ”

อ่าว … แย่หละซิครับ ถ้าเราไม่เอะใจแล้วปล่อยเลยตามเลยจากปัญหาเขาจะกลายมาเป็นปัญหาเราแบบไม่รู้ตัวครับ เราจะจัดการกับสถานการณ์นี้ยังไงดี? (ท่องไว้ในใจเลยครับว่า คนจริงใจต้องนิ่ง )

หนึ่ง

พยายามตัดปัญหาที่ไม่เกี่ยวกับตัวเรา หรือเราไม่จำเป็นต้องเข้าไปเกี่ยวข้องออกไปซะ คงไม่ถึงขนาดตัดเยื่อใยไม่ช่วยหรอกนะครับ แต่อาจจะเป็นการแนะนำคนที่เขาควรจะไปคุยด้วยจริงๆให้มากกว่า

สอง

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

สาม

ถ้าเราจำเป็นจะต้องเข้าไปติดตามตรวจสอบปัญหานั้นอย่างต่อเนื่องหละก็บอกลูกน้องไปว่าการตัดสินใจต่างๆที่จะเกิดขึ้นเป็นการตัดสินใจร่วมกันระหว่างเขาและเราและปัญหานั้นก็ยังเป็นของเขาอยู่ จากเหตุการณ์ข้างบน เราอาจจะบอกเขาเพิ่มเติมไปว่า “ถ้าคุณ ก.ตอบมาแล้ว เรามาคุยเรื่องนี้กันอีกทีนะ” เป็นต้นครับ

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

วันนี้ผมมีแบบทดสอบว่า “คุณเป็น Project Manager ที่ดีแล้วหรือยัง?” มาฝากกันครับ ที่มาของบทความนี้ก็ไม่มีอะไรมากครับ แค่ผมมานั่งนึกว่า “อยากรู้เหมือนกันนะว่าตอนนี้เราเป็น Project Manager ที่ดีแล้วหรือยัง? เรายังมีจุดบกพร่องตรงไหนอยู่อีกบ้าง?” ผมก็อ่านมาบ้างนะครับ บทความที่พูดถึงคุณสมบัติที่ดีของ Project Manager แต่ก็ไม่ค่อยเห็นภาพเท่าไร เอาแบบนี้เลยดีกว่าครับ แบบทดสอบของ Project Manager โดยเฉพาะ หวังว่าจะถูกใจเพื่อนๆนะครับ

แบบทดสอบ

แบบทดสอบข้างล่างนี้มี 10 ข้อซึ่งเกี่ยวข้องโดยตรงกับทักษะที่สำคัญที่สุดที่ใช้ในการบริหาร Project โดยเฉพาะอย่างยิ่ง Project ที่ใหญ่และซับซ้อน คำถามข้างล่างนี้เขียนออกมาในรูปแบบที่ง่ายต่อการตอบว่า “ใช่” หรือ “ไม่” ถึงแม้ว่าจะมีบางส่วนไม่สามารถชี้ขาวชี้ดำได้หรือบางข้อที่คุณไม่เคยประสบพบเจอมาก่อน ลองพิจารณาอย่างรอบคอบว่าถ้าสถานการณ์นี้เกิดขึ้น คุณจะทำอย่างที่แบบสอบถามบอก “ใช่” หรือ “ไม่”

[ใช่/ไม่] คุณไม่มีการวางแผนที่ดีเท่าไรเพราะว่าคุณมองตัวเองเป็นคนทำงานมากกว่าเป็นคนวางแผนงาน หลายๆคนเป็นคนที่ชอบทำงาน เมื่อพวกเขาได้รับมอบหมายงานอย่างแรกที่เค้าจะทำก็คือกระโดดลงไปทำงานนั้นๆทันที

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

[ใช่/ไม่] คุณพยายามที่จะหาข้อแก้ตัวเมื่อมีปัญหาแทนที่จะแสดงความรับผิดชอบ Project Manager บางคนก้าวออกมาเพื่อรับผิดชอบกับเรื่องราวทุกอย่างที่เกิดขึ้นใน Project ที่พวกเขารับผิดชอบอยู่ ในขณะที่บางคนชอบที่จะไม่ทำเช่นนั้น สำหรับคนกลุ่มหลัง พวกเขาจะสามารถหาเหตุผลร้อยแปดว่าทำไมงานไม่เสร็จ ทำไมงานมีปัญหา คุณเป็นแบบไหน? คุณพยายามที่จะปัดปัญหาออกไปจากความรับผิดชอบของตัวเอง หรือคุณแสดงออกถึงความรับผิดชอบทั้งกับเรื่องดีและเรื่องไม่ดี และพยายามที่จะหาทางกำจัดเหตุที่ทำให้เกิดปัญหาและความล้มเหลวเหล่านั้น?

[ใช่/ไม่] คุณเป็นคนที่ทำตามคำสั่งของลูกค้าอย่างเคร่งครัดโดยไม่พยายามปรับใช้การบริหารความเปลี่ยนแปลงใน Project (Scope Change Management) พฤติกรรมที่เน้นให้ลูกค้าเป็นศูนย์กลาง (client-focus) ในความหมายของคุณคือการทำทุกอย่างที่ลูกค้าต้องการใช่หรือไม่? หรือว่าคุณใช้หลักบริหารความเปลี่ยนแปลงมาช่วยในการจัดการกับความต้องการของลูกค้า?

[ใช่/ไม่] คุณมักจะปล่อยให้ปัญหาขยายวงกว้างจนกลายเป็นหายนะใช่หรือไม่? คุณเป็นคนชอบผลัดวันประกันพรุ่งใช่หรือไม่? คุณมักจะมองปัญหาที่เกิดขึ้นว่าเป็นเรื่องน่ารำคาญและอยากให้มันหายไป? คุณจะใส่ใจปัญหาที่เกิดขึ้นก็ต่อเมื่อมันเริ่มลุกลามจนกระทั่งก่อให้เกิดผลกระทบกับ Project ใช่หรือไม่?

[ใช่/ไม่] คุณไม่มีการทำแผนงานหรือคุณไม่ได้อัพเดทมันบ่อยๆ นี่เป็นหนึ่งในปัญหาที่พบได้ทั่วไป Project Manager หลายคนมีการทำแผนงานขึ้นมาแต่ว่าพวกเขาไม่เคยกลับไปอัพเดทแผนนั้นหรือว่าปล่อยปะละเลยมันไประหว่าง Project ถ้าพวกเขาถูกถามถึงงานที่เหลืออยู่ใน Project พวกเขาก็จะมีแต่คำตอบที่ไม่ค่อยชัดเจนและไม่สามารถวัดปริมาณงานที่เหลือออกมาเป็นตัวเลขที่ชัดเจนได้

[ใช่/ไม่] คุณยอมที่จะส่งงานที่มีคุณภาพต่ำลงแทนที่จะยืนยันว่าคุณต้องการเวลาในการทำงานเพิ่ม หลายๆ Project ทำเสร็จในเวลาและงบประมาณที่กำหนด แต่คุณภาพที่ได้ออกมาไม่ค่อยดีนัก Project Manager เหล่านี้ขอที่จะส่งงานให้ทันเวลาและยอมไปแก้ปัญหาที่เกิดขึ้นในระบบที่ใช้จริง (Production) คุณเป็นหนึ่งในพวกเขาเหล่านี้ใช่หรือไม่?

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

[ใช่/ไม่] คุณไม่สนใจความเสี่ยงของ Project ถึงแม้ว่าความเสี่ยงบางตัวจะมองเห็นตั้งแต่เริ่ม Project ก็ตาม Project Manager หลายคนไม่คิดว่าการบริหารความเสี่ยง (Risk Management) เป็นความรับผิดชอบของพวกเขา ในขณะที่ Project Manager บางคนก็มีการระบุถึงความเสี่ยงที่มีแต่ก็ไม่ได้ทำอะไรกับมันต่อจนกระทั่งสายไป

[ใช่/ไม่] คุณสื่อสารแค่เฉพาะข้อมูลหรือเรื่องราวที่สำคัญเท่านั้น เป็นเรื่องน่าประหลาดที่ Project Manager หลายๆคนคิดว่าการสื่อสารเป็นหนึ่งในงานที่น่าเบื่อ สมาชิกในทีมของพวกเขาอาจจะทุ่มเททำงานได้อย่างยอดเยี่ยมน่าชื่นชมแต่พอถึงเวลาต้องสื่อสารจริง พวกเขากลับเลือกที่จะเขียนรายงานสั้นๆแทนที่จะเป็นการพูดคุย พวกเขาจะไม่ค่อยมีการประชุมเพื่อติดตามความก้าวหน้าของงาน ถ้า Project ของคุณต้องการการสื่อสารอย่างเข้มข้น คุณจะพร้อมรับความท้าทายนี้หรือว่าคุณจะรู้สึกหงุดหงิดกับคนที่คอยมาถามถึงความก้าวหน้าของงาน?

ให้คะแนน

เอาล่ะ มารวมคะแนนข้อที่คุณตอบว่า ?ใช่? แล้วมาดูผลกันเลย

?0? ถ้าคุณไม่ตอบ ?ใช่? เลยซักข้อ … คุณมีโอกาสสูงทีเดียวที่จะเป็น Project Manager ที่ประสบความสำเร็จ

?1? อืมมม คุณไม่ Perfect แต่ก็ไม่หมดหวังซะทีเดียวหรอกนะ พยายามให้มากขึ้นกับข้อที่คุณตอบว่า ?ใช่? แล้วคุณจะกลับมาตอบคำถามเหล่านั้นว่า ?ไม่? อย่างเต็มภาคภูมิ

?2? นี่คือเส้นแบ่งเขตแดนเลยหละ ขึ้นอยู่กับว่าคุณตอบ ?ใช่? กับสองคำถามไหน คุณจะสามารถขจัดจุดอ่อนได้ด้วยการพยายามทำให้ตรงข้ามกับความหมายของสองข้อนั้น

?มากกว่า 2? ถ้าคุณตอบ ?ใช่? มากกว่า 2 ข้อขึ้นไป คุณต้องกลับมาปรับเปลี่ยนแนวคิดเกี่ยวกับ Project Management ของคุณแล้วหละ นี่ไม่ได้หมายความว่าคุณเป็นคนไม่ดีหรือใช้ไม่ได้หรอกนะ แต่คุณควรตั้งคำถามถึงความรู้ของคุณเกี่ยวกับการเป็น Project Manager ที่ดี หรือตั้งคำถามเกี่ยวกับแรงบันดาลใจที่จะทำงาน Project Management ของคุณ บางทีคุณควรจะพยายามปรับปรุงการทำงานและกลับมาทำแบบทดสอบนี้อีกครั้งหลังผ่านไปหกเดือนนะ

สรุป

คำถามทั้งหมดข้างบนเป็นข้อมูลที่เล่าต่อกันมาซึ่งใช้เพื่อการแสดงถึงจุดอ่อนที่พบได้มากใน Project Manager การตอบว่า ?ไม่? ทั้งหมดไม่ได้การันตีว่าคุณจะประสบความสำเร็จในการเป็น Project Manager อย่างไรก็ตาม การตอบ ?ใช่? กับบางคำถามจะชี้ให้เห็นถึงจุดที่จะทำให้ Project ของคุณอยู่ในความเสี่ยง โดยเฉพาะกับ Project ที่ใหญ่และซับซ้อน

เพื่อนๆลองทำแบบทดสอบแล้วได้ผลยังไงบ้างครับ? บอกกันบ้างน้าาา

ปล. ที่มาของแบบสอบถามอยู่ที่นี่ครับ

Before

ตอนศึกษา คิดวิเคราะห์ ไตร่ตรองก่อนที่จะวางแผนอย่างดี เรามั่นใจเลยว่า Automated Testing จะช่วยเราได้ … รู้จ่ะรู้ว่าช่วงแรกๆมันต้องลงทุนสูง ก็แน่ซินะ ทั้งเตรียมโค๊ดให้พร้อม ทั้งเขียน Test Script ประสบการณ์ก็ไม่ค่อยจะมี แต่ไม่เป็นไรๆ เราหว่านพืชหวังผลระยะยาวอยู่แล้ว คอยดูนะ เดี๋ยวเราจะเอากราฟข้างล่างนี้ไปให้หัวหน้าดู อิอิ

After

อืมมม ทำไมนะ เราว่าเราก็ศึกษามาดีแล้วนี่ วางแผนก็น่าจะใช้ได้ ตอนทำจริงก็ทุ่มเทกันสุดๆ … แล้วทำไมเป็นแบบเนี่ยะ??? (ใครจะกล้าเอาไปโชว์หัวหน้าหละ ) อยากรู้จังเลยว่าเราทำอะไรผิดไป

Your Opinions

สวัสดีครับ ผมคิดว่าเหตุการณ์ข้างบนคงเกิดขึ้นกับเพื่อนๆหลายคนเลย (รวมตัวผมเองด้วย) วันนี้ผมจึงขอใช้บทความนี้เพื่อเป็นการรวบรวมความคิดเห็นและประสบการณ์ของ เพื่อนๆเกี่ยวกับคำถามที่ว่า ทำไม ทำไม Automated Testing ถึงล้มเหลว? ลองช่วยกันหาสาเหตุดูครับ แล้วผมจะมาสรุปใ้ห้ตอนท้ายอีกทีครับ

ขอบคุณมากๆครับ

ปล. ผมดัดแปลงรูปมาจาก http://wonam.exteen.com/20090224/automated-testing ขอบคุณต้นฉบับครับ

Requirement Changes vs. Project Risk

Software Development Project เป็นการทำงานที่มีความเสี่ยงสูงอยู่ในตัวมันครับ ซึ่งความเสี่ยงนี้จะมีผลทำให้โอกาสที่ Project จะประสบความสำเร็จลดลง ผลการสำรวจจาก Standish Group ชี้ให้เห็นว่า 53% ของ Project ไม่ประสบความสำเร็จ (ไม่ทางใดก็ทางหนึ่งครับ) เช่น ใช้งบประมาณเกิน เสร็จช้ากว่ากำหนด หรือมี feature ไม่ครบตามที่ได้ตกลงไว้ตั้งแต่แรก เป็นต้น

หนึ่งในความเสี่ยงที่สำคัญที่สุดของ Software Development Project ก็คือความเสี่ยงที่เกิดจาก Requirement Changes นี่แหละครับ ดูจากข้อมูลและความคิดเห็นของกูรูทั้งหลายได้

Barry Boehm: A Top 10 List of Software Risk Item

Requirement Changes: High change threshold, information hiding, incremental development (deferring changes to later increments).

John McManus and Trevor Wood-Harper: Key Reason Why Projects Get Cancelled

Poor requirements management: Our earlier research elaborated on the symptoms of information systems project failure in three specific areas: frequent requests by users to change the system; insufficient communication between the different members of the team working on the project and the end users (stakeholders); and no clear requirements definitions.

รู้แล้วว่า Requirement Changes สร้างความลำบากให้เราขนาดนี้ … มาหาทางป้องกันกันซักหน่อยดีมั้ยครับ?

ป้องกันที่1: ติดต่อและพูดคุยกับลูกค้าอย่างสม่ำเสมอ

Requirements ที่ถูกรวบรวมไว้เมื่อสามเดือนก่อน พอมาถึงวันนี้อาจจะใช้ไม่ได้แล้วครับ การเปลี่ยนแปลงนั้นเกิดขึ้นได้จากหลายสาเหตุอย่างที่ผมได้กล่าวไว้ในบทความนี้ ปัญหาจะยิ่งรุนแรงขึ้นถ้าเรามารู้ภายหลังว่างานที่ทำมาตลอดสามเดือนนั้นเสียเปล่าเพราะ Requirement เปลี่ยนไปแล้ว

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

• ระัดับผู้จัดการ (Manager Level): เราควรจะเข้าไปพูดคุยกับผู้จัดการฝ่ายต่างๆที่เกี่ยวข้องกับ Project ที่เราทำอยู่อย่างสม่ำเสมอครับ (อาจจะเป็นอาทิตย์เว้นอาทิตย์ก็ได้) นอกจากจะได้รับรู้ถึงความเคลื่อนไหวในระดับการบริหารงานซึ่งอาจมีผลให้เกิด Requirement Changes แล้ว เรายังได้คะแนนพิเศษจากความใส่ใจที่มีให้ลูกค้าด้วยครับ
• ระดับพนักงาน (IT Staff Level): ระบบส่วนใหญ่ไม่ได้สร้างมาให้ผู้จัดการใช้หรอกครับ ต้องนี่เลย เหล่า IT Staff ต่างหาก ลูกค้าตัวจริงฮะ เราก็ควรจะสร้างสัมพันธ์กับพนักงานเหล่านี้ไว้ด้วยครับ เราควรสังเกตว่าลูกค้าตัวจริงของเราทำงานอะไรอยู่ และมีกระบวนการทำงานอย่างไร ประโยชน์ก็เพื่อจะได้ตรวจสอบว่าจะมีโอกาสเกิด Requirement Changes รึเปล่า อีกอย่างก็เพื่อที่จะตรวจสอบดูว่าความต้องการของผู้จัดการและพนักงานตรงกันหรือไม่ ถ้าเราดูแล้วไม่ชอบมาพากลก็ต้องรีบแจ้งผู้จัดการครับ เพราะว่านี่เป็นจุดเริ่มต้นของปัญหาที่ชัดเจนมากๆ

ป้องกันที่2: ส่งงานใ้ห้ลูกค้าดูบ่อยๆ

ยากครับที่ใครจะมองเห็นทะลุปรุโปร่งจากในกระดาษว่า “นี่แหละ สิ่งที่ฉันต้องการ” นั่นคือสิ่งที่เราใส่ลงไปใน System จริง (ถึงแม้ว่าจะตรงกับ Requirement Specification) อาจจะไม่ใช่สิ่งที่ลูกค้าต้องการแบบ 100% ครับ ดังนั้นเพื่อเป็นการเปิดโอกาสให้ลูกค้าได้พูดว่า “ใช่เลยๆ ผมต้องการแบบนี้” หรือ “เ่่อ่อ ผมคิดว่าตรงนี้ไม่ค่อยถูกต้องเท่าไรนะ” เราควรจะส่งงานให้ลูกค้าดูบ่อยๆครับ

การป้องกันที่2นี้ไม่ได้มีวัตถุประสงค์เพื่อจะทำให้ไม่เกิด Requirement Changes แต่เป็นการป้องการไม่ให้เกิด Requirement Changes ขนาดใหญ่ยักษ์ซึ่งส่งผลกระทบรุนแรงกับ Project ของเราครับ

ป้องกันที่3: แบ่งงานเป็นส่วนย่อยๆ

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

• เวปไซต์จัดหางาน
  • ระบบล๊อกอิน
  • ระบบค้นหาข้อมูล
    • ค้นหาด้วยชื่อตำแหน่ง
    • ค้นหาด้วยชื่อบริษัท
    • ค้นหาด้วยกลุ่มงาน
      
  • ระบบสมัครงาน
  • ระบบแจ้งเตือนอัตโนมัติ
  • อื่นๆ
    

วันรุ่งขึ้นมีคนมาคุยกับผมว่า “สวัสดีครับ วันนี้มาดูเรื่องระบบการค้นหาด้วยชื่อตำแหน่งงานกันนะครับ ผมคิดว่าเราน่าจะค้นหาแบบ Case Sensitive นะครับ คุณคิดว่ายังไงฮะ?” ผมจะรู้สึกดีกว่า “สวัสดีครับ วันนี้เรามาดูเรื่องเวปไซต์จัดหางานกันครับ เริ่มที่ไหนกันดีครับ?” จริงๆแล้ว Agile Development มีหลักการแบ่งงานเป็นส่วนย่อยๆที่ดีมากครับ แล้วผมจะหาโอกาสมาขยายความเรื่องนี้นะครับ

ประโยชน์ที่เห็นได้ชัดอีกอย่างของการแบ่งงานเป็นส่วนย่อยๆนั่นคือทำให้เรามีโอกาสส่งงานให้ลูกค้าดูได้อยู่เรื่อยๆซึ่งจะเป็นผลดีในระยะยาวในการป้องการ Requirement Changes ขนาดใหญ่ยักษ์ได้ด้วย

ป้องกันที่4: ลดความเสี่ยงด้วย operational concept

เพื่อเป็นการสร้าง requirement ที่สมบูรณ์ (complete), ชัดเจน (clear), และถูกต้อง (valid) ซึ่งจะช่วยลดโอกาสที่จะเกิด Requirement Changes ลงได้ ระหว่างการพูดคุยลองประยุกต์ใช้ Operational Concept มาช่วยดูครับ

ป้องกันที่5:???

ผมมั่นใจว่ายังมีวิธีการป้องกัน Requirement Changes อีกมากมายครับ เพื่อนๆเคยใช้วิธีไหนบ้างครับ?