สิ่งที่อยากได้ของนักพัฒนาจากเจ้าของผลิตภัณฑ์

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

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

ความชัดเจนในการมองเห็นผลิตภัณฑ์ — ให้ความรู้

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

จัดลำดับความสำคัญของรายการคุณสมบัติ

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

ทุกอย่างควรทำงานพร้อมเพรียงกัน

สถานการณ์ข้างต้นเป็นสิ่งที่ Product Owner สามารถช่วยเหลือได้

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

ให้ความรู้แก่ทีมเทคว่าทำไมเราถึงต้องการคุณสมบัติ

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

ทำความเข้าใจรายละเอียดของงานด้านเทคนิคในระดับสูง

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

เจ้าของผลิตภัณฑ์ควรทำอย่างไรกับ Tech Tasks

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

เวลาวิเคราะห์

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

บทสรุป

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

เนื้อหาเพิ่มเติมที่PlainEnglish.io สมัครรับจดหมายข่าวรายสัปดาห์ฟรีของ เรา ติดตามเราได้ที่Twitter , LinkedIn , YouTubeและDiscord สนใจในการแฮ็คการเติบโตหรือไม่? ตรวจสอบวงจร