25 มี.ค. 2021 เวลา 01:00 • ธุรกิจ
ถอดบทเรียน Scrum in Big data ภาครัฐ: Part II
สวัสดีครับท่านผู้อ่าน ในตอนนี้เรากำลังเริ่มเข้าสู่ช่วงสำคัญของบทความไตรภาค “ถอดบทเรียน Scrum in Big data ภาครัฐ” กันแล้วครับ ในบทความไตรภาคนี้จะเล่าถึงการนำ Scrum มาปรับใช้ในองค์กรเพื่อช่วยส่งเสริมการทำงานให้สามารถส่งมอบงานที่มีคุณค่าแก่ลูกค้าได้เร็วขึ้น โดยหากผู้อ่านท่านใดยังไม่ได้อ่านบทความแรก ที่ว่าด้วยพื้นฐานของ Scrum สามารถเข้าไปอ่านได้ที่นี่นะครับ
ตอนที่ 1: คอนเซ็ปต์ Scrum ล้วน ๆ ไม่มีวัวผสม
ตอนที่ 2: บริบทขององค์กรและการนำมาปรับใช้จริง
ตอนที่ 3: ผลที่เกิดขึ้นและความท้าทายใหม่ ๆ
ตอนที่ 2: บริบทขององค์กรและการนำมาปรับใช้จริง
ในบทความนี้ผมจะมาถึงบริบทและการนำ Scrum มาปรับใช้ผ่าน 3 หัวข้อนี้ครับ
1. โครงสร้างและการทำงานภายในองค์กร
2. การเตรียมตัวก่อนนำ Scrum มาปรับใช้
3. การปรับใช้กิจกรรมต่าง ๆ ใน Scrum
“เอาล่ะ ถ้าพร้อมแล้ว มาเริ่มกันเลย”
โครงสร้างและการทำงานภายในองค์กร
“ภาพบรรยากาศในการทำงาน”
องค์กรของเราจะแบ่งกลุ่มทำงานออกเป็น 3 กลุ่มหลัก ๆ คือ กลุ่มผู้บริหาร กลุ่มสนับสนุนการทำงานขององค์กร เช่น งานเอกสาร งานจัดซื้อ เป็นต้น และกลุ่มที่ใหญ่ที่สุดก็คือ กลุ่มที่ทำงานแบบเป็นโปรเจกต์ ๆ โดยจะแบ่งเป็นทีมย่อย ๆ ตามธีมที่แตกต่างกัน เช่น ท่องเที่ยว สาธารณสุข เด็กและเยาวชน เป็นต้น โดยในแต่ละทีมจะประกอบไปด้วย data scientist อาจจะมี data engineer บ้างขึ้นอยู่กับลักษณะของงานที่ต้องทำ ซึ่งส่วนใหญ่แล้วจะรวมกันไม่เกิน 8-9 คน ส่วนโปรเจกต์ที่ทำอยู่ในแต่ละทีมนั้นก็จะอยู่ในงานหลัก ๆ 3 งาน ดังนี้
1. งานให้คำปรึกษาทางด้านข้อมูล เช่น การทำ dashboard จากข้อมูลของลูกค้าเพื่อหามุมมองใหม่ ๆ ของข้อมูลที่เกิดขึ้น หรือการให้คำปรึกษาในการทำเริ่มต้นการทำ big data
2. การทำ prototype เพื่อพิสูจน์ว่าโปรเจกต์ของลูกค้า สามารถทำได้จริง หรือเป็นการนำร่องให้ลูกค้าภาพชัดเจนมากขึ้น โดยส่วนมากจะเป็นงานในลักษณะของการสร้างโมเดลเพื่อการจัดกลุ่มหรือทำนายอะไรบางอย่าง
3. อบรมความรู้ที่เกี่ยวข้องกับข้อมูล ไม่ว่าจะเป็นการทำ dashboard จนถึงงานด้าน data science หรือ data engineer
ส่วนลักษณะการทำงานภายในองค์กรนั้นจะมีกลิ่นไอการทำงานที่คล้าย ๆ กับ Startup คือ การใช้พื้นที่ทำงานร่วมกัน เพื่อช่วยให้เพื่อน ๆ ภายในทีมสามารถพูดคุยกันได้สะดวกขึ้น และตอบนโยบาย work from home ที่ให้อิสระในการทำงานของพนักงาน 2 วันต่อสัปดาห์ เวลาคนไหนไม่เข้ามาทำงานก็จะได้มีพื้นที่ให้คนอื่น ๆ มานั่งทำงานแทนได้
การเตรียมตัวก่อนนำ Scrum มาปรับใช้
ในการบริหารจัดการกิจกรรมต่าง ๆ ใน Scrum ที่จะเกิดขึ้น มันก็คงจะดีถ้ามีเครื่องมือต่าง ๆ เข้ามาช่วยให้เราแบ่งเบาภาระ ซึ่งเครื่องมือเหล่านี้จะมาในรูปแบบของ software เช่น JIRA, Azure DevOps, Asana ซึ่งในแต่ละเครื่องมือก็มีส่วนที่เหมือนกันบ้าง แตกต่างกันบ้าง ซึ่งอาจจะต้องเลือกจากลักษณะงานที่ทำ และความยากง่ายในการใช้งานของคนในองค์กรด้วย
เมื่อเราเลือกเครื่องมือกันได้แล้ว ก็มาเลือกบทบาทของคนในทีมที่อยู่ใน Scrum กันเถอะ
1. Product owner หรือ เจ้าของผลิตภัณฑ์ จะเลือกจาก project manager เดิมของทีมนั้น ๆ หรือถ้าเป็นทีมใหม่หรือทีมที่ไม่มี project manager ก็ควรจะเลือกผู้ที่มีความสามารถในการบริหารจัดการงาน เช่น ประเมินระยะเวลาที่ต้องใช้ในการทำงาน กำหนดเกณฑ์การวัดผลงานที่สมบูรณ์ สื่อสารกับบุคคลภายนอกทีม ไม่ว่าจะเป็นลูกค้า หรือผู้มีส่วนได้ส่วนเสียได้ เป็นต้น
2. Scrum master ผู้ที่ดำเนินกิจกรรมต่าง ๆ ของ Scrum และช่วยแก้ไขอุปสรรคต่าง ๆ ที่รบกวนการการทำงานของทีม โดยในการเลือกนั้นจะขึ้นอยู่กับแต่ละทีมอาจจะมาจากการสุ่ม หรืออาสาสมัครภายในทีมก็ได้ 1 คน ซึ่งควรจะผลัดกันเป็น จะได้เป็นการพัฒนาทักษะภาวะผู้นำ การอำนวยความสะดวกในการประชุมกลุ่ม และความรับผิดชอบ ของคนในทีมไปในตัวด้วย
3. Development team จะเป็นสมาชิกที่เหลือและ Scrum master ทุกคนจะมีหัวข้องานที่ต้องทำเป็นของตัวเอง หากมีสมาชิกที่ต้องทำงานหลายทีม (share resource) ก็จะแบ่งว่า ทีมนี้ทำกี่เปอร์เซ็นต์ ทีมนั้นทำกี่เปอร์เซ็นต์ เพื่อให้การทำงานเป็นไปตามความคาดหวังของ product owner
การปรับใช้กิจกรรมต่าง ๆ ใน Scrum
Sprint planning
คนในทีม จะไปวางแผนกันเองว่าต้องทำอะไรใน sprint เพราะแต่ละคนจะรับผิดหัวข้องานที่ต้องทำอยู่แล้ว เช่น ทำเว็บไซต์ สร้างโมเดลข้อมูล หรือ ทำ dashboard เป็นต้น จากนั้นจะแจ้ง product owner เพื่อช่วยดูทิศทางของงานให้อีกที สาเหตุที่ต้องทำแบบนี้เพราะหลัก ๆ แล้ว องค์กรต้องการให้ความสำคัญกับ product ownership มาก ๆ อยากให้พนักงานวางแผนเป็น คิดได้รอบด้านมากขึ้น และเติบโตไปพร้อมกับโปรเจกต์ที่ทำอยู่ โดยมีพื้นที่ปลอดภัยหรือก็คือ product owner ช่วยดูแลอยู่ ถ้ามีเรื่องที่ต้องคิดร่วมกันก็อาจจะใช้เวลาหลัง sprint retrospective ในการทำ sprint planning คุยกัน การทำแบบนี้จะช่วยให้คนในทีมไม่ต้องรอทุกคนวางแผนกันเสร็จทั้งหมด เพราะบางคนคิดช้า บางคนคิดไว
หากคนในทีมต้องไปทำงานให้ทีมอื่นด้วย ก็จะแบ่งภาระงานตามความเป็นจริง โดยภาระงานนี้เรียกว่า story point ซึ่งใช้ในการกำหนดความซับซ้อน ปริมาณ และความเสี่ยงของงานออกเป็นค่า ๆ หนึ่ง โดยประมาณว่า 1 story point นั้นเทียบเท่า งานปกติ ๆ ที่ทำในแต่ละวัน ไม่ยากไม่ง่าย ความเสี่ยงกลาง ๆ ดังนั้นเวลาวาง story point ก็ไม่ควรจะเกิน 10 แต้มต่อ sprint เพราะ 1 sprint มี 2 สัปดาห์ แต่ในความเป็นจริง จะประมาณไว้แค่ 8 เพราะเผื่องานด่วน งานแทรกกลาง sprint
Daily Scrum
ทีมเราจะใช้เวลาในการอัปเดตงานทุก ๆ วันตอน 8.30 โดยสิ่งที่พูดคือ เมื่อวานทำอะไร, วันนี้ทำอะไร และระหว่างการทำงานติดปัญหาอะไรไหม โดย Scrum master จะเป็นผู้แจ้งกำหนดการอัปเดตใครพูดก่อนหลัง เพื่อให้คนในทีมได้เตรียมตัวและจะได้ไม่เปิดไมค์ชนกันในกรณีประชุมออนไลน์ เมื่อสมาชิกในทีมยกเว้น product owner พูดหมด Scrum Master ก็จะแจ้งให้ product owner พูดอัปเดตอะไรที่จะบอกในทีม เมื่อพูดเสร็จก็เป็นอันสิ้นสุด Daily Scrum ต่างคนต่างแยกย้ายไปทำงาน หรือ อาจจะมีคุยนอกรอบกันต่อ โดยเวลาในกิจกรรมนี้จะไม่เกิน 15 นาที ถ้ามีแนวโน้วมว่าจะเกิน Scrum master จะช่วยเตือนว่านานไป หรือ อาจจะให้ไปนัดคุยนอกรอบก็ได้
“Daily Scrum เนื่องจากบางคน work from home”
Sprint review
ทุกคนนอกจาก product owner จะพูดอัปเดตงานที่ทำมาใน 2 สัปดาห์ คนละประมาณ 2 นาที และหลังจากนั้นจะเป็นการโชว์ผลงานที่ทำมาทั้ง sprint แล้วจะมีการแลกเปลี่ยนความคิดเห็นภายในทีมกันว่าผลงานที่โชว์นั้น ถูกต้องเหมาะสมหรือไม่ ถ้าไม่ ก็จะมีคำแนะนำในการแก้ไข เพื่อกลับไปวางแผนการทำงานใน sprint ถัดไป
“บรรยากาศการทำ sprint review”
Sprint retrospective
“บรรยากาศการทำ sprint retrospective ออนไลน์”
ในการทำ sprint retrospective นั้น สำหรับองค์กรทั่วไปก็อาจจะทำ Good, Bad, Try บ้างก็ Good, Bad บ้างก็เป็นชั่วโมงรุมด่าคนที่ไม่ชอบ หรือชั่วโมงเชือดคนที่อัดอั้นมาทั้ง sprint แต่เนื่องด้วยองค์กรเรายังใหม่ และทีมเราเป็นทีมใหม่เช่นกัน เลยยังไม่มีอคติอะไรขนาดนั้น ทุกคนรู้ว่าตัวเองทำอะไร แล้วอะไรที่ทำได้ดีและไม่ดีใน sprint อยู่แล้ว ถ้าไม่รู้ก็จะรู้จาก sprint review เมื่อกี้ในช่วงที่ทำโชว์ผลงาน ทำให้ตอนนี้ทุกคนตกผลึกกับตัวเองแล้ว ดังนั้นที่สิ่งทีมเราทำก็คือ การถอดบทเรียนภายใน 2 สัปดาห์ที่ผ่านมาเองเลย ด้วยการแจก post-it จำนวน 2 แผ่น เพื่อทำตามขั้นตอนดังนี้
แผ่นที่แรกจะทำ emotion tracking บอกว่า Sprint ที่ผ่านมา ในแต่ละวันรู้สึกยังไง ดี, เฉย, แย่ ถ้าจำไม่ได้ก็เอาคร่าวๆ วาดเป็นกราฟออกมา ถ้าจุดไหนมีเรื่องจะเล่าก็จด ๆ ไว้ ส่วนอีกใบนั้นเขียน 3 อย่าง คือ
1. อะไรที่เราทำดี
2. อะไรที่เราได้เรียนรู้เพิ่มขึ้นใน sprint ที่ผ่านมา
3. อยากจะพัฒนาอะไรใน Sprint ถัด ๆ ไป
จากนั้นก็ผลัดกันแชร์กัน ซึ่งสิ่งที่เกิดขึ้นนั้นค่อนข้างหลากหลาย บรรยากาศบ้างก็เศร้า บ้างก็ตบมุกเฮฮา ซึ่งมันเหมือนกับว่าเรารับฟังเขา เขาไม่ได้เหนื่อยหรือทำงานอยู่คนเดียว ไม่ต้องเก็บเรื่องทุกข์ใจอยู่คนเดียว คนไหนเล่าได้ก็ได้ระบายสิ่งที่อัดอั้นตันใจออกมา แถมยังได้ฮีล ได้กำลังใจดี ๆ กลับไปอีก ซึ่งจะช่วยทำให้สมาชิกในทีมเปิดใจต่อทีมมากขึ้น
“ตัวอย่างการทำ sprint retrospective”
วัตถุประสงค์ของการทำ retrospective แบบนี้ คือ อยากให้ทีมเป็นเหมือนพื้นที่ปลอดภัยในการแสดงความเห็น และการทำงานร่วมกัน เพราะมันเป็นการสร้างความสัมพันธ์ภายในทีมที่ดีเลย หลัง ๆ ก็เริ่มมี track emotion ที่ไม่เกี่ยวกับงานด้วย แชร์ชีวิตส่วนตัวบ้าง ซึ่งในความเห็นส่วนตัว ผมมองว่า มันเป็นเรื่องดีมาก ๆ เพราะผมไม่ได้มองว่า การทำงานต้องเป็นการทำงานตามคำสั่ง ตามผลประโยชน์ที่ควรจะเป็นในเชิงธุรกิจขนาดนั้น แต่มันเหมือนเป็นการใช้ชีวิตร่วมกันกับเพื่อนที่จะเดินทางไปถึงฝันด้วยกันมากกว่า การทำงานเป็นทีมไม่ควรจะโดดเดี่ยวหรือเหงาในส่วนลึก ๆ ของจิตใจ แต่กลับกันน่าจะสนุกกับการเห็นความหลากหลายของคน ของชีวิตและพึ่งพาซึ่งกันและกันมากกว่า แต่ก็มีข้อควรระวังบางทีการทำกิจกรรมอาจจะมีความอ่อนไหวทางอารมณ์ ความรู้สึก ดังนั้นก่อนนำกิจกรรมไปปรับใช้ ควรดูปัญหาที่มีอยู่ในทีมก่อน ว่าจะส่งผลกับกิจกรรมมากน้อยแค่ไหน เพราะไม่งั้นมันอาจจะไม่เกิดประโยชน์ คนตีกันก่อน
สรุป
ในการนำ scrum มาปรับใช้นั้น สิ่งที่ต้องพิจารณาหลัก ๆ เลย มี 2 อย่าง ก็คือ คนภายในทีม ว่าเราจะกำหนดบทบาท Product owner , Scrum master , Developer team กันอย่างไร และกิจกรรมที่จะนำมาปรับใช้ภายในทีมว่าสอดคล้องกับบริบทของทีมและองค์กรหรือไม่ ซึ่งไม่จำเป็นต้องเป็นไปตามทฤษฎีทุกอย่าง ขอแค่ตอบวัตถุประสงค์ของกิจกรรมนั้น ๆ และทำให้กระบวนการทำงานเร็วขึ้น คนในทีมมีความสุข เท่านี้ก็น่าจะเพียงพอแล้ว
จบไปแล้วนะครับบทที่สอง ซึ่งถือเป็นบทหลักเลยทีเดียว ที่พูดถึงบริบทขององค์กรและการนำไปปรับใช้ ซึ่งในอนาคตนั้นก็จะต้องมีการปรับกิจกรรมไปเรื่อยๆ หากบริบทเปลี่ยน ทั้งเรื่องหน้าที่ของคนในทีมและกิจกรรมของ Scrum เองโดยผลที่คาดหวังไว้นอกจากการส่งมอบงานที่มีคุณค่าแล้ว ก็คือการพัฒนาคนให้มีคุณค่าต่อองค์กรและสังคมในอนาคต ผ่านการทำงาน และเก็บเกี่ยวประสบการณ์ที่จะเกิดขึ้นครับ ในบทความหน้าจะเป็นบทความสุดท้ายที่จะสรุปการนำ Scrum ไปปรับใช้ในองค์กรแล้วนะครับว่าเราได้เรียนรู้อะไรจากการทดลองใช้ Scrum กันบ้าง และมีอะไรที่เรายังต้องปรับปรุงกันต่อไปครับ
อ้างอิง
ติดตามและพูดคุยกับ GBDi ได้ที่
#gbdi #govbigdata #bigdata #bigdatathailand #datascience #dataengineer #dataanalytics #digitalthailand #DigitalTransformation #Scrum #Government
โฆษณา