エンジニアからリーダーへ。 パート1：正義感

ソフトウェアエンジニアとして長い間働いていて、経験と知識に加えて、特に作業プロセスと上司に対する不満とコメントも集めました。 問題に出くわすたびに、私はそれをどのように解決でき、この状況で何ができるかを考えました。 何かできることはありましたが、プロセスと管理装置について何かが壊れていました。 そして、問題とその解決策が私に延期されるたびに、必要なレバレッジがあれば、それを変更して正しい方法で実行できることに気付きました。 私は精神システムを形成しさえしましたが、それはあまりにも面倒で、紙で形式化することはできませんでした。 私の周りに広がっている不正は私にとっては隠されていましたが、喉の塊であり、魂の石に変わりました。 蓄積されたすべてのものを実現し、修正する機会と機会を期待していました。



あなたの欲望に注意してください-彼らは叶います！







そして、偶然にも、私は自分の才能とスキルを高く評価し、私の野望を実現することができるリーダーシップの地位を提供されました。 マネージャーとの会話は、最高の伝統「 あなたは今上司です 」で終わりました。 そして今、私は正義の輝く透明な光を具体化し、人々を幸せにし、言葉とバイトを人々に伝えなければなりませんでした。 しかし、ほとんどすぐに、以前に思っていたよりも少し複雑であり、上と下からの問題の視野角がわずかに異なり、ネイティブコードが膨大な数の問題や懸念よりもわかりやすいことが判明しました。 だから今、私は最終的にパフォーマーとボスのプリズムから紙にドグマを描くことにしました。 実用的な例とジョークのジョークを除いて、良い本にすでに書かれているもののほか、新しいことを言うことはまずないので、すぐにスクロールするか、Catにようこそ。



まず、何かをして、何かを達成することから始めます。あなたが知る必要があり、やりたいことがあります。 幸運やピーターの原則にうなずくだけでは十分ではありません。「 階層システムでは、どの従業員も無能のレベルにまで上昇します 。」 これは自然なプログラマーの正義を望むよりも頻繁に起こりますが。 あなたは、自分の視点から見える視点からの参加よりも、紙の所有が卒業証書を与えるよりも、原則が必要とするものよりも多くを知る必要があります。 私は普通の従業員として、ITアーキテクトとプロジェクトマネージャーがどのようにITを行うのか、すべてがどのように接続され、どのように機能するのか、なぜコードを書いているのか興味がありました。 いいえ、もちろん、ソフトウェアがコントローラーのメモリに書き込まれ、顧客がコントローラーにお金を渡すことを抽象的に理解しました。 しかし、私のコードのほかに、他にも多くのことがまだありました。しばしば、それは不必要であるように思えました（時にはそうでした）。そして、そのミッションの本質と目的、私が月の名のもとに持っている正義を理解することは私にとって不可欠でした。







プログラマー、開発者には正義感があります。 そうでない場合、このスペシャリストは悪いです。 彼に対処せず、彼に頼らないでください。 優れたプログラマーは、ソリューションが公正であると判断するまで妥協しません。 したがって、最も重要な動機の1つは、聖なる目標、目標管理です。 良い例は、平和主義のAppleや従業員の自由のあるGoogleの例です。 良い例は、他社に直面した「悪」に対するパフォーマンスです。 ワークフローと企業レベルの両方で目標を持っていると、請負業者が自分の行動に使用する機能とリソースを決定するのが簡単になり、彼は最終的に彼が働いている理由と目的を理解し、キャッチしたバグがもはや飛ぶことはありません飛行機の制御装置のどこかに着席し、何百人もの疑いのない人がいるのです。彼の会社は、人々の人生を最高の目標に設定しているからです。 自分の理想と正義を持っている開発者は、オットセイを殺す会社や、理想と矛盾する場合は予算をパッチングピットに削減する会社に行くことはありません。 コードのスタイルは彼にとって重要です（インドのコードだけではありません！）、クッキーの数（誰にも手に入れないでください！）、窓からの眺め（上司から川へ、プログラマからレンガの壁へ）とノイズオフィス（マネージャーは常に仕事の代わりに話す）。 プロセスの他の参加者の観点から見ると、開発者は常に正しいとは限りませんが、彼は自分の聖なる目標、教義を持っています。その違反は、たとえば報酬よりもはるかに悪いです。



これは非常に重要なポイントです。開発者の報酬は、彼が心配を考えず、お金を稼ぐためにスナップショットを探すようなものであるべきではありません。 そして彼の成功は賞の形での確認を必要としません。 彼は目的のために、正義のために働きますが、励ましのためではありません。 開発者に手で餌を与えると、彼の代わりにもっと長く燃える優秀な専門家を単に破壊して、ワークフロー全体を彼のアイデアで照らす危険があります。 ただし、開発者が最前線でお金を投入し、定期的に上司にボーナスを要求する場合、これは問題の兆候です。 人またはプロセスと。 ミスが発生し、そこから利益は得られませんでしたが、プロセスと管理の観点からは、他の従業員が将来同様の問題を回避することが可能です。



いつでも好きな金額と必要な額を支払われたわけではなく、フリーランスのサイトに同時に登ったこともありましたが、職場ではイニシアチブを取り、予定より早く仕事をして、一般的にheしている従業員を助けました私は熱心に働いていましたが、ジャムを使っていましたが、賞のためではなく、成功のために「私たちは同じハーネスにいます」と努力しました。 私は正直でしたが、内なる正義感が跳ね上がりました。結果のために働き、同僚は何時間も働きます。 同じ排気ガスで8時間ではなく2時間働くことができたので、交通渋滞に余計な時間をかける必要はありませんでした。 ボーナス（これが提供された場合）を支払うことはできませんでしたが、結果から、その従業員怠lazな人の予算から。 正義はさまざまな方法で回復できます。 しかし、誰もそれをしませんでした。 それは管理の誤りであり、モチベーションの低下と椅子に座っていた。 どんな状況でも、開発者が他人の仕事をする機会を、自分のイニシアチブであっても決して与えないでください。 計画を変更し、過失を追放し、複雑なタスクを積極的に与えますが、開発者が不公平な分業を感じることはできません。 開発者の側からは、自分の仕事で手段に夢中になるのではなく、時間を計画し、リソースを別の方向に向かわせる必要があります。学習、コミュニケーション、プロセスの改善です。



おそらく、読者の観点から、それは私自身のせいであると言うことができます、私自身はそれをやっていませんか？ なぜ私は「あの男」を耕したのですか？ 多くの人が職場でbashorgを読み、仕事の見た目を維持できる場合、正義感が高まっているために、マニュアルを熟読し、アセンブラーの位置にQtコード（たとえば）を書くことは、私にとって困難でした-当局を欺くのですか？ はい、仕事で何か他のことをすることはどこにも歓迎されません。 これは、経営陣のもう1つの誤りです。従業員を訓練することではありません。 開発者の2番目に重要な品質は学習可能性です。 私たちIT関連の人々は、学習と改善の永続的な状態にあります。 スキルを磨くだけでは十分ではありません。brainfuckでハローワールドを、Haskelでテトリスを、そして私たちに求められていない多くのことを書くのは興味深いことです。 新しいことを学ぶことに興味があります。 そして、経営者に「トレーニング、セミナーはありますか？」と尋ねると、彼らは否定的に答えてくれました。 彼らは常に仕事に関連しているとは限らず、雇用者のリスクとリソースの損失をもたらす可能性がありますが、私の知識と影響力の範囲の拡大、他のプログラマーとの経験の交換、そして私の分野の新製品の知識はポジティブです。 そして、美しい、または超高速で低レベルの読めないコードを書くのは、しばしば楽しいことでしたが、驚くことは何もありません。 最終的に、それは内部標準と矛盾しませんでしたが、リーダーシップの不満を引き起こしましたが、コードは人間に依存するようになりました。 私たちの必要性は不公平を補いました。



このGoogleの従業員は、時間の20％を自分のプロジェクトに費やす権利があり、可能であれば、将来的にそれらを実装します。 率先してください。 実際には、これはほとんどの場合そうではありません。 さらに、通常、日常業務は興味深いタスクよりも優先されます。また、サイドプロジェクトの欠如は、開発者の雰囲気やモチベーションに悪影響を及ぼします。 それでも、開発者のモチベーションを殺すのは非常に難しく、遅かれ早かれ彼のアイデアや運動がリーダーシップを発揮します。 もちろん、すべてが役に立つわけではありませんが、原則として、有害なものはありません（もちろん、スペシャリストが、最後のコミットで贅沢で未承認の機能を使用してビルド全体を停止した場合を除きます）。 ただし、彼に大きな打撃を与えると、結果がゴミ箱に捨てられます。 たとえば、アーキテクチャ全体とそれに続く反復/テストに関係するものではありません。 例として、コード、タブ、コメントのタイプミス（新しい記述された関数に加えて）、またはMC \ DCへの単体テストの追加の純粋に美的な舐めを引用することができます。 機能的にそのような変更が何も変更しないことは非常に明白であり、コードの一部ではなく他の人が更新に入るという事実につながり、一般に変更は予想以上のものになります。 問題：イニシアチブの結果はゴミ箱に捨てられます。 これは違反でもワークフローの妨害でもないという事実にもかかわらず。 またはその逆-イノベーション（機能、ワークフロー、ツール）は、アイデアの作成者の下ではなく、別の従業員または中間ボスの名前の下で受け入れられます。 一方で、これはひどい窃盗と見なすことができ、他方で、従業員に対する不信のシグナルとして見なすことができ、それは彼自身の評価にはるかに悪い影響を与えます。



とりわけ、開発チームの支援と結束も重要です。 後援とは、上から開発者に降り注ぐすべてのもの-会計報告書、集会、SCRUMスプリント（プロセスが確立されていない場合）、在庫、技術機器、会社の生活に参加する機会、が管理者と管理者のバッファによってフィルタリングされるべきであることを意味します。 開発者には、人生の特別なパラダイムがあり、理解できない何かを立ち上げる特別なエコシステムは非常に危険です。 彼らは、巨大なモデルを念頭に置いて、プロジェクトとコードの関係を「些細なこと」で気を散らすことはできません。さもないと、すべてがカードの家のように崩れ始め、作業プロセスを再開する希望が面倒になり、チャットします。 。 しかし、これに加えて、会社の生活に参加することは、明るい目標を見るだけでなく、あなたの重要性を感じる方法であることに注意することが重要です。 最も一般的な問題は、「あなたはお金をmakeけない」というメッセージです。 IT担当者は、何も生産しないでお金を使います。 そして、営業部門はお金を稼ぎます。 売ります。 サポートは顧客と連携します。 この声明は、分散した懸念であってもIT担当者の役割が「不採算」である場合の大きなシステム上の問題の兆候です。ただし、原則として、1つの開発チームの自動化とプロジェクトは数千および数百万個の商品を販売することができます ITインフラストラクチャ部門では、特にうまく機能している（ケーブルを常に引っ張っていない）場合やテスト（コードが記述されている！）の場合、状況は特に悪くなります。 この態度は「愚かな腐敗した女性」に対する防御的な反応を引き起こすが、最も重要なことは、多くの場合、懸念全体（および最終的には最終利益）がかかっているコグ開発者の怠慢につながる：国内計画では-二流の椅子で、救う機会（彼らは誰と文句を言いませんか？彼らは人々と仕事をしません）、クッキーやモバイル通信の予算を削減し、不幸なプログラマーが暗い森を通ってオブジェクトに出張するのに十分幸運だった場合、オオカミを食べるために黒い森に残します。



開発者は非常に忍耐強い人です。なぜなら、彼らは通常、第一に愚か者を攻撃しないこと、そして第二に彼らが気分を害する人々に水を運ぶことを知っているからです。 しかし、従業員が最初に無料のCookieがある会社に来て、窓からの眺めがスクラブだった場合、時間の経過後に従業員はこれを奪われ、トラブルを待ちます。 財務部門と支払われたお湯で動作するとは考えられません。 それは良かった-それは悪化し、さらに、今ではペットの墓地の窓からの眺めがあります。 これは、開発者がプロ​​グレッシブクリーチャーであり、コントロールできないリグレッションが見られる場合、保護が存在しないためです。



チームの結束は非常に重要なことであり、どういうわけかそれを管理フォームに組み込むことは非常に困難です。 結束とは、チームが同じチームに参加し、互いに補完し合い、共通の関心を持ち、「最悪で最良」を強調しない能力です。 私はすでに、目標と目的が重複してはならず、人と人との間に競争や競争があってはならないと述べました。 評価、プロモーション、ニンジン、クッキー、特にエリート向けのクッキーは、悪の裏側です。 そして、集合体自体も劣悪ではありません。 開発者は理解され、受け入れられたいという欲求を持って仕事に来ます。 そして、共通基盤が重要です。 多くの場合、共通点はサブグループ、利益グループを形成します。 どの社会でもこれは正常ですが、作業プロセスでは受け入れられません。 実際、私がこのポーカーファンのグループに所属していないことは、さらに悪いことです。 問題は、グループのコアが人のコアから単純に分岐する場合です。 たとえば、ニュースポータルや愛されていないスポーツについての毎日の議論は不満を引き起こします。 人が黄色いニュースを読んでおらず、左小指でコアの魅力的な蹴りを見ていないからです。 さらに、そのようなコミュニティへの統一は、単に相互の集会と後援、一方を他方よりも促進することになる。 通常の社会では、これらはコミュニケーションの問題ですが、技術社会では、IT環境ではコミュニケーション能力が低いため、このような問題は本質的に終末になります。 さらに、これは従業員の一人がマニュアルを勉強し、テーマのリソースを読み、同僚に「ここでそのようなフレームワークを見つけました」と答えたときに「それは何もない、私たちにとっては面白くない」と聞く機会です。 これは開発者が考える機会です-彼はまったくそこに来ましたか？ そして、従業員の管理について考える理由：彼らは忙しく、彼らは適切な人ですか？ 専門家の関心なしに問題とタスクを解決する能力は、プロセスとチームの衰退の兆候です。 したがって、関心は開発者の3番目の重要な品質です 。



これらの問題はすべて、不正義と間違った感覚をもたらします。 プロセス、人、人を取り巻くすべてのもの。 そして、これらの要因により、私はリーダーとして、以前の過ちを繰り返さずに戦わなければなりませんでした。



これを行うには、上記にリストしたすべての最終リストを作成できます。

1. 合理的であり、開発者の視点を見てください。
2. フィードバックを受け入れる;
3. 主題を知っている人の権限を持っている;
4. 去ることを恐れずに人々を育てる。
5. 管理の信頼と委任。
6. 守れない約束をしないでください。
7. チームと人々の選択を管理する;
8. 目標と価値を開発する。
9. オープンで明確なプロセスがある。
10. そもそもチームの利益を守る。

後者については、管理にとってこれが重要なポイントの1つであることに注意できます。 チームはリーダーのサポートであり、チームが強くなればなるほど、開発者の満足度が高まり、プロジェクトを予定通りに完了し、顧客に提供し、理想的にする機会が増えます。



次回は、他の問題、経験、詳細について話します。