ITの初心者CTOによる典型的な間違い-専門家の意見

tech.coからの画像



IT企業の一部の従業員からは、「テクニカルディレクターの地位の正確な意味がよくわかりません」という発言を聞くことができます。 Toasterユーザーの1人が非常にシンプルな形で述べたように、「CTOはビジネスの何かを理解する技術者です。」 この概念をもう少し広く考えると、IT製品の開発と技術スペシャリストのチームとマネージャーとのビジネス決定の採用との接点でバランスが取れていると言えます。



したがって、ITのテクニカルディレクターになりたい専門家には、少なくとも2つの方法があります。

1. 標準-「開発者->シニア->チームリード-> CTO」。
2. 人道支援-「PM->上級PM-> CTO」。

もちろん、2番目のオプションの場合、テクニカルディレクターが技術的なニュアンスを理解することはより困難になる可能性があります。



しかし、一般的には、経験を積んだ専門家は、望ましいことを達成すると、初心者のカテゴリーに入るようになります。 彼は一種のジュニアCTOになり、新たな課題に直面しています。



業界の専門家に、IT分野で新しく作られたテクニカルディレクターを待っている間違いと落とし穴について話すように依頼しました。

Victor Shaburov、起業家、投資家、Looksery Inc.、Handster Inc.の創設者の一人 およびSPBソフトウェア

初心者のCTOはどのくらいの頻度で期限を間違えますか？



これは、CISのほとんどすべてのサービスステーションの典型的な間違いです。彼らは、自分が最も効果的であり、すべてを迅速に行えることを証明しようとします。 苦労すらしていません-無駄です。 成績の条件を2倍にするだけです。



どのような場合を思い出せますか？



はい、100％のケースです。 サービスステーションに、自分が2階に渡すときに条件を2倍にする必要があるが、チームには伝えないように説明することができます。 最初の計画に従ってチームを動かしてください-そして、すべてを時間通りに行うことが判明しました。



これはあなたにとってどれほど重要ですか？



避けられない自然現象のように、私はすでに禅に入ってそれに耐えているので、それは問題ではありません。 条件を2倍にするだけです。



従業員間でタスクを設定および分散する際に、初心者のCTOが間違っている頻度はどれくらいですか？



原則として、私は常に良いサービスステーションで仕事をすることができて幸運でした。 彼らはおそらく間違いを犯したかもしれませんが、よく見ていました。 数日後、タスクが正しく分散されていないことを確認でき、この問題を解決しました。



これはあなたにとってどれほど重要ですか？



サービスステーションが作業を注意深く監視している場合-これは問題ではありませんが、すぐに修正できます。



どのスペシャリストがテクニカルディレクターのミスに苦しんでいますか？ テスター、開発者、プロジェクトマネージャーですか？ どのような場合を思い出せますか？



パパー-私が一緒に働いたすべてのサービスステーションは素晴らしいものでした。 STO Handster（そしてOpera Software）のAlex Reshetkoは特に幸運でした-彼は最初にHewlett Packard Appstoreを新年に立ち上げ、その後Opera Appstoreを新年に再び立ち上げる必要がありました。 休暇中、チーム全員が耳を傾け、誰も飲んだり眠ったりしませんでした。



アプリストアを数百万ドル規模に展開しましたが、どちらも非常に怖かったのですが、ローンチはうまくいきました。 今年のOpera Appstoreは月間1億人のユーザーに成長しました。



最初のテクニカルディレクターの間違いは、上級同志の誤算だと思いますか、それとも頭の無能だと思いますか？ チームはテクニカルディレクターを「教育/育成」できますか？



人は技術的な能力を獲得できます。 しかし、責任は最初にあるべきです-それがそこになければ、すぐに人を変えなければなりません、それは成長しません。 これは通常、インタビューで見られます。



どのような場合を思い出せますか？



最も印象的なケースは、おそらくLookeryの技術面を率いたYuri Monastyrshinです。 責任は、すべての問題に対する非常に高く、正しいアプローチでした-今、それらに対処する必要があります。



彼（5年生）が現在何億人もの人々に使用されており、1日あたり数十億回の視聴を生み出しているプロジェクトをどのように作成したかは、私にはまだ謎です。

Dmitry Shashlov、iOS開発者：

初心者のCTOはどのくらいの頻度で期限を間違えますか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



「ロシアの古代から」締め切りは日付を示し始め、その結果、周り​​の誰もがあなたがどれだけクールで明確にあなたがすべてをやり遂げたかをきしむでしょう。 これにより、何らかの理由で、すべてのマイルストーンも未知の方法で締め切りになりました。もしあなたがそれらに合わなければ、それを書いて、それはすべて失われ、終わりはすべてです、入札は失われ、誰も二度と働きません。



市場のほとんどのタスクは、当初設定された期限を超えることは自然です（技術的な要件のみで作業を開始しますか？）、正確に分析し、議論することができる必要があります、期限を逃した理由、それに影響した要因、および状況を繰り返すために取られた措置これと同様に、その後は発生しませんでした。



従業員間でタスクを設定および分散する際に、初心者のCTOが間違っている頻度はどれくらいですか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



私が何よりも80％働いていたチームは30人までの技術者で構成されており、その中で問題の声明に対する以下の反応は非常に一般的です。



-A.「これまでにやったことのない作業に自信がない」



-B.「サイトを作成しますか？ 素晴らしい、同時にPerl'eで解析する方法を理解します»



-C.「テーブルで結合するのは若者向けです。普通の仕事をしてください！」



-D.「検証ツールは統一されますか？」 そうでない場合-8時間、そうである場合、10-12。



そして、コンストラクター：フォースBで調査する必要がある場合、その合理的な計算により、Dを使用することは非合理的です。 Aを助けるために同志Cを与えると-しかし、最初のものは充電され、2番目のものはかゆみを止めます。 だから、おそらく、最も重要なことは無関心ではなく、工夫を適用することです。



どのスペシャリストがテクニカルディレクターのミスに苦しんでいますか？ テスター、開発者、プロジェクトマネージャーですか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



テクニカルディレクターが十分な管理経験を持っている場合、その後のプロセスに不可欠なエラーにつながる可能性のあるすべてのタスクは、通常、タスクの直接実行に関与する技術スタッフ（またはチームリーダー）に委任されます。自分の決定から。



ここでは、意思決定が行われる組織レベルに大きく依存します-さまざまな状況で、個々の従業員が「苦しむ」（意思決定が必要なコンテキストに関係なく、自分自身に近い意思決定を行う）、チーム全体（技術的なタスクが誤って計算されました）初期データの量が不十分であるため、実装に重要な特定のポイントに注意が払われず、製品の必要な一貫した実装を理解せずに管理が行われました。



しかし、もちろん、間違いを犯さないようにするのではなく、それらから正しい結論を引き出すことができることが重要です：計画の間違いは何でしたか、どの従業員に意思決定のより多くの/より少ない自由が与えられるべきか、どのテストが最初に実装仮説をテストするべきかなど



最初のテクニカルディレクターの間違いは、上級同志の誤算だと思いますか、それとも頭の無能だと思いますか？



評価は純粋に主観的なものであり、CTOがあなたが取り組んでいる役割に依存します。ギブアンドブリング氏を上級同志として扱うことはほとんどありません。 それどころか、CTOもプロセスの参加者であり、CTOが生産プロセスに直接もたらすメリットが具体的であると感じている場合、重要なことに、技術責任者として、「このJediにはより多くの力がある」と感じますそのようなリーダーに敬意を払い、自分の失敗を一般的なものとして認識し始めます。 確かに、表紙にくっついて、ひどく壊れてしまう危険性があります-これはあなたの貯金箱で人々を読む能力の経験です。



チームはテクニカルディレクターを「教育/育成」できますか？ どのような場合を思い出せますか？



可能性が高いはい。 しかし、それを強化できるのはチームだけです。

ビクターRpslアナウンサー。 オーケストラの男。

みなさんこんにちは、まず第一に、私たちの世界は多面的であり、指導者の間違いや無能について急いで結論を出すことはできないことを強調したいと思います。 異なる位置を占める場合、「鐘楼」は異なり、それらからのビューが対応して開きます。 多くの場合、現時点で誤算と思われるこれらの省略は、長期的には有用であるか、ビジネスによって決定されます。



初心者のCTOはどのくらいの頻度で期限を間違えますか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



テクニカルディレクターがタスクのタイミングに非常に間違えた話を思い出せません。 開発者としての経験が豊富な上司は、問題の解決方法、使用するツール、および所要時間を非常によく知っています。 通常、タスクに明確な期限が設定されている場合、テクニカルディレクターです。 彼は常に時間の「バッファ」を設定し、さらに実行者とタスクの実行を調整します。 このようなアプローチにより、タスクが「研究」計画ではなく、重要なものである場合、タスクが常に時間通りに完了することが保証されます。



従業員間でタスクを設定および分散する際に、初心者のCTOが間違っている頻度はどれくらいですか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



従業員間のタスクの分散について話すと、間違いがはるかに頻繁に発生します。 「すでにこれを行っているので、もっと早くやる」という原則に従ってタスクが分散されていることをよく見ました。 繰り返しますが、それが間違いであるかどうかは長い間議論されていますが、長期的にはチームがシステムについての理解を失い、全員が狭いプロファイルの専門家になり、システムの他のコンポーネントと連携することができなくなります。



私の仕事では、パフォーマー間でタスクをシャッフルし、「機能所有者」とみなされる人がいないようにすることを好みます。このアプローチにより、すべての人がすべてに遅れずについていくことができ、さまざまなコンポーネントを多面的に見ることができ、チームの雰囲気が向上します。



どのスペシャリストがテクニカルディレクターのミスに苦しんでいますか？ テスター、開発者、プロジェクトマネージャーですか？ どのような場合を思い出せますか？ これはあなたにとってどれほど重要ですか？



リーダーの過ちは彼の部下によって最も影響を受けます。何が起こったのかを掻き集めなければならないのは彼らだからです。 これは、タイムラインの約束と間違ったツールまたはアプローチの選択の両方に適用されます。 選択したソリューションが適切であり、新しい要件が出現した状況とこれを混同しないことが重要です。 これは通常の状況です。これは、計画の誤りではなく、実行する必要がある作業です。



私の練習から、私はすでに何年も前の瞬間しか覚えていません。標準を変更し、svnでgitに、netbeansでアイデアに切り替えるようにテクニカルディレクターを説得したことを覚えています。 私のすべての試みは誤解の壁と「これらのツールは新しいものをまったく与えない、現在のものではまったく同じことができる、つまりプラットフォームを変更する意味がない」という主張に打ち勝ちました。



最初のテクニカルディレクターの間違いは、上級同志の誤算だと思いますか、それとも頭の無能だと思いますか？



他人の間違いに対する個人的な認識は非常に主観的なものであり、このプロセスが行われている人々とその関係に依存します。 失敗したときに喜ぶ人もいれば、共感する人もいます。



チームはテクニカルディレクターを「教育/育成」できますか？ どのような場合を思い出せますか？



上司は部下を教育しなければならないので、チームは絶対に上司を教育しなければなりません。 一方にはビジネスがあり、もう一方にはない人生の健全な関係はありません。 私は行動の要因に深く入りたくありませんが、上司、テクニカルディレクター、またはチームリーダーは、部下にとっては一種の「ガチョウのお母さん」でなければなりません。



すべての親友と一緒にいる必要はありませんが、チームをかわして、みんなと一緒に、そしてお互いに顔を合わせて、常に人々と通信しないことが非常に重要です。



私が初めてチームリーダーを務めたときは、毎月少なくとも1回は部下と夕食に行くことを決めていたので、心から話す機会がありました。 会社で行われているプロセスと近い将来に予定されていることについて話すことができ、みんなはチャットやチャットでまったく言いたくないことを話し合うことができました。 このテーマに関する多くの本、たとえば「猫の放牧方法」がありますが、それらはすべて、私が説明できるよりもはるかに優れています。



ご清聴ありがとうございました。



PS

専門家の声明が誰かを興味深い結論に導いたことを願っています。 おそらく、誰かが自分の物語の中で自分自身を認識し、誰かがすべてが正しく行われていると確信しました。 いずれにせよ、プロジェクトの成功または失敗は、テクニカルディレクターのエラーの数ではなく、作業全体の最終結果によって決まります。 この観点から、CTOの「不可fall性」は二次的な要因のようです。