บล็อกใหม่ที่ Medium.com

Posted by kannique On July - 20 - 2014ADD COMMENTS

เมื่อประมาณหนึ่งเดือนที่แล้วผมได้อ่านบทความที่เขียนถึงเรื่องราวของ Alex Proba กราฟฟิกดีไซเนอร์ที่ทำงานให้ Kickstarter เธอบังคับตัวเองให้ใช้เวลา 30 นาทีทุกวันในการออกแบบและทำ Digital Poster ออกมาโดยเธอตั้งเป้าหมายว่าต้องทำแบบนี้ให้ได้ทุกวันเป็นเวลาหนึ่งปีและเธอก็ทำสำเร็จแล้วอย่างงดงามกับ “A Poster A Day” Project


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

ผมจะเขียนบล็อกทุกวันเป็นเวลาอย่างน้อยหนึ่งปีให้ได้


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

AlexProba

ก่อนผมรู้จัก Alex ผมใช้เวลาทั้งหมด 973 วันในการเขียนบทความ 33 บทความล่าสุด แต่หลังจากผมรู้จักเธอผมใช้เวลาแค่ 33 วันในการทำแบบนั้น … ถึงตรงนี้ผมอยากจะขอบคุณ Alex มากๆที่เป็นแรงบันดาลใจให้ผมทำอะไรดีๆแบบนี้ออกมาได้ Thank you so much, Alex :)  สำหรับเพื่อนๆที่สนใจว่าผมเขียนอะไรบ้าง เชิญเยี่ยมชมครับ

อาจจะเริ่มที่บทความนี้: ที่มาของ Agile Development หรืออันนี้ก็ได้: Kanban ในชีวิตจริง — จุดเริ่มต้น


สุดท้ายนี้

ผมจะเขียนบล็อกทุกวันเป็นเวลาอย่างน้อยหนึ่งปีให้ได้ :D


เมื่อผู้บริหารมีความกังวลเรื่องประสิทธิภาพการทำงานของ Project Team เรื่องราวจะดำเนินไปอย่างไร?


บริษัทแห่งหนึ่งมี Project Team ทั้งหมดสี่ทีมที่เป็นอิสระต่อกัน มีทีมงานเป็นของตัวเองทั้งหมด หลังจากมีการปรับกระบวนการทำงานแบบเดิมมาเป็น Agile/Scrum ได้ระยะหนึ่งปรากฎว่าผลการทำงานไม่ดีอย่างที่คาดหวังยกเว้น Project Team A ที่ดูว่า “ดีกว่า” ทีมอื่นๆเล็กน้อย ผู้บริหารก็เริ่มมีความกังวลว่าเกิดอะไรขึ้นกับสามทีมที่เหลือ ทำไมไม่สามารถทำงานได้ดีเท่ากับ Project Team A … แน่นอนการประชุมก็เกิดขึ้นเพื่อหาทางแก้ปัญหานี้ หลังจากการถกเถียงแลกเปลี่ยนความคิดเห็นและวิเคราะห์ (อย่างผิวเผิน) ไปซักพัก เหล่าผู้บริหารก็ได้ระบุสาเหตุของปัญหานี้ออกมาว่า

เพราะเราไม่มีกฎเกณฑ์และมาตรฐานที่ชัดเจนว่าในแต่ละขั้นตอนของการทำงานใน Project ต้องมีอะไรบ้าง ในแต่ละจุดอะไรคือ Input อะไรคือ Output และอะไรคือตัวชี้วัดว่านี่คือการทำงานที่ดีมีประสิทธิภาพ


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

  1. สร้างกฎเกณฑ์และมาตรฐานขึ้นมาโดยด่วนที่สุด
  2. สั่งให้ Project Manager รับหน้าที่ควบคุมให้ทุกคนทำตามกฎเกณฑ์และมาตรฐาน
  3. และทำให้ทุกทีมต้องมี Project Manager


เพียงเท่านี้ปัญหาที่มีก็จะได้รับการแก้ไขอย่างถาวรแล้วในมุมมองของผู้บริหาร … Happy Ending หรือไม่? ก็น่าจะเป็นแบบนั้น แต่เมื่อดูให้ลึกในเบื้องหลังแล้วจะพบว่า

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


เหตุการณ์สมมตินี้บ่งบอกชัดเจนสำหรับผมว่าผู้บริหารให้ความสำคัญกับกฎเกณฑ์และมาตรฐานมากกว่าทักษะและลักษณะนิสัยของคนในทีม เพราะสาเหตุที่ Project Team A ทำงานได้ดีคือการมีส่วนผสมที่ลงตัวของทักษะที่จำเป็นในการทำงานและการที่คนในทีมมีลักษณะนิสัยที่ดีในการทำงาน สองสิ่งนี้คือสิ่งที่ Project Team อื่นๆขาดไป ดังนั้น

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

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

เรื่องแบบนี้ไม่มีทางลัด ถ้าอยากให้ปัญหานี้หมดไปอย่างถาวรต้องคิดให้ลึกซึ้งวางนโยบายให้ดีและที่สำคัญ … ต้องอดทน

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

ขอบคุณครับ