소프트웨어 엔지니어도 기술 지원 역할을해야합니까? [닫은]

소프트웨어 엔지니어도 기술 지원 역할을해야합니까? 즉, 회사에서 엔지니어가 소프트웨어 엔지니어와 기술 지원 모자를 모두 착용하도록 허용해야합니다. 엔지니어의 많은 시간이 기술 지원에 의해 사용되는 경우 소프트웨어 작성 기능을 제거하는 것으로 보입니다.

이것은 소프트웨어 회사이든 아니든 업무에 소프트웨어 개발 구성 요소가있는 회사의 전형적인 문제입니다. 나는 항상 이것으로 고투한다.

생산 지원에 개발자 참여

찬성

• "진공 개발"증후군과 싸우십시오 . 사용자가 앱을 사용하는 방식에 노출되는 것이 중요합니다. 마침내 이것을 젊은 개발자로 볼 때까지 나는 엉터리 UI 개발자가 무엇인지 몰랐다. 디자인, 분석 또는 사용자의 관점이 아니라 코딩에만 관심이있었습니다.
• 자신이 생각하는 것만 큼 좋지 않은 개발자는 겸손해질 수 있습니다 (이 혜택을받을 것이라는 보장은 없지만 일부 개발자는 진정으로 망각하고이기적이고 완고합니다).
• 개발자는 도메인 지식을 습득 합니다. 개발자가 결국 비즈니스 분석 단계 (있는 경우)에서 누락 된 갭을 식별하고 작성하는 데 더 능숙 해지는 경우에 중요합니다.
• 좋은 지원은 마케팅 포인트입니다. 잘하면 고객이 감사하게 될 것입니다. 의사 소통 기술과 도메인 지식을 갖춘 숙련 된 개발자가이를 잘 수행 할 수 있습니다. 그러나 여전히 지원이 필요하지 않은 응용 프로그램의 품질이 높은 것을 선호합니다. 우수한 품질은 자체 고객 지원 형식 (및 마케팅 지점)입니다.

단점

• 방해 요인 . 이것은 프로젝트 작업과 지원 작업을 혼합하는 가장 큰 결함입니다. 프로젝트는 지원을 방해하고 지원은 프로젝트를 방해합니다. 프로젝트는 추정치와 이정표 진행 상황에 따라 달라지며 지원은 예측할 수 없으며 즉석 긴급 상황이 발생할 수 있습니다. 프로젝트는 스케줄 기반이며 지원은 중단 기반입니다. 행복한 조합이 아니며 개발자가 다루는 데 매우 실망합니다.
• 모든 사람이 지원을 잘하는 것은 아닙니다 . 앱이나 비즈니스에 익숙하지 않은 사람 또는 사용자 액세스로부터 더 잘 보호되는 성격이나 의사 소통 기술을 가진 사람은 지원이 잘되지 않을 수 있습니다.
• 비효율적 인 자원 사용 . Frank Shearar는 사소한 지원을 수행하는 개발자는 레벨 1 지원 기술보다 비쌀 수 있다고 의견에 언급했습니다.

내 경험상 대부분의 개발자는 지원을 좋아하지 않습니다. 프로젝트와 지원 측면에서 모두 봉사하면서 동정 할 수 있습니다. 동시에 두 가지를 모두 수행해야 할 경우 완화 요소는 종종 지원 비상 사태를 처리하고 프로젝트 마감 시간을 정하기 위해 종종 초과 근무 수당으로 이루어집니다. 프로젝트 관리자는 더 많은 비용을 들이지 않고 날짜를 만드는 것을 의미하기 때문에 무급 초과 근무를 좋아하지만 개발자에게는 막대한 그릇입니다.

그러나 개발자가 안정적이고 직관적 인 시스템을 만드는 데 더 나은 작업을 수행하면 지원이 줄어든다고 생각합니다. 그래서 이것은 두 가지를 혼합하는 이상한 원형 논쟁을 만듭니다. 두 가지를 모두 해야하는 경우 내가해야 할 일은 동시성을 피하는 방법을 찾는 것입니다.

개발자들은 이미 두 개의 모자를 쓰고 있다고 생각합니다. 지원은 컴퓨터를 연결하지 않은 등 사소한 문제로부터 개발을 보호하는 데 사용되는 필터와 비슷합니다. 그러나 개발과 지원 사이에는 긴밀한 연결이 있어야합니다. 일부 고객은 버그로 인한 합법적 인 문제가 있습니다. 이러한 문제를 가능한 빨리 정리하려면 개발 책임이 있어야합니다. 어떤 의미에서 개발자는 이미 지원 팀의 일원입니다. 2 단계 지원이라고합니다.

아니야
우리 모두는 당신이 무슨 일을 중지해야 할 수 있습니다 얼마나 어려운 알고 묻는 질문에 대답. 헬프 데스크의 전화에 응답하고 일부 유틸리티 응용 프로그램을 작성합니다.

5 분마다 전화를 받아야하므로 문제 해결에 집중할 수 없습니다. 나는 문제를 해결하기 위해 내가 할 수있는 일에 대해 끊임없이 생각하고 있기 때문에 일을 할 수있을뿐 아니라 일도 할 수 없으며, 내가 가진 솔루션을 완전히 구현할만큼 오랫동안 프로그래밍 작업을하고 있지 않습니다.

다시 한 번, 나는 한 측면이나 다른 측면에 집중할 수있는 것이 얼마나 중요한지 충분히 강조 할 수 없었습니다.

필자는 결코 개발자를 최우선 지원으로 두지 않을 것입니다. 중단 횟수와 반복해야 할 양은 대부분의 개발자가 RTFM 을 외치며 다음 전화를 걸도록합니다. 이것은 고객이 필요로하는 것이 아니며 개발자가 견뎌야하는 것도 아닙니다.

고객 서비스 위치에는 특정 규칙이 있습니다. 화나게 부르는 사람에게는 전화를받는 첫 번째 사람이 잘못되었습니다. 회사의 사장, 앱을 개발 한 사람 또는 지원 관리자가 있더라도 상관 없습니다. 고객이 자신이하는 일을 알거나 알 수없는 두 번째 사람을 얻으면 고객은 진정하고 문제를보다 명확하게 설명 할 수 있습니다.

이것은 좋은 개발자를 유지하려는 환경이 아닙니다. "컵 홀더가 더 이상 작동하지 않는 이유"를 넘어서는 특히 어려운 문제에 대해 개발자가 고객과 상호 작용하도록하는 데 가치가 있습니까? 물론. 그러나 지원 요청이 첫 번째 및 두 번째 계층 지원 라인을 통해 심사 된 후입니다.

회사에 따라 다릅니다.

내 직업은 정확히 이와 같습니다 . 저는 소프트웨어 개발자이지만 상당히 작은 회사이므로 각 개발자는 일반적으로 자체 소프트웨어를 기반으로 "비공식"지원 역할을 수행합니다. 일부 개발자는 개발 / 배송 한 제품 수, 제품 버그, 지원 효율성 등 여러 요인에 따라 다른 개발자보다 더 많은 지원을 수행해야 합니다 . 고객에게 문제를 해결하는 데 필요한 것을 정확하게 제공 할 수 있으면 가능한 빨리 문제를 해결하기 위해 고객에게 계속 돌아옵니다. 양날의 칼? 예. 생산성 저하로 어려움을 겪지 만 고객은 행복하며 고객이 될 가능성이 높습니다. 이것은 소규모 회사에 중요합니다.

우리는 시스템 지원 팀을 가지고 있지만 우리가하는 일의 특성상 대부분 하드웨어 관련 문제를 처리해야합니다. 개인적으로, 소규모 회사에서는이 문제가 생각만큼 파괴적이지 않습니다. 물론 중요한 기능을 해결하려고하면서 동시에 고객 서비스에 전화를 겁니다훨씬 향상되었습니다. 그들은 중고 정보와 지원 스크립트를 가진 사람 대신 문제를 해결하는 방법을 알고있는 권위있는 목소리를 가질 수 있습니다. 문제를 해결할 수 없으면 버그에 대한 수정을 구현하거나 향후 릴리스에 대한 기능 요청을 고려할 수 있도록 개인적으로 안심시킬 수 있습니다. 소프트웨어 사용자로부터 직접적인 피드백을받을 수 있으므로 다음 버전이 기존의 생각보다 훨씬 나아질 수 있습니다.

나는 행복한 고객이 회사의 이미지를 더 긍정적으로 만들어서 더 많은 고객 을 유도한다고 생각합니다 . 이것이 바로 소프트웨어 엔지니어로서 기술 지원을 좋아하는 이유입니다.

컴퓨터 기술 지원팀이 무슨 일이 일어나고 있는지 실제로 이해하는 사람과 당신을 연결시키지 않으려는 것보다 더 실망스러운 것은 없습니다. 모든 대기업에 기술 지원을 제공 할 프로그래머가 있기를 바랍니다.

개발자는 마지막 지원 라인이어야합니다.

헬프 데스크와 QA 부서가 고객을 도울 수 없을 때만 우리는 번거 롭습니다. 그럼에도 불구하고 우선 순위가 지정된 버그 추적 시스템을 거쳐야합니다.

그것이 정말로 큰 문제라면 우리는 그것을들을 것입니다.

새로운 개발자이거나 도메인 및 고객 기반에 익숙하지 않은 경우에만이 작업을 수행합니다. 영구적으로 만드는 것은 좋은 생각이 아닙니다.

나의 마지막 직업은 바로 이것이었다. 기존 시스템을 지원하고 필요에 따라 새로운 시스템도 작성했습니다. 총재 해였습니다. 나는 끊임없이 중단 될 것입니다. 프로젝트가 시작되기까지 영원히 걸릴 것이기 때문에 나의 사기는 매우 낮았습니다. 또한 추가 비용없이 근무 외 시간 지원을 위해 호출기를 휴대해야했습니다 (이는 의료 분야에있었습니다). 솔루션 (당시 관리자에게 제안한)은 최첨단 기술 지원을 받았을 것이며 소프트웨어 버그 인 경우 개발자에게 전달해야한다고 생각합니다. 말할 것도없이 나는 더 나은 모든 개발 직업을 위해 마침내 떠날 때까지 1 년 반 밖에 지속되지 않았다!

때로는 그렇습니다. 고객과 대면하는 것은 대부분의 사람들, 특히 프로그래머가 부족하다는 관점을 제공합니다. 사용자가 실제로 제품을 사용하거나 실제로 생각하는 방식은 종종 빌더 (엔지니어)가 생각하는 방식에서 멀리 떨어져 있습니다.

실제 개발 작업을 방해하지 않도록 짧은주기의 뾰루지가 있어야합니다.

소프트웨어를 개발하는 데 필요한 재능과 기술과 1 차 지원에 효과적이어야하는 재능과 기술이 있습니다. 나는이 재능이 어떤 상관 관계가 있는지 모른다.

즉, 전화 지원 기능에 부분적으로 기초하여 개발자를 고용하거나 고객을 잘 다루지 않고 처음부터하고 싶지 않은 사람들과 직접 대화 할 수있게됩니다. 이것은 예의 바른 대본을 읽는 두꺼운 인도 억양을 가진 남자와 대화하는 것보다 낫거나 나을 수도 있습니다.

또한 작업을 불쾌하게 만들 때 (실제로 일차 지원을 즐기는 개발자를 모르는 경우) 일부 개발자가 떠나게됩니다. 이들은 일반적으로 다른 일자리를 더 쉽게 얻을 수있는 사람들입니다. 즉 좋은 일자리입니다. 이 과정이 진행됨에 따라 재능이 적은 사람들로 가득한 상점이 생겨서 유능한 직원이 다른 사람의 첫 번째 구인 제안을 통과하는 것이 훨씬 즐겁지 않습니다.

심각한 개발이 완료되는 한 자주 중단이 발생하면 잊어 버리십시오. 제 아내는 개발과 사용자 지원을 동시에 할 것으로 기대되는 것에 대해 많은 불평을했습니다.

많은 것이 회사에 달려 있다고 생각합니다. 일반적인 BigCo 회사는 일반적으로 개발자를 격리시킬 사람들을 지원할 여유가 있습니다. 반면에 총 인원이 3 명인 신생 기업 은 별도의 지원 인력을 제공 할 자원이 없을 수 있습니다.

회사 규모 나 조직에 관계없이 가장 일반적인 전략은 지원 팀을 사용하여 매달린 과일과 가장 일반적인 문제를 해결하는 것이라고 생각합니다 ( "전원을 껐다 켜 보셨습니까?"). 엔지니어는 시스템이 작동하는 방식에 대한 지식과 개발자 중심의 지원 (API, 개발자 도구 등)에 대한 지식이 필요한 까다로운 문제에 대해 고객과 협력해야합니다. 지원 담당자가 "교제 원"역할을하도록 할 수는 있지만 일반적으로 가치가있는 것보다 더 문제가 많습니다.

필자는 개발자를 항상 지원으로 사용하는 것이 적절하지 않다고 생각하지만 개발자가 응용 프로그램의 초기 지원을 수행하도록하는 것에 대한 언급이 있다고 생각합니다. 특히 근무 시간 외 지원이 포함되어야합니다. 또한 정기적으로 앱에 대한 시간 외 지원을 예약하는 것이 유용 할 수 있다고 생각합니다.

특정 디자인 결정 및 / 또는 바로 가기가 사람들이 코드를 지원하고 유지하는 능력에 어떤 영향을 미치는지 알기 위해 여러 번의 3AM 호출과 같은 것은 없습니다.

이상적으로는 위의 사이트에 대한 이유는 없지만 개발자가 비즈니스에서 기대하는 빠른 해상도를 제공하여 소프트웨어의 지속적인 개선을 지원할 수 있기 때문에 프로젝트가 초기 단계 인 경우에는 그렇습니다. 나는 똑똑한 지원을 제공하는 개발자, 예를 들어 분석적인 기술을보다 정식적인 전일제 지원 팀에 빌려주는 개발자, 그리고 서비스와 협력 정신을 보여주는 방식으로 비즈니스에 응답하는 개발자를 소중하게 생각합니다. 그러나 이러한 성공의 열쇠에는 1 단계 및 2 단계 지원을 인식하고 공식화하는 관리가 포함되어있어 개발자는 단기적인 역할만으로도 개발자를 신속하게 오프로드 할 수 있습니다. 개발 및 지원에 대한 요점을 보여주는 개발자는 3 차 지원 또는 지원 담당자 지원으로 육성되어야합니다. 그래서 해야 시간에 의존하고 재능과 욕구에 의존하며 효과적으로 관리됩니다.

저의 관심은 어려운 지원 질문에 답하고, 경험에서 배운 내용을 종합하여 지원의 필요성을 줄임으로써 최종 사용자와 기본 지원 모두에게 이익이되는 것입니다.

돈을 많이 벌고 회사에 들어 왔을 때이 함정에 빠졌습니다. 인터뷰 중에 70 %의 개발과 30 %의 지원이있을 것이라는 제안을 받았으며 제안을 수락했습니다. 현재 작업중인 회사 또는 환경 일 수 있습니다. 그러나 실제로는 90 % 지원 및 10 % 개발입니다. 몇 년이 지난 지금 나는 개발의 그립을 잃었습니다. 이 제안을 수락 한 것을 후회합니다.

그러나 많은 새로운 기술과 프레임 워크에서 코딩에 대한 관심을 잃어버린 것 같습니다. 이제 어디서부터 다시 시작할지 모르겠습니다. 계속 준비하고 있지만이 helloworld 예제는 실용 경험이 충분하지 않아서 내 지식과 경험을 업데이트하기가 실제로 어려워지고 있습니다. 가족의 헌신 때문에 직장을 떠날 수도 없습니다.

불행히도 나는 교착 상태에 있습니다.

마음에 들지 않거나 관심이 없으면 역할을 수락하지 마십시오.

단점-고객과 직접 거래해야한다고 가정합니다.

1) 고객을 망치고

개발자가 고객을 직접 다루는 첫 번째 / 두 번째 / 세 번째 줄 지원 (실제로 흐릿한 줄 지원)이라면 큰 단점입니다. 개발자는 문제를 디버깅하거나 문제를 해결하기위한 솔루션을 개발하는 데 필요한 기술을 보유하고 있습니다. 고객이 개발자에게 완전히 액세스 할 수있는 경우 (흐리게 표시됨) 고객이이 권한을 "남용"하지 않아도되므로 다른 고객보다 더 많이 지불하지 않는 부패하고 까다 롭고 특권 고객이됩니다.

2) 개발자가 이야기를 구성하고 구성하도록 컨디셔닝.

고객과 거래 한 사람은 누구나 거짓말을 할 수있는 전제 조건이라는 것을 알고 있습니다. 5 분 안에 수행 할 수있는 1 줄 수정 버그가 있습니다. 고객 지원 담당자는 고객의 기대치를 관리하도록 훈련을 받았으며, 해결하는 데 최대 3 일이 소요되었습니다.

개발자는 고객과 직접 거래해야하는 경우 기술적 인 문제를 해결하고 시스템이 원활하게 실행되도록해야 할 때 일을 할 때 고객을 진정 시키거나 속이는 창의적인 방법을 고려해야합니다.

3) 이력서가 고통받습니다.

소프트웨어 엔지니어에서 비즈니스 분석가 / IT 컨설턴트 / 프로젝트 관리로 전환하지 않는 한 CV는 기술적 인 측면에서 어려움을 겪을 것입니다.

팀간에 순환되는 유료 지원 작업은 다른 이야기입니다.

찬성

1) Whiners가 휘젓는 것을 멈추십시오

자신이 싫어하는 일을하는 개발자는 코딩을 훨씬 더 좋아하게 될 것입니다. 끊임없이 변하는 프로그래머가 있습니까? 한 달 동안 핫라인에 두십시오.

그렇습니다. 이 질문을 읽을 때 나는 lol'd? 나는 이것이 어떻게 질문인지 (나는 OP에게 질문 할 권리에 의문을 제기하는 것이 아니라) 어떻게 같았 지 만, 내가 만난 거의 모든 Dev가 그의 또는 그 내부에 어떤 유형의 기술 지원 작업을 암시했기 때문에 그것은 매우 수사적입니다. 그녀의 직업 기능. 당신은 단순히 그것을 피할 수 없습니다. 대부분의 경우 기능 영역뿐만 아니라 일반적으로 IT 측면에서 가장 기술적으로 유능한 사람입니다. 완전히 피하는 것은 매우 어렵습니다.