Data Scientist, Data Analyst in different Organization - ฉบับคนนอกสายอ่านเข้าใจ
มองงานที่ Data Analyst, Data Scientist ทำผ่านการมองโครงสร้างทีม, ความแตกต่างระหว่าง Data Analyst, Data Scientist, Business-oriented vs Engineering-oriented, งานที่เกี่ยวกับทีมธุรกิจ
Introduction
ช่วงสองสามสัปดาห์ก่อนผมไปเจอกับคำถามหนึ่งเข้าซึ่งผมเองก็จำไม่ได้แล้วว่าไปอ่านเจอจากที่ไหน อาจจะเป็นบทความสักเรื่องใน medium หรืออาจจะมาจากการได้ฟังคำถามของคนที่อยู่นอกสาย ทุกคนต่างสงสัยว่า Data Analyst, Data Scientist ทำอะไรบ้าง แล้วสายงานทั้งสองแตกต่างกันอย่างไร ผมคิดว่ามันเป็นเรื่องยากที่จะอธิบายสิ่งที่พวกเราทำโดยไม่มีปัจจัยแวดล้อมมาเกี่ยวข้อง ผมมองว่างานของเราขึ้นกับทีมที่เราอยู่ ดังนั้นการจะเข้าใจว่าพวกเราทำอะไรและสร้างประโยชน์อย่างไร อันดับแรกควรเข้าใจก่อนว่ามีทีมประเภทไหนบ้าง เพราะลักษณะของทีมที่แตกต่างกันก็มีเป้าหมาย กระบวนการทำงาน รวมถึงลำดับความสำคัญที่ไม่เหมือนกัน นอกจากนี้บริษัทที่เราเข้าไปทำงานก็จะส่งผลต่อรูปแบบของงานที่ได้ทำ
ผมเชื่อว่าในปัจจุบันเราสามารถจำแนกทีมหรือแผนกที่ Data Analyst อยู่แบ่งออกเป็น 3 ประเภทได้แก่ หนึ่ง ทีมที่อยู่ภายใต้แผนก engineer มีรูปแบบในการเติบโตเพื่อจะทำงานที่เกี่ยวข้องกับ data science โดยตรง แม้จะเป็น Data Analyst แต่งานจะมีความคล้ายคลึงกับ Data Scientist มากกว่า สอง การเป็นทีมสนับสนุนในการดึงข้อมูลให้กับทีมธุรกิจหรือทีมผู้บริหาร ซึ่งรวมทั้งการดึงข้อมูลและการสร้าง dashboard เพื่อให้ทีมธุรกิจเห็นข้อมูลผ่านกราฟ แผนภูมิต่างๆ ทีมดังกล่าวจะเป็น Business Intelligent team(BI) ของส่วนกลาง หรือ Data team ก็ได้ สาม ทีมย่อยที่อยู่ภายในทีมธุรกิจได้แก่ Marketing, Sales, Call center, Operation, Strategy, หรือแม้แต่แผนก Product องค์กรในลักษณะนี้จะคล้ายกับทีมธุรกิจมากกว่าทีมอื่นๆ อาจมีโอกาสได้ทำข้อมูลออกมาในรูปแบบของ report, excel, slide ในบางกิจการอาจมีการวางโครงสร้างให้เราสามารถขยับไปทำตำแหน่งของฝั่งธุรกิจในทีมเดียวกันได้ด้วย ส่วน Data Scientist ผมมองว่าควรจะสังกัดอยู่ภายใต้ทีมประเภทที่หนึ่งเท่านั้น ด้วยเหตุผลที่ว่าวิธีการทำงานล้อไปกับทางแผนก engineer หรือทีม tech มากกว่า
ลักษณะของทีมทั้งสามประเภทนี้แยกขาดจากกันซึ่งหมายความว่าในบริษัทหนึ่งอาจมีทั้งสามทีมหรือไม่มีเลยก็ได้ ยิ่งไปกว่านั้นในบางบริษัทอาจจะรวมขอบเขตของสิ่งที่ต้องมาทำรวมไว้ในทีมเดียวกันซึ่งทำให้สิ่งที่ทีมต้องดูแลมีมากยิ่งขึ้น ผมทึกทักเอาเองว่าอย่างน้อยบริษัทที่ใช้ข้อมูลปริมาณมหาศาลน่าจะมีทีมประเภทแรกอยู่เพราะว่าในหลายกรณีทีมประเภทอาจรวมทีมที่ทำงานเกี่ยวกับ Data ไว้ด้วยกันทั้งหมด Data Analyst, Data Scientist, Machine Learning Engineer, BI Analyst, Data Engineer, Data Analytics Engineer, BI developer, Data Visualization หรือแล้วแต่ใช้ชื่อตำแหน่งว่าอะไรก็ตาม
ในบทความนี้ผมพยายามแยกโจทย์(problem space) และงาน(task) ออกจากกัน ผมเห็นว่าไม่ว่าจะทำงานที่ไหน ถ้าทำสิ่งเดียวกันก็ควรถูกจัดไว้ว่าเป็นงานอย่างเดียวกันโดยไม่จำเป็นต้องแยกชื่อตำแหน่งหรือโจทย์ ตัวอย่างเช่น ถ้าหากผมทำงานในธนาคารแล้ว manager ให้ผมสร้าง dashboard เพื่อติดตาม default rate(อัตราการผิดนัดชำระหนี้) ของสินเชื่อส่วนบุคคลว่ามีการเปลี่ยนแปลงไปอย่างไร ก็ไม่แตกต่างไปจากการที่ผมต้องสร้าง dashboard เพื่อติดตามว่า churn rate(อัตราการเลิกใช้ผลิตภัณฑ์หรือบริการ) ของแอพเปลี่ยนไปอย่างไร ไม่ว่าจะทำงานในสายธนาคารหรือสาย tech การสร้าง dashboard ก็คือการสร้างกราฟเหมือนเดิม มีตัวแปรที่เราสนใจที่ต้องติดตามเหมือนกัน ต้องใช้ line chart(กราฟเส้น) เหมือนกัน ต้องเขียน query ดึงข้อมูลเหมือนกัน แล้วก็มี business stakeholder เหมือนกัน ดังนั้นในบทความนี้เราจะมองกันที่งานหรือกิจกรรมมากกว่าที่จะสนใจว่าโจทย์เป็นอย่างไร หรือใช้เทคนิคอะไรในการแก้โจทย์
Team 1: Data Science Team/Central Analytics Team
ในทีมประเภทแรกเป็นทีมที่อยู่ภายในแผนก engineer หรือ tech ซึ่งอาจจะชื่อทีมว่า Data Science, Analytics, Analytics & Insight, Advanced Analytics ฯลฯ โดยพื้นฐานทีมนี้สนับสนุนทั้ง business, engineer, product ผมคาดว่าทีมดังกล่าวสามารถบริหารได้ 2 แบบคือ หนึ่ง บริหารทีมเหมือนกับทีม engineer อาจจะใช้ระบบ Scrum framework ซึ่งรวม daily stand-up(อัพเดทตอนเช้าว่างานมีความคืบหน้าหรือติดขัดอะไร) sprint planning(วางแพลนการทำงานในหนึ่งรอบ) เป็นต้น หรืออาจใช้ระบบแบบอื่นที่แผนก engineer ใช้กันเช่น Kanban การทำงานในทีมนี้ผมคิดว่าค่อนข้างคล้ายกับการทำงานในแผนก engineer ในบางองค์กรเราอาจได้ไปอยู่ในทีมเฉพาะ(scrum)เพื่อสนับสนุน product หนึ่งตัว(หรือหลายตัว)เลยก็ได้ ในทีมนี้งานแต่ละชิ้นที่เราได้รับจะมีขอบเขตที่มีความชัดเจนมากกว่าการทำงานกับทีมธุรกิจ manager ของเราสามารถช่วยให้เราทำงานได้สะดวกสบายมากยิ่งขึ้น(ไม่มีการทักมาของานเพิ่มระหว่างทาง) ในประเภทการบริหารงานแบบที่สองจะค่อนข้างตกไปในงานรูปแบบของ Data Scientist มากกว่าซึ่งจะอธิบายเพิ่มเติมภายหลัง
การทำงานให้กับทีม Engineer ข้อดีก็คือเนื้องานจะมีความชัดเจนมากกว่า (อาจ)มีงาน analysis น้อยกว่าหรือแทบไม่มีเลยถ้าหากเราไม่ต้องพยายามในการอธิบาย หรือขายงานของเรา หรือวัดผลงานอย่างละเอียด งานจะมีความเป็น Modeling, ML มากกว่า อาจจะต้องทำ ETL(เขียน query สร้าง table ให้รันอัตโนมัติ) อาจจะได้จับงานที่เกี่ยวข้องกับ deployment(การเอาโมเดลที่ทำเสร็จแล้วไปใช้จริงบนแอพ/เว็บ) ด้วยถ้าหากบริษัทไม่ได้มี Machine Learning Engineer(MLE) คอยช่วย ผมเชื่อว่ามีแนวโน้มค่อนข้างสูงที่จะได้ทำแบบ end-to-end ตั้งแต่ดึงข้อมูลลงมาเอง research เอง ทดลองทำ prototype เอง วัดผลเอง ประเมินผลเอง คุยกับ stakeholder เองไปจนถึงขั้นตอนสุดท้ายคือเอางานขึ้นไป deploy ด้วยตัวเอง ใครที่พอคุ้นเคยกับงานของ Data Scientist ก็จะพอเห็นภาพว่านี่มันเหมือนกันเลยชัดๆ! ซึ่งกรณีนี้จะเกิดในเคสที่เอา Data Analyst มาเป็นตำแหน่งเริ่มต้นของสายงาน Data Scientist นั่นเอง
การทำงานกับทีม Product จะขึ้นกับ Product Manager ว่ามีขอบเขตการทำงานถึงส่วนไหน ถ้า Product Manager วาง road map เองแล้วก็ประสานกับทีม tech เองก็จะมีโจทย์หรือโปรเจคซึ่งเป็นไปเพื่อพัฒนา product ให้ดียิ่งขึ้นผ่านการทำโมเดลต่างๆ เช่น การทำนายว่าใครจะเลิกใช้ product นี้เพื่อหาทางแก้ไข หรือการทำ analysis เช่น หาสาเหตุที่ทำให้เขาเลิกใช้ product ดังกล่าว หรือช่วยคำนวนสิ่งที่เขาสนใจที่จะใช้เป็นตัวชี้วัด หรือต้องการให้เราสนับสนุนข้อมูลเพื่อประกอบการตัดสินใจหรือทำการวิเคราะห์ข้อมูลหลังจากทำ experiment จะเห็นได้ว่าโจทย์ที่ Product Manager ต้องการแก้เป็นส่วนผสมระหว่าง Modeling, Analysis ดังนั้นการทำงานกับ Product Manager เรามีโอกาสได้ทำทั้งสองอย่าง(ไม่ว่าคุณจะตำแหน่ง Data Analyst/Data Scientist ก็ตาม)
Team 2: Business Intelligence Team/Data Team
โครงสร้างทีมประเภทสองเป็นทีมของส่วนกลางอยู่ภายใต้แผนก engineer หรือแผนก data ก็ได้ ทีมนี้มีจุดประสงค์เพื่อเรียบเรียงและดูแล source of truth หรือข้อมูลที่สำคัญและถูกต้อง ในฐานข้อมูลของบริษัทจะมีข้อมูลที่สำคัญเช่น ข้อมูลที่เกี่ยวข้องกับข้อมูลส่วนบุคคลของลูกค้าจำพวกบัตรเครดิต รายละเอียดการใช้จ่าย หรือข้อมูลการทำธุรกรรมของลูกค้า อีกสิ่งที่ทีมนี้ทำคือการสนับสนุนทีมธุรกิจซึ่งไม่สามารถดึงข้อมูลออกมาจากระบบเองได้ หรือช่วยให้พวกเขาสามารถทำการตัดสินใจโดยมีพื้นฐานมาจากข้อมูล(Data Driven Decision-Making) ทีมนี้จะทำการสนับสนุนทั้งแบบทางตรงและทางอ้อม สำหรับงานที่เกี่ยวข้องโดยตรง เช่น ดึงข้อมูลออกมาเป็น excel file หรือ report หรือสร้าง dashboard เพื่อให้ทีมธุรกิจสามารถติดตามตัวเลขที่พวกเขาให้ความสำคัญ อีกตัวอย่างหนึ่งคือการนำข้อมูลออกมาวิเคราะห์ทั้งแบบที่ทีมธุรกิจชอบทำ(pivot table, time series) อาจรวมไปถึงการวิเคราะห์แบบอื่นด้วยที่เกี่ยวข้องกับโจทย์ของทีมที่เราเข้าไปช่วย เราอาจจับกลุ่มงานเหล่านี้เรียกรวมกันว่า Adhoc Analysis ส่วนทางอ้อมได้แก่การสร้าง data table หรือตารางที่เก็บข้อมูลซึ่งรวบรวมและประมวลผลข้อมูลให้อยู่ในรูปแบบที่นำไปใช้ต่อได้ การสนับสนุนทั้งแบบทางตรงและทางอ้อมอาจจะทำโดยคนคนเดียวกันหรือแยกคนทำก็ได้ การที่ทีมดังกล่าวเป็นทีมของส่วนกลางทำให้สามารถมีการจัดแบ่งทีมย่อยภายในเพื่อดูแลข้อมูลคนละแหล่ง หรือคนละธุรกิจได้ การแบ่งดังกล่าวก็ขึ้นอยู่กับองค์กรหรือหัวหน้าทีมที่จัดแบ่ง ในโครงสร้างแบบนี้นั้นทีมสามารถบริหารได้สองลักษณะคือ หนึ่งการบริหารแบบเดียวกับทีม engineer เหมือนกับโครงสร้างทีมประเภทแรก หรือบริหารแบบ Kanban(ticket based)[4] ในการบริหารแบบหลังนั้นเกิดจากการที่บริษัทต้องการให้ทีมมีระบบในการช่วยทีมธุรกิจหรือทีม engineer ดังนั้นทีมจึงจำเป็นต้องมีช่องทางในการรับงาน แล้วก็วางแผนในการบริหารจัดการเพิ่มเติมจากนั้นก็รวบรวมงานมาไว้ในที่เดียวกันเพื่อแบ่งกันทำต่อไป การรับงานแบบดังกล่าวยังทำให้สะดวกต่อการหยิบมาทำหรือแก้ไขได้ตามความเร่งด่วนของงาน
Team 3: Internal Analytics Team
ทีมประเภทสุดท้ายเป็นทีมที่สังกัดอยู่ภายใต้ทีมธุรกิจเช่น ทีม analytics ของแผนก Performance Marketing, Sales, Call Center, Product ฯลฯ ทีมในลักษณะนี้ผมคาดการณ์ว่าเกิดขึ้นเนื่องจากปัญหาที่ทีมประเภทแรกหรือสองมีจำนวนคนไม่เพียงพอที่จะช่วยให้ทีมธุรกิจทำงานได้สะดวกเพียงพอ หรืออาจมีความจำเป็นต้องมี analyst ที่ทำงานคล้ายกับ business analyst ประจำอยู่ในทีม ทีมนี้มีจุดประสงค์เพื่อเป็นทีมสนับสนุนให้กับทีม business ที่เราไปสังกัดอยู่ไม่ว่าแผนกนั้นจะทำอะไรก็ตาม รูปแบบก็ไม่แตกต่างจากทีมอื่นมากนักเพียงแต่คนที่ส่งงานมาให้เราทำอยู่ภายในทีมเดียวกัน ผมเชื่อว่าส่วนใหญ่แผนกในรูปแบบนี้จะมีทีมแยกขาดระหว่างทีม analytics แล้วก็ทีมธุรกิจ ยกเว้นในกรณีพิเศษคือรวมกันไปเลย หมายความว่า businss analyst คนนั้นสามารถทำงานฝั่ง data ได้เองด้วยแล้วก็ยังทำงานปกติที่ทีมนั้นต้องทำได้ด้วย
คำถามที่น่าสนใจคือถ้าอย่างนั้นทีมนี้ต่างกับทีมสองประเภทก่อนหน้าอย่างไรนอกเหนือไปจากแค่ว่าสังกัดแตกต่างกัน? หนึ่ง คือสิทธิ์ในการเข้าถึงข้อมูลอาจจะไม่เท่ากัน เผื่อใครจะยังไม่ทราบตอนนี้กฎหมาย PDPA เริ่มมีการใช้งานแล้วเพราะฉะนั้นบริษัทใดก็ตามต้องให้ความสำคัญกับ Data Security นั่นอาจเป็นสาเหตุหนึ่งที่ทำให้การเข้าถึงข้อมูลได้มีน้อยลง สอง เนื้องานลึกกว่า เนื่องจากเราต้องประกบอยู่กับทีมเดิมตลอดเวลาทำให้มีโอกาสได้เห็นความก้าวหน้าของโปรเจคไปด้วย(หรือแม้แต่เห็นตอนจบโปรเจค) สาม manager ของทีม ผมต้องขออธิบายก่อนว่าผมคิดว่าคนที่อยากทำงานสาย data analytics, data science จริงๆ มีโอกาสค่อนข้างน้อยที่จะไปอยู่ใต้ทีมธุรกิจเพราะฉะนั้นผมจึงคาดเดาเอาเองว่า manager ของทีมส่วนใหญ่อาจจะมาจากสายอื่นแทนเช่น ทำงานในสายธนาคารแล้วย้ายสายข้ามมา ทำงานในทีม tech แล้วมาทำ อาจจะมาจากฝั่ง consult หรือแม้กระทั่งคนที่จบ MBA ดังนั้นงาน analytics ที่จะได้จับโดยมากจะไม่ได้เน้นที่ความสลับซับซ้อนสูงที่ใช้เวลาทำนานกว่าจะเห็นผลแต่จะเป็นไปเพื่อธุรกิจมากกว่าที่จะเอียงไปทางด้าน data science แล้วก็เนื้องานอาจมีความเป็น operation, routine มากกว่า สี่ วิธีการทำงานจะอ้างอิงไปตามทีมธุรกิจ มากยิ่งขึ้นเช่น มี brainstorm session ต้องทำสไลด์นำเสนองาน หรือวิธีการเพื่อช่วยแก้ไขปัญหา งานแบบนี้มีน้อยหรือไม่ค่อยสำคัญถ้าหากเป็นทีมประเภทอื่น ห้า deadline ของงานอาจจะดุเดือดยิ่งกว่าทีมที่เหลือ การที่เราเป็นย่อยในทีมธุรกิจนั่นหมายความว่าบางครั้งอาจจะมีงาน adhoc โผล่มาจากไหนก็ไม่รู้แล้วก็จำเป็นต้องรีบทำให้เสร็จซึ่งนี่เป็นวิธีการทำงานตามปกติของทีมธุรกิจ
แล้ว Data Scientist แตกต่างจาก Data Analyst ตรงไหน?
ผมต้องขอเกริ่นก่อนว่าตัวผมเองก็ไม่ได้มีประสบการณ์การทำงานหลายมากพอที่จะบอกได้โดยละเอียด ในความคิดเห็นของผมมองว่า Data Scientist จะจัดอยู่ภายใต้แผนก engineer หรือไม่ก็แผนก data โดยตรง ดังนั้น Data Scientist จะทำงานอยู่ในทีมประเภทที่แรกซึ่งมีรายละเอียดของวิธีการทำงานหรือลักษณะการทำงานเหมือนกับที่ผมระบุไว้ การบริหารทีมอีกรูปแบบหนึ่งที่ไม่ได้บริหารเหมือนทีม engineer เนื่องจากเนื้องานความเป็น research มากกว่า ในบางองค์กรอาจเรียกตำแหน่งนี้ว่า Research Scientist หรือไม่ก็เรียก Data Scientist เหมือนเดิม หมายความว่าทีมอาจจะมี scope งานที่กว้างกว่ามีอิสระมากกว่าในการเลือกปัญหาที่จะเข้าไปแก้ไขได้ แต่ในขณะเดียวกันก็บริหารทีมบริหารโปรเจคยากกว่าด้วย เนื่องจากการบริหาร research team ก็ไม่ต่างอะไรกับการบริหารทีมนักวิจัยที่เนื้องานแตกต่างกัน จุดที่ท้าทายที่สุดสำหรับผมก็คือการบริหารให้เกิดผลลัพธ์ออกมาได้ในกรอบเวลาที่กำหนดเพราะงาน research วางแผนงานให้ชัดเจนได้ยากว่าจะทำอะไรให้เสร็จตอนไหน
ทุกคนอาจเกิดคำถามต่อมาว่าแล้วถ้างั้น Data Scientist ดูไปก็ไม่แตกต่างจาก Data Analyst เลยรึเปล่า ถ้าหากทั้งสองตำแหน่งอยู่ภายในทีมประเภทแรกเหมือนกันบริหารด้วยวิธีการเดียวกัน? ผมเห็นว่ามีคนอธิบายพวกเครื่องมือต่างๆ และองค์ความรู้เยอะแล้ว(อ้างอิงจาก Reference section) ดังนั้นคิดว่าผมจะขอลองอธิบายมุมมองอื่นให้ได้เห็นเพิ่มเติม ความแตกต่างที่อาจจะเกิดขึ้นได้ก็คือ หนึ่ง ระยะเวลาในการทำงานของ Data Analyst ต่อหนึ่งงานจะค่อนข้างสั้น นั่นหมายความว่าเราทำเร็วจบเร็วกว่า Data Scientist ที่ต้องใช้เวลาหลัก 2–3 เดือน(เป็นอย่างเร็ว!) อาจเหลือเพียงหลักสัปดาห์อาจจะหนึ่งหรือสองขึ้นกับความซับซ้อนของ analysis และมี data พร้อมใช้แค่ไหน ที่ทำเร็วกว่าไม่ใช่ว่าเก่งกว่า แต่เป็นเพราะขอบเขตของงานแคบกว่า ความเร่งของงานมากกว่า ในกรณีที่เป็นแค่การดึงข้อมูล ตรวจสอบข้อมูลอาจจะต้องทำเสร็จในเวลาไม่กี่ชั่วโมง สอง สำหรับ Data Analyst แล้วงานส่วนที่เกี่ยวข้องกับ engineer หรือ software development จะมีไม่มาก หมายความว่าปริมาณของ best practice ที่ต้องทำให้ได้ตามมาตรฐานของทีม Tech ก็จะน้อยลงตามเช่น อาจจะไม่ต้อง refactor code ให้สะอาดตามมาตรฐาน อาจจะไม่ต้องสร้าง python sever หรือ deploy งาน หรือแม้แต่เอางานขึ้น github/gitlab การลดปริมาณมาตรฐานตรงนี้ลงสัมพันธ์โดยตรงกับความเร็วของงานจากข้อแรก แต่แลกด้วยการที่งานทำซ้ำได้ยาก แบ่งให้คนอื่นทำยาก แล้วก็ตรวจสอบยาก สาม Data Analyst มักจะไม่จำเป็นต้องใช้เครื่องมือที่มีความสลับซับซ้อน ส่วนมากอาจใช้เครื่องมือเดิมในการช่วยแก้ไขโจทย์ แต่ก็ไม่ได้หมายความว่ามันง่าย แค่ง่ายกว่า ตัวอย่างเช่น ถ้าหากทีมต้องทำ dashboard อยู่เสมอก็อาจจะใช้แค่ Power BI, Tableau หรือเขียนแค่ SQL ในการทำงานไม่จำเป็นต้องใช้ python สี่ โจทย์ของ Data Scientist นั้นกว้างกว่าในเชิงองค์ความรู้ เนื่องจากในปัจจุบันสาขานี้เติบโตขึ้นอย่างมากทำให้เกิดการรวมเอา Machine Learning หรือ AI จากหลายด้านมารวมกันแต่ในขณะกลับกันทีมส่วนใหญ่ในประเทศนี้(ผมคาดเดาเอาเอง) น่าจะเป็นทีมกลางที่ไม่มีการแยกความเชี่ยวชาญเฉพาะด้านทำให้ DS หนึ่งคนอาจมีโอกาสได้ทำตั้งแต่ NLP, Vision, DL, Graph ML, Simulation, Optimization หรือเทคนิคอื่น ห้า การทำงานของ Data Scientist อาจจะเป็นแบบโปรเจคเดี่ยวหรือโปรเจคกลุ่มซึ่งต่างจาก Data Analyst ที่ต้องฉายเดี่ยวตลอด เนื่องจากบางงานมีขนาดค่อนข้างใหญ่ถ้าหากต้องการให้งานมีความคืบหน้าและเสร็จเร็วในเวลาไม่กี่เดือนก็จำเป็นต้องเอา Data Scientist หลายคนมารุมกันช่วยกันแก้โจทย์ ถึงแม้ว่าตามปกติสายงานนี้จะต้องทำงานแบบลุยเดี่ยวก็ตาม หก งานของ Data Analyst อาจจะเป็นงานที่ routine มากกว่า มีเนื้องานเป็นงาน operation มากกว่างาน Data Scientist เพราะโดยพื้นฐานทีมที่ Data Analyst สังกัดไม่ได้มี analytical product ของตนเอง สิ่งที่มีก็คือ Data table, Dashboard เป็นหลัก นั่นหมายความว่าทีมที่ DA สังกัดเป็น service team ตรงกับจุดประสงค์คือการสนับสนุนทีมธุรกิจ หรือไม่ก็เป็นทีมปฏิบัติการ(operation team) ที่ต้องมีความสามารถในการทำงานกับข้อมูล
“ต่างจากงานในทีมธุรกิจหรือทีม tech ที่ยิ่งลงแรงมากยิ่งได้ผลออกมามาก”
อีกประเด็นที่สำคัญไม่แพ้กันคือถ้าใครเป็นคนชอบทำงานแล้วรู้สึกว่างานเสร็จงานจบ แน่นอนว่าอาจจะไม่ชอบงาน Data Scientist เท่าไหร่ ผมเคยมีโอกาสคุยกับเพื่อนที่จบสถาปัตย์แล้วย้ายสายมาเป็น software developer เพื่อนบอกว่างาน design เป็น “งานที่ไม่จบ” คำว่าไม่จบหมายถึงว่าเราไม่รู้ขอบเขตว่าจบลงที่ตรงไหน ผมไม่เคยออกแบบบ้านมาก่อนแต่คิดว่าคำว่าสวยงามเพียงพอของคนแต่ละคนคงจะไม่เท่ากัน นั่นทำให้การออกแบบที่สวยเพียงพอ มีการใช้งานได้ดีพอของแต่ละคนไม่เหมือนกัน บางคนขอแค่มีห้องนอนก็เพียงพอ บางคนอาจจะต้องการถึงขั้น smart home บางคนต้องการวัสดุจากต่างประเทศ หรือเครื่องเรือนที่งดงาม ในงานของ Data Scientist เองก็เช่นกันมันเป็นงานที่ไม่มีจบ ไม่มีขอบเขตที่แน่ชัดทำให้บริหารจัดการได้ยาก คนที่ชอบงานที่มีกรอบที่แน่นอน งานจากทีมประเภทที่สองและสาม หรืองานในสายธุรกิจหรือสาย tech อาจจะเหมาะกับคุณมากกว่า ขอให้ผมได้ยกตัวอย่างละเอียดขึ้นเพื่อความกระจ่าง สมมติว่าผมต้องการทำนายว่าลูกค้าคนหนึ่งมีโอกาสมากน้อยขนาดไหนที่จะเลิกใช้งานบริการของเรา ขอบเขตของมันเป็นกรอบที่ใหญ่มากตั้งแต่ว่าจะใช้ข้อมูลส่วนไหนบ้าง ใช้ข้อมูลจำนวนกี่วัน ใช้เครื่องมือหรืออุปกรณ์อะไรในการช่วยประมวลผล ต้องทดสอบมากน้อยขนาดไหนถึงจะมั่นใจได้ว่าดีพอ ถึงแม้ว่าจะพยายามบริหารโปรเจคโดยอยู่บนพื้นฐานของความเป็นจริง มีกรอบเวลาและตัวเลขเป้าหมายเป็นตัวกำหนดเช่น ต้องการความแม่นยำ 95% แต่ในความเป็นจริง การลงทุนลงแรงกลับไม่ได้ส่งผลโดยตรงที่จะทำให้ความแม่นยำเพิ่มขึ้น ซึ่งต่างจากงานในทีมธุรกิจหรือทีม tech ที่ยิ่งลงแรงมากยิ่งได้ผลออกมามาก นี่จึงเป็นความแตกต่างที่เห็นได้ชัดเจนของงาน Data Scientist
Business-Oriented or Engineering-Oriented
ภาพที่สองด้านบนผมได้ไอเดียมาจาก manager ท่านหนึ่งที่ผมเคยทำงานด้วย จากภาพด้านบนผมได้แบ่งทีมทั้งสามชนิดแยกไว้ในกล่องทางด้านซ้าย ตรงกลาง และทางขวา จากทางด้านซ้ายเป็นทีมย่อยภายในทีมธุรกิจตรงกับทีมประเภทที่สาม ตรงกลางคือทีมประเภทสองที่เป็นทีม Business Intelligent และในทีมธุรกิจอาจมีทีมประเภทที่สามรวมอยู่ด้วย ส่วนทีมทางขวาคือทีม Data Science วิธีในการแบ่งดังกล่าวเป็นการแยกทีมหน้าบ้านที่ติดต่อหรือมีปฏิสัมพันธ์โดยตรงกับลูกค้า ออกจากทีมหลังบ้านซึ่งงานก็อาจจะส่งผลโดยอ้อมต่อลูกค้าแต่ด้วยเป้าหมายที่แตกต่างกันคือพัฒนาระบบหรือดูแลระบบ ส่วนทีมตรงกลางเป็นทีมที่เกี่ยวข้องกับทั้งหน้าบ้านและหลังบ้าน จากมุมมองข้างต้นแสดงให้เราเห็นว่าความเกี่ยวข้องกับทีมธุรกิจไม่เท่ากัน ลักษณะของปฏิสัมพันธ์ระหว่างทีมหรือโปรเจคเองก็แตกต่างกัน ทีมหลังบ้านเกี่ยวข้องกับทีมตรงกลางมากกว่าทีมหน้าบ้าน ในทางกลับกันทีมหน้าบ้านเองก็คุยหรือประสานงานกับทีมตรงกลางมากกว่าทีมหลังบ้าน
สิ่งนี้สะท้อนว่า Domain Knowledge หรืออาจเรียกว่ามุมมองเกี่ยวกับธุรกิจและความเข้าใจเกี่ยวกับตัวธุรกิจไม่เท่ากัน คนที่ชอบทำงานที่เกี่ยวข้องกับธุรกิจมากกว่าควรที่จะเลือกทำงานที่เกี่ยวข้องกับหน้าบ้านมากกว่าหลังบ้าน งานที่เกี่ยวข้องกับธุรกิจไม่ได้รวมเฉพาะงานในแนวทางของการสนับสนุนธุรกิจเพียงอย่างเดียวแต่รวมถึงงานอื่นๆ ด้วยที่จะอธิบายเพิ่มเติมในส่วนถัดไป ยิ่งถ้าหากใครที่อยากจะย้ายเข้าไปในสายธุรกิจในภายหลังการทำงานกับทีมธุรกิจมากกว่าก็ถือเป็นโอกาสที่ดีกว่า ในทางตรงกันข้ามคนที่ชอบทำงานแบบ engineer ก็ควรทำงานอยู่หลังบ้านมากกว่าหน้าบ้าน สำหรับทีมที่อยู่ตรงกลางถ้าหากเป็นทีมย่อยในทีมธุรกิจก็จะอ้างอิงโครงสร้างในแบบสุดท้าย ซึ่งก็จะแตกต่างจากทีม Business Intelligence ที่เป็นทีมแยกต่างหาก
นอกเหนือไปจากงานอีกเรื่องแตกต่างกันคือ career track หรือแนวทางการเติบโตในการทำงาน ต้องบอกก่อนว่าผมเองก็ไม่ได้อยู่มาครบทีมทุกรูปแบบตามที่ผมได้เขียนอธิบายไว้ แต่ถ้าหากอ้างอิงจากภาพเราก็จะโตไปตามโครงสร้างของทีมของเรา หมายความว่าถ้าหากเราทำงานในทีม Data Science ถึงแม้ว่าตำแหน่งเราจะเป็น Data Analyst แต่เราก็คือทำงานเพื่อจะเติบโตขึ้นไปเป็น Data Scientist และถ้าหากเราทำงานในฝั่งของทีมธุรกิจ เราก็จะโตไปเป็นทำงานในทีมธุรกิจนั้น กรณีที่อันตรายคือการทำงานภายในทีมธุรกิจโดยที่ผู้บริหารไม่ได้มองสายการเติบโตของเราเอาไว้ นั่นหมายถึงว่าเราไม่มีการเติบโตในสายงานอาจจะเป็นการทำงานเหมือนเดิม จากความเข้าใจดังกล่าวคงจะตรงไปตรงมาที่จะบอกว่าถ้าเราอยากโตไปทำตำแหน่งอะไร เราก็ควรพาตัวเองไปอยู่บริบทหรือสภาพแวดล้อมแบบนั้น
งานที่เกี่ยวข้องกับทีมธุรกิจ
ผมไม่ได้พูดถึงงานที่เกี่ยวข้องกับทีมธุรกิจมากนักเพราะไม่ว่าจะเป็นโครงสร้างแบบไหนก็มีโอกาสได้จับงานที่เกี่ยวกับทีมธุรกิจทั้งนั้น ในที่นี้คำว่าทีมธุรกิจของผมหมายความรวมถึงทีมที่อยู่หน้าบ้านหรือตรงกลางทั้งหมดไม่จำเพาะแค่ทีม Marketing, Business Development, Strategic Partnership ฯลฯ ในส่วนนี้ผมอยากจะลงรายละเอียดถึงงานที่เราได้ทำและที่เราทำได้ งานที่เกิดขึ้นด้านล่างส่วนมากเป็นงานที่อาศัย Data Analyst เป็นคนทำแต่ในกรณีที่งานค่อนข้างซับซ้อนหรือบางบริษัทอาจแบ่งรูปแบบของงานแตกต่างออกไป ก็อาจจะให้ Data Scientist เป็นคนทำแทน
ขอเริ่มจากงานที่ค่อนข้างพื้นฐานอย่างการดึงข้อมูล ประมวลผลข้อมูล และเก็บข้อมูล ดังนั้นก่อนจะนำข้อมูลมาใช้ต้องมีข้อมูลที่ใช้ได้ก่อน ตัวอย่างเช่น ทีม marketing ต้องการประเมินผลอีเมลล์แคมเปญแยกลูกค้าที่มียอดใช้จ่ายที่แตกต่างกันในช่วง 6 เดือนที่ผ่านมาโดยพิจารณาเป็นรายเดือนแล้วก็ต้องการคำนวนอัตราการเปลี่ยนแปลงสัปดาห์ต่อสัปดาห์ แล้วแยกแบ่งข้อมูลลูกค้าตามช่วงการใช้จ่าย จากรายละเอียดนี้เราจะเห็นว่าเราต้องดึงข้อมูลออกมา ประมวลผลด้วยการคำนวนค่าที่สนใจด้วยวิธีการอย่างค่าเฉลี่ย(ซึ่งตกไปในหมวด Descriptive Statistics) แล้วก็อาจจะนำเสนอข้อมูลออกมาในรูปแบบที่ใช้งานได้ง่ายเช่น excel เป็นต้น ทุกคนอาจจะคิดว่างานมันก็ดูง่ายนิดเดียวแต่ในความเป็นจริงตอนเขียน SQL เราจะพบกับการจำแนกแยกแยะข้อมูลที่มีตัวแปรแตกต่างกัน การพิจารณากลุ่มข้อมูลที่ไม่เหมือนกันนำไปสู่ตัวเลขที่ไม่ตรงกันเช่น คำว่าลูกค้าควรนับลูกค้าทุกคนที่เคยใช้ผลิตภัณฑ์ของเราหรือนับเฉพาะลูกค้าที่ใช้สม่ำเสมอ ในองค์กรจะเราสามารถอ้างอิงได้จาก Business Intelligence team หรือคือทีมประเภทที่สอง ปกติถ้าหากเราไม่รู้จักข้อมูลก็จะต้องถามจากทีมนี้เพื่อให้ได้วิธีการคำนวนที่ถูกต้องก่อนจะไปใช้จริง หรือถ้าหากทีมที่เราทำงานด้วยมีคำอธิบายมาให้เราก็ต้องเขียนขึ้นมาเอง ความซับซ้อนที่สองคือเรื่องปริมาณของข้อมูล ข้อมูล 6 เดือนนั้นอาจจะไม่สามาถใช้ SQL ปกติที่เราใช้กันได้ดังนั้นก็ต้องย้ายไป spark sql หรือวิธีอื่นเพื่อประมวลผลข้อมูลขนาดใหญ่แทน นอกจากนี้ความซับซ้อนอื่นก็ยังมีอีกเช่น ไม่มีข้อมูล มีข้อมูลตกหล่น ข้อมูลไม่ตรงกัน วันที่ไม่ตรงกัน ไม่มีวิธีในการประกอบข้อมูลที่ต้องการ(no mapper) ข้อมูลตั้งต้นคำนวนมาผิด ฯลฯ สมมติว่าเราทำงานจนเสร็จได้ผลลัพธ์ออกมาเป็น excel file เรียบร้อย เราอาจจะต้องนำ sql ขึ้นไปรันเป็นงานที่รันทุกวัน ETL(เขียน query สร้าง table ให้รันอัตโนมัติ) แล้วเขียนข้อมูลลงไปใน data table
การสร้าง report, dashboard ก็จะอ้างอิงจากงานพื้นฐานด้านบน ทุกคนสามารถจินตนาการตามผมได้ว่าเมื่อเราทำโปรเจคอะไรสักอย่าง ก็จะมี metric หรือตัวชี้วัดที่เราต้องการติดตาม manager ในแต่ละระดับก็จำเป็นต้องตามติดตัวเลขดังกล่าวผ่าน report หรือ dashboard ที่เราสร้าง การสร้างสิ่งเหล่านี้ไม่ได้มีความซับซ้อนในเชิงเทคนิคแต่วุ่นวายในเชิงการคำนวนให้ถูกต้องตามสูตรและกลุ่มข้อมูลที่ต้องการ งานเหล่านี้นำมาสู่อีกงานหนึ่งที่ทุกคนน่าจะมีโอกาสได้เจอคือการตรวจสอบคุณภาพ(QA; Quality Assurance) เพื่อดูว่าสิ่งที่เราตั้งใจให้มันเป็นนั้นถูกต้องตามนั้นหรือไม่ ตัวอย่างที่ง่ายที่สุดก็คือ ตัวเลขยอดขายประจำวันนั้นตกลง สิ่งที่ทีมธุรกิจมักจะสนใจคือสาเหตุของการเกิด เพื่อที่จะได้เข้ามาแก้ไขปัญหา หรือถ้าหากข้อมูลมันดูผิดเพี้ยนไปจากเดิม เช่นจำนวนออร์เดอร์มากขึ้นหรือน้อยลงก็ตาม นั่นก็สามารถเป็นที่มาของงานในลักษณะการตรวจสอบคุณภาพได้ ซึ่งการตรวจสอบต้องอาศัยการย้อนทวนดูที่มาที่ไปของข้อมูลว่ากลุ่มไหนมีการเปลี่ยนแปลงอย่างไร หรือการตรวจสอบว่าทำไมข้อมูลที่แสดงผลจากคนละแหล่งมีข้อมูลที่ไม่ตรงกัน
การนำข้อมูลมาประกอบการตัดสินใจที่มากกว่าแค่การติดตามดูตัวชี้วัดเป็นการสร้างให้เกิด data-driven culture เรื่องเริ่มต้นจากทีมธุรกิจอาจมีโครงการ ไอเดีย โปรแกรม หรือแม้แต่ปล่อยผลิตภัณฑ์หรือบริการตัวใหม่ พวกเขาต้องการคำแนะนำหรือช่วยออกแบบการคำนวนที่สมเหตุสมผลเช่น ควรจะประมาณการจำนวนลูกค้าที่เข้ามาใช้งานอย่างไร จะเป็นไปได้มั้ยที่เราจะขยายให้ทำได้ดียิ่งขึ้น หรือพิจารณาว่าการเพิ่มโครงการ หรือโปรแกรมใหม่ เพิ่มรายได้ต่อหัวได้กี่บาท คำถามเหล่านี้ผมเรียกรวมกันว่า Analytical question ส่วนหนึ่งเพราะมันไม่สามารถนำข้อมูลมาคำนวนและตอบได้เหมือนกับข้อด้านบน อาจจะต้องทำการทดลอง (Online controlled Experiment, หรือ A/B testing) แล้วต้องมาแปลผล ในกรณีที่ซับซ้อนในเชิงข้อมูลมากเช่นต้องดึงข้อมูลจากหลายแหล่งมาประกอบร่างเอาเพื่อให้เห็นภาพที่มีความชัดเจนก็เรียกได้ว่าเป็นงานวิเคราะห์รูปแบบหนึ่ง ในด้านที่ต้องอาศัยความรู้ในเชิง Statistics, Probability มากขึ้น อย่างการคำนวนค่าผลกระทบของการปล่อยแคมเปญหนึ่งออกไปย้อนหลังก็จะซับซ้อนขึ้นไปอีก(causal inference analysis) การวิเคราะห์ไม่ว่าจะเป็นรูปแบบใดก็จะเริ่มต้นจากโจทย์และความคาดหวังหรือไอเดียของเราหรือของทีมธุรกิจ การที่เราได้เห็นว่ามันดียิ่งกว่าที่เราคิด หรือแย่กว่าที่เราคิดแบบเทียบไม่ติด ทั้งหมดนี้ก็สามารถเรียกได้ว่า insight อย่างหนึ่ง
ส่งท้าย
ผมหวังว่าทุกคนจะได้เห็นภาพโครงสร้างการทำงานไปไม่มากก็น้อยของตำแหน่งงานที่แต่ละคนสนใจแล้วก็งานที่จะได้ทำในแต่ละทีม ทั้งนี้ผมต้องให้ข้อมูลเพิ่มเติมว่าตัวผมเองก็ยังมีประสบการณ์น้อย เนื้อหาในนี้อาจจะไม่สามารถรับประกันได้ว่าจะเกิดขึ้นจริงในบริษัทที่ทุกคนไปทำงาน ข้อมูลอ้างอิงของผมเกิดจากประสบการณ์และการคาดการณ์ของผม ดังนั้นอย่าอ้างอิงเพียง 1 datapoint แล้วเชื่อว่ามันเป็นความจริง ถ้าหากใครที่อ่านแล้วเห็นว่ามีคำศัพท์ที่ซับซ้อนมากเกินไปผมต้องขออภัยด้วยจริงๆ แม้ผมจะพยายามลดความซับซ้อนลงให้ได้มากที่สุดแต่ก็ยังจำเป็นต้องเขียนคำที่ตรงตามความหมายให้มากเข้าไว้ ส่วนใครที่มีข้อคิดติชมเสนอแนะสามารถทักมาคุยกับผมได้ที่ LinkedIn ของผมครับ :)
Reference
สำหรับใครที่อยากอ่านเกี่ยวกับสายงานเพิ่มเติม ลองไปอ่านจากพี่ๆ ที่เขียนเกี่ยวกับสายงานเพิ่มเติมได้
