ร่วมทำ Product Discovery กับทีม PO; Part III

สวัสดีครับ วันที่ 10 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part III

       เข้าสู่วันที่ 3 แล้ว เราก็มาทำการแตก Flow อื่นๆ กันต่อครับ โดยร่วมกันทำทุกคน ให้ได้มากที่สุด

       ให้ทีมเริ่มเขียน task ที่เป็น card Spike ออกมาในเรื่องที่ทีมพัฒนาไม่มั่นใจ แล้วต้องการทดสอบดูก่อนว่ามีความเป็นไปได้มากน้อยแค่ไหน แล้วให้ PO ดูเพื่อประกอบการตัดสินใจว่าเป็นอย่างไร อยากให้ทำแยกออกมาก่อนไหม หรือจะให้ทำตอน sprint เลย อันนี้แล้วแต่ PO ตัดสินใจได้ทั้งนั้น

        การ Estimate Time ของงานแต่ละชิ้นนั้น ก็จะปรับเปลี่ยนไปได้ตลอดทุกเมื่อที่มีการปรับ Requirement หรือ Technology ก็ตาม

        กำหนด Definition of Done ของแต่ละ sprint ว่าการทำงานของแต่ละครั้งนั้นต้องส่งอะไรออกมาให้ PO บ้าง เช่น Source Code เก็บที่ไหน, Scope of work, Test Case เป็นต้น

        หาก Requirement ชัดเจนมาตั้งแต่แรกนั้นจะทำให้การแตก Flow ทำได้เร็วขึ้นมากเลยทีเดียว แต่ก็ขึ้นอยู่กับคน conduct ด้วยว่าจะทำให้เกิดขึ้นได้เร็วกว่าได้อย่างไร การควบคุมคนให้ Focus อยู่เรื่องๆนึงนั้นไม่ง่ายเลยทีเดียว วุ่นวายเหมือนจับปูใส่กระด้งเลย

ร่วมทำ Product Discovery กับทีม PO; Part II

สวัสดีครับ วันที่ 10 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part II

       วันนี้เป็นวันที่สองของการทำ Product Discovery บรรยากาศเหงาลงไปเนื่องจากคนมาน้อยลง ซึ่งไม่ดีน่ะครับแบบนี้ เพราะอยู่กันไม่ครบองค์ แต่ก็ยังทำไปได้อยู่ในส่วนที่เหมือนกันครับ

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

       ทีมพัฒนาเอา tool ที่จะมาช่วยพัฒนาให้ทีม PO เห็นกันว่า น้องๆทีมพัฒนาเขาต้องเจออะไรบ้างกับ flow แต่ละหน้า

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

       ก็เริ่มงานกันเลย เอา Flow แรกของเมื่อวานหยิบมาทำกัน โดยการทำนี้คือการ design หน้าจอออกมาเลยครับ แต่บนกระดาษน่ะ ไม่ใช่ในจอคอม เพื่อให้ง่ายต่อการแก้ไข โยกย้ายได้ง่าย 

       แบ่งออกเป็น 2 กลุ่ม กลุ่ม 1 ทีม PO และกลุ่ม 2 ทีมพัฒนา เมื่อแยกกันทำแล้ว ผลที่ออกมา ว่า Programmer ออกแบบก็หน้าจอจะแข็งๆ ดูยาก เล่นยาก ตาม logic เขา ส่วนฝั่ง PO ก็ลงรายละเอียดเยอะกว่าเลยละ 

       ตรงนี้จะสลับกันวิจารณ์กันน่ะครับ โดยให้เขียนลง Post-it ไว้ ว่าชอบ ไม่ชอบ เสนอแนะอะไร แล้วรับฟังกัน ต่างคนต่างคิดวิเคราะห์ไว้ แล้วรวมกันสิว่าตรงไหนดีหยิบมา รวมร่างกัน ก็จะได้ออกมาระดับนึงละ

       พักเที่ยงกันก่อน แล้วกลับมาใหม่

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

       ต่อมาก็หยิบ flow ที่เกี่ยวข้องกันมาทำกัน โดยแบ่งกลุ่ม 2 กลุ่ม แต่ให้คละคนเข้ากัน เพื่อให้เกิดการ discuss กันและเห็นร่วมกันได้ทั้ง Dev และ PO แล้วก็ design เหมือนเดิมออกมาเลยครับ

       ลอง Estimate กันสิ ทีมพัฒนาคิดว่าจะใช้เวลาเท่าไร เมื่อได้เห็นรายละเอียดมากขึ้นแล้ว การตัดสินใจจะง่ายขึ้นกว่าเมื่อวานมาก แต่ไม่ได้หมายความว่าจะเสร็จเร็วขึ้นน่ะ

       วันนี้ก็จบด้วย Flow ใหญ่ 1 ตัวที่ประกอบไปด้วยหลายๆ Flow ย่อย และ Estimate คร่าวๆ

       การทำ Product Discovery นี้ทำให้ทุกๆฝ่าย USER,PO,DEV มองเห็น เข้าใจ ปัญหาร่วมกัน เห็นอกเห็นใจซึ่งกันและกัน มองเห็นความเป็นไปได้ร่วมกัน จนทำให้งานที่ออกมานี้จะเกิดการแก้ไข(BUG, Rework) ออกมาน้อยที่สุด 

       เสียเวลากับ Product Discovery มากๆ ดีกว่าการแก้ไขโปรแกรมแบบไม่รู้จบ

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

       การควบคุมให้ Focus กับงานที่ทำ ไม่ออกนอกเรื่องไปมาก เพราะยิ่งนอกเรื่องยิ่งเสียเวลา

ร่วมทำ Product Discovery กับทีม PO; Part I

สวัสดีครับ วันที่ 9 พ.ย. 2558

ร่วมทำ Product Discovery กับทีม PO; Part I

       วันนี้เป็นวันแรกของการทำ Product Discovery ครับ ซึ่งคนที่เข้าร่วมนั้นก็มีดังนี้ Product Owner (PO), Stockholder หรือ User, Development Team(Developer, Tester, SA), Scrum Master

      โดยปกติคนที่จะพาทำกิจกรรมต่างๆของการทำ Product Discovery นั้นต้องเป็น PO ครับ แต่ถ้า PO ยังใหม่กับการทำแบบนี้ Scrum Master ก็เข้ามามีบทบาทได้ เพื่อช่วย PO ทำงาน

      เริ่มกันเลย SM แนะนำให้ทุกคนรู้จักการทำ Product Discovery ก่อนว่าคืออะไร มีไว้เพื่ออะไร เพื่อความเข้าใจให้ตรงกันว่า วันนี้เราจะมาทำอะไรกัน เพื่อเป้าหมายอะไรกัน จะได้ไปในทิศทางเดียวกัน

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

      SM ถามถึง Business Requirement คืออะไรบ้าง และ Software Requirement คืออะไรบ้าง ให้ทุกคนช่วยเสนอออกมา ถ้าคนเยอะให้แบ่งเป็นกลุ่มๆ เพื่อลดการโต้เถียงที่ยาวนาน เมื่อทุกกลุ่มได้ออกมาแล้วก็พูดออกมาว่ามีอะไรบ้าง ถ้ากลุ่มไหนมีเหมือนกันก็เสริมกันได้เลย แต่ถ้าแตกต่างก็ discuss ได้แต่อย่านานเกินไป เนื่องจากพอได้ตรงนี้มาแล้ว เราจะหันมาถาม Development Team ว่า Business Requirement เพียงพอที่จะเอาไป develop ได้หรือไม่ เมื่อไม่พอต้องเพิ่มอะไรมาบ้างตรงนี้ละที่สำคัญเลย

      Business Requirement เช่น

• Flow Business
• Condition
• User
• User Interface
• Test Case + Data Test

      Software Requirement เช่น

• Performance
• Response Time
• Non-Functional

      SM เริ่มโดยการถามทุกคนว่า

• PROBLEM ปัญหาที่ทำให้เกิด Product นี้คืออะไร
• GOAL เป้าหมายเพื่อให้ Product นี้สำเร็จได้คืออะไร อันนี้ควรจะตอบโจทย์ปัญหาน่ะ และควรเป็น GOAL ที่ชัดเจน และเรียง PRIORITY ด้วย
• MAXIMIZE OUTCOME ผลที่อยากให้เกิดขึ้นเมื่อ PRODUCT นี้ได้เอาไปใช้แล้ว เช่นมีคนใช้งานมากขึ้นเรื่อย, ลดขั้นตอนการทำงานจาก PRODUCT เก่า เป็นต้น

      หลังจากได้ PROBLEM, GOAL, OUTCOME มาแล้ว เราก็เริ่มแก้ปัญหาทีละเรื่อง (Flow Business)

      โดยให้ช่วยกันเขียนว่าเรามี Flow Business อะไรบ้างออกมาให้หมด

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

      ใส่ People และ Step workflow ที่เกี่ยวข้องกับ Flow Business นี้ลงไปแต่ละ Flow เลยว่า ใครทำอะไร มี step การทำงานอย่างไรลงไป ตรงนี้ถ้าเกิด flow ใหม่มาก็เพิ่มได้เลย (แต่จะเน้นให้ทำเฉพาะส่วนที่ Dev Team บอกว่าทำได้ก่อน)

• PO มาเรียง PRIORITY ว่าต้องการ flow ไหนก่อนหลัง
• ถ้า Fix Time ให้ PO บอกว่า Flow ต้องได้อย่างน้อยเท่าไร
• Dev Team บอก PO ว่าจะทำได้อย่างที่ PO ขอหรือไม่ ถ้าไม่ ได้แค่ไหน พร้อมเหตุผล

     เราจะเห็นว่ามีการปรับ PRIORITY ได้ตลอดเวลา และการ Estimate ว่าทำได้แค่ไหนนั้น คือการเดาล้วนๆเลยครับ แต่ถ้าเรา ลงรายละเอียดของแต่ละ Flow Business ได้มากแค่ไหนก็ยิ่งง่ายต่อการพัฒนา ครับ

     การทำกิจกรรมของวันแรกนี้คือ

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

     จบวันแรกละ เนื่องจากใช้เวลากับการลงรายละเอียดแต่ละ flow เยอะ และการอธิบายเนื้อของแต่ละ Flow พรุ่งนี้มาต่อน่ะครับ