ห่างหายการเขียน Ebook ไปนานแสนนานแต่หลังจากที่เริ่มเขียนบล็อกทุกวันที่ https://medium.com/@piyorot ผมก็มีเรื่องราวมาปะติดปะต่อเป็น Ebook ได้สองเล่มครับ

User Story & ‘INVEST’

การเขียน User Story ที่ดีด้วยหลัก INVEST

ในเล่มนี้จะเป็นเรื่องราวสมมติของ

ศิริพงษ์ – Project Manager ผู้มีใจรักใน Agile Development และมีความเชี่ยวชาญพอสมควรในเรื่องของการเขียน User Story … กับ เอกภพ – Product Owner มือใหม่ที่ไม่เข้าใจว่า User Story คืออะไรและมีหลักการในการเขียนอย่างไร ศิริพงษ์จึงเปิดฉากอธิบายเพื่อตอบข้อสงสัยของเอกภพ


Download ได้ที่นี่

9 Ways To Split User Stories

เก้าวิธีช่วยแบ่ง User Stories ให้เล็กลง

เรื่องราวบทสนทนาของศิริพงษ์และเอกภพยังดำเนินต่อมาจากเล่มแรก

ศิริพงษ์ – Project Manager ผู้มีใจรักใน Agile Development และมีความเชี่ยวชาญพอสมควรในเรื่องของการเขียน User Story … กับ เอกภพ – Product Owner มือใหม่ที่ถึงแม้จะเริ่มเข้าใจว่า User Story และ INVEST คืออะไร แต่เค้ายังมีข้อสงสัยถึงเทคนิคในการแบ่งย่อยให้ User Story มีขนาดเล็กลง ศิริพงษ์ไม่รอช้า … นี่คือเก้าวิธีที่จะช่วยเอกภพได้


Download ได้ที่นี่

สำหรับเพื่อนๆที่สนใจในเรื่อง Agile Development, Software Development และ Product Development สามารถติดตามผลงานของผมได้ที่ https://medium.com/@piyorot ผมเขียนทุกวันครับ

ศิริพงษ์นำเสนอ Definition of Done ให้กับทีมดูอีกครั้งในการประชุมซึ่งมีแขกรับเชิญพิเศษมาด้วยดังนี้

• เอกภพ ทศพล และจีรวรรณ PO ทั้งสามคนที่กำลังมีงานที่ Active อยู่กับทีม
• โมทช์ตัวแทนจากทีม UI/Graphic Designer
• กฤษตัวแทนจากทีม Operations ที่ดูแลเรื่อง Deployment

ศิริพงษ์: “Definition of Done เป็นเรื่องของทุกคนครับ ผมเลยถือโอกาสเชิญแขกพิเศษของเรามาด้วยในวันนี้ อันนี้คือสิ่งที่ผมคิดมานะครับ เดี๋ยวจะเล่าให้ฟังทีละขั้นตอน”

ศิริพงษ์ใช้เวลาเล่า ถกประเด็น และแก้ไข Definition of Done ร่วมกับทีมอยู่ประมาณ 45 นาทีก็ได้ข้อสรุปออกมา จากนั้นเค้าก็ร่ายต่อเรื่องสำคัญการกำหนด Work in Progress ในแต่ละคอลัมน์

ศิริพงษ์: “ขั้นตอนต่อไปครับ เราต้องกำหนด Work in Progress หรือ WIP”

ศิริพงษ์: “สิ่งแรกที่ต้องทำให้เคลียร์ก่อนคือผู้รับผิดชอบในแต่ละคอลัมน์ครับ อย่างเช่น Requirement เนี่ยะ มีคนรับผิดชอบหลักสามคนแน่ๆคือ PO ในแต่ละ Product”

ศิริพงษ์: “UI Design/Creation นี่มีโมทช์คนเดียวใช่ปะครับ?”

โมทช์: “มีปราบอีกคนครับ แต่ทั้งคู่มี Effort ให้ทีมพี่ 80% นะครับ”

ศิริพงษ์: “โอเคครับ”

เวลาผ่านไป 15 นาทีพวกเค้าก็ตกลงกันได้ในเรื่องคนรับผิดชอบในแต่ละคอลัมน์

การกำหนด Work in Progress ก็จะง่ายขึ้นแล้ว …

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

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

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

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



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

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

สุดท้ายนี้

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

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

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

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

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

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 เข้าไปเพื่อ?

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

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

“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.