สอง พองานทั้งเยอะและใหญ่ก็ต้องใช้เวลานานในการทำเป็นเรื่องปกติ อย่างต่ำมีหกเดือนหรือเป็นปีแบบนี้ก็เห็นบ่อยไป … เริ่มเกิดเป็น Long Cycle และสุดท้ายพอทำเท่าไรไม่เสร็จซักทีเพราะความเยอะและใหญ่ จะเทสได้ยังไงล่ะ … เกิดเป็น Test Later

Requirement Document

Requirement Document ผิดอย่างไร — ตัวมันเองไม่ผิดหรอกครับ มันผิดที่คนใช้มากกว่า แต่ก่อนนั้นเราคิดว่าเอกสารฉบับนี้คือจุดเริ่มต้นของทุกสิ่งอย่าง ดังนั้นเราก็จะพยายามใช้เวลาเขียนมัน แก้มัน รีวิวมันอย่างมากมายเพราะคิดว่าพอเขียนเสร็จแล้วเราจะได้ใช้มันไปตลอดงานของเรา แต่จริงๆแล้วมันไม่ใช่เลย เพราะมันไม่ใช่ของจริง

• 80% ของเอกสารฉบับนี้เป็นตัวอักษร … 50% ของตัวอักษรเป็นอะไรก็ไม่รู้ที่ไม่เกี่ยวกับ Software, Requirement, Feature ใดๆทั้งสิ้น เช่นประโยคข้างล่าง (ผมแต่งเองนะ) มันบอกอะไรเราบ้างในมุมมองของ Software หรือ Programming สำหรับผมไม่ได้อะไรเลย แล้วเราก็เสียเวลาเขียน อ่าน รีวิว แก้
  

  Because the world is changing rapidly, our customers need to have a more flexible reporting system that can be integrated to world-class social networking websites, …

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

  ผม: ผมทำตาม Requirement Document นะครับ

  เค้า: ไม่ได้ คุณอย่าไปทำตามนั้น คุณต้องทำตามผมบอก

  ผม: อ่าว …

• เอกสารไม่มีปากมีเสียงครับ อยากจะแก้หรือจะเพิ่ม Feature อะไรลงไปทำง่ายมาก ก็แค่เพิ่ม Bullet ใน MS Word แล้วพิมพ์ไง ง่ายปะ? แต่ของจริงหละไม่ใช่เลย 1 Bullet อาจจะต้องใช้เวลาทำจริงๆ 1 เดือนหรือมากกว่านั้น
• บางสถานการณ์รู้ทั้งรู้ว่า Feature แบบนี้มันไม่น่าจะเวิร์คหรอก แต่ก็ทำอะไรไม่ได้เพราะลูกค้าจะเอา สุดท้าย Software เราก็จะกลายเป็นอะไรที่ใหญ่โตเทอะทะและมี Feature ที่ไม่มีคนใช้เต็มไปหมด
• 99% ของ Requirement Document คือเอกสารตายทันทีที่เขียนเสร็จ เพราะเมื่อเริ่มทำงานแล้วการแก้ไขจะเกิดขึ้นที่ระดับ Software ไม่ว่าจะที่ Design หรือ Coding เพราะนั่นคือของจริงที่จับต้องได้ แล้วทุกคนก็จะลืมเอกสารฉบับนี้ไป ไม่คิดจะกลับมาแก้ ไม่คิดแม้แต่จะกลับมาเปิดอ่าน … แล้วจะเสียเวลาเขียนทำไม?
• อันนี้น่าเห็นใจ บางคนรู้ครับว่าทำไปไม่ได้ประโยชน์แต่ก็ต้องทำเพราะมันเป็นกฎมันเป็นกระบวนการที่ถูกกำหนดไว้แล้ว

Test Later

Test Later ผิดอย่างไร — ผิดตรงที่เราจับ Developers แยกจาก Testers โดยยึด Requirement Document เป็นหลัก กว่าจะได้เจอกันอีกทีก็ตอนเริ่ม System Test หลังจากผ่านไปแล้วหลายเดือน

• หลายครั้งที่เขียน Test Case ออกมาแล้วไม่ตรงกับสิ่งที่เป็น Software จริง บางคนคิดว่า Developers เขียนโค๊ดผิด แต่ Developers ก็จะบอกว่าถูกแล้ว Requirement มันเปลี่ยนไปแล้วแต่ Testers ไม่รู้ เกิด Conflict กันขึ้นมา
• (ประสบการณ์ส่วนตัว) 85.96% Developers เขียนโค๊ดเสร็จไม่ทันตามแผน แล้วก็มาบีบเวลาของ System Test ให้เหลือน้อยลง สุดท้ายก็ต้องตัด Scope Test ออกแล้วก็ก้มหน้ารับสภาพกับ Software ที่ไม่มีคุณภาพกันไป
• บั๊กบานแน่นอนครับ ฟันธงเลย ทำไมเค้าเรียก Developers … เพราะเกิดมาเพื่อ Develop มั้งครับ ฮ่าๆๆ ขอโทษที่ Test ไม่เป็น (อาจจะทำเป็นแต่ไม่อยากทำ) ดังนั้น Unit Test อาจจะไม่มี แล้วปัญหาที่ดินพอกหางหมูมานานหลายเดือนจากการเขียนโค๊ดผิดๆจะมาโผล่ตอน System Test นี่แหละ
• พอบั๊กบานก็แก้ไม่ทันตามระเบียบ

Long Cycle

Long Cycle ผิดอย่างไร — ขอขยายความนิดนึงครับ Long Cycle ด้วยตัวเองไม่ผิดครับ มันผิดที่ Long cycle with one shot delivery นั่นคือทำงานไปนานแล้วค่อยปล่อยของออกมาทีเดียว

• ในส่วน Software ยิ่งใช้เวลาทำงานนาน เขียนโค๊ดสะสมไปเรื่อยๆบนความเข้าใจที่อาจจะเปลี่ยนไปแล้วใน Requirement ตัวนั้น จะทำให้มันยากที่จะเปลี่ยนแปลงแก้ไขครับ ดังนั้นถ้ามี Change เข้ามามันจะเจ็บปวดมาก ทั้งด้านร่างกาย (ทำกันใหม่) จิตใจ (เซ็ง) และกระเป๋าตังค์ (เสียเงินเพิ่มอะดิ)
• ในส่วน People ยิ่งทำงานนานแล้วไม่เห็นผลงานออกมาซักที มันเป็นการปั่นทอนกำลังใจอยู่ครับ ในทางจิตวิทยาแล้วผมคิดว่าการฉลองความสำเร็จถึงแม้จะแค่เล็กน้อยจะเป็นการช่วยสร้างแรงบันดาลใจที่ต่อเนื่องและยิ่งใหญ่ให้กับทีมงานได้
• ในส่วน Business ถ้าทำนาน ลงทุนเยอะ สุดท้ายขายไม่ออก อันนี้เจ๊งหนักเลยนะครับ หลายที่ถึงกับปิดบริษัทกันไปเลยก็มี

Am I Working on the Right Product?

การทำงานแบบนี้ทำให้เราขาดความสามารถในการตรวจสอบหา Idea Bug เพื่อตอบคำถามที่สำคัญที่สุดนั่นคือ “เฮ้ย นี่เรากำลังสิ่งที่มันควรจะทำจริงรึเปล่า?” “ไอ้ Software นี้มันเป็น Right Product ใช่มั้ย?”

ใครจะตอบคำถามนี้ได้ครับ? เจ้าของบริษัท … เจ้าของไอเดีย … Developer … Tester … Project Manager … ไม่ใช่เลยซักคนครับเพราะมีแต่ “ลูกค้า” เท่านั้นที่จะให้คำตอบเราอย่างชัดเจนและจับต้องได้มากที่สุด เคล็ดไม่ลับอยู่ตรงที่ว่า “ยิ่งรู้ช้า ยิ่งจ่ายแพง” เทียบกันนะ ถ้าจะเจ๊งจริงๆ เจ๊งตั้งแต่หกสัปดาห์แรกมันถูกกว่าเจ๊งตอนหกเดือนผ่านไปมากนักครับ ทั้งเงิน ทั้งแรง ทั้งกำลังใจ

ตรงนี้เองที่เป็นหลักการของแนวทางการทำ Software แบบใหม่ … Build – Measure – Iterate บทความหน้ามีกรณีศึกษาที่น่าสนใจมาฝากครับ

Related posts:

1. มารู้จัก Agile Development กันเถอะ
2. กระบวนการพัฒนาซอฟท์แวร์อย่างมืออาชีพ — ภาค5
3. Ideas of The Month — ว่าด้วยเรื่องของ Change

รูปนี้เป็นขั้นตอน Software Development ที่คุ้นเคยกันรึเปล่าครับ?

สาเหตุที่ทำให้ Product หรือ Feature ของเราลงท้ายด้วย 11. No one uses it. เกิดจากสาเหตุสามข้อครับ

1. Requirement Document — เรายึดถือมันเป็นต้นแบบในการทำ Software โดยไม่คิดถึงโลกความจริงและการเปลี่ยนแปลงที่เกิดขึ้นได้ตลอดเวลา
2. Test Later — เราคิดว่าความผิดพลาดมันจะเกิดขึ้นก็เฉพาะแต่ใน Software ดังนั้นเมื่อ Software ยังไม่เสร็จสมบูรณ์เราก็ยังไม่จำเป็นต้องเทสมัน
3. Long Cycle — เราคิดว่า Software ที่ดีต้องมี Features เยอะๆ ทำให้ต้องใช้เวลาในการทำ Project ยาวขึ้นเรื่อยๆ

เมื่อเข้าสู่วงจรนี้แล้ว เราจะมุ่งแต่จะผลิตและทดสอบ Software เป็นหลัก (เริ่มจากขั้นตอนที่ 3 ในรูป) เราคุยกันว่าจะมี Features อะไรบ้างใน Release นี้ เราคุยกันว่าจะต้องเพิ่มหรือลดอะไรมั้ย เราคุยกันว่าจะเทสมันยังไง เราคุยกันว่าจะแก้บั๊กตัวไหนบ้าง Performance มันจะดีมั้ย Scalability จะได้รึเปล่า ทั้งหมดคือการจัดการกับ Software และ Software Bug โดยที่เรามองข้ามไปเลยว่าสิ่งที่ยิ่งใหญ่และสำคัญกว่านั้นมากคือ Idea Bug (ขั้นตอนที่ 1 ในรูป) ซึ่งเป็นที่มาของ Wrong Product ที่ไม่มีใครใช้ แล้วมันจะมีประโยชน์อะไร

• ถ้าเราทำ Software ที่มี Features ระดับเทพเจ้า
• ถ้าเราทำ Software ที่ไม่มี Bug แม้แต่ตัวเดียว
• ถ้าเราทำ Software ที่ส่งได้ตรงเป๊ะตามเวลา
• ถ้าเราทำ Software ด้วยการใช้เงินลงทุนไม่ขาดไม่เกินซักบาท

เราจะทำอย่างไรให้รู้ได้ว่า Idea ที่เราคิดนั้นมันเป็นสิ่งที่ต้องการจริงๆของโลกใบนี้ต่างหากที่เป็นสิ่งสำคัญกว่าการจัดการ Software และ Software Bug ไปแล้ว และบทความนี้เป็นจุดเริ่มต้นของเรื่องสั้นที่ชื่อ Software Development 2012 (SD12) ที่จะพูดถึงแนวคิดนี้ทั้งหมด มีทั้งเรื่องธุรกิจและกระบวนการทำงานควบคู่กันไป … ติดตามต่อพรุ่งนี้ครับ

Related posts:

1. Operational Concept สำหรับ Software Requirement Analysis
2. SD12 — Long Cycle and Wrong Process

• แต่ละวัน เราได้อีเมล์กี่ฉบับ (อย่างต่ำมี 30) แล้วเราตอบกลับกี่ฉบับ (ไม่เกิน 10) แปลว่าอะไร เราขี้เกียจหรอ? ไม่แน่ ฮ่าๆๆ หรือ 67% ของอีเมล์ที่ได้มันไม่เกี่ยวกับเรา?
• แล้วเราเริ่มต้นส่งอีเมล์กี่ฉบับ (ไม่เกิน 10) เราขี้เกียจอีกรึเปล่า? ก็ไม่หรอกนะ แค่บางครั้งรู้สึกว่าอีเมล์ไม่ใช่ทางเลือกที่ดีที่สุด
• ต่อมา มีกี่อีเมล์ที่แค่เห็นหัวข้อ (Subject) แล้วก็กดลบทันทีแบบไม่ต้องคิด (เยอะครับ) … ไม่ได้บอกว่าผิดนะ ผมว่ามันเป็นวิธีการจัดการอีเมล์ที่ดีด้วยซ้ำไป
• มีกี่อีเมล์ที่เปิดมามีชื่อเราอยู่ใน cc list แล้วอ่านๆไปก็ อ่าว มันไม่เกี่ยวกับเราซักกะหน่อย (โชคดีที่มีไม่ค่อยเยอะ)
• มีกี่อีเมล์ที่เปิดอ่านแล้วก็จบไป ไม่ได้ทำอะไรต่อ แบบเป็นอีเมล์ประเภท FYI อะไรแบบนี้ (อันนี้เพีียบ)
• มีกี่อีเมล์ที่คิดว่าสำคัญแล้วก็เก็บไว้นานแสนนาน แต่ไม่เคยได้เปิดขึ้นมาอ่านเลย จนเมล์บ๊อกเต็มแล้วเต็มอีก (อันนี้เยอะมากกกและโดนเตือนบ่อยมากกก)
• สุดท้าย ตอนนี้ใน Inbox มี Unread อีเมล์กี่ฉบับ (โชคดี ตอนนี้ของผมไม่มีเลย)

1. อย่างแรกเลยที่ผมทำคือปิด Email Notification ถ้าอยากรู้ว่ามีใครส่งเมล์มามั้ย เดี๋ยวผมเปิดเองได้ ไม่ต้องเตือน มันช่วยให้เราลดสิ่งรบกวนในการทำงานไปได้หนึ่งอย่าง
2. แต่เพราะติดนิสัย ถึงแม้ไม่มี Email Notification แล้วผมก็ยังเปิดดูอีเมล์บ่อย (ทุกครั้งที่นึกได้แหละ) คิดไปคิดมา แล้วมันจะมีประโยชน์อะไรวะเนี่ยะ ว่าแล้ววันนี้มาแนวใหม่ครับ ปิดอีเมล์ไปเลย ปฏิญาณตนว่าจะเปิดชั่วโมงละครั้งพอ (ยังบ่อยไปมั้ย? ฮ่าๆๆ)
3. หลังๆมานี่ ผมเลิกอ่านเมล์ใน Blackberry ตอนเช้าระหว่างเดินทางมาทำงาน มันช่วยให้สมองผมปลอดโปร่งและคิดอะไรอื่นๆออกเยอะเลย แต่ก่อนพอขึ้นรถไฟใต้ดินปุ๊บ หยิบโทรศัพท์มาดูเลยว่ามีใครส่งเมล์เรื่องอะไรบ้างเมื่อคืน … บางวันอ่านแล้วเล่นเอามึนตึ๊บไปทั้งเช้าก็มี ฮ่าๆ
4. จัดกลุ่มอีเมล์ให้เป็นระเบียบครับ มันช่วยให้เก็บและค้นหาอีเมล์ได้ง่ายขึ้นเยอะมากๆ ส่วนใหญ่แล้วผมจะแบ่งกลุ่มอีเมล์แยกตาม Project และหัวข้อหรือกลุ่มคนที่เราต้องติดต่อด้วย
5. ผมทำเป็น Folder Template ไว้เลยใน Outlook ครับ พอเปิด Project ใหม่ก็แค่ Copy Template นั้นมา … พร้อมใช้
6. ถ้าทำได้ผมจะคุยผ่าน Instance Messaging กับคนที่เราจะติดต่อก่อน ให้ได้ข้อสรุป ถ้าดูแล้วจำเป็นต้องส่งอีเมล์ก็ค่อยส่งไปเป็นข้อสรุป
7. ถ้าไม่แน่ใจว่าควรส่งอีเมล์หรือไม่ … ลองดูรูปนี้ครับ เจ๋ง (source: http://www.onlineitdegree.net/email-overload/)

   

8. ถ้าต้องส่งอีเมล์ เลือก cc คนให้น้อยที่สุดเท่าที่จะทำได้ เลือกเฉพาะคนที่จำเป็นต้องรู้เรื่องพวกนี้จริงๆ … ปุ่ม Reply All ใช้ให้น้อยจะดีครับ
9. ปกติผมจะ Bcc ตัวเองไว้ด้วยนะ ขี้เกียจไปตามหาใน Sent Items
10. ลบอีเมล์ทันทีถ้าอ่านหัวข้อ (Subject) แล้วไม่เกี่ยวกับตัวเรา บางครั้งไม่แน่ใจก็คลิ๊กเข้าไปอ่านเนื้อหา ถ้าไม่เกี่ยวผมก็ลบเลยครับ เก็บไว้รกเปล่าๆ
11. มีบางสถานการณ์ที่เราต้องตอบอีเมล์แต่ยังมีข้อมูลไม่เพียงพอ ที่ผมทำคือเปิดอีเมล์นั้น กด Reply แล้ว Save Draft ให้มันอยู่ใน Draft Folder ไว้กันลืมครับ บ่ายๆพอได้ข้อมูลครบแล้วค่อยมาส่งตอบไป … ก่อนกลับบ้านก็อย่าลืมดูใน Draft Folder ด้วยนะว่ามีอะไรค้างอยู่บ้าง
12. ทุกเช้าวันจันทร์มันจะเป็น Email Clearance Sales ของผม มีสองอย่างครับ (1) ลบอีเมล์ที่ไม่จำเป็นทิ้งให้หมด และ (2) จัดเก็บอีเมล์ที่คิดว่ายังจำเป็นต่อการใช้อ้างอิงไว้ หลังจากการ Reply กันไปมา 10 ตลบ หลักการของผมคือเก็บเฉพาะอีเมล์สุดท้ายครับ แต่ แต่ ถ้าใน Thread เหล่านั้นมี Attachment ผมก็จะเก็บไว้หมดครับ

การมี Inbox ที่สะอาดๆมันทำให้ชีวิตดูเป็นระเบียบขึ้นเยอะเลย

Related posts:

1. มาเพิ่มประสิทธิภาพในการทำงานกันเถอะ – ภาค 1
2. ฟรี Project Management Template
3. Software Prototyping ภาค 1

• นั่งรอต่อไปให้คนที่สายทั้ง 7 คนนั้นมากันพร้อมหน้า หรือ
• ไม่รอ เริ่มประชุมไปเลยกับคนที่มาแล้ว 2 คน

กรุณาตอบด้วยความซื่อสัตย์ … ผมเลือกข้อสองอะ มันก็น่าจะดีไม่ใช่หรอที่รอให้มากันครบๆก่อนค่อยเริ่มประชุม หยุดตรงนี้ซักแป๊บ … ถ้าคิดเช่นนั้นลองดูเหตุผลตรงนี้ซักนิด

ต่อไปนี้ผมก็จะทำแบบนี้กับทุกประชุมที่ผมเป็นเจ้าของครับ … เริ่มจาก Chapterpiece.Meeting.5.5: The Future of Software Testing (again) เลยดีมั้ย?

Related posts:

1. Historical Data กับ Software Estimation
2. Chapterpiece.Meeting.3: User Story for Agile Development
3. ความสุขง่ายๆเริ่มได้ที่ Inbox

Related posts:

1. Requirement Traceability Matrix (RTM) คืออะไร?
2. Rocky Flats กับรางวัล Project แห่งปี 2006
3. Project Manager สำคัญแค่ไหนสำหรับ Facebook, Inc.