ソフトウェアエンジニアは技術サポートも務めるべきですか？[閉まっている]

ソフトウェアエンジニアもテクニカルサポートとして行動する必要がありますか？つまり、企業がエンジニアにソフトウェアエンジニアとテクニカルサポートの両方の帽子を着用させる場合です。エンジニアの時間の多くがテクニカルサポートに費やされると、ソフトウェアを書くことができなくなるようです。

これは、ソフトウェア会社であるかどうかに関係なく、ソフトウェア開発コンポーネントを仕事に持つ企業の典型的な問題です。私はいつもこれに苦労しています。

開発者をプロダクションサポートに関与させる

長所

• 「真空中の発達」症候群と戦う。ユーザーがアプリをどのように使用しているかを知ることが重要です。ついにこれを若い開発者と見なすまで、私がくだらないUI開発者であることに気付きませんでした。私が気にかけたのはコーディングだけで、設計、分析、ユーザーの視点ではありませんでした。
• 自分が思っているほど良くない開発者は謙虚になることができます（この恩恵を受ける保証はありませんが、一部の開発者は本当に気が遠く、利己的で、頑固です）。
• 開発者はドメインの知識を獲得します。これは、開発者が最終的にビジネス分析フェーズ（あると仮定した場合）で見逃したギャップを特定して埋めることができるようになる場合に重要です。
• 良いサポートはマーケティングのポイントです。あなたがうまくやれば、クライアントはそれを高く評価するようになるでしょう。そして、コミュニケーションスキルとドメイン知識を備えたバランスの取れた開発者は、これをうまく行うことができます。ただし、アプリケーションがサポートを必要としないほど十分に高品質であることを引き続き希望します。優れた品質は、独自の形態の顧客サポート（およびマーケティングポイント）です。

短所

• 中断要因。これは、プロジェクト作業とサポート作業を混合することの最大の欠点です。プロジェクトはサポートに干渉し、サポートはプロジェクトに干渉します。プロジェクトは見積もりとマイルストーンの進捗状況に依存し、サポートは予測不可能であり、緊急の緊急性を伴う場合があります。プロジェクトはスケジュールベースであり、サポートは中断ベースです。幸せな組み合わせではなく、開発者が対処するのは非常にイライラします。
• 誰もがサポートが得意というわけではありません。アプリやビジネスの経験が浅い人や、性格やコミュニケーションのスキルがユーザーアクセスからより適切に保護されている人は、サポートがうまく機能しない可能性があります。
• リソースの非効率的な使用。Frank Sheararはコメントで、些細なサポートを行う開発者はレベル1のサポート技術よりも高価になる可能性があると指摘しました。

私の経験では、ほとんどの開発者はサポートが好きではありません。プロジェクトとサポートの両方の面で役立ったので、同情できます。両方を同時に行う必要がある場合、緩和要因は、多くの場合、サポートの緊急事態に対処し、プロジェクトの期限を守るために、通常は無給の残業です。プロジェクトマネージャーは、お金をかけずにデートをすることを意味するので、無給の残業が好きですが、開発者にとっては、それは単なる大げさなことです。

ただし、開発者が信頼性が高く直感的なシステムを作成するためのより良い仕事をした場合、サポートが少なくなると思います。そのため、2つを混合するための奇妙な循環引数が作成されます。両方を実行する必要がある場合に実行する必要があると思うのは、同時実行を回避する方法を見つけることです。

開発者はすでに2つの帽子をかぶっていると思います。サポートは、コンピューターを接続しないなどの些細な問題から開発を保護するために使用されるフィルターに似ています。ただし、開発とサポートの間には密接な結合が必要です。一部のお客様には、おそらくバグの結果である正当な問題があります。これらの問題をできるだけ早く解決するのを支援することは、開発の責任であるべきです。ある意味で、開発者はすでにサポートチームの一部です...それをティア2サポートと呼びます。

強調していません。
我々は、すべてのそれはあなたがして何をしているか停止する必要がありますすることができますどのように困難を知って尋ねる質問に答えます。ヘルプデスクの電話に応答し、ユーティリティアプリケーションをいくつか作成します。

5分ごとに電話を取り直す必要があるため、問題の解決に集中できません。私は常に問題を解決するために何ができるかを常に考えているので、どちらの仕事もうまくいくことはありません。

繰り返しますが、私は、ある側面または他の側面に集中できることがどれほど重要であるかを十分に強調できませんでした。

開発者を最前線でサポートすることは決してありません。中断の回数と自分で繰り返さなければならない量によって、ほとんどの開発者はRTFMを叫び、次に電話をかける人に電話を切ります。これは、クライアントが必要とするものでも、開発者が耐えなければならないものでもありません。

カスタマーサービスポジションには特定のルールがあります。激怒した発信者にとって、電話に最初に応答した人は間違っています。会社の社長、アプリの開発者、またはサポートマネージャーのいずれであっても、問題ではありません。クライアントは、自分が何をしているのかを知っているかもしれないし、知らないかもしれない二人称を取得すると、落ち着いて問題をより明確に説明できるようになります。

これは、優秀な開発者を保持したい環境ではありません。「なぜカップホルダーが機能しなくなったのか」を超えた特に難しい問題について、開発者がクライアントと対話することに価値はありますか？絶対に。しかし、それはサポートリクエストが第1層および第2層のサポートラインを通じて審査された後です。

会社によって異なります。

私の仕事はまさにこのようなものです。私はソフトウェア開発者ですが、私たちはかなり小さな会社であるため、各開発者は通常、独自のソフトウェアに基づいた「非公式な」サポートの役割を担っています。一部の開発者は、開発/出荷した製品の数、製品のバグ、サポートの効果などの多くの要因に応じて、他の開発者よりも多くのサポートを行う必要があります。問題を解決するために必要なものを正確に顧客に提供できる場合、顧客はあなたに戻って問題をできるだけ迅速に解決し続けます。両刃の剣？はい。あなたは生産性の低下に苦しんでいますが、顧客は満足しており、顧客であり続ける可能性が高くなります。これは中小企業にとって重要です。

システムサポートチームがありますが、私たちの仕事の性質上、ほとんどの場合、ハードウェア関連の問題に対処する必要があります。個人的に、小さな会社では、この問題は想像するほど破壊的ではありません。確かに、重要な機能を実行しようとしているときに電話がかかりますが、同時に、カスタマーサービス大幅に改善されました。彼らは、（多くの場合）中古の情報とサポートスクリプトを持っている人の代わりに、問題の解決方法を知っている権威ある声を持つことができます。そこで問題を解決できない場合、バグの修正を実装することを個人的に安心させるか、将来のリリースに対する機能要求を検討することができます。ソフトウェアのユーザーから実際のフィードバックを直接受け取ることができるので、次のバージョンはあなたがすでに思っているよりもさらに良いものになります。

幸せな顧客はあなたの会社のよりポジティブなイメージを作り出し、それが通常より多くの顧客につながると思うのが好きです。それがソフトウェアエンジニアとして技術サポートが好きな理由です。

何が起こっているのかを本当に理解している人とあなたをつなぎ合わせたくないというコンピューター技術サポートほどイライラすることはありません。大規模なアプリケーション会社には、テクニカルサポートで働くプログラマーがいることを願っています。

開発者はサポートの最後の行である必要があります。

ヘルプデスクとQA部門が顧客を支援できない場合にのみ、面倒になります。その場合でも、優先順位付けされたバグ追跡システムを通過する必要があります。

それが本当に大きな問題であれば、私たちはそれを聞くでしょう。

私がこれを行うのは、それが新しい開発者であるか、ドメインおよび顧客ベースに精通していない場合のみです。それを永続的なものにすることは良い考えではありません。

私の最後の仕事はまさにこれでした。既存のシステムをサポートし、必要に応じて新しいシステムも作成しました。それは完全な災害でした。私は常に中断されます。開始したプロジェクトが完了するまでに時間がかかるため、私の士気は非常に低かった。また、追加料金なしで営業時間外のサポートのためにポケットベルを持ち歩く必要がありました（これはヘルスケアの分野でした）。解決策（当時上司に提案した）は、テクニカルサポートの最前線を持つことであり、それがソフトウェアのバグである場合、開発者に転送することだったと思います。言うまでもなく、私は最終的にすべての開発ジョブを改善するために去るまで、1年半しか続きませんでした！

時々、間違いなくはい。顧客に対面することは、多くの人、特にプログラマーに欠けている視点を与えます。ユーザーが実際に製品を使用する方法、または実際に考える方法は、多くの場合、ビルダー（エンジニア）が考える方法とは大きく異なります。

開発の実際のタスクを中断しないように、短い定期的なスティント用でなければなりません。

ソフトウェアを開発するために必要な才能とスキル、および第一線のサポートで効果的になるために必要な才能とスキルがあります。これらの才能に相関関係があることはわかりません。

これは、電話サポートを行う能力に一部基づいて開発者を雇わなければならないか、顧客を処理するのが苦手で、そもそもやりたくない人に直接顧客に話させることを意味します。これは、丁寧な台本を読む太いインド人のアクセントのある人と話すよりも良い場合と悪い場合があります。

また、あなたが仕事を不快にすると（そして、実際に第一線のサポートを楽しんでいる開発者を知りません）、あなたの開発者の何人かは去ります。これらは一般に、他の仕事をより簡単に得ることができる人、すなわち、良い人です。このプロセスが進むにつれて、才能のない人々で満たされたショップができあがり、有能な人が他の誰かからの最初の求人を過ぎて滞在することはさらに快適ではなくなります。

深刻な開発を完了する限り、頻繁に中断する場合は忘れてください。私の妻は、開発とユーザーのサポートを同時に行うことが期待されていることについて多くの不満を持っています。

その多くは会社に依存していると思います。通常、典型的なBigCo会社は、開発者を隔離するためのサポートを提供する余裕があります。一方、合計 3人のスタートアップには、個別のサポートスタッフを提供するリソースがない場合があります。

（会社の規模やリソースを考慮せずに）最善の一般的な戦略は、サポートチームを使用して、ぶら下がっている果物と最も一般的な問題のトラブルシューティングを行うことだと思います（「電源を入れたり切ったりしましたか？」）。エンジニアは、システムがどのように機能するかについての知識と、より開発者指向のサポート（API、開発者ツールなど）を必要とする、よりトリッキーな問題について顧客と協力する必要があります。サポート担当者に「連絡役」として行動してもらうこともできますが、それは通常、それが価値があるよりも厄介だと思います。

開発者を常にサポートとして使用することは適切ではないと思いますが、開発者にアプリケーションの初期サポートを行わせることについて何か言わなければならないことがあると思います。これには、特に営業時間後のサポートを含める必要があります。また、定期的に彼らのアプリの営業時間外のサポートに参加してもらうのに役立つと思います。

特定の設計上の決定やショートカットが、コードをサポートおよび保守する人々の能力にどのような影響を与えるかを認識するために、複数の3AM呼び出しのようなものはありません。

上記の理由で理想的ではありませんが、プロジェクトが始まったばかりの間はそうです。開発者は、多くの場合、ビジネスで期待される迅速な解決策を提供でき、ソフトウェアの継続的な改善に役立ちます。私は、サポートをスマートに提供する開発者を大切にしています。たとえば、より正式なフルタイムのサポートチームに分析スキルを提供する開発者や、サービスと協力の精神を示すような方法でビジネスに答える開発者です。ただし、この成功の鍵には、管理者が短期および短期の役割のみから開発者を迅速にオフロードするための第1レベルおよび第2レベルのサポートを認識および正式化することが含まれます。開発とサポートの両方のコツを示す開発者は、第3レベルのサポート、またはサポート担当者のサポートとして育成する必要があります。そうすべき 時間に依存し、才能と欲求に依存し、効果的に管理されます。

私自身の関心は、困難なサポートの質問に答えることであり、経験から学んだことを総合的にサポートの必要性を減らすことであり、それはエンドユーザーとプライマリサポートの両方に利益をもたらします。

良い給料で会社に入社したとき、私はこのtrapに陥りました。インタビューの中で、開発が70％、サポートが30％になると言われ、その申し出を受け入れました。私が現在取り組んでいる会社や環境かもしれません。しかし実際には、90％がサポートされ、10％が開発されます。数年が経ちましたが、開発のグリップを失いました。私はこの申し出を受け入れたことを後悔しています。

しかし、多くの新しいテクノロジーとフレームワークで、コーディングのグリップが失われたように感じます。今、どこから始めればいいのかわかりません。私は準備を続けていますが、これらのhelloworldの例は実用的な経験をするのに十分ではなく、私の知識と経験を更新することは本当に難しくなっています。家族のコミットメントのため、仕事をやり直すことさえできません。

残念ながら、私は行き詰まっています。

気に入らない場合や興味がない場合は、役割を受け入れないでください。

短所-顧客と直接取引する必要があると仮定します。

1）顧客を台無しにする

開発者が顧客と直接やり取りする最初/ 2/3のラインサポート（私は本当にぼやけたラインサポートを意味します）である場合、それは大きな欠点です。開発者には、問題をデバッグしたり、問題を解決するソリューションを開発したりするために必要なスキルセットがあります。顧客が開発者に完全にアクセスできる場合（ぼやけた線）-顧客がこの特権を「乱用」するのを止めることはできません。

2）開発者にストーリーを作成し、嘘をつくように条件付けする。

顧客に対処したことがある人なら誰でも、顧客に嘘をつくことができることが前提条件であることを知っています。5分で実行できる1行修正のバグがあります。カスタマーサポート担当者は、顧客の期待を管理するためのトレーニングを受けていました。解決するまでに最大3日かかります。

開発者として、顧客に直接対処しなければならない場合、技術的な問題を解決し、システムがスムーズに実行されるようにすることが主な仕事である場合、顧客をなだめるか欺く独創的な方法を考える必要があります。

3）履歴書が苦しんでいます。

ソフトウェアエンジニアからビジネスアナリスト/ ITコンサルタント/プロジェクト管理に切り替える場合を除き、履歴書には技術的な側面があります。

チーム間で交代する有償サポート作業は別の話です。

長所

1）ウィナーズウィニングの停止

自分の嫌いなことをする開発者は、コーディングをもっと感謝するでしょう。絶えず泣いているプログラマがいますか？それらを1か月間ホットラインに登録します。

はい、彼らはそうします。この質問を読んだとき、私は笑いましたか？私はこれがどのように質問であるかのようでした（OPを質問するあなたの権利を質問しているわけではありません）が、それは非常に修辞的です彼女の職務。それを避けることはできません。ほとんどの場合、あなたの機能領域だけでなく、一般的なITの面でも、最も技術的に責任のある人です。完全に回避するのは非常に困難です。