キャリアオプションとしてサポートを「販売」する方法[終了]


9

さまざまなプロジェクトに取り組む開発者を雇うのは比較的簡単です。

問題はプロジェクトが終了したときに発生しますが、まだサポートする必要があります。

私たちは人々をサポートチームに参加させるために本当に戦います。それは行き止まり、キャリア制限、退屈、セカンドクラスなどと見なされています。

現在、これを回避するには、プロジェクトチームにチームの一部をしばらくの間サポートチームに割り当てさせます。割り当ての一部は、サポートチームが理解できるようにプロジェクトの「ブレインダンプ」を実行することです。これは、割り当てが一定期間のみである限り機能します。

フルタイムでサポートに従事する人々を雇おうとすることは問題です。用途は少なく、口径はそれほど高くありません。

(ただし、財政的な現実としては、企業にとってサポートは非​​常に有利であり、評判を得ると、元の開発に関与していなくても、他の企業からサポートを受けるよう依頼されます。)


8
「それは行き止まりで、キャリアを制限し、退屈であると見なされています...」-それは通常そうであるためです。開発者は多くの場合クリエイターであり、定義上、サポートは何も作成しません。
Steven Evers

あなたが意味するようにサポートを定義できますか?これにはバグ修正またはそれまでのすべてが含まれますか?
ジョンホプキンス

バグ修正が含まれます。
nzpcmad

優れたフルタイムのバグ修正プログラムはまれですが、存在しています。あなたは会社全体として非常に魅力的であり、多くの正直な面接を受けなければなりません(そうでなければ多くの人はすぐに去るでしょうから)。
ジョブ

回答:


16

しない

私にとってここでの最良のオプションは、開発者をサポートと非サポートに最初から分離しないことです。私見3つの主な理由があります。

  • サポートするのが難しいものを書く人は、サポートする必要があるまで学習しません。
  • サポートのみを行う人々は、将来の作業を妨げる場合でも、通常、エラーを修正する際の抵抗を最小限に抑えます。
  • 別々のサポート開発者を雇うことにより、新しい開発でスケジュールを維持することで理論的に時間を節約することは、指示を与えたり、作業を繰り返す必要があることで常に消費される以上のものです。

開発チーム内では、メンテナンスタスクを持っている人や、メンテナンスタスクを新しいチームメンバーのトレーニングの場にするアプローチを取ることができますが、ポジションの長期的な目標としてそれを売り込もうとすると、魅力的なものになります。あなたに胸焼けを与える人々または間もなく彼らの道を行く人々。

100%のサポート開発者の役割から抜け出すための明確な道筋が常に必要であり、優れた人々の関心を維持するために、特定の割合の新しい開発作業が必要です。

あなたはその役割でいつまでも幸せな種類の人々を引き付けたくはありませんし、そうでなければ良い開発者にその役割を引き受けて、彼らに考慮されないような報酬を提供しない限り、それを長期間維持するように説得することは決してありません。キャリアの動き。


これは、プロジェクトAにチームがいるという基本的な問題を解決しません。プロジェクトが終了し、チームが分割されます。プロジェクトAには問題があります。それを修正するには、他のプロジェクトから離れる必要があります。したがって、サポートチームのアイデア。
nzpcmad

3
常にその制約があります。別のサポートチームがいる場合でも、ドキュメントとハンドオフ、および第2層のサポートを行う元の開発チームメンバーのサイクルを失っています。私見それはずっとクリーンであり、この失われた時間が常に追いつけようとするだけの2番目のクラスの開発チームではなく、今後のプロジェクトの見積もりに組み込まれる単なる指標である場合、スタッフ全体にとってより魅力的です一流のチームによって作成された問題に取り組みます。サポート開発アプローチがうまく機能するのを見たことがありません。常にスタッフの解約が発生します。
ビル・

8

開発者にとってサポートジョブを楽しく価値あるものにします。

私は次の理由でサポートをするのが大好きです:

  • 私は世界中の人々と話します。そんな友達がたくさんできました。数年前、私の顧客の1人が私を彼の結婚式に招待しました!私は以前、自分のオフィスに世界地図を配置し、ピンを配置していた。
  • サポートは、あなたの仕事の満足感得るための最良の方法です。ユーザーを幸せにすることは、あなたを本当に幸せにすることにもなります。
  • 苦情はあなた自身を改善するための有用な方法です。私は苦情を真剣に受け止め、ほとんどの場合、怒っている人を幸せな顧客/ユーザーに変えて、最終的にはその言葉を広めることができます。
  • 顧客/ユーザーが何を必要としているかを理解するのに役立ちます。その後、より良いソフトウェアを構築できます。

それはほんのいくつかの理由です。

サポート自体については、管理しやすいプロセスを実装することをお勧めします。

サポートケースを取得すると、次のことを行います。

  • 再現可能なバグの場合は、バックログに追加して、そのIDを顧客/ユーザーに提供します。また、お客様/ユーザーのIDを使用して、解決策を通知し、個人的にリリースします。これは彼のメールを直接収集すれば簡単です。
  • ソフトウェアの使用に問題がある場合は、ドキュメントを改善する機会としてこれを利用します。回答は、後でデータベースに追加するナレッジベースの記事のように記述されます。書くのに3倍の時間がかかりますが、後で繰り返すことはありません(ほとんどのユーザーはKBでの閲覧を好みます)。
  • 機能のリクエストの場合は、ユーザーを製品の所有者に直接連絡します。これは非常に貴重です。もちろん、uservoice.comのようなシステムを使用していますが、ユーザーと直接話す方がはるかに優れています。
  • 苦情の場合は、プロセス外で管理するように努めます。苦情が重要であると見なされることを好む人々(苦情が些細な場合でも)。

顧客が本当に望んでいるものを見つけるための最良の方法としてのサポートの+1 。
AShelly

3
「サポートデベロッパー」としての役割について言及するのではなく、「リファクタリングエンジニア」のようなやる気を起こさせるものを使用し、彼らが扱っていることや改善していることについても創造的になるように彼らを励ます。
Nick Josevski、

@Nick Josevski-間違いなく、既存のシステムに改善/改良を開発する自由を与えることは、「サポート開発」が「壊れたときにそれを機能させる」だけではないことを意味します。私の最初の開発の役割は、サポート/メンテナンスでした(ただし、実際のプロジェクト作業に初めて移ったときは、それをたくさん楽しんでいました)。
Adam Luchjenbroers、2011

@Pierre 303、私は誰もがあなたのようではないのではないかと思います。私は内向性対外向性が方程式の一部であるに違いない。
ジョブ


3

ビルドよりもサポート開発者に5または10kだけ支払って、開発者を忘れないのはなぜですか?

役割をサポートするための追加のプレミアムを添付することにより、「顧客連絡」と「量産コードの保守」の追加の課題を認識して; あなたはモチベーションを高めるだけでなく、より重要なことに、役割はより名声を持っていると見なされます。結局、より高い給与はより重要な役割を意味しなければならず、それがそうでない場合でも、そのように受け入れられます。


これが保持を改善するとは思いません。確かに、より多くの人々がサインオンするでしょうが、彼らがいくらかの現金を銀行に預けたら、彼らは去ります。いくつかの研究では、お金が本当に重要なのは、それがない場合だけです。「知識労働者」にとっては二重にそうです。
Steven Evers

3

サポートが二流の仕事だと思うなら、おそらくそのために人を雇うのに苦労するでしょう。それをキャリアを制限する行き止まりの仕事として扱うならば、あなたは良い志願者を得ることができません。

サポートは通常、新しい開発ほど楽しいものではありません。開発チームとサポートチームが分かれている場合、サポートチームは開発によって得られたものを採用する必要がありますが、多くの場合、面白くありません。(私はかつてR&Dが何かクールなソフトウェアを私たちに渡す場所で働いていましたが、通常は生産品質になるように再設計する必要があり、政治的な理由でそれを行うのに十分な時間がありませんでした。それはそうではありませんでした。楽しい。)

サポートが本当にビジネスクリティカルである場合は、そのように扱う必要があります。個別のサポートチームを設けることを強く求め、優れたサポートチームを用意することが重要な場合は、これらの問題に対処する必要があります。キャリアパスがあることを確認してください。サポートから得ているお金を、一部は自尊心のために、一部は他の人にその価値を実感させるために、一部は履歴書にその活動の金額を表示できるように宣伝します。標準を確立し、プロジェクトが開発からサポートに移行する準備ができているかどうかについて、サポートチームが何らかの情報を入力できるようにします。仕事は面白くなく、おそらくもっと重要なので、彼らにもっとお金を払ってください。(通常、「必要な応募者を見つけることができない」と翻訳されていない場合は、「必要な応募者を取得できない」と不平を言うマネージャーにもっと同情します。)


1

一般的にサポートしていることは悪いことだと私は同意しますが、多くの開発者は実際にソフトウェアを記述していなくても、プロジェクトの「所有権」に伴う名声を実際に享受する可能性があります。そのプログラマーはそのプロジェクトの代表者になり、彼らは本当にシステムの非常に貴重な専門家になります。私は主に私が働いている会社の新しい開発に携わっていますが、実際に有能な同僚の多くは、最もミッションクリティカルなソフトウェアのメンテナンスで非常に尊敬されています。結局のところ、現在サポートされているソフトウェアは、おそらく現在収益を上げているソフトウェアです(手元にいる鳥は、茂みの中では2匹の価値があります)。
支持者が準標準のプログラマーにとって恐ろしいダンジョンの仕事だとは誰もが思っているわけではない、と私は言っています。


1

いくつかの考え:

1)それは行き止まりとキャリアの制限として見られていると言います。これが当てはまらず、人々が他のこと(開発、プロジェクト管理、チームの運営)に進んでいる場合は、使用できる例があると思います。例がない場合は、それが行き止まりでキャリアを制限していることを受け入れなければならず、これらの問題に対処する必要があります。

2a)サポートにバグ修正が含まれている場合、なぜそれらが分離しているのですか?誰かが最初からひどくコード化した場合、あなたは彼らの混乱を他の誰かに与えて整理することによって彼らに何を教えていますか?さらに、サポート開発者が開発者ほど優れていない場合、どのようにして開発者が正しくできないものを修正することを期待できますか?真剣にルールを書いて、修正するべきです。

2b)サポートにバグ修正が含まれていない場合、それらは非常に異なる仕事であり、異なるスキルを強調します。開発とクリーニングの間のクロスオーバーについて心配する以上に、ここでクロスオーバーについて心配する必要はありません。

3)あなたはそれが会社にとって有利であると言った-そしてそれを関係する人々のために有利にする。これは、より良いお金、より良いトレーニング、より良いキット、そして彼らが本当にこのことを本当にうまく行うために必要なすべてを彼らに与えることによるかもしれません。利用可能なお金がある場合、それを素晴らしい仕事にします。

あなたの投稿を読むことの問題は、あなたがそれが良い仕事であると信じていないように見えることです。それが本当なら、それを一体として売ることができないのも不思議ではありません。


0

サポートは難しい仕事です。一日中人々が不満を言うのを聞くのが好きな人はいません。良い人を見つけるには時間がかかるかもしれませんが、それができたら、それを維持する必要があります。

  1. 優れた人々を維持するために、業界のレートをはるかに上回って、十分なお金を支払う
  2. 良い職場環境を提供します。昼食や飲み物を手伝う仕事など、ささいなことを助けます
  3. サポートスタッフ全員を小さな騒々しい部屋に詰め込まないでください

0

zappos.comは、良い会社に勤めているときに仕事がくだらない必要はないことを示していると思います。サポートの最悪の部分は誰かを助けることができないことです。サービス契約でユーザーをめちゃくちゃにしたり、すぐには修正されないバグの多いソフトウェアを出荷したりすると、サポートはうんざりします。彼らは問題の解決策を見つけるように励まされる必要があります。プログラミングのようなものです。


0

私は大学を卒業した最初の会社を数年間サポートしました。数年間サインアップさせたのは、

  1. ソフトウェアエンジニアになるために必要なキャリアパス。
  2. 会社の主要言語をブラッシュアップする時間が必要でした(Fortran、年頃1989年)
  3. 私は結婚していなかったので、会社や仕事が気に入らなければ辞職することができました。

0

開発とサポート(分割された役割)の混合はどうですか?すでに述べた理由(開発者!=製品サポート担当者)のために、それでも賛同を得るために苦労することになると思います。しかし、製品が内部テクノロジの幅広い理解に依存している場合、おそらく80%の開発、20%のサポートは、適切なトレードオフになります。または、新入社員が製品に関する正しい情報を確実に入手できるようにするための何らかのメンタリング/シャドウイング。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.