マネージャーはデモごとに要件仕様を変更し続けます
私の職場環境の背景
私のマネージャーは、コンピューターやソフトウェアについての知識や背景がまったくありません。彼は、自分の生活の中で、いかなる形でも（物理的な距離が10フィート以下でも）コードを見たことがない可能性が高いです。
私が実装するように求められていることの複雑さを理解している人はいません。セミハードコード化すればだれにもわからないほどです。
Joel's test では、信じられないほどのスコア0を記録します。
問題点
- マネージャーと時々他の「シニア」は要件仕様を変更し続けます。適切なエンジニアリングが行われ、パッチの「修正」ではない場合、基礎となる設計の変更が必要な変更。
- コードを見る人は絶対にいない（おそらく誰も方法を知っていないため、または行う必要がある場合でも）これは、誰も決してこれを行わないことを意味しますできる：
- 問題の複雑さや解決策の優雅さを評価してください。
- アプローチの改善を提案します。
- コードの品質を高く評価してください。
- コードを改善できる場所を指摘します。
- 文法的には意味のある多くの専門用語が使用されていますが、他の方法では意味がありません。
- ソフトウェア会社のように感じたり、行動したり、働いたりしません。
質問
何をすべきか？ 特に、私のコードの改善を指摘する人がいないことに関して
更新
HLGEM（およびおそらく他の人）が私がそれを試して修正するために行ったことについての質問に答えるためRedmineをセットアップし、ソースコントロールをすべての人に紹介することを提案しました。分散型（gitまたはMercurial）をお勧めしますが、集中型についても説明し、チームに決定させます。応答は物事が行われており、数週間以内に行われることでした。それを見たことがなく、会社の他の部分がそれを使用しているかどうかもわかりません。
ショートバージョン：
実行します。
やや長いバージョン：
managerがプロジェクトの実行方法を知らない場合、および上級者がそれに順守する場合、問題を修正するチャンスはほとんどありません。
ソフトウェアプロジェクトを管理するために、マネージャーはソフトウェアについて何かを理解する必要があります。マネージャがそうしない場合、彼らは最初に学ぶ必要があります。 あなたがあなたの経営者やあなたの先輩にそれがすべて間違っていると説得する可能性はありますか？あなたが彼らに何かを教える可能性は何ですか？
私はかつて同じような状況にありました（先輩がいなかっただけです）。私はひどい年の後にやめて、決して振り返りませんでした（嫌悪感を除いて）。
...要件仕様を変更し続けます。適切なエンジニアリングが行われ、パッチの「修正」ではない場合、基礎となる設計の変更が必要な変更。
現実世界のように聞こえます。これはいつでもどこでも起こります。はい、残念ですが、ある種のアジャイルな態度で耐えられます。さらに、ソフトウェアの良さの1つの指標は、その柔軟性です。挑戦してください。
文法的には意味のある多くの専門用語が使用されていますが、他の方法では意味がありません。
繰り返しますが、あまり馴染みがないように聞こえません;-)
私が実装するように求められていることの複雑さを理解している人はいません。
あなたでもないの？あなたがそれを理解していれば、鏡の中にそれを理解している人が一人います。したがって、会社の福利に対するあなたの責任は、おそらく正式な肩書きが示唆するよりも重いでしょう。あなたが問題を理解していてマネージャーが理解していない場合、彼らが会社を適切に指示できるように、経営陣に物事を明確にすることはyourの責任です。最寄りのマネージャーすべきは技術的に有能であると想定するのが妥当かもしれません（マネージャーほど能力があるとは限りません-彼らはマネージャーですが、あなたはエキスパートですが、少なくとも少しは有能です）。しかし、明らかにそうではなく、あなたが彼らを助けることができるなら、なぜあなたはそうしませんか？
簡単な回避策の解決策は、会社を切り替えることです。ただし、別のオプションとして、Joelテストの項目の実装を検討してください。 5からの項目は管理者とのより多くの協力を必要としますが、項目1から4は、誰にも尋ねられることなくそれらを設定することができるようなものです。
そうは言っても、SEの誰もあなたの正確な状況を知ることはできません。あなたは無能なジャークで混雑した会社にいる可能性があり、そのような混乱から何か良いものを作ることは誰にとっても多すぎるかもしれません。自分で状況を評価する必要があります。
コメントの1つで、これが最初の仕事だと言っています。私の経験では、マネージャーは専任のソフトウェアショップを除いて、どこも技術的ではありません。これは人生の一部です、それに慣れるだけです。
あなたのソリューションの優雅さを評価する人がいないので、あなたは泣き叫び泣きます。ここでの本当の問題は、あなたのソリューションの優雅さを評価する人がいないということではありませんが、あなたのソリューションがあなたが思っているほど良くないことを教える人がいないということです。事実上すべての新しいプログラマーは、実際のスキルを過大評価しています。メンターがいないと、より良い実践を手助けしてくれる人はいません。あなたを指導する人がいない場合は、ローカルユーザーグループに参加し、積極的に参加して、誰かをあなたに指導してもらいます。さらに良いことに、それは最終的にはより良い仕事を見つけるのに役立ちます。
あなたはジョエルテストでゼロを獲得しましたか？あなたが唯一のコーダーである場合（そしてそれがあなたが書いたもののように聞こえる場合）、彼らはなぜソース管理を使用しないのですか？何があなたを妨げていますか？あなたが唯一のコーダーでないなら、なぜコードレビューを行える人がいないのですか？すべての開発者がコードレビューを行います。特にマネージャーが技術者でない場合、それは管理機能ではありません。
要件はほとんどすべての場所で変化します。ビジネスニーズは絶えず変化し、プログラマーではない人は、何かが発生するまでプログラムが何をするかを視覚化できないことがよくあります。それから彼らはそれが彼らが必要とするものではないことを理解します。古いメソッドがその変更をうまく処理できなかったため、アジャイルが本当に生まれたのはそのためです。
管理者が自分でデータを入力したくない場合でも、バグ追跡を設定します。誰かがあなたに彼らに言及するように、新しいバグ/機能を入力する責任があります。変更が必要なときにマネージャーに他に27の割り当てられていることを伝えることができると本当に助かります。ここにリストがあります。優先リストを下に移動して、この新しい変更に対応させてください。実装したバグ修正と機能の数を数えることができるので、レビュー時に役立ちます。誰もがそれを使用していない場合は、少なくともあなた自身の仕事のためにできます。ソフトウェアをインストールできない場合は、Excelスプレッドシートを使用してください。率先してください。結果を表示できるようになると、他のユーザーの関心が高まります。 1人では作業量が多すぎると思われる場合は、バグトラッカーを使用して証明できます。
洗練された見た目のデモを提供しないでください！デモは、紙にペンで落書きされているように見えます。インターフェースが洗練されていればいるほど、技術者でない人はそれが完成したと思うようになります。
たとえば、ベストプラクティスやsemi_hardコードに従わないとだれも知らないかもしれませんが、気づくと、ずさんな悪い習慣に陥ります。それはあなたの次の仕事であなたによく役立ちません。したがって、状況に応じて可能な限り正しい方法に近づいてください。必ずテストを記述し（開発時間の一部としてこれを考慮し、特に見積もりの一部とは言わない場合でも、管理者が行う見積もりにそれを行う時間を置いてください）、それらのテストを使用して確認します。後で変更しても他のものは壊れません。
これは、成長と改善のための貴重な機会と考える必要があります。実際のコーディングの自由度は、キャリアのその段階で多くの人が持っているよりも多くなります。したがって、これを、成功した実装プロジェクトのポートフォリオを作成する機会と考えてください。その次の仕事を探しに行くとき、制度化されたソース管理、制度化されたバグ追跡、成功したプロジェクト実装のX個の作成などの成果を指摘できると、他の人よりも目立つようになります。
ここには、期待を上向きに管理する方法を学ぶ絶好の機会もあります。これはあなたのキャリアの残りの部分で重宝するスキルです。ここでこれを行おうとしても失うものは何もありません。物事はすでに良くありません。しかし、後でより良い場所で役立つ政治的スキルを学ぶことができます。費用便益分析を学ぶ。あなたが彼らと話すときあなたが説得できるようにビジネスドメインを理解することを学びなさい。会社への利益と利益の観点から話すことを学びます。割り当てられたすべてのタスクについて見積もりを行い、管理が提供するものと一致しない場合でも、見積もりと実際に何を行ったかを記録して、作業を見積もる能力を向上させます。推定値が歴史的に管理値よりも正確であることを示すことができれば、推定値が低すぎると彼らが耳にすると、彼らは耳を傾ける可能性が高くなります。ただし、より正確な見積もりと、最も重要なのは、プロジェクトを提供してそれらを機能させる能力の両方の最初に実績を構築する必要があります。繰り返しますが、これはあなたがあなたのキャリアで上に移動するときに持っている良いスキルです。
とりわけ、受動的ではなく、上からの改善が期待されます。
もし私があなただったら、私は別の仕事を見つけようとします。どうして？残念ながら、あなたの上司は「良くない」ということを知っていると思います。ただし、上司と一緒にいくつかのことを試してみる必要があります。
あなたが去りたくない、そして/またはあなたが誰かと話をするつもりがないなら、あなたはあなた自身で何かを見つけなければならないでしょう。社内の誰もあなたのコードを知らない場合、上司はあなたがあなたの要件を満たしていることをどのようにして知っているはずですか？ただ言って。
トークマネージャーと先輩にこれについて。 説明あなたの問題と解決策を提案します。伝えたい一般的なメッセージがわかるように、話を少し準備します。
講演終了後、しばらくお待ちください。物事が変化するかどうかを確認します。そうでない場合は、自分で変更を実装してみてください表示マネージャーとシニアに変更の肯定的な結果。
話が役に立たず、変更が却下された場合は、その場所でどれだけ働きたいかを自分でevaluateする必要があります。はい、仕事は悪いかもしれませんが、多分給料は良くて、あなたは5分の通勤しかありませんか？あなたの仕事の良い面が悪い面を上回っていますか？そうでない場合は、新しい仕事を探し始めます。
あなたの問題は、発券システムとバージョン管理が技術的な問題であり、非技術系マネージャーの入力に関係なくこれを行うべきであるということです。これは、技術的にはベストプラクティスとして想定されるべきであり、これがセットアップされていない場合は、自分で考えてこれを実現する必要があります。
技術者以外の管理者が、欠陥追跡、ソース管理、継続的な統合の利点を理解することは期待できません。これが彼らが非技術的であり、彼らがそれを知っていたり、気にかけたりしていない理由であり、彼らはドメインとビジネス知識の専門家です。彼らが提供すべき唯一のものは、高レベルの指示と要件です。
私には技術者以外のマネージャーもいて、ジョエルテストのスコアを4から8に上げることができました。私が行って許可を求めなかったからです。
あなたのグループには強力な技術的リーダーが必要であり、誰もその分野に踏み出したことがありません。
チェックアウト http://community.rallydev.com/ 彼らはアジャイルプロジェクト管理と欠陥追跡の優れた仕事をするコミュニティエディションを持っています。それだけでJoelのスコアが上がり、セットアップにサーバーのスペースや時間はまったくかかりません。
これが小さなお店で、あなたと他の「シニア」が基本的に唯一のコーディングをしている人の場合、実際にはyour責任があり、マネージャーに何をする必要があるかを示す必要があります「ジョエルテスト」を満たすため。
要件の変更は常にそこにあり、あなたの仕事はそれらを受け入れることです。これはベースの1つです アジャイル開発の原則 ：
開発の後半であっても、変化する要件を歓迎します。アジャイルプロセスは、変化を利用して顧客の競争力を高めます。
ただし、変化する要件に適応するということは、他のアジャイル原則にも従うことを意味します。管理レベルでは、これは、マネージャーがそのようなすべての変更にはコストが伴うことを顧客に透過的に提示できなければならないことを意味します。期限を満たすためにプロジェクトのスコープを変更するか、期限をシフトする必要があります（後者は推奨されません）。
これが、マネージャーがすべての要件を考案したプロジェクトのようなプロジェクトである場合は、彼/彼女がアジャイルな顧客であるように行動し、彼らに同じことを説明する必要があります（スコープ<->期限の妥協点） ）。
しかし、小さな会社の開発者レベルでは、コーディングの部分がアジャイルの推奨事項に確実に準拠するようにするのはあなたの責任だと思います。
これらはあなたが絶対にする必要があるいくつかのステップであり、おそらくあなた自身でそれらを行う必要があるでしょう：
- あなたがバージョン管理システムを持っている必要があります（小規模なチーム用にセットアップするのに1日かかります）
- あなたは必ずビルドスクリプトを使用して、リリースを頻繁に作成できるようにします（セットアップも非常に迅速です）。
- あなたは必須自動ユニットテストを使用する必要があります（これはコーディングの方法であり、設計全体を根本的に決定するため、それらを密結合プロジェクトの途中）
- 継続的な統合システムをセットアップして、自動化されたビルドとテスト、および機能テストとGUIテスト（これは少し書くのが難しい）を確実にすることもできます。
自分のマシンのローカルにSVNリポジトリを作成できることに注意してください。単純なTODOリストは、貧乏人のバグ追跡システムとして機能する場合があります（少し極端ですが、ちょっと）。そして、ビルドスクリプトがないという言い訳はありません。
また、スコープ/期限の妥協について説明する前に、特定の機能にかかる時間を予測する必要もあります。これは通常、アジャイルの世界では「理想的な日」で行われます。つまり、各機能の相対的な労力を予測するために最善を尽くし、実際のコーディング速度を使用して確認する必要がありますどのくらいうまく予測したか（それに応じて「曲線」をスケーリングしたかどうか）。
あなたのチームには責任の層が欠けていると思います。プロジェクトマネージャー、システムアナリスト、ビジネスアナリスト、開発者が必要です。プロジェクトマネージャーの役割は、（他のタスクの中で）顧客とプロジェクトのコミュニケーション戦略を定義して実施する責任があります。
マネージャーはコードや複雑さを理解する必要はありません。リソース、コスト、リスクを理解する必要性。
ソースコードのバージョン、コードの品質、複雑さなどは、PMの責任者または上級開発者の責任です。
解決策は次のとおりです。
1-プロジェクトチームの構造とその責任を定義する
2-管理に支障をきたすソフトウェア障害が発生した場合にマネージャーを教育する-技術的な詳細には近づかないでください。グーグルでいくつかの例を見つけることができます。
特に私のコードの改善を指摘する人がいないことに関して。
コードを見ている人がいるようにコードレビューを設定してみませんか？コードに構造を与えるのに役立つ規約や標準はありますか？もちろん、これはあなただけが開発者ではないことを前提としています。
あなたは素晴らしい場所ではないようですが、最終的にはうまくいっているように見えますか？プロジェクトは完了していて、物事は進んでいますか？物事は成し遂げられていますか？ ダクトテーププログラマー は、Joelの記事であり、読みたくなるでしょう。
オプション1-「このプロジェクトに加えたすべての変更を加えた場合、それを展開するまでにシステムの実行が非常に遅くなる」または「お客様がそれを理解できない」と伝えます。あなたのマネージャーはスパゲッティコードを気にしませんが、彼らは顧客を気にします。コードの記述ではなく、理解した内容で問題を説明します。
オプション2-必要なものを提供します。彼らがあなたが言うことについて不平を言うとき、それはあなたが求めたものです」