記事では「サイトあたり12,000ルーブル。 モスクワリングロード以外にもビジネスはありますか？」私は、社内で開発された技術に基づいてサイトを開発するためのアプローチについて書きました。 この記事の執筆時点では、1か月あたり24のターンキーサイトを作成していました。 これは、8人のチームによる1日に複数のサイトです。
ハブでの当社のテクノロジーに関する話の後、ウェブサイト開発のリクエストの数は数回増加しています。 2012年3月だけで、約60件の商用オファーが提示され、それらのほとんどが契約になりました。
そして、私たちの生産は継ぎ目で割れました。 ほとんどすぐに、アプリケーションがキューに入り始め、マネージャーがプロジェクトで混乱し始め、デザイナーが休暇を求め始めました。 状況は本当に緊張し始めていました...
問題認識
最初にやらなければならなかったのは、約束された開発期間を一時的に5から8に、時には10日間に延長することでした。 選択肢がありませんでした。 クライアントは同情的で、待つ準備ができていました。 しかし、状況がさらに緊張するまで待つ準備ができていませんでした。 何かをする必要がありました。 すべての指標（および標準）に対処する必要がありましたが、これは起こりませんでした。
顧客を拒否したくありませんでした。 スタッフを増やすこともできませんでした。 時間がかかります。 私たち自身の有効性を高め、隠れたリソースを見つける必要がありました。 私たちはすべて計算しました。 さらに、チームに落ち着いた雰囲気を戻すことが急務でした。
継続的な改善プロセス
プロダクションとしてのWebサイト開発を見てみましょう。 本番は、すべてのリンクが相互接続されているチェーンです。 この場合、チェーンリンクは、セールスマネージャー、エグゼクティブマネージャー、デザイナー、コンテンツマネージャー、プログラマー、テスターです。 私はそれぞれの機能をペイントしていません。それらはとても理解しやすいと思います。
1つのリンクはアプリケーションを受け入れ、もう1つのリンクは作業、設計、アセンブリ、改訂のためのプロジェクトを受け入れます...別のリンクはテストと計算などに従事しています。 少なくとも1つのリンクに障害が発生すると、プロセス全体の速度が低下するか、停止します。 そして重要なポイントがあります。 チェーンの強度を決定するものは何ですか？ 当然、最も弱いリンク。 チェーン内の「最も」弱いリンクは1つであり、これが生産管理へのアプローチの重要なポイントであることに注意してください。 産業界でのこのアプローチは、制約理論によって説明されています。
詳しく説明します。 生産チェーンにおけるあなたの役割は、完成したデザインからサイトを組み立てることだとしましょう。 あなたは最も弱いリンクではありません。 あなた自身の天才と働く能力の結果として、あなたはさらに2倍を集め始めました。 チェーン全体のパフォーマンスをどの程度向上させましたか？ いくらでもそうです。 絶対に関係なく。 ローカルの改善のほとんどは、チーム全体のパフォーマンスを向上させるものではありません。 これは、「より良い」ということは、チェーンの全体的な効率の向上につながる道ではないことを意味します。
全体的なパフォーマンスを強化する場合、最初のステップは最も弱いリンクを見つけて強化することです。 最も弱いリンクが政治または技術である場合、それに応じてポリシーまたは技術を変更する必要があります。
私たちの場合、問題を実現した時点での弱点はセールスマネージャーでした。 その機能には、プロジェクトの販売と契約の締結だけでなく、特定のプロジェクトの実施も含まれていました。 私たちは彼をプロジェクト管理から完全に解放し、アプリケーションへのタイムリーな応答に関する問題はなくなりました。 最も論理的でシンプルなものでした。
私たちはリンクを強化しましたが、もはや弱くはありません。 ここで、最初のステップに戻って、弱いリンクの検索を再開する必要があります。 これは継続的な改善のプロセスであり、チームの隠れたリソースを探して私たちが追随しています（そして追随しています）。
作業速度を同期し、生産のバランスを取ります
弱いリンクの帯域幅を決定して増やした場合（まだ弱い場合）、このリンクの速度の他のすべてのプロセスを従属させる必要があることを理解する必要があります。 たとえば、アセンブリごとに1つしかサイトを発行できない場合、デザイナーが1日に2つのデザインを描くことは意味がありません。 クライアントは、事前に行われた中間段階ではなく、宣言された期間内の最終結果に関心があります。
そのため、チェーンの力により、以前と同様に、5日以内にサイトを作成する必要がありました。 技術的には、これを行う方法を学びましたが、...今、一部のプロジェクトでは、生産チェーンが以前ほど好意的に見えなくなりました：
プロジェクトは引きずり出され始め、マネージャーにはこれについて多くの理由がありました。 しかし、多くの理由があります。 根本的な原因は、原則として1つです。
プロジェクトを並列化すると、チェーン全体の速度が低下し、コストが増加します。
私たちのボトルネックは、TKの形成段階でプロジェクトマネージャーになりました。 また、開発段階で、一部のプロジェクトが2か月に延長され、実際の期間は5〜8日間であったことを観察し始めました。 マネージャーは、現在のプロジェクトをリリースせずに新しいプロジェクトを作成する必要があることが判明しました。 その時までに、マネージャーあたりの「作業中」のプロジェクトの数は20個を超えました。
簡単な例を見て、プロジェクトの並列化が生産性とコストにどのように影響するかを見てみましょう。 マネージャーが自分の仕事にいくつかのプロジェクトを持ち、それらが順番にサービスを提供するとします（顧客からの資料を解析し、タスクを形成します）。 この操作の各プロジェクトでは、期限を満たすために、1営業日以内で（基準に従って）過ごすことができます。 マネージャーがプロジェクトからプロジェクトに切り替える場合、それは何につながりますか？ 写真は、前のプロジェクトを完了せずに次のプロジェクトに切り替えると、その長さが2倍になることを明確に示しています。
タスクからタスクへのジャンプは、プロジェクトのタイムリーな実行に最大の悪影響を与えるという明確な理解がありました。 誰もがこれに苦しんでいます。 このジャンプがどのような形で発生するかは問題ではありません。 それは、会議、「発火」、情報の損失、行動の不整合-まさに、サイトの作成要求が何度も増加した後に始まったものです。 すべてを一度に起動することで、すべてのプロジェクトが危険にさらされ、コストが大幅に増加することに気付きました。
明らかに、マネージャーあたりのプロジェクト数を制限し、約束された顧客に5つのプロジェクトをリリースするための時間を短縮するための対策を講じる必要がありました。
マネージャーごとに5つのプロジェクト
マネージャーごとのプロジェクトの数は、プロジェクトのリリースサイクルの期間とマネージャーが1つのプロジェクトに費やすことができる時間によって決まります。 プロジェクトのリリース時間は5日間で、マネージャーがプロジェクトに費やすことができる時間は5時間です（1営業日のマージンがあります）。 したがって、管理者は5〜7個以下のプロジェクトを持つ必要があります。
プロジェクトの5日間
ここで、5日間でプロジェクトを完了する保証された機会をマネージャーに提供する必要があります。 これを行うには、作業中の多数のプロジェクトに加えて、これらの義務を果たすことが難しいことを理解する必要があります。
当然のことながら、主な問題の1つは、クライアントのホスティング上のプロジェクトのレイアウトでした。 クライアントはパスワードを覚えていないか、機能しない、ドメインとホスティングが合わない、「エキゾチックなホスト」は私たちの管理システムと友達になれません...非常に異なる問題がありました。 問題に対処する時間がないため、新しいプロジェクトに切り替える必要がありました。
2番目の問題は、テキストとデザインの準備のための資料の不足でした。 運転中、材料の一部がないことが明らかになりました。 彼らの領収書は同様に困難であることが判明し、プロジェクトの実行時間を延長しました。
他のすべては、最初の2つと比較して重要ではありません。
状況を分析した結果、義務を期日どおりに果たすことができると確信できるまで、プロジェクトを運用しないという決定を下します。 このため、プロジェクトのステータスは「情報収集」です。つまり、彼らはプロジェクトに関与していますが、まだ作業中ではありません。 これは契約で提供され、作業を開始するときにクライアントに通知します（システムを介した通知の送信）。
これがチェーンの外観です。
これまでのところ、これらは暫定的な解決策です。 彼らは時の適切なテストに合格していません。 しかし、ほとんどのプロジェクトでは、約束された5日間をお客様に返し、チームに落ち着きを取り戻しました。 中央オフィス（メイン）の生産性は、これまでのところ1か月あたり36プロジェクトに成長しています（2012年5月の結果による）。
誰もがそのようなスキームの恩恵を受けます。 すべての資料を時間通りに提供した顧客は、約束された時間に結果を受け取ります。 急いでいない顧客は、作業がまだ始まっていないことを知って、予備段階（情報収集）にいます。 したがって、彼らは期限の遅れを主張しません。 不確実性が最小限のプロジェクトでは、生産は（開始方法と比較して）静かなモードで動作します。 マネージャーは、プロジェクトを予定どおりに実施することに集中する機会があります。
以下は、ストリーミング制作の現在の最適化に関する簡単な観察結果です。 誰かが助けてくれることを願っています。
まとめ
ストリーミング制作を継続的に改善するアプローチを簡単に要約します。
- 最初のステップは、システムの制限を見つけることです。 現在、最大パフォーマンスを設定しているのは何ですか？
- 2番目のステップは、システムの制約を最適化することです。 追加の投資をせずに、狭いリンクを最大限に活用してください。
- 3番目のステップは、すべての生産の速度を狭いリンクの作業速度に従属させることです。
- 4番目のステップは、狭いリンクを拡張することです。
- ステップ5-ステップ1に戻るが、慣性を覚える
これらは、 Goldrattの制約理論の 5つのステップであり、工業生産にうまく適用されています。 サイトの制作に適用してみませんか？
生産効率の向上というテーマを継続し、コンベア上のすべての操作に関する詳細な統計を収集しています。 これをさらなる分析とボトルネックの検索に使用する予定です。
私たちの生産の技術的特徴は記事「サイトあたり12,000ルーブル」で説明されていることを思い出させてください。 モスクワ環状道路の外にビジネスはありますか？” 彼女は多くの質問に答えます。
PS低コストのプロジェクトの「死亡率」、顧客にとっての本当のメリットなどについて書くようにという要求がありました。今のところ、フィードバックと統計を収集します。 すぐに少し分析があります。
Vasily Churanovとweb-canape.ruチーム