この記事の歴史は、少なくとも7年前、ドイツのWeb企業で働いた後、大規模なエンドカスタマーの管理下にあり、リモートで作業を開始したときに始まりました。
人生は落ち着き、子供は成長し、少し自由な時間があり、私は少しフリーランスを始めました。 しばらくして、同様の経験を積んだ数人の友人と一緒に、小規模なWeb開発会社を組織し、とりわけローカル市場を開発し、大規模なプロジェクトを調達し、一般にさらなる開発を行うことにしました。
組織作業や他のルーチンの最初の時間はたくさんありましたが、これはほんの数年後に自分の感覚に達し、最終的に私が好きな方法で働いていること、さらにはそれらの基本的なこと私の仲間は、おそらく彼らがまったくいないからです。
そして、最後に、私にとってこれらの自明で明白なことは、「マニフェスト」（hehe）、コンセプト、説明、および会社がIMHOなしで働く価値がないもののリストを作成することにしました。 これはクライアントと働くことではなく、管理そのものではなく、お金やビジネス計画ではなく、ウェブのために（そしておそらくウェブだけでなく）開発者の小さな会社の仕事を組織化することについてであることを明確にします成功し、開発するために重要なことを行うこと。
プレゼンテーションに少し一般性を持たせるために使用されたテクノロジーとソフトウェア製品は無視しようとしますが、小規模企業でのWeb開発の詳細に焦点を当てることが重要です。これは、多数の比較的小さなプロジェクト、他のテクノロジーとサービスへの依存、およびさまざまなアプローチ同じ問題を解決し、プロジェクトのテクノロジーを選択することさえできます。
定義から始めましょう。
開発者の小さなグループ（5〜6人）が仕事をするために会社（会社）に団結しています。
- この会社の活動から収入を得る
- この作業と結果をお楽しみください。
既に知っている方法とやりたいことに基づいて、当社は以下に対処する必要があります。
- まず、ウェブ用にさまざまな複雑さのプロジェクトをプログラミングすることにより（大規模なソフトウェアシステムから数ページのボリュームを持つ名刺まで）、
- お客様のニーズとお客様のニーズに合わせて独自のホスティングサービスを実施し、
- リモートサーバー（主にホスティング用）、サービス、およびデータベースにシステム管理サービスを提供し、
- ウェブデザインをする
- ウェブ技術の分野でサポート、SEO、コンサルティングに従事する。
つまり、計画からウェブサイトのプロモーションまで、クライアントに完全な作業サイクルを提供することです。 もちろん、このリストの順序は非常に重要です。 ここでは、開発/プログラミングに焦点を当て、システム管理に従事することを宣言しますが、原則として、私たち自身のプロジェクトをホスティング内でのみ行い、ここで誰とも競争しません。 プロジェクトにはデザインも必要ですが、Webスタジオとしての位置付けはしていません。デザインは私たちにとって優先事項ではありません。 また、サポートとSEOは完全に二次的であり、完全なサービスサイクルのコンテキストでのみ重要です。
人的資源から、初心者にとっては、自己学習が可能な少数の開発者/プログラマーのみがチームに成長し、その後のいくつかの同様のチーム（ユニット）へのその後の拡張と変換を目指します。 有能なシステム管理者が必要です。 また、おそらく継続的にではなく、最初はデザイナーとseoshnikが必要です。 そして、おそらく最も重要なのは、関心のあるリーダーが必要だということです。 ディレクター、プロジェクトマネージャー、アナリスト、オーガナイザーなどが1人で。
基本的な値を決定することも重要です。 将来の会社の安定した発展を確保するために、各従業員に専門的な成長の機会を提供し、開発者間で知識と情報を交換するプロセスを最大限に刺激し、簡素化したいと考えています。 開かれた雰囲気と、学び、そして特に知識を共有したいという願望は、あらゆる方法で奨励されるべきです（とりわけ、そのような雰囲気自体が優れた動機付け要因として機能します）。 ただし、合理的な方向でのプロセス全体の方向も必須であり、ここではいくつかの制限なしに行うことはできません。 そして、このような制限の結果として達成したい最も重要なことは、もちろん、開発者の可能な限りの互換性です。
余談として、素材に関するいくつかの言葉（ワークステーションについて）。 もちろん、マイクロソフト製品用に開発しているのでない限り、ここではプロプライエタリなソフトウェアを使用しないでください。 経験から、今日のオープンソースソリューションで十分であり、MS Windowsの下でオフィスに1台のマシンのみを保持することは理にかなっています（デザイナー、視覚テスト用）。 ただし、開発者を、たとえば1つのLinuxディストリビューションのみのスコープに制限することは意味がありません。ここでは、誰もが自分の仕事を自分の好きなように編成する権利があります（一般的なツールを除く-以下を参照）。 ただし、内部開発サーバー（以下も参照）ですべて（またはほとんどすべて）の開発を行うことは理にかなっています。これらの目的のために、適切なハードウェアとネットワークを使用しないでください。
さて、このすべてを理解し、それらに割り当てられた役割があるとしましょう。
チームはどのように働くべきですか？
私の意見では、私たちの仕事には次のこと/実践/アプローチが必要です。
だから、重要：
- 単一のコーディングスタイル（表記法と一般原則）を使用します。 小さなドキュメントでルールを発行します。
- 共通のIDEおよびその他のツールの共通セット（データベースソフトウェアなど）。 メッセンジャーは、もちろん誰でも好きなものを使用できますが、同じ技術で作業しているので、お金がかからなくてもIDE動物園を維持することはできません。
- すべてのプロジェクトにバージョン管理システムを使用します。 少なくともコードを表示することは（少なくとも「どこで既にこれを行ったのか？」を検索するために）意味があります。1人だけがプロジェクトで作業している場合でも、展開のために、クライアントの要求に応じてロールバックおよび変更を行います。 私たちの会社で好まれている私見は、まだ分散型ではなく、集中型のリポジトリ組織です。
- 単一のプロジェクト管理システム（PMS）によるすべてのプロジェクトの管理：基本計画、タスク追跡、リクエストとバグ追跡、時間追跡、部分的にCRM。 もちろん、自分のニーズに合わせて独自のものを作成することは望ましいことですが、既成のものにすることはできますが、望ましくありませんが、私の観点からは、サードパーティのサービスを使用します。 たとえば、プロジェクトマネージャーが（通常はデスクトップ上のフォルダーに）保存することを決定した顧客または通信からのファイルがある場合、すべてのドキュメントを配置するための厳密に定義された順序がある状況を許可してはなりません。
- ドキュメント、書籍、ヘルプファイルなどを含むリソースの必須の使用（作成、更新、更新） -一般的な知識ベース。 コードスニペットとステップバイステップの説明を会社全体の構造化されたwikiリソースに削除します。
- コードをテストすることをお勧めします。 プロジェクトの特に重要な部分の単体テスト。理想的にはTDDが標準です。
- ドキュメントを生成するために、特定の1つのシステムに対して1つのスタイルのドキュメントコードを使用します。 ただし、ドキュメントは、これが追加的に合意されたプロジェクトに対してのみ提供および維持されます。
- チームは、1つまたは2つのフレームワークを適切に管理し、それらだけを使用して比較的複雑なプロジェクトを開発する必要があります。
- 比較的単純なプロジェクトには1つまたは2つのCMSを使用します。すべてのチームメンバーについてそれらを調査することが望ましいです。
- 同時に、比較的多数のDBMSを操作する価値があります。
- 常に自己教育、新入社員の研修、インターンに取り組みます。 まず、一般的な毎週のセミナーを開催します。 また、コードフラグメントを定期的に分析し、ペアプログラミングを練習することもお勧めします。
- 新しい技術と作業方法の開発を計画します。 ソフトウェアの新しいバージョンへの計画的な移行を実行します。
- 有能なプロジェクト計画の実施に努め、短いサイクルで反復計画を優先します。 各プロジェクトの終了後に分析と結論を出すには、実際のコスト、開発チームの速度などを評価することが不可欠です。これをPMSに反映することが非常に望ましいです。
- タスクの計画と管理に加えて、各プロジェクトの短い技術仕様を作成し、最新の状態に保つことが不可欠です。
- 仕事のための候補者の恒久的な募集とスクリーニングを実施するために、彼らの訓練に関する計画された仕事
- 会社の短期およびグローバルな開発計画を立てる。 定期的に修正してください。
- 適切なマーケティング戦略を立てる。
- 開発は開発用の別のサーバーで実行され、このサーバー上のリソース（作業中のサイト）のサポートと配置の唯一のスキームが重要です。 開発プロセスにおけるプロジェクトの3レベルのレイアウト：開発、プレビュー、生産。 開発とプレビューは、1つのオフィスサーバーに物理的に保持できます。 すべての開発サーバーリソースは、認証を必要とするか、ローカルネットワークからのみ、読み取り専用モードでのみ利用可能である必要があります。
- リソースへのアクセスレベルを提供するための単一のコンセプト/スキームが必要です：誰が、何を、どこで、いつでも。 たとえば、少なくとも新しい従業員のリポジトリへのアクセスを、別のプロジェクトまたはその一部の両方およびオフィスからのみに制限する必要がありますが、会社のすべての人およびすべての人が共通のナレッジベース/ wikiリソース（承認用）にアクセスできるようにする必要があります。 言い換えれば、企業内でのオープン性、情報交換、経験の交換を促進するために、情報漏えいの防止についても考慮すべきです。 この点で、各開発者に、そのプロパティが彼が会社のために書いたコードになるという概念を伝えることも重要です（しかし、無理しないでください！）。
- オフィスと開発サーバー用の単一のバックアップスキームが必要です（本番環境へのバックアップは別のタスクです）。 最も単純なケースでは、開発がサーバー上でのみ実行される場合、ワークステーションはまったくバックアップできないため、この質問はだれが作業するのかを考慮してください。
- ワークステーション上の統一された独自のソフトウェアポリシー。 各warezプログラムのインストール時（理由と期間）、ディレクターの通知は必須と見なされます。 ソフトウェアのライセンスされたコピーのみを使用するよう努めてください（はい、必要に応じて購入します）。
- プロジェクト管理機能と開発機能を明確に分離することが重要です。 プログラマーが実際にクライアントと直接接触することはありません。すべてのタスクはプロジェクトマネージャーを経由する必要があります。 開発者が複数のプロジェクトで同時に作業しないように努めます（もちろん、可能な限り）。
各アイテムは、理由のためにこのリストに表示され、合理的に詳細にすることができます。 それにもかかわらず、上記のすべては、結局のところ、個人的な経験の結果であり、したがって、完全であるふりをすることはなく、最終的な真実でさえありません。
ここで、可能であれば、簡単に、それですべてです。