中小企業から大企業への移行[終了]

新興企業から大規模組織に移行するアプリケーション/データベース開発者のためのヒント、考え、警告、または一般的な知恵はありますか？

考えの例には、次のようなものが含まれます。

• 管理チェーンと異なる方法でやり取りするにはどうすればよいですか？
• 大小で異なる品質または開発速度の傾向が見られますか？
• チーム開発者の考え。
• 社会的側面。
• 他に何か。

追加：誰かが同様の動きと共有する個人的な物語や経験を持っていますか？

何らかの方法で明確にできるかどうかを教えてください。

ご意見ありがとうございます！

共有するいくつかの個人的な経験：

• 移動前：

  • すべての大きな約束を信頼しないでください。彼らは才能を探しているので、彼らはあなたにすべての良い面を見せて、それらの悪い事実を隠します。位置がある場合はその良い、なぜそれが私の前に満たされていませんか？:-)
  • ビジネスはビジネスであり、唯一の目的は利益を上げることです。機内に持ち込むことが目的に価値をもたらすかどうかを考えてください。彼らはあなたが付加価値をもたらすと考えるので、あなたは招待されています。あなたはそうする？
  • あなたがプログラマーであると仮定すると、大企業は通常、技術的な課題以外の複雑さ、例えば政治、コミュニケーションスキル、規制などを伴います...準備はできていますか？

• 移動後：

  • 機能グループ（部門）のKPIをできるだけ早く特定するようにしてください。簡単に言うと、なぜこの大企業は、こうしたことをしている人々のグループにお金を払うつもりなのでしょうか？
  • 上記の答えを見つけた場合、自分自身を上記の回答の要因として位置付けます。ボーグと戦わないでください。あなたは勝つつもりはありません。従うために支払われます。
  • 良いものを作り、良い仕事をすることは、通常、最も難しい部分ではありません。

• うまくいくとき：

  • 少しずつ改善し、座って文句を言わないでください。
  • 難しい仕事をすることを恐れないでください。あなたが重要な役割にある場合、あなたは削除される可能性が低くなります。
  • 地球上の最後の一滴の水であるかのように資源を使用します。
  • 管理職の役割があなたとあなたの将来のキャリアパスにとって良いかどうか、何度も考えてください。優秀な管理者であるエンジニアはあまり多くありません。

• 物事がうまくいかないとき：

  • 少なくとも1か月（時間またはお金の;-)でパニックしないでください。
  • 繰り返しますが、戦わないでください。彼らが心を変えることができるなら、彼らはすでにそうしました。
  • 何があっても、sh_tsが発生します。それは正しいか間違っているかではなく、一致するかどうかについてです。
  • 世界は1社よりも大きい。機会は、準備ができている人のためのものです。

乾杯！

• 管理チェーンと異なる方法でやり取りするにはどうすればよいですか？

大企業は、あなたが慣れているよりも官僚的です。上下のレイヤーを操作します。スキップはまれです。

• 大小で異なる品質または開発速度の傾向が見られますか？

より多くのレイヤーがあります。実稼働サーバーへの管理者アクセス権がないため、より多くのハンドオフが発生します。大企業では、通信チャネルと文書化およびプロセスによって速度が低下します。

• チーム開発者対カウボーイコーディングに関する考え。

無関係。大きくても小さくてもどちらでもかまいません。

• 社会的側面。

大企業は、失うものが多いため、保守的な傾向があります。

大企業には1つの大きな利点があります。給与計算の方法を知っています。私が一緒に働いていた中小企業のいくつかはそれに失敗しました。小規模企業にとっては、売上と収益の流れを維持することが問題になる可能性があります。

• 他に何か。

あなたは多くの人の中で一つの声になるでしょう。あなたの影響は、ムーバーやシェーカーと自分をどれだけうまく統合できるかにかかっています。

自由と境界

私の経験で考えられる最大の違いは、境界と柔軟性の違いです。中小企業の場合：

• あなたはより多くのことをする必要がある開発者としてより大きな役割を果たし ます。サーバーのセットアップ、ソース管理システムの構成、Company Product Xのデータベースの管理など です。

• もっと社交的です-会社のオーナー/ディレクターなどと関係があるかもしれません。

• あなたの意見が会社の周りでさらに広がるにつれて、あなたはより多くの影響力を感じます。

大規模な組織に移行すると、境界はより明確になります。

• あなたの役割はもっと具体的です。

• ほとんどあなたがプログラマーになっただけ です。

• タスクの更新についてプロジェクトマネージャーに報告します。

• インフラストラクチャは、サポート/コミュニケーションチームによって管理されます。

• UATテストを実行し、バグ追跡システムのバグを回避するテストチームが時々存在します。

• 人々が人々の海で登り、気づかれようとしている明確な階層があるので、それはより競争力があります。

両方の環境で働いている人として、ここに私の考えがあります：

• 管理 -おそらく、多くのコミュニケーションが「階層で失われる」ことがわかるでしょう。これが私が意味するのは、小さな会社では、ほとんどすべての人がすべてを知っているということです（少なくとも「知っている」）。大企業では、ミドルマネージャーが何に取り組んでいるのかわからないことは珍しいことではありません（チームリーダーの仕事です-チェーンの上下で情報の粒度が失われます）。
• 開発の品質と速度 -これは、大企業ではより遅くなる傾向があります。スタートアップはより機敏である傾向があります（これの一部は、小さな会社の製品が小さい可能性が高いという事実に由来します）。ただし、大企業には必ずプロセスと方法論が確立されている必要があるという考えに陥らないでください。特に、会社の主な能力がソフトウェアにない場合、ソフトウェアチームは小さなハックショップよりも優れた運営はできません。実際、私がこれまで働いた中で最高の場所の1つは、これまでのところ、小さなハックショップでした-主にそれが本当の小さなソフトウェアショップだったため-プログラマーによって開始され、実行されました。Joel Testのものでは12/12になります。
• チーム開発 -上記のとおり。本当にチーム次第です。大企業は必ずしも他の分野とは異なり、より良い経営をしているわけではありません。それは主に、ソフトウェアチームの担当者がどの程度「ソフトウェア開発能力」があるかにかかっています。ソフトウェアを十分に理解していないミドル/アッパーマネージャーは、特に大企業のソフトウェアチームの資金不足と不満を招きます。
• 社会的側面 -全体として、中小企業と新興企業は一般に非公式で社会的ですが、大企業も堅くする必要はありません。多くは、業界ドメインとチームの平均年齢に依存します。大企業の若くて緊密に協力しているソフトウェアチームは、独自の小さなスタートアップをほとんど感じることができます。

その他（私が考えることができるいくつかのランダムな考えと警告）：

• チーム間の競合に注意してください。大企業では、システムのさまざまな層を担当する別々のチームなどがよくあります。人間の性質、人間、人間の性質-ここには「私たちと彼ら」のメンタリティーがしばしばあることを意味します。等）。誰もが本質的に同じチームに所属している小さなスタートアップでは、これを見る傾向はありません。

• ソフトウェアがどのように機能するか分からない人からの注文に慣れる。もちろん、これはどこでも問題になる可能性がありますが、会社が大きくなればなるほど、「ビジネスマン」とソフトウェアチームの分離はより強く定義される傾向があります。小さなスタートアップでは、彼らはしばしば同じ人たちです。大企業では、ほとんどありません。会社が実際のソフトウェア会社（Microsoftなど）であれば、これはそれほど悪いことではありません。

• クライアントの「最前線」からよりシールドされる可能性があります。クライアントに対処するヘルプデスクとプロダクトマネージャーが存在する可能性が高く、おそらくほとんど必要はありません。これは良いことも悪いこともあります。直接的なサポートに対処する必要がないという意味では良いのですが、比較的単純な問題を解決するためにコミュニケーションの問題や退屈な所要時間があるという意味では悪いのです。

これは私が今のところ考えることができるすべてについてです。