-開発者の価値の概念はどのように見えると思いますか？
価値を高めるには、次の3つのことを行う必要があります。
- 現在および将来の市場で要求される技術を研究する。
- ユニバーサルスキル（ソフトスキル）を開発します。
- より多くの責任を負います。
-最も単純なものから始めましょう。 どの技術を習得すべきか？
今日のトレンドは非常に急速に変化しています。 したがって、傾向を説明したり予測したりするのではなく、いくつかの一般原則を表明したいと思います。 経験とスキルの理想的な構成は、T字型の専門知識を持つ人（T字型の人）であると考えています。 この用語の本質は、特定の技術分野の専門家として、彼は近隣の分野で何が起こっているかを知っているべきだということです。
たとえば、バックエンド開発者は、言語の機能（Pythonなど）および一般的なフレームワークに関する深い知識に加えて、テスト、アセンブリ、および展開プロセス（JenkinsなどのCI / CDパイプライン）を知っており、できれば構築できる必要があります。 彼は、コードが動作する環境の機能と、その中でフォールトトレランスを確保する方法を知っている必要があります。 たとえば、AWS / Azure / GCEまたはk8sのオンプレミスインストールに対処するには、golangで記述された展開ツールのエラーを修正できます。
一部の地域では、価値によって証明書の可用性が向上します。 採用する場合、ポートフォリオは重要です。オープンソースプロジェクトに参加するか、githubにペットプロジェクトを投稿することで、スキルとコードを最も簡単にデモンストレーションできます。
-あなたは、いくつかの一般的な技術的ソリューションについて言及しました。 トレンドにあるものを学ぶ必要があることがわかりましたか？
必ずしもそうではありません。 あなたは市場で誇大広告に行くことができます、または反対方向に行くことができます。 希少な技術に興味があり、ファッションを追いかけたくない場合は、独自の知識により価値を高めるチャンスがあります。
現代のテクノロジーの巨人は十分な柔軟性を備えており、システムを正常にアップグレードする余裕があります。 そして、判断できる限り、YandexとGoogleには、時代遅れのテクノロジーに基づくソリューションの印象的な遺産がありません。
しかし、より保守的なセクターがあります。 国際銀行 、産業およびエネルギーの巨人、防衛産業です。 彼らが自分のスタックで専門家を見つけることは非常に難しく、彼らは良いお金を払う準備ができています。 良い例は、booking.comおよびmail.ruで「死にかけている」Perlを使用することです。 または、60年代に開発され、一部の米国の金融機関でまだ使用されているCOBOL 。
-そして、ユニバーサルスキルとはどういう意味ですか？
他の人とコミュニケーションをとることができるため、会社の開発者の価値が大幅に高まります。 実際には、これは、人が問題を提起し、自分の意見を実証し、解決策を提案し、利害関係者を正しく特定し、異なる人々と効果的に対話する方法を知り（柔軟性）、対立を建設的に解決し、交渉し、訓練し、指導し、指導することができることを意味します。 そして、公に話したり、出席したりします。
これには、デザイナーと同じ言語を話す能力と、リーダーの動機の理解も含まれます。 英語の知識について考えるので、すべてが明確です。
-より多くの責任を負うとはどういう意味ですか？
私たちは、作業ツール（技術）よりも少し先を見て、エンドユーザーの価値に集中する人々を雇うよう努めています。 たとえば、開発プロセスを最適化するためのオプションを提供し、クライアントの問題の解決策を探しており、変更について議論し、実装する努力をする準備ができている人たちです。
残念ながら、ツールを中心にカルトを作成する開発者をよく見かけます。 ただし、コードが予定どおりに本番稼働しなかった場合、その品質や使用するツールは重要ではないことを理解する必要があります。 このコードは会社に利益をもたらしませんでした。
「アジャイルの価値を思い出させます。」 接続はありますか？
はい アジャイルの価値を開発するDevOpsと呼ばれる一連のプラクティスがあります。 これにより、企業は、プロセスを形式化することから、価値を生み出すために社内でやり取りすることに焦点を移すことができます。 しかし、これはすべてのチームメンバーによる最終結果に対して責任を負うことなく不可能です。
優れた開発者は、DevOpsの文化を理解し、彼のチーム、そして理想的には会社でそれを適用する方法を知っています。 または植物ですら。 たとえば、DevOpsプラクティスの1つはCI / CD（最も頻繁なリリース）です。 頻繁にリリースする（少なくとも1日に1回）場合は、統合とテストの自動化、展開プロセスの自動化と安定化、リリースとリリースの分離（機能の切り替え）がなければ機能しません。下位互換性、ロールバックメカニズムの変更など。 QA部門にタスクを転送しても、優れた開発者の責任が終了しないことは明らかです。
頻繁なリリースの価値は誰にとっても明らかであるようです。
Anti-DevOpsは、生産プロセスを、開発、テスト、運用、セキュリティの2つ以上の機能的ウェルに分割したものです。 その結果、各関数は独自の問題のみを解決します。
一般的な意味では、チームは製品の品質、クライアントの機能の価値、タイミング、およびタスクの説明の要件への正式な準拠の程度については責任を負うべきです。 開発者は、自分の責任を制限することに偏見を持ってはなりません。「私はすでにタスクをテストに移しました。 他には何もできません。」
責任が大きいほど、会社の結果への影響は大きくなります。 良い会社では、その成長に影響を与える人々がキャリアの梯子を上っていきます。
チームの責任には、良好なコミュニケーションが必要です。 建設的なコミュニケーションとチームワークのスキルなしに上記のすべてを構築することはほとんど不可能です。
-どこでもそうですか？
成熟したプロセスが既に設定されている大企業では、責任を受け入れることは、プロジェクトの作業を超えて何かを行うことを意味します。会議の開催、技術的な話、ハッカソン。 プレセールまたはインターントレーニングに参加する。
-結論は？
要約すると、個人開発の最も最適な戦略は、 コミュニケーションスキルを身につけて、製品やチームや会社で起こっていることに対する責任の境界をより効果的に拡大することです。