マネージャーは、デモごとに要件仕様を変更し続けます[終了]

職場環境の背景

私のマネージャーには、コンピューターやソフトウェアの背景や理解がまったくありません。彼は彼の人生でどんな形のコードも（10フィート以下の物理的距離からでも）見たことがない可能性が高いです。

私が実装を求められているものの複雑さを理解している人はいません。私が半ハードコード化すれば誰も知らないという点まで。

上ジョエルのテスト我々は信じられないほどのスコアスコア0。

問題点

• マネージャーおよびその他の「シニア」は、要件の仕様を変更し続けます。パッチを適用した「修正」ではなく、適切なエンジニアリングを行った場合、基礎となるデザインの変更が必要な変更
• コードを見る人は絶対にいません（おそらく、誰もその方法を知らないため、または行うべきであっても）。
  • 問題の複雑さやソリューションの優雅さを評価してください。
  • アプローチの改善を提案します。
  • コードの品質を評価してください。
  • コードを改善できる場所を指摘します。
• 文法的には意味がありますが、他の方法では意味をなさない多くの専門用語が使用されます。
• ソフトウェア会社のように感じたり、振る舞ったり、働いたりしません。

質問

何をすべきですか？特に、私のコードの改善点を指摘する人がいないことに関して。

更新

HLGEM（およびおそらく他の人）の質問に答えるために、それを試して修正するために何をしたかについて。Redmineをセットアップし、ソース管理をすべての人に紹介することを申し出ました。分散型（gitまたはmercurial）をお勧めしますが、一元化されたものについても話し、チームに決定させます。応答は、物事が行われており、数週間以内に行われることでした。それを見たことがないし、会社の他の部分がそれを使っているかどうかも知らない。

ショートバージョン：

走る

やや長いバージョン：

マネージャーがプロジェクトの実行方法を知らない場合、およびシニアがそれに沿って進む場合、物事を修正する機会はほとんどありません。

ソフトウェアプロジェクトを管理するために、マネージャーはソフトウェアについて何かを理解する必要があります。マネージャーがそうしない場合、最初に学ぶ必要があります。経営陣と先輩に、彼らがそれをすべて間違っていると納得させる可能性は何ですか？あなたに彼らに何かを教えるチャンスは何ですか？

私はかつて同様の状況にありました（シニアはいませんでした）。私はひどい年の後に辞め、決して振り返ることはなかった（嫌悪感を除いて）。

...要件仕様を変更してください。パッチを適用した「修正」ではなく、適切なエンジニアリングを行った場合、基礎となるデザインの変更が必要な変更

現実の世界のように聞こえます。これはいつでもどこでも起こります。はい、それはひどいですが、ある種の機敏な態度で我慢できます。また、ソフトウェアの良さの尺度の1つは、その柔軟性です。それを挑戦としてください。

文法的には意味がありますが、他の方法では意味をなさない多くの専門用語が使用されます。

繰り返しますが、それほど馴染みのない音ではありません;-)

私が実装を求められているものの複雑さを理解している人はいません。

あなたでさえない？あなたがそれを理解しているなら、それを理解している鏡の中に一人の人がいます。したがって、あなたの会社の幸福に対するあなたの責任は、おそらく正式な肩書きが示唆するよりも重いでしょう。問題を理解し、上司が理解していない場合は、経営陣に物事を明確にして会社が適切に指示できるようにするのはあなたの責任です。あなたの最も近いマネージャーが技術的に有能である必要があると仮定することは合理的かもしれません（必ずしもあなたと同じくらい有能ではない-彼らがマネージャーである間、あなたはエキスパートです-しかし、少なくともほんの少しは有能です）そして、あなたは彼らを助けることができます、あなたはなぜですか？

簡単な現実逃避の解決策は、会社を切り替えることです。ただし、別のオプションとして、Joelテストの項目の実装を検討してください。5以降の項目は経営陣とより多くの協力を必要としますが、項目1〜4は、だれにも尋ねることなく設定することができるようなものです。

とは言っても、SEの誰もあなたの正確な状況を知ることはできません。あなたが無能なジャークで混雑している会社にいる可能性があり、そのような混乱から良いものを作ることは誰にとっても多すぎるかもしれません。自分で状況を評価する必要があります。

コメントの1つで、これがあなたの最初の仕事だと言います。私の経験では、マネージャーは専門のソフトウェアショップを除き、多くの場合技術的ではありません。これは人生の一部であり、それに慣れるだけです。

あなたのソリューションの優雅さに感謝する人はいないので、あなたは泣き叫びます。ここでの本当の問題は、あなたのソリューションの優雅さに感謝する人がいないということではありませんが、あなたのソリューションがあなたが思っているほど良くないことをあなたに教える人がいないということです。実質的にすべての新しいプログラマーは、実際のスキルを過大評価しています。メンターがいなければ、より良い実践を手助けしてくれる人はいません。あなたをメンターする人がそこにいない場合は、ローカルユーザーグループに参加し、積極的に参加し、そこに誰かをメンターしてもらいます。さらに良いことに、それは最終的により良い仕事を見つけるのに役立ちます。

ジョエルのテストでゼロを獲得しましたか？あなたが唯一のコーダーである場合（そして、あなたが書いたものから聞こえます）、彼らはなぜソース管理を使用しないのですか？何があなたを妨げていますか？あなたが唯一のコーダーではないのに、なぜコードレビューを行える人がいないのですか？開発者はすべてコードレビューを行います。特にマネージャーが技術的でない場合、管理機能ではありません。

要件はほとんどすべての場所で変わります。ビジネスニーズは絶えず変化しており、非プログラマーは多くの場合、プログラムが何をするかを視覚化できません。それから彼らはそれが彼らが必要とするものではないことを理解します。古いメソッドがその変更をうまく処理していなかったため、アジャイルが実際に登場したのはそのためです。

管理者がデータ自体を入力したくない場合でも、バグ追跡を設定します。誰かがあなたに言及したときに新しいバグ/機能を入力する責任があります。マネージャーに、他の27の項目が割り当てられていることを変更する必要があることを伝えることができると、本当に役立ちます。リストを次に示します。バグ修正と実装した機能の数を数えることができるため、レビュー時に役立ちます。誰もがそれを使用していない場合、少なくともあなた自身の仕事のためにできます。ソフトウェアをインストールできない場合は、Excelスプレッドシートを使用します。イニシアチブを取ります。結果を表示できるようになると、他の人の関心が高まります。1人の作業が多すぎると思われる場合は、バグトラッカーがそれを証明するのに役立ちます。

洗練された外観のデモを提供しないでください！デモは、まるで紙にペンで走り書きされているかのように見えるはずです。インターフェースが洗練されているほど、技術に詳しくない人が完成したと考えるようになります。

たとえば、ベストプラクティスとsemi_hardコードに従わない場合、誰も知らないでしょうが、あなたは知っていて、だらしない悪い習慣に陥ります。それはあなたの次の仕事ではうまくいきません。そのため、状況に応じて可能な限り正しい方法に近いものを実行してください。テストを作成してください（開発時間の一部としてこれを考慮し、それが推定の一部であると明確に言っていない場合でも、管理に与える推定にそれを行う時間を入れてください）、それらのテストを使用して確認してください後の変更は他の何かを壊さない

これを成長と改善のための貴重な機会と見なす必要があります。あなたは、多くの人があなたのキャリアのその段階で持っているよりも、実際のコーディングに多くの自由を持っています。したがって、これを成功した実装プロジェクトのポートフォリオを作成する機会と考えてください。その次の仕事を探しに行くとき、組織化されたソース管理、組織化されたバグ追跡、作成されたX個の成功したプロジェクト実装などの成果を指摘できると、他の人から目立つようになります。

また、ここでは期待を上向きに管理する方法を学ぶ素晴らしい機会もあります。これは、あなたのキャリアの残りの部分で役立つスキルです。ここでこれを行おうとして何も失うものはありません。物事はすでに良くありません。しかし、後でより良い場所であなたを助ける政治的スキルを学ぶことができます。費用便益分析を行う方法を学びます。あなたが彼らと話すときにあなたが説得できるように、ビジネスドメインを理解することを学んでください。会社に対する利益と利益の観点から話すことを学ぶ。割り当てられたすべてのタスクの見積もりを行い、管理が提供しているものと一致しない場合でも、見積もりを記録し、実際に仕事を見積もる能力を向上させるために必要なことを記録します。過去の見積もりが管理の見積もりよりも正確であることを証明できたら、見積もりが低すぎると伝えると、耳を傾ける可能性が高くなります。しかし、より正確な見積もりと、最も重要なこととして、プロジェクトを提供して機能させる能力の両方の最初に実績を構築する必要があります。繰り返しますが、これはあなたがあなたのキャリアで上に移動するときに持っている良いスキルです。

とりわけ受動的ではなく、上からの改善が期待されます。

もし私があなただったら、私は別の仕事を見つけようとします。どうして？残念ながら、あなたのマネージャーは「良くない」ことを知っていると思います。ただし、マネージャーと一緒に作業を試みる必要があります。

あなたが去りたくない場合、および/または誰かと話すつもりがない場合、あなたは自分で何かを見つけなければならないでしょう。社内の誰もあなたのコードを知らない場合、あなたのマネージャーはあなたが要件を満たしていることをどのように知ることになっていますか？ただ言って。

これについて上司や先輩に相談してください。問題を説明し、解決策を提案してください。伝えたい一般的なメッセージがわかるように、少し話を準備します。

講演後、しばらくお待ちください。物事が変化するかどうかを確認します。そうでない場合は、自分で変更を実施し、変更のプラスの結果をマネージャーとシニアに見せてください。

話が役に立たず、変更が却下された場合、その場所でどの程度働きたいかを自分で評価する必要があります。はい、仕事は悪いかもしれませんが、多分給料は良く、通勤時間は5分しかありませんか？あなたの仕事のプラス面はマイナス面を上回りますか？私はそうしません、私は新しい仕事を探し始めます。

あなたの問題は、チケットシステムとバージョン管理は技術的な問題であり、非技術的なマネージャーの入力に関係なくこれを行うべきだということです。これは技術的にはベストプラクティスとして想定されるべきであり、もし彼らがこれをセットアップしていないなら、あなたはこれを実現するために自分自身でそれを取るべきです。

技術者でないマネージャーが欠陥追跡、ソース管理、継続的インテグレーションの利点を理解することは期待できません。これが彼らが非技術的である理由であり、彼らはそれについて知ることも気にすることも想定されていません。彼らはドメインとビジネスの知識の専門家です。彼らが提供すべき唯一のことは、高レベルの指示と要件です。

非技術系のマネージャーもいますが、Joel Testのスコアを4から8に増やすことができたのは、私が行って許可を求めなかったからです。

あなたのグループには強力な技術リーダーが必要であり、誰もプレートにステップアップしていません。

http://community.rallydev.com/をチェックしてください。アジャイルプロジェクト管理と障害追跡の優れた仕事をするコミュニティエディションがあります。それだけでJoelスコアが上がり、セットアップにサーバースペースや時間は一切かかりません。

これがあなたと他の「シニア」が基本的にコーディングする唯一の人である小さな店である場合、実際には「ジョエルテスト」を満たすために何をする必要があるかをマネージャーに示すのはあなたの責任かもしれません。

要件の変更は常にそこにあり、あなたの仕事はそれらを受け入れることです。これはアジャイル開発の基本原則の 1つです。

開発の後期であっても、要件の変更を歓迎します。アジャイルプロセスは、顧客の競争上の優位性のために変化を利用します。

しかし、変化する要件に適応するということは、他のアジャイル原則に従うことも意味します。管理レベルでは、これはマネージャーがそのようなすべての変更にコストが伴うことを顧客に透過的に提示できる必要があることを意味します：期限を満たすためにプロジェクトの範囲を変更するか、期限を変更する必要があります（後者は推奨されません）。

これがプロジェクトのようなもので、マネージャーがすべての要件を満たしている場合は、彼/彼女がアジャイルな顧客であるように行動し、同じことを彼らに説明する必要があります（スコープ<->期限の妥協）。

しかし、小さな会社の開発者のレベルでは、コーディング部分がアジャイルな推奨事項に準拠していることを確認するのはあなたの責任だと思います。

これらは絶対に必要な手順であり、おそらく自分で行う必要があります。

• バージョン管理システムが必要です（小規模なチーム用にセットアップするには1日かかります）
• 頻繁にリリースできるようにビルドスクリプトが必要です（セットアップも非常に迅速です）
• 自動化された単体テストを使用する必要があります（これはコーディングの方法であり、設計全体を根本的に決定するため、密結合プロジェクトの途中でそれらを追加することは困難です）
• また、自動化されたビルドとテスト、および機能テストとGUIテスト（作成が少し難しい）を確実にするために、継続的統合システムをセットアップすることもできます。

SVNリポジトリを自分のマシンにローカルに配置できることを忘れないでください。単純なTODOリストは、貧乏人のバグ追跡システムとして機能する場合があります（少し極端ですが、ちょっと）。また、ビルドスクリプトがないという言い訳はありません。

また、スコープ/デッドラインの妥協に関するステートメントを作成する前に、特定の機能にかかる時間を予測する必要もあります。これは通常、アジャイルの世界では「理想の日」に行われます。つまり、各機能の相対的な努力を予測するために最善を尽くし、実際のコーディング速度を使用して予測を確認します（それに応じて「曲線」をスケーリングします） ）。

あなたのチームには責任の層が欠けていると思います。プロジェクトマネージャー、システムアナリスト、ビジネスアナリスト、開発者が必要です。プロジェクトマネージャーの役​​割は、（他のタスクの中でも）顧客とプロジェクトのコミュニケーション戦略を定義および実施する責任があります。

マネージャーは、コードや複雑さを理解する必要はありません。理解する必要性、リソース、コスト、リスク。

ソースコードのバージョン、コードの品質、複雑さなどは、PMの責任者または上級開発者のものです。

解決策は次のとおりです。

1-プロジェクトチームの構造とその責任を定義する

2-ソフトウェアの障害により管理が不適切になった場合にマネージャーを教育する-技術的な詳細は避けてください。グーグルでいくつかの例を見つけることができます。

特に、私のコードの改善点を指摘する人がいないことに関して。

コードを見ている人がいるようにコードレビューを設定してみませんか？コードに何らかの構造を与えるのに役立つ規則や標準はありますか？これは、もちろんあなたがそこにいる唯一の開発者ではないことを前提としています。

素晴らしい場所にいる可能性は高いですが、最終的には機能しているように見えますか？プロジェクトは完了しており、物事は前進していますか？物事は成し遂げられていますか？ ダクトテーププログラマーは、読みたいJoelの記事です。

オプション1-「このプロジェクトに加えているすべての変更を加えて、展開するまでにシステムの実行が非常に遅くなる」または「顧客が理解できない」と伝えます。あなたのマネージャーはスパゲッティコードを気にしませんが、顧客を気にします。コードの書き方ではなく、彼らが理解することに関して問題を投げかけます。

オプション2-欲しいものを提供します。彼らが何かについて不平を言うとき、「しかしそれはあなたが求めたものだ」と言う