ถ้าใครสนใจอยากให้ผมไปพูดบรรยายหัวข้อเรื่องเหล่านี้ติดต่อผมทาง Facebook Message ได้เลยครับ

  • Agile Development, Scrum, Kanban, อื่นๆ
  • Lean Start-Up
  • Software Development Process
  • Project Management

บรรยายในรูปแบบกลุ่มย่อย สำหรับนักเรียนนักศึกษา สำหรับองค์กรและบริษัทได้หมด … ไม่คิดค่าเหนื่อยครับ :D

Question?

Posted by kannique On March - 19 - 2014ADD COMMENTS

กับงาน New Product Development หรือ Product Enhancement รู้สึกยังไงคำถามที่ลงท้ายด้วยคำว่า “จะเสร็จเมื่อไร?” ครับ ผมมีความรู้สึกแปลกๆกับคำถามนี้มาสักพักแล้ว โดยเฉพาะอย่างยิ่งเมื่อคำถามนี้ถูกถามในทีมที่บอกว่าประยุกต์ใช้หลักการ Agile และ Lean ในการทำงาน … เหตุผลมีดังนี้

  1. “จะเสร็จเมื่อไร?” เป็นคำถามที่บอกเราว่างานนี้ Fix Scope / Flexible Schedule ถ้าผมตอบว่า 6 เดือนแล้วมันเป็นคำตอบที่คนถามพอใจมันมีนัยยะว่าเรามั่นใจมากเลยนะว่า Scope (หรือ Requirement) ที่เราคิดไว้มันจะถูกต้องโดนใจลูกค้าแบบ 100% แต่ความจริงมันเป็นเรื่องน่าเศร้าที่ 80% มันจะไม่ถูกต้อง คำถามนี้มันเป็นการขัดขวางการเรียนรู้จากข้อมูลจริงเพียงอย่างเดียวที่มีในโลกซอฟท์แวร์นั่นคือความคิดเห็นและความพึงพอใจของลูกค้าเพราะกว่าเราจะรู้ว่า Scope มันห่วยก็ต้องใช้เวลาอย่างน้อย 6 เดือน ++ นี่คือ Waste ที่ยิ่งใหญ่ที่สุดในโลก
  2. “จะเสร็จเมื่อไร?” เป็นคำถามปลายปิดที่ไม่มีประโยชน์อะไรเลย มันเป็นการสร้างความกดดันอย่างยิ่งให้คนที่ต้องถูกบังคับให้ตอบแล้วสวนใหญ่คนที่ต้องตอบจะเป็นคนที่ไม่ได้ทำงานเอง ถามว่าเค้าเอาคำตอบมาจากไหน ก็ (พูดให้สุภาพหน่อยว่า) คาดคะเนอย่างมีการศึกษา (Educational Guess) ซึ่งในความเป็นจริงแล้วก็นั่งเทียนกันทั้งนั้น ปัญหาที่ตามมาคือคนถามก็เอาคำตอบนี้ไปยึดมั่นถือมั่นมากว่ามันต้องเป็นตามนั้น (เค้าก็ไม่ผิดหรอก เค้าก็เลือกที่จะเชื่อตามที่เราบอกอยู่แล้ว) ทีนี้ถ้าไม่ได้ตามนั้นหละ ตามสูตรก็มีอาจจะมีบทลงโทษกันบ้าง แล้วที่ขำคือเค้าก็ถามใหม่ว่า “อะ แล้วมันจะเสร็จเมื่อไร?” 555 กลับเข้าวงจรเดิม

ถ้าเราเป็นคนต้องถาม เรามีทางเลือกอะไรบ้าง … ผมคิดได้สองทางครับ

เปลี่ยนคำถาม

เปลี่ยนคำถามเป็น “ภายในเดือนเมษายนนี้ คิดว่าจะทำอะไรเสร็จบ้าง?” คำถามนี้เป็นการเปลี่ยนมุมมองการทำงานจากเดิมเป็น Fix Schedule / Flexible Scope มันช่วยในหลายๆเรื่องครับโดยเฉพาะอย่างยิ่งทำให้คนทำงานทุกคนรู้ว่าเป้าหมายเรามีร่วมกันคือไม่ว่าอะไรจะเกิดขึ้นเราต้อง Release วันที่ 30 เมษายน มันเป็นคำถามที่จะช่วยให้ทุกคน (หวังว่านะ) มานั่งคุยกันว่า เฮ้ย เรามีเวลาแค่นี้เราควรทำ Requirement ไหนก่อนหลังยังไง อะไรที่ทำแล้วจะเกิดคุณค่าทางธุรกิจสูงสุด แน่นอนมีเรื่องต้องพูดคุยถกเถียงกันมากแต่ผมว่าเป็นการถกเถียงที่ได้ประโยชน์กว่าตบตีกันเรื่องงานจะเสร็จเมื่อไรนะ


เปลี่ยนแนวคิด

ลดๆการถามคำถามปลายปิดอย่าง “จะเสร็จเมื่อไร?” มาเป็นคำถามปลายเปิดมากขึ้น … ตอนนี้ผมคิดได้หนึ่งคำถามนั่นคือ

ในช่วงเวลาที่ผ่านมา เราเรียนรู้อะไรบ้าง?

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

  1. หาทางทดสอบ Idea บ่อยๆ (Release Often)
  2. หาทางเลือกทำเฉพาะสิ่งที่สำคัญจริงๆก่อน (Prioritization)
  3. หาทางวัดผลและเรียนรู้จากสิ่งที่ได้ทำ (Continuous Improvement)

คำตอบที่ได้อาจจะสร้างความประหลาดใจให้คนถามก็ได้นะ เช่น

  1. ลูกค้าไม่ชอบหน้าตา App แบบนี้
  2. ลูกค้าไม่ใช้ Feature ที่เราเพิ่งทำไปเลย แนวคิดนี้ห่วยแตก เลิกทำซะเถอะ เสียเวลา
  3. ลูกค้าส่วนใหญ่เราเป็นผู้หญิงหวะ แบบนี้ควรออกแบบ App ให้มี UI น่ารักๆดีมั้ย มาลองทำดูใน Sprint หน้าดีกว่า
  4. ลูกค้าเราไม่ใช้ Feature นี้เลย เอาออกดีมั้ย?
  5. Activation Rate เพิ่มขึ้น 50% เลยหลังจาก Release Feature นี้ไป แสดงว่าเค้าต้องชอบแนวนี้แน่ๆ ทำต่อเลยครับ
  6. งานเยอะไปนะพี่ ผมไม่พอใจกับ Quality เลย Sprint หน้าลดลงหน่อยได้มั้ย ผมจะได้มีเวลาจัดการกับ Quality ให้ดีกว่านี้
  7. อื่นๆ

ในอีกมุมนึง คำตอบที่ได้จากคำถามนี้มันเอามา Reuse ได้ Share ได้ Develop ต่อได้ … แล้วคำถามที่ว่า “จะเสร็จเมื่อไร?” หละ มันเอามาทำแบบนี้ได้มั้ย ฮ่าๆ ถึงวันนึงเราเป็นคนที่ต้องถามคำถาม … ถ้าเลือกคำถามที่ว่า “ในช่วงเวลาที่ผ่านมา เราเรียนรู้อะไรบ้าง?” ได้ก็จะเป็นพระคุณกับคนทำงานอย่างสูง

ขอบคุณครับ

Start Small

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


Build Cross Functional Team

เริ่มจากเล็กๆแปลว่าจำนวนคนต้องไม่เกิน 5 คน 10 คน หรือ 20 คนก็ได้ … สาระสำคัญไม่ได้อยู่ตรงนั้นเท่าไร เช่น บริษัท Start-Up ในอุตสาหกรรมซอฟต์แวร์โดยทั่วไปจะมีคนอยู่สองขั้วมาจับคู่กัน คนนึงมีแนวคิดทางธุรกิจ คนนึงมีความสามารถเรื่องเทคโนโลยี ช่วงเริ่มต้นไม่มีเงินทุนไปจ้าง Sales, จ้าง Support, จ้าง Marketing, จ้าง Accountant, จ้าง Finance, จ้าง HR, จ้าง Web Designer หรือ Graphic Designer และอื่นๆ แล้วเค้าทำยังไง? มีสองทาง หนึ่ง Outsource บางงานออกไป หรือสอง ทำเอง ตรงทำเองนี่แหละสาระสำคัญเพราะมันคือการสร้าง Cross Functional Team ขึ้นมาแล้ว คนที่มีแนวคิดทางธุรกิจซึ่งสุดท้ายจะพัฒนาตัวเองไปเป็น CEO มีความสามารถพอที่จะดูแลเรื่อง Product, Sales, Customer Support, Marketing, Strategy, Finance, และอื่นๆ ได้ ในขณะที่คนที่เก่งเรื่องเทคโนโลยีซึ่งกำลังจะกลายเป็น CTO ดูแลได้ทั้งเรื่อง Architecture, Development, Testing, Technical Support, Hardware, Graphic Design, อื่นๆ


เมื่อมีการทำงานแบบ Cross Functional ความชัดเจน โปร่งใสในแนวทาง แนวคิด ข้อมูล การสื่อสารรวมถึงปัญหาจะเกิดขึ้น สิ่งนี้สำคัญมากที่จะผลักดันให้งานออกมาอย่างมีคุณภาพและลดปัญหาเรื่องความขัดแย้งต่างๆ เช่น Product ที่ได้ออกมากับ Marketing Plan ไปกันคนละทาง หรือ Sales ไปขายของไว้อย่างนึงแต่ Developer ทำออกมาเป็นอีกแบบนึง

กลับมามองในองค์กรใหญ่ มันจำเป็นด้วยหรอว่าความว่า Cross Functional Team คือคนแค่สองคน ไม่ใช่แน่นอน สาระสำคัญของมันคือพยายามให้ทีมนี้ประกอบด้วยคนจากแต่ละหน่วยงานที่เกี่ยวข้องให้ได้มากที่สุดในปริมาณเหมาะสมที่สุด มันคือการสร้างความสมดุลระหว่างองค์ความรู้และจำนวนคน เป็นทั้งศาสตร์และศิลป์ในตัวเอง

Hire Them Yourself

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


สิ่งที่สำคัญไม่แพ้กันคือ Culture หรือวัฒนธรรมองค์กร ด้วยการทำงานแบบเดิมๆบนวัฒนธรรมแบบเดิมๆผลลัพธ์ก็ออกมาแบบเดิมๆอย่างที่เห็น ถ้ามันไม่ดีพอก็ต้องเปลี่ยนแปลงและคนกลุ่มนี้จะเป็นกำลังสำคัญของการเปลี่ยนแปลงนี้ ดังนั้นเค้าต้องเป็นตัวแทนของคนรุ่นใหม่ที่ถ่ายทอดวัฒนธรรมใหม่ทีดีกว่าเดิมออกมาได้อย่างชัดเจนเพื่อเป็นตัวอย่างให้คนอื่นๆเห็น ไม่ว่าหลักการมันจะเป็นอะไรก็ตาม Customer First (ลูกค้าต้องมาก่อน), Employee First (เพื่อนพนักงานต้องมาก่อน), Innovation (นวัตกรรม), Technology-Driven (ไฮเทคเข้าไว้), Continuous Improvement (พัฒนาอย่างต่อเนื่อง), และอื่นๆ … Tony Hsieh (Zappos) และ Jack Dorsey (Twitter, Square) เน้นถึงความสำคัญเรื่องนี้ไว้อย่างชัดเจน

Tony Hsieh: เราไม่เลือกเค้าด้วยเหตุผลว่าเค้าเป็นคนเก่งเพียงอย่างเดียว ที่สำคัญไม่แพ้กันคือเค้าต้องเข้ากับวัฒนธรรมองค์กรของเราได้ ในทางกลับกันเราเลือกที่จะไล่คนที่ไม่เข้าใจในความเป็น Zappos ออกไปถึงแม้เค้าจะเก่งแค่ไหนก็ตาม … Performance Review ของเรา 50% จะพิจารณาจากการที่คุณซึมซับและมีชีวิตอยู่ในองค์กรด้วย Value และ Culture ของเราหรือไม่

Jack Dorsey: สิ่งที่สำคัญสำหรับผมในฐานะผู้นำคือ “Edit your team” — วัฒนธรรมขององค์กรคือ Product ที่มี Feature เป็นไปตามทีมงานที่คุณเลือกมา เลือกจะจ้างใคร เลือกจะไล่ใคร เลือกจะโปรโมตใคร


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

แล้วประสบการณ์หละไม่ต้องพิจารณาเลยหรอ? มันเป็นดาบสองคมในกรณีนี้ บางคนที่มีประสบการณ์มากทำงานกับสิ่งนั้นมานานจนทำให้มุมมองถูกจำกัดด้วยเรื่องเก่าทฤษฏีเก่า ถ้าเราเลือกคนที่ไม่มีประสบการณ์เลยมาเป็นส่วนหนึ่งของทีมนี้หละ น่าสนใจนะ ไม่รู้อะไรเลย ไม่มีทฤษฎีอะไรเลย ไร้เดียงสาเหมือนเด็กน้อย และหลายครั้งที่เด็กน้อยตั้งคำถามที่ทำเอาผู้ใหญ่ที่มีประสบการณ์มากมายต้องอึ้ง … แนวคิดนี้ขอยืมจาก Google

Report Only To You

การเปลี่ยนแปลงไม่มีความแน่นอน มันคือการลองผิดลองถูก พูดให้ดูดีอีกนิดคือการลองผิดลองถูกแบบมีทฤษฎีสนับสนุน อย่างไรก็ตามไม่มีทางที่อะไรจะราบรื่นอย่างที่หวังและเมื่อปัญหาเกิดขึ้นเราควรต้องรับรู้ทุกเรื่อง พยายามเข้าใจทุกอย่างเพื่อหาทางแก้ไขร่วมกับทีมงาน ก็ในเมื่อทีมงานเหล่านี้เราเลือกมาเองกับมือเราต้องดูแลพวกเค้าด้วยตัวเอง ตัดคนกลางออกไปให้หมดเพราะลำดับชั้นและอคติจะทำให้ข้อมูลและการสื่อสารคลาดเคลื่อนอย่างมากทั้งจากบนลงล่าง (Top-Down) เรื่อง Vision ของเรา (เราจะมั่นใจได้อย่างไรว่าคนกลางจะเข้าใจและถ่ายทอด Vision ของเราได้ครบถ้วนชัดเจน) และล่างขึ้นบน (Bottom-Up) เรื่องปัญหาและอุปสรรคต่างๆที่เกิดขึ้นจริงในการทำงาน


ทำไม Steve Jobs ต้องดูแลโครงการพัฒนาผลิตภัณฑ์ต่างๆด้วยตัวเอง เพราะเหตุผลนี้รึเปล่า?

Work in a Close Environment

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


Give Them Freedom

Dan Pink ได้ข้อสรุปจากการศึกษาของเค้าว่าในศตวรรษที่ 21 ความสุขในการทำงานหรือแรงผลักดันให้สร้างผลงานของมนุษย์คือความเป็นอิสระ (Autonomy) ความเชี่ยวชาญ (Mastery) และเป้าหมาย (Purpose) ภายใต้ Close Environment ถ้าทีมงานมีโอกาสได้ใช้ความเชี่ยวชาญอย่างอิสระในการทำงานเพื่อบรรลุเป้าหมายที่ชัดเจนร่วมกันก็มีเหตุผลอันเชื่อได้ว่าความสำเร็จอย่างโดดเด่นจะตามมา


Atlassian (ผู้ผลิต Jira) เจริญเติบโตได้ด้วยหลักการข้อนี้เป็นสำคัญ คล้ายๆ Google พนักงานทุกคนสามารถใช้เวลา 20% ของตัวเองทำงานในสิ่งที่ตัวเองสนใจ พนักงานคนนั้นเลือกที่จะกำหนดแนวทางของตัวเองหรือเลือกทีมงานของตัวเองได้ตามใจชอบ สนุกสนานไปกว่านั้นกับ “Shipit Days” คุณมีเวลา 24 ชั่วโมงที่จะทำงานอะไรก็ได้ที่เกี่ยวกับสินค้าของบริษัท อยากเพิ่ม Feature ใหม่ อยากแก้บั๊ก แม้แต่อยากทำ Product ใหม่ได้หมด แต่ใน 24 ชั่วโมงคุณต้อง Ship … ข้อจำกัดเป็นตัวเร่งความคิดสร้างสรรค์และนวัตกรรมชั้นดี

ทั้งหมดคือความคิดของผมเมื่อต้องการเปลี่ยนแปลงอะไรสักอย่างในองค์กร ไม่ว่าจะมองถึง New Product Development, Agile Adoption, หรือ Re-Organization เพราะจากประสบการณ์จริงสิ่งที่สำคัญที่สุดของเรื่องพวกนี้คือ “ทีมงานของคุณมีความรู้สึกเป็นเจ้าข้าวเจ้าของ (Sense of Ownership) กับงานที่ทำอยู่แค่ไหน?” ถ้ามีความรู้สึกนี้ทุกอย่างจะเดินไปได้ครับ ผมมั่นใจแบบนั้น Sense of Ownership จะเป็นบันไดให้ทีมงานของเราสร้างสิ่งที่สุดยอดได้ เมื่อผลงานเป็นที่ปรากฏผมก็หวังว่าแรงต่อต้านใดๆก็จะลดลง คนเปิดใจรับสิ่งใหม่มากขึ้น การเปลี่ยนแปลงที่จะตามมาจะไม่ใช่การบังคับแต่เป็นไปด้วยความสมัครใจมากขึ้นซึ่งก็จะเป็นการขยายวงของ Sense of Ownership ให้กว้างขึ้นไปเรื่อยๆซึ่งเป็นเรื่องสำคัญที่สุดจริงๆ


Process Management ใน IT Project Management

Posted by kannique On July - 22 - 2013ADD COMMENTS

มีคำถามจากเพื่อนในกลุ่มเรื่องการวางมาตรฐานของ IT Project Management ในหน่วยงานครับ … ผมเห็นว่าเป็นคำถามที่น่าจะมีประโยชน์กับใครอีกหลายคน ขออนุญาตเจ้าของคำถามตอบในนี้นะครับ … เรียก “ท่าน” เลย เขิน ฮ่าๆ

อยากรบกวนขอความคิดเห็นหน่อยครับ คือ ถ้าหน่วยงานของไทยกำลังต้องการร่างมาตรฐาน IT Project Management ซึ่งมีลักษณะคล้ายๆ Checklist
- ว่าใคร (Role เช่น PM, Executive, User)
- ต้องรับผิดชอบอะไร (เช่น แค่แจ้งให้ทราบ, ต้องทำ, ต้องอนุมัติ)
- ทำอะไรบ้าง (เช่นทำ Business Case, กำหนด Spec, ตรวจรับ)

ท่านอยากจะให้มีเนื้อหาเรื่องอะไรเป็นพิเศษบ้างหรือเปล่าครับ (เช่น เจอปัญหา…ประจำเลย ดังนั้น ควรมีการป้องกันแบบ….)

ขอบคุณล่วงหน้ามากครับ


Process Management

ขอเล่าโดยรวมก่อนนะครับ เรื่องการวางมาตรฐานหรือปรับเปลี่ยนกระบวนการทำงานเป็นเรื่องที่ไม่เคยง่ายจากประสบการณ์ที่ผ่านมาครับ และส่วนที่อยากที่สุดคือเรื่องคนครับ เพราะอะไร? อาจจะเป็นเพราะว่าธรรมชาติของเราแล้วเราไม่ชอบความเปลี่ยนแปลงนั่นเอง ที่เค้าพูดกันว่า “Comfort Zone” ครับ และสิ่งที่เรากำลังจะทำอยู่ตอนนี้มันเหมือนเป็นการบีบบังคับกลายๆให้พวกเขาออกจาก Comfort Zone … เค้าไม่ชอบอยู่แล้วและสิ่งที่จะตามมาคือแรงต่อต้าน (Resistance)


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

Process_Management
กระบวนการการวางมาตรฐานหรือปรับเปลี่ยนกระบวนการทำงานควร (จริงๆแล้วจำเป็นมาก) ที่ต้องเริ่มต้นจากการมองหาปัญหาที่เป็นปัญหาจริงๆซะก่อน (Identify) จากนั้นค่อยหยิบความรู้ ทฤษฎีหลักปฏิบัติ แนวคิด และหนังสือเข้ามาปรับใช้ (Define) ผมใช้คำว่าปรับใช้นะครับ ไม่ใช่ลอกมาทั้งหมดเพราะผมไม่เชื่อว่าการใช้แต่ทฤษฎีหรือหลักการเพียงอย่างเดียวจะแก้ปัญหาได้ในทุกสถานการณ์ ไม่มีทฤษฎีไหนดีที่สุดครับ มันอยู่ที่การเข้าใจและประยุกต์ใช้มากกว่า

เราวางมาตรฐานใหม่เสร็จแล้วจบแค่นี้หรือไม่? ไม่ใช่แน่นอนครับ กระบวนการที่ตามมาซึ่งสำคัญไม่แพ้กันนั่นคือเราต้องติดตามดูผลลัพธ์ที่ได้จากการทำงานแบบใหม่ (Monitor) ดูว่ามันได้ผลตามที่คาดหวังมั้ย? ผู้ใช้เข้าใจเรื่องใหม่ๆแบบนี้แค่ไหน? ผู้ใช้มีความพึงพอใจกับการทำงานแบบใหม่ๆมั้ย? เราต้องไม่ทิ้งผู้ใช้ให้โดดเดี่ยวในสถานการณ์ที่กำลังเปลี่ยนแปลงไปนะครับ สุดท้ายครับเมื่อติดตามเก็บข้อมูลมาแล้วก็ถึงเวลาต้องปรับปรุงให้กระบวนการทำงานของเราดีๆขึ้นไปอีก (Improve) ผมไม่เชื่ออีกแหละครับว่าครั้งแรกจะสมบูรณ์แบบ (ไม่มีทางเลย) เราจำเป็นที่ต้องกลับมาวิเคราะห์หาปัญหาเก่าที่ยังไม่ได้การแก้ไข หรือปัญหาใหม่ที่ก่อตัวขึ้นจากการวางมาตรฐานใหม่ของเรา เช่น เอ้ .. เอกสารนี้ไม่จำเป็นต้องแยกเล่มออกมาแต่เราควรรวมเข้าไปกับเอกสารนี้เลย หรือ อืม .. หลังทำขั้นตอนนี้เสร็จเราควรต้องแจ้งหัวหน้าใหญ่ให้ทราบด้วยนะ หรือ เอ้อ .. วาระการประชุม (Agenda) ของการประชุมนี้ไม่เหมาะสมเลย ถึงว่าหละประชุมทีไรไม่ได้ผลลัพธ์ที่ต้องการ เราต้องปรับแล้วนะ ณ จุดนี้เราจะกลับไปใช้ขั้นตอนเดิมครับ Identify – Define – Monitor – Improve

มาดูในรายละเอียดของการวางมาตรฐานต่อครับ … สำหรับผมเองกระบวนการนี้มีองค์ประกอบสำคัญอยู่ไม่กี่อย่างครับ ตามนี้

  1. แนวทาง/เป้าหมาย (Direction) – เราต้องรู้ก่อนว่าแนวทาง/เป้าหมายที่เรากำลังจะก้าวไปให้ถึงมันอยู่ที่ไหน สิ่งนี้จะถูกกำหนดจากผู้บริหารของหน่วยงานนั้นๆ สิ่งนี้จะเป็นตัวกำหนดองค์ประกอบที่ตามมาทั้งหมดเลย ในกรณีที่เรามีแนวทาง/เป้าหมายเชิงปิด เช่น ต้องการเป็น Scrum/Agile Team 100%, หรือต้องการได้ CMMi Level 3 Certificate แบบนี้เราคิดอะไรนอกกรอบมากไม่ได้ ฮ่าๆ … แต่ถ้าเป็นเชิงเปิดหละ? เช่น ยังไงก็ได้ขอให้งานออกมามีคุณภาพและทีมงานมีความสุข, ทำยังไงก็ได้ให้กระบวนการทำงานโปร่งใสตรวจสอบได้ในทุกขั้นตอน, หรือ ทำยังไงก็ได้ให้เหมาะสมกับสิ่งที่เราเป็นและวัฒนธรรมองค์กรที่เรามี แบบนี้สนุกครับ
  2. กรอบแนวคิดและความรู้ (Framework) – Direction จะเป็นตัวกำหนด Framework ของเราครับ เช่น ถ้าเป็น Direction เชิงปิดก็จบเลย ฮ่าๆๆ Scrum/Agile หรือ CMMi ไปเหอะ แต่ถ้าเป็นแนวเปิดหละ? เรามี Frameworkให้เลือกใช้เยอะนะครับ เช่น Agile/Scrum, Waterfall, CMMi, ISO, ITIL, PMBOK, PRINCE2, BABOK และอื่นๆตามรูปข้างบนครับ แบบนี้เราหยิบเล็กผสมน้อยเพื่อการประยุกต์ใช้ที่เหมาะสมกับสถานการณ์ที่สุดได้
  3. ผู้เกี่ยวข้อง (Actor) – ทั้ง Direction และ Framework จะเป็นตัวกำหนด Actor ของเรา บวกกับลักษณะธุรกิจหรือการทำงานขององค์กรเราก็เช่นกัน เราเป็นบริษัท Software House, เราเป็น Outsource, เราเป็นภาครัฐ,เราเป็นบริษัทเอกชนยักษ์ใหญ่, เราเป็น Freelance (อันนี้เค้าก็มีมาตรฐานของเค้าเองนะ ฮ่าๆ) นั่นรวมถึงคุณลักษณะของกลุ่มลูกค้าเราด้วยครับ อันนี้อธิบายยากครับ แล้วแต่กรณีจริงๆ
  4. กระบวนการ (Methodology) – เมื่อเรากำหนดองค์ประกอบข้างบนได้แล้ว เราจะลงรายละเอียดกันที่ Methodology นี่แหละครับ เช่น เราจะทำ Requirement Analysis ด้วยหลักการ Operational Concept, หรือ User Story, เราจะประเมินเวลาการทำงานในแต่ละงานด้วยวิธี PERT, Delphi หรือ Planning Poker, เราจะจัดเก็บ Requirement ทั้งหมดในรูปแบบของ Project Requirement Document, หรือ Product Backlog หรือใช้ร่วมกัน เยอะแยะเลยครับ
  5. ข้อมูลนำเข้าและผลลัพธ์ (Input – Output) – สุดท้ายครับ เราควรระบุให้ชัดเจนว่าในแต่ละขั้นตอนของการทำงานอะไรคือ Input และสำคัญคืออะไรคือ Output เผื่อให้ผู้ใช้เข้าใจและทำตาม เช่น ก่อนจะเริ่ม Coding ได้เราจำเป็นต้องมีเอกสาร Project Requirement Document และ Architectural Design Document มาก่อน และผลลัพธ์ที่เราต้องการจาก Coding คือ Software ที่ผ่าน Unit Testing เรียบร้อยโดยไม่มี High Severity Defect ตกค้าง อะไรประมาณนี้ครับ


Responsibility Matrix

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


ประเด็นที่น่าสนใจอยู่ตรงนี้ครับ … เราจะกำหนดกลุ่มของ Actor อย่างไรดี ในโปรเจกต์จะมี Actor มากมายหลายหลากขึ้นกับลักษณะงาน และแน่นอนครับที่ Actor แต่ละคนแต่ละกลุ่มก็จะมีบทบาทหน้าที่และระดับความเกี่ยวข้องที่ไม่เท่ากัน ผมขอขยายความตรงนี้นิดนึงครับ โดยทั่วไปแล้วเราจะแบ่งกลุ่มของ Actor ได้เป็น 3 กลุ่มใหญ่ๆ ได้แก่ Core-Team, Extended-Team, และ Other Stakeholders ตามรูป

Project_Team
เข้าไคลแมกซ์ซะที … ผมกำลังจะบอกว่าองค์ประกอบทั้ง 5 ข้อข้างบนมีผลต่อการกำหนด Responsibility Matrix ทั้งสิ้นครับ … ยากเลยทีนี้ ฮ่าๆๆ แต่ไม่เป็นไรครับ ผมขอยกตัวอย่างตามที่พอจะเขียนได้มาให้ดูนะครับ สำหรับรายละเอียดจริงๆที่เหมาะสมกับเจ้าของคำถาม ผมรบกวนติดต่อมาทาง Facebook ได้เลยครับ ยินดีช่วยคิดต่อ :D

ดาวน์โหลดตัวอย่าง Responsibility Matrix ที่นี่

เมื่อเกิดเหตุการณ์แบบนี้ขึ้น เราจะแก้ปัญหายังไง?

  • เราเป็นทีมที่ใช้ Agile Framework
  • ทีม Dev มีคนมากกว่า QA มาก ประมาณว่า Dev 4 คน QA 1 คน
  • อยากได้ Automate test ในมุมมอง System (end-to-end) Test ให้ cover มากกว่า 80%

หลายครั้งคนเป็นหัวหน้าจะมองแค่ Output ว่าอยากได้อะไรโดยไม่สน Input และ Process ระหว่างกลาง ความอันตรายของสิ่งนี้คือความสุขใจของคนในทีมจะถูกทำลายลงได้อย่างรวดเร็ว ถึงกระนั้นคนเป็นหัวหน้าก็ยังไม่สนใจอยู่ดี (เยี่ยมไปเลย) ถ้าเราเป็นคนที่อยู่ในทีม เราเป็นคนที่สนใจ Input และ Process ระหว่างกลาง … เราควรจะจัดการอย่างไร?

ผลการวิเคราะห์ได้ออกมาว่างานจะไปโหลดที่ QA เยอะมาก (ขอไม่เรียกว่าทีมเพราะมีอยู่คนเดียว) เพราะนอกจากจะต้องรับมือกับ Dev ตั้ง 4 คนแล้วยังต้องมาจัดการงานที่เป็น Automate test ด้วย (เอา Coverage ตั้ง 80%+) เราจะทำอะไรได้บ้างที่จะช่วยลดความกดดันตรงนี้ของ QA ผู้โชคร้าย ถึงจุดนี้ขอนำเสนอว่าเราน่าจะสร้างหลักการทำงานใหม่ขึ้นมาซักสองข้อคือ

  1. เราเป็นทีมเดียวกัน
  2. เราจะลองใช้ Kanban

ขยายความนิดนึงเรื่อง Kanban … หลักการง่ายๆมีแค่สองข้อ (1) Visualize Workflow (ทำอะไรคล้ายๆ Scrum หรือ Agile Board) และ (2) Limit Number of Work-In-Progress (WIP) หมายถึงว่าในแต่ละช่องเราจะกำหนดไปว่าจะมีงานอยู่ในนั้นได้มากสุดกี่งาน ตรงนี้มีไว้เพื่อสร้าง Focus ในทีมว่าควรพยายามทำงานให้เสร็จเป็นชิ้นๆและเพื่อช่วยในการแสดงให้เห็นถึงคอขวดที่เกิดขึ้นในกระบวนการทำงานของเรา

Kanban
แล้วจะใช้หลักการสองข้อที่ว่ามาแก้ปัญหานี้ได้อย่างไร?

  1. เราเป็นทีมเดียวกันคือเรามีสัญญาร่วมกันว่าเราจะช่วยกันทำงานอย่างจริงจัง ในกรณีนี้ Dev จะมาช่วย support QA ในการเตรียม Automate test
  2. เมื่อเพิ่มหลักการของ Kanban เข้าไป เราจะเห็นได้ชัดเจนขึ้นว่า ณ ตอนนี้ใครต้องการความช่วยเหลือในเรื่องงานบ้างและด้วยสัญญาที่มีทุกคนจะไม่รับงานใหม่จนกว่าจะไปช่วยกันทำงานที่ติดปัญหาอยู่ให้เสร็จก่อน

ประโยชน์คืออะไรบ้างหละ? ถ้าทำได้จริง … ที่เห็นได้ชัดคือ

  1. ทุกคนเป็นทีมเดียวกันจริงๆ
  2. Dev ได้มีโอกาสเรียนรู้งาน QA มากขึ้น
  3. งานเสร็จเป็นชิ้นๆด้วยคุณภาพที่ดี (ดูรูป — ถ้าเรากำหนด WIP = 2 เราจะทำงานสองงานแรกเสร็จภายใน 10 วันซึ่งเร็วกว่า WIP = 4)

WIP


ปัญหาที่จะตามมา? เท่าที่เห็นตอนนี้คือถ้า Dev ไม่ชอบงาน QA? มันอาจจะเกิดเหตุการณ์แบบนี้

  1. Dev รับปากแต่ไม่ช่วยจริงๆจังๆ
  2. Dev เบื่อและไม่มีความสุขในการทำงาน ทางแก้มีมั้ย?

ลองดูว่าแนวทางนี้เหมาะสมกับทีมเรามั้ย … หมุนเวียนให้ Dev แต่ละคนมาช่วยงาน QA เป็น Sprint ไปเพื่อสร้างอัตราส่วนที่สมดุลมากขึ้นจาก 4 : 1 กลายเป็น 3 : 2 คอขวดที่ QA ก็น่าจะน้อยลง อีกอย่าง Dev คนไหนที่ไม่ชอบงาน QA ก็ไม่ต้องทนทำแบบชั่วลูกชั่วหลาน แต่เราจะสับเปลี่ยนหมุนเวียนกันอย่างยุติธรรม

Ratio3_2
ปัญหาสุดท้าย … ท่านหัวหน้าใหญ่จะว่าอย่างไร?

 

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

 

ขอบคุณสำหรับคำแนะนำดีๆครับและต้องขออภัยที่ข้อเขียนของผมคลุมเครือและไม่ครบถ้วนในมุมมอง QA, Tester, และ Testing

ความตั้งใจที่ผมจะสื่อคือภาพของปัญหาในบริบทที่ชัดเจนนั่นคือ “หัวหน้าทีม Tester (เลี่ยงไม่ใช้คำว่า QA นะครับ) ต้องการให้ทีมของเค้าทำ Automate Test Script ในระดับ System (end-to-end) testing ให้ cover อย่างน้อย 80%” เผอิญว่าทีมนี้มีความแตกต่างของจำนวน Developer กับ Tester ที่มากเกินไป (4 ต่อ 1) ทำให้เกิดปัญหาว่า Tester ทำงานของเค้าไม่ทันครับ งานที่ไหลเข้ามาจาก Developer มันเยอะเกินไปมาก ฮ่าๆๆ

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

ผมไม่มีข้อขัดข้องอะไรกับข้อเขียนของคุณ Kamon เรื่องกระบวนการทำงาน เรื่องหน้าที่รับผิดชอบของแต่ละคนในทีมครับ ถ้าทำได้จริงก็คงจะดีมาก ใครที่ได้อยู่ในสภาพแวดล้อมการทำงานแบบนี้ผมคิดว่าโชคดีและยินดีด้วยครับ แต่โลกแห่งความเป็นจริงของผมตอนนี้มันไม่ใช่ (อาจจะโลกแคบ) ทฤษฎีก็เรื่องนึงปฏิบัติก็อีกเรื่องนึง ผมเข้าใจว่ามีอีกหลายคน หลายทีม หลายบริษัทยังไปไม่ถึงจุดนั้น ทุกคนมีปัญหาเฉพาะหน้าให้ต้องแก้กันไปครับ ผมเพียงแค่นำเสนอแนวคิดต่อปัญหาในบริบทที่ชัดเจนดังกล่าวมา ไม่ได้ต้องการจะสื่อว่าอัตราส่วนของ Developer กับ Tester ต้องเป็น 1 ต่อ 1 หรือ x ต่อ y ครับ ขออภัยอีกครั้งที่ผมอธิบายได้ไม่ชัดเจนครับ

ป.ล. 1: Developer ทีมนี้ก็มีทำ Automate Testing ในระดับ Unit นะครับ ไม่ใช่ว่าผลักภาระ Testing ทั้งหมดไปให้ Tester ครับ

ป.ล. 2: ผมได้ยินมาบ่อยว่า “ถ้าทำ Agile หรือ Scrum ครึ่งๆกลางๆก็อย่าเรียกตัวเองว่าเป็น Agile/Scurm Team เลย” หรือ ”ถ้าบอกว่าตัวเองเป็น Scrum Master แต่ไม่ได้ทำตัว วางตัวตามที่หนังสือบอกไว้ว่าต้องทำก็อย่าเรียกตัวเองว่า Scrum Master เลย” สำหรับผมจะเป็น Agile หรือ Scrum หรือไม่ไม่ได้เป็นสาระสำคัญอะไรเลย สิ่งสำคัญคือเราเข้าใจในหลักการอย่างเพียงพอที่เราจะเลือกประยุกต์ใช้สิ่งเหล่านั้นให้เหมาะสมกับลักษณะงาน ลักษณะคน โครงสร้างและธุรกิจขององค์กร เป็น Agile/Scrum Team ไม่ได้การันตีความสำเร็จ หรือเป็น Agile/Scrum แบบครึ่งๆกลางๆแล้วจะต้องล้มเหลว

ผมเคยอยู่ในทีม (ทีมที่ผมภูมิใจมาก) ที่ทำ Agile แบบครึ่งๆกลางๆแต่ตลอดเวลา 5 ปีที่ผ่านมาทีมนี้สามารถส่งมอบงานได้ตรงตามเวลา ครบทุก Feature ด้วยคุณภาพที่ดี และ Product ก็ขายดีติดอันดับของบริษัทมาตลอด ที่แปลกคืออัตราส่วนของ Developer กับ Tester เกือบจะเป็น 1 ต่อ 1 แถมมี Phase System Test แยกออกมาไว้ทำ Regression Test อีกต่างหาก ซึ่งช่วงนั้นผมและเพื่อนๆ Developer ยังเคยไปช่วย Tester ทำ Testing อยู่บ่อยๆทำให้อัตราส่วนเกือบจะเป็น 1 ต่อ 1.2 ด้วยซ้ำ แต่คุณภาพก็ออกมาดี ทีมเราก็มีความสุขมากทีเดียวครับ

ขอบคุณครับ