プロジェクト管理のYAGNI原則

当社はカスタムWebアプリケーションを開発しています。 名刺サイト、つまりアプリケーションではありません。 ほとんどの場合-企業向け。



カスタム開発の最も差し迫った問題の1つは、作業が完了し、顧客が満足し、利益が十分であるように、プロジェクトの条件と予算を正しく評価することです。 3年の間に、期限と予算の問題を解決するためのさまざまな作業方法とアプローチを試みました。 たくさんの本を読み直し、多数の会議、ウェビナーなどに参加しました。 カットの下には、私たちにとって興味深い予算で顧客に最大の利益をもたらすことがわかったソリューションの説明があります。



まず、私たちがこれに到達した方法について話さなければなりません。

古典的なアウトソーシング-時計の販売または固定価格

時計の販売：クライアントは「無限の」契約を結んでおり、チームは徐々に増加し、場合によっては料金も上がります。 多くの場合、誰かが顧客の側で作業を配布します。開発チームには独自のアナリストがいません。短所：レートを上げることはめったにありません。プロジェクトがうまくいかず、全員が士気を失い、退屈してチームを交代させなければならないことがしばしばあります。 スターのない平均的なプログラマーがいると有利ですが、そのようなチームでは本当に面白くて複雑なプロジェクトを行うことはできません。



oDeskの小さな固定価格：短時間での小さな作業で、単独で迅速に作業できるロックスターに適しています。 短所：星は、自分自身がこのように働き、フリーランスになることができることをすぐに認識します。



固定価格：合意された期間のTKのプロジェクトを、異なる役割のあるチームにします。 古代の古典は、すべてを分析、評価、プログラミング、テスト、実装し、予算から飛び出すことです。

闘争の方法：

1. 短い反復に分割し、
2. リスク評価、確率論的手法、推定値に「pi」を掛けるなど。
3. 両方のオプションの組み合わせは短い反復であり、それぞれが開発速度の推定値を使用し、確率的手法、たとえばSCRUMを使用したリスク管理を使用します。

積荷のカルトでダウン-純粋な形のスクラムが私たちのチームで機能しなかった理由

私たちはいくつかのプロジェクトを試しました。プロジェクトを選択するための基準、つまり顧客がSCRUMに取り組む意欲についても書きました。 短所：顧客にこのすべてが必要な理由を説明することは困難です。チームでプロセスを適切に確立することはかなり困難です。チームを変更する条件での速度の推定は不十分であり、多くの顧客は偏見を持っています。 お客様の主な質問に対する答えが見つかりませんでした：「プロジェクトの完了までに何スプリントが必要ですか？」



SCRUMから採用されたもの：回顧による継続的な改善のプロセス-プロセスの変更まで。 顧客とともに編集された機能の受け入れ基準。 機能の優先順位付け。 評価用のプランカー。

産業別の製造業の幸福-お金のためにコードを書きたくないのはなぜですか

仕事で働いて、彼らの言うことをし、そして何か他のものに喜びを見いだす多くの人々がいます-ゲーム、趣味、過食。 私のパートナーのネムと私はこれらに属していないため、時間が経つにつれて、チーム内で彼らの仕事を楽しんでいる人々に会いたいという結論に達しました。



そして、知的な人、特に広義の開発者が仕事を楽しみたいときは、まず自分の仕事が理にかなっており、誰かがそれを必要としていることを理解したいのです。 （退化したケースがあります-超オタクは、技術のために技術を真っ逆さまに掘り下げますが、これはすべて、彼と同じ志を持つ人々の狭いグループにのみ必要です）。



私たちは他の誰かのビジネスのために働いているので、私たちがやることはこのビジネスにとって有益なはずです。 または、それが普通のインターネットユーザー向けの製品である場合-好きで、彼らに利益をもたらします。



テクノロジーとプロセスの代わりに主な焦点がユーザー、開発者、顧客の幸福になるとすぐに-その順序で、外観は根本的に変わります。 私は、お尻の時間という点で完全に考えたくありません。 基本的に、私たちが好きなプロジェクトは固定価格チームのカテゴリーに属します。



ユーザーを満足させるには、優れたインターフェイスを作成し、メリット、利便性、美しさの観点から各機能を最終的に検討する必要があります。 チームはマーケティングについて最高の形で考え始めます。良い製品を作るだけで、ユーザー自身が噂を広めるでしょう。



チームが幸せになるためには、誰かがこれをすべて必要としていることを知っておく必要があります。 チームは、合理的な議論を適切に認識し、「これは100ドル以上です、削除」という観点ですべてを測定するわけではない製品に目が光っている顧客を見る必要があります。 そして重要なポイント-チームは一定の締め切りと故障の締め切りで作業するべきではなく、通常の週末と夕方があるはずです。 しかし、誰かが家にいてもプロジェクトに携わるほど情熱的であれば、これは普通のことです。 しかし、ここまで行けば全員を労働時間に制限できると説明する方が良いでしょう。



顧客の幸福について話している場合、「期限と予算に適合する」スキルが重要です。 上記のすべてから、最近適用しようとしているプロジェクトで作業する特定の方法があります。 そして、これはある種の方法論ではありません。それは常識と顧客のビジネスの理解であり、方法論の組み合わせを選択するか、正当化されたときにすべてのルールを破る必要があります。 ある時点で、弁証法の第一法則の蓄積された知識がパラダイムシフトにつながった。 私たちは顧客の製品を私たち自身のものとして扱い始めました。

現在適用しているプラ​​クティス

1. FFF-固定価格、固定タイミング、柔軟な範囲

FFFは締め切りと予算内にとどまるための高レベルの方法と見なすことができ、顧客が支払うお金と彼が割り当てようとする時間のために、できる限り最高のものを手に入れることを保証します。



ここでの基本原則の1つは、すでに述べたYAGNIです。 各機能と希望について、優先順位が明確にされ、製品全体の重要性などが明らかにされます。 この時点で、チームの誰もが「この機能が必要な理由」、「このリリースでリリースすることが重要な理由」、「この機能がリリースされない場合、製品が失われるのはなぜですか」という質問をする権利があります。



アンドレイ・シャピロは、非常に限られた時間でレポートのスライドを作成する方法を説明しました。 一般に、問題を解決するための有限時間の割り当てにより、問題を解決する簡単な方法を探すようになり、時にはプログラミングをはるかに超えてしまいます。

さらなる技術は、この目標を達成するのに役立ちます。

2. MVP-必要なものだけでそれ以上

だから-私たちは、私たちが何のために、誰のために機能しているかを理解したいと考えています。 このために、事業計画で使用することが通常推奨される方法が使用されます（たとえば、スタートアップはそれらが非常に好きです）。

1. リーンキャンバスは、主な対象読者、その問題と期待、提案されたソリューション、コストと収益を理解するのに役立ちます。 さて、顧客がすでにこれらすべてを完了している場合。 そうでない場合、私たちは彼とそれを行います。 目的：このプロジェクトを行う必要があるかどうかを理解する。 ツール：A0形式のシート、ステッカー、ペン、マーカー。
2. 人物は、対象となる視聴者の集合画像であり、製品を使用するときに特定の役割を果たすアニメーションキャラクターです。 目的：新しい機能を計画するとき、または古い機能を改善するときは、「意見」に焦点を合わせ、それらがどのように反応するかを想像します。 ツール：A4シート、鉛筆、ペン。
3. インパクトマッピングは、ビジネス目標のマインドマップです。ここでは、従業員とビジネスがこれらの目標を達成する方法を想像します。 目的：製品の主なアクションと機能を決定します。 ツール：ボードとマーカー、またはオンラインサービス。
4. ストーリーマッピングはインパクトマッピングの類似物であり、ユーザー側のみが対象です。 すでに存在する人物を取得し、そこから最も重要な人物を選択し、Impactマッピングに従って、それぞれの高度な機能を書き留めます。 次に、必要な機能属性の最小セットを説明します。これにより、製品はその人にとって価値のあるものになります。 そして、限られた時間内に頭に浮かぶ開発オプションで写真を補足します。 目的：最初のリリースの範囲を決定するために、最小限の価値のある製品またはMVPでもあります。 ツール：ボード、シートA0、ステッカー、ペン、マーカー。 どのスプレッドシートでも可能です。

ステッカーとボードが優れているのはなぜですか？ 全員が集まり、プロセスに関与します。

3.顧客の旅-役割、コンテキスト、気分

ページ（Webの場合）でナビゲーションのドラフトバージョンを作成するか、他の場合のステージ間のクライアントの遷移を作成します。 私たちは、重要であると特定されたすべての人々を取り上げ、それぞれのためにします。 各ページの前に、ユーザーがここに来たコンテキストを理解しようとします。



私たちは彼の代わりに自分を置き、彼が見たものからの彼の感情と次のステップに進む動機を評価します。 目的：ユーザーが製品とのコミュニケーションを継続する動機付けになっているのはどのページコンテンツであり、何が彼を去らせるのかを理解すること。 ツール：ボード、シートA0、ステッカー、ペン、マーカー。

4.インターフェイスプロトタイピング-迅速な仮説テスト

機能を理解するための重要なポイントは、仕様が存在する場合でも、インターフェースのプロトタイピングです。 チームにUXスペシャリストがいなくても、誰もが紙に長方形を描くことができます。 インターフェースについての共通の理解を顧客に同意することは非常に重要です。



プロジェクトの作業の初日からデザイナーと協力してみませんか？ デザイナーは、ささいなことを掘り下げて、すべての影とグラデーションを使って、最後までレイアウトを色で仕上げることが非常に好きです。 彼らはアーティストですが、別の目標があります-レイアウトがビジネスニーズに対応しているかどうか、ページ上のブロックの場所について5つのオプションをすばやく理解する必要があります。 プログレッシブJpegメソッドは、最も有名なデザインスタジオの1つであるArtem Gorbunov Bureauによって推進されているという事実にもかかわらず、すべてのデザイナーがパラダイムを変更する準備ができているわけではありません。 これを完全に理解し、他の人を使用し、訓練する私に知られている2人の局の設計者は、より高度な技術的または物理的数学教育を受けています。



この方法の本質は、詳細を徐々に追加することです。 Web開発に関しては、まず、ページの概要とナビゲーションスキームのみ、次に詳細なレイアウトとレイアウト、次に実装のみ。 重要：段階的な改善と詳細のプロセスは、一度に1つではなく、すべてのページをまとめて行います。 機会と時間があれば、紙のプロトタイプを使ったインタラクティブなゲームで、チーム、他のプロジェクトのチーム、顧客と遊ぶことができます。



目的：インターフェースを高度に理解し、顧客を創造的なプロセスに関与させる調整-魂をモデルに入れたため、彼はもはや価値がないとは言えない。 ツール：紙、はさみ、ステッカー、鉛筆、ペン、接着剤。 またはバルサミクのような製品

5.開発プロセスの最適化

そのため、リリース機能が定義されています。 すべての機能の受け入れ基準がコンパイルされます。 ここで、すべての機能と顧客の優先順位を決定することが重要です。 そして、厳密に必須ではないもののいくつかを強調するために、YAGNIを再度思い出します。 何らかの理由で、開発が割り当てられた時間に収まらない場合、これらの機能がナイフの下に入ります。



これまで、私たちは顧客側だけに譲歩を求めてきました-機能を減らすことに同意し、目標と意味に関する質問に忠実であり、何かが行われないかもしれない客観的な理由を理解することを期待します。 そして、品質を犠牲にすることなく可能な限り間に合うように、私たちは何をしますか？



Goldrattの制約理論を使用して、開発プロセスを最適化します。 クリティカルパスを決定し、必要な場所にバッファを配置します。 この図には、顧客の参加が必要な場所も示されています-質問への回答、資料の提供など。 目的：どのタスクを実行するかが明確なときはいつでも、顧客は期限のシフトがそれに依存している場所を確認し、用語にpiを掛けるよりもインテリジェントに安全バッファーを使用するのに役立ちます。 ツール：任意のスプレッドシートまたは特別なソフトウェア（私には知られていない）。

6.変更の準備

TORの起草は歓迎しません。 顧客が同行することもありますが、たった1つの場合に変更なしで開発の最後まで生き残ることができることを知っています：作業指示書に書かれていることはもはや関係がないと理解していても、誰もが最後の変更に抵抗します。



代わりに、外出先で機能を変更する可能性を許可します。 夜になると、素晴らしいアイデアが顧客に伝わり、彼は彼女と一緒に走ります。 たとえば、SCRUMを使用すると、このアイデアはタスクのバックログに移動します。 彼らは次のスプリントの前にそれを取り上げず、おそらく議論することさえしません。 私たちは、機能を追加する方向だけでなく、削減の方向でも、リリースの構成を変更できることをお客様に伝えます。 私たちは、半日の議論が優先リストの末尾からいくつかの機能を捨てざるを得ないことを説明します。 これらすべてが彼の熱意を冷やさず、彼がこのアイデアが議論し、実行する価値があると本当に信じているなら、私たちはそれに取り組んでいます。

まとめ

現在では、方法論をその最も純粋な形で適用することはできません。 他の人の経験を勉強し、プログラミングに直接関係しないテクニックに興味を持ち、そこからツールやアイデアを引き出す必要があります。



まあ、あなたは方法論とプロセスが高品質の製品を作るのを助けないことを理解する必要があります。 頭を含めて、自分自身に責任を持たなければなりません！ みんなに。



PSこの記事では、それぞれの方法について詳しく話す方法はありません。 また、Googleが著者のビデオスピーチを見るのにも役立ちます。このすべての詳細が語られました-突然誰かが読書に飽きていませんでした:-)



聴衆の質問への回答を含む同じトピックに関するスピーチ、方法の説明写真といくつかの詳細があります：





ストーリーマッピング、ペーパープロトタイピングなどのプラクティスの詳細