堅固で柔軟なITスキル:考えている以上に多かれ少なかれ

最近、IT専門家の「基本的なスキル」が減価していること、そして何よりも人生を磨いたわけではない他のスキルを支持しているというわずかなヒントで、非常に神経質な反応をしばしば観察する必要があります。 これは、いわゆるハードスキルとソフトスキルを対比する議論で最も明確に現れます。 このような態度自体が、この問題の重要性を示しています。 しかし、その深みには仮定があり、それは私には不均衡に警報を膨らませているように思えます:それがどんなに馬鹿げた音に聞こえるとしても、おそらくこのような鋭い反応は、私たちがソフトスキルを十分に真剣に受け取らないという事実によって引き起こされます。 今日、私は状況に対する私の見解を共有し、私たち全員を助けることができる一連のステップを提案したいと思います。











いくつかの観察



インターネットで人々を膨らませる最も信頼できる方法の1つは、ソフトスキルが最終的にIT分野で前面に出て、ハードスキルをあいまいにする可能性があると想定することです。 「ねじ込む」と言うとき、私は単に意見の相違だけでなく、強い感情との意見の相違を意味します。 この輝きは非常に重要な指標です。



私が多くの状況で従うことができた非常に信頼できるパターンが1つあります。人の発言に対する感情的な反応の強さは、この発言が彼にとって苦痛なトピックとどれだけ密接に関連しているかを多く伝えることができます。 言い換えれば、すべてが透明であるように見えますが、検出方法としては非常に効率的に機能します。 急性の反応は、実際の問題と実際の脅威に私たちを導きます。



(私は心理学者、より具体的には心理療法士からこのトリックを巧みに盗みました。彼らはそれを使用して、患者にとって基本的な問題を見つけます。一般的なルールはこれです:何かについて話すことが難しいほど、それはより重要です、同じ原理が...、例えば、他の多くの分野で適用することができるだろう、彼はいくつかの品質や情熱を持って入金されたときに、人がおこっている場合 -これは、多くの場合、手段、彼らが絶対になりたくないするグループなどの品質と熱意特性こと それは多くの類似性を検出しているが、数値)。



私たちの場合、関心は何らかの理由で人々がハードスキルとソフトスキルの相対的な価値を非常に心配しているという事実によって引き起こされており、これらの2つの要因も危険をもたらしますが、一般的な経済的不安定や専門家による市場の過剰についてはそうではありませんそのステータスのため。



急性反応の頻度は、暗黙的に表明された一種の「世論」として捉えることができます。 文化の観点からは、これは重要なポイントです。結局のところ、文化はまさにその社会によって創造されます。 過去数年間の会話のパターンとこのトピックへの回答を特定し、不安のレベルがどれほど議論されているかを見て、私は次の結論に達します:それは自分で持っているでしょう。



この背後にあるもの



横から見ると、この急激な上昇に驚くことはありません。 「困難な性格を備えた孤独な天才」のタイプは、一人の技術によって今ではほとんど技術が生み出されていないという理由で、ますます少なくなっています。 私の以前の仕事では、私の責任のかなりの部分は、数千人ではないにしても数百人を合意に導き、全員が同じ方向に進むようにこのコンセンサスを維持することに関連していました。 それは非常に難しい仕事でした。 ほとんどのITスペシャリストのように、私はこれに対してまったく準備ができていませんでした。だれも理解できないことを期待して、自分が何をしているのかを知っているふりをしているだけだと常に感じていました。



大規模なチームで作業する場合、コミュニケーションと協力の問題の解決は、すぐに成功または失敗の決定要因に変わります。 「心理的安全性」や「相互信頼」といったものは、特定のプログラミングタスクよりもはるかに強い毎日の作業プロセスに影響します。 後輩にとって、彼らは彼らの生活の質を決定するという理由で重要です。あなたに耐えられない人々の間で技術的な仕事をしようとすることは困難で苦痛です。 あなたがより高いレベルに移動するとき、チーム内の雰囲気を作成し、維持することは徐々にあなたの責任になります。 ジュニアとシニアのポジションの大きな違いはこれにあります。ジュニアのタスクは質問に対する答えを探すことであり、シニアのタスクはどの質問を尋ねるべきかを見つけることです。 特定の境界線を越えると、専門知識のレベルに対応する技術的な質問の数が急激に減少し、信頼性の高いコンパイラーからStack Exchangeまで、さまざまなツールの広範な使用が意味するのは、直接回答できる複雑な質問が増えていることです。



もちろん、非常に不可解な問題であり、経験の浅い従業員は、どれだけ多くタスクを投げても、急にポンプをかけられない限り、対処できない最も不可解な問題が常に残ります。 したがって、スキルの開発と拡大を継続する必要もあります。 しかし、スペシャリストとして開発することで、これらの非常に難しい技術的なタスクがすべてあなたの仕事時間を費やすわけではないことがすぐにわかるでしょう。 それどころか、システムの動作の最も基本的な(および最も複雑な)問題は、システムが外界と、つまり人々とどのように相互作用するかに関連している可能性が高くなります。



興味深いことに、ハードスキルとソフトスキルは、ほとんどの人が考えるよりもはるかに多く重なり合っています。 人々が要素として機能するより大きなシステムの一部としてシステムを検討し始めるとき、人々がどのように相互作用して行動するのか疑問に思うとき、ハードスキルによって開発された古き良きシステムの多くは、より理解しやすいだけでなく、一般的にソフト球と呼ばれる質問に対してより正確な回答を提供します。 2つの典型的な例は、多くのユーザーがいるサイトでの操作ルールと、あらゆる種類の結果のランキングです。 どちらの場合でも、全体のポイントは、人々が望むものの「ソフトな」直感的な理解を「ハードな」数式に変換することです。



しかし、技術的なタスク自体にソフトスキルとハードスキルの混合が必要な場合は、これらのケースを採用しなくても、現在価格に含まれているソフトスキルの多くは、コミュニティ管理に直接関連しています。 この分野は、プログラマーの間で歴史的に悪い評判を得てきました。(これも古い伝統によると)、プログラミングで何も理解しておらず、さらに重要なことに、それに関連する人々とそれに関係する人々が常にそこで働いていたからです。敬意のヒント。 その理由は、これらのマネージャーのほとんどが20世紀の産業経営の学校を去ったためです。これはまさに「人的資源」のような表現を与えた分野です。 彼らのための労働者は不必要なトラブルと費用であり、高い生産基準を維持するために「管理」する必要がある集団です。



このタイプの「管理」は、あなたがそれをまったく呼ぶことができれば、ソフトスキルとも関係ありません。 それは、人々と働くことの技術を学んだとしばしば信じていた人々によって作成されましたが、実際には非常にひどく、時には病理学的な程度までそれをしました。 人々がマネージャーの側に敬意の欠如を感じているという単なる事実は、非常に警戒すべきです。 最後に、マネージャーの仕事は、人々を調整し、チームワークのためにセットアップすることです。 彼らが従業員と自分自身の間に相互尊重を構築することができる最も基本的なレベルでできない場合、他の人は間違いなくこの点で彼らからの助けを期待すべきではありません。



一番下の行は、問題のそれらのソフトスキルはどこからともなく来ていないということです。 「エチケットレッスン」や「パーティー」では教えられません。 彼らは、人々を観察し、彼らの特性を研究し、彼ら自身が望むものを明確に表現できない場合でも、彼らのニーズを理解する能力で構成されています-したがって、それらを解決することは想像を絶するほど難しく、プロのスキルよりも簡単ではありません。 それらをスキルではないかのように話し、価値を否定し、プロの範囲外に持って行くという私たちの習慣は、私たちに害を与えるだけです:私たち自身でタスクを実行する必要になると、すべてがそこに原始的ではないことがすぐに明らかになります。











-私たちの分野の専門家は、長年この問題に取り組んでいます。

「もう戦う必要はありません!」 私はアルゴリズムでそれを解決するためにここにいます

* 6か月後*

-うわー、それはどれほど複雑か。

-何言ってるの?



(あるおなじみのエンジニアの話はこれを思い出させます。彼のチームが別の建物に移動したとき、彼は致命的な言葉を発しました。彼らはスペースを整理するのは簡単だ、彼はそれを扱うことができる、彼はエンジニアだと言います。科学者とディレクターは同じ病気に苦しんでいるようです:他のすべての職業は些細な問題であるという信念)



良いニュース:抜け道がある



私は、状況を非常に「簡単な」方法で修正できると思います。ソフトスキルを真剣な専門スキルとして扱い始め、後者と一緒に評価し、人々を訓練し、すでにそれらを習得した人々を雇うことです。他のすべての基本的なスキルに関連して。



最初のステップとして、それらを議論するための共通の辞書があることを確認することは害になりません。 名前のないものに感謝するのは難しい。 私たちの視野の外にしばしばある典型的なタスクには、「誰もが現在プロジェクトで何が起こっているかについての一般的なアイデアを得る機会を与えます」、「基本的な技術概念の共通語彙を開発して誰でも説明できるようにする」、「確認する」誰もが投票する権利を持ち、重要な恐怖は単に「恐怖」から発言されないままではなく、すべての参加者がプロジェクトに個人的な関心を感じ、その成功を自分自身であると見なすようにします」 私たちがしばしば注意を払わない典型的な指標には、「ユーザーは製品の使用中に刺激や他の否定的な感情をどのくらいの頻度で経験し、これが長期保持にどのように影響しますか?」これは製品の全体的な印象に影響しますか?」



前のパラグラフでは新しいことはリストしませんでした。これらはすべて、プロジェクト管理からユーザーエクスペリエンスの調査まで、さまざまな専門分野の標準的な質問です。 しかし、主要な成功要因ではなく、チーム全体がそれらを担保の考慮事項として扱う場合、物事は災害で終わる可能性があります。 さまざまなグループが、わずかに異なるバージョンの製品に取り組んでおり、それらは統合された最終段階でのみ競合を開始します。 チームの1つは、製品の成功を望まないため、徐々に製品を妨害しています。 ユーザーは、ある種の「小さな」バグに遭遇し、恐ろしくなります(これは、大量流出から訴訟に至るまで、何につながる可能性があります)。 顧客の信頼は徐々に不足しています。 技術的にはすべてが非の打ちどころがないという事実にもかかわらず、これらの各理由がプロジェクトの崩壊にどのようにつながるかを自分の目で見ました。



そのようなことをプロジェクトの三次ではなく重要なコンポーネントとして扱う場合、チームメンバーは、たとえそれらを扱っていなくても、少なくともその重要性を理解できるように、それらについて一般的な考えを持っている必要があります。 これらは、フロントエンド、バックエンド、またはセキュリティとともに、チーム内の個々の役割の基盤として考慮され、特定の人々に分散される必要があります。



すべてのエンジニアがこれらすべての職務を遂行するために必要なスキルを持っていなくても構いません。 私はもっ​​と言います:完全なリストに対処できる人がいるならば、私は驚くでしょう。 しかし、それらから「目に見えない労働」をすることは誰にも認められず、どこにも考慮されず、それが必要とするスキルが存在しないふりをして、何も達成しない、私たちは自分自身を傷つけるだけです。



この害は、直接的な結果(つまり、必要な作業が実行されないこと)だけでなく、それほど明白ではないものにもあります。不必要な恐怖に対処する必要があります。 記事の冒頭で説明した不安は、私たちが認識していることの兆候です。私たちは重大な何かを見逃しており、この見逃している未知は日々ますます必要になっています。 不足しているのはスキルではなく、出生直後からできる人(最も人気のある候補者は女性とパーティーの人です)が、他の人(プログラマー)はできないと思う場合、この状況から私たちは不安を感じます。 結局のところ、私たちは仕事から追い出され、プログラマを軽視する不明瞭な人々に取って代わられようとしていることがわかります。 しかし、これらすべてのスキルを真のスキル、つまり人々が何を学び、どのように人生を改善するか(まあ、または改善しないか)を認識すると、これはまったく異なる会話になります。 そして、この会話は次のように聞こえます。「くそ、チームの誰も[必要なものを挿入する]ことができず、必要に応じて出て​​行けない」-つまり、少なくとも1つのプロジェクトに関与した人なら誰でも痛いほど親しみます はい、これらのタスクに最もよく対処する人々は、通常、プログラミングに関係のない分野から来ています。これは純粋な真実です-プログラミングの分野では、数十年にわたってそのようなことを学ぶのを怠ることが慣習となっています。 しかし、これは、彼らがプログラミングについて少しでも理解しておらず、この分野を尊重していないという意味ではありません。



たぶん私はバナリティーを言いますが、プログラマーの調整やユーザーとのやり取りのデバッグなどの責任を負う人がプログラマーを敬意を持って扱う場合、彼は仕事に対処せず、雇われるべきではありません。 「誰もがこの人と話すことから手を離します」-深刻な鐘であり、職業そのものの避けられない副作用ではありません。



ただし、これは逆の方向で機能することに注意してください。各プロジェクト参加者は、それに取り組むために必要なすべてのスキルを尊重し、対話に参加するために十分に理解する必要があります。 システムの運用に関連する法的な問題がある場合、全員が関連記事を知っている必要があります。 ユーザーの調査により、何かがポジティブまたはネガティブな反応を引き起こしていることが判明した場合、設計する際に誰もがこれらの事実を考慮する必要があります。 遅延がユーザーの行動のいくつかのタイプをブロックする場合、誰もが問題が何であるかを理解する必要があります。 同様に、誰もが人と仕事をするスキルを理解し、評価する必要があります。最終的に、構築しているシステムには少なくとも自分自身が含まれます。



All Articles