ในงาน Blognone Tomorrow 2019 มีเซคชั่นที่พูดถึง DesignOps (Design Operations) ซึ่งเป็นคำที่เราจะได้ยินกันบ่อยขึ้นในวงการเทคโนโลยี ผู้ที่มาให้ความรู้คือ คุณสรรพวิชญ์ ศิริผล ดีไซเนอร์จาก KBTG ผู้ผลักดันกระบวนการทำงาน DesignOps เข้ามาปรับใช้ใน KBTG ในหัวข้อ Keeping Up with the Dev Cycle by Way of Agile Design operation
คำนิยามของ DesignOps คือกระบวนการ, ทีม, แผนก ที่เชื่อมการทำงานระหว่างทีมดีไซเนอร์ และทีมนักพัฒนาให้สามารถทำงานด้วยกันอย่างกลมกลืน มีกระบวนการที่ชัดเจน และลดขั้นตอนยุ่งยากรวมถึงความผิดพลาดต่างๆ จากการพัฒนาผลิตภัณฑ์
Blognone มีโอกาสสัมภาษณ์คุณสรรพวิชญ์ เพื่อทำความเข้าใจกระบวนการ DesignOps อย่างละเอียด รวมถึงประสบการณ์ของ KBTG หลังนำกระบวนการ DesignOps มาปรับใช้แล้ว เกิดผลอย่างไรบ้าง
ในมุมมมองของ KBTG มองว่า DesignOps เป็นตำแหน่งที่เหมือนจิ๊กซอตรงกลาง คอยเชื่อมการทำงานระหว่างดีไซเนอร์, นักพัฒนา, ฝ่ายธุรกิจ และ tester เข้าด้วยกัน
คนที่มาทำหน้าที่ DesignOps ต้องสามารถแปลภาษาของนักพัฒนาให้ดีไซเนอร์เข้าใจ (และในทางกลับกันคือแปลภาษาดีไซเนอร์ให้นักพัฒนาเข้าใจ) หากบางครั้ง นักพัฒนาไม่สามารถพัฒนาผลิตภัณฑ์ให้ตรงตามสิ่งที่ดีไซเนอร์ออกแบบมา เนื่องจากข้อจำกัดทางเทคนิคบางอย่าง DesignOps ต้องพยายามสื่อสารให้ทุกฝ่ายเข้าใจตรงกัน และร่วมกันคิดว่าจะแก้ปัญหาที่เกิดขึ้นอย่างไร
จุดเริ่มต้นมาจากการพัฒนาแอป K PLUS เลย เนื่องจาก K PLUS เป็นโปรเจกต์ใหญ่ มีดีไซเนอร์เข้ามาทำงานถึง 8 คน และมีนักพัฒนาที่รอเขียนโค้ดต่อเป็นร้อยคน เท่ากับดีไซเนอร์ 1 คน ต้องทำงานซัพพอร์ตนักพัฒนาเป็นจำนวนมาก แต่ละฟีเจอร์ถูกแบ่งให้ 1-3 ทีมนักพัฒนา แล้วแต่ขนาดของฟีเจอร์นั้นๆ
ระหว่างการทำงานย่อมมีปัญหาเกิดขึ้น เมื่อนักพัฒนาเขียนแอปมาได้ระดับหนึ่ง หลายครั้งก็ติดประเด็นว่าตัวฟีเจอร์ที่ออกแบบไว้ทำงานไม่ได้ เพราะไม่สามารถดึงข้อมูลจาก API มาได้อย่างที่คิดไว้ตอนแรก ดีไซเนอร์จึงต้องเริ่มคิดว่าจะดึงอะไรมาแสดงแทนในพื้นที่ตรงนั้น หรือยอมปล่อยว่างไว้
นอกจากนี้นักพัฒนาทำงานไปสักพัก ก็ยิงคำถามเข้ามาหาดีไซเนอร์เรื่อยๆ ว่าตรงที่ออกแบบไว้มีจะแสดงผลอย่างไร เมื่อเกิดเคสอื่นๆ ที่ไม่ได้ออกแบบไว้ เช่น Internet เชื่อมต่อไม่ได้ หรือแสดงผลการค้นหาไม่เจอ ยิ่งทีมนักพัฒนามีปริมาณมาก บางทีก็ไม่รู้ทั่วถึงกันว่าดีไซเนอร์คนไหนรับผิดชอบการออกแบบฟีเจอร์ไหน อาจถามผิดคนบ้าง ต้องรอประสานงานต่ออีก กว่าจะถามได้ถูกคนจึงใช้เวลานาน กระบวนการพัฒนาก็ล่าช้า DesignOps จึงมีบทบาทเข้ามาอุดช่องว่างตรงนี้
เพื่ออุดช่องว่างของการสื่อสารระหว่างทีม คนที่เป็น DesignOps ต้องเข้ามาเกาะการทำงานตั้งแต่เริ่มออกแบบเลย กระบวนการตั้งแต่ตอนที่ส่งหน้าสกรีนออกแบบไปให้นักพัฒนา ควรมี DesignOps เข้ามาอยู่ด้วยแล้ว เพื่อจะได้รู้ว่า ดีไซเนอร์คนไหนรับผิดชอบออกแบบฟีเจอร์ไหน
คุณสรรพวิชญ์เล่ากระบวนการทำงานของทีมออกแบบ และเครื่องไม้เครื่องมือที่ช่วยให้งานมีความสอดคล้องกันให้เห็นภาพชัดเจนขึ้น
ในการทำงานของ Designer Team เราเลือกใช้ Sketch เป็นเครื่องมือหลักในการออกแบบ ทั้งเว็บไซต์และโมบายแอปพลิเคชั่น เนื่องจาก ณ เวลาที่เริ่มออกแบบโปรเจค K PLUS 5.0 นั้น Sketch ยังเป็นเครื่องมือที่แก้ปัญหาในข้อจำกัดหลายอย่างๆ ในการทำงานได้ดีที่สุด ไม่ว่าจะเป็นจำนวน Plugins ที่หลากหลายที่สามารถช่วยลดเวลาในการทำงาน รวมถึงยังมีซอฟต์แวร์ที่ช่วยจัดการเรื่อง Version Control อีกหลายตัว แต่สุดท้ายทีมเราเลือกที่ใช้เครื่องมือชื่อ Abstract ที่ออกแบบมาเพื่อ Sketch โดยเฉพาะ เครื่องมือตัวนี้ช่วยให้ DesignOps สามารถวางแผนในการสเกลขนาดทีมในแต่ละงานได้ ตามความเร่งด่วนในแต่ละช่วงเวลา
ต่อมาเมื่อโปรเจกต์มีขนาดใหญ่ขึ้น ปัญหาถัดมาที่เจอคือดีไซเนอร์มักจะลืมไปแล้วว่า ฟีเจอร์เก่าที่เคยออกแบบไว้เมื่อ 1-2 เดือนก่อนนั้น มีการจัดเรียงข้อมูลในแต่ละหน้าอย่างไร และมี Flow การทำงานตั้งแต่ต้นจนจบอย่างไรบ้าง
DesignOps จึงแก้ปัญหาด้วยการเพิ่มเครื่องมือที่ชื่อ Overflow เพื่อช่วยให้ Designer สามารถทำ Document เป็น Screen Flow ได้ง่ายและรวดเร็วมากขึ้น และแชร์ผ่านเว็บไซต์ให้ทีม Business ตรวจทานอีกครั้งก่อนส่งให้ทีมพัฒนาได้ในขั้นตอนต่อไป
การมี Screen Flow เพิ่มเข้ามายังช่วยให้กับทีม BA (Business Analysis) และทีมนักพัฒนาในการทำงานแบบ Agile สามารถทำ Sprint Planning ได้ก่อนโดยไม่ต้องต้องรอ Screen ที่สมบูรณ์ทั้งหมดจากดีไซเนอร์เหมือนในอดีต ซึ่งในช่วงที่ทีมพัฒนาวางแผนและเตรียม API นั้นจะมีเวลาให้ ดีไซเนอร์สามารถปรับ Elements ต่างๆ ในงานให้เรียบร้อย ทั้งเรื่อง Spacing, ขนาดตัวหนังสือ และระยะ Grid รวมถึงการเตรียม Assets (รูปภาพ และ icons) ที่เหมาะสมกับทั้ง 2 แพลตฟอร์มของแอปพลิเคชั่นอีกด้วย จากนั้นจึงทำการส่งทั้งหมดผ่านทางเครื่องมือที่ชื่อ Zeplin เพื่อให้นักพัฒนาสามารถเข้ามา Inspect และดาวน์โหลด Assets นำไปใช้งานได้ต่อไป
คุณสรรพวิชญ์ มองว่า ถ้าองค์กรนั้นสามารถวางโรดแมปการพัฒนาแอพพลิเคชั่นได้นานระดับ 6 เดือน - 1 ปี และมีงบประมาณจำนวนหนึ่ง ก็ควรเริ่มมองหา DesignOps ได้แล้ว เพราะการนำทีม DesignOps เข้ามาทีหลังกระบวนการพัฒนาเริ่มไปแล้ว อาจต้องใช้เวลาไปกับการแก้ปมปัญหาเก่าๆ ไปพร้อมกับตอนที่เริ่มพัฒนาฟีเจอร์ใหม่
การมี DesignOps ในทีมตั้งแต่แรกช่วยให้การพัฒนาไวขึ้น เพราะ DesignOps จะมาประสานการทำงานระหว่างฝั่งออกแบบและฝั่งพัฒนาตั้งแต่วันแรก คุณสรรพวิชญ์เล่าว่า จากประสบการณ์ที่เจอมาคือ ทั้งสองฝั่งมักไม่ค่อยคุยกัน เมื่องานติดขัดทำให้สื่อสารกันแล้วไม่เข้าใจกัน จนถึงสื่อสารไปไม่ถึงทีมอื่นที่เกี่ยวข้องด้วย
นอกจากการพัฒนาผลิตภัณฑ์แล้ว DesignOps ยังช่วยให้คำแนะนำและตัดสินใจว่า ควรรับสมัครคนทำงานตำแหน่งไหนเข้ามาเพิ่มในทีมดีไซน์ก่อน เพื่อให้ส่งมอบงานในโปรเจกต์ได้ตรงตาม Timeline ที่ถูกกำหนดไว้ เช่น ควรรับดีไซเนอร์ที่เน้นด้าน User Research, UX หรือ UI เข้ามาก่อนกี่ตำแหน่ง เป็นต้น
อย่างตอนทำ K PLUS ทาง DesignOps ได้พูดคุยกับทีมพัฒนาว่า ควรแบ่งการทำงานอย่างไร เมื่อทำงานเป็น Agile จะมีการแบ่ง Sprint และกี่สัปดาห์และมีการ Sprint Planning ในแต่ละ Feature อย่างไร เพื่อจะได้วางแผนต่อได้ว่าจะวางดีไซเนอร์มาสนับสนุนการทำงานของแต่ละ sprint อย่างไร แล้วก็นำ DesignOps เข้ามาช่วยเรื่องการสื่อสารและการใช้เครื่องมือร่วมกันอีกที
เนื่องจาก DesignOps คือคนที่เป็นจิ๊กซอระหว่างดีไซเนอร์และนักพัฒนา จึงจำเป็นต้องมีทักษะการเขียนโปรแกรมบ้าง โดยเฉพาะด้าน Front-end หรือมีพื้นฐานความเข้าใจการทำเว็บไซต์และ แอปพลิเคชั่นมือถือว่ามันมีข้อจำกัดอะไรบ้าง หรือถ้ายังไม่มีทักษะตรงนี้ก็ต้องหาวิธีเรียนรู้ คุยกับนักพัฒนาให้เข้าใจว่าข้อจำกัดของแต่ละแพลตฟอร์มคืออะไร
กล่าวโดยสรุปคือ DesignOps ต้องเป็นคนที่มีตรรกะแบบนักพัฒนาอยู่ในตัว และรักที่จะทำงานกับดีไซเนอร์ เช่น เป็นคนเรียนวิศวกรรมคอมพิวเตอร์มา และค้นพบว่าตัวเองชอบทำงานสายที่คาบเกี่ยวกับการออกแบบมากกว่า เป็นต้น
ส่วน Soft skill ก็สำคัญมาก ต้องมีความเห็นอกเห็นใจ เข้าใจคนอื่น เพราะแต่ละทีมย่อมมีข้อจำกัดของตัวเอง อย่างทีมธุรกิจก็ต้องทำตามผู้บริหารสั่งมา ส่วนนักพัฒนาก็ต้องทำให้ได้ตามกรอบเวลาที่วางไว้ ดีไซเนอร์ก็ต้องออกแบบให้ได้ภายในระยะเวลาจำกัด และต้องทำให้มันออกมาสวย ดังนั้น DesignOps จึงต้องเข้าใจข้อจำกัดเหล่านี้ และออกแบบวิธิการบริหารงานให้ราบรื่นที่สุด
คุณสรรพวิชญ์ มองว่า DesignOps จำเป็นต้องมีทักษะการออกแบบ แต่อาจจะไม่ต้องโดดเด่นในเรื่องความคิดสร้างสรรค์เพราะนั่นเป็นหน้าที่หลักของดีไซเนอร์ แต่สิ่งที่ DesignOps ต้องทำคือ การรวบรวมไอเดียที่ดีไซเนอร์ออกแบบมา ให้เข้ามาเป็นระบบกลางได้อย่างไร
ถ้าแพลตฟอร์มขยายใหญ่ขึ้น การมี DesignOps จะช่วยรักษาความสม่ำเสมอหรือ consistency ของงานได้
คุณสรรพวิชญ์ เล่าจากประสบการณ์ให้ฟังว่า คนที่มีหัวครีเอทีฟมากๆ มักจะรักษาความสม่ำเสมอของฟอนต์, สี ได้ไม่มากนัก ตัวอย่างเช่น ได้งานสีเทาเหมือนกันแต่เป็นคนละเฉดสี ดังนั้น DesignOps ต้องทำหน้าที่ควบคุมเรื่องนี้ เพื่อส่งมอบงานที่เป็นค่าสีเดียวกันเสมอให้ทีมนักพัฒนานำไปใช้ต่อไป
ต้องยอมรับว่าคนที่มีทักษะนี้หายาก KBTG โชคดีตรงที่ทีมดีไซเนอร์กลุ่มแรกๆ ที่เข้ามา เรียนจบทางวิศวกรรมคอมพิวเตอร์มา ก่อนมาจับงานดีไซน์ ตรงนี้สังเกตได้ว่าแอพ K PLUS เวอร์ชั่นก่อนยังใช้งานค่อนข้างยากและการแสดงผลไม่ทันสมัยเหมือนคู่แข่ง แต่ในปัจจุบันทั้งคู่กลายเป็นทีมงานที่สำคัญที่คอยแปลภาษาของโปรแกรมเมอร์ให้ทีมดีไซเนอร์รุ่นใหม่เข้าใจ ว่าควรออกแบบอย่างไรให้ตรงตาม Guideline ของ Mobile OS ทั้ง 2 Platforms
หลังจากที่ทีมเริ่มขยาย มีการรับดีไซเนอร์เข้ามาในทีมเพิ่มเติม DesignOps จะเข้ามาช่วยสื่อสารให้เข้าใจแต่แรกเรื่องวิธีการสื่อสารระหว่างทีมออกแบบและทีมนักพัฒนาให้มีประสิทธิภาพ
แนวทางการหาคนตำแหน่ง DesignOps ที่วางแผนไว้ตอนนี้คือ เทรนคนข้างในที่เหมาะจะเป็น DesignOps และถ้ามีคนนอกยื่นใบสมัครเข้ามาและมีแนวโน้มจะทำงานได้ ก็จะรับพิจารณาเช่นกัน
คุณสรรพวิชญ์ มองว่า ในไทยยังไม่มีแพลตฟอร์มแอปพลิเคชั่นใหญ่ๆ มากนัก จึงยังพอมีเวลาในการเทรนคน หรือพัฒนาทักษะ DesignOps ขึ้นมา
ในไทยตอนนี้ กลุ่มธุรกิจขนาดใหญ่ และสามารถลงทุนพัฒนาแพลตฟอร์มขนาดใหญ่ได้ในตอนนี้ คือกลุ่มธุรกิจการเงิน ส่วนหนึ่งก็เพราะเป็นกลุ่มธุรกิจที่จะโดน Disruption ได้ตลอดเวลาจากทั้ง Startup และองค์กรขนาดใหญ่ที่มาจากสายอุตสาหกรรมอื่น ดังนั้น DesignOps ในเมืองไทยน่าจะเริ่มจากกลุ่มธุรกิจนี้ก่อน เพราะมีความพร้อมทั้งเงินลงทุนและการสเกลคน
ส่วนอีกกลุ่มธุรกิจที่น่าจับตามองตอนนี้คือธุรกิจด้านสุขภาพ ที่ได้ถูกลดข้อจำกัดบางอย่างออกไป เช่นการรับยาที่ร้านขายยา และจำนวนกลุ่มผู้สูงอายุที่เพิ่มจำนวนมากขึ้น