この短いメモは、彼のスタジオがどこでお金を失っているのかを体系的に探している人向けです。 私たちの楽しい時間で称賛に値するレッスン。
よく体系化されたタイプのトヨタの損失者。 Toyotovtsyは7-8種類のムダ、生産の損失を割り当てます。 自動車産業の損失とスタジオの仕事の間に類似点があるかどうか見てみましょう。
ムダNo. 1.過剰在庫による損失
スタジオ内： 未完成または未完成のすべての作品。
- 配信されていないデザイン。
- 信頼できないレイアウト。
- テストされていないコード。
- プログラムされていない要件。
- 計画外のコード。
会社の未完成の仕事が多いほど、売掛金が増えます。 燃え尽きる危険があります。
繰り返しますが、顧客の観点から見ると、未完成の仕事は利益をもたらさない。 彼は彼女を必要としません。
対処方法：フックまたは詐欺師によって、同時に配信されなかった作業量を減らすようにしてください。 4-5を引き受けて並行して行うよりも、1つのプロジェクトを最後まで実行してから次のプロジェクトに進む方が適切です。
ムダNo. 2.不要な輸送中の損失
スタジオで： 既に決定が下されている同じ問題の再議論（再学習）。
たとえば、スタジオである種のバージョン管理システムを使用するのがいいだろうという結論に達しました。 この問題を慎重に調査しました。 集まって、賛否両論について話し合った。 彼らは、GITまたはSVNの方が優れていると称賛しました。 問題を本当に完全に理解しました。 そして標準として、svnをホストすることにしました。 標準として実装されます。 学んだ。 使い始めました。
そして6ヶ月後、ある賢明な男が言います：「みんな！ そして、なぜGITではなくSVNを使用するのですか？ SVNは<argument>であり、GITは<another argument> "であるためクールです。 実際、6か月後、これらの議論がすでに検討されていたこと（そして、あなたはそれらが不十分であるという結論に達しました）、または議論中にこれらの議論をスキップしたことを誰も覚えていません。 質問をもう一度勉強しなければなりません。 お金を稼ぐ代わりに時間を無駄にします。
対処方法：決定だけでなく、決定のコンテキストと議論も修正します。 ここではグラフがうまく機能します（ 根本原因 分析 、 マインドマップ、 A3分析 ）。 開発プロセス/ツールのレビューと、受け入れられている標準への準拠とのバランスを見つけてください。
ムダNo. 3.過剰生産による損失
スタジオ内： 不要な機能。
だから、5段目のページでいくつかのチップやイースターエッグを手に入れたり、写真を磨いたりするのは楽しい。だれも0.005秒のダウンロード速度でOur Guideページにアクセスしたり最適化したりすることはない。
一般的な考え方：誰も使用しない（クライアントが獲得しない）関数を作成することは損失です。 リーダーの例はMS Excelです。ユーザーの95％は常に5％の機能しか使用しません。 残りは何ですか？
対処方法：行っていることをメリットの観点から批判的に評価します。 顧客とあなた自身に利益をもたらさない仕事をマークして排除します。
ムダNo. 4.待ち時間による時間の損失
スタジオ内： 承認の遅延。
- 顧客との合意を待っています。
- 内部承認;
- 役に立たない会議、ディスカッション、対面会議。
このような実際の損失は予想です。 顧客は3つのレベルでレイアウトに同意します。 テキストを承認しながら。 弁護士は、請負業者に編集内容を送信するように設計されています。
特に、些細な問題に関する個人的な会議には多くのリソースが使用されます。 多くの場合、お尻を隠して決定を下さないために、あらゆる問題に関する会議にできるだけ多くの人々が招待されます。 「手紙の大きさ」について話し合うためにモスクワ周辺の機関を会議に移動するのは非常に高価ですが、そのような会議を1つ集めて開催するのにどれだけの費用がかかるかを本当に考えている人はほとんどいません（ヒント：通常数万ルーブル）。 合意は決まっておらず、議論は空虚に飛び散っています。
対処方法：プロジェクトに関係する人の数を最小限に減らします。 できるだけ早く決定を下します。 会議と個人的な会議の数を減らします。 すでに会議を開催している場合は、契約を明確にスケジュールし、記録し、明確に遵守する必要があります。
Muda No. 5.不良品のリリースによる損失
スタジオで： バグ。
バグについて知っておくべき重要なこと：後で欠陥が発見されるほど、それはより高価になります。 プログラマーが自分でバグを見つけて修正したら、すぐにそれは安上がりです。 しかし、クライアントが彼を見つけた場合、これはすでに困難です。 特に2年後にバグが発見されたとき、それはクライアントのデータベースを破壊し、コードを書いたプログラマーは別の都市で休暇を取って亡くなりました。
対処方法：できるだけ早くテストします。 大規模プロジェクトの場合- 自動テスト 。 明確なコーディング標準。 定期的なコードレビュープラクティス。 初心者向けのチューター。
ムダNo. 6.不要な動きによる損失
スタジオ内： プロジェクト転送損失。
伝送損失：
- 責任。
- 知識の。
- プロジェクト。
- アクション。
- アプリケーション。
クライアントのアイデアが頭からどのように具体的にそれを行う人に至るまでの中間リンクがいくつありますか？ クライアントが最初にアカウントマネージャーに、次にプロジェクトマネージャーにストーリーを伝え、次にプロジェクトマネージャーがすべての導入分析を伝え、次に分析がデザイナーに渡される可能性があります。
プロジェクトが転送されるたびに、時間と情報が失われます。言葉によるものと非言葉によるものです。 最終的に情報が失われると、エラー、変更、そして再び-時間の無駄につながります。 あるプロジェクトマネージャーから別のプロジェクトマネージャーにプロジェクトを転送する場合、またはプロジェクトのプログラマーを変更する場合、損失は特に敏感です。 そして最も難しいケースは、クライアント側の責任者の変更です。
重要な微妙さ：プロジェクトが初めて研究され分析されるとき、それはクライアントにとって価値があります。 損失は、同じ情報を繰り返し粉砕するだけです。
対処方法：プロジェクトに関係する人数を必要最小限に抑えます。 チームと責任者間のプロジェクトの転送を除外します。
ムダNo. 7.不要な処理ステップによる損失
スタジオで： 開発者をさまざまなタスクに切り替える
人間の脳はマルチタスクにあまり適応していません。 プロジェクトからプロジェクトに切り替えている間、タスクのコンテキストが失われています。 コンテキストを復元するには、15分から30分かかります。 これは純損失です。
あなたが人を引いた場合、あなたが15分を漏らしたことを考慮してください。 レートを掛けて、給与から引きます。 貪欲な場合-引っ張らないでください。 それが残念ではなく、質問にそれだけの価値があるなら、あなたは引っ張ることができます。
ところで、プログラマーがコンテキストをすばやく切り替えることができる場合、それはマネージャーの傾向が強いことを意味します。
対処方法：人を引っ張らない
ムダ番号8。従業員の未実現の創造性
スタジオで： ファッキングルーチン。
常に選択肢があります。プロジェクトに100500の同様のプロジェクトを作成した人を配置するか、そのようなトピックを理解していない人を配置するかです。 開発者にルーチンをロードし、開発者が独立して行動するのを防ぐことにより、HRの負担が増大します。 トレーニングにリソースを投資するか、人事に投資するかはあなた次第です。
対処方法：時々タスクをプログラマーの能力の限界まで設定してみてください。 常にこれを行う必要はありませんが、従業員のチャレンジタスクが表示される場合があります。