ทำอย่างไรกับโปรเจคไอที 1 ปี ที่ทำมา 3 ปี แล้วยังไม่เสร็จซักที
ถ้าพูดถึงโปรเจคไอที เรามักจะพบเห็นอยู่ใน 3 รูปแบบใหญ่คือ พัฒนาระบบใหม่เลย (Clean Slate) ทำเพิ่มเติม (Enhancement) หรือทำมาแทนระบบเก่า (Modernization)
ซึ่งโปรเจคสองแบบแรกนั้นสามารถนำแนวคิด Agile มาปรับใช้ได้ไม่ยาก เพราะ Framework แบบ Agile เช่น Scrum นั้นถูกออกแบบมาสำหรับการพัฒนาใหม่อยู่แล้ว แต่ทว่าโปรเจคแบบสุดท้ายหรือ Modernization นั้นเป็นงานปราบเซียนจนทำให้หลายๆคนคิดไปด้วยซ้ำว่า เราไม่สามารถใช้ Agile กับงานแบบนี้ได้ โดยเฉพาะเวลาที่เป็นการนำ Software สำเร็จรูปมาปรับแต่ง (หลายๆที่เรียกว่า Implement) ไม่ใช่การพัฒนาใหม่ (Software Development) บทความนี้เลยอยากจะมาเล่าให้ฟังว่า Lean In มีประสบการณ์อย่างไร กับการนำ Agile ไปใช้กับโปรเจคมหาหินแบบนี้
เมื่อหลายปีก่อน Lean In Consulting ได้มีโอกาสเข้าไปช่วยให้คำปรึกษากับการนำ Agile ไปใช้กับการทำโปรเจคในการ Migrate ระบบ Core System ของสถาบันการเงินหนึ่ง ซึ่งต้องการย้ายระบบจาก Legacy System ที่มีมาหลายสิบปี ไปเป็นระบบใหม่ที่ทันสมัยกว่า ลำพังตัวระบบหลักนั้นก็เป็นเรื่องถ้าทายอยู่แล้ว แต่ยังมีสิ่งที่ท้าทายกว่าระบบเล็กๆน้อยๆมากมายที่ต่อเชื่อมอยู่ (Peripherals) และยังมีเรื่องของ Data Migration กับข้อมูลมหาศาลอีกด้วย ในตอนที่เราเริ่มเข้าไปช่วยนั้นโปรเจคนี้เดิมมีกำหนดการจะเสร็จภายใน 1 ปี แต่ทำมาแล้ว 3 ปี ยังไม่มีทีท่าจะเสร็จ แต่หลังจากที่นำ practice ของ Agile ไปเริ่มปรับใช้ เราก็สามารถออก Release แรกได้ภายใน 6 เดือน
ประสบการณ์ในโปรเจคนี้จริงๆก็ผ่านมาหลายปีแล้ว แต่วันนี้พอดีมีเพื่อนผมคนหนึ่งซึ่งได้รับมอบหมายให้ไปทำงานที่ท้าทายไม่แพ้กัน ผมก็เลยว่าจะมาเขียนสรุปให้เขาฟังว่าถ้ามองย้อนกลับไป จากในวันนี้ที่ผ่านประสบการณ์ต่างๆมามากมาย ผมเห็นอะไรบ้าง
ใช้เทสนำ ทำทีละเรื่อง
ต่อเนื่อง ตัดสินใจร่วมกัน
แสดงสิ่งสำคัญ ให้เห็นภาพตลอดเวลา
ในมุมของ Agile Practice ผมมองเห็นถึง Practice 3 ตัวหลักที่มีส่วนช่วยอย่างมากในการจัดการกับอภิมหาโปรเจคแบบนี้
(1) ใช้เทสนำ ทำทีละเรื่อง — ATDD with Scenario Mapping
(2) ต่อเนื่อง ตัดสินใจร่วมกัน — Agile Interactions
(3) แสดงสิ่งสำคัญ ให้เห็นภาพตลอดเวลา — Visualizations
❤️ Practice 1 : ใช้เทสนำ ทำทีละเรื่อง — ATDD with Scenario Mapping
สมมุติว่าเราทำโปรเจคเหมือนการผลิตเครื่องซักผ้า สิ่งที่เรามักจะคุ้นชิ้นกันก็คือการแบ่งโปรเจคออกเป็น Module ย่อยๆ ตามมุมมองของคนผลิต เช่น ระบบซัก ระบบปั่น ระบบถ่ายน้ำออก ระบบใส่ผงซักฟอก ระบบใส่น้ำยาปรับผ้านุ่ม ระบบตั้งเวลา ฯลฯ ซึ่งการแบ่งแบบนี้ทำให้คนผลิตแยกส่วนงานกันทำได้ง่าย ใครถนัดทำระบบไหน ก็ตั้งหน้าตั้งตาทำระบบนั้นไปตาม Spec ไม่ต้องคุยอะไรกันมากมาย แต่ก็อย่างที่รู้กันว่า มันมักจะวอดวายตอนมาประกอบร่างกัน และ Feedback ก็มักจะมาท้ายๆโปรเจคตอนทำ UAT ไปแล้ว 5 รอบ
ในยุคของ Agile เราก็พยายามหั่นงานใหญ่ๆ ออกเป็นชิ้นย่อยๆเพื่อให้เกิด Feedback ที่รวดเร็วขึ้น บ้างก็หั่นเป็น User Story จบใน Sprint บ้างก็หั่นเป็น Feature แต่หลายๆครั้งสิ่งที่เกิดขึ้นจริงคือเราก็ยังไม่ได้ Feedback อะไรมากมายนักจนกว่าจะท้ายๆโปรเจค สาเหตุก็เพราะว่า User ไม่ยอมทำ UAT! หลายๆคนก็มองว่า User ไม่ให้ความร่วมมือบ้าง ไม่เห็นความสำคัญบ้าง หรือ User ไม่เข้าใจ Agile บ้าง
ในโปรเจคผลิตเครื่องซักผ้า สมมุติว่าผ่านไป 3 Sprint แล้วและตอนนี้มี Progress คือ ระบบซักเสร็จ 100% ระบบปั่นเสร็จ 20% ระบบถ่ายน้ำออก 0% ระบบฉีดใส่ผงซักฟอก 50% ระบบใส่น้ำยาปรับผ้านุ่ม 0% ระบบตั้งเวลา 50% คือซักได้สะอาดเลยนะ แต่ปั่นแล้วยังดูดน้ำออกไม่ได้ ผงซักที่ใส่ไปก็เข้าครึ่งไม่เข้าครึ่ง เครื่องนี้ราคาเต็ม 10,000 บาท ผมขายให้ 5,000 มีใครเอาไหมครับ? จริงๆขาย 500 ก็อาจจะไม่มีใครเอาเพราะว่าไม่รู้จะเอาไปทำอะไร
User ก็เหมือนกันครับ เขาไม่รู้จะ UAT ไปทำไม มันยังไม่ครบ Flow การทำงานปกติของเขา
โปรเจคที่ทำงานแบบ Agile หน่อย ก็อาจจะไม่ได้แบ่งงานเป็น Module ตามคนผลิต แต่อาจจะแบ่งเป็น Feature ตามมุมของผู้ใช้ เช่น ซักได้ ปั่นได้ ตั้งเวลาได้ แต่ทว่า แบ่งแบบนี้มันก็แทบจะเหมือนกับแบ่งตาม Module เลยนี่นา แล้ว User ก็ยังไม่ยอม UAT อยู่ดี ก็มันยังไม่ครบ Flow การทำงานปกติของเขาอยู่ดี แล้วมันต้องแบ่งอย่างไรหล่ะ?
ถ้ามองในมุมของการใช้งานของ User เป็น Use Case หรือ User Scenario เราอาจจะแบ่งออกมาได้เป็น
- ซักผ้าขาวธรรดา
- ซักผ้าสีธรรมดา
- ซักชุดกีฬาเลอะโคลน
- ซักชุดชั้นใน
- ซักผ้านวม
- ฯลฯ
ทีนี้สมมุติว่าโปรเจคที่ผมทำเครื่องซักผ้าตอนนี้มี Progress คือ ซักผ้าขาวได้ 100% ซักผ้าสีได้ 50% ยังซักชุดกีฬาเลอะโคลนกับซักผ้านวมไม่ได้ ผมขายให้ 5,000 บาท สนใจไหมครับ? ดูแล้วอาจจะมีคนสนใจก็ได้ จริงไหมครับ? ถ้าเราแบ่งโปรเจคออกมาแบบนี้ User จะสามารถ UAT ได้เพราะว่ามันครบ Flow การทำงานปกติของเขา
กลับมาที่อภิมหาโปรเจคของสถาบันการเงินแห่งหนึ่งที่ Lean In ได้เข้าไปช่วยที่เลทมาแล้วหลายปี สิ่งที่เราเสนอให้ทำสิ่งแรกคือหยุดการแบ่งงานตาม Module และเปลี่ยนมาแบ่งงานตาม End-To-End User Scenario ซึ่ง Scenario ที่ทางลูกค้าเลือกมาเป็น Scenario แรกคือการโฟกัสที่การขายผลิตภัณฑ์ตัวที่เป็นที่ทำเงินที่สุดของเขาจากผลิตภัณฑ์ทั้งหมดที่เขามีหลายสิบตัว ทั้งนี้เราก็หั่น Scenario ให้บางลงอีกเพื่อให้ได้ Feedback เร็วขึ้นโดยการโฟกัสที่การขายผลิตภัณฑ์ตัวที่เป็นที่ทำเงินที่สุดให้กับลูกค้าใหม่ที่ชำระด้วยเงินสดเท่านั้น
เราจะเริ่มทำงานทุกระบบที่เกี่ยวข้องกับ Scenario นี้ก่อนและเพื่อทำให้ Scenario นี้ทำงานได้เท่านั้น ยังไม่ต้องไปทำ Scenario อื่นๆ และจะค่อยๆโฟกัสไปทีละ Scenario และยิ่งสามารถทำให้ Scenario นั้นยิ่ง End-To-End มากได้เท่าไหร่ยิ่งดี
เป็นได้สูงมากว่า Scenario แรกที่เลือกมาจะใช้เวลามากกว่า Scenario อื่นๆมากเพราะว่ามันอาจจะแตะไปในทุก Module ทุกระบบเลยก็ได้ แต่ข้อดีก็คือเราจะได้ Feedback จากการที่ไปแตะทุกระบบ (การ integrate) นี้ตั้งแต่เนิ่นๆ ไม่ต้องไปรอท้ายๆโปรเจคแล้วแก้อะไรไม่ทัน
การปรับมาหั่นโปรเจคแบบนี้ โดยทั่วไป User ค่อนข้างให้ความร่วมมือ เพราะว่าเขามองเห็นภาพและมันเป็นธรรมชาติการใช้งานของเขาอยู่แล้ว แต่แรงต้านมักจะมาจากฝั่งไอทีเองเพราะว่าพอจบ Scenario หนึ่งและตัองไปทำ Scenario ใหม่ จะมีโอกาสสูงมากที่เขาอาจจะต้องรื้อต้องแก้สิ่งที่ทำไปแล้ว แต่ทั้งนี้ถ้าเทียบกับการ UAT 5 รอบ 8 รอบ ซึ่งก็อาจจะต้องรื้ออยู่ดี และมี deadline มาบีบขั้นมากๆ การทำแบบนี้จะได้ผลดีกว่ามาก เพราะเป็นการกระจายความเสี่ยงออกจากที่มักจะไปอัดกันท้ายๆโปรเจคออกมาตั้งแต่ตอนเริ่มและค่อยๆทยอยทำไปทีละ Scenario
วิธีการทำแบ่งเป็น Scenario ของ Lean In จะใช้เครื่องมืที่เรียกว่า Scenario Mapping ซึ่งเป็นเทคนิดที่เราต่อยอดออกมาจาก User Story Mapping และ User Journey โดยให้ผู้เกี่ยวข้องทั้ง 3 ฝ่าย คือ User คนตรงกลาง (เช่น PO หรือ BA) และ Developer มาช่วยกันร่วมทำ Map หรืออาจจะใช้สิ่งที่เราคุ้นกันอยู่แล้วอย่างเช่น End-To-End Test Case มาเป็นตัวแบ่งก็ได้ มองอีกมุมวิธีการทำแบบนี้ก็คือการเอาหลักการของ Acceptance Test Driven Development (ATDD) มาประยุกต์ใช้กับโปรเจคนั่นเอง
ตัวอย่าง Scenario Map — พนักงานบริษัทมางาน Agile Tour
ตัวอย่างในรูปนี้คือ Scenario Map ของการจัดงานสัมมนา Agile Tour ที่เป็น Scenario ซึ่งพนักงานบริษัทมางาน Agile Tour จะเห็นว่า Scenario นี้มี User Activity (สีเขียว) จำนวน 3 Activity มาเรียงต่อกัน โดยแต่ใน Activity นั้นจะมี Step (สีน้ำเงิน) เป็นรายละเอียดของแต่ละ Activity ซึ่งสองแถวบนนี้เป็น User View ที่ไม่ว่าเห็นก็พอจะทำความเข้าใจได้ไม่ยากว่า Scenario นี้คืออะไร ส่วนด้านล่างของแต่ละ Step จะมี Work Item (สีเหลือง) ของงานที่เหลืออยู่ที่จะต้องทำเพื่อให้ Step นั้นเกิดขึ้นได้จริง ซึ่ง Work Item นี้เองที่เรามักจะเอาไปเป็นเป็นงานที่ทำในแต่ละ Sprint
ตัวอย่างของ Project Room ที่ผนังห้องเต็มไปด้วย Scenario Map
พักหลังๆเวลามีคนขอให้เราสอนวิธีการเขียน User Story เรามักจะตอบไปว่าเราเลิกใช้ไปแล้ว และแนะนำให้ลูกค้ามาลองใช้วิธี Scenario Mapping แทน ซึ่งวิธีนี้จะทลายข้อจำกัดของ User Story ที่ต้องมี Value พอและต้องจบใน Sprint ซึ่งในหลายๆบริบททำได้ยาก ถ้าปกติใครใช้ Epic แทน Story ใหญ่ๆที่ต้องแตกออกเป็น Story ย่อยให้จบใน Sprint อาจจะมองว่า Scenario นี้คือ Epic ก็ได้
❤️ Practice 2 : ต่อเนื่อง ตัดสินใจร่วมกัน — Agile Interaction
ถ้าเราวางแผนแล้วทุกอย่างเป็นไปตามแผนที่วางไว้ก็คงจะดี แต่ในโลกแห่งความเป็นจริงนั้น ไม่เคยมีอะไรเป็นไปตามแผน เราจึงควรเลิกหลอกตัวเองและพยายามควบคุมให้ทุกอย่างเป็นไปตามแผนที่เราวางไว้ตั้งแต่ตอนที่เรารู้น้อยที่สุด และเปลี่ยนมาเป็นปรับแผนบ่อยๆให้เข้าสิ่งที่เราได้เรียนรู้เพิ่มขึ้นอยู่ตลอดเวลา
ใน Scrum จะเห็นว่าเรามีการปรับแผนกันเป็นประจำสม่ำเสมอทุก Sprint ใน Sprint Planning และยังสามารถปรับแผนของ Sprint ได้เป็นประจำสม่ำเสมอทุกวันใน Daily Scrum
การทำงานแบบโปรเจคในองค์กรขนาดใหญ่ มักจะมีทีมที่เกี่ยวข้องกันหลายทีม บางทีมทำ Agile บางทีมก็ไม่ได้ทำ Agile แต่อย่างไรก็ตาม เราก็ยังหลีกหนีความจริงที่ว่า แผนที่วางไว้จะไม่เป็นไปตามแผนไม่ได้ เราจึงควรจะจัดเวทีให้ทีมต่างๆเหล่านี้ ส่งตัวแทนมาพบเจอกันเพื่อคุยถึงแผนที่อาจจะมีความเปลี่ยนแปลงไปจากเดิมที่วางไว้อย่างเป็นประจำสม่ำเสมอ ส่วนความถี่ที่มาเจอกันนั้น จะถี่มากถี่น้อยก็ขึ้นอยู่กับความเปลี่ยนแปลงที่เกิดขึ้นในโปรเจคนั้นๆ อาจจะเป็นสัปดาห์ละหน สองสัปดาห์หน หรือจะกี่วันหน รวมถึงจะมีกี่ Interaction เรื่องอะไรบ้าง ก็แล้วแต่จะตกลงกัน
ตัวอย่างของ Project Team ที่มี Agile Interaction คือ Monthly Project Sync ทุกสัปดาห์ที่ 3 และ Monthly Project Demo ทุกสัปดาห์ที่ 1
ปกติในแต่ละโปรเจคนั้นมักจะมีการประชุมกันเป็นระยะอยู่บ้าง แต่สิ่งที่ Agile Interactions แตกต่างจากการประชุมทั่วไปคือใน Agile Interactions นั้นจะเน้นเรื่อง “การตัดสินใจร่วมกัน” มากกว่าการมารายงานความคืบหน้า
เมื่อเรายอมรับกันแล้วว่าการเปลี่ยนแปลงเป็นเรื่องธรรมชาติและแผนจะไม่เป็นไปตามแผนที่วางไว้ การนัดมาเจอกันเป็นระยะๆเพื่อตัดสินใจร่วมกันเพื่อตอบสนองกับการเปลี่ยนแปลงที่เกิดขึ้นจึงเป็นเรื่องปกติที่ควรจะทำ สิ่งที่เรามักจะคุยกันบ่อยๆใน Agile Interactions จึงเป็นเรื่องของ Dependency ที่ทีมหนึ่งต้องส่งมอบให้กับอีกทีมหนึ่ง ยิ่งถ้าเราหั่นงานให้เล็กเพื่อให้ได้ Feedback ที่รวดเร็ว เช่นการใช้ ATDD ด้วย Scenario Mapping ตามที่เล่ามาข้างต้น การ Integrate จึงจะเกิดขึ้นตั้งแต่ช่วงต้นๆของโปรเจค และการมาคุยกันเรื่อง Dependency ว่ายังเป็นไปตามแผนหรือไม่ ถ้ามีการเลื่อนแผนจะกระทบใครอย่างไร จึงเป็นเรื่องปกติที่ควรจะทำ
ถ้าในองค์กรมีการทำงานเป็น Agile หรือ Scrum เป็นหลักอยู่แล้ว การนำตัวแทนทีมมาคุยกันเป็นรอบๆเพื่อวางแผนร่วมกันก่อนจะแตกงานเข้า Sprint ของแต่ละทีมจึงเป็นเรื่องปกติที่ควรจะทำ ลองนึกภาพว่าเป็นการทำ Big Grooming ที่มีทั้ง Product Owner, Scrum Master และตัวแทนจากทีม Scrum ต่างมา Grooming ร่วมกันก็ได้ ใน Scaling Agile หลายตำราก็มี Practice ทำนองนี้เป็นเรื่องปกติ
เพราะ Agile Interaction เป็นการมาพบกันเพื่อตัดสินใจร่วมกัน คนที่มาพบกันจึงจำเป็นจะต้องเป็นคนที่มีอำนาจตัดสินใจ ไม่อย่างนั้นการมาพบกันก็ไม่เกิดประโยชน์อะไร ส่วนเรื่องการตรวจสอบความคืบหน้านั้น เราจะไม่เน้นทำกันใน Agile Interaction แต่จะใช้เครื่องมือ Visualization ในการทำให้ทุกคนสามารถเข้าถึงข้อมูลของความคืบหน้าของโปรเจคได้อย่างโปร่งใสและเป็นปัจจุบัน
❤️ Practice 3 : สร้างสิ่งสำคัญ ให้เห็นภาพตลอดเวลา — Visualization
โปรเจคขนาดใหญ่โดยทั่วไปมักจะมี Project Manager หรือ PM เป็นคนที่คอยดูภาพรวมและทำรายงานความคืบหน้าให้ผู้บริหาร แต่เอาเข้าจริงๆ PM ก็อาจจะไม่ได้รู้สถานะจริงๆของแต่ละทีมย่อย ต้องคอยไปถามเอากับตัวแทนทีมซึ่งก็อาจจะได้ข้อมูลที่เชื่อถือได้บ้างไม่ได้บ้าง ข้อมูลที่เป็นเป็นปัจจุบันบ้างไม่เป็นปัจจุบันบ้าง หลายๆที่เวลารายงานให้กับผู้บริหารก็จะมีการรายงานภาพรวมโดยใช้สีของไฟจราจร แทนสถานะของโปรเจคว่าตอนนี้เขียว หรือเหลือง หรือแดง ในองค์กรที่ยังมีวัฒนธรรมที่ไม่ค่อยกล้าพูดความจริงกันสักเท่าไหร่ หรือถ้า PM ถือคติว่า
“If The Status Is Red, The Project Manager Is Dead”
สิ่งที่มักจะพบเห็นได้ทั่วไปก็คือ สถานะของโปรเจคนั้นจะเขียวมาตลอดแต่พอใกล้ๆถึงกำหนดนั้น เปลี่ยนเป็นเหลืองเป็นแดงกันรวดเร็วจนแทบตั้งตัวกันไม่ทัน แต่จังหวะนั้นจะให้ผู้บริหารมาแก้ไขปัญหาอะไรก็อาจจะลำบากหรือว่ามีค่าใช้จ่ายที่แพงมากแล้ว
ในองค์กรขนาดใหญ่หลายที่ การเตรียม Presentation เพื่อรายงานสถานะให้กับผู้บริหาร เป็นเรื่องที่มีค่าใช้จ่ายในการเตรียมตัวสูงมากจนบางทีเราก็ล้อกันเล่นว่าเราต้องมี PowerPoint Engineer ไว้คอยทำ Slide รายงานผู้บริหาร แต่เป็นที่น่าเสียดายเป็นอย่างยิ่งว่า ข้อมูลที่อยู่ใน Slide เหล่านี้บางครั้งก็ไม่ค่อยได้ช่วยให้ผู้บริหารตัดสินใจอะไรได้ดีขึ้นสักเท่าไหร่ เพราะข้อมูลเหล่านี้มักจะไม่เป็นปัจจุบันและไม่สะท้อนถึงความจริงที่เกิดขึ้น
ในการทำงานในทีม Agile นั้น เรามักจะมี Visualization ที่เป็นเครื่องมือในการสื่อสารถึงความคืบหน้าของ Task เช่น Task Board ที่ใช้โพสต์อิตแทน Task โดยแบ่งสถานะออกตาม Column ตามสถานะเป็น To Do, Doing และ Done หรือเป็น Kanban Board ที่แสดงสถานะของ Work Item ตามแต่ละ State ของ Flow ของ Work Item นั้นๆ นอกจาก Visualization เหล่านี้จะช่วยแสดงสถานะของชิ้นงานนั้นๆแล้ว สิ่งที่ทำให้ Visualization นี้เป็นเครื่องมือที่ช่วยให้สร้างความโปร่งใสที่เชื่อถือได้มากกว่าการตามงานด้วยใครสักคนเช่น PM ก็คือ การ์ดบนบอร์ดนั้นจะได้รับการเปลี่ยนสถานะโดยคนทำงานแต่ละคนเองเป็นประจำสม่ำเสมอทุกวัน ตามแนวคิด Self Managing ของการทำงานแบบ Agile นอกจากจะทำให้ไม่ต้องมีใครคนใดคนหนึ่งมาเป็นคนคอยติดตามสถานะของงานของทีมแล้ว ถ้างานไหนติดขัดปัญหาอะไร คนทำงานก็สามารถคุยกันได้ทันทีโดยไม่ต้องผ่านตัวแทนหรือตัวกลาง
ตัวอย่างของ Visualization ด้วย Project Kanban Board
เราสามารถนำหลักการ Self Managing แบบการทำงานใน Agile นี้มาช่วยแบ่งเบาภาระของ PM ที่ดูแลโปรเจคทีต้องอาศัยการประสานงานระหว่างหลายๆทีมงานได้ โดยการสร้าง Visualization ที่แสดงถึงชิ้นงานที่เกิดขึ้นในโปรเจคและให้ตัวแทนทีมต่างๆที่มาพบกันใน Agile Interaction ใช้ Visualization นี้เป็นเครื่องมือช่วยในการตัดสินใจร่วมกัน ถ้า Dependency เป็นสิ่งที่สำคัญใน Project เราก็อาจจะทำให้มันเด่นชัดขึ้นมาใน Visualization ที่เราสร้างขึ้นมานั้นก็ได้ อย่างใน Program Board ของ SAFe ก็มีการนำเอาเชือกมาโยงกันระหว่างโพสต์อิตที่มี Dependency กันเพื่อแสดงให้เห็นเด่นชัดบนบอร์ดกันเลยทีเดียว
ตัวอย่างการ Visualization ให้เห็น Dependency ชัดเจนใน SAFe
❤️ ทิ้งท้าย
ทั้ง ATDD with Scenario Mapping, Agile Interaction และ Visualization นั้น แม้ว่าจะเป็นเครื่องมือที่เราพบว่า สามารถนำไปใช้ช่วยให้การทำโปรเจคมีความคล่องตัวและประสบความสำเร็จได้มากขึ้น แต่ก็ยังไม่สำคัญเท่า Mindset ของคนที่ทำงานในโปรเจค โดยเฉพาะผู้ที่มีส่วนสำคัญในการขับเคลื่อนโปรเจคไม่ว่าจะเป็นผู้บริหารและตัว PM เอง หากเขาเหล่านั้นยังไม่ยอมรับธรรมชาติของการทำงานที่ว่า แผนจะไม่เป็นไปตามแผน เราจึงต้องหั่นงานเป็นชิ้นเล็กที่ทำให้ได้ Feedback มาอย่างรวดเร็วเพื่อให้เกิดการเรียนรู้มากขึ้นไประหว่างทาง การนำเครื่องมือเหล่านี้ไปใช้ก็จะแทบไม่เกิดประโยชน์อะไรเลย
ถ้าใครเคยศึกษาเรื่อง Flight Levels มาบ้างคงพอจะได้กลิ่นของ Flight Levels ในบทความนี้ จริงๆเราก็ใช้อะไรทำนองนี้มาตั้งแต่เรายังไม่รู้จักคำว่า Flight Levels พอได้เจอกับ Klaus Leopold ที่ชวนมาเข้า Flight Levels Academy ก็เลยลงตัว ใครสนใจเรื่อง Flight Levles ก็ไปหาข้อมูลต่อได้ที่ https://www.flightlevels.io นะครับ
6ถูกใจ
5แชร์
1.6Kรับชม
แสดงความคิดเห็นของคุณ...
