私はCTOの地位にたどり着いたのは、「 開発者 -> シニア -> チームリーダー -> CTO 」という標準の道ではなく、「 PM- > シニアPM- > CTO 」です。 これには賛否両論があり、それ以上のものを言うのは難しいですが、常に十分な個人的な課題があり、技術的な過去がしばしば救われましたが、今はそうではありません。
4.強制グレード
字幕に付けたものに加えて、最初の間違いはまだ一般的なすべての評価に参加したいということでした。すぐに60〜70％の時間がかかりました。 徐々に、私はこれを拒否し、大きなリードにのみ従事し始め、私が信頼することを学んだチームリーダーの慈悲に小さな評価を完全に残しました。
アウトソーシングでの潜在的なプロジェクトの評価は、開発プロセスの認識を大きく変え、屋根裏部屋が行くことができるようにするものです。 最初の数ヶ月は、前のテクニカルディレクターの間違いを決して犯さないと確信していましたし、すべてのプロジェクトを受講するために成績を過小評価することもありませんでした。 最初は可能でしたが、2四半期後には、「 はい、それは5秒です 」と呼ばれた古い評価アプローチと新しい評価アプローチの境界がどこを通過するかが明確になりました。
明らかに、評価へのより近いアプローチにより、待機時間と評価自体の両方が増加しました。 営業部門からの苦情は、見積りを返す期限を遅らせ、絶えずそれらを誇張しているように見え始めました。 しかし、まあ、これはまだ戦うことができ、潜在的なプロジェクトのその後の人生全体と、それ自体のリスクを減らす会社自体にとってのこの段階の重要性を説明しています。 「 この機能にはX時間必要です 」というカテゴリからの議論は、明らかな理由でまったく機能しませんでした。販売には高品質は必要なく、安い必要があります。 しかし、プロジェクトを適切に評価する権利を求めて営業部門と戦うことがまだ可能であった場合、何かをする意志と欲求を完全に殺した実践は、精神のトップマネジメントからの手紙です。「 Guys、XYZは非常に大きな潜在的パートナーです、私たちは彼が必要ですフックアップ！ 「。 原則として、これはあなたの評価をあなたの耳に入れて時計回りに3回回すことができることを意味し、潜在的なパートナーは依然としてトップマネジメントが見せたいものを見るでしょう。 私のすべての実践において、これが良いものにつながることは決してなく、「損失を売る」ことは不可能でした。 最もひどいケースは、 3,000時間以上の見積もりを1,000時間に絞らなければならなかったときです。 私たちはプロジェクトに勝ちましたが、その損失は最終的に会社にとって大きな金額になり、長い間、皆に反響しました。
このような場合の2番目の特徴は、原則として、1日または2日でそのような評価を準備する必要があり、一定の過負荷と時間外のティムライドにより、追加の問題が生じることでした。
現在の日により近い、私はすべての聴衆の前で評価の数字を支持し、正当化することを学びました：営業から経営陣まで、しかし、「 N時間でサインインしてから別のN + 700を販売しよう 」などの冒険によく同意したという事実大きな間違い。
3.技術的な遅れ
特にアウトソーシングでは、ITの慣性が常に存在します。これは、個々のテクノロジーとコンポーネントがすぐに陳腐化することがあるためです。 また、ある技術またはツールから別の技術またはツールへの切り替えは、主にプロジェクトの合流点またはその大規模な段階で行われます。
会社にいる間、サービスステーションとしてだけでなく、開発エコシステムと競合他社を含むサードパーティのエコシステムを比較する機会が何度もありました。 時々私たちの遅れは非常に重要でした。ここで私はすべてを一度に話します：開発を加速および簡素化する新しいツールを使用しない、新しい（または他の）プラクティスを使用しない、開発者の継続的なトレーニングの可能性の欠如、継続的な市場分析の欠如など 多くの点で、すべて予算に依存し、日常使用に必要なエンタープライズソフトウェアを購入することもありました。これは問題であり、非常に永続的に達成しなければならない目標でした。 時には彼は山の頂上で口shouldを吹くべきであることを癌に証明することができましたが、これは大工が上昇して上昇するのと同じくらい頻繁に起こりました。 もちろん、そのような環境は完全に創意工夫を訓練し、さまざまな状況から抜け出す方法が常にありましたが、それでもまだ不健康です。
成功したとき、販売評価に新しいツール、ライブラリ、およびテクノロジーの簡単な調査を含めることを試みましたが、これはまれであり、定期的ではありませんでした。 その結果、時間がたつにつれて、ファッションのトレンドとそれに対応する見積もりのリクエストを失い始めたという事実につながり始めました。 特定のトピックに到達する方法がわかりませんでした。 例として、私たちにとって非常に長い間ブラックボックスであった拡張現実に関するプロジェクトに言及することができます。
この場合の私の間違いは、会社の技術レベルが手に負えないジャークで成長し、スムーズではない場合、全体として同様の状況の仮定を考慮することです。 ただし、空き時間と予算が限られている状況では、この状況を修正できる可能性はまだいくつかあることを認識しておく価値があります。そのうちの1つを以下に説明します。
2.ジョブの説明
私に直接触れた最も個人的なポイントですが、涙を流さないために、簡単に説明しようと思います。 作品のリストは事前に合意する必要があります-これは標準ですが、多くの場合、私たち自身の立場からこれを無視します。 新しいポジションに移ったとき、私は最初からそのような間違いを犯しました。 その結果、私は通常の機器の購入から、収益性の計画の達成や営業部門の再編成の試みなど、非常にワイルドなものまで、すべてを一度に担当するようになりました。 そして、もちろん、タスクの一部が失敗しました。なぜなら 私は何か他のもので忙しかった。
私は自分の職務内容を書き直し、調整しようとする試みを3回も受けましたが、すでにその数から、このプロセスは簡単ではないことが理解できます。 やってはいけない仕事に困ったら、30の触手がすでに宇宙服にくっついていて、下から行かせたくないので、それから抜け出すのは非常に困難です。 これはすべて、彼ら自身のアイデアの実装と直接的な実装のタイミングにその印を残しました。
これは大きな間違いです。なぜなら、 タスクのために多くの時間が殺されました。テクニカルディレクターは対処すべきではなく、それらについても考えてはいけません。
1.候補者
おそらく、多くの人々にインタビューしなければならない人の心痛は、多くの場合、あなたが本当に好きな候補者を引き受けることができないことと、会社をジュニアプランテーションに変えないための上級管理職との絶え間ない闘争です。 原則として、ここでのポイントはお金と条件です。 悪い開発者を雇わなければならなかったと言ってはいけません。 それどころか、私たちとの選択はつねに厳しかったので、私は先輩や親愛なる候補者が私に何をもたらすことができるかを常に理解していました。 これは経験だけでなく、知人、新しい専門知識、新しいアイデア、批判的な見方などです。 しかし、そのようなプレーヤーを獲得するコストの問題は常に優勢でした。
多くの場合、各ポジションに金銭的上限が割り当てられたという理由だけで、私が話したばかりの候補者の履歴書を脇に置いていました。 これは標準的な慣行ですが、私の間違いは、このアプローチに同意し、後に財政と専門知識の観点から候補者の重要性を正当化することを学んだことです。 そして、ここでかなり高価な開発者について話しています。
これは、新しい開発オフィスを組織するために去ったときに起こりました。 それは私が人を雇うことについて決定を下した唯一の人だったとき、私は、例えば、10人中8人の場合、まさに最も好きな人を正確に連れて行くことができました。 私は多くの論争を経て、取締役会と高価なRFP候補について話さなければなりませんでしたが、それは価値があり、私が採用できた幸運な人々は誰も期待しなかった素晴らしい結果をもたらしました。 そのとき、これらの人々の仕事の結果と彼らのアイデアや提案の束を持って、特定の候補者を採用したいという願望がどのように実証されるべきかを正確に実感しました。
ここで重要な点は、親会社を雇うことは会社の技術的成長のための選択肢の1つに過ぎないということです。 これが、私たちが拡張現実の専門知識の問題を解決した方法です-特にこの分野で豊富な経験を持つ人を雇うことによって。
エピローグ
これらの各点について、大きな記事を書くことはかなり可能ですが、今はできません。 もちろん、以前の同様の経験がなかったために、これらだけでなく、多くの間違いが犯されましたが、これにより苦味が減ることはありません。 すべてが明確で意識的なものになったのは素晴らしいことです-これが開発のすべてです-そしてこれをすべて経験と新しいスキルに変換できたのは良いことです。 これはビジネス側からの見解ではなく、人間であり続けたいという願望であるという事実について長い間書くことができますが、これはまったく別の話です。