empathy-put-yourself-on-their-shoes

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

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

จากปากของหนึ่งในผู้ร่วมเขียน และประกาศ Agile Manifesto for Software Development ท่านสอนไว้ประมาณนี้ ณ ค่ำคืนที่มือถือแก้วที่มีน้ำแข็งละเครื่องดื่มแอลกอฮอล์เบาๆ ท่ามกลางเสียงดนตรีแจ๊ส

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

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

จากประสบการณ์ส่วนตัวของผมทั้งที่ตอนดูแลบริหารจัดการทีมพัฒนาซอฟต์แวร์ทีมเล็กๆ แต่ทรงพลัง และเมื่อออกมาขายบริการนั้นพบว่า เมื่อคุณอยู่ในบริบทของการนำ SCRUM มาใช้ ผมมักจะเจอะเจอว่า

ใน 2 พิธีกรรมของ SCRUM

  1. Sprint Planning Part I ที่ Product Owner นำ PBI (Product Backlog Item) เข้ามาให้ทีมพัฒนาและส่งมอบ (Development Team) พร้อมกับตอบ 2 คำถามในแต่ละ PBI คือ
    • What เรากำลังจะพัฒนาใหม่ หรือปรับปรุง หรือแก้ไข หรือยกเลิก อะไร?
    • Why เพื่อตอบโจทย์อะไรในเชิงการการให้บริการ สินค้าและบริการ นั้นๆ ในการใช้งานของผู้ใช้งาน ทั้งภายนอก และ/หรือภายในองค์กร
  2. Product Backlog Refinement ที่ Product Owner กับ ทีมพัฒนาและส่งมอบ (Development Team) เข้ามาร่วมกันเพื่อเตรียมความพร้อมของ PBI ที่อยู่ใน Product Backlog เพื่อให้เกิดความสมบูรณ์ พร้อม และประณีต เพื่อให้ตอบคำถาม What และ Why

ซึ่งที่มักจะเกิดขึ้นใน 2 พิธีกรรมนี้คือ

  1. Product Owner ก็ ไม่มีความรู้ ไม่รู้จัก ไม่เข้าใจ มิเคยใช้ สินค้าและบริการ สินค้าและบริการ โดยเฉพาะอย่างยิ่งไม่รู้ด้วยซ้ำว่าทำให้ใครใช้บ้าง ซึ่งมักจะมองแค่คำว่า ลูกค้า แต่ก็จะลืมผู้ใช้ภายในองค์กร เช่น ทีม Call Center ทีม Customer Support หรือทีมบัญชี เป็นต้น
  2. ทีมพัฒนาและส่งมอบ (Development Team) ก็ ไม่มีความรู้ ไม่รู้จัก ไม่เข้าใจ มิเคยใช้ สินค้าและบริการ สินค้าและบริการ โดยเฉพาะอย่างยิ่งไม่รู้ด้วยซ้ำว่าทำให้ใครใช้บ้าง ซึ่งมักจะมองแค่คำว่า ลูกค้า แต่ก็จะลืมผู้ใช้ภายในองค์กร เช่น ทีม Call Center ทีม Customer Support หรือทีมบัญชี เป็นต้น

ซึ่งเป็นเรื่อง ผิดปกติที่ปกติ

เพราะไม่ว่าจะเป็นใคร เมื่อวันหนึ่งบอกว่าเราจะใช้ SCRUM แล้วก็จับไปสอนๆๆ เรียนๆๆ แล้วก็คิดว่าเขาเหล่านั้นจะประพฤติตนเยี่ยงกับ  Product Owner และ Development Team แบบที่เขียนไว้ใน SCRUM นั้นได้ในชั่วข้ามคืนนั้น หาได้จะเกิดขึ้นไม่ เราไม่สามารถปรับเปลี่ยนพฤติกรรม และจริต ของใครได้ภายในระยะเวลาสั้นๆ และไร้ซึ่งการนำพาต่อไปเพื่อให้เกิดการเปลี่ยนแปลงนั้นอย่างต่อเนื่อง

หลายๆ คนน่าจะเจอคำว่า UX (User Expereince) และน่าจะมีคำว่า Empathy ผมขอยำความหมายจากเว็บไซต์หนึ่งที่ให้ความหมายไว้น่าฟังว่า

Empathy

จุดที่น่าสนใจในมุมมองผมคือ

  • Experience = ประสบการณ์ ซึ่งเกิดจาการการที่ใช้งาน สินค้าและบริการ นั้นๆ
  • Understanding another person’s condition from their perspective = เข้าใจ เกิดจากการใช้งาน สินค้าและบริการ นั้นๆ ในบริบทและเงื่อนไขของผู้ใช้แต่ละกลุ่มบุคคลที่เกี่ยวข้องกับ สินค้าและบริการ นั้นๆ
  • You place yourself in their shoes and feel what they are feeling

เกี่ยวข้องอย่างไรกับพิธีกรรม 2 พิธีกรรมของ SCRUM ที่ผมกล่าวไว้ข้างต้น

เมื่อไม่มีความรู้ ความเข้าใจ ไร้ซึ่งประสบการณ์การใช้งาน แถมไม่รู้จักด้วยว่าผู้ใช้ สินค้าละบริการ นั้นๆ ต้องการอะไรจริงๆ ใน 2 พิธีกรรมนั้นก็จะ อุดมไปด้วย ความเพ้อฝัน ฟุ้งฟิ้ง ฟุ้งซ่าน เทคโนโลยี โซลูชั่น เทคนิคอล มันเลยออกมาเหมือนเดิม เหมือน เหล้าเก่าในขวดใหม่ เท่านั้น

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

“บุญทักษ์ หวังเจริญ” lead the change สมาคมธนาคารไทย 2 ปีกับการผลักดันแผน 5 ปี ระบบแบงก์กิ้งไทย 13 เรื่อง 7 เป้าหมาย

หนึ่งในเรื่องที่ผมชอบคือ

เปลี่ยนได้-ไม่ได้ ไม่ใช่เทคโนโลยี อยู่ที่ “วัฒนธรรมองค์กร”

เพราะคนส่วนใหญ่คิดว่าการนำการพัฒนาและส่งมอบซอฟต์แวร์แบบแอจไจล์เข้ามาปรับใช้แล้วนั้นมันจะสร้างการเปลี่ยนแปลงให้ดีขึ้น มิหนำซ้ำการนำ เทคโนโลยีใหม่ๆ ล้ำๆ เข้ามาใช้ มันจะทำใก้เกิดการเปลี่ยนแปลงที่ดีขึ้น จริงๆ แล้วเป็นแค่ประเด็นรอง แถมเล็กๆ ประเด็นที่สำคัญมันคือเรื่องของ “บุคคล และวัฒนธรรมองค์กร” นะจ๊ะ

ผมตั้งชื่อบทความนี้ว่า เอาใจเขามาใส่ใจเรา สิ่งที่ SCRUM Team ต้องทำทุกๆ วัน เพราะ ในบริบทของ SCRUM นั้น SCRUM Team ประกอบไปด้วย

  • 1 Product Owner และทีมผู้ช่วยของ Product Owner
  • 1 Development Team ซึ่งประกอบไปด้วยกลุ่มบุคคลที่มีความรู้ ประสบการณ์ และทักษะที่จะช่วยกันสร้างสรร พัฒนา ดูแลควบคุมคุณภาพ และส่งมอบซอฟต์แวร์
  • 1 ScrumMaster ซึ่งเป็นผู้นำทางจิตวิญญาณ ที่มีประสบการณ์ในการเปลี่ยนแปลงการพัฒนาซอฟต์แวร์แบบแอจไจล์ โดยใช้ SCRUM

ซึ่งมั้ง 3 บทบาทนี้ต้อง มีความรู้  รู้จัก เข้าใจ ใช้ สินค้าและบริการ สินค้าและบริการนั้นๆ ในทุกๆ บริบทของผู้ใช้งาน

ผมขอยกตัวอย่างจากประสบการณ์ที่มีมาในอดีต

ตัวอย่างที่ 1:

ครั้งที่เคยเป็นหัวหน้าวินมอไซต์ เมื่อมีสมาชิกใหม่เข้ามาในทีมไม่ว่าจะบทบาทใดๆ แม้กระทั้งนักศึกษาฝึกงาน 2-3 วันแรกไม่ต้องทำงานอะไร นั่งเล่น สินค้าและบริการ นั้นๆ ทั้งบท Development Environment และบน Production Environment ที่เปิดให้บริการอยู่ แล้วในรายวันสรุปมาบอกกับเพื่อนพ้องในทีมว่า ชอบ ไม่ชอบ และมีไอเดียอะไรที่จะทำให้สินค้าและบริการนั้นดีขึ้น

ตัวอย่างที่ 2:

ครั้งที่ไปขายบริการ ณ บริษัทแห่งหนึ่ง ในยามบ่ายของการทำพิธีกรรม Sprint Planning พี่ท่านหนึ่งที่สวมหมวกเป็น Product Owner (พี่เขาเป็นโดยธรรมชาติจากประสบการณ์ 25 ปี) บอกกับทีมว่า Sprint นี้พี่ขอให้งานน้อยนะ เพราะพรุ่งนี้ทั้งวันอยากให้ทีมใส่รองเท้ากีฬามา แล้วไปเดินรอบๆ นี้ในรัศมี 5 กิโลเมตร แล้วลองใช้งาน Application บน Tablet ที่เราทำมา เพื่อให้รู้ว่าเวลาใช้งานจริงๆ แล้วนั้นคนที่จะต้องนำสิ่งที่เราทำอยู่ไปลงพื้นที่จริงๆ นั้นเขารู้สึกอย่างไร จะเจอปัญหาอะไร พอต้องเดินกลางแจ้ง กลางแสงแดด สีสรรที่ใช้บน Application นั้นมันเหมาะกับการใข้งานในเวลากลางวันหรือไม่ และเมื่อถึงเช้าวันที่นัดหมายทีมพัฒนาและส่งมอบซอฟต์แวร์พร้อมกับทีมผู้ช่วยของพี่ Product Owner ท่านนี้ก็ออกเดินกันเกือบตลอดทั้งวัน พร้อมได้ข้อมูลที่ได้จากการสมบทบาทการใช้งาน Application นั้นบน Tablet รุ่นที่จะถูกติดตั้ง

สุดท้าย และท้ายสุดของบทความนี้ ผมขอยก 2 กรณีศึกษาจากต่างประเทศ และขอให้สนุกกับการเห็นว่า You place yourself in their shoes and feel what they are feeling นั้นเป็นเช่นไร

และ

ณ จุดๆ นี้ ขอให้ทั้ง Product Owner เอย Development Team เอย ScrumMaster เอย รวมทั้ง Management หรือ C-Level ทั้งหลายที่หลงเข้ามาเสพบทความนี้จนถึงบรรทัดนี้ลองถามตัวเองดูสิว่า ณ ตอนนี้ที่ยังไม่ต้องนำแอจไจล์เข้าไปปรับใช้ในองค์กร

เรา

มีความรู้  รู้จัก เข้าใจ ใช้ สินค้าและบริการ สินค้าและบริการนั้นๆ ในทุกๆ บริบทของผู้ใช้งาน

แล้วหรือยัง?

วัฒนธรรมองค์กร เอื้อให้เกิด การรู้จัก เข้าใจ ใช้ สินค้าและบริการ สินค้าและบริการนั้นๆ ในทุกๆ บริบทของผู้ใช้งาน

แล้วหรือยัง?

ถ้าคำตอบออกมาว่า ยัง ผมก็แนะนำให้ปรับปรุงเปลี่ยนแปลงและทำให้เกิดสิ่งนี้ก่อนที่จะไปสู่ การพัฒนาซอฟต์แวร์ด้วยแอจไจล์ ไม่ว่าจะเป็นประบวนท่าใดๆ เช่น SCRUM

วันเสาร์ที่ 7 พฤษภาคม พ.ศ. 2559 08:39 น.
อำเภอหัวหิน จังหวัดประจวบคีรีขันธ์