より小さい単位のソフトウェアを出荷し、ローカル ホスト ブランチのサイズを制限する

過去 10 年間、 HackerNoonを率いて、私は多くの才能あるソフトウェア開発者と仕事をしてきましたが、彼らの在職期間の早い段階で、私はたいてい同じことを言ってしまいました。つまり、より小さな単位のソフトウェアを出荷し、ローカル ホスト ブランチのサイズを制限するということです。なぜ？主な理由が 2 つと大きな理由が 1 つあります。

1. あなたがプロジェクトの完了に向けて作業を続けている間、ユーザーはあなたの仕事からより多くの利益を享受し、フィードバックを与えます。

6 か月分の作業が必要なプロジェクトがあり、その後 6 か月間公開されなかった場合、ユーザーは 5 か月と 30 日ほど作業から何のメリットも得られないことになります。それがライブである場合にのみ、インターネットの残りの部分があなたが発送したものから恩恵を受ける機会さえ得られます。それでも、それはちょうど養子縁組をめぐる大規模な困難な戦いが始まるときです。代わりにプロジェクトの一部を毎週出荷すると、ユーザーはプロジェクトのライフサイクル全体にわたって価値を獲得し始めるでしょう。

私の元同僚であるデーン・ライオンズはかつて私にこう言いました。「私たちは価値の原子単位を追加し続け、必要なだけリリースを行うべきです。 [機能] に満足して次に進む準備ができるまでに、簡単に 10 回のリリースが必要になるでしょう。」

CEO として、私はよく新入社員が収益貢献者になるまでにどれくらいの時間がかかるかで判断します。営業の場合、これはより厳密であり、彼らの売上は報酬を上回りましたか?もちろん、マーケティングやインフラストラクチャなどの限界費用など、考慮すべきことは他にもありますが、どのように切り取っても、ソフトウェア開発者が営業担当者よりも収益にどのような影響を与えるかを測定するのは困難です。ソフトウェア開発者として新しい役割を担っている場合は、ホームランを狙う前に、シングルをうまくつなぎ合わせてみることをお勧めします。

ソフトウェア開発というゲームでは、スコアに関する普遍的なルールはありません。確かに、ポイント システムを割り当てる人もいれば、KPI を定義する人もいますが、結局のところ、価値を生み出すかどうか、そしてどのように生み出すかを決めるのは製品を使用する人々です。より早く発送することで、より早くフィードバックを受け取ることができます。あなたのソフトウェアを使用している人は、プロジェクトの次のアトミック ユニットをどのように構築するか、構築しないかをより明確にします。

2. ブランチが本番環境の現実から乖離すればするほど、チームメイトがプロジェクトに貢献し、隣接するプロジェクトを前進させることが難しくなります。

最新バージョンが出荷されないことによる外部性は、最初はわかりにくい場合があります。すべてはつながっています。たとえば、HackerNoon のような製品では、プロフィール ページとストーリー ページは孤立して存在しません。これらは 1 つの製品内で接続されたページとして存在します。 1 つのページの機能に変更が発生すると、そのページに接続されているすべてのページの機能に影響します。

ローカル ブランチが非常に大きい場合、その大規模なブランチが最終的に本番環境に出荷されると、ローカル ブランチに接続されているページや関数で行われる他の変更が機能しなくなることがよくあります。これでは物事が壊れてしまいます。これによりバグが発生します。そのため、作業をやり直す必要が生じます。これにより、チームメイトはあなたと一緒に働きたくないという願望を抱くことになります。これにより、ローカルブランチですべての作業を行う前にすでに得ていたものよりも悪い製品エクスペリエンスが作成される可能性さえあります。

小さな変更をより定期的に行うことで、他の人が貢献できるようになります。彼らは、生産ベースラインが何であるかについてお互いがすでに合意しているため、自分たちが出荷するものでも機能すると感じています。インクリメンタルはあなたの味方です。それはあなたを現実と結びつけます。段階的な変更が製品にマイナスの影響を与えているのであれば、同じ方向へのより大きな変更が製品エクスペリエンスにプラスの影響を与えるとなぜ考えるのでしょうか?

そして、古くからあることですが、大きすぎる枝になる可能性のある大胆なプロジェクトを恐れる必要はありません。なぜなら、あなたはこのクソみたいなことが人々にどのように機能するかに変化をもたらすことができる悪い人だからです。

プロジェクトによっては、単純に大規模なブランチにする必要があるものもあります。たとえば、新しいデータベースのような大規模な依存関係を持つものは、既存の使用法に深く根付いている可能性があるため、時計を逆戻りして、毎年オンプレミス 2.0 リリースのようにプロジェクトに取り組むことが最善です。また、ChatGPT のような他の画期的なテクノロジは構築に非常に時間がかかるため、トレーニングされていない不完全なクソ UX バージョンの新しいテクノロジをリリースすることは採用の意味がありません。大きくスイングしてください。滑走路があるとき。チームが参加しているとき。しかし、誇張しないでください。ほとんどの場合、ソフトウェア開発は車輪の再発明ではありません。それは単に次の原子ユニットを出荷するだけです。