Product Owner กับ Design Patterns

ระบบ ABC กำลังถูกพัฒนาขึ้นเพื่อรองรับผู้ใช้สองประเภท (1) ผู้ใช้ภายในบริษัทเองและ (2) ผู้ใช้ภายนอกที่เป็นเวนเดอร์และพาร์ทเนอร์ สิ่งที่ทีมงานกำลังกังวลกันอยู่คือการจัดการบัญชีผู้ใช้

Product Owner: “พี่เข้าใจนะว่าถ้าเป็นผู้ใช้ภายในเราดึงข้อมูลพนักงานมาจาก LDAP ของฝ่ายบุคคลได้ แต่กับพวกเวนเดอร์ล่ะ เราจะจัดการยังไง?”

System Analyst: “อืมมมม เอางี๊มั้ยพี่ เราก็สร้างระบบ LDAP พิเศษสำหรับกลุ่ม External User”

Product Owner: “หรอ ก็ได้มั้ง”

Product Owner ที่มีความรู้รอบตัวพอสมควรจะมองว่าแนวทางการสร้าง LDAP ขึ้นมาเองนั้นไม่ถูกต้องในทางปฏิบัติด้วยสาเหตุหลายประการ

1. การเรียกใช้ข้อมูลในเซิร์ฟเวอร์ด้วย LDAP แปลว่าเราต้องมีเซิร์ฟเวอร์เพิ่ม
2. การมีเซิร์ฟเวอร์เพิ่มแปลว่าเราต้องมีฐานข้อมูลที่แยกจากระบบ ABC ซึ่งเป็นระบบหลัก
3. ข้อมูลพนักงานใน LDAP ตามปกติแล้วถูกสร้างและอัพเดทโดยทีม HR (ผ่านระบบ HR Management ซักตัว) ถามว่าถ้าเรามีระบบ LDAP ที่ไว้เก็บข้อมูลคนนอกแล้วใครจะเป็นคนคอยตามอัพเดทข้อมูลที่เปลี่ยนแปลงตลอดเวลา? — ชื่อ นามสกุล อายุ วันเริ่มงาน ตำแหน่ง สถานะ (ทำงานอยู่ ลาออกแล้ว) …

แม้แต่การคิดจะเอาระบบ ABC ไปเชื่อมต่อกับเซิร์ฟเวอร์ LDAP ของเวนเดอร์และพาร์ทเนอร์แต่ละเจ้าก็เป็นเรื่องที่ยากอยู่ดี — ใครจะยอม? ถ้ามี 100 เจ้าก็ต้องเชื่อมต่อ 100 ครั้ง? แล้วถ้าเจ้านี้ไม่มี LDAP ล่ะ?

Product Owner ที่มีความขี้สงสัยพอสมควรจะถามตัวเองว่า

“เฮ้ย ระบบระดับโลกเค้าแก้ปัญหานี้ยังไงวะ?”

มองไปมองมาก็จะเห็นว่ามันมีรูปแบบมาตรฐานที่จัดการปัญหานี้อยู่ — เค้าเรียกว่าระบบส่งบัตรเชิญ (Invitation) ซึ่ง Trello, Slack, Mailbox, Pinterest และอีกมากมายหลายระบบใช้อยู่

ถึงแม้เราในฐานะ Product Owner จะไม่มีแบ็คกราวน์ด้านไอทีและการพัฒนาซอฟต์แวร์โดยตรงแต่เรา “จำเป็น” ต้องมีความรู้รอบตัวเรื่องการออกแบบและแก้ปัญหาในโดเมนของตัวเอง ผมเคยเขียนบทความเรื่องพลังพิเศษของ Product Owner ไปแล้วซึ่งหนึ่งในนั้นคือพลังพิเศษที่มองเห็น Design Patterns ที่ทีมพัฒนามองไม่เห็น …

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

สุดท้ายสำหรับวันนี้ — ทีมพัฒนาซอฟต์แวร์อาจจะโฟกัสแค่ “จะสร้างระบบ สร้างฟีเจอร์นี้อย่างไร” แต่ Product Owner มีหน้าที่กำหนดว่า “ควรจะสร้างระบบหรือสร้างฟีเจอร์นี้หรือไม่” ครับ

Web UI Design Patters from UXPin: https://www.uxpin.com/web-design-patterns.html

สุดท้ายจริงๆ — ถ้าใครสนใจเรื่อง UI Design Patterns ลองอ่าน Ebook เล่มนี้ดู เจ๋งมากผมเพิ่งอ่านจบอย่างรวดเร็วในเวลา 2 ชั่วโมง มันเป็นหนังสือที่รวบรวมข้อมูลและตัวอย่างการออกแบบ User Interface ที่ใช้แก้ปัญหาหลายๆแบบจากระบบและแอพระดับโลกครับ — ความรู้ทั้งนั้น

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ