ในบทความนี้ ฉันจะแบ่งปันประสบการณ์ของฉันในการเลือกแนวคิดสำหรับการพัฒนาฟังก์ชันการทำงานของผลิตภัณฑ์ของเรา และบอกวิธีรักษาเวกเตอร์การพัฒนาหลัก
เรากำลังพัฒนาระบบการชำระเงินอัตโนมัติ (ACS) - การเรียกเก็บเงิน ภาคเรียน
อายุของผลิตภัณฑ์ของเราคือ 14 ปี ในช่วงเวลานี้ ระบบได้เปลี่ยนจากรุ่นแรกของเครื่องวัดทางอุตสาหกรรมไปสู่คอมเพล็กซ์โมดูลาร์ที่ประกอบด้วยผลิตภัณฑ์ 18 รายการที่เสริมซึ่งกันและกัน สิ่งสำคัญที่สุดประการหนึ่งของการมีอายุยืนยาวของโปรแกรมคือการพัฒนาอย่างต่อเนื่อง และความคิดที่จำเป็นสำหรับการพัฒนา
ความคิด
แหล่งที่มา
มี 5 แหล่ง:
- เพื่อนหลักของผู้พัฒนาระบบสารสนเทศขององค์กรคือ ลูกค้า. และลูกค้าคือภาพรวมของผู้มีอำนาจตัดสินใจ ผู้สนับสนุนโครงการ เจ้าของและผู้ดำเนินการกระบวนการ ผู้เชี่ยวชาญด้านไอทีภายในองค์กร ผู้ใช้ทั่วไป และผู้คนจำนวนมากที่มีความสนใจในระดับที่แตกต่างกัน เป็นสิ่งสำคัญสำหรับเราที่ตัวแทนของลูกค้าแต่ละคนอาจเป็นผู้จัดหาแนวคิด ในกรณีที่เลวร้ายที่สุด เราได้รับแต่ความคิดเห็นเชิงลบเกี่ยวกับปัญหาในระบบ ที่ดีที่สุด มีบุคคลในฝั่งไคลเอ็นต์ซึ่งเป็นแหล่งความคิดอย่างต่อเนื่องสำหรับการปรับปรุง โดยให้ข้อมูลที่มีโครงสร้างเกี่ยวกับความต้องการของลูกค้า
- ของเรา ผู้ขายและผู้จัดการบัญชี เป็นแหล่งความคิดที่สำคัญอันดับสองสำหรับการปรับปรุง พวกเขาสื่อสารเป็นจำนวนมากและกระตือรือร้นกับตัวแทนในอุตสาหกรรม รับคำขอโดยตรงสำหรับฟังก์ชันการเรียกเก็บเงินจากผู้มีโอกาสเป็นลูกค้า ผู้ค้าและบัญชีต้องตระหนักถึงการเปลี่ยนแปลงที่สำคัญทั้งหมดในการทำงานและการอัปเดตซอฟต์แวร์ล่าสุดของคู่แข่ง สามารถปรับข้อดีและข้อเสียของโซลูชันต่างๆ ได้ พนักงานของเราเหล่านี้เป็นคนกลุ่มแรกที่รู้สึกว่าคุณสมบัติการเรียกเก็บเงินบางอย่างกลายเป็นมาตรฐานโดยพฤตินัยหรือไม่ หากไม่ถือว่าซอฟต์แวร์นี้สมบูรณ์
- เจ้าของผลิตภัณฑ์ เป็นหนึ่งในผู้จัดการระดับสูงของเราหรือผู้จัดการโครงการที่มีประสบการณ์สูง คำนึงถึงเป้าหมายเชิงกลยุทธ์ของบริษัทและปรับแผนการพัฒนาผลิตภัณฑ์ให้สอดคล้องกัน
- สถาปนิกบุคคลที่เข้าใจความเป็นไปได้และข้อจำกัดของโซลูชันทางเทคโนโลยีที่เลือก/ใช้แล้ว และผลกระทบต่อการพัฒนาผลิตภัณฑ์
ทีมพัฒนาและทดสอบ ผู้ที่มีส่วนเกี่ยวข้องโดยตรงกับการพัฒนาผลิตภัณฑ์
การจำแนกประเภทของเพลงฮิต
เราได้รับข้อมูลดิบจากแหล่งที่มา - จดหมาย ตั๋ว คำขอปากเปล่า ทั้งหมด
การอุทธรณ์ถูกจัดประเภท:
- รับปรึกษา ที่มีความหมายว่า "ทำอย่างไร" "ได้ผลอย่างไร" "ทำไมใช้ไม่ได้" "ไม่เข้าใจ..." การโทรประเภทนี้ไปที่สายสนับสนุนระดับ 1 เป็นไปได้ที่จะอบรมการปรึกษาหารืออีกครั้งในการอุทธรณ์ประเภทอื่นๆ
- เหตุการณ์ โดยมีความหมายว่า "ไม่ทำงาน" และ "ข้อผิดพลาด" จัดการโดยแนวรับ 2 และ 3 หากจำเป็นต้องแก้ไขและออกแพตช์อย่างรวดเร็ว ก็สามารถโอนจากฝ่ายสนับสนุนไปยังการพัฒนาได้โดยตรง เป็นไปได้ที่จะจัดประเภทใหม่เป็นคำขอเปลี่ยนแปลงและส่งไปยังงานในมือ
- การขอเปลี่ยนแปลงและพัฒนา. เข้าสู่ Backlog ของผลิตภัณฑ์ โดยไม่ต้องผ่าน Support Lines แต่สำหรับพวกเขามีขั้นตอนการประมวลผลแยกต่างหาก
มีสถิติเกี่ยวกับการเข้าชม - ทันทีหลังจากการเปิดตัวจำนวนการเข้าชมเพิ่มขึ้น 10-15% ในช่วงเวลาสั้น ๆ นอกจากนี้ยังมีสายเรียกซ้อนเมื่อมีลูกค้าใหม่ที่มีผู้ใช้จำนวนมากมาที่บริการคลาวด์ของเรา ผู้คนกำลังเรียนรู้ที่จะใช้คุณสมบัติใหม่ของซอฟต์แวร์ พวกเขาต้องการคำแนะนำ แม้แต่ลูกค้ารายเล็กเมื่อเริ่มงานในระบบก็สามารถใช้งานการปรึกษาหารือมากกว่า 100 ชั่วโมงต่อเดือนได้อย่างง่ายดาย ดังนั้น เมื่อติดต่อกับลูกค้ารายใหม่ เราจึงเผื่อเวลาไว้สำหรับการให้คำปรึกษาเบื้องต้นเสมอ บ่อยครั้งที่เราคัดเลือกผู้เชี่ยวชาญเฉพาะราย แน่นอนว่าค่าเช่าไม่ได้ชดเชยต้นทุนแรงงานเหล่านี้ แต่เมื่อเวลาผ่านไป สถานการณ์ก็จะคลี่คลายลง ตามกฎแล้วระยะเวลาของการปรับตัวจะใช้เวลาตั้งแต่ 1 ถึง 3 เดือนหลังจากนั้นความจำเป็นในการให้คำปรึกษาจะลดลงอย่างมาก
ก่อนหน้านี้เราใช้โซลูชันที่เขียนขึ้นเองเพื่อจัดเก็บการโทร แต่ค่อยๆเปลี่ยนไปใช้ผลิตภัณฑ์ Atlassian ขั้นแรก การพัฒนาถูกถ่ายโอนเพื่อให้ทำงานบน Agile ได้ง่ายขึ้น แล้วจึงค่อยสนับสนุน ตอนนี้กระบวนการที่สำคัญทั้งหมดอยู่ใน Jira SD และยังมีปลั๊กอินต่างๆ สำหรับ Jira รวมทั้งการบรรจบกัน โซลูชันที่เขียนขึ้นเองยังคงอยู่ในกระบวนการที่ไม่สำคัญสำหรับกิจกรรมของบริษัทเท่านั้น กลายเป็นว่าตอนนี้งานของเราเป็นแบบ end-to-end พวกเขาสามารถถ่ายโอนระหว่างการสนับสนุนและการพัฒนาโดยไม่ต้องกระโดดจากระบบหนึ่งไปยังอีกระบบหนึ่ง
จากบันเดิลนี้ เราสามารถรับข้อมูลเกี่ยวกับงานทั้งหมด ต้นทุนแรงงานที่วางแผนไว้และตามจริง ใช้ตัวเลือกการเรียกเก็บเงินที่หลากหลายสำหรับลูกค้า และสร้างเอกสารสำหรับความต้องการภายในและรายงานให้กับลูกค้า
กำลังประมวลผลคำขอเปลี่ยนแปลง
โดยทั่วไปแล้ว คำขอเหล่านี้มาในรูปแบบของข้อกำหนดคุณสมบัติ นักวิเคราะห์ของเราศึกษาคำขอ สร้างข้อกำหนดและ TOR ระดับบนสุด โอนข้อกำหนดและ TOR ไปยังบุคคลที่ส่งคำขอนี้เพื่อขออนุมัติ - เราต้องแน่ใจว่าเราพูดภาษาเดียวกันกับลูกค้า
หลังจากได้รับการยืนยันจากลูกค้าว่าเราเข้าใจกันถูกต้องแล้ว นักวิเคราะห์จึงป้อนคำขอลงในรายการค้างของผลิตภัณฑ์
การจัดการคุณสมบัติผลิตภัณฑ์
งานค้างสะสมคำขอที่ได้รับสำหรับการเปลี่ยนแปลงและการพัฒนา ทุก ๆ หกเดือน สภาเทคนิคซึ่งประกอบด้วยผู้อำนวยการ หัวหน้าฝ่ายบำรุงรักษา การพัฒนา ฝ่ายขาย และสถาปนิกระบบจะประชุมกัน ในรูปแบบการสนทนา สภาจะวิเคราะห์และจัดลำดับความสำคัญของแอปพลิเคชันจากงานในมือ และตกลงเกี่ยวกับงานพัฒนา 5 งานเพื่อนำไปใช้ในรุ่นถัดไป
ในความเป็นจริง สภาเทคนิคตอบสนองต่อข้อกำหนดของอุตสาหกรรมและตลาด โดยพิจารณาจากความต้องการที่บันทึกไว้ในใบสมัคร ทุกสิ่งที่มีความเกี่ยวข้องเพียงเล็กน้อยจะยังคงค้างอยู่ในงานในมือและไปไม่ถึงการพัฒนา
การจำแนกประเภทของคำขอเปลี่ยนแปลงและการเงิน
การพัฒนามีราคาแพง ดังนั้น เราจะแจ้งให้คุณทราบทันทีว่าเรามีตัวเลือกใดบ้างหากคำขอเปลี่ยนแปลงมาจากลูกค้า ไม่ใช่จากพนักงาน
คำขอเปลี่ยนแปลงจำแนกได้ดังนี้: ความต้องการเฉพาะอุตสาหกรรมหรือลักษณะเฉพาะขององค์กร ฟังก์ชันใหม่จำนวนมากหรือการแก้ไขเล็กน้อย การแก้ไขเล็กๆ น้อยๆ และคำขอแต่ละรายการได้รับการประมวลผลโดยไม่มีอะไรหรูหรา คำขอแต่ละรายการจะถูกคำนวณและนำไปใช้กับลูกค้ารายใดรายหนึ่งโดยเป็นส่วนหนึ่งของโครงการที่ทำงานร่วมกับเขา
หากนี่ไม่ใช่ความต้องการขนาดใหญ่ของอุตสาหกรรมและจำนวนฟังก์ชันมีมาก ก็สามารถตัดสินใจพัฒนาโมดูลใหม่แยกต่างหากที่จะขายนอกเหนือจากฟังก์ชันหลักได้ หากได้รับคำขอดังกล่าวจากลูกค้า เราสามารถครอบคลุมค่าใช้จ่ายในการพัฒนาโมดูล จัดหาโมดูลให้ลูกค้าโดยไม่คิดค่าใช้จ่ายหรือชำระเงินบางส่วน และขายโมดูลในโดเมนสาธารณะ ในสถานการณ์เช่นนี้ ลูกค้ารับภาระส่วนหนึ่งของระเบียบวิธีและดำเนินการนำร่องการใช้งานโมดูล
หากนี่เป็นความต้องการขนาดใหญ่ของอุตสาหกรรม ก็สามารถตัดสินใจรวมฟังก์ชันการทำงานใหม่ๆ ไว้ในผลิตภัณฑ์พื้นฐานได้ ค่าใช้จ่ายในกรณีนี้เป็นภาระของเราทั้งหมด และฟังก์ชันใหม่จะปรากฏในเวอร์ชันปัจจุบันของโปรแกรม
ลูกค้าเก่าจะได้รับการอัปเดต
อาจเป็นไปได้ว่าลูกค้าหลายรายมีความต้องการที่คล้ายกัน แต่ไม่ได้ดึงผลิตภัณฑ์จำนวนมาก ในกรณีนี้ เราสามารถส่งข้อมูลจำเพาะไปยังลูกค้าเหล่านี้และเสนอให้แบ่งค่าใช้จ่ายในการพัฒนาระหว่างกัน ในท้ายที่สุด ทุกคนเป็นผู้ชนะ: ลูกค้าได้รับการใช้งานฟังก์ชันด้วยต้นทุนที่ต่ำ เราทำให้ผลิตภัณฑ์สมบูรณ์ขึ้น หลังจากนั้นไม่นาน ผู้เข้าร่วมตลาดรายอื่นก็สามารถรับฟังก์ชันการใช้งานได้เช่นกัน
DevOps
การพัฒนาเตรียมการเผยแพร่หลักสองครั้งต่อปี ในแต่ละรุ่น เวลาจะถูกสงวนไว้สำหรับการดำเนินการ 5 งานที่ได้รับจากสภาเทคนิค ดังนั้น เบื้องหลังการหมุนเวียน เราจึงไม่ลืมเกี่ยวกับการพัฒนาผลิตภัณฑ์
แต่ละรุ่นต้องผ่านชุดการทดสอบและเอกสารประกอบที่เหมาะสม นอกจากนี้ รีลีสนี้ได้รับการติดตั้งในสภาพแวดล้อมการทดสอบของลูกค้าที่เกี่ยวข้อง ซึ่งจะตรวจสอบทุกอย่างอย่างพิถีพิถัน และหลังจากนั้นรีลีสจะถูกโอนไปยังการผลิต
นอกจากระบบการวางจำหน่ายแล้ว ยังมีรูปแบบของการแก้ไขข้อบกพร่องอย่างรวดเร็วเพื่อให้ลูกค้าไม่ต้องอยู่กับข้อผิดพลาดเป็นเวลาหกเดือน รูปแบบสื่อกลางนี้จะช่วยให้คุณสามารถตอบสนองต่อเหตุการณ์ที่มีความสำคัญอันดับแรกได้อย่างรวดเร็วและปฏิบัติตาม SLA ที่ระบุไว้
ทั้งหมดข้างต้นเป็นจริงสำหรับภาคธุรกิจและโซลูชันภายในองค์กรเป็นหลัก สำหรับบริการคลาวด์ที่มุ่งเน้นไปที่ส่วน SMB ไม่มีโอกาสมากมายสำหรับลูกค้าที่จะมีส่วนร่วมในการพัฒนาผลิตภัณฑ์ รูปแบบการเช่าสำหรับ SMB ไม่ได้แนะนำสิ่งนี้ด้วยซ้ำ แทนที่จะเป็นคำขอเปลี่ยนแปลงในรูปแบบของข้อกำหนดที่ชัดเจนจากฝ่ายองค์กร มีเพียงคำติชมและความปรารถนาตามปกติสำหรับบริการเท่านั้น เราพยายามฟัง แต่ผลิตภัณฑ์มีขนาดใหญ่มาก และความปรารถนาของลูกค้ารายหนึ่งที่จะนำสิ่งที่คุ้นเคยจากระบบประวัติศาสตร์เก่าของเขาอาจขัดแย้งกับกลยุทธ์การพัฒนาของระบบโดยรวม
ที่มา: will.com