/写真Sistema Bibliotecario Vimercatese CC
ほとんどすべての大規模な組織は、スタッフにソフトウェア開発者を雇用しています。 ただし、ITに関連するビジネスに直接関与しているのはそのうちの3分の1だけです。 しかし、彼らが働く場所に関係なく：製薬会社、教育または広告の分野では、彼らはプログラマーのままです。
チームワークは責任あるタスクです。この場合、人々は自分自身だけでなく、他の人々にも責任を負い、コミュニケーションを取り、助け合うからです。 どんなに些細なことであっても、人々の間の生産的なコミュニケーションの鍵は常に礼儀正しさと相互尊重です。 ただし、同僚、顧客、「所有者」、またはプロジェクトマネージャーである場合、開発者やテスターとの会話では、たとえそれらが丁寧で正しいように聞こえても、フレーズのリストはまだあります。
1.「すぐにテストを終了できますか？」
テストは、重大な欠点を見逃さないように、慎重かつ慎重に実行する必要があります。 優れたテストは、高品質の製品の鍵です。 もちろん、プロセスを高速化するツールがあります（ここにStack Exchangeの居住者が提案するテスト自動化のチュートリアルがいくつかあります）が、自動化されたテストでさえも維持し、常に修正する必要があります。
理想的には、テストは製品の設計段階から始まり、リリースまで続き、デザイナーと開発者はテスターと密接に協力します。 あなたの会社が違うやり方をしているなら、おめでとう、あなたは遅延、エラー、予算不足のレシピを学んだ（テスターが聞きたくないいくつかの事柄がある）。
2.「バグレポートを読む時間がないため、問題を一言で説明してください」
テスター（少なくとも良いもの）は、バグレポートのコンパイルに多くの時間と労力を費やし、エラーを再現するために必要なすべてのステップを書き留めます。 リーダーまたは開発者のこの不注意な態度は、テストエンジニアにとって時間の無駄だけでなく、他の深刻な問題にもつながります。 常にバグレポートを読んでください！
このアドバイスを過小評価しないでください。一度そのようなことを言う無謀さを感じたら。 当時、私は若い専門家であり、チームにそれほどの重みはありませんでした。 当然、私は2つの大事な言葉を聞きましたが、バグの本質についてではなく、愛する人について自分自身に...テスターとの通常の関係を回復するのに少なくとも1週間かかりました。
3.「バグがないことを約束してください」
テスターの役割は「品質管理」ではなく、「品質を達成するための支援」です。 テスターのタスクは、製品がエラーなく実装されていることを検証することではなく、会社の特定の要件を満たしている（または満たしていない）ことを確認することです。
ビジネスには「約束を少なくし、より多くを行う」という格言があります。そのため、100％のコードカバレッジを追いかけるべきではなく、テストの品質に集中する必要があります。
贅沢な約束を営業部門とマーケティング部門に任せてください。 現実に焦点を当てた製品をテストします。 ところで、QAトピックには注意が必要なポッドキャストがいくつかあります 。
4.「そのままにして、自分で仕上げます」
このエラーは常に発生します。 タスクをより速く完了するために、開発者が自分で問題を理解するのを待たずに、すべてを自分の手に委ねることがあります。 これをやめることをお勧めします。 メンターとして行動し、スペシャリストを訓練して、スキルが会社とともに成長するようにしてください。 時々これは非常に不便に思えるかもしれませんが、将来このアプローチはあなたを大いに助けます。
優れたリーダーは、まず第一に、自分自身の代わりを育てることができるという点で際立っています。 従業員のために全力を尽くすと、従業員は何も学びません。 プロジェクトの所有者は、今後の状況を考慮する必要があります。 明日病気になったらどうしますか？ チームが単独で問題を解決できれば、悪いことは何も起こりません。
ただし、シニア開発者が多数の後輩のメンターである状況を回避することが重要です。その理由は、シニア開発者には他のタスクの時間がないためです。 そのような場合、メンタリングに関与し、複雑な問題についてのみ上級同僚に連絡する仲介者を任命する価値があります。 また、独自のドキュメントとトレーニングコースを作成するのに適したソリューションです（ここでは、実用的なヒントをいくつか紹介します ）。
重要 ：「おいしい」タスクや興味深いタスクを部下と共有してください。 このため、彼らはあなたを愛しています。
5.「ちょっとした質問があります...」
フレーズは最高ではありません。 質問が本当に短いことが判明したとしても、その答えはそうではないかもしれません。 同僚があなたに詳細に答える時間があるかどうか（今、または将来）から始めるように頼んでみてください。 対談者に即時の回答を拒否し、将来的に自由時間を割り当てる機会を与えます。
緊急のビジネスの場合、このルールは無視できますが、あまり頻繁に行わないようにしてください。 「オオカミ！」と叫ぶマネージャーになりたくありません。
6.「帰宅しました」（プロジェクトマネージャーを指す）
つまり、プロジェクトマネージャーの主なタスクは、作業の進行状況を監視することです。 プロセスが停止すると、従業員はエラーのために矢印をあきらめるかシフトします。PMは作業に入り、状況を理解し、前進する方法を見つけます。
チームと連帯することが重要です。 彼らと時間を過ごす。 開発者は、重要なプロジェクトをできるだけ早く終了するために長引きましたか？ また、適切な場所にいる必要があります-あなたの人々の士気を低下させないでください。 チームの強みは、団結、サポート、敬意です。 難しい瞬間に開発者を運命に任せないでください。
7.「ここで彼はあなたよりも速くそれをするでしょう」
それぞれが独自の速度で動作し、独自の長所と短所があります。 誰かがタスクを迅速に実行し 、誰かが考える時間が必要です。 ただし、多くの場合、速度は品質とコストの反対です。
作業の速度ではなく、タスクを完了するのにかかる時間を「 予測 」 する機能に注意してください。 主なことは、同僚が自分の能力をどれほど客観的に評価するかです。
8.「私は、長い間コードを書いていないようです」
プログラミングでは、コード行の作成に必要な時間は宣言されていません。 書いたばかりの関数は再考するのに時間がかかることがあるので、開発者が何時間も何もしていなかった場合、彼は眠りに落ちることはありません（そのような可能性はありますが、非常に小さいです）、彼はフォーラムやディレクトリで情報を検索したり、コードを変更する必要があります。
9.「一日中何をしているの？」
前の段落から生じるテーマ。 優れたプログラマーは、「どうやってXを作るのですか？」ではなく、「どうやってXを良くするのですか？」 同時に、開発者の時間の95％は、ソリューションを確実に実装し、現在のアーキテクチャと調整する方法について考えることに費やされています。 一日の残りはコードを書いています。 まあ、時々、ピンポンでさえRedditやHabrなどのニュースサイトを読んでいます。
人が数時間コードを書いていない場合、これは彼が何もしていないという意味ではなく、おそらく、彼は美しく有能なソリューションを探しています。 この記事を読むことをお勧めします。これは、プログラマーの作業を「外観」だけで評価する価値がない理由を説明しています。
10.「生徒でもこのタスクを実行できます。テンプレートを取得するだけです」
「生徒」に重要なタスクを与えたので、すべてをやり直す必要がある場合、2倍の費用を払う危険があります。 私たち自身の経験から、1cloudでは、顧客やマネージャーが私たちの主観的な経験に基づいてタスクの複雑さや開発の人件費を評価すると、開発者は非常に悩まされると言うことができます。 同時に、多くの場合、ヘッドは開発に関する専門知識を持っていませんが、開発者に評価を課そうとします。
一般に、開発のタイミングと複雑さを評価するときは、ずさんなフレーズは避けてください。 たとえば、開発者自身が表現する「これはささいなタスクで、最大数時間...」というフレーズは、タスクが実際に迅速に実行される可能性が高いことを示しています。
そのような判断がマネージャーまたは顧客から来た場合、不快な効果が発生します。開発者にとって、タスクを「些細な」と呼び、顧客が事前に自分の仕事を減価しているように思われるかもしれません。 そのため、人件費の評価に開発者とテスターを巻き込むことを忘れないでください。彼らがこの仕事またはその仕事をどれだけ早く行えるかを決めようとしないでください。
11.「これを見て、急がなければならない...」
プログラマの仕事は、芸術の人々の仕事に匹敵します。 プログラマーはアーティストとしてタスクに集中し、非常に複雑な画像を念頭に置いています。 「緊急」行為で彼の考えを中断すると、彼はストリームから「抜け落ちます」。 研究によると、人は集中状態に戻るには少なくとも15分必要です（ストリームでの作業方法に関する記事を読んでください）。
マネージャーは、朝と夕方にタスクを配って完成した結果を受け入れるように作業を調整し、再び昼間でチームの気を散らすことなく、全員が自分のペースで作業できるようにする必要があります。 同僚に仕事中の沈黙を確保する必要があります[そして、それはむしろ、致命的な沈黙やヘッドフォンで音楽を聴くことを禁止することではなく、迷惑な会話がないことについてです]-仕事の効率はずっと高くなります。
12.「リファクタリングなし、今日は製品が必要です！」
コード内の「クランチ」が多ければ多いほど、それを好むプログラマーが減り、特に書き直しが許可されていない場合、そのコードで作業する必要が少なくなります。 コードベースの状態を監視しないと、「 ダート 」が多くなり、ハックを使用して変更を加える必要があります。 これは、プロジェクトの崩壊につながります。
コードでの作業は、ゲームの「ジェンガ」を連想させます。プレイヤーが交互にタワーのベースからブロックを取り出し、それらを一番上に置くと、タワーがすべて高く安定しなくなります。 そのため、タワーが倒れないように、変更を加えるには時間がかかります。 リファクタリングのためにチームに週に1日を与えます。そうしないと、ある日、プロジェクトを最初から書き直さなければなりません。 リファクタリングは、コードの可読性を向上させるだけでなく、そのパフォーマンスも向上させることができます。これにより、お客様の満足度が向上します。
13.「どのようにして開発者になりましたか？ 「summer /友人/などのために夏のある種の副業を見つけるだろう」
この質問は、ソフトウェア製品を作成するという遠い考えを持つ人々によって最もよく尋ねられます。 彼らは、最新の技術により、マウスを数回クリックするだけでプログラムを作成できると考えています。 はい、補助サービスはプログラマの作業を簡素化しますが、経験の浅い人にとっては、人気のあるフレームワークは暗い森のように見えるかもしれません（必然的に表示されます）。
これらの理由により、夏にアルバイトを見つけることはまずありません。 しかし、6〜7か月でデューデリジェンスを行うと、仕事に十分な初期スキル（オンラインコース、オープンソースプロジェクトからの学習など）を独自に習得することができます。 ただし、ターゲットのプログラミング言語と空室に依存します。
主なことは、プログラマの仕事はライフスタイルというよりも職業ではないことを覚えておくことです。 大学で学ぶこと、独学、趣味、そして重要なことに、情熱はこの分野で成功するための重要な要素です。
私たちの仕事では、おそらく、上記の状況のほとんどすべてに遭遇しています。 そして、それらのどれでも開発者/テスターを簡単に混乱させることができます。 もちろん、言葉を「禁止する」ことは意味がありません。同僚に伝えたいことと、そのような決定や行動がもたらす結果を単に理解することが重要です。
そのため、 1cloud IaaSプロバイダーの開発プロセスでは、開発者を含むすべての専門家がプロジェクトにおいてかなり高い自由度を持ち、決定の結果に対して責任を負うよう努めています。 これにより、マネージャーと開発者は、1つのチームのように感じて、個人的なコミュニケーションで論争や滑りやすい瞬間をすぐに解決できます。 。
PS仮想インフラストラクチャ1cloudを提供するためのサービスに取り組んでいる私たち自身の経験だけでなく、Habréのブログで知識の関連分野についても話しています。 更新、友人を購読することを忘れないでください！