すべてのスタートアップが従うべきグッドプラクティス[終了]

職場の友人数人が小さなスタートアップをセットアップし、独自のソフトウェアを作成します。おそらく、最初の仕事は月明かりです。まだ仕事をやめる余裕がないためです。

私たちのどちらもこのような経験はありません。以前に他の会社で働いたことがあり、一連のガイドラインが設定されています。これは、従うべき慣行を確立するときだと思います（例：ミーティングを避ける）。

このように行った人たちに、どのようなアドバイスをしてくれますか？

次のようなものの技術的な側面をもっと探しています。

• ある種のビルドサーバーを用意する価値はありますか、それともはるかに進んでいますか？

• 広範なTDDを行うか、経験の浅い小規模なチームにとってオーバーヘッドが多すぎると思いますか？

しかし、物事の管理面に耳を傾けてもかまいません。

プロジェクトはASP.NET MVCで実行されるWebアプリケーションです。リモートで作業するので、MercurialとBitBucket、Kiln + FogBugz、またはその他のオンラインプロジェクト追跡ツールを使用することを考えています。

1. できるだけ早く解放します。開始するコードの90％が最初の6か月を過ぎない可能性があります。したがって、それを狂ったように設計する意味はありません。市場投入までの時間をできるだけ早くコーディングし、ユーザーがそれをさらに開発する方法を決定できるようにします。TDDが最も速くコーディングする方法である場合は、TDDを使用します。それ以外の場合は、ハックしてください。早期導入ユーザーは、製品がベータ版の場合、いくつかのバグをかなり許容します。

2. システム管理者であるあなたの時間を無駄にしないでください。バグ追跡（例：FogBugz）とソース管理のためのホストされたプラットフォームを使用して、適切なアイデアを得ました。Googleドキュメントなどのオンラインドキュメントリポジトリを使用します。ローカルに何かを保存する場合は、Carboniteなどのオンラインクラウドバックアップサービスを使用してください。実際の環境では、余裕がある場合は、フルマネージドのホスティングソリューションをレンタルしてください。独自のサーバーを維持する必要がないようにしてください。

3. あなたのユニークな点に集中してください。以前に行われたはずのコードを書いていることに気付いた場合は、すでにあるコードを使用してください。ビジネスの問題を解決する専門家になり、ドメイン外の問題に気を取られないようにします。

チームがあなただけではない場合、標準が重要になります。それらは複雑である必要はありません（「意味のある変数名、CamelCaseを使用し、ビルドを壊さない」）。TDDは動作するので揺るぎません。使用してください。思いついたテストは、すぐにデモの優れた基盤にもなります。ビルドサーバーはオーバーボードである場合がありますが、そうでない場合があります。それなしで始めて、それがどうなるか見てください。同様に追跡ツール。必要に応じて後で追加できます。

この製品が販売されることを想定して、市場調査を行って、人々が実際に欲しいものを構築していることを確認してください。ゼロから市場へと進み、責任と公平性を分割し、お互いに責任を負うためのビジネス計画の概要を説明します。

幸運を！