ジャイアントを管理する方法：Web開発におけるチームの構築と構築プロセスのルール

ロシアでは、5,000社以上の企業がカスタムWeb開発に取り組んでいます（分析機関Taglineによる ）が、私見では、市場はまだ初期段階にあります。 多くのデジタル企業、Webスタジオ、インテグレーターは、実際には大規模プロジェクトの品質開発とサポートの準備ができていません。 AGIMAは 、入札で選択した現在の請負業者が実施する作業の質に不満のある企業からしばしば連絡を受けます。 ロシアの大手企業と長年にわたり仕事をしてきましたが、私たちは大規模なインターネットプロジェクトの開発と開発を組織する上で膨大な経験を蓄積してきました。それを共有したいと思います。 この記事では、インフラストラクチャを適切に編成し、チーム間のコミュニケーションを構築し、「ジャイアント」と連携する際にエージェントサービスの重要なコンポーネントを忘れないようにする方法を説明します。



主要なプロジェクトとは何ですか？ プロジェクトがプロジェクトチーム全体で毎月合計2500人以上の工数を生み出した場合、マネージャーの仕事はカウントしません。 作業の構成によって、これは通常、800〜1000人時の並行する2〜3の大規模なタスクと、テクニカルサポートの特定のサブスクリプションの一部としての5〜6の小さな日常タスクです。 これは、大規模な保険会社、銀行、大規模なオンラインストア、企業ポータル、HRポータル、およびメディアのサイトです。

記事であなたを待っているもの：

大規模プロジェクトの開発、開発、およびサポートにおけるチームとプロセスを編成するための要件に関するマニュアル。 カスタムWeb開発の市場での10年の経験に基づいています。 この間、100以上のプロジェクトを立ち上げることができました。 過去2年間、私はAlfaStrakhovanieプロジェクトの開発とサポートを管理してきました。

誰のための記事ですか？

この記事は、プロジェクトマネージャーや、Webアプリケーション開発プロセスの組織やクライアントとのやり取りに何らかの形で関係するすべての人にとって興味深いものになります。

免責事項：

この記事は万能薬ではなく、著者（AGIMAのエグゼクティブディレクター、エフゲニーロバノフ）の純粋に個人的な意見です。

おめでとうございます、あなたは大きなプロジェクトを持っています！

どうやって得たのかは関係ありません。 多くの場合、大規模なプロジェクトは単純なタスクから成長します。クライアントを小さなタスクで満足させ、全体としてサポートと開発を提供するか、クライアントと一緒に成長するかのいずれかです。これが最適なオプションです。 しかし、おそらくあなたはただ捨てて、自分でそれを期待せずに、大規模なプロジェクトをサポートし、開発するための入札に勝ちました。

たとえば、最初の「巨大な」プロジェクトの1つは、seo'shnikovの要件に応じた小さな技術的な改善から生まれました。 ある時点で、クライアントは次のように述べました。「新しいバージョンのサイトを立ち上げたいと思っています。ほとんどすべての準備ができていますが、現在の請負業者はそれを終えることができません。 迅速に改善する方法が気に入りました。 終了して起動しますか？」 私たちは契約を結んだという事実に直面しましたが、このレベルのプロジェクトのためのインフラストラクチャとプロセスがありませんでした。 どうする？

チーム

最も重要なことから始めました-プロジェクトのために新しいチームを別々に形成しました。手がなければ、大量のタスクを「消化」することができないからです。 チームを選択するプロセスは、最も困難で長い段階の1つになりました。 多数の履歴書をフィルタリングし、多くのインタビューを行いました。 これらはプロジェクトの重要な役割であるため、プロジェクトマネージャーとチームリーダーとの検索を開始し、チームのさらなる選択にすでに参加しているため、他の参加者の検索により効率的にアプローチできました。



最初の行



大規模なプロジェクトでは常に多くのコミュニケーションが行われます（この場合、クライアント側に特定の種類のタスクを担当するマネージャーが3人以上いたため）単一のエントリポイントを作成する必要がありました。 当時、このプロジェクトは1人のマネージャーによって管理されていたため、彼が倒れた評価、タスク、質問、バグに対する大量のリクエストに対処できませんでした。 すべての責任者をタスクマネージャーにドラッグしようとすると、すぐに膨大な数の重複とうんざりするタスクの精緻化に直面しました（異なるビジネス部門からであるが、共通ページ：メイン、ニュースなど）。 次に、かなり単純なことを試してみることにしました-プロジェクト管理者の役割を紹介しました。 これは、1つのプロジェクト内のクライアントマネージャーからのすべての要求が届く「テクニカルサポート」の非個人化された電子メールアドレスであり、複数の専任の従業員が処理できます。

通信量が非常に多いため、少なくとも1人のチームメンバーの作業リソースを完全に占有します。 プロジェクトマネージャーがリクエストフローを管理できるように、プロジェクト管理者を雇いました。 通信の効率を監視する最初の行であるため、要求に対する応答と応答時間は15分以内でなければなりません。 最初の行はクライアントの期待を制御するため、長期間にわたって彼からのフィードバックがない場合、プロジェクトマネージャー、チームリーダー、またはクライアントにタイムリーに「ping」する必要があります。 最初の行には、毎月のテクニカルサポートレポートの準備も含まれています。

各タスクは、タスクマネージャーに入力する必要があります。 タスクなし-タスクなし。 すべてのタスクは、プロジェクト管理者によって更新およびルーティングされます。 そこで、より戦術的に重要な他の責任のためにプロジェクトマネージャーをオフロードしました。

プロジェクトマネージャー



ずいぶん前に、プロジェクトマネージャーがプロジェクトのすべての責任を負います。 これは、計画、各タスクのタイミングのコンパイル、優先順位の決定、およびすべてのリスクの考慮に携わる人です。 重要な決定（特定の実装と方法論の使用、生産的環境での立ち上げの決定、従業員の専門知識の獲得）を行い、問題を解決するためにつながります。

最初の行の有効性とSLAの実装を監視し、プロジェクトの収益性と明確な目標に責任を持つPMを含む透明なKPIを修正しました。 最初のタスクが変更された場合、彼は追加のサブタスクごとにコストと条件の変更を正当化し、弁護しなければなりません。 紛争の場合、言葉は事実によって確認されなければならないので、すべての議論は文書化されるか、少なくとも書面で、例えばメールで書かれなければなりません。

すべての作業は上級管理者によって厳しく管理されています。アカウントディレクターとテクニカルディレクターは、来月の作業計画からすべてのタスクを毎週カットします。

ティムリッド



これはプロジェクトの最後のリンクであり、タスクを実稼働環境に起動することを決定します。 当社には複雑な統合タスクを伴うプロジェクトが多数あるため、主な負担はチームリーダーの肩にかかっています。大規模プロジェクトをスケールアップするには、2つのチームチームを同時に接続します。 私たちはすぐにこれを始めましたが、チームリーダーが一人だったとき、休暇や病気の重大性を認識してのみでした。

しかし、残念ながら、完成したチームリーダーを見つけるのは非常に難しいため、優秀なプログラマーから教育する方がより適切です。 すべてのプログラマがチームリーダーになることができるわけではありません。開発チームの責任者は管理スキルを持っている必要があります。

プロダクトオーナー



ある時点で、クライアントの思考の流れを制御し、プロジェクト開発戦略を正しい方向に導き、製品チームの内部相談を行う人が必要であることに気付きました。 プロダクトオーナーは、クライアントよりもビジネスと製品の詳細についてより多くの知識を持ち、すべてのニュアンスを予測できる必要があります。 クライアントとそのチーム全体がビジネス上の問題に対する最適なソリューションを選択し、プロジェクトマネージャーとクライアントとともにチームの負荷を管理できるように、クライアントの市場からそのような人物を選びました。

予備のベンチ：プラガブルスペシャリスト



主な専門家（デザイナー、レイアウトデザイナー、プログラマー、テスター）に加えて、大規模なプロジェクトでは追加のリソースが必要になることがよくあります。

私たちの大規模なプロジェクトでは、ほとんどの場合必要です：

• 建築家

アーキテクトなしではできないタスクがあります。これにより、開発された機能をさらに開発および保守することでリスクを最小限に抑えることができます。 多くの場合、アーキテクトのタイムリーな接続は、さらなるリファクタリングからあなたを救うことができますが、これはクライアントに販売することはほとんど不可能です。

設計段階での新しいタスクには、アーキテクトとプロダクトオーナーも含まれます。

• アナリスト

Web分析も設計に関係しています。 分析の段階で収集されたデータは、設計中だけでなく設計中にも、さらなるインターフェースの基盤となります。
物議を醸す技術とインターフェイスの違いがあるタスクにWeb分析を適用します。 それらは、クライアントとのコミュニケーションだけでなく、チーム内でも発生します。 そのような場合、私たちは分割テストに頼り、結果に基づいて、より成功したソリューションを最終製品に適用します。

• デザイナー

これは、作業のロジックとインターフェイスの相互作用を考え出す人です。 プロトタイプに加えて、プロトタイプの説明文書（仕様）を常に作成しています。 これにより、設計とレイアウトの段階で追加コストが削減され、デザイナーとプロジェクトマネージャーによるプロジェクトのデザイナーの監督が容易になります。
複雑な統合で機能をリファクタリングするには、チームリーダーと協力してデザイナーを引き付けます。 これにより、現在の統合スキームを最適化し、すべての欠点を特定し、それらに対処するための推奨事項を提示できます。
したがって、「サービス分析」と呼ばれるドキュメントが開発され、すべてが詳細に説明されています。

• Ux

各インターフェイスで、テストと調査を実施し、その結果をクライアントと共有します。 率直な問題があれば、私達は私達の費用でそれらをやり直します。

UX専門家の計装：

• ユーザビリティテスト。
• 調査;
• カードの直接および逆仕分け。
• 日記研究;
• フィードバック分析;
• テキストのセマンティックおよびセンチメンタル分析。

州外のリソース



大規模プロジェクトの負荷は、急激に増加する場合と急激に減少する場合があります。 常に大量のタスクが発生する可能性があり、迅速にスケーリングする機能を提供しています。 これには、リモートチームが関与します。1か月以内に大幅に削減する必要がある場合、内部スタッフを膨張させることは意味がないためです。

そのようなチームは、リソースの量を増やす緊急の必要性が生じた場合にいつでもヘッジできます。 同時に、生産計画の新しい主要タスクの計画期間が5営業日に達する可能性があることをクライアントと文書化しました。

プロセス

方法論

大規模なプロジェクトで作業する場合、適切な方法論を選択することが非常に重要です。
多くの場合、大規模なプロジェクトでは、1つの作業スキームに限定して、ウォーターフォールまたは柔軟な方法論だけでプロジェクト全体を実装することは不可能であるという結論に達しました。 ウォーターフォールプロセスの反復の一環として、スプリントとかんばんボードを使用した混合方法を使用します。 そして、私たちが理解した主なことは、方法論に関係なく、チーム全体が問題を解決するプロセスに参加することが重要であることです。

作業プロセス

2番目のグローバルなステップである、クライアントとの明確なワークフローに同意しました。 たとえば、火曜日にリリース、水曜日に評価、その週の生産計画の計画タスク、木曜日に開催された回顧展を実施します。 スケジュールは、タスクトラッカーレベルのプロジェクト管理者とクライアントからの要求レベルのプロジェクトマネージャーによって厳密に制御されます。

適切なリソース計画について言えば、すべての計算と評価において、労働者の日は8時間ではなく6時間であると記録しました。さらに、事故やバグの時間を事前に設定する必要があります。時間の割合であり、修正はわずか10％です。 バグ修正を迅速化するために、リソースを分割しました。異なる技術チームが技術サポートと生産に関与し、交点は管理とチームリーダーのみです。

テストとQA

大規模なプロジェクトは、常に複雑なアーキテクチャ、高いワークロード、および大きな財政的責任です。 したがって、すべての重要な機能を機能テストのグリッドでカバーする必要があります。 これにより、潜在的な問題が回避され、バグを修正する時間が最適化されます。

接続されたアーキテクチャの問題は長い間私たちを悩ませ、顧客との関係に否定性を加えました。 製品の品質をどのように確認しますか？ まず、プロジェクトの開発過程で、必ず標準化されたチェックリストを使用し始めました。 次に、アプリケーション設計の段階でユーザーケースの作成を開始しました。これにより、開発段階での多くのリスクとコストが削減されました。たとえば、プログラマーとテスター間の複数のタスクの転送です。 再テストでタスクが開発者に返される場合、これはすでに問題のシグナルであり、これが2回以上発生する場合は、接続して理由を調べる必要があります。

CIのフレームワーク内での自動テスト（gitフロー）

どれだけテストしても、エラーはまだそこにありました。 私たちは自分自身に質問をしました-バグを分析する時間を最小限に抑え、事故に迅速に対応する方法は？

このタスクは、可用性と機能の継続性を監視することで効果的に解決されました。 中断のない操作（データは独自のzabbix監視システムと2つの外部独立監視サービスから取得されます）および機能の可用性に関するデータ（TeamCityビルドサーバーから取得）の各URLの重要なリストのコンテキストでデータを集約する特別なイベントウィジェットを開発しました。 アクセシビリティまたは機能エラーに問題がある場合、アラートシステムがトリガーされます。すべての責任者は、電子メール、SMS、携帯電話への電話で手紙を受け取ります。 したがって、ダウンタイムに対する応答時間は15分以内です。







重要なURLのリストで機能テストを実行するルールを作成しました。

• スケジュール（9:00および18:00）に基づく毎日の自動実行。
• プッシュの前に開発サイトのスペシャリストで実行します（開発は機能ブランチで実行され、それぞれに専用の領域があります）。 コミット時に、コードレビューと単体テストを実行するフックを実行します。 テストが正常に完了すると、開発ブランチは安定した開発ブランチと自動的にマージされ、更新されます。 次に、ユーザースクリプトの自動機能テストが開始されます。 この前に、スクリプトは環境も準備します。変更がデータベースの変更に影響を与えた場合、キャッシュを強制的にクリアし、必要なファイルを最小化し、インストーラーを起動します。 テスト結果に基づいて、すべての関係者（開発者、マネージャー、テスター）がアクセスできるレポートが生成され、テストのステータスとともに通知がメールに送信されます。
• アセンブリのリリース後、ステージ上（実稼働サーバーのほぼすべて）で戦います。

ガイドライン

エラーは技術的なだけでなく、視覚的なものでもあります。 これらは、すべての制御状態とエラー処理を提供する設計者およびレイアウト設計者向けの準備されたガイドライン（例1および2 ）によって最小化できます。

プログラマー向けのガイドラインもあります（ 例 ）。 これは、ドキュメント、クラスとメソッドの説明、統合メカニズムなどです。 このすべての有用な情報をナレッジベースに集約して保存します（ confluenceを使用します）-プロジェクトマネージャーは情報を更新する責任があります。

最低限の「クランチ」を必要とする有能なアーキテクチャを検討することが重要です
機能の完成と開発の段階で。 コードを実行するとき、 PSR-1およびPSR-2標準を順守します。 これにより、開発者とチームリーダーの間でタスクを切り替えて転送する時間を短縮できます。 IDE、たとえばPHPStormで作業する人は、 標準への準拠の自動検証をセットアップできます 。 phpSnifferを使用して、バックエンドサーバー側に自動コード検証を実装しました。

また、アーキテクチャを開発するときは、情報セキュリティ要件を常に考慮します。コードの整合性制御、FZ-152準拠、xssおよびsqlインジェクションの脆弱性の欠如、TOP-10 OWASP要件の準拠です。

実際には、ガイドライン、ドキュメント、および自動テストの販売は非常に困難です。 多くの場合、スタジオはこれらの作品を予算に含めないため、怖い言葉になります
「リファクタリング」が、原則として、請負業者の別のチームと。 したがって、プロジェクトの設計と開発をすぐに真剣に考えなければなりません。 大規模な顧客のサポートを事前に準備します。これにより、まず市場が開拓され、本当に高品質のプロジェクトを作成できます。

PSこのシリーズの次回の記事では、プロジェクトのプロセスの計画と編成を構造化および最適化するのに役立つプロジェクトマネージャー向けのツールについて詳しく検討します。