ソフトウェアエンジニアも技術サポートとして機能する必要がありますか？
ソフトウェアエンジニアも技術サポートとして機能する必要がありますか？つまり、企業がエンジニアにソフトウェアエンジニアと技術サポートの両方の帽子をかぶることを許可する場合です。エンジニアの時間の多くがテクニカルサポートに費やされている場合、ソフトウェアを作成する機能が削除されるようです。
これは、ソフトウェア会社であろうとなかろうと、ソフトウェア開発コンポーネントを自社の業務に組み込んでいる企業の典型的な問題です。私はいつもこれに苦労しています。
プロダクションサポートに関係する開発者
長所
- 戦闘「真空中の発達」症候群。ユーザーがアプリをどのように使用するかを知ることは価値があります。ようやくこれを若い開発者として見るまで、私は自分がどんなにくだらないUI開発者なのか理解していませんでした。私が気にしたのはコーディングだけで、設計、分析、ユーザーの視点ではありませんでした。
- 自分が思っているほど良くない開発者は謙虚になることができます（この利点が得られる保証はありませんが、一部の開発者は本当に気づかず、利己的で、頑固です）。
- 開発者はドメインに関する知識を得る。これは、開発者が最終的にビジネス分析フェーズ（存在する場合）で見落としているギャップを特定して埋めることができるようになる場合に重要です。
- 良いサポートはマーケティングのポイントです。うまくやれば、クライアントはそれを高く評価するようになります。そして、コミュニケーションスキルとドメイン知識を備えたバランスの取れた開発者は、これをうまく行うことができます。ただし、私は、アプリケーションがサポートを必要としないほどの高品質であることを望みます。優れた品質は、独自のカスタマーサポートの形態です（マーケティングポイントでもあります）。
短所
- 中断係数。これが、プロジェクト作業とサポート作業を混在させる最大の欠点です。プロジェクトはサポートに干渉し、サポートはプロジェクトに干渉します。プロジェクトは見積もりとマイルストーンの進捗状況に依存し、サポートは予測不可能であり、緊急の緊急性を伴う場合があります。プロジェクトはスケジュールベースで、サポートは中断ベースです。幸せな組み合わせではなく、開発者が対処するのは非常にイライラします。
- 全員がサポートに長けているわけではありません。アプリやビジネスの経験が浅い人、またはユーザーのアクセスからよりよく保護されるような性格またはコミュニケーション能力を持つ人は、サポートでうまく機能しない可能性があります。
- リソースの非効率的な使用。 Frank Sheararは、些細なサポートを行う開発者は、レベル1のサポート技術よりも費用がかかる可能性があるとコメントで述べています。
私の経験では、ほとんどの開発者はサポートを好みません。プロジェクトとサポートの両方の役目を果たしたので、私は共感できます。両方を同時に行う必要がある場合、サポートの緊急事態に対処し、プロジェクトの期限を延ばすために、緩和要因は多くの場合、通常は無給の残業です。プロジェクトマネージャーは、お金をかけずに日付を作ることを意味するので、無給の残業が大好きですが、開発者にとっては、それは単なる大したことです。
ただし、開発者が信頼性の高い直感的なシステムを作成するために優れた仕事をした場合、サポートが少なくなると私は思います。したがって、これは2つを混合するための奇妙な循環引数を作成します。あなたが両方をしなければならないなら、あなたがすべきことは、それを同時にすることを避ける方法を見つけることです。
開発者はすでに2つの帽子をかぶっていると思います。サポートは、コンピューターが接続されていないなどのささいな問題から開発を保護するために使用されるフィルターのようなものです。ただし、開発とサポートの間には密結合が必要です。バグの結果であると思われる正当な問題を抱えている顧客もいます。これらの問題をできるだけ早く整理するのを助けるのは開発の責任であるべきです。つまり、ある意味では、開発者は既にサポートチームの一員です...それをTier 2サポートと呼んでください。
Emphatically、no。
私たちは皆、あなたがしていることをやめなければならないことがいかに難しいかを知っています。 尋ねる 質問に答えます。ヘルプデスク用の電話に応答し、ユーティリティアプリケーションをいくつか作成しています。
5分ごとに電話を取らなければならないので、問題の解決に集中できません。問題を解決するために何ができるかを常に考えており、私が持つ可能性のあるソリューションを完全に実装するのに十分なほど長い間プログラミングに取り組んでいないため、どちらの仕事もうまくいくとは限りません。
繰り返しますが、私はどちらか一方の側面に集中できることがどれほど重要であるかを十分に強調することができませんでした。
開発者を第一線のサポートとすることは決してありません。中断の数と自分で繰り返す必要がある量により、ほとんどの開発者は [〜＃〜] rtfm [〜＃〜] と叫び、次の通話相手に電話を切ります。これはクライアントが必要とするものでも、開発者に我慢してもらいたいものでもありません。
カスタマーサービスのポジションには一定のルールがあります。激怒した発信者にとって、電話に応答する最初の人は間違っています。会社の社長、アプリの開発者、サポートマネージャーのいずれがいても問題ありません。クライアントが、何をしているかわからないかもしれない2人目の人物を取得すると、落ち着いて問題をより明確に説明できるようになります。
これは、優れた開発者を維持したい環境ではありません。 「なぜ私のカップホルダーはもう機能しないのか」を超えた特に難しい問題について、開発者がクライアントと対話することに価値はありますか？もちろんです。しかし、それは、サポートリクエストが第1層と第2層のサポートラインを通じて精査された後です。
それは会社に依存します。
私の仕事はまさにこのようにです。私はソフトウェア開発者ですが、私たちはかなり小さな会社なので、各開発者は通常、自分のソフトウェアをベースにした「非公式な」サポートの役割を担います。一部の開発者は、開発/出荷した製品の数、製品のバグの程度、および効果の大きさ）などのいくつかの要因に応じて、他の開発者よりも多くのサポートを行う必要がありますサポートされています。問題を解決するために必要なものを正確に顧客に提供できる場合、彼らは問題を可能な限り迅速に解決するためにあなたに戻ってきます。両刃の剣？はい。あなたは生産性の低下に苦しんでいますが、顧客は満足しており、顧客であり続ける可能性が高くなります。これは中小企業にとって重要です。
私たちはシステムサポートチームを持っていますが、私たちの仕事の性質上、ハードウェア関連の問題に対処する必要があります。個人的には、小さな会社では、この問題は想像できるほど破壊的ではありません。確かに、いくつかの重要な機能を試そうとしているときに電話を受けることになりますが、同時にカスタマーサービスが大幅に改善されています。彼らは、多くの場合、中古情報とサポートスクリプトを持つ誰かの代わりに、問題を解決する方法を知っている信頼できる声を持つことができます。そこに問題を解決できない場合は、バグの修正を実装するか、将来のリリースのために機能のリクエストを検討することを個人に安心させることができます。ソフトウェアのユーザーから直接フィードバックを得ることができるので、次のバージョンは、あなたが思っているよりもさらに良くなる可能性があります。
私はそれを考えたいと思います幸せな顧客はあなたの会社のより肯定的なイメージを作成します、それは通常より多くの顧客につながりますそれが、ソフトウェアエンジニアとして、テクニカルサポートが好きな理由です。
開発者はサポートの最後の行である必要があります。
ヘルプデスクとQA部門がお客様をサポートできない場合にのみ、私たちは煩わされることになります。それでも、優先順位付けされたバグ追跡システムを通過する必要があります。
それが本当に大きな問題であるならば、我々はそれを聞くでしょう。
コンピューターの技術サポートが何が起こっているのかを本当に理解している人にあなたをつなげたくないので、それ以上に苛立たしいことはありません。大規模なアプリケーション会社には、テクニカルサポートを担当するプログラマーがいることを願っています。
ソフトウェアを開発するために必要な才能とスキル、および第一線のサポートで効果的にするために必要な才能とスキルがあります。これらの才能に相関関係があることは知りません。
これは、電話サポートを行う能力に部分的に基づいて開発者を雇う必要があるか、または顧客を顧客の対応が得意ではなく、そもそもそれを行いたくないと思われる人々に顧客に直接話せるようにする必要があることを意味します。これは、丁寧な脚本を読んでいる濃いインドのアクセントを持つ男と話すよりも良いかもしれません。
また、あなたがその仕事を不愉快にすると（そして私が実際に第一線のサポートを楽しんでいる開発者を知りません）、あなたの開発者の何人かが去ります。これらは一般的に他の仕事をより簡単に得ることができるものです：つまり、良いものです。このプロセスが進むにつれ、才能のない人でいっぱいの店に行き着き、有能者が誰かからの最初の仕事のオファーを過ぎて滞在するのがさらに不愉快になります。
深刻な開発が行われる限り、頻繁な中断がある場合はそれを忘れてください。私の妻は、開発とユーザーのサポートを同時に行うことを期待されていることについて多くの不満を述べています。
私の最後の仕事はまさにこれでした。既存のシステムをサポートし、必要に応じて新しいシステムも作成しました。それは完全な災害でした。私は常に中断されます。開始されたプロジェクトが完了するまでに長い時間がかかるため、私の士気は非常に低かったです。また、時間外サポートのために追加料金なしでポケットベルを持ち歩かなければなりませんでした（これは医療分野でした）。解決策（当時、私が上司に提案したもの）は、技術サポートの最前線に立ち、ソフトウェアのバグであれば開発者に転送することでした。言うまでもなく、私が1年半しか続かなかったのは、ようやくすべてのより良い開発作業に出発するまででした。
時々、確かにそうです。多くの場合、顧客に直面すると、ほとんどの人、特にプログラマーには欠けている視点が与えられます。ユーザーが実際に製品を使用する方法、または実際に考える方法は、ビルダー（エンジニア）が行う方法から遠く離れていることがよくあります。
開発の実際のタスクを中断しないように、それは短い定期的なスティントのためのものであるべきです。
新しい開発者であるか、ドメインと顧客ベースに精通していない場合にのみ、これを行います。永続的なものにするのは良い考えではありません。
開発者をサポートとして使用することは適切ではないと思いますall当時、開発者にアプリケーションの初期サポートを実行させると言うべきことがあると思います。これには、具体的には勤務時間外のサポートが含まれます。また、定期的に自分のアプリの営業時間外サポートをスケジュールすることもできます。
特定の設計上の決定やショートカットが、人々がコードをサポートおよび保守する能力にどのような影響を与えるかを理解させるための複数の3AM呼び出しのようなものはありません。
その多くは会社にかかっていると思います。あなたの典型的なBigCo会社は通常、開発者を隔離するためのサポートスタッフを雇う余裕があります。一方、3人のスタートアップtotalには、個別のサポート担当者を提供するためのリソースがない可能性があります。
（会社の規模やリソースに関係なく）最善の一般的な戦略は、サポートチームを使用して、ぶら下がっている果物と最も一般的な問題（「オフにしてからオンにしてみましたか？」）をトラブルシューティングすることです。エンジニアは、システムがどのように機能するかについての知識と、より開発者向けのサポート（API、開発者ツールなど）を必要とする、よりトリッキーな問題について顧客と協力する必要があります。サポート担当者を「連絡係」として機能させることもできますが、通常はそれよりも問題が多いと思います。
上記の理由から理想的にはありませんが、プロジェクトの初期段階ではそうです。開発者は、ビジネスで期待される迅速な解決策を提供できるため、ソフトウェアの継続的な改善をサポートできます。私はサポートをスマートに提供する開発者を評価します。例としてより正式なフルタイムのサポートチームに分析スキルを貸す開発者と、サービスと協力の精神を示すようにビジネスに答える開発者です。ただし、この成功の鍵には、短期的な役割だけでよいものから開発者を迅速にオフロードするための経営陣が第1レベルと第2レベルのサポートを認識して正式化することが含まれます。開発とサポートの両方のコツを示す開発者は、第3レベルのサポート、またはサポートスタッフのサポートとして育成する必要があります。つまりすべきは時間に依存し、才能と欲求に依存し、効果的に管理されます。
私自身の関心は、困難なサポートの質問に答え、経験から学んだことを利用してサポートの必要性を全体的に減らし、エンドユーザーとプライマリサポートの両方に利益をもたらすことです。
給料の良い会社に入社したとき、私はこの罠に入りました。インタビュー中に、70％の開発と30％のサポートがあると言われ、申し出を受け入れました。それは私が現在取り組んでいる会社や環境かもしれません。しかし、実際には90％がサポートされ、10％が開発されています。それから数年が経ち、開発の手がかりを失いました。申し訳ありませんでした。
しかし、私はあちこちで多くの新しいテクノロジーとフレームワークをコーディングすることのグリップを失ったように感じます。今、どこから始めればよいかわかりません。私は準備を続けていますが、これらのhelloworldの例は、いくつかの実用的な経験を得るには十分ではなく、私の知識と経験を更新することは本当に難しくなっています。家族の責任のため、仕事をやり直すことすらできません。
残念ながら、私は行き詰まっています。
気に入らない、または興味がない場合は、役割を受け入れないでください。