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