私の経験では、ソフトウェア開発者は複数の帽子をかぶって、複数の役割をさまざまな責任で果たす傾向があります。コーディングだけでなく、SQLの作成、ユーザーインターフェイスの設計、データベースの設計、グラフィックスの操作、さらにはQAテストまで。
主な役割がソフトウェア/コードを書くことである場合、開発者はどんな役割を引き受けてはいけませんか?何かありますか?
この質問の意図は、開発者が別の役割を満たすことができないからではなく、実際に追加の役割を持つことが主な役割に対して機能するか、または主にプログラムを行わない人の献身的な役割である。
システム管理者。ソフトウェアの開発とITインフラストラクチャの処理は、部外者のように見える2つの異なるスキルセットです。 (それはすべて、コンピューターにぶつかるだけですよね?)小さめの会社にとって、コンピューターの男にオフィス内のすべてのマシンの責任を負わせたいという誘惑は非常に強くなります。
あなたが実際に両方の帽子を着用するスキルをお持ちなら、素晴らしいです。しかし、それは人々が気づくよりもはるかに長い時間のシンクになる可能性のあるものの1つであり、あなたが行くにつれて独学している場合、あなたはあまりうまくやっていない可能性があります。
あなたは雇用主が求めるどんな帽子でも着ます。それがあなたをチームプレイヤーにする理由です。それがあなたをProblem Solverにする理由です。
人々は、「開発者」または「建築家」または「アナリスト」であるという考えに夢中になりすぎます。ねじ込みます。あなたは問題解決者であるべきです。コードは単なるベルトのツールです。
問題解決が時代遅れになることはありません。
私の雇用主が私に技術サポートやコンピューターの構築を望んでいるなら、そうしてください。彼らは開発者の給与を考慮して彼らのお金を浪費していると思いますが、それは彼らのビジネスです。私は問題を解決するためにここにいます。それはできるけど、やるよ。そして、一定の時間が経過した後、自分の才能が無駄になったり、仕事の満足度が望みどおりにならない場合は、別の仕事に進む権利がほとんどあります。
しかし、基本的な質問に-あなたが身に着けていない帽子はありません。一体、彼らがあなたにコーヒーを取ってきて欲しいなら、それをしてください。彼らの問題を解決します。変更を希望する場合は、別の仕事を見つける権利があることを知っているだけです。
テスター!
テスターが必要な場合は、テスター学校から直接送ってください。
プログラマーはテスターであり、非常に賢いので機能するはずなので、テスターがいなければ、すべてがすぐに機能することを期待します。
私はドッグフードが良い考えではないと言っているのではありません。私がプログラマーになった今、テスターは非常に重要だと思います。
オフィスのハードウェアの問題については頼りになる人になることに注意する必要があります。これには、PCのトラブルシューティング、サーバー管理、バックアップ、さらには電話システムの作業も含まれます。私は以前のハードウェアの経験について言及するのを間違え、結局私のハードウェア/トラブルシューティングの仕事は私のプログラミングの仕事とひどく矛盾しました。
プログラマーだけが自分のコードのテスターであってはなりません。
開発者は、一連の仮定を使用してコードを記述します。テスターが同じ一連の仮定を持っている場合、テスターはそれらの境界外で予期しない機能を実行せず、多くの問題が検出されないままになります。
さらに、前進するために、開発者は物事を壊そうとする動機があまりありませんが、テスターは(おそらく潜在意識レベルで)います。
これは、開発テストが役に立たないことを意味するものではありません。まったく逆です-優れた開発テストにより、テスターはより深い問題の発見に集中できます。ただし、開発者向けテストは、専用のテスターにとって代替ではありませんです。
一般に、ほとんどのプログラマーがユーザーインターフェイスのルックアンドフィールを開発するべきではないというのが私の経験です。私は確かにUIを開発することができます(プロトタイプまたは概念実証を作成するときにUIを作成することがよくあります)。これはヒューマンファクターの担当者に任せてください(私たちの小さな会社ではグラフィックアーティストであり、画面のレイアウトも行い、ほとんどのマニュアルやパンフレットを作成しています)。
また、開発者はQAテストを行うべきではありません-それはQA部門の仕事です(私が働いている会社は組み込み医療機器を作っているので、これはテストが別の部門によって行われる必要があります)。
一方、開発者がデータベースを設計したりSQLを作成したりできない理由は、彼らがそうするバックグラウンドを持っているのであれば、私にはわかりません-私は何度も行ってきました。
2つはすぐに考えることができます。
CSS/UI開発はプログラミングの「領域」の外にあると言えますが、私の経験では、それは今日必要なスキルです。あなたはテーブルから離れて、それを正しく実装するために誰かに頼ることはできません。デザインを実装したり、新しいデザインを処理するようにコードを変更したりするのは好きではないかもしれませんが、それは仕事の一部です。
クエリの記述は問題なく、Q/Aテストは問題ありません(そしてIMO すべきはプログラマーの仕事です。サーバー管理は少し灰色の領域です。プロジェクトの規模や、専用サーバー管理者がいる場合は、プロジェクトが必要な場合と必要でない場合があります。
テクニカルサポート
私の一日の多くは、テクニカルサポートの電話を受けることで無駄になっています...
人気のあるものは次のとおりです。
彼に自分を管理させる任意の役割。小さなチームでは、多くの場合、シニア開発者の1人をプロジェクトマネージャーにする傾向がありますが、彼をプログラマーとしてチームに留めておく傾向もあります。この男はプログラマーとして基本的に管理されていないため、これはあらゆる種類の問題を引き起こします。すべてのタスクを他のチームメンバーに委任する代わりに、彼は多くの場合、特に最も困難なタスクを自分自身に割り当てるように誘惑されます。したがって、最も困難なタスク、つまり問題を引き起こす可能性の高いタスクは、プログラマーとして50%しか利用できない人に割り当てられ、そのため誰にも報告されません。他のチームメンバーがお尻を蹴るのではなく、提供できない場合は、プロジェクトマネージャーとしての成功に責任があり、それを達成するための最も安全な方法は自分で行うことなので、彼は自分のタスクを実行しようとします。 、そうではありませんか?
開発、デプロイ、維持に手が足りず、トレーニングを受けておらず、大きな変更について最新の状態になっていないものに対するテクニカルサポート。私の仕事の一部は、クライアントがインターネットが機能していない理由について電話をかけることでした。私はそのビジネスの半分を扱っていないので、彼らに何の役にも立たない。
テクニカルサポートを行う必要はなく、問題はありません。物事を開発しようとしている間、それは秘書/技術サポート人です。
人々が一日中不平を言ったり、彼らに何も伝えられないことに耳を傾けなければならないことはかなりの負担になります。私はこれを絶対に回避することをお勧めします。
売上高。
一部の貧弱なバガーはそれを行う必要がありますが、開発者であってはなりません。
年をとるにつれて、開発者が独自の配置を行わないのが最善であることに気づきました(私はこれを一本の爪でやりました)。選択権を除いて、本番データベースに対する権利を持たないでください。コードのバグが大幅に減少しました(変更は製品でのみ行われたため、同じことが複数回発生することはありませんでした。その後の開発者による展開で再度上書きされたため、急いでリンスして繰り返し、製品でのみ修正されました)。デプロイを他の人に提供し始めなければなりませんでしたが、デプロイメントが適切ではなかったため、本番環境での迅速な修正を許可されていませんでした。さらに、「テーブル内のすべてのレコードを変更するハイライトされたwhere句のない更新」の問題が発生するのを防ぎました。
アーティストおよびユーザーインターフェイスデザイナー。
ほとんどのプログラマーはアートワークが苦手ですが、企業はアーティストに製品の画像やアイコンを描くためにお金を払う必要はなく、単に「プログラマーアート」を使用するだけです。 (Windows Vistaまでは、これがMacとPCを区別する最も明白な要因でした。Macは美しくフレンドリーであり、PCは目障りでした)
同様に、多くのプログラマーはユーザーインターフェイスにあまり関心がなく、主にコードに関心があります。彼らは単にメンバー変数の内容をいくつかの編集可能なフィールドに直接公開します。多くの場合、フォーム上のボタンとフィールドを配置する場所は気にせず、これで十分であると想定して、ソフトウェアが使用できなくなります。 (iPhoneが登場して実際に使いやすい電話UIを作成できることを彼らに示すまで、携帯電話業界全体がこれに非常に有罪でした)
ロータスノーツは、プロのデザイナーがプログラマーの手助けをしてくれない場合に、これらの両方がどれほど悪いものになるかを示す素晴らしい例です。
全体的なテストとテスト計画の作成。真剣に、皆さん、私は自分のテスト計画を書くことができますが、それは私がものを書いている間に私が行った誤解、誤った仮定、および認識の間違いを製品に焼き込むことを意味します。私が働いていたある会社について私が嫌っていたのはそれだけだった。私が今いるところでは、少なくともこのことをキャッチできるコードレビューがあります。
合理的に扱うことができ、快適である以上の「帽子」を着用しないでください。開発者がやるべきではないことを言って穴を開けようとする---[〜#〜] a [〜#〜]または- [〜#〜] b [〜#〜]は、優れたUIデザイナーが見過ごされる可能性があることを意味します。
結局のところ、誰もがさまざまな長所と短所を持っていることになり、優れたマネージャー/スーパーバイザー/チームリーダーは、彼らのために働いている人々に才能が適切に使用されていることを確認するよう指示する最良の方法を知っているはずです。同様に、UIの設計やエンドユーザーへの対応に慣れていない場合は、チームに知らせて、その領域での役割を最小限に抑えることができます。ただし、別の領域で追加の作業を行う準備ができている必要があります。
また、あまりにも多くの帽子をかぶっている場合(プログラマー、UIデザイナー、テスター、ビジネスアナリストなど)、それらのいくつかではうまくいかないか、またはあなたは燃え尽きてしまいます。処理できる帽子の数を把握し、そのレベルのワークロードを維持するようにしてください。
それを超えて、開発者がその役割でExcelを使用するスキルを持っている場合、開発者が着用してはならない「帽子」は本当にありません。
私は次の場合に限り、私に投げつけられた仕事を引き受ける傾向があります。
このようにして、私は主に上司に対して保険をかけられ、誰かが間違った場合は少なくとも修正可能です。
「デザイナー」または「クリエイティブ・ガイ」。アプリケーションのインターフェースのモックアップを無邪気に組み立てることから、次のオンライン広告キャンペーンのためのマーケティングテキストを書くこと、または「正しい」青の色合いについてx_xを知る前に無限のディスカッションまでを行います。
開発者は状況(顧客、所有者など)の利害関係者であるため、意味のある仕事を期待する権利があります。私の意見では、それはあなたの strengths で働く機会を意味します。
したがって、開発者は、エネルギーを与えず、個人の成長に貢献し、最高のパフォーマンスにつながる帽子をかぶるべきではありません。そして、これらのことを行う「帽子」から時間を奪ってください。
自分のコードをテストしているのは1人だけではないことを除けば、帽子をかぶっている開発者にとって意味のある作業であれば、どんな「帽子」でも大丈夫だと思います。
ストローが付いている側面のビール缶が付いている帽子。捕まったら悪い考えです。
編集:
これは私が嫌う帽子ですが、それは大きな報酬です-これが壊れるかどうかはすべてあなたのせいだと私に言っている大きな兆候です... -地下に戻って...いい子...それだけです。
非難の帽子。