CTOは会社のすべての段階で何をする必要がありますか？（パート2）

会社に次の開発段階があるとします。

• 0：設立段階。

• 0.5：製品はありますが、管理段階はありません。

• 1：開発の1年後、最初の安定した段階。

• 1+：着実な開発段階。

前回の記事では、CTOが会社の立ち上げ段階で何をする必要があるかについて話しました。この記事は前の記事から続き、CTOが0.5対1の段階と1+の急速な発展で何をする必要があるかを分析します。ステージ。

 

0.5〜1段階

同社は立ち上げ段階を過ぎ、製品も稼働している。次に、製品には高速で高品質のイテレーションが必要であり、テクニカルマネージャーとしてすべての側面を標準化する必要があります。

 

管理を標準化する必要があります

 

プロジェクト管理プロセスを確立します。

• JiraやTowerなどのプロジェクトタスク管理ツールを使用するかどうか。

• Confluenceなどのドキュメントナレッジマネジメントツールを使用するかどうか。

• どのような開発モードを選択するか、アジャイル開発または従来のウォーターフォール開発。

• 固定の朝の会議、毎週の会議、要約会議など、さまざまな会議システムを開発します。

• ブランチの使用プロセスとコードレビュープロセスの計画。

• テストの実施方法、選択するバグ管理プラットフォームの種類、バグの分類など。

• 会社の他の部門と定期的に同期し、プロジェクト計画プロセス全体について話し合います。

 

コミュニケーションと報告のプロセスを確立します。

• 毎日の内部および外部のIMコミュニケーションツールと電子メールの使用に関するルールを計画します。

• 毎日の作業プロセス（レビュー、テスト、リリース、オンライン）を決定します。

• 各チームメンバーの日次または週次レポートのテンプレートを作成します。

 

パフォーマンス管理：

パフォーマンス管理を行う方法、OKRまたはKPIを選択しますか？議論が多すぎて意見が違う。TGO Kunpeng Clubのグループ活動では、チームメンバーがこのトピックについて話し合うことがよくあります。会社ごとに異なるアプローチがあり、会社レベルの文化、背景、プロジェクトの属性、さらには経営陣の個性に関連しています。他人の慣習を真似することは不可能です。

比較的成熟した企業にとって、その企業に適した業績管理手法は不可欠であり、絶え間ない探求が必要だと思います。一般的に言って、評価はあまり良くない人をやる気にさせるために使われます。どんなに良い人が評価されても、彼らは常に最初の人々のグループになります。しかし、どの企業も、従業員の100％がパートナーの精神と熱意を持っていることを達成することは不可能であり、従業員の100％が世界クラスの才能であることもできません。したがって、すべての従業員が明確な目標を設定し、レビューと評価を実施できるようにすることが非常に重要です。全員の目標を明確、具体的、かつ正確にします。

 

テクノロジーを標準化する必要があります

 さまざまな環境の標準化：

• 開発、QA、ステージング、およびライブ環境の役割、各個人の権限、および各環境の使用を明確に定義します。

• 毎日のリリースを処理するための統合リリースシステムを確立します。たとえば、シェルスクリプトまたはJenkinsをカプセル化し、イベント後およびイベント後のオンラインパブリッシングを明確にすることができます。これには、運用と保守、開発、テスト、製品、およびその他の責任が必要なポイントが含まれます。

 技術標準と仕様を確立します。

• PRD製品要件文書とUIマーキング基準。

• たとえば、開発標準は、AliのJava開発仕様に基づいて話し合い、会社のニーズを満たす開発標準を要約し、コード仕様プラグインを介してそれらを制約することができます。

• 設計文書の基準、文書に含める必要のあるポイント、およびレビューのために提出する時期の概要を説明します。

• テーブル構造とサービス定義の設計標準、さまざまなミドルウェアの使用方法の標準とベストプラクティスの概要を説明します。

• セルフテスト基準、ユニットテスト要件、不完全なセルフテストテストに対するペナルティなど。

• CMDBの確立、サーバー構成、基本的なオペレーティングシステム構成、プログラムのインストール方法の運用と保守の標準化。時間が経つにつれて、チームに適した標準またはベストプラクティスを要約できます。すべての標準を認識し、すべてのチームメンバーが従う必要があります。これらの標準は、定期的に確認および議論できます。

 監視および管理システムを確立します。

• ログ、監視、およびアラームインフラストラクチャを構築します。たとえば、ELK、Grafana、InfluxDbなどを使用してビルドできます。

• 会社のログブックと管理フレームワークを統合し、プロジェクトログと管理標準を標準化して明確にします。

• 各事業の監視パネルと警報規則を確立し、警報処理基準を明確にします。

• 事故分類プロセス、レビュー方法、および説明責任方法を定義します。

• 運用および保守ルーチンの監視能力検査方法と緊急対応計画を定義します。

 

1+急速な開発段階

 

ビジネス規模が拡大すると、複数の製品ラインが存在する可能性があります。チームの規模が拡大すると、完全にフラットな組織構造ではニーズを満たすことができない場合があります。訪問数が増えると、テクノロジーとアーキテクチャの要件も高まります。ますます増えています。この場合、技術的要件と管理要件の両方が次のレベルに引き上げられました。現時点では、標準に基づいて管理と組織構造の進化を行う必要があり、管理はより高い視点から検討する必要があります。（現時点では、些細な作業を行うことは全体にとってほとんど重要ではありません）。

 

技術昇華

会社の発展に伴い、商品は形が豊富で、さまざまな商品やビジネスが生まれるか、商品の形が変わらず、来場者数が急増しています。前者の場合、経営陣が犯しやすい間違いは、単に事業ラインを分割し、採用、採用、採用してN * 20のようなチームを形成することです。各チームは比較的独立しており、テクノロジーの普及はありません。後者の場合、スタックサーバーの使用やスタックの運用と保守を通じて圧力の増加に抵抗するという間違いを犯しやすく、技術アーキテクチャの古い問題の数が増加します。チーム拡大のこの大まかなスタイルは健全ではありません、そしてより良い方法はもっと投げることです：

1. 私の提案は、技術と組織構造の調整を通じて専門家を形成し、垂直的な技術ラインを形成し、共通の技術を洗練して、会社全体が統一された前向きな技術プラットフォームを蓄積できるようにすることです。

2. 自動化された手段によって人々を解放することを強制し、人々は創造的な仕事をするべきです。

3. チームの快適な状態を排除し、チーム間またはビジネスライン間の競争が勢いを維持できるようにします。

 

組織再編

事業規模の拡大に伴い、チームの規模も拡大しており、事業ラインの技術チームを水平に分割するだけでは不十分（X次元分割）。水平ビジネスチームにサービスを提供するには、専任の垂直チームも必要です。 。アーキテクチャ、ミドルウェア、運用、保守などの垂直チームを確立し、テクノロジとアーキテクチャの統合を確保することで、すべてのビジネスチームにサービスを提供します（Y次元分割）。

チームメンバーが20人を超え50人未満の場合は、管理職を増やして最前線の従業員を管理し、3層構造にする必要があります。50人を超え100人未満の場合は、上級管理職を追加して管理職を管理し、4層構造（Z次元分割）になります。もちろん、技術担当者の育成、技術標準化、および企業レベルでの主要な技術タスクを定義および調整するために、仮想または実際の技術またはプロジェクト管理委員会を形成することもできます。

次の点を追加します。

1. レベルの上昇に伴い、管理職が最前線の従業員に到達することがますます困難になり、その結果、実行効率が低下する可能性があります。現時点では、部下の監督者の任命と管理が非常に重要です。監督者も、第一線の従業員の管理と同様に、業績評価と基準が必要ですが、監督者が管理職に就き、第一線の従業員は直接管理され、影響を受けます。これは、監督者のトレーニングにとって非常に重要です。管理にはCTOの独自の基準とルーチンを使用する必要があるだけでなく、さらに重要なことに、監督者に管理責任を明確に認識させ、独自の管理スタイルを刺激する必要があります。

2. 上司が完全に権限を与えられ、チーム管理の自律性を持っていることを確認しながら、上級管理職がすべての従業員のアイデアを理解できるように、第一線の従業員が自分のアイデアを表現および表現する機会を持つためのチャネルを提供することが最善です公正な透明性を維持します。

3. 会社のこの段階では、人事のランク要件と給与基準をHRとともに一律に定義できます。これを業績評価と組み合わせて、一定期間のランク調整計画を作成し、明確な上向きのチャネルを形成する必要があります。すべてのメンバーに、自分の努力で会社内を遠くまで行くこともできることを認識させます。

4. ビジネスチームとプラットフォームアーキテクチャチームには異なる目標と使命があり、いくつかの矛盾があります。CTOとして、私たちは優れた指導を行い、ビジネスチームに統合アーキテクチャの重要性を認識させ、アーキテクチャチームにビジネスチームのプレッシャーを認識させる必要があります。アーキテクチャチームがビジネスを理解し、ビジネスチームがテクノロジーを掘り下げるように、チーム間の転職を促し、技術チームのトレーニングを行うこともできます。

 

文化を構築する

結局のところ、人は社会的な動物であり、感情を持っています。会社のすべての管理方法が難しい方法である場合、従業員がそれらを心から認識することは困難です。HRBPと協力して、チームの特性を備えた技術文化を構築することができます。たとえば、共有文化、オープンソース文化、学習文化、自動化を促進する文化などです。

技術チームのWeChat公式アカウントを作成して、全員が一緒に投稿して操作できるようにすることができます。自己開発プロジェクトはオープンソースでコミュニティに貢献できるため、コミュニティは一緒に改善し、社内または会社と会社の間で定期的な技術トレーニングや交換を組織し、毎年恒例のテクノロジースター、製品スターの選択を組織することができます、など。待ってください。早い段階で、一定の報酬とインセンティブを使用して、固定された技術文化を広めることができます。文化が形成された後、各チームメンバーは、仕事は個々のタスクを完了するだけでなく、グループで成長し、チーム、そして価値観を持っています。

 

価値を構築する

一般的に言えば、3〜5の重要な値が企業レベルで抽出され、技術チームはこれに基づいて技術的価値を洗練および洗練し、評価に含めることもできます。

個人的には、価値観は私たちに一般的な方向性を設定できると思います。たとえば、どのような人が必要かなどですが、一方で、すべての従業員に微妙に影響を与える心理的なヒントに似ています。ゆっくりと、従業員は会社の価値観に沿った人々に進化する（会社との「夫婦」になる）か、価値観に適応できないことに気付いたときに自発的に退職します。たとえば、技術チームの価値を複数の能力に特化したものとして定義し、主導権を握り、革新に勇敢に立ち向かい、技術チームの価値であるとあなたが言うことを実行し、いくつかのサブアイテムをリストすることができる場合評価に含めるため。従業員のビジネス能力は良好であるが、日常のパフォーマンスが価値観に適合していない場合でも、彼は通りすがりの人にしかなれず、会社と一緒に成長することはできません。そのため、多くの大企業は価値観を重視しています。

チームの規模が小さい場合は、最前線にいる限りチームをうまく管理できます。規模が中程度の場合は、いくつかの基準やシステムを使用して管理できます。規模が大きくなると、より高いレベルが必要になります。 -次元の文化的価値観。すべての従業員に感染し、従業員に会社を認識させるこのような手段は、制限的なコマンド管理よりも効果的です。

 

会社のこの段階では、CTOは内部管理の良い仕事をするだけでなく、会社がブランドプロモーションを行うのを助けるために外部の仕事をするために時間をかけ、定期的な会議などのより良いリソースを目指してテクノロジーを使用する必要があります仲間や投資家とのコミュニケーション、組織化、技術的な議論への参加、業界のトレンドのフォローアップなど。

 

最後に、テクノロジーが会社の戦略にどのように役立つかについて話したいですか？

個人的には、2つのポイントが非常に重要だと思います。1つは持続性、もう1つは緊張、そして3つ目は思考です。これらのポイントを中心に、テクノロジーサービス会社の戦略の重要なポイントをいくつか挙げました。

 製品技術部門の最も基本的な責任

製品技術チームとしての最も重要な仕事は、企業のビジネスニーズを満たすために、高品質で信頼性の高い製品を継続的かつ効率的に出力することです。また、使いやすさを継続的に向上させると同時に、自動化と標準化によって効率を向上させ、人件費を節約します。組織の規模が大きくなった後は、管理を使用してチームの効率を維持できます。ビジネスとチームの規模の拡大に伴い、これらのポイントを達成することは容易ではありませんが、これらは会社の戦略に役立つテクノロジーの基本的な要件にすぎません。

 技術革新で不可能を可能にする

たとえば、あるとき、ビジネスから要件が与えられましたが、基盤となる外部インターフェイスの制限のために実現できませんでした。しかし、ビジネスは、なぜ他の企業が達成できるのか、私たちはできないと言った。この時、私は時間をかけて画期的な方法があるかどうかを真剣に考え、他の人の実装方法を見つけようとし、最終的に制限を回避してこのプロジェクトを実現する方法を考えました。思っていなかったのは、プロジェクトが始まってから、当時の質問が間違っていたとのことでしたが、実は他の人は気づかなかったのですが、この技術を実現したのは私たちだけだったので、多くの人が喜んで協力のために私たちに来てください。

私は技術の研究開発に10年以上の経験があると思います。会社の既存の技術を十分に理解しており、何かが達成できるかどうかについてすぐに結論を出すことができると思います。実際、これは正しくありません。外部からの要求を受け取るときは、逆に考える必要があります。まず、この要求を実現する必要がある、または競合製品がすでに実現していると想定します。他の人を拒否する前に、数日待ってからチームに数日を与えます。毎日それを達成する方法を考えます。他の人ができないことをするなら、あなたのテクノロジーはあなたのコアコンピタンスです。

 速く戦うことができる鉄軍技術チームを設立する

会社の技術の標準化と成熟により、チームは迅速に戦う能力を持つ必要がありますが、安定したビジネスでは、ベテランが温水で茹でガエルの状態になることがよくあります。テクニカルマネージャーは、さまざまな方法を使用して、全員の闘志を動機付け（ステージのリファクタリング、ハッカソンなど）、チームの活力を維持する必要があります。このように、新たに開発されたプロジェクトがあれば、社内で簡単に死の部隊を見つけて戦闘に参加することができます。超高実行力により、新規事業は低コストの試行錯誤を行ったり、これは、成熟したテクノロジー製品チームでもあります。

 戦略に従って、チーム構造と技術構造を時間内に調整します

チーム構成や技術構成に関係なく、一定の進歩期間が必要です。一般的に、線形開発プロジェクトの場合、会社が現在AレベルのPVにある場合、Aレベルの10倍の予約を開始する必要があります。 PV構造。ビジネスの発展に基づいて技術アーキテクチャの課題を見積もり、テクノロジーがビジネスの速度を低下させないように、6か月または1年前に新世代のアーキテクチャ計画を確立します。チーム構造では、最初にスケルトンを定義してから、考えられるすべての位置の穴を埋める必要があります。技術管理者は、会社の戦略に敏感であり、会社の発展と戦略に応じてこれら2つの構造調整を事前に準備し、必要に応じて調整を適用する必要があります。

 コアテクノロジーを洗練し、製品を商品化し、製品出力の可能性を探る

2C製品を使用している場合、販売する分野で長年の経験を経て、コアテクノロジーまたは製品から2BまたはSaaS製品のセットを抽出できる可能性があります。成功した場合、これは2C製品だけでなく、非常に優れています。おそらく別の2B製品のセットまたは2Cプラットフォームのセットさえあります。2B製品を製造している場合は、現在の製品がコピーアンドペーストでカスタマイズされた製品なのか、完全に構成された製品化された製品なのかを考える必要があります。そうでない場合は、どうすればより用途が広く、人件費を削減できますか。製品化とプラットフォーム化のプロセスは、技術に対する要件が高い、苦痛を伴う抽象的なプロセスですが、実現すると、企業のユーザーと規模を爆発的に発展させることができます。これは、実際の技術変更戦略です。

 最先端技術に焦点を当て、最先端技術と企業ビジネスの組み合わせを考えます

現在、技術変化の危機的段階にあります。今後5年間で、AIの垂直セグメンテーションが成熟し、ブロックチェーンにも多数の実用的なアプリケーションが存在する可能性があります。技術管理者は、これらの技術に常に注意を払い、可能性を考え続ける必要があります。組み合わせシナリオ。考えることを愛する人は少なくありませんが、ビジネスを理解している人はテクノロジーを理解していない人が多く、テクノロジーを理解している人はビジネスの問題点を理解できません。最先端のテクノロジーに積極的に注意を払い、議論やコミュニケーションを続けている限りビジネスの専門家と、いつか衝突するかもしれません。革新的な製品。

- 終わり -