วิศวกรซอฟต์แวร์ควรทำหน้าที่เป็นฝ่ายสนับสนุนทางเทคนิคหรือไม่ [ปิด]

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

นี่เป็นปัญหาคลาสสิคใน บริษัท ที่มีองค์ประกอบการพัฒนาซอฟต์แวร์ในการทำงานไม่ว่าจะเป็น บริษัท ซอฟต์แวร์หรือไม่ก็ตาม ฉันต่อสู้กับสิ่งนี้ตลอดเวลา

มีผู้พัฒนาที่เกี่ยวข้องในการสนับสนุนการผลิต

ข้อดี

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

จุดด้อย

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

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

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

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

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

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

อีกครั้งฉันไม่สามารถเครียดพอที่จะให้ความสำคัญกับสิ่งใดสิ่งหนึ่ง

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

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

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

มันขึ้นอยู่กับ บริษัท

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

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

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

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

นักพัฒนาควรเป็นบรรทัดสุดท้ายของการสนับสนุน

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

หากเป็นปัญหาใหญ่จริง ๆ เราจะได้ยิน

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

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

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

มันควรจะเป็นช่วงเวลาสั้น ๆ เพื่อไม่ให้ขัดจังหวะภารกิจการพัฒนาที่แท้จริง

มีความสามารถและทักษะที่คุณต้องใช้ในการพัฒนาซอฟต์แวร์และความสามารถและทักษะที่คุณต้องการเพื่อการสนับสนุนที่มีประสิทธิภาพ ฉันไม่รู้ว่าพรสวรรค์เหล่านี้มีความสัมพันธ์กัน

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

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

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

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

ฉันคิดว่ากลยุทธ์ทั่วไปที่ดีที่สุด (โดยไม่ต้องคำนึงถึงขนาดของ บริษัท หรือการกู้คืน) คือการใช้ทีมสนับสนุนเพื่อแก้ไขปัญหาผลไม้แขวนลอยต่ำและปัญหาที่พบบ่อยที่สุด ("คุณลองปิดเครื่องแล้วหรือยัง?") วิศวกรควรทำงานร่วมกับลูกค้าในปัญหาที่ยุ่งยากกว่าซึ่งต้องการความรู้เกี่ยวกับวิธีการทำงานของระบบพร้อมกับการสนับสนุนเชิงผู้พัฒนาเพิ่มเติม (APIs, เครื่องมือสำหรับนักพัฒนาและอื่น ๆ ) คุณอาจให้ผู้สนับสนุนทำหน้าที่เป็น "liason" แต่ฉันพบว่านั่นเป็นปัญหามากกว่าปกติ

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

ไม่มีอะไรที่เหมือนกับการเรียก 3AM หลายครั้งที่จะทำให้คุณทราบว่าการตัดสินใจออกแบบและ / หรือทางลัดบางอย่างมีผลต่อความสามารถของผู้คนในการสนับสนุนและรักษารหัสของคุณ

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

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

ฉันเข้าร่วมกับดักนี้เมื่อฉันเข้าร่วม บริษัท ที่มีค่าตอบแทนดี ในระหว่างการสัมภาษณ์ฉันได้รับแจ้งว่าจะมีการพัฒนา 70% และการสนับสนุน 30% และฉันยอมรับข้อเสนอ อาจเป็น บริษัท หรือสภาพแวดล้อมที่ฉันกำลังทำงานอยู่ แต่จริงๆแล้วมันรองรับ 90% และพัฒนา 10% สองสามปีที่ผ่านมาตอนนี้ฉันสูญเสียการพัฒนา ฉันเสียใจที่ฉันยอมรับข้อเสนอนี้

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

น่าเสียดายที่ฉันอยู่ในภาวะชะงักงัน

โปรดอย่ายอมรับบทบาทหากคุณไม่ชอบหรือไม่สนใจ

ข้อด้อย - สมมติว่าคุณต้องติดต่อกับลูกค้าโดยตรง

1) ทำให้ลูกค้าของคุณเสีย

ถ้าเป็นการสนับสนุนบรรทัดแรก / 2nd / 3rd (ฉันหมายถึงการสนับสนุนบรรทัดเบลอจริง ๆ ) ซึ่งนักพัฒนาจัดการกับลูกค้าโดยตรงก็เป็นเรื่องใหญ่ นักพัฒนามีชุดทักษะที่จำเป็นสำหรับการแก้ไขปัญหาหรือพัฒนาวิธีแก้ไขปัญหา หากลูกค้ามีสิทธิ์เข้าถึงนักพัฒนาซอฟต์แวร์อย่างสมบูรณ์ (สายเบลอ) - ไม่มีการหยุดลูกค้าจากการ "ละเมิด" สิทธิพิเศษนี้ซึ่งส่งผลให้ลูกค้าที่เสียความต้องการและได้รับสิทธิพิเศษที่จ่ายเงินไม่เกินลูกค้ารายอื่น

2) ปรับอากาศนักพัฒนาของคุณที่จะโกหกและทำเรื่อง

ใครก็ตามที่จัดการกับลูกค้ารู้ว่าเป็นสิ่งจำเป็นก่อนที่จะโกหกพวกเขา มีบั๊กที่มีการแก้ไข 1 บรรทัดซึ่งสามารถทำได้ภายใน 5 นาที เจ้าหน้าที่ฝ่ายสนับสนุนลูกค้าจะได้รับการฝึกอบรมเพื่อจัดการความคาดหวังของลูกค้าซึ่งอาจใช้เวลาถึง 3 วันในการแก้ไข

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

3) ประวัติความเป็นมาของคุณ

หากคุณไม่ได้เปลี่ยนจากวิศวกรซอฟต์แวร์เป็นนักวิเคราะห์ธุรกิจ / ที่ปรึกษาด้านไอที / การจัดการโครงการประวัติย่อของคุณจะประสบปัญหาทางเทคนิค

งานสนับสนุนที่เสียค่าใช้จ่ายซึ่งหมุนเวียนระหว่างทีมเป็นเรื่องที่แตกต่าง

ข้อดี

1) หยุด Whiners จาก Whining

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

ใช่เพราะพวกเขาทำ ฉัน lol'd เมื่อฉันอ่านคำถามนี้? ฉันเป็นเช่นนี้ยังเป็นคำถามได้อย่างไร (ไม่ใช่ว่าฉันกำลังถามสิทธิ์ของคุณที่จะถามคำถาม OP) แต่มันเป็นเชิงโวหารเพราะเกือบทุก Dev ที่ฉันเคยพบเคยมีงานสนับสนุนด้านเทคนิคบางประเภทโดยนัยภายในหรือ ฟังก์ชั่นงานของเธอ คุณไม่สามารถหลีกเลี่ยงได้ ในกรณีส่วนใหญ่ผู้ที่ปฏิบัติตามข้อกำหนดทางเทคนิคของคุณไม่เพียง แต่ในโดเมนการใช้งานของคุณ แต่ในแง่ของไอทีโดยทั่วไป มันยากมากที่จะหลีกเลี่ยงอย่างสมบูรณ์