โสเหล่ (Zolaé™) กับ
▪️วิธีคิดแบบ
▫️โสเหล่ (Zolaé™) กับ ▪️วิธีคิดแบบ "เปรียว" (Agile Mindset) เข้ากันและไปด้วยกันได้
โดย…อาจารย์กฤษฎ์ อุทัยรัตน์
LINE@ : https://goo.gl/LpxiYk
f Messenger : http://m.me/AJK.sciArtist/
เราคงเคยได้ยินกันบ่อยขึ้น มากขึ้น กว้างขึ้นกับคำฮิตแฟชั่นช่วงเพลานี้ คำว่า “Agile” (อ่านว่า แอจ’ไจล์ หรือ แอจ’จิล) ผมแปลว่า “เปรียว” นะ ไม่ต้องเชื่อและเอาตามนะจ๊ะ ซึ่งก็แล้วแต่จะแปลกันไปว่ากระฉับกระเฉง, กระวีกระวาด, แข็งขัน, ว่องไว งัดเอามาใช้ได้เลย อีกคำนึง คำว่า “Scrum” (สกรัม : ลุยเพื่อให้บรรลุเป้าหมาย ส่วนใหญ่เรียกว่ารุมสกรัมทำนองนั้น แต่ในที่นี่คือรุมสกรัมงานนะครับ ไม่คิดลบนะจ๊ะ)
วิธีคิดแบบเปรียว (Agile Mindset) จะไม่เคร่งครัดในระเบียบวิธีปฏิบัติมากจนเกินไปคือมีการปล่อยวางบ้าง ยืดหยุ่นสูง เมื่อเทียบกับรูปแบบดั้งเดิมที่ใช้กันมานานหลายสิบปี เมื่อของเรื่องเกิดขึ้นในเดือนกุมภาพันธ์ ปี 2001 (พ.ศ.2544) เหล่าผู้รู้ที่มี ส่วนร่วมในการนำเสนอระเบียบวิธีการพัฒนา Softwareแบบใหม่ได้มีโอกาสนัดพบปะกัน ณ รีสอร์ท แห่งหนึ่งในรัฐยูท่าห์ เพื่อหารือถึงแนวทางร่วมกันในการนำเสนอสิ่งที่กลุ่มฅนเหล่านี้ได้ค้นพบ ซึ่งได้ข้อสรุปว่าชื่อ Agile” (แอจ’ไจล์) ครับ
Agile (เปรียว) จึงเป็นชื่อเรียกรวมๆ ของระเบียบวิธีการพัฒนาซอฟแวร์หลายชนิด ซึ่งมีแนวทางร่วมกัน 4 ข้อ ดังนี้
▪️(1) เน้นการให้ความสำคัญกับ “ฅน” โดยเน้นที่การทำงานร่วมกัน และกระจายอำนาจในการตัดสินใจไปสู่หน้างานจริงๆ
▫️(2) เน้นการสร้าง Software ที่ใช้งานได้จริงมากกว่าการยึดถือเอกสารหรือรายงาน อย่างที่ปฏิบัติต่อๆ กันมา
▪️(3) เน้นการทำงานร่วมกันระหว่างนักพัฒนาและลูกค้าหรือผู้ใช้ตลอดโครงการ เหตุเพราะความต้องการของระบบนั้นเป็นสิ่งที่ไม่สามารถเก็บได้ก่อนที่จะเริ่มงานจริง Feedback จากลูกค้าหรือผู้ใช้เป็นสิ่งเดียวที่จะบอกได้ว่า Software นั้นถูกต้องหรือไม่
▫️(4) เน้นการรับความเปลี่ยนแปลงได้ตลอดเวลา แม้ในช่วงท้ายของโครงการ เนื่องจากธุรกิจเป็นสิ่งที่ต้องก้าวไปข้างหน้า และความเปลี่ยนแปลงในโลกธุรกิจเกิดขึ้นทุกวัน Software ที่ไม่สามารถตอบสนองต่อความเปลี่ยนแปลงนั้นได้ จะไม่สามารถนำพาธุรกิจไปสู่ความสำเร็จได้อย่างยั่งยืน
▪️นอกจากนั้นแล้ว ยังได้มีการกำหนดข้อปฏิบัติ อีก 12 ข้อ ผมเห็นว่าดีมากๆ ก็เลยขอนำมาผนวกเข้ากับ HR พัฒนาองค์กร งานให้คำปรึกษาไปด้วย เพื่อให้สามารถปฏิบัติตามได้และนำมาปรับใช้ได้ นะครับ คือ
1. เปลี่ยนจากทำงานให้ “เสร็จ” เป็นส่งมอบ Software (หรืองานหรือผลิตภัณฑ์/บริการ) ที่มีคุณค่าและสร้างความพึงพอใจให้แก่ลูกค้า คือการทำให้มัยน “สำเร็จ” แทน
2. Software ต้องก้าวไปพร้อมธุรกิจของลูกค้า เปรียบเสมือนงาน การให้คำปรึกษา การคิด การทำต้องพร้อมและสอดคล้องไปกับนโยบายและประเภทธุรกิจนั้นๆ ด้วย
3. Software จะต้องถูกออกแบบให้สามารถยอมรับความเปลี่ยนแปลง (Change) ได้เสมอ แม้จะเป็นช่วงท้ายของโครงการ เช่นเดียวกันฅน HR ที่ปรึกษาต่างๆ ต้องเข้าใจบริบทของความไม่เที่ยงแท้จีรังไว้ด้วยเสมอ กฎแห่งธรรมชาติข้อนี้ไม่เคยเปลี่ยนแปลงและมันจริงจังเสมอไป คือต้องรู้จักปรับเปลี่ยนให้เป็น อย่าคิดว่าเป็นไปไม่ได้ หรือกลัวต้องเหนื่อย
4. Software ที่ใช้งานได้จริงจะต้องถึงมือลูกค้าอย่างสม่ำเสมอ เพื่อรับรู้ถึง Feedback หรือเสียงสะท้อนกลับจากลูกค้า ฅนจากทั้งฝั่งธุรกิจและนักพัฒนาจะต้องทำงานร่วมกันเป็นประจำทุกวันตลอดโครงการ เช่นเดียวกันหัวหน้ากับลูกน้อง ที่ปรึกษากับลูกค้า HR กับพนักงานก็ต้องเข้าถึง รับฟังและบอกผลดีผลเสียที่ตามมาเป็นระยะๆ ด้วย เพื่อสื่อสารไม่ให้เกิดปัญหาความเข้าใจผิดและล่มสลายของงานในภายหลัง
5. เริ่มจากคัดเลือกฅนที่เหมาะสมกับงาน และให้อำนาจในการตัดสินใจที่เหมาะสมไปด้วย กระบวนการสรรหาคัดเลือกของงาน HR ต้องมาสกรีนให้เหมาะเจาะ
6. ใช้การสื่อสารที่มีความกว้างที่สุดเท่าที่เป็นไปได้ หมายถึงการสนทนาแบบ ตั้งวงโสเหล่ (Zolaé™) เห็นหน้าค่าตากันให้เยอะๆ มันก็ย่อมดีกว่าการไลน์ การโทรศัพท์ ส่วนการโทรศัพท์ย่อมดีกว่าการส่งอีเมล์ อะไรทำนองนี้ บางทีการเปลี่ยนหรือสร้างบรรยากาศให้ผ่อนคลาย เป็นกันเอง นอกสถานที่บ้างก็เป็นตัวช่วยให้การสื่อสารนั้นสำเร็จได้ดีนะ
7. วัดความก้าวหน้าของงานจาก Software ที่ทำงานได้จริง ไม่ใช่เอกสารหรือรายงาน เช่นเดียวกัน ธุรกิจมีเอกสารมากมาย กติกาชัดเจนรุงรัง แผนกลยุทธ์แนว Documented แต่กำไรไม่เข้าเป้า ลูกค้าน้อยลงก็ไร้ความหมาย หรือ เขียนสัญญาแต่พอผิดสัญญาก็รอมชอม ปล่อยไป ไม่เอาจริงก็ไร้ประโยชน์ สอนและเข้าใจ Soft Skill แต่มันไม่ซึ้งเข้าในหัวใจผลลัพธ์ออกมาตรงกันข้าม ลูกน้องไม่เชื่อฟัง วินัยหย่อน มาสายบ่อย ใบเตือนปลิวว่อน ลาออกเยอะ KPIs พลาดเป้า เป็นต้น แล้วมันประโยชน์อะไร จริงป่าว
8. การทำงานต้องยั่งยืน การโหมงานให้เสร็จตามกำหนดที่กระชั้นชิด (หางจุกตูด) จะส่งผลต่อคุณภาพของ Software (หรืองานการที่ทำหรือให้คำปรึกษาไป) ในระยะยาว
9. จะต้องใส่ใจในความสมบูรณ์ของการสร้างสรรค์ทุกขั้นตอนเพราะ Software มีอายุการใช้งานที่ยาวนานมากกว่า Hardware เว้นแต่มีการเปลี่ยนแปลง ซึ่งก็บ่อยมากๆ เดี๋ยวนี้ เหมือนงานก็ต้องใส่ใจทุกขั้นตอน ต้องดูเชื่อมโยง มองขาด วางระบบเผื่อการเปลี่ยนแปลง และเปิดช่องให้อนาคตที่มีแนวโน้มเปลี่ยนแปลงแน่ๆ ถูกลดผลกระทบหรือความเสียหายที่จะเกิดขึ้นให้น้อยลงหรือไม่ส่งผลอะไรเลย ยิ่งดี
10. Software ที่สร้างแล้วเป็นภาระในการดูแลรักษา เช่น ต้องการทดสอบอย่างสม่ำเสมอ ดังนั้นการไม่สร้าง Software ส่วนที่ไม่เกิดมูลค่าจะเป็นการดีที่สุด ได้แก่ ไม่สร้างฟีเจอร์ที่ไม่ถูกใช้หรือใช้ไม่บ่อยนัก เหมือนกับงานที่เราทำก็ต้องโฟกัสเฉพาะที่สำคัญจริงๆ หากคิดว่าทุกอย่างก็สำคัญไปหมด เราตายแน่ๆ เราทำไม่ไหวหรอก ใช้เวลานานไป เพราะไอ้เจ้าสิ่งที่สำคัญน้อยๆ ลงไปนั้นมันไม่คุ้มที่จะทำ ไม่เกิดมูลค่า จะก่อหนี้และเพิ่มต้นทุนด้วยซ้ำไป
11. สถาปัตยกรรม Software ที่ดีที่สุดมาจากที่หน้างานจริงไม่ใช่หอคอยงาช้าง หัวหน้าก็ต้องลงหน้างานดูเห็นเข้าใจปัญหาจะได้แก้ไขป้องกันได้ตรงจุดที่สุด “ชี้ให้ถูกที่ จี้ให้ถูกจุด” ทำนองนั้นครับ
12. ทีมที่ดีจะต้องมองย้อนถึงสิ่งที่ตนเองได้ทำไปแล้วเป็นประจำสม่ำเสม เพื่อนำมาปรับปรุงแก้ไขวิธีการทำงานอย่างต่อเนื่อง เพื่อให้ทีมมีประสิทธิภาพการทำงานดียิ่งๆ ขึ้นไป คือ อย่ายินยอมที่จะยึดมั่นถือมั่นว่าที่ทำเสร็จแล้วมันจะใช่และสมบูรณ์แบบ เปลี่ยนแปลงไม่ได้ ห้ามพัฒนาต่อ ต้องคิดใหม่ว่าวันนี้ทำได้ดีมีมาตรฐานแล้ว พรุ่งนี้เกิดมีอะไรใหม่ๆ มาพลิกมาตรฐานของวันนี้ล่ะ วันนี้ก็ล้าสมัยไปเลยครับ
จากที่ผมนำมาเล่าสู่กันฟังข้างต้ ได้กลายเป็นเรื่องแพร่หลายโดยการเริ่มต้นมาจากงาน iT อย่างที่ว่านั่นแหละ และได้ถูกใช้ในหมู่ Startup กันเกร่อ แต่หากเข้าใจและ “ซึ้ง” ไปกับมัน ขอบอกว่าได้ผลดีนะ ก่อนอื่นต้องบอกก่อนว่า ‘Agile’ เป็นแนวคิดในการทำงานที่เป็นทางเลือกอีกทางหนึ่ง ไม่ได้บอกว่าเป็นทางเลือกสุดท้ายต้องเอาไปใช้แหง๋ๆ อะไรทำนองนั้นนะ อน่าสุดโต่งเกินไปก็ไม่ดี เอากลางๆ เพราะก่อนหน้านี้องค์กรส่วนใหญ่มักจะทำงานแบบ ‘Waterfall Process’ คือทำงานเป็นลำดับขั้นตอน แต่วิธีคิดแบบเปรียว (Agile Mindset) หรือ ปราดเปรียวว่องไวนี่ จะส่งผลให้มีรูปแบบการทำงานที่แตกต่างออกไป
วิธีคิดแบบเปรียว (Agile Mindset) นั้นเกิดขึ้นมาจากบริษัทที่ทำในเชิง Software Development เป็นหลัก เพราะปัญหาของระบบเดิมที่บรรดาบริษัท Software เจอจาก ระเบียบวิธีการพัฒนาซอฟแวร์หลายชนิดก็คือความยากในการวางแผน การนั่งคิดทุกอย่างตั้งแต่เริ่มจนถึงจบ Project นั้น เป็นเรื่องยากที่จะวางแผนทุกอย่างได้ลงตัวและแม่นยำ ทั้งในเรื่องของงบประมาณที่อาจจะบานปลายหรือเวลาที่ไม่ลงตัว กว่าจะรู้ว่าผิดพลาดก็อาจจะสายไปเสียแล้ว (ISO เรียกว่า Special Process กว่าถั่วจะสุก งาก็ไหม้ไปแล้ว) ในระบบแบบ Waterfall การไหลตามน้ำตามชั้นลดหลั่นลงมาแบบน้ำตกกว่าที่จะมีการทดสอบ Product หรือ Software นั้นก็ต้องเป็นในขั้น Test ซึ่งการ Design and Development นั้นแทบจะเสร็จอยู่แล้ว ถ้าไปเจอความผิดพลาดตอนนั้น ไม่ว่าจะด้วยเข้าใจ Requirements ผิดพลาดหรือมีการเปลี่ยนแปลงก็ตามเถอะครับ ไอ้การจะแก้ไขตามความต้องการนั้นก็จะทำได้ยาก (บางครั้งอาจถึงขั้นต้องรื้อทำกันใหม่ ทะเลาะกันอีกระหว่างลูกค้ากับผู้รับจ้าง เพราะต้องขอเงินสินจ้างเพิ่มขึ้น และแจ้งสาเหตุจริงๆ ให้ผู้จ้างรู้ ผู้จ้างก็คิดเอาว่ามึงหาข้ออ้างนี่หว่า) เรื่องนี้จะยกตัวอย่างให้เห็นภาพอีกทีครับ
เพื่อจัดการกับปัญหาเหล่านี้ วิธีคิดแบบเปรียว (Agile Mindset) ก็เลยถูกนำมาประยุกต์ใช้คือแทนที่จะวางแผน กำหนดเป้าหมายและมุ่งไปในครั้งเดียวให้เสร็จ ก็เปลี่ยนเป็นวางแผนและทำงานไปทีละนิดทีละหน่อย และค่อยๆ ประเมินว่าไปต่อไหวมั๊ย ไปต่อแล้วจะได้ดีมั๊ย ไปถูกทางมั๊ย แล้วจึงค่อยไปต่อ หรือจะหยุดแล้วปรับกันเดี๋ยวนั้นเลย ก็ทันการณ์นะ คือพยายามกำหนดเป้าหมายระยะสั้นและค่อยๆ เดินไป เพื่อที่เมื่อเจอปัญหาจะได้แก้ไขได้ง่ายขึ้น หรือเมื่อ Requirements เกิดการเปลี่ยนแปลงก็สามารถรับมือได้ดีขึ้น ซึ่งเป็นแนวคิดเดิมๆ เพียงแต่นัก iT ผู้บริหาร ฅน HR ไม่ได้เรียนรู้และให้ความสนใจมันเลย วิธีคิดแบบเปรียว (Agile Mindset) เป็นแนวคิดที่เกิดขึ้นหลัง TQM (Total Quality Management ซึ่งมีกระบวนการที่คุ้นโลก คือ PDCA Plan-Do-Check-Act สอนให้วางแผน ทำ ตรวจ ปรับปรุง ตั้งมาตรฐานแบบเป็นระยะๆ วางแผน (P) แล้วลงมือทำ (D) เลย ทำแล้ว (D) ไม่ได้เรื่องไม่พอใจ ก็วางแผน (P) ใหม่ แล้วทำ (D) ใหม่ ทำแล้ว (D) ตรวจสอบ (C) เออไม่ไหว ก็กลับไปทำ (D) ใหม่หรือวางแผน (P) ใหม่ คือหากไม่ใช่ตรงไหนของวงจร PDCA ก็สามารถวนกลับไปว่ากันใหม่ได้เสมอ ไม่ต้องทำจนสุดซอยแล้วเริ่มมาเริ่มใหม่ตรง P = Plan ทุกที มันเสียเวลา เสียเงินและเสียความรู้สึก)
เอาล่ะ ผมขอยกตัวอย่างให้เห็นภาพ อย่างโปรแกรมเมอร์เมื่อจะใช้วิธีการพัฒนา software ที่เดิมๆ จะใช้และเรียกว่า Waterfall นั้น มันมีแบบแผนชัดเจน คือ ต้องทำการวิจัยว่าลูกค้าต้องการอะไรหรือต้องรับ requirements จากลูกค้ามาก่อนถูกมั๊ย จากนั้น —> เขียนโปรแกรม ตาม requirements ที่ได้รับมาจากลูกค้า แล้ว—> ส่งมอบโปรแกรมที่เขียนเสร็จแล้วทั้งหมดให้กับลูกค้า
▪️เช่น บริษัท A ต้องการโปรแกรมทำบัญชีใหม่ จึงไปจ้างบริษัท software B มาทำโปรแกรมให้ บริษัท A ก็เขียน list มาว่า อยากจะให้โปรแกรมบัญชีใหม่นั้นทำอะไรได้บ้าง (ภาษา IT เค้าเรียกว่า “Feature” นั่นเอง) ก็ว่ามาเลย 1 2 3 4 5.. บริษัท software B ก็จะส่ง AE (Account executive) ซึ่งเป็นฅนดูแลเรื่องสัญญา การเงิน มาตีราคาว่า โปรแกรมแบบนี้น่าจะราคาเท่าไหร่ เมื่อตกลงราคากันเป็นที่เรียบร้อยแล้ว บริษัท software B ก็จะเอา requirement ดังกล่าว ไปส่งให้โปรแกรมเมอร์ทำ เจ้าตัวโปรแกรมเมอร์ก็นั่งทำตามจนเสร็จ ก็ส่งโปรแกรมบัญชีนี้ให้บริษัท A ไปใช้ คุณเห็นอะไรที่จะทำให้เกิดปัญหาตามมามั้ยครับ อืม ดังนี้ครับ
1. โปรแกรมเมอร์ แทบไม่ได้เจอกับ ฅนใช้งานเลย (User) แล้วจะทำโปรแกรมที่เหมาะกับฅนใช้ได้อย่างไร ลองคิดดูครับ ขนาดเรานั่งคุยกันเองอยู่ตรงหน้าแท้ๆ บางทียังคุยกันไม่ค่อยจะเข้าใจเลย การที่โยนแค่ requirements ให้หรือต่อให้คุยกันทีสองที จึงแทบจะเป็นไปไม่ได้เลยที่โปรแกรมเมอร์ จะเข้าใจและเขียนโปรแกรมที่เหมาะกับฅนใช้งานได้ 100%
2. การคุยงานก็คุยผ่านฅนกลาง ฅนที่ตีราคาว่าโปรแกรมนี้จะราคาเท่าไหร่ ไม่ได้เป็นฅนที่ทำโปรแกรมเอง ซึ่งเหตุผลที่ต้องมีฅนกลางของคุยงานเรื่องราคา ก็เพราะว่า ถ้าหากทำๆ ไปบริษัท A เกิดอยากได้ feature ใหม่ๆ แต่ดันไปคุยกับโปรแกรมเมอร์โดยตรง ก็จะทำให้บริษัท B ขาดรายได้ (เพราะถ้าคุยกับ AE ในการเพิ่ม requirements ทางบริษัท A ย่อมจะเสียเงินมากกว่า ไปคุยกับโปรแกรมเมอร์โดยตรงอยู่แล้ว เหมือนอย่างบริษัท A จ้างอาจารย์กฤษฎ์ไปบรรยาย อบรมให้พนักงานในบริษัทโดยตรงย่อมได้ราคาไม่แพงไปกว่าการจ้างอาจารย์กฤษฎ์ผ่านสถาบัน B ถูกมั๊ย จึงต้องมีฅนกลางไง)
3. เมื่องานจบ ส่งเสร็จ หากใช้งานแล้วไม่ถูกอกถูกใจบริษัท A การจะไปแก้ไขใหม่ เป็นเรื่องที่ยากสำหรับโปรแกรมเมอร์ (สำหรับฅนที่ไม่รู้เรื่องคอมเลย บางทีการแก้จุดเล็กๆ จุดเดียวในโปรแกรม อาจจะต้องตามไล่แก้จุดอื่นอีกหลายจุดที่มันเชื่อมต่อกันอยู่ด้วย บางครั้งใช้เวลามากกว่าเขียนโปรแกรมใหม่ขึ้นมาซะอีก) การแก้ก็ต้องใช้เงินจำนวนมากขึ้น (แต่ User ไม่รู้คิดว่าแก้นิดเดียว ยากตรงไหนว่ะ เออก็ไม่เคยมาเป็นโปรแกรมเมอร์เองนี่หว่า) บริษัท A ก็ไม่พอใจ และในที่สุดก็จะเกิดการกางสัญญา (requirements) ที่ทำไว้ตั้งแต่แรกว่าข้อตกลงเป็นอย่างไร เพื่อที่จะดูว่าใครผิดใครถูก ซึ่งไม่ว่าใครจะผิดหรือถูก ตาผลพวงหลังจากนั้น 2 บริษัทนี้ย่อมจะไม่อยากติดต่อซื้อขายกันอีกต่อไปแล้วแน่นอน
แต่พอได้เปลี่ยนมาใช้ วิธีคิดแบบเปรียว (Agile Mindset) หลังจากพอรู้ว่า โปรแกรมห่วยๆ นั้นเกิดจากสาเหตุอะไรแล้ว Agile จะเน้นให้โปรแกรมเมอร์ เข้าใจ user มากๆ ทั้งก่อน ขณะ และหลังทำโปรแกรม (กฎของ วิธีคิดแบบเปรียว (Agile Mindset) ข้อนึง ถูกเขียนไว้ว่า ถ้าทำโปรแกรมมาแล้ว ฅนใช้ไม่พอใจทั้งหมด คุณก็ต้องเปลี่ยนให้เค้าใหม่ทั้งหมดนะ รู้แล้ว ตามนั้นนะจ๊ะ เรื่องจริง) เพราะปัญหาใหญ่ของการทำโปรแกรมนั้น คือ ฅนใช้ไม่สามารถจินตนาการออกหรอกว่า โปรแกรมที่ยังไม่เกิดขึ้นมานั้น มันจะมีหน้าตาเป็นเยี่ยงไร ใช้ยากง่ายแค่ไหน แต่พอโปรแกรมเมอร์รับ requirements ไปแล้ว ทำจนเสร็จก็แล้ว ปรากฏว่า ฅนใช้ดันไม่ชอบ โปรแกรมเมอร์ก็ไม่อยากจะทำให้ใหม่แล้วก็จบแล้วไง อีกอย่างคือเพราะมันต้องทำเยอะมากครับ เกิดดราม่าขึ้นทั้งสองฝ่าย วิธีที่ง่ายที่สุด คือ ทำแบบคร่าวๆ เล็กๆ ให้ฅนใช้ได้ลองและวิจารณ์ก่อน ซึ่งถ้าทำเล็กๆ แล้ว ต้องการแก้โปรแกรมเมอร์ ก็ไม่ลำบากใจที่จะแก้ การทำงานแบบ Agile เราจึงต้องซอยงานออกมา เป็นชิ้นเล็กๆ และส่งให้ผู้ใช้หรือลูกค้าได้ลองใช้ มีประสบการณ์เกิดขึ้นบ่อยๆ (และก็เป็นที่มาของชื่อ Agile คือต้องส่งงานอย่างว่องไวหรือ “เปรียว” นั่นเองครับ) เพราะฉะนั้น เมื่อจบงาน ก็จะไม่เกิดปัญหา แก้ใหม่หมด (เพราะมันถูกแก้เล็กๆ น้อยๆ ไปก่อนหน้านั้นหมดแล้ว) ฅนใช้ไม่ถูกใจ (เพราะมันถูกปรับให้ถูกใจก่อนหน้านั้นไปหมดแล้ว)
วิธีคิดแบบเปรียว (Agile Mindset) นั้นไม่ได้มีการระบุเป็นกฎไว้อย่างชัดเจน หลักการสำคัญของ Agile ที่เห็นได้ชัดๆ นั้นจะประกอบไปด้วย
▫️1. ไม่เน้นกระบวนการ ไม่บ้าเอกสาร ให้เน้นไปที่การพัฒนาผลิตภัณฑ์ให้ดีที่สุดมากกว่าจะยึดติดกับเอกสารต่างๆ (ไม่ใช่ว่าไม่จำเป็นเลยนะ อย่าหลงประเด็น แต่ให้ความสำคัญน้อยกว่า) คือต่อให้มีเอกสารยืนยันแล้วว่าจะทำอะไร แต่มีอีกทางที่ส่งมอบ Value ให้กับลูกค้าได้ดีกว่า Agile จะเลือกทางนั้น ไม่ใช่ทางที่เอกสารเขียนไว้เท่านั้น แต่ระวังกับดักไว้ หากสิ่งที่ทำเกี่ยวกับฅน ต้องดูกฎหมายแรงงานด้วย คิดถึงมุมนี้ไว้ด้วย แต่ผมก็ชอบใจ วิธีคิดแบบเปรียว (Agile Mindset) ที่มันลดการทวงถามเอกสาร ซึ่งทำให้เราติดกับดักเมื่อไม่มีเอกสาร เดินทางมายังไม่ถึง ไม่เห็นการอนุมัติกูก็ไม่ทำ กว่าจะได้ลงมือทำ ก็เสียเวลาไปโขทีเดียว
▪️2. ยอมรับการเปลี่ยนแปลง เพราะ requirements อาจเปลี่ยนแปลงได้ตลอดเวลา มองเป็นธรรมชาติ วิธีคิดแบบเปรียว (Agile Mindset) จะไม่ฟูมฟาย คร่ำครวญไปกับการเปลี่ยนแปลง ไม่มีการทำงานหรือยึดติดกับ Gantt Chart Work Procedures Work Instructions คู่มือการทำงาน เป็นสรณะแต่จะทำงานแบบ ค่อนข้าง Flexible ตามสิ่งที่เกิดขึ้นจริงเป็นหลัก สามารถเปลี่ยนแปลงได้ตลอดเวลาตามความต้องการของลูกค้า ไร้บ่นกร่นด่ากันยึดโยงความจริงและปัจจุบันให้มากที่สุด (อยู่กับปัจจุบัน)
▫️3. ค่อยๆ ทำทีละนิดแต่อย่าเชื่องช้าอย่าง สลอธ หรือ สโลธ (sloth) แต่ต้องทำบ่อยๆ คือมีการส่งมอบงานอะไรบางอย่างให้ทีมหรือลูกค้าอย่างต่อเนื่องทีละเล็กทีละน้อย เช่น ส่งมอบอะไรใหม่ทุกๆ 2 อาทิตย์หรือทุกๆ เดือน จะไม่ให้ลูกค้ามีการรอนานไปหน่อยเพื่อรอ Project ใหญ่เสร็จแล้วค่อยส่งมอบทีเดียว
▪️4. แก้สิ่งผิดพลาดให้ว่อง คือไม่กลัวที่จะลงมือแก้ไขสิ่งผิด กลับหลังหันให้ไว เมื่อเจอกับความผิดพลาดให้แก้ไขไปทีละนิด จะไม่ใช่การวางแผนโดยละเอียดเพื่อป้องกันความผิดพลาด แต่พอเราเจอสิ่งที่ผิดไปจากแผนจริงๆ (เพราะอย่างที่รู้ว่าน้อยครั้งนักที่เราจะทำตามแผนได้ทั้งหมด)
▫️5. ทำงานเป็นทีมมากกว่าที่จะสนใจกระบวนการ คือเน้นที่การมีปฏิสัมพันธ์ระหว่างบุคคลมากกว่าที่บอกว่าต้องเป็นไปตามกระบวนการ มีปัญหาอะไรให้พูดคุยกับทีมตรงนี้แหล่ะบอกให้ ตั้งวงโสเหล่ (Zolaé™) ได้เลยทันที บางครั้งอาจถึงขั้นเอา Programmer ไปเจอลูกค้าเพื่อให้เข้าใจ requirements ที่แท้จริงด้วย ให้ลูกค้าเข้ามามีส่วนร่วมตั้งแต่เริ่มกระบวนการ ซึ่งทีมมักจะประกอบด้วยหลายๆ ตำแหน่ง และมีอำนาจมากพอที่จะตัดสินใจทำหรือไม่ทำอะไรเพื่อ Drive ให้งานที่ทีมรับผิดชอบสำเร็จตามเป้าหมาย
ข้อดีของการทำงานในแนวคิด Agile หลักๆ คือการไม่มีกำแพง (หรือมีก็ทำลายมันลงซะ) ระหว่างฝ่าย เพราะเอาทุกฝ่ายมาอยู่ในทีมเดียวกัน เน้นที่การสื่อสารระหว่างบุคคล ทำให้ลดความไม่เข้าใจลงไป และสามารถแก้ปัญหาได้รวดเร็วๆ (สมมติว่า Test แล้วมีปัญหา ก็สามารถบอกกับ Designer หรือ Programmer ให้แก้ไขได้ทันที โดยไม่ต้องส่งเรื่องข้ามฝ่าย) รวมถึงการที่ค่อยๆ ส่งมอบงานทีละนิดทำให้มีความยืดหยุ่นในการทำงานสูง ซึ่ง วิธีคิดแบบเปรียว (Agile Mindset) มักจะมาคู่กับกรอบการทำงาน (Framework) แบบ ‘Scrum’ จริงๆ ต้องบอกว่า Framework ภายใต้แนวคิด Agile นั้นมีหลากหลายวิธี แต่ ‘Scrum’ เป็นวิธีการทำงานที่ได้รับความนิยมมากที่สุดสำหรับการทำงานภายใต้แนวคิดนี้ มันคือวิธีการทำงานที่ให้ ‘ทีมช่วยกันรุมงาน’ ซึ่งในวิธีการทำงานแบบ Scrum จะไม่มี Project Manager, Design, Analyst, Tester (และอื่นๆ) แต่จะมีเพียงแค่ 3 ตำแหน่งสำคัญคือ
Product Owner มีหน้าที่ประเมิน Values และจัด Priorities ของ Tasks ต่างๆ ให้กับทีม Scrum Master เป็นผู้ทำให้การทำงานเป็นไปอย่างลื่นไหล ซึ่งไม่ได้หมายถึงการเป็นผู้นำทีม แต่จะคอยกำจัดอุปสรรคที่ขัดขวางไม่ให้ทีมบรรลุเป้าหมาย Team จะทำงานแบบ Self-Management ซึ่งในหนึ่งทีมจะประกอบด้วยฅนประมาณ 3-9 ฅน และรวมทุกตำแหน่งทั้ง Designer, Programmer, UI/UX, Testing เข้าด้วยกัน เพื่อให้ทีมหนึ่งทีมสามารถทำงานตั้งแต่ต้นจนจบได้ด้วยตัวเอง โดยไม่ต้องข้ามแผนก
วิธีการทำงานของ Scrum ก็จะประกอบไปด้วยสิ่งที่น่าสนใจดังนี้
1. Backlog : เป็น Task งานที่ต้องทำ ทั้ง requirement ของลูกค้าและทีม ซึ่ง Product Owner จะเป็นฅนตัดสินใจนำ Task ต่างๆ เหล่านี้เข้าไปใน Sprint ตามลำดับความสำคัญ (ส่วนใหญ่แล้วก็จะพิจารณาด้วย Value ของ Task นั้นๆ เมื่อแลกกับ effort ที่ต้องใช้)
2. Sprint Phase : อย่างที่บอกว่า Agile นั้น เน้นการส่งงานให้เร็วและบ่อย ซึ่ง Period นั้นจะเรียกว่า Sprint โดยมีกำหนดประมาณ 2-4 สัปดาห์ โดยเป้าหมายของ Sprint คือการ Deliver บางสิ่งบางอย่างให้สำเร็จ (Task ที่ Product Owner ได้ประเมินว่าควรทำตั้งแต่ก่อนเริ่ม Sprint) ซึ่งเมื่อจบ Sprint ก็จะมีการ Review ผลงาน (Sprint Review) ให้กับฅนอื่นๆ ที่เกี่ยวข้องอาจจะเป็นทีมเซลล์ Users หรือลูกค้า เพื่อให้รับทราบถึงความคืบหน้าของ Project อยู่เรื่อยๆ
3. Daily Scrum Meeting : ในทุกๆ เช้าทีมจะมีการประชุมสั้นๆ 10-15 นาที เพื่อบอกว่าเมื่อวานทำอะไร วันนี้จะทำอะไร และมีปัญหาอะไรบ้าง เพื่อให้การทำงานในทุกๆ วันเป็นไปอย่างราบรื่น ,รู้ว่ากำลังเดินเข้าสู่เป้าหมายหรือยัง และมีการแก้ไขปัญหาอย่างต่อเนื่อง
การประยุกต์ใช้ในองค์กรใหญ่ค่อนข้างทำได้ยาก เพราะมีทีมและแผนกที่ค่อนข้างใหญ่ ต้อง Downsize บ้าง การให้ทุกฅนยอมรับวัฒนธรรมนี้ค่อนข้างเป็นไปได้ยาก รวมถึงการแตกฝ่ายต่างๆ เพื่อมารวมเป็นทีมย่อยขนาดเล็กก็ทำได้ยาก
▪️วิธีคิดแบบเปรียว (Agile Mindset) เป็นแนวคิดที่ค่อนข้างสนับสนุนกับระบบแบบ Flat Organization (องค์กรแบนราบที่มี Layer ไม่ควรเกิน 3 นับตั้งแต่ระดับชั้นสูงสุดขององค์กร) เพราะฉะนั้นสำหรับบางบริษัทหรือบริษัทที่ผู้บริหารมีแนวคิดแบบ Pyramid Structure ก็จะประยุกต์ใช้ Agile ได้ยากขึ้นนะ วิธีคิดแบบเปรียว (Agile Mindset) เป็นแนวคิดที่พัฒนามาจากบริษัท Software Development เลยเหมาะในการใช้พัฒนา Technology Product มากกว่า แต่ไม่ได้หมายความว่าจะประยุกต์ใช้กับงานแบบอื่นไม่ได้นะ ปรับใช้ได้หมดแหล่ะในโลกใบนี้ เพียงแต่ต้องเข้าใจมันให้ “ลึก” และ “ซึ้ง” จริง
วิธีคิดแบบเปรียว (Agile Mindset) มันเกิดมานานแล้วนะครับ แต่มามีชื่อเสียงโด่งดังขึ้นมาทันทีเมื่อ ส่วนหนึ่งคือ ความสำเร็จของบริษัทเทคโนโลยีเกิดใหม่ (Tech Startup) อย่าง Google หรือ Facebook เมื่อมีคำถามว่าพวกเขาทำงานกันอย่างไร คำตอบเดียวคือพวกเขาใช้ “เปรียว” (Agile) มีหลายบริษัททั้งใหญ่และเล็กต้องการให้ตนเองประสบความสำเร็จในแบบเดียวกันกับ Google หรือ Facebook ก็เริ่มนำ วิธีคิดแบบเปรียว (Agile Mindset) ไปปรับใช้ในองค์กรของตนเองเมื่อมีการทำงานศึกษาพบว่า ข้อดีของการนำ วิธีคิดแบบเปรียว (Agile Mindset) ไปใช้มี 4 ด้านคือ
▫️1. พนักงานมีขวัญและกำลังใจในการทำงานดี
▪️2. เวลาในการพัฒนา Software ออกสู่ตลาด (Time To Market) สั้นลง
▫️3. ผลิตภาพสูงขึ้น และ
▪️4. ข้อบกพร่องของ Software (Defect) ลดลง
ซึ่งท้ายที่สุดแล้วหมายถึง ความก้าวหน้าทางธุรกิจ สิ่งสำคัญที่ช่วยให้ธุรกิจที่ใช้ วิธีคิดแบบเปรียว (Agile Mindset) ประสบความสำเร็จนั้นมาจากการส่งมอบคุณค่าให้แก่ลูกค้าตั้งแต่ช่วงต้นและต่อเนื่องตลอดการพัฒนา ซึ่งนอกจากจะช่วยให้สนองตอบต่อตลาดได้รวดเร็วแล้ว ยังสร้างความพึงพอใจให้แก่ลูกค้าอีกด้วย ที่สำคัญทีมพัฒนาเองก็ได้รับ Feedback เพื่อนำมาแก้ไขปรับปรุง Softwareในเวลาที่รวดเร็วอีกด้วย
ว่ากันแบบสรุป วิธีคิดแบบเปรียว (Agile Mindset) คือ ระเบียบวิธีพัฒนาซอฟแวร์หรือวิธีพัฒนาฅน พัฒนาองค์กร ที่ทำให้ฅนในองค์กรสามารถส่งมอบงานได้อย่างรวดเร็ว ต่อเนื่อง และโดนใจลูกค้าและบรรดาผู้มีส่วนได้ส่วนเสียกับองค์กรของคุณนั่นเอง ทั้งในมุมมอง iT และมุมมองอื่นๆ ที่จะนำมาปรับใช้ครับ
ผมก็เลยอยากให้เรามามองกัน และคิดอย่าง iT เนื่องจากในการพัฒนา Software นั้นจะต้องเร็วมาก และต้องตอบสนองต่อความต้องการของลูกค้าที่เปลี่ยนแปลงไปอย่างรวดเร็วมากๆ ให้ทันการณ์จริงๆ ดังนั้นแนวทางในการบริหารจัดการก็จะต้องรวดเร็วทันที วิธีคิดแบบเปรียว (Agile Mindset) จึงถูกนำมาใช้เน้นความรวดเร็ว ความคล่องตัว ยืดหยุ่นสูง ก็เลยนำมาประยุกต์ใช้กับงานธุรกิจในด้านอื่นๆ มากขึ้น ไม่เว้นงาน HR งานที่ปรึกษา งานพัฒนาองค์กร และผมเอง (อาจารย์กฤษฎ์ อุทัยรัตน์) มองว่าสามารถนำมาใช้กับงานให้คำปรึกษาด้านกฎหมายธุรกิจและกฎหมายแรงงานได้อย่างดีด้วยเพราะใช้อยู่ ในจะทำให้เกิดความทันสมัยยิ่งขึ้น ทั้งนี้ก็เพื่อตอบสนองความต้องการของลูกค้าได้อย่างรวดเร็ว เพื่อให้เกิดผลลัพธ์ที่ดีอย่างต่อเนื่อง
วิธีคิดแบบเปรียว (Agile Mindset) มันมาแทนที่การทำงานแบบ Waterfall ขอย้ำอีกที ซึ่งจะเป็นการวางแผน กำหนดเป้าหมาย กระจายงาน ใน step ขั้นตอนเดียว ทำให้กว่าจะได้ผลลัพธ์สุดท้าย ใช้เวลานานเนิ่น เกิดเป็นปัญหาใหญ่ตามมา 2 ประการสำคัญ ได้แก่
1. ปัญหาเรื่องการวางแผนให้เป็นไปตามเวลา และงบประมาณ เนื่องจาก scope ของงานใหญ่ และมีการแบ่งทีมกันดูแล ทำให้ใช้เวลาในการรวบรวมงาน หรือ communicate กันระดับหนึ่ง ส่งผลให้กว่าจะสำเร็จดังเป้าหมาย
2. ปัญหาเรื่องการเปลี่ยนแปลงทั้งภายใน และภายนอก ที่ส่งผลให้Projectต้องถูกพับเก็บไป เนื่องจากเป็น scope ใหญ่ ที่วางแผนระยะยาว ทำให้เมื่อเกิดปัญหา ที่ผิดพลาดไปจากแผน ก็ไม่สามารถปรับตัว หรือเปลี่ยนแปลงอะไรได้มากนัก
อย่างไรก็ตาม วิธีคิดแบบเปรียว (Agile Mindset) ต้องอาศัยมุมมอง และ Vision ของผู้บริหาร ด้วย เพราะเป็นแนวคิดที่เน้นให้เกิดงานแบบทีมเล็กๆ ที่แข็งแกร่ง อาจไม่เหมาะกับองค์กรใหญ่ที่มีทีม และแบ่งเป็นแผนกๆ ใหญ่ๆ ก็เป็นได้ แต่เอาล่ะ ถ้าบริหาร (Management) เป็นกันจริงๆ ไม่มีอะไรทำไม่ได้ เพียงแค่ Re-organization ซิ ง่ายนิดเดียวแค่อาศัยความกล้าก็พอ
อีกอย่างในมุมมองอย่าง iT ด้วย Software และ Technology Life Cycle มันสั้น ซึ่งเกิดจาก Technology Disruption นั้น ทำให้การทำ Project เกี่ยวกับ IT หรือ Product Development ต่างๆ เปลี่ยนรูปแบบไป จากเดิมที่เลือกซื้อ Software สำเร็จรูป จึงเปลี่ยนสภาพไปเป็นมองหา Software ที่ Flexible สามารถแก้ไข หรือเขียนโปรแกรมเพิ่มเติมเข้าไปในระบบเดิมได้ เพื่อลดความเสี่ยงเมื่อเกิดการเปลี่ยนแปลงในอนาคต
สิ่งที่ชวนให้คิดต่อคือ เมื่อ Life Cycle ของ Technology สั้นลง และดูเหมือนว่า ในระยะหลังๆ จะมีบริษัท Technology ใหม่ๆ เกิดขึ้น ที่มี Core Business หลักๆ เป็นการศึกษา และพัฒนา Technology โดยเฉพาะ ทำให้บริษัทยักษ์ใหญ่ที่มีแผนก IT ต่างๆ อาจต้องมีการปรับกลยุทธกันใหม่ จะ In-house หรือ Outsource ก็คงต้องมีการวางแผนกันอย่างรัดกุมอย่างเนิ่นๆ แล้วล่ะครับ
อาจารย์กฤษฎ์ อุทัยรัตน์
นักวิทย์ศิลป์
ผู้เชี่ยวชาญ HRM HRD OD Strategic Management TQM ISO
ผู้นำแห่งกฎหมายแรงงานแบบบูรณาการ อันดับหนึ่งในประเทศไทย
ผู้ไม่เคยแพ้คดีแรงงาน เชี่ยวชาญการบริหาร เข้าใจนายจ้างลูกจ้าง
“ชอบด้วยกฎหมาย ขอให้เป็นธรรม ย้ำหลักสุจริต ไม่คิดเอาเปรียบ”
✺Credit : อาจารย์กฤษฎ์ อุทัยรัตน์ Ref. : www.KRISZD.com
Credit : ꍏj.Kяιꌗz∂ ꀎ-✞ɧąıཞaṭⒸ อาจารย์กฤษฎ์ อุทัยรัตน์ นักวิทย์ศิลป์ S⃕c̫ίArϯίṧt
ωωω.ƘRISZD.ꉓom KDV@KRISZD.com
#สำนักงานอาจารย์กฤษฎ์ #AJKsMissionDevelopmentCenter #AJK_MDC #อาจารย์กฤษฎ์#AJK #AjKriszd #SciArtist #AJKPublicFigure #อาจารย์กฤษฎ์อุทัย??