90％のメンテナンスと10％の開発を行っていますが、これは正常ですか？
私は最近、中規模企業のWeb開発者としてキャリアをスタートさせました。私が始めた直後に、既存のアプリケーションを拡張するタスクを取得しました（不適切にコーディングされ、長年にわたって複数のプログラマーによって開発され、同じタスクをさまざまな方法で処理し、構造をゼロにしています）。
そのため、要求された機能を使用してこのアプリケーションを正常に拡張した後、アプリケーションを完全に保守するためのタスクが与えられました。もちろんこれは問題ではなかったので、私は思った。しかし、既存のコードを改善することは許可されておらず、バグが報告されたときにのみバグ修正に集中することはできないと聞きました。
それ以来、上記と同じようにさらに3つのプロジェクトがあり、現在も維持する必要があります。そして、私はアプリケーションをゼロから作成することが許可された4つのプロジェクトを取得しました。それらも維持する必要があります。
現時点では、維持しなければならない各アプリケーションのユーザー（読み取りマネージャー）からの毎日のメールに少し頭がおかしくなっています。彼らは私がこれらのメールを直接処理すると同時に他の2つの新しいプロジェクトにも取り組んでいることを期待しています（そして、それらの後にすでに5つのプロジェクトが並んでいます）。悲しいことに、自分でコーディングしたものについてのバグレポートをまだ受け取っていません。そのため、180度ごとに異なる変更要求を時々受けました。
とにかく、これは正常ですか？私の意見では、私は開発者のチーム全体と同等の仕事をしています。
最初は物事が違うと思っていたとき、私は馬鹿でしたか？
この投稿は大騒ぎになったと思いますが、これはすべての開発者にとって同じではないことを教えてください。
追伸私の給料はスーパーのレジの給料よりも低くはないにしても、ほぼ同じです。
インターンシップ の1つで、バグ修正に多くの時間を費やしていることがわかりました。あなたは入門レベルの従業員として、あなたが最もセクシーな仕事を得るつもりはない、あなたは他の誰も欲しがらない粗末な仕事を手に入れるつもりであることを理解しなければなりません。それは残念なことですが、それはすべての仕事での状況です。
さらに、企業にとっては、クリーンなコードを持つよりも、機能するコードを持つことが重要であることを理解する必要があります。会社の観点から見ると、既存の構造を変更することは、すでに行われていることをやり直したり、さらに多くのエラーを強力に導入したりするのにお金を浪費することになります。通常、これらのタイプの企業はコンピュータ/ソフトウェア企業ではないため、十分なレベルの高いマネージャーは、これらの主要なオーバーホールを行う必要があることを知っている技術的背景を持っていません。とは言っても、あなたの会社が技術的に有能な人々によって運営されていて、彼らが優れたコードの価値を理解している場合、あなたはより多くの余裕を得るかもしれませんが、戦いを選択する必要がある場合もあります）。
とはいえ、ソフトウェアに自分の足跡を残せるようになり、より有意義な仕事をしたいというのは不合理ではありません。また、非常に多くの異なるマネージャーからの要求に応えながら、一度に非常に多くのプロジェクトに対処しなければならないことも残念です。
プログラマーとしては、自分でコードを最初から作成するよりも、他の人のコードを保守および変更することに多くの時間を費やすことになります。これがあなたにとって問題であるならば、あなたはおそらく趣味としての開発に固執し、別のキャリアを追求すべきです。コードの保守には問題がなく、効果的に使用されていない、または圧倒されていると感じた場合は、上司と話し合う必要があります。あなたの問題がそれより深刻である場合、または上司がスキルセットを効果的に管理する方法を知らないように思われる場合は、別の会社での職を見つけることを検討することをお勧めします。あなたの低い給与を考えると、これはおそらくあなたの最善の行動方針です。
管理には、ワークロードの管理とタスクの優先順位付けに問題があるようです。あなたはマネージャーに話しかけ、あなたが過負荷であることを理解させ、誰もがすぐに実行したい要求で誰もがあなたを攻撃し続けていると、効果的な仕事をすることができません。
これにより、あるタスクからプロジェクトにジャンプし、ギアの切り替えに多くの時間を費やすことになります。効果的なソフトウェア開発作業を行うには、タスクに没頭し、そのタスクに完全に集中できる必要があります。割り込みが多くなるほど、コンテキストの切り替えに費やされる時間が多くなります。研究によると、没頭して flow の状態になるまでに約15分かかります。 15分ごとに中断が発生した場合、流れが発生することはありません。これは、あなたと会社の両方にとって途方もない無駄です。
ですから、マネージャーとより賢明な作業モードを交渉するようにしてください。これには、着信リクエストの優先順位付けとある程度の事前計画を含める必要があります。すべてのユーザーリクエストは、優先度順に並べられたリストで管理する必要があります。また、優先順位はリクエスタによって決定されるべきではありません（当然のことながら誰もが彼/彼女のリクエストが地球上で最も重要であると考えています）十分なビジネス知識を持ち、メンテナンスしている製品の全範囲の概要を知っている人（製品所有者）。
理想的には、すべての受信リクエストを [〜＃〜] jira [〜＃〜] または Mantis のような課題追跡に入力する必要があります。または、少なくともあなたではなく、製品の所有者に郵送しました。そして、彼/彼女は、「なぜ私のリクエストはまだ準備ができていないのですか？！」に関してユーザーからのすべての不満に対処し、開発作業に集中できるようにするべきです。これが達成できない場合は、着信要求を調べて処理するときに、少なくとも時間枠を交渉して、開発の目的で時間の中断のない部分を予約する必要があります。
これが可能であれば、次のステップはある程度前もって計画を立てることです。つまり、優先度の高いリクエストの実装に必要な時間を見積もり、次に sprints にスケジュールします。これは、それぞれ1週間以上になる場合があります。あなたの時間をカバーするのに十分なタスクを次のスプリントに割り当てます。
おそらく、緊急リクエストを受信するために時間の一部を確保する必要がありますが、残りは事前に計画することができます。また、さまざまなプロジェクトの作業を別々の「ストリーク」に編成することもできます。つまり、月曜日にプロジェクトA、木曜日の朝にプロジェクトB、木曜日の朝にプロジェクトC、午後にDなどの作業を行います。コンテキストの切り替えを減らします。
このようにして、次の1週間または数週間で何をするかを大まかに把握できます。さらに、これはクライアントにもロードマップを提供します。クライアントは実装されたリクエストをいつ取得するかを確認できます。ここであなたのマネージャーに「アジャイル」という言葉について言及したいと思うかもしれませんが、これは基本的には アジャイル開発 ですが、実際には何であるかを知らずにアジャイルに反対する人もいます:-)
現在の地位が会社から高く評価されているように見えても、より多くのプロジェクトを維持するほど、交渉力が高まることに注意してください。
これらすべてのプロジェクトを維持するための新規採用者を見つけてトレーニングするには、会社にとってかなりの時間（=お金）がかかります。また、コードがこれらのアプリケーションのレガシー部分よりもはるかに優れていることを正しく指摘するかもしれません。そのため、同じ金額で同様の機能の候補を簡単に見つけることができるのは当然です。言うまでもなく、彼らが労働条件を改善しなければ、彼らは次の男をうんざりさせ、あなたと同じくらい早く辞任させます...彼らがそれを理解しているようにしてくださいあなたを守り、あなたがどこにいてもあなたを幸せに保つための彼ら自身の最善の利益:-)これは、あなたに上記の条件を交渉したり、昇給を要求したりする力を与えるかもしれません。
どのくらいの交渉力を持っているか-それは大きな問題です。あなたの経営陣はこれらのアイデアを受け入れるかもしれないし、そうでないかもしれません。しかし、あなたのカードを上手くプレイすれば、チャンスがあります。そして、彼らが拒否した場合...あなたは常により良い職場を探すことができます。この状況は、すべてのスターターで同じではありませんが、（悲しいことに）経験はかなり典型的です。しかし、本当に良い職場があります。職場の質は地理的位置と大まかにしか相関していませんが、私の感じでは、北ヨーロッパでは平均よりも高い可能性があります。したがって、現在の状態が著しく改善されない場合は、完全にうんざりして燃え尽きる前に、すぐに調査を開始する必要があります。
まだ仕事がある間に仕事を探す方が非常に良いので、すぐにお金が必要なだけという理由で最初のオファーを受け入れる必要はありません。最終的には、より良い場所を見つけるでしょう:-)
追伸私の給与はスーパーマーケットのレジの給与よりも低くはないとしてもほぼ同じです。
それを読むまで、交渉の仕方について何か書きたかったんです。今私が言えることはすべて休暇です！それが学位を持つ開発者が通常稼ぐものの半分であると仮定します。そして、物事が改善し、すぐに10％の増加が得られると仮定すると、そこに到達するのにかかる時間を把握できます。また、仕事で何も学んでおらず、優秀なエンジニアに囲まれているようにも見えないので、時間の無駄です。
私も同じような状況にありました、そしてあなたがそのトラックに留まればそれは終わらないとあなたに言うことができます。経営者はあなたにそれを突き刺し続けます、なぜなら...彼らはできるからです。
このトピックについて、私はいくつかの追加の考えを持っています。
好きなことをしてください。あなたがそれを愛していない場合は、あなたが愛しているかもしれないものを見つける試みをする準備をしてください。
コミュニケーション。非現実的な期待に応えることができないことを明確に伝えます。私の同様の経験で、建築家（最もシャベルをした人）は、「あなたは他の人の期待を管理しなければならない」と言いました。
バーンアウト。燃え尽き症候群を経験していない場合は、運命を誘惑しないでください。それはあなたの心からあなたの人生と魂を吸い込みます。あなたの最善の努力にもかかわらず、あなたの仕事の目的は灰色で、退屈で無意味になります。どうしても燃え尽き症候群を避けなければならないので、私はこのアドバイスをします。
トレーニング。こちらはシルバーの裏地です。あなたのトレーニングと経験は、苛立たしく、おそらく低給ですが、実際、あなたのキャリアにとって非常に貴重です。これは、できるだけ多くの学習を吸収し、避けられないガラスの天井を遅らせることができるため、これを実現するための節約の恵みです。
あなたが成長している才能とスキルに焦点を当ててください...これらはあなたのキャリアの次の機会を通してあなたを運ぶでしょう。
ここで複数の問題を扱っています...明白なものから始めましょう...
これは正常ですか？
地獄。しかし...それは一般的ですか？残念ながらそうです。
バグ修正のフラストレーションについて
それはあなたが対処しなければならない残りの混乱とそれらがあなたに負担をかける複数のプロジェクトを許すわけではありませんが、私は開発者としてあなたを苛立たせながら、「バグ修正」のみのアプローチであることを簡単に述べたいと思いますは、会社とその経営者にとって完全に賢明なアプローチとなります。
バグとコストを増やすためのSurface
タッチするコードが多いほど、たとえそれを改善するつもりでも、バグが発生する可能性が高くなります。つまり、開発時間、テスト時間、およびコストが長くなります。そして、それが中から高欠陥のサービスリリースへと移行する場合、それは彼らにとって大きな混乱です。
ログのノイズ/フォグ
SCMの観点から見ると、バグ修正に関連する変更を明確に把握したいので、サービスリリースのブランチから直接作業する場合にも少し意味があります。実際に1行のコード変更を必要とするバグ修正を取り巻く何千もの変更を伴う15のコミットがある場合、それは少し面倒です。
したがって、新規採用者であるため、ソフトウェアのリファクタリングや拡張を控えるように依頼することはさらに理にかなっており、バグ修正を可能な限り「外科的」に行うことは、私の考えではまったく問題ありません。それは頭痛の種を寄せ付けないだけです。
あなたはそれについて何かできますか？
しかし、これは、コードの健全性と関係者の心の健全性の両方を実現する方法が存在することを意味するものではありません。ジュニアであるため、変更、特にバグ修正を誰かにレビューしてもらい、サービスリリースビルドに移行する前に承認されていることを確認する必要があります。それは根本的な変化を防止または制限し、より安全になります。
地獄からのプロジェクト
クラップコード、プログラマの群れ、複製、クラップアーキテクチャ
繰り返しますが、ここでは悪魔の支持者ですが、最初のリクエストに重要でないビットがいくつか含まれていることを示しています。
私のポイントはこれです：私は本当に本当にこの状態にないコードベースを引き継ぐことはめったにありません。そして、私が行ったオフチャンスでは、彼らは最近、かなり優れたプログラマーによってキックスタートされたプロジェクトまたはプロトタイプを開始しました。しかし、それらの驚くほど圧倒的多数はがらくたのように見えました、そしてこれらの恐ろしい数は実際のがらくたでした。優れたプログラマーや優れたプログラマーによって始められたものでも、最終的にはがらくたになり、締め切りやその他のエンゲージメントが役立ちます...
実際の産業用ソフトウェアエンジニアリングへようこそ！
そして、あなたは何が楽しいか知っていますか？ 多くの場合、Web開発の世界では状況が悪化します。楽しんでください！ :)
プロジェクトと要求が多すぎて、手と時間が足りない
問題はおそらくここにあります：
- あなたの管理（おそらく無意識のうちに）あなたを虐待すること、
- 同僚が（おそらく無意識のうちに）あなたを虐待している、
- あなたの（多分無意識のうちに）あなたのお尻をカバーせず、あなたの戦いを十分に戦いません。
管理者は、管理しているプロジェクトが多すぎることに注意する必要があります。そうでない場合は、できるだけ早く確認してください。また、それが公園のすべてのピックニックではなかったこと、そしてあなたがプレッシャーを感じたこと、そしてそれを止める必要があることを彼らが知っていることを確認してください。
周りを見回して、同僚が直接（実際には「Xがそれを処理できるようになる」と言って）、または間接的に（「私は適切な人物ではない」と言って）、他のタスクやプロジェクトをそらさないようにします。これ、誰か他の人を見つけてください」->最終的にはあなたになります）。
ここでの個人的な逸話：私は数年前にインターンシップを行いましたが、私の最後の日に、評価を得たとき、上司は私の仕事全体に非常に満足しているにもかかわらず、私に言った- マネージャーの1人は、別のインターンで「それほど楽しくないタスク」をアンロードしていたような気がしました彼らが私に迎えに来てくれると期待していたとき。私はmortifiedに彼らを失望させたように感じ、そして私が怠けているように見えるだろうと考えていたとき私の意図は正反対でした：私はより強く掴もうとしていたタスクと他の若いインターンに髪の毛を引っ張る問題を少なくする。私が彼の立場にあったなら、私は挑戦の欠如に飽きていて、おそらく彼のやり方を感じていたことに気づきませんでした。重要なのは、3つの非常に異なる事柄についてだれもが誤った仮定をしないようにするために、コミュニケーションをとる必要があるということです。
- できること、
- やりたいこと、
- およびあなたが喜んで行うこと。
ですから、それをこのようにするのはあなたのせいでもあります。しかし、それは正常であり、誰もが学ぶ必要のある教訓です。それは2文字で保持されます：[〜＃〜] n [〜＃〜]-[〜＃〜] o [〜＃〜]。
あなたは通常、それをより長いがそれほど課金されない答えの接頭辞として使用します：いいえ、私はこれを行うことはできません。いいえ、どうすればよいかわかりません。いいえ、私がこれにふさわしい人物かどうかはわかりません。いいえ、私はそれをしたことがありません。
最初は、「はい、私は（最終的には）やります」と言って、積み重ねてそれらを完了することができるように感じるのは非常に簡単です。 あなたの時間は、あなたのスキルの後で、あなたにとってもあなたの会社にとっても、最も貴重な資産であることを理解する必要があります。それが悪用された場合、-プロジェクト、期限、および予算に影響します。それと同じくらい簡単です。
また、報告する人が多すぎるのではないかと少し心配です。対処する顧客が複数いる場合や、複数のプロジェクトオーナー、または主要な利害関係者でさえコミュニケーションを取る必要がある場合は問題ありません。ただし、全体的に、特に新規採用者の場合は、ほとんどの場合、数人のマネージャーのみに報告する必要があります（ほとんどの場合、直属のマネージャーのみ、そして場合によってはリードまたはシニアの開発者のみ）。どうやってこのようになったのですか？知りません。それはあなたの会社の組織的な問題かもしれません、あるいはあなたが好意をして直接連絡した結果「いいえ」と言わなかった結果かもしれません。あるいは、あなたの直属の上司が、私が知っているすべてのために、タスクのディスパッチに関する問題である可能性があります（私は本当に推測していますが、パターンは認識可能でよく知られています）。
次のことをすぐに行うことをお勧めします。直接マネージャーに直接話しかけて、他のマネージャーが少し強引かもしれない、または（おそらく気まぐれではないかもしれないが）あまりにも多くの人からの積み過ぎが多いことを説明し、そしてどの入力に優先順位を付けるかを知るには、彼の入力（および場合によっては入力も）が必要です。
180度の変更リクエスト
これらは別の大きな問題です。それらはおそらくあなたのせいではありませんが、あなたが彼らがそれに対処するのを助けることを試みることができます。
「180度の変更要求」は、美しく正確に呼び出すと、要件が曖昧であることを示す明確な兆候の最初からであり、誰もそれらを削って片づけるのに十分な努力をしていません。時間。
通常、このような場合に誰かが電話に出て（または、より良いのは自分の足で）、=利害関係者をつかむ必要があります手で説明し、明確に伝えます。 、私たちが正しい方向に向かっていることを確認しましたか？」最初は明確な答えが得られなくてもかまいませんが、時間が経過するほど明確になるはずです。そうでない場合、このプロジェクトは災害の発生を待っています。
通常、私はすべての利害関係者を手の届くところに集め、部屋に入れ、訴訟を起こし、段階的にこれらを解決しようとします-そして、あなたがそれにいる間に優先順位を取得します。しかし、あなたの場合、これはあなたがすでに行うためのあなたの呼び出しではないかもしれません。しかし、あなたは彼らがあなたにプロジェクトの責任を本当に与えたと述べました。ですから、それが本当の場合は、責任を負ってください。そして恥ずかしがらないでください"私たちはそれを行うことはできません"または"私たちはそれをしません"と言うことから。プロジェクトの範囲を制限することは本当に重要です。
スコープがない場合、ディスカッションの最後に明確な要件はありません。
メールの過負荷
人々は、使用する通信媒体に基づいて異なる行動をとる傾向があります。個人的には、私はどちらかと言えばやさしい話者です（そして、主に海外で働いているので、電話で話すのはあまり好きではなくなります）が、生産性に基づいて優先順位を優先します。
- 対面で話す、
- 電話で人と話したり、
- iMで人と話したり、
- メールで人と話す。
メールは追跡、確認の取得、メモの送信に適しています。
問題のあるポイントのスケジュール、計画、および議論については、それらはほとんど役に立ちません。 男のドアをノックしてください男がドアを開けてメモ帳とドキュメントのコピーを添えて座って物事を明確にします。完了したら、メールを送信して確認を求めます。否定的な答えが返ってきた場合や、封筒に何かを忍び込ませようとするわずかに隠れた試みがあった場合は、対談担当者のオフィスを再び包囲してください。
これはソフトウェア工学です。多くの場合、キーボードでタイプ入力しないと生産性が向上し、実際に対処する必要があるがらくたを前もって削減できます。
チームの価値ある仕事をする
あなたはチーム相当の仕事をしていますか？多分。
あなたはあなたのチームと同等の仕事をしていますか？おそらくそうではありません。
つまり、あなたのチームはおそらく忙しく働いており、あなたは過労だということです。そして、それが問題です。現在のプロジェクトのタイムラインから押し出されたり、時間のある人に渡されたりする必要があるものが多すぎます。
最初は物事が違うと思っていたとき、私は馬鹿でしたか？
番号;パーティーは初めて。それは最初の二日酔いや関係のようなものです。あなたはそれを乗り越えるでしょう。
この投稿は大騒ぎになったと思いますが、これはすべての開発者にとって同じではないことを教えてください。
これは、スタートアップや老舗の巨人など、混沌とした組織のすべての開発者に同じであり、規模の右側に生存のチャンスを傾けるために物事を少しでも動かす経験や自信がありません。
追伸私の給与はスーパーマーケットのレジの給与よりも低くはないにしても、ほぼ同じです。
私は安っぽく見える仕事にまともな給与をしました。重要なのは小切手の数字ではなく、状況です。何をしているのか、あなたの年齢、どこに住んでいて働いているのかなど...
そうは言っても、あなたが著しく低賃金で、働きすぎで、完全にジュニアではない場合は、[昇給を依頼するか、新しい仕事を得る！
それは簡単です：
- 彼らがあなたの行動を評価するなら、彼らは昇給に喜んで同意します、
- そうでない場合、この会社の将来はそれほどばらばらに見えるわけではないので（少なくとも、あなたにとってはそれが重要なことです）、辞めることを気にしないでください。
最初はそう考える必要はないかもしれませんが、昇給を求めることはis良いことです。それはあなたがあなたが何をしているのかを追跡していることを証明し、あなたがまだ機内に留まりたいと思っている間、あなたが他のオプションに目を離さないことを示唆します。そして、彼らは就職の面接や交渉一般のようであるため、それらを要求することに慣れるのは良いことです。これは練習が必要なものであり、自分で手を伸ばさなくても空から落ちることはありません。一部の企業は要求されずに定期的にレイズを配布しますが、それは彼らがあなたを半分幸せにし、変化する気が少なくなることを知っているのに十分利口であり、彼らがあなたの足の下の草を刈りたいと思っているからです（ほとんどの人は直接提供されたレイズオファーの引き上げについては少し不安です）。
このリクエストの処理方法は、ここではこのプロジェクトの範囲外なので、詳細には触れません。ただし、SCMコミットID、修正済みのバグと実績の記録を準備し、それらをチームの全体的な取り組みと比較するレポートも準備することをお勧めします。こちらです：
- 自分で測定できます同僚よりもはるかに効果的だったかどうか
- あなたの立場に立つことができます彼らがあなたの要求が正当化されないと言っている場合。
他の人のコメントに加えて：
はい、エントリーレベルの従業員が他の誰もしたくない仕事を与えられるのは普通です。
あなたはこれをあなたの将来のキャリアのためのビルディングブロックとして見るべきです。
それであなたは何をすべきですか？プロの開発者であることを証明するには、作業が構造化され、計画されていることを確認する必要があります。そうしないと、現在行っている優れた作業に基づいて構築することが難しい場合があるため、次のようなことを試みる必要があります（あなたはまだです）。
プロジェクトごとに、作業を正確に記録します。したがって、プロジェクトAのバグを修正するのに1時間費やした場合は、この時間をログに記録してください。これは、ワークロードについて話し合いたい場合にマネージャーに示すのに役立ちます。
単体テストを記述します。あなたが維持しているプロジェクトのいくつかはバグでいっぱいであると言っているので、私のテストではユニットテストは（もしあれば）少ないと思います。バグレポートごとに、バグを複製する単体テストを記述してから、バグを修正します。これは、リグレッションが発生しないことを保証し、コードの品質を向上させ、機会が与えられた場合にコードをリファクタリングするプラットフォームとして機能します（たとえば、一部の部分を書き換えることで改善できることを関係者に納得させるのに役立ちます）ユニットテストスイートにより、新しいバグを招くことのない品質）。
新しい仕事を探します-一度に多くのプロジェクトに取り組み、コードを最初から作成し、プロジェクトのライフサイクル全体を経験した可能性があります。これらはすべて他の場所に適用するための良い経験です。
あなたの状況は少しエッジの効いていますが、それでも正常です。しかし、それを処理する方法は非常に悪いです。これはあなたがする必要があることです：
上司に立ち向かおう。不正なコードベースが実際にどれだけの時間を費やしているかの証拠（数値）が必要です。彼が技術的負債のようなものを理解していない場合は、それについて言及するのをやめてください。それはあなたの頭を破壊し、あなたは「悪い態度」の男としてマークされる可能性があります。上司に仕事をするように教えるのはあなたの仕事ではありません。
独自のバックログ（かんばん）を維持します。新しいタスクが来たら、それを終了し、完了の推定時間を伝えます。
応答時間を増やし、1日2回だけメールをチェックしてください。通常は昼食前と出発直前。 （メールをチェックした後にコードを記述しないでください。頭を壊す可能性があります）。
各タスクの一部として小さなコードの改善を行います。使用しているコード、スキル、ツールを改善するのは単にあなたの仕事です。それはまた長期的にあなたの道徳を後押しします。
日中のプロジェクトの切り替えはありません。今日は単にプロジェクトXに取り組んでいますが、明日はYの他のタスクを開始します。
ゲートキーピングのために1日あたり1時間を割り当てます。これは、取るに足らない小さなタスクを意味します。このタスクに10分より長い時間がかかる場合（理由がどうであろうとも）、それはバックログに入り、マネージャーに通知されます。
今、難しい部分があります。現在、マネージャは互いに通信していません。自分のプロジェクトを最優先で完了すると想定しているだけです。あなたは議論の真っ最中なので、これはあなたの頭に多くのストレスをもたらします。マネージャーに作業の調整を開始するように強制する必要があります。最後に、素敵でシンプルなバックログが必要です。マネージャーはあなたなしでお互いをいじめます。
それでは、簡単なロールプレイングをしましょう。 3つのマネージャーとプロジェクトがあります（プロジェクトXのXavier、プロジェクトYのYvonne、プロジェクトZのZed）。 Xに5日間、Yに5日間の2週間のバックログがあります。
- Zはいくつかのタスク（1日）を実行するように求めます
- 11日で完了すると回答しました。
- Zは、それは単純なタスクであり、1日以上かかるべきではないと応答します（Zは小さな圧力をかけることに注意してください）。
- あなたは現在Xで働いており、Zでは後者で働いていると答えます。その後、彼女の仕事をすることができます。
- Zは、とにかくすぐに彼のタスクを実行するように応答します（圧力の増加、XおよびY領域への直接違反）。
- あなたは彼女の仕事をするとXとYの仕事が遅れるだろうと答えます。彼はまず彼らに尋ねるべきです。 あなたもCC XとYです。
現在、2つの目的があります。
マネージャーは互いに吠え始め、多くのメール、おそらくいくつかの会議...離れて、勝者にタスクを割り当てさせるべきです。
何も起こりません、Zは彼の仕事がどこにあるか2日後に尋ねます。あなたは現在Xで働いていると答え、彼はプロジェクトZについて何も言及しなかった。再びCCX。
これで、このタイプの動作により解雇される可能性があります。しかし、あなたの状況は持続不可能であり、おそらくとにかくすぐにやめるでしょう。このソリューションは、マネージャーが互いに競合している場合にのみ機能します（ごく普通）。また、だれかがだまされていると不平を言う場合に備えて、作業の記録（バックログ）を保持する必要があります。
7年前、私はしばらくの間ほぼ100％のメンテナンス作業を行っていて、それについての記事を書きました The Art of Maintenance Programming 。役立つと思われる部分：
- 好きになる
どうすれば誰でもメンテナンスプログラミングを好きになることができますか？開発者はチームのチーフアーキテクトになることを夢見ており、開発者が既存のソフトウェアを維持することになると、それはまるで罰のように感じられます。必ずしもそうである必要はありません。メンテナンスプログラミングには独自の一連の課題があり、多くの創造性、適応性、忍耐力、規律、優れたコミュニケーションが必要です。それはあなたのキャリアにとっても良いことです。履歴書に「アーキテクトされたn層24/7エンタープライズアプリケーション」のような大げさなエントリがあることは見栄えが良いですが、実際に雇用主は問題を解決する人を高く評価しています。メンテナンスプログラミングは、問題解決スキルを実証する絶好のチャンスです。
あなたの問題はあなたがより頻繁に聞くsommethingのように聞こえます。これは、 The Daily WTF に簡単に適合できるジョブのようです。
多くの組織は、品質よりも販売や機能の推進に重点を置いています。これらの企業が見落としているのは、ソフトウェアの外的品質以上のものがあるということです。 ワードカニンガム は 技術的負債 という用語を作り出しました。
また、技術的な負債について Steve McConnellを読むこともできます 。彼はいくつかの興味深い点を持っています。 Google Tech Talkでは、 Ken Swaberがアジャイルソフトウェア開発について語っています 。良い部分はあなたに似た物語についてです。彼は、 リファクタリング をまったく行わずに、さまざまなプログラマーによるプログラミングの10年後に「頭がおかしい」ソフトウェアプロジェクトについて語っています。このビデオを見れば、あなたが説明していることと多くの類似点があると思います。
ソフトウェアシステムは、拡張すると品質が低下します。実際に生き残るためには、それが必要です。 リーマンの法則 はこの原理を非常によく説明しています。最終的には、次の質問に要約されます： 「上司にリファクタリングを行うように説得するにはどうすればよいですか？」 。
私が同様の問題にどのように取り組んだか：
- 私は上司に立ち向かい、開発を続けるとコード品質が低下することを説明しました（ リーマンの法則 ）。
- 私は上司に 技術的負債 の概念を説明しようとしました。そして、彼があなたを働かせる方法は、長期的には彼にお金がかかる方法です。
- 実際に問題の深刻さを示すために、私自身の時間で静的コード分析を行いました。上司はソフトウェアを理解していませんが、数字は理解しています。コードメトリックス には欠点がありますが 、測定可能な測定値があるとよいでしょう。これらのメトリックの通常の読み取り値を調べてみてください。これを独自のコードベースと比較すると驚くでしょう。
- 何も役に立たず、何も変更されない場合、実行できる唯一のことは、特定の新機能にはコードベースの他の部分の再加工が必要であることを説明することです。重複するコードがあり、変更のコストも重複する何かを変更したい場合は説明してください。
- 前のポイントに対する一般的な答えは、誰もこの再作業に対して要求しておらず、したがって支払っていないということです。その「たぶん」この手直しは不必要です。ソフトウェアは常に変更する必要があることを説明する必要があります。 リーマンの法則 が言うように;使用し続けるには、変更する必要があります。そうでない場合、変更を加えた他のプログラムは常に存続します。変化を期待し、生き残るのは変化に適応できる人々です。これが アジャイルソフトウェア開発 のすべてです。 （ ウィキペディア ）
私の上司は最近、技術的負債の概念を使用して、構築するソフトウェアの一部を再加工する必要があることをお客様に説明しています。それを証明するために-あなたが合理的な上司を持っている場合、物事をより良いものに変えることが可能です。
あなたが直面している状況は、（完全ではないにしても）ほとんどの新入生にとってほぼ同じです。
これはキャリアの初期段階で起こります。ここに問題があります。この問題を克服し、会社にその価値を証明する必要があります（中規模または [〜＃〜] mnc [〜＃〜] ）。私たちは状況が私たちに何を要求するかについて決定を下すことができるはずです。ですから、あなたがそのことに気づき、自分の仕事に個人として立つならば、仕事に力を注ぐことに害はありません。あなたが価値があるなら、会社は気づくでしょう！アディオスと幸運。
私の意見では、リファクタリングを禁止する会社は働く価値はありません。リファクタリングは必須のソフトウェア開発スキルであり、バージョン管理ツールを使用すると、「トランク」を壊すことなく変更を分離して非常に簡単に開発できます（リファクタリングが実際にした場合何かを壊す）。 ボブおじさん が言う（言い換え）：「専門家になって仕事を正しくするように頼む必要はありません。」
メンテナンスプログラミングは、不良コードが永続することを意味するものではありません。
5年前に私の友人からこのメールを受け取りました。
Email body:
新しく加わった研修生エンジニアは、上司に「評価の意味は何ですか」と尋ねます。
ボス：「辞任の意味を知っていますか？」
研修生：「はい、そうです」
ボス：「評価と辞任を比較して、評価とは何かを理解させてください」
Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------|
| Appraisal | Resignation |
|---------------------------------+----------------------------------|
| In appraisal meeting they | In resignation meeting they |
| will speak only about your | will speak only about your |
| weakness, errors and | strengths, past achievements |
| failures. | and success. |
|---------------------------------+----------------------------------|
| In appraisal you may need to| In resignation you can easily |
| cry and beg for even 2% | demand (or get even without |
| hike. | asking) more than 10-20% hike.|
| | |
|---------------------------------+----------------------------------|
| During appraisal, they will | During resignation, they will |
| deny promotion saying you | say you are the core member of|
| didn't meet the expectation,| team; you are the vision of |
| you don't have leadership | the company how can you go, |
| qualities, and you had | you have to take the project |
| several drawbacks in our | in shoulder and lead your |
| objective/goal. | juniors to success. |
|---------------------------------+----------------------------------|
| There is 90% chance for not | There is 90% chance of getting|
| getting any significant | immediate hike after you put |
| incentives after appraisal. | the resignation. |
|---------------------------------+----------------------------------|
研修生：「はい、上司、もう私の将来を理解しました。評価のために辞任する必要があります... !!!」
私があなただったら、無料でアプリケーションを再構築する作業のあと、遅い時間を費やすことになります。それはおそらく楽しい仕事でしょう。終わったら上司に見せてください。それが機能し、あなたがそれにメンテナンスをしているなら、彼は心配する必要は何もないはずです。これはあなたの仕事をはるかに容易にし、会社でのあなたの可能性に高いレベルの目を開くでしょう。
私はフルタイムの大学生で、1時間10ドルでアルバイトのインターンシップをしています。私は、退屈で反復的で簡単なQAを行います。私はいつかこれがより大きくより良い場所への扉を開くことを知っているので、私は自分が非常に幸運であると考えています。
はい、あなたは常にあなたと他の人々の両方によって書かれたアプリケーションを維持する必要があります。唯一の例外は、メンテナンスを必要としないプログラムを作成する場合です。だから、あなたはより良いメンテナンスを得ることができます。
あなたのアプローチの欠陥についてのあなたの質問には微妙なヒントがあると思います。つまり、バグの修正にはコードの改善は含まれません。
しかし、既存のコードを改善することは許可されておらず、バグが報告されたときにのみバグ修正に集中することはできないと聞きました。
「コードを改善せずにバグを修正する必要がある」と誰かが言ったなんて信じられません。これは難しいと不可能の両方です。既存のコードベースで使用されているアプローチが気に入らない、または理解しにくいという理由だけでアプリケーションを書き直すことはできません。
私のアドバイスは、リファクタリングを学ぶことです。バグを修正しているときはいつでも、コードの少なくとも一部を改善する機会があります。コードベースのどの程度がリファクタリングされるかは、バグが何であるか、およびコードの良し悪しによります。しかし、バグを修正して コードのにおい をあちこちに残している場合、あなたは仕事をしておらず、 技術的負債 を築いています。
いくつかのバグは実際には単にリファクタリングによって修正されており、時には コードを理解するためにリファクタリングする が役立つことがあります。これは、コードの保守性と一貫性を向上させるためにリファクタリングを行う必要があるためです。
バグ修正を見積もるとき、私は通常、メジャーなリファクタリングがそれを行うための最良の方法になるかどうかを決定し、それを考慮に入れます。単体テストでも同じです。これらは両方とも、コードの記述方法の一部であり、余分な時間を必要とするオプションではありません。
したがって、「バグを修正するときにコードを改善できますか」と尋ねるべきではありません。とにかくあるべきだから。 「バグを修正するためにリファクタリングを使用できますか」と尋ねるべきではありません。アプリケーションをバグアウトさせる原因となっているコードがリファクタリングを切実に必要としているのであれば、とにかくそれを行うべきです。 「このバグを修正するときに単体テストを作成できますか？」と尋ねるべきではありません。バグの修正を始める前に、回帰テストを書く必要があるからです。
注意：私は彼の記事の3つをリンクしたので、この回答のいくつかの帰属はジェフ・アトウッドに行くべきだと思います。
あなたが既存のコードを改善することが禁止されているという範囲であなたをマイクロマネージすることはあなたの雇用主の決定であってはなりません。あなた自身の専門的な判断を使用してください。作業量を見積もるときに、将来の生産性が向上する場合は、リファクタリングを考慮して追加の時間を考慮します。
とにかく、あなたはあなたの雇用主と効果的にコミュニケーションしていないようです。
あなたはリファクタリングがお金を節約するという証拠を持っています。リファクタリングプロジェクトの提案を起草し、ビジネスで節約できる時間と費用を示します。コードにどのような変更を加え、どのくらいの時間がかかるかを正確に説明します。
コーディング、会議、メールの返信に費やした時間を記録するために、正確なログを保管してください。これにより、予定より遅れた場合に保護されます。
徐行。これは少し直感に反するように思えるかもしれませんが、すべてをすばやく実行する場合にのみ、時間が乱用されます。あなたが少ないことをすれば人々はあなたの時間をより尊重するでしょう。たとえば、1日に1〜2回だけメールをチェックします。そうしないと、燃え尽きの危険があります。
あなたの給与率を考えると、頭痛の種を取り除く価値はありません。毎日時間通りに出発するようにしてください。追加の補償なしに余分な時間を費やさないでください。例外は、優れた進歩のオプションがある場合、または会社の評判があなたの履歴書を大幅に後押しする場合は、それを吸い上げる必要があります。
詳細を知らなくても、上司とよりオープンになってみることをお勧めします。タスクの見積もりを増やし始めるかもしれません。ワークロードがどれほどビジーであるかを常に通知します。また、上司と面談し、今後6か月以内に給与を引き上げたいことを説明し、この昇給を達成するために業績を向上させる方法を尋ねる必要があります。
幸運を。
あなたの雇用主と話してみて、あなたがこれを解決できるかどうか見てください。あなたはこれについて頭を悩ませているように思えますが、それは悪いプログラマであることとは何の関係もありません。
中小のウェブ企業は、同時に多くのプロジェクトを進行させる傾向があり、多くの点で、それでもあなたを一概に言えません。状況を最大限に活用するか、可能であれば新しい仕事を見つけてください。私はもっと良いコーディングの仕事があることを約束しますので、この最初の人があなたを怖がらせないようにしてください。
幸運を祈ります。あなたとあなたの同僚の両方が重力またはあなたの努力を理解してくれることを願っています！
個人的な経験
ここにいる多くの人のように、私もあなたの状況を認識しています。私は基本的に給料が低い最初のコーディングの仕事を手に入れ、構造の悪い多くのビルドされたコードを維持する必要がありました。最初は新しいことを学ぶのは面白かったですが、結局、維持する必要のあるプロジェクト、作成する新しいプロジェクト、そして毎日どんどん大きくなるホワイトボードがあり、私がやっていなかった点が増えていました。うまくいかなかった。
2年間それを我慢した後、私は辞めて、数か月後に別のコーディングの仕事を見つけました。
とにかく、多くの場合、問題になるのはプロジェクトだけではありません。自分の仕事が認められ、尊敬されるようになると、自分は職場でより快適になります。あなたがいる状況の問題は、雇用主が作成されたプロジェクトから発生するバグに気づくだけで、他のすべてのバグを削除するのにかかる時間ではないということです。
給与
より多くのお金が欲しいなら、あなたはそれをしばしば得ることができます。なんとか2年以内に給与を交渉して33％の引き上げになりました。
基本的に、あなたの仕事の価値と、会社があなたにどれだけ必要かを考えてください。彼らがあなたが稼いだ給料をあなたに与える余裕がないなら、会社は彼らの費用を調べるか、彼らのビジネスがうまくいっていないことを理解する必要があります。
そして、ここで多くの人が述べたように、私も同意しますが、あなたは会社のパズルの非常に価値のある作品です。地獄、おそらくあなたはそのパズルを解くことができる唯一の人です。 :)
これはすべてお金の問題です。私の推測では、まず第一に、あなたはすでに彼らが支払った以上の額をすでに獲得している顧客にはおそらく親切すぎると思います。
新しいリクエストの価格を見積もる方法を学びます。これは簡単ではなく、顧客はよくあなたを試してみるでしょう。可能であれば、経験豊富なプロジェクト/製品マネージャーの支援を求めてください。
お金の面で考えると、経営陣とのコミュニケーションはずっと簡単になります。現在の顧客がフルタイムのお金を提供している場合は、新しいプロジェクトを選択しないでください。しかし、経営陣はあなたをいじめようとするつもりであることを理解するでしょう。
あなたが会社にとって本当に価値があるなら、あなたは交渉力を得るでしょう。より多くの人を雇うように依頼したり、新しいプロジェクトを減らしたり、メンテナンスの負荷を減らしたり、給与を増やしたりするように依頼できます。
私はこのStack Exchangeサイトに潜んでいるため、まだコメントできません。ここに情報を追加します。
始めたばかりなので、MicrosoftやAmazonなどの大企業に勤めない限り、給与はそれほど高くありません。しかし、それは食料品店の従業員のものではありません！長い間それを我慢しないでください、あなたがしていることをやっている経験を積んで、より良い機会が生じたら進んでください。
エントリーレベルのギグの場合、これは普通のことです。ワークロードが高すぎますが、作業のタイプが予想されます。より良い開発者になるには、他の人の過ちから学ぶ必要があります。見れば見るほど良くなります。しかし、それはあなたが悪い習慣を学ぶのではなく、学ぶべきことを探していることを意味します...
プロジェクト作業に対するメンテナンスの比率は、時間とともに変化するはずです。そうでない場合、それはあなたが働いている会社が優れた開発者を維持する方法を理解していないことを意味します。彼らはあなたに毎日同じことをやらせるつもりです。自分がどこになりたいか、給与と仕事の期待について賢明に年間目標を立て、それに応じて行動します。
4）満足できない場合は、そのままにしてください！人生は短すぎるので愚かな人々に対処することはできません。
ではごきげんよう。
ToDoリストを追跡するために、課題トラッカーの使用を開始します。
これは、何が重要かを追跡するのに役立つだけでなく、ユーザーと上司が現在のワークロードが何であるかを確認するのに役立ちます。
また、彼らが2人目の開発者を雇った場合（またはあなたが辞め、代わりにあなたのワークロードがかかるようになった場合）、これはワークロードの管理に役立ち、互いにつま先を踏まないようにすることができます。
私の経験では、アカデミックな世界、または技術志向のスタートアップの最初の6〜12か月が、真の白紙の状態に遭遇する唯一の信頼できる領域です。どちらも独自のコストがかかりますが、コーディングが好きで、実際に目にするコードの品質に恐怖を感じる場合は、これらの方向のいずれかにキャリアを向け始める必要があります。
上司はこれらすべての変更リクエスト（メンテナンスリクエスト）を認識していますか？あなたが制裁を行う権限のないような要求により、あなたの時間がふるいにかけられることに気づいていますか？それとも、マネージャーが要求するたびに変更を加えますか？
最初の連絡先はすべてをマネージャーのデスクに置くことだと思います。誰も直接あなたのところに来てはいけません。問題は、そのような分野を問わず、通常はサポートチームを通じて発生します。短いハンドオーバ期間（通常は1週間程度）でコードをサポートするのは通常のことです。変更は、「中規模」に分類されるすべての会社で費用がかかり、請求（転送請求）する必要があります。これは迂回されているようです（彼らがあなたを氾濫させているのも不思議ではありません-あなたはプロムの女のようです）。
問題の発生と変更要求の両方に対して適切な要求手順が必要です。サポート/メンテナンスは、バグと問題の修正に関するものです（元の仕様に適合しますが、コードのバグまたは外部のイベント（電源切断やアップストリームシステムの破損など）が原因で失敗します）。
あなたの会社がこれを何も提供せず、この無数のランダムな要求に対処して責任を負うことを期待している場合は、真剣に進むことを検討する必要があります。最初のプログラミング作業（ほぼ25年前）で、給与は常に下がっています。私は同じ会社で8年間費やしましたが、給与は少し上昇しました（ただし、常にキャッシャーよりはるかに高額でした！）。退職後2年以内に2倍になり、その後2年後には、当初の10倍以上の家に持ち帰りました（ただし、当時は独立した請負業者でした）。いつものように、拍車を稼ぎ、貿易を学び、船をより暖かい環境にジャンプさせます。
答えは、理解できる言葉で説明してみることです。
- オイル交換のようなものです。彼らは緊急ではありません....しかし、それでも定期的に行う必要があります
- Rustの上にペイントすると、見栄えがよくなります。染み出るまで
- 補強サポートなしで新しいルーフパティオルーフデスクを構築します。しばらくはうまくいくでしょう。その後、それは崩壊し、人々を傷つけ、あなたが責任を負うことになります。
- a/cは素晴らしいです。窓ユニットは、1〜2部屋に最適です。 146のウィンドウユニットエアコンをアパートの建物に設置しようとすると、問題が発生します。
- 5人の子供を教えるのは問題ありません。 10は悪くない。しかし、限界があります。非公式に75人の子供たちに教えてみてください。これが表示されます。
これらが共鳴していない場合。出発-翌日ではなく、書面でオファーを得る日！新しい仕事を終えたら、ゼロ通知を残してください。文字通りその日に来ないだけです。しかし、あなたが何をしたかを知っている同僚が1人か2人いることを確認してください。これは、もし会社が助けられるならば、彼らの無礼と傲慢さが代償を払うことを彼らに示すことによって、実際に会社を助けます。最後の会社で、6か月以内に残った4つの技術者の3人で、仕事に行く必要がありませんでした。それは少なくとも声明を出し、去る人に一度言う機会がありました、「ええ、あなたは毎日言うニースbsあなたはそれでいっぱいです、私はあなたに私の通知に満足を与えることすらしません。
最後に、この問題がNORMであり、アジャイル、tdd、bdd、およびリファクタリングが標準以上になる20年前の標準だったことを知ってください。あなたはすぐに「私はこれを自分でやったので、それはうまくいきました」と答える高齢者と話しているかもしれません。まあ、すべての馬と馬車は150年前はうまく機能していました。技術分野では、20年前の技術は150年前の輸送と同じくらい時代遅れです。彼らがこの罰金を拒否した場合。彼らが留まるまともな現在の技術開発者を決して雇わないことを知ってください。彼らは最悪の最悪の事態に陥り、彼らのビジネスにひどく害を及ぼすでしょう。彼らがテクノロジーに依存していて適応できない場合、それらは失敗し、最終的にはそれがあなたにとって最高の報酬となるでしょう。機能不全の組織が長期間続くことができるので、それはそれがしばらくかかるかもしれないというだけです。
この連鎖を断ち切る唯一の方法は、柔軟性のために設計され、完全なユニット+統合テストが行われた新しいインフラストラクチャを開発することです。
これを経営陣に販売する（他の開発者やマネージャに1：1ミーティングでコンセプトに署名する）と、アプリケーションのコードのほとんどがインフラストラクチャにあり、簡単に状態に到達できます。拡張と保守が可能ですが、実際のアプリケーションは軽量であり、かなり迅速に記述できます。
インフラストラクチャの開発により、最初は既存のアプリケーションの一部を置き換え、しばらくすると（数年かかる場合があります）アプリケーション全体を置き換えることができます。
長期的には、新しいアプリケーションの開発時間と将来の既存のアプリケーションのメンテナンス時間を大幅に削減できます。
新しい開発には、1人以上の開発者のチームによるチームの少なくとも80％（できればそれ以上）の献身が必要になります（2人以上の心は1人より優れています）。すべての開発者は、創造的に考え、既存の先入観を打破できる必要があります。
そのような新しいインフラストラクチャを定義して高レベルの設計を試みてから、その定義を同僚や管理者に提示してください。
あなたの労働条件として、これらの問題に対処する（定義と設計に基づいて）新しいインフラストラクチャチームを率い、必要に応じて支援しながら、新しい開発者に古いものを維持するよう依頼してください（最大10〜20％）。時間）。経営陣がその考えに同意する場合は、条件の再交渉を依頼できます。彼らが拒否した場合は、別の仕事を見つける準備をしてください。 （覚えておいてください、あなたの仕事にはスキル、知識、経験が必要です。彼らはあなたが信じるようにお金を払っているのと同じくらい簡単に置き換えることができません。）
たぶん、あなたはマネージャーのところに行って、次のように言う立場にいるでしょう。
私はA、B、Cで多すぎることをやっています。これを維持することはできません。正直に言って、罪を犯すつもりはないので、これを修正するか、辞任の手紙を残して、この部屋から出ます。これがすべて空中になっているので、これを正しくするためにどのように協力することができますか？」
あなたの経営陣は基本的にあなたを尊重したり仕事の負荷を理解したりしていないようです。
経由するすべての機能リクエストを実装する必要はありません。あなたのマネージャーはあなたと着信要求の間のバッファーとして機能するはずです（おそらく最も単純な中断/修正要求を除く）。次に、彼または彼女はあなたと一緒に座り、承認された要求の実現可能性と優先順位を決定する必要があります。
また、あなたはおそらく彼らがあなたに払っているものを（少なくとも）2倍にする必要があります。
彼らはおそらくあなたと一緒に仕事をするために少なくとももう1人の開発者を本当に必要としているように思えますが、彼らがあなたに支払っているものではそれはかなりありそうに聞こえません。
彼らがあなたに適切に支払うか、あなたの仕事量を管理するのを助けたくないなら、私は新しい仕事を探しています。あなたはteamの一部であり、あなたの経営陣がプロジェクトを完了するためにあなたと協力する場所で働きたいと思っています。できるだけ早く沈没船から降りてください。
一人のチームのヒーローになることはあなたを燃やすだけです。
私は学生（まだ）ですが、それはごく普通のことです（私のインターンシップの経験から）。これは、サポートやWebアプリケーションで作業するときに得られるものです。
コーディングを開始する前に、クライアント（マネージャー）が何を望んでいるかを理解することをお勧めします。彼らは自分でそれを知らないこともあるので、彼らが何かに同意するまで彼らと協力するので、それは難しいかもしれません。コーディングする前に、最終的なソリューションについて両方が同意することを確認してください。
また、メンテナーであれば、コードのほとんどを変更できます-動作を変更したり、バグを引き起こしたりしないことを確認してください。私は、マネージャーがあなたに何かを変更することを「許可」しないことを期待します。なぜなら、彼らは今に慣れていて、現在の状態に満足しており、新しい変更にお金を払いたくないからです。
最後に、何か他のことをしているために何かを処理できない場合でも心配しないでください。あなたが仕事に圧倒されており、彼らの要求には時間がかかることを人々に知らせることをお勧めします。そうしないと、マネージャーはあなたが怠惰だと思うだけです。あなたがすでに仕事をしていて、もっと多くの人を雇うかもしれないと彼らに知らせてください。彼らにとって、その仕事が一人では多すぎることを知る方法は他にありません。
これはプロジェクト管理の問題です。なんらかのプロジェクト管理を使用して、何に取り組むのが最も優先順位が高いかを決定します。
a）作業するには、アイテムのバックログが必要です。コードを改善するための計画をバックログに入れます。
b）すべてのバグがバックログに入る
c）バックログが優先されます。
d）すべてを優先順に実行します。
バグの方が優先度が高い場合がありますが、一度すべてを修正すると、新機能やデザインのリファクタリングに費やすサイクルがあります。
修正する問題/バグがあるセクションを渡すため、リファクタリングの改善を段階的に行うだけの場合が最も簡単です。次に、「Aを修正する必要がありましたが、Bは根本的に壊れていたため、ソリューションCを実行してすべてを修正し、Dが将来的に簡単/安価になるようにする必要があります」A =バグ、B = Theアンチパターン、C =ソリューション、D =将来の利益
仕事をする価値がある投資として正当化できない場合、ビジネスパーソンはそれを決して受け入れません。
これはいつものことです。あなたがそこで働き続けている限り、あなたは搾取されるでしょう。自分がしていることに満足しているのではなく、このモデルを使い続けることが会社の最大の利益になります。それに来るとき、彼らは本当に気にしません。それは彼らのために信頼できるコードを作成することであり、あなたが一人の男のバンドなら、彼らは確かにあなたの銀行を作っています。なぜ変わるのか？
これらすべての良いニュースは、あなたがVIP=彼らが知らない場合でも彼らにです。あなたが船にジャンプする前にいくつかのさらなる機会を並べてそれらをつかむことですボールとより高い給与を要求します。より良い機会に移動しないとしたら、私の意見では、もっとエキサイティングな仕事をすぐに見つけるべきです。できるだけ高く目指してください。デベロッパーショップに着くと、はるかに幸せになりますグーグルや、あなたが本当に幸せに感じる共同開発者文化が存在するいくつかの楽しいスタートアップのようなものです。
私が個人的に行ったのは、ヘッドハンター請負業者の組織を使用することでした。そして、私の請負業者からの着実な雇用を維持しながら、次から次へと移動しながら、多くの素晴らしい経験を身につけました。それはあなたが退屈するのを防ぎ、あなたに挑戦します。やがて、暇なときに小さなビジネスを立ち上げ、実際のビジネスに花を咲かせ、その後契約作業をやめるようになりました。