[Review] คอร์ส Passionate Product Ownership by Jeff Patton

สวัสดีครับ ด้วยการสนับสนุนจากผู้ใหญ่ใจดีท่านหนึ่ง ทำให้ผมได่มีโอกาสได้เข้าเรียนในคอร์สที่ผมใฝ่ฝันมานาน ก็คือคอร์สนี้แหละครับ ผู้เรียนจะได้รับใบประกาศ CSPO (Certified SCRUM Product Owner) โดยอัตโนมัติ (คนสอนบอกว่าขอแค่ survive ให้ครบ2วันก็พอ ไม่ต้องสอบครับ อิอิ)

โอเค มาเริ่มกันเลย เรื่องจากworkshopนี้เป็นส่วนหนึ่งของงาน Agile India 2015 ดังนั้นผู้เรียนส่วนใหญ่จึงเป็นคนอินเดีย มีคนไทยบินมาเรียน2คนถ้วนและฝรั่งอีกจำนวนหนึ่งครับ  มีผู้เข้าเรียนประมาณ 40 คน นั่งได้โต๊ะละ 5 คน ก็ได้มีเพื่อนรวมโต๊ะเป็นชาวอินเดียสองท่านครับ ปัญหาก็คือผมฟังภาษาอังกฤษสำเนียงอินเดียไม่ค่อยออกครับ แต่คนสอน(ต่อไปขอเรียกว่า ลุงJeff นะครับ เพื่อความสะดวก...ของผม อิอิ) ฟังออกแฮะ น่าจะคุ้นเคยกับคนอินเดียเป็นอย่างดี แต่ก็ผ่านมาได้ครับ รู้เรื่องบ้างไม่รู้เรื่องบ้าง เออๆออๆ ตามน้ำไป ฮิฮิ

มาดูทางด้านการเรียนการสอนกันบ้าง ก็จะเป็นการฟังบรรยายสลับกับทำ workshop สั้นๆ ประมาณ 5 นาทีครับ มากับเนื้อหาที่อัดแน่นสุดๆ แต่ด้วยสไตล์การสอนของ  Jeff  นี่ไม่มีเบื่อเลยครับ น่าทึ่งมากๆ

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

พูดถึงเนื้อหาที่เรียนกันบ้าง ก็เกี่ยวกับการทำ Software, เรื่องของ Collaboaration แล้วก็เข้าเรื่อง Process แกเอา Paper ของ Waterfall model มากางให้ดูเลยครับ ว่ามันเขียนไว้ตั้งแต่ปี 1970 แล้วนะ ว่าทำแบบนี้แล้วมันจะเจ๊งนะ ในpaperมันมีการevolveไปเรื่อยๆจนสุดท้าย เราจะได้ข้อสรุปว่า Good process is messy
อันนี้เป็นการปูเรื่องเพื่อเข้าสู่ที่มาของ SCRUM ซึ่งผมว่าเป็นการเล่าเรื่อง SCRUM ที่เจ๋งมากๆ หาจากอาจารย์ท่านอื่นไม่ได้แน่นอน (ไม่ได้บอกว่าท่านอื่นสอนไม่ดีนะครับ)

พอจบเรื่อง SCRUM แล้วแกก็เล่าเกี่ยวกับการทำงานของProduct manager หรือ owner ใน SCRUM นั่นเองครับ พูดถึงการทำงานร่วมกันระหว่าง PO, Dev และ UX,BA ฯลฯ ภาพที่ควรเกิดขึ้นนั้นเป็นอย่างไร, งานของ UX นั้นมีอะไรบ้าง, กระบวนการทำ Product discovery, เรื่อง Output กับ Outcome, การทำ Story mapping, การหา MVP, Metric ที่นำมาใช้วัดความสำเร็จของ Product, การทำ Persona, การกำหนด Prioritize Backlog Strategy ฯลฯ  แล้วยังมีดีเทลยิบๆย่อยๆอีกเยอะครับ เขียนไม่หมด

หมดเรื่อง Product discovery แล้วก็กลับมา cover เรื่อง SCRUM กันอีกครั้ง ก็หยิบเรื่อง กิจกรรมต่างๆใน SCRUM มาคุยกัน เช่น Daily standup PO ควรทำอะไร? อันนี้เป็นคำถามปลายเปิด ให้ผู้เรียนหาคำตอบกันเอาเอง แล้วก็เรื่อง Sprint Review ที่ควรแยกกันกับ Stakeholder Review
ต่อด้วย แนวคิดของ Lean startup นำมาช่วยในการออกแบบ Product ,การทำ Prototype แล้วปิดท้ายด้วย Design thinking แล้วก็ตอบคำถามอีกนิดหน่อย ได้ Key takeaway มาเยอะมากๆครับ ถ้ามีแรงจะเอามาเล่าต่อเรื่อยๆนะ

ระหว่างเรียน ก่อนจะไปเบรก ลุงJeff แกจะให้เราเขียน Key takeaway (หรือ A-ha) มาอย่างน้อยหนึ่งอย่างลงใน Post-itไปแปะที่บอร์ดครับ (คอร์สนี้ใช้ Post-it เปลืองมากๆ บริษัท 3M มาเห็นนี่ต้องน้ำตาไหลอ่ะ) ผมชอบเทคนิคนี้มาก เหมือนกับว่าได้ทบทวนไปในตัว น่านำมาใช้ครับ เวลาไปแชร์ความรู้ให้คนอื่นๆ

จบชั้นเรียนด้วยการให้ผู้เรียนทุกคนเลือก Key takeaway ที่ชอบที่สุดมาหนึ่งอัน แล้วก็จบ ก็แยกย้ายกันกลับ (มีบางท่านยังมันส์อยู่ ก็ไปคุยกับ Jeff ต่อครับ ยาวๆไป อิอิ)

อ้อที่สำคัญคือ คอร์สนี้แจกแหลกครับ ทั้ง Handout ที่พิมพ์สีทั้งเล่ม, ตัวอย่างที่ใช้ใน workshop ก็เก็บกลับบ้านไปด้วยได้เลย(ไม่มีใครเก็บไปเลยแฮะ แอบแปลกใจเล็กน้อย) สุดท้ายคือแกแจกหนังสือครับ ใช่ครับ User Story Mapping ของแกนั่นแหละ แถมยังเซ็นชื่อให้ครบทุกคนอีกตะหาก โคตรป๋าอ่ะ

สรุปว่าสุดยอดมากๆครับคอร์สนี้ ไม่ว่าคุณจะเป็นใครที่เกี่ยวข้องกับการทำ Product น่าจะหาโอกาสมาเรียนกันครับ ไม่ต้องทำ SCRUM ก็ได้ ไม่มีอะไรเกี่ยวข้องกับ Agile เลยก็ยังได้ครับ ลองดูๆ ใบ Cert. เป็นแค่ของแถมครับ

Even a single line is worth extracting if it needs explanation.

อ่านเจอประโยคนี้ในหนังสือ Refactoring  ของลุง Martin Fowler

แปลเป็นไทยก็ได้ความว่า

"ต่อให้เป็นโค้ดแค่บรรทัดเดียว แต่ถ้ามันต้องการคำอธิบายเพิ่ม มันก็ควรจะถูก Refactor"

ยกตัวอย่างง่ายๆเช่น ผมมีเงื่อนไข สักอย่างแบบนี้

if (username !== null && email !== null && password === confirmPassword) {
    ...
}

ตอนที่เราเขียนอาจจะไม่เป็นไร แต่เวลาเรากลับมาอ่านล่ะ หรือลองให้เพื่อนอ่านสิ จะยังรู้เรื่องอยู่มั้ยนะ

เราสามารถช่วยโลกใบนี้ได้ ด้วยการ Extract  ออกไปเป็น  Method หรือ  Function แบบนี้

if(isRegistrationFormCompleted()) {
    ...
}

function isRegistrationFormCompleted(){
    return username !== null && email !== null && password === confirmPassword
}

จะเข้าใจเลยว่าเงื่อนไขชุดนี้เอาไว้เช็คว่าฟอร์มใส่ข้อมูลมาครบแล้วหรือยังใช่มั้ยครับ

ทีนี้ดูต่อไปอีกหน่อย ในชุดเงื่อนไขพวกนี้ ยังดูแล้วยุ่งๆนะฮะ ลองแยกเงื่อนไขแต่ละอันออกไปเป็น Function ดูสิ

if(isRegistrationFormCompleted()) {
    ...
}

function isRegistrationFormCompleted(){
    return isUsernameNotNull() && isEmailNotNull() && isComfirmPasswordMatched();
}

function isUsernameNotNull(){
    return username !== null;
}

function isEmailNotNull(){
    return password !== null;
}

function isComfirmPasswordMatched(){
    return password === confirmPassword;
}

สามารถมองออกได้ทันทีเลยว่าแต่ละเงื่อนไขเราจะเช็คอะไร

ผมจะพอเท่านี้แหละ แต่โค้ดนี้ยัง Refactor ต่อไปได้อีกนะครับ เช่นแยกส่วนเงื่อนไขเหล่านี้ออกไปเป็น Class ใหม่, เปลี่ยนเงื่อนไขเป็น Strategy pattern ฯลฯ แล้วจะมาเขียนแนะนำกันเรื่อยๆครับ

มีมิตรสหายท่านหนึ่งถามมาว่า แค่เขียนคอมเม้นก็พอมั้ย มันก็ได้นะครับ แต่ลองคิดดูว่าถ้าโค้ดตรงนั้นมันโดนแก้ไขแล้วหรือไม่ได้เป็นไปตามที่เขียนคอมเม้นเอาไว้อีกต่อไปแล้ว เราจะยังคอยตามไปแก้ให้มันอัพเดทอยู่เสมอมั้ย?