上司が常に要件と全体的な設計に関する重要な決定を延期する場合はどうすればよいですか？

新しいプロジェクトを開始するとき、上司は常に決まった決定を下すことを避けています。彼は通常次のように言っています：わかりました、何かを書き始めて、できるだけ一般的になりなさい。終了したら、私たちがどのように続けるかを見ていきます。彼の議論は基本的に、あなたが決して知らない「アジャイル開発」だということです。

質問をできるだけ一般的にするために、上司が意思決定をしたくない場合はどうしますか？

それに固執して、数週間後に重いリファクタリングと部分的な書き換えを受ける可能性のあるコードを書くだけですか？または、ボスが少なくともいくつかの決定をするまで議論を続けますか？これは多かれ少なかれ私の現在の戦略です。それは物理学の法則に似ているため、ある時点で何かを提供する必要があります。上司のボスが結果を見たいか、何かがばかげているからです。

また、上司がほぼすべてを批判していることも観察しています。彼自身に基づいた提案でさえ...

プロトタイプを構築する

最初は何もしない画面の描画を開始します（おそらくそれで十分ですか？）

部分的にゆっくりと機能させることができ、やろうとしていることがより明確になったら、最終的にいくつかの不良コードをリファクタリングできるはずです。

彼らが何かを見て、それが彼らが望むものではないことに気付くまで、彼らは彼らが望むものを知らないということは一般的な問題です。誰かがあなたに「フレームワーク」または彼があなたに言っているような「一般的」なものの構築を始めてほしいと望んだとき、あなたが試してみるとあなたはただ困ってしまうことを発見しました。フレームワークはすでに作成されているので、その必要はありません。

メッセージから収集したいくつかの問題があります。0-プロジェクトを管理するのはあなたの仕事ではなく、エンドユーザーの要件を収集するのはあなたの仕事ではありません。1-上司は正確な要件を知らない2-上司は要件についてエンドユーザーと話さない3-上司はアジャイルをあまり理解していない用語を投げかけている4-何回か書かれて、あなたはそれについて幸せではありません

1、2、3に関しては、あなたが年配の人でない場合、これについてはほとんど何もできません。ただし、次のことが可能です。

A-プロジェクト計画をあなたと共有するよう彼に頼みます。彼は1つを持っているか、タスクと期限を示すものを作成します。これらの1つは、分析と要件の収集に関するものでなければなりません。提案しない場合。

B-ソフトウェアプロジェクトの成功に対する要件の重要性に関する参考資料を準備する

C-彼にアジャイルとは何かという1ページを用意します。

D-設計段階への典型的な入力のリストを彼に準備し、それぞれの価値を説得します。

E-ビジネスアナリストやデータモデラーをチームに追加することを提案します。そのような役割は、エンドユーザーと一緒に座って、必要な情報または少なくともその大部分を入手する必要があります。

F-他の開発者がこの男にどのように協力したかを見てください。

＃4に関しては、プロトタイピングアプローチまたはコードジェネレーターを使用するように彼に提案できます。コードジェネレーターは、あなたとユーザーがアプリケーションの機能的側面について気にするのに役立ちます。ほとんどのツールは完璧なGUIを生成しませんが、少なくとも必要な機能をキャプチャできます。

すべての場合において、各反復を明確に文書化し、受け取った入力、実行した内容（詳細）および結果についてメールを送信するようにしてください。（要件の欠如など）などの適切な原因に結果を起因させるようにしてください。

残念ながら、一部の人々はアドバイスを受け入れません。だから、彼とどのようにコミュニケーションをとるかに注意してください。

これはうまくいきません！

幸運を。

私はそのようなボスを持っていました。実際、彼のモットーは「優柔不断が柔軟性の鍵」であったと冗談を言うでしょう。

どのような開発作業を行っても、おそらく上司よりもクライアントの問題を解決するのに適した立場にあります。クライアントが解決しようとしている問題がわからない場合（仕様とは異なります）、誰かが要件を適切に収集していません。

いくつかのページレイアウトをスケッチするか、非/半機能プロトタイプを構築します。しかし、何かをしてください。フルクライアントソフトウェアを構築するのか、ウェブアプリを構築するのかは投稿から明確ではありませんが、後者の美しさは、リリースの早い段階から頻繁にリリースできることです。ベアボーンから始めて、そこから作業を進めます。誤った開始は、何らかの対話が行われ、いくつかの決定が行われても害はありません。

クライアント向けの$ WORK（内部Webアプリ）については、「あなたが欲しいものを教えてくれるように、何かをあげます」と言っています。最初のドラフトを破棄する準備をしますが、実際に必要なことはめったにありません。

彼に、アジャイルの本はできる限り決定を延期するよう提案しているが、それ以上ではないことを指摘しなさい。すべての決定には、それを行う必要があるポイントがあり、おそらくあなたは今そこにいるでしょう。

一方、自分自身にも疑問を投げかけます。このアプリに使用する永続レイヤーを決定する必要が本当にありますか？または、CSVへの書き込みから始めて、後でその決定を下すために十分に抽象化したままにしておくことができますか？

独自の仕様書を作成し、説明を記載したレビューを開催し、彼はそれを承認します。その後、あなたは上司になり、上司は技術的な問題よりも対人関係の管理の問題に移行します。

上司やクライアントとの「上向きの管理」の話し合いに取り組み、いくつかのソリューションを見つけ、チームが実装するのに最適なソリューションを選択し、他のソリューションの欠陥を見つけ、マネージャーを「管理」して「正しい」決定を下します。

そしてもちろん、彼はそれがすべて彼/彼女のアイデアだと思っていることを確認してください。（特にそれがすべてうまくいかないとき！）

何かを設計して実装する必要があります。上司が決定を下さないので、自分で決定してください。実装する前に、決定と仮定を文書化するために少し時間をかけてください。上司を含む関係者に送信してください。うまくいけば、そのリストには上司以外のものも含まれているので、他の人はあなたが進む準備ができていることを他の人が知っているので、上司にいくつかの決定を迫るでしょう。特に他の人が同意しない決定を下す場合、書面で決定を下すとフィードバックがすぐに得られることに驚くでしょう。それまでの間、別段の指示がない限り、あなたの決定を進めます。

あなたが上司が望んでいないものを実装する時間を無駄にした場合、それは彼の上にあり、あなたがそうする道を知っていたのであなたの上ではありません。

また、始めるのに苦労している人もいますが、具体的なものを見ると心が動き始めます。上司がそのようなものであり、書面で何をするつもりかを彼に伝えることで心を動かすことができます。

自分で決定を下し、コーディングを開始します。もちろん、柔軟な方法で開発することは役立ちます（ロバートCマーティンのアジャイルパターン、原則、およびプラクティスをまだ読んでいない場合は読んでください）が、決定が行われない場合、世界のすべての柔軟性は役に立ちません。考えていることをただ開発する必要があるかもしれませんが必要であり、必要に応じて変更します。多くの場合、クライアント/上司は、見たいと思うか、見たくないものが見えるまで、何が欲しいかを知りません。これはおそらく開発者の範囲外にあなたを連れて行きますが、それは人生です。私と同僚がビジネス上の意思決定を効果的に行っていることにしばしば気づきます。時にはこれらは疑問視されず、私が下した決定は、純粋に他の誰も決断を下さないだろうという理由でビジネスを推進し始めました。すべての前提と決定（例外なし）をリストし、それらを上司に提示してください。