計画の価値を「アジャイル」な製品マネージャーに納得させる
数か月前に新興企業の技術リーダーになりました。ソフトウェア開発は、組織図の製品の下にあります。
スタートアップ標準でさえ、私が継承したコードベースは貧弱です。例：開発チームは、サイトのフッターにある静的テキストを更新するのに3週間かかりましたが、それでもページの80％を過ぎると諦めました。フッターの「再利用可能なコンポーネント」を更新すると、一部のテンプレートが破損しますが、コードを数か月間使用していても、その理由はわかりません。もちろん、元の請負業者は長い間いなくなっており、ドキュメントを残していません。
私はものを片付け、書き、技術負債を減らすために賛同を得ましたが、もちろんfirst新しい中規模の機能を構築する必要があります。スタック。これは他のより大きな機能へのステップであることを知っています。コードベースは放棄された半完成した機能でいっぱいのようです。そのため、開発者の1人が5日間かけてコードを探索し、さまざまなアプローチを考案しました。
5日のうち3日目に、プロダクトマネージャーは開発者に進捗状況を尋ねました-簡単な回答、ここに私たちができるいくつかのアイデアがありますが、その手がかりはありませんコードはごちゃごちゃしていて、2日目に対処するためにサイトの停止があり、さらに時間が必要なため、まだ問題はありません。その夜、マネージャーはスパイクをジャンクし、アイデアの1つに基づいて「プロトタイプ」に置き換えました。これを行うにあたり、製品マネージャーである彼らはその場でいくつかの技術的な決定を行い、技術リーダーである私にランクを付けました。この事件やその他の事件から、私は「プロトタイプ」がすぐに「この外観でよろしいですか？開発者のMacbookでテストします。
「アジャイルスタートアップ」のすべてを取得します。先週、リスクに対するリラックスした態度と、何かanythingをユーザーの手に届ける必要が出てきました。階級を引かれてもかまわない。
しかし...私は明示的に言われました"私たちはスタートアップです、私たちはこの調査には参加していません****"-"研究"はそれが汚い言葉であるかのように話されました。また、コードベースが現状と同じである理由にも感謝しています。
古い手は、これがproductの場合に見えることに気づくでしょうprocessesが悪いためです。おそらく組織文化が貧弱であるからです。塹壕の中に立っていて、これは「アジャイルはあなたが進むにつれてそれを作り上げる、私たちの過ちから学ぶことは敗者のためである！」の最悪のケースに見えます。私が見たもの。
どうすれば、計画と先見の明に価値があるとマネージャーに納得させることができますか？または、おそらく、私はmyselfに、これがこのアジャイルスタートアップの「あるべき姿」であることを納得させる必要がありますか？
邪魔にならないようにするには、いくつかの重要なポイントがあります。
- アジャイル！=遅延開発
- スパイクとプロトタイプは交換可能なアイデアではありません
- 上記で説明したものは、アジャイルまたはスクラムによって規定されていません。
あなたのケースを作る方法についてのあなたの質問には、それは彼らの本当の動機に依存します。彼らが何をしているかの影響を理解していない場合は、新機能を迅速に提供する能力に対する技術的負債の影響について訴訟を起こすことができます。一方、彼らが貧弱な開発とビジネス慣行を隠蔽するために単に「アジャイル」を使用している場合、彼らはすでに知っており、彼らが気にしないため、物事を変えることができると主張することはできません。今、私は両方をたくさん見たので、どちらか一方を想定しないことをお勧めします。あるいは、必要であれば、楽観的なオプションを選択して開始することをお勧めします。
技術的負債
私が技術的負債についての議論で最も成功した方法は、次のとおりです。
スプリントの時間はXです。技術的負債のレベルが高い場合、時間の40％が技術的負債の管理に費やされ、60％が新機能に費やされるとしましょう。開発に長けていれば、その山はわずかに増えるかもしれません。数字を選んで、スプリントごとに1〜2％としましょう。ただし、新興企業では高速で旋回する必要があり、多くの場合、誤って多くの技術的負債を負うことになります。そのため、優れた新興企業チームでも、スプリントにさらに5〜10％の負担がかかる可能性があります。もちろん、うまく動かない場合は、より速くビルドできます。あなたがその技術的負債を片付けていないのなら、それはただ築くだけです。すぐに、1〜2日かかるはずの変更が3週間かかります（おなじみの音）？
この時点で、あなたは親切であるか、まじめな人として脱ぐことができます、そして、あなたが彼らに共感するかどうかは本当に異なります。古い問題を停止して修正できればすばらしいのですが、おそらく組織はそうしないので、新しい解決策を見つけましょう。まず、技術的債務の発生をそれほど早く停止する必要があります。単体テスト、コード標準、コードレビューなどの効果的な品質測定は重要です。次に、すでに発生した借金の返済を開始する必要があります。たぶん、金曜日にアイスクリームでコードを整理することは、会社が吸収できるものです。また、最も新しい機能の開発を完了する必要がある領域を対象とすることで、より迅速な機能の提供により、よりクリーンなコードベースがどのように利益を得るかを実証できます。
計画/分析
あなたの質問では、技術的負債と分析を混同しているようです。それで、もしそれが役に立つなら、あなたはこれでそれらを売る必要があるかもしれません。そのためには、複雑であり、複雑な問題があることを理解することが重要です。複雑な問題の場合、専門家は問題を短時間で分析し、適切な解決策を特定できます。既知のフォームからのエントリを格納するための最適なデータ構造は、この良い例です。複雑な問題では、未知の要因が多数あるか、異なる要因が互いに影響し合う方法を予測することが困難です。これには、実験と結果の観察が必要です。ある程度の分析を行っても答えは得られません。そこに入り込んで何かを試す必要があります。あなたが解決している問題の種類を知ることは重要です。
これは、大きな問題全体を一度に処理するのではなく、問題の断片を解決するという問題である反復的な開発とは明らかに異なります。
お役に立てれば。幸運を祈ります。あなたが一緒に働いている人々が彼らの行動の影響を知らないことを願っています。
計画に価値がない彼らにがないため、あなたはできません。
PMは、製品がどの程度うまく機能しているかではなく、時間と予算に基づいてプロジェクトを完了したことに対してクレジットを取得します。
あなたができることは、作業を開始する前に、彼らをだまして要件を追加することです。例：「PCで動作」。
優れたプログラミング手法を推進するのは、より微妙な要件です。 「品質」でも「正しく」でもない
実行したいリファクタリングの一部を実行するには、「テンプレートシステムで動作する」や「ゼロダウンタイムのデプロイメント」などの要件が必要なようです。
適切な要件を得ることができれば、コードを修正することがプロジェクトとなり、PMはあなたに対してではなくあなたのために働きます。
「どのように納得させるか...」という質問は、あなたが正しいことと、製品マネージャーが間違っていることを前提としています。あなたの質問の枠組みから、あなたは製品マネージャーの推論を理解するために大きな努力を払ったようには見えません。ただし、プロダクトマネージャーが全体像を把握している場合があります。開発者と技術者がリードするとき、あなたは自分が運営しているビジネス上の制約を理解する必要があります。
あなたが話を説明したように、製品マネージャーは迅速な決定をすることで2日間の研究を節約しました。また、「先週、ユーザーの手に何かを届ける必要性」を理解していると述べています。これらの前提を考えると、プロダクトマネージャーは適切な電話をかけたようです。
あなたがhaveクリーンアップのためにいくつかのリソースを使用するために賛同することを考えると、管理doこのような迅速で汚いソリューションにはトレードオフがあることを理解しているようです。それで、あなたが彼らを説得したいのは何ですか？開発が必要な修正や機能の重要性に関係なく、常に調査に3日間を費やすべきか？
新興企業にとって、市場投入までの時間は非常に重要です。テック系新興企業が危機に瀕しているとしましょう。1か月間ユーザーの成長を続けると、新たに大きな投資をすることになります。成長が停滞した場合、事業は閉鎖する必要があります。このような状況では、新興企業は技術的な負債を喜んで受け入れます。長期的な保守性を犠牲にして、機能の迅速な提供に向けて最適化します。事業が閉鎖された場合、長期保守性の問題は議論の余地があります。成功した場合は、より多くの開発者を雇って混乱を解消できます。
あなたが最初にすべきことは、あなたが働いている制約と優先順位をよりよく理解するために製品マネージャーと話をすることです。
よく見てください：
そこ！絵は千の言葉を描くのではないでしょうか？ええと、このグラフを額面どおりに受け取らないでください。これは単なる例示ですが、非常に具体的なものです。
最初のケース（縞模様の領域の下部を通る線）は、慎重に開始し、適切なパターンと実践を採用し、事前の計画と設計に必要な時間を費やすケースを表しています。 「出生時」にそれを完済するために追加の少量の時間を費やすことによって技術的な負債を回避し、「 interest 」を蓄積しないようにします。
2番目のケース（縞模様の領域の上部を通過する線）は、最初に開始するケースを表します
うっかり非常にプレッシャーがかかっているため、今すぐ結果を出し、後でクリーンアップする必要があります。その場合、あなたとあなたのチームがどれほど経験を積んでも、あなたにできることは、技術的負債への関心を抑えることだけです。しかし、時間の経過とともに蓄積されます。
あなたが2番目のケースに該当するように見えるので、私はこれらのケースに焦点を合わせています。これは、スタートアップの典型的な "取引"と言えます。時間（およびリソース）を使って輝くか、結果をすぐに得て、後で支払う（ただし、少なくとも仕事は残っている）かのいずれかです。
ポイントはこれと同じくらい簡単です：anyの開始点が与えられると、criticalインスタントが将来、あなたは深刻なに悩まされ始め、「研究」を無視することで生産性を阻害します（実際に時間をかけるだけの流行語）あなたの技術的負債を減らすか、それをずっと避けてください）。したがって、もちろん、「研究」を無視している間は、しばらくの間より多くの作業を行うことになりますが、この期間は永遠ではありません。この事実は、上のグラフのオレンジ色の縞模様の領域で表されています。
どんなに壁に頭をぶつけても、この事実を回避することはできません。技術的負債は利息を累積します。現在修正するのにx時間かかり、y> = x時間かかる問題後で修正します。 ">"の方がはるかに可能性が高く、時間の経過とともに差異が大きくなります。
やらなければならないことは、深刻な考慮事項を作成することです。この将来の重要な時期が一部非常に重要な締め切り。将来の生産性をハンディキャップするつもりなら、そうするためにとても良いrea $ on $が必要です！たとえば、オール・オア・ナッシングの取り決めに沿って何かを考えます。
研究を無視することは、時々「wise」のことになるかもしれないことを覚えておいてください。たとえば、会社がリソースを必要としている可能性があります。リソースはt-criticalの前に来ると予想されますが、確実に遅くなることはありません。そのため、多くの場合、痛みを伴うキャッチアップは、どの会社よりも優れています。
これは、マネージャーが当然処理しなければならない難しいことなので、それは彼らの呼びかけですが、彼らは事実をよく理解する必要があります。少し考えてみれば、実際の数値を概算し、これらの数値どのようにしてこの重要な瞬間を超えており、常に生産性の低下率を下げる準備をしています。
あなたのマネージャーが少なくともあなたが言う/示すことに注意を払うのに時間がかかる場合、いくつかのキャッチーなチャートはどんな量の話された言葉よりもはるかに優れたポイントを獲得するかもしれません。
更新
新しい質問を提起するコメントのいくつかのために、上のチャートは単に（過度に）単純化された近似であることを述べる必要があります。このt-criticalインスタントのおおよその位置を推定することは非常に難しい問題ですが、私たちが通常解決しようとしている問題ではありません（これは、単一責任の原則によると、 、管理の問題）。私たちが努力すべきことは、ある瞬間に、この瞬間に関して、時間軸のどちら側にいるかを知ることです。
また、このグラフは、管理者が知っておくべきことを単に表しています：「調査を無視した場合****、調査（および適切なコードのハウスキーピングの単なる別名である他のすべてのキーワード） 、私たちは決して私たちができなかったと同じくらい良くなるでしょう-最初はもう少し時間をかけただけです」会社の野望/目標/必要性の1つが非常に柔軟で高性能な技術チームである場合、現在のコードベース/製品の状態を考えると、失われたケースでより多くのリソースを浪費する代わりに、すぐにそれを落とすこともできます。
これに基づいて、ダイアログは次のようになります。
- この1行目の上の「研究によるピーク生産性」をご覧ください。それはおそらく私たちが近くにいることは決してないだろう場所です。
- 以下の2行目の「研究なしのピーク生産性」を参照してください。これが私たちが最高の状態になる場所です、つまり、運がよければ。これをメートル単位で測定しようとしないでください。垂直スケールは何桁も縮小されます！
- 会社の存続が下の線の上にある「viably」であることに依存する場合、リソースを節約し、さまざまなキャリアの機会を検討し始めることができるようになりました。
私たちが今向かっている方法は、過去t-criticalなので、 将来のある時点で2行目を上回ることもできます、私たちは非常に努力する必要がありますからfirstがvirtual work gainsオレンジ色の線の縞模様の領域で表され、その後生産性の向上によるメリットを、提供するのに十分な大きさの作業量に徐々に変換するよう努めます。
「仮想作業の増加」とは、より多くの作業を行ってからを行うことは、その作業を将来から盗むようなものだったことを意味します。毎日10分の生産的な時間があるとしたら、私たちの生活がどれほど良くなるか想像できますか？まあ、私たちの下着で働くことは私たちにそれらの10分の追加の生産性を提供するでしょう。これがまさに行われたことです。ドレスアップしないことはあなたの仕事から時間を節約する良い方法ではありません、私はあなたが類推と比喩に従っていることを望みます。
ちなみに、十分に生産的であるだけでは十分ではありません。また、
行われるいつでも実行されています。これは期限によって表されます！回復のための時間を確保するために次の計画された期限を移動するか、全員が家に帰ります...もちろん、もちろんではありませんが、期限をキャッチするには、2行目よりはるかに高い生産性が必要になる場合がありますチャート...そのように続けていると到達できないもの...
アジャイルの場合、アイデアは、計画を立て、クリーンにしていくことです。厄介なコードベースの機能を計画する1週間があるとき、プロセスは次のようになります。
- 大まかなアイデアとホワイトボードを同僚とブレインストーミングする朝を過ごします。
- 最も有望なアイデアの最初のステップを実行しようとする午後を過ごします。新しいテクノロジーの場合、それはある種のHello Worldを意味します。私はここで主なタスクを達成しようとはしていません。私は主な仕事を成し遂げるのを阻むものを見つけようとしています。
- この時点で、よく構造化されていないコードに直面することがよくあります。機能を追加するために直接変更する必要がある領域で、1日か2日それをクリーンアップしてテストを改善しますjust。
- 機能をもう一度追加するために朝を過ごします。より基本的な障害にぶつかり、月曜日にブレインストーミングしたプランBにピボットすることを決定します。
- 機能は同じ一般的な領域にあるため、火曜日に行ったクリーンアップは依然として役に立ちますが、新しいアプローチでは、少し異なる領域で追加のクリーンアップが必要になります。午後はさらにクリーンアップを行います。
- 今、私が変更する必要があるコードははるかに良い形になっています。私はそれをより深く理解しています。私はいくつかの異なるアプローチを試しました。特定のアプローチが実行不可能な理由を製品管理に詳しく説明できます。クリーンアップ/コードの追加サイクルを短くすることで、はるかに迅速に進行できます。
実行中のコードのクリーンアップはhow速く動きます。コードでの作業は、プログラマーが何が機能するかを学ぶ方法です。それはあなたが計画しないという意味ではありません。つまり、計画/実行/クリーンアップのサイクルを、週単位ではなく時間単位で行うことを意味します。