A Great Team

Posted by kannique On April - 6 - 2014ADD COMMENTS

“You don’t need world-class talents to create world class products. But, what you need is a right balance of skill, knowledge, work environment and most importantly a great team; the team that is united and has a very strong bond. If you can choose to invest in something, invest in building great teams then step out of their way and let them shine.”

– Piyorot Piyachan

What does it look like to build a great team? It starts with a promising story. Think of when you have a dream to do something great but unfortunately you cannot make it by yourself. You need someone who can help. Instead of finding the most talented people in the world who you have never met before, you choose to call your close friends, share them the dream, and invite them to join the ride. Some says yes, some is in doubt, some gently declines. At this point, if you start asking yourself “Why did I call this guy?”, and “Why did they respond differently?” There are three elements related to that:

  1. You called this guy because you trust him or her. You know in your heart that this is the one you can rely on no matter whatever happens.
  2. They said “Yes” because for sure they also trust in you. A part from which, your story and vision touches his or her heart. He/She, for a long time, wanted to do something great and at that very moment he/she get motivated to be part of this.

This is a foundation. We trust each other, we believe and share the same vision, and we are so motivated to make it reality. Skill, ability, knowledge, and money are just trivial at first. This is a purpose-driven team. This team works for something bigger than themselves. This team doesn’t understand the word “Me”, but it profoundly believes in the word “We”.

Sadly, many big-outdated companies are struggling with finding a way to build a great team. Even worse, some of them don’t understand this simple concept, let alone seeking the answer.

Well … how? It is simple and straightforward. As a leader, you build an environment that allows a team to be formed based on trust not availability, inspiration not manipulation, and motivation not job function. Let them share their story, vision, and belief. Let the others choose what they want to work on and with whom. With this shift, let’s see a difference it can make. You will be surprised.

Thank you.

ถ้าใครสนใจอยากให้ผมไปพูดบรรยายหัวข้อเรื่องเหล่านี้ติดต่อผมทาง 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 ที่นี่