วิธีทำให้การติดตามกิจกรรมเป็นส่วนหนึ่งของกระบวนการเผยแพร่ของคุณ

หมายเหตุบรรณาธิการ: บทความนี้เผยแพร่ครั้งแรกในบล็อก Iteratively เมื่อวันที่ 15 มีนาคม 2021

เมื่อสร้างฟีเจอร์หรือผลิตภัณฑ์ใหม่ เป็นเรื่องปกติมากที่จะทิ้งการวิเคราะห์ไว้ในนาทีสุดท้าย หรือแม้กระทั่งลืมมันไปโดยสิ้นเชิง สถานการณ์นี้อาจดูคุ้นเคยสำหรับคุณ:

• PM ทำงานเกี่ยวกับการเปิดตัว
• การปล่อยเกิดขึ้น
• CEO ถาม PM เป็นอย่างไรบ้าง
• PM: ให้ฉันถามทีมข้อมูล
• ทีมข้อมูล: คุณไม่เคยนำเราเข้ามา ไม่มีข้อมูลเกี่ยวกับคุณลักษณะนี้
• PM กลับไปหา CEO โดยไม่มีคำตอบ
• ทีมข้อมูลและ PM รู้สึกว้าวุ่นใจ

สถานการณ์เช่นนี้อาจเกิดขึ้นได้ค่อนข้างบ่อย และสิ่งสำคัญคือต้องจำไว้ว่าไม่มีใครถูกตำหนิสำหรับเรื่องนี้ ส่วนใหญ่อาจมาจาก วัฒนธรรม

การชี้ไปที่ “วัฒนธรรม” เป็นส่วนสำคัญของปัญหาอาจดูเหมือนง่าย เพราะวัฒนธรรมนั้นยากที่จะนิยาม แต่บ่อยครั้งมากที่ค่านิยมและเป้าหมายขององค์กรไม่ได้สะท้อนให้เห็นอย่างสมบูรณ์ในพฤติกรรมของสมาชิกในทีม ตัวอย่างเช่น:

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

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

สิ่งนี้เกิดขึ้นเนื่องจากช่องว่างระหว่างค่านิยมขององค์กรของคุณกับวัฒนธรรมในชีวิตประจำวันที่เกิดขึ้นจริง มันง่ายมากที่จะพลาดช่องว่างนี้ บ่อยครั้งทีมจะมุ่งเน้นไปที่การรับข้อมูลเชิงลึกมากกว่าการสร้างแนวปฏิบัติที่ดีในการรวบรวมข้อมูลจริง การรักษาวัฒนธรรมข้อมูลที่ดีนั้นยาก!

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

รวมการวิเคราะห์เข้ากับวงจรชีวิตการพัฒนาซอฟต์แวร์ของคุณ

เมื่อทีมวิศวกรเริ่มทำงานสร้างชิ้นส่วนของผลิตภัณฑ์ พวกเขาจะเขียนโค้ดและทำสิ่งปกติกับมัน: แยกส่วน คอมมิต ทดสอบ ตรวจทาน ผสาน เพื่อให้แน่ใจว่าทุกคนเข้าใจตรงกันกับงานสร้างและสามารถแก้ไขข้อผิดพลาดใด ๆ ได้อย่างง่ายดาย

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

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

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

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

หมายเหตุเกี่ยวกับ QA ในบริบทของการวิเคราะห์: คุณอาจคิดว่าในขณะที่การนำแผนการติดตามไปใช้นั้นตรงไปตรงมาเพียงพอด้วยเครื่องมือและวัฒนธรรมที่เหมาะสม แต่ก็ยังไม่มีวิธีแก้ปัญหาที่ชัดเจนและสวยงามในการยืนยันว่ามันใช้งาน นี่คือเหตุผลที่ Amplitude ผสานรวมกับ CI และให้คุณเพิ่มความครอบคลุมการวิเคราะห์ให้กับการทดสอบที่มีอยู่ของคุณด้วยปลั๊กอินการทดสอบหน่วยของเรา

สร้างกระบวนการที่ทำซ้ำได้สำหรับการติดตามการวิเคราะห์

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

ศัตรูตัวฉกาจของการนำกระบวนการใหม่มาใช้คือการขาดการ ยอมรับ คุณไม่สามารถเพียงแค่พูดว่า “นี่คือวิธีที่เรากำลังทำการวิเคราะห์ของเราในตอนนี้” และคาดหวังให้ทุกคนเข้ามามีส่วนร่วม เรายืนยันอยู่เสมอว่าการติดตามการวิเคราะห์เป็นการทำงานร่วมกัน เมื่อคุณรวบรวมแผนการติดตาม ทีมที่เกี่ยวข้องทั้งหมดควรมีส่วนร่วมในการกำหนดแผน

นั่นหมายถึงการมีส่วนร่วมของผู้มีส่วนได้ส่วนเสียหลักทั้งหมดเมื่อคิดกระบวนการใหม่: ทีมผลิตภัณฑ์ ทีมข้อมูล/นักวิเคราะห์ และทีมวิศวกรรม ความเชี่ยวชาญเฉพาะของทีมเหล่านั้นจะช่วยให้คุณตัดสินใจ:

• เป้าหมายทางธุรกิจของคุณคืออะไร
• เมตริกที่คุณจะใช้เพื่อระบุว่าบรรลุเป้าหมายเหล่านี้หรือไม่
• หลักการตั้งชื่อแบบใดที่คุณจะใช้สำหรับเหตุการณ์ และอนุกรมวิธานอื่นๆ (เช่น เป็น 'songPlayed' หรือ 'song_played' หรือไม่ รายละเอียดเพิ่มเติมเกี่ยวกับสิ่งนี้ในส่วนของเราเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด)

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

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

กำหนดเป้าหมายการติดตามของคุณให้สอดคล้องกับเป้าหมายทางธุรกิจของคุณ

หากคุณกำลังสร้างผลิตภัณฑ์ที่คล่องตัว (เช่น การใช้โครงสร้าง วัดผล เรียนรู้เฟรมเวิร์ก) คุณจะต้องใช้ข้อมูลในการตัดสินใจอย่างแน่นอน อย่างไรก็ตาม : เมื่อต้องตัดสินใจว่าจะไปในทิศทางใดต่อไป อย่าเริ่มต้นด้วยข้อมูล แต่ให้เริ่มด้วยคำถาม

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

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

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

ส่วนหนึ่งของการสร้างวัฒนธรรมข้อมูลที่ดีคือการช่วยให้ทีมเข้าใจว่า วิธีที่ คุณใช้ข้อมูลเป็นตัวสร้างความแตกต่าง ไม่ใช่ตัวข้อมูลเอง เริ่มกระตุ้นความอยากรู้อยากเห็นโดยธรรมชาติ และเฉลิมฉลองผลกระทบของการตัดสินใจตามข้อมูลเชิงลึกภายใน

ข้อมูลและวัฒนธรรมการวิเคราะห์ที่ดีเป็นกระบวนการต่อเนื่อง

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

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

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

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