タグ付けされた質問 「management」

現在、今後のパフォーマンスレビューでジレンマに直面しています。約1年前に会社を始めたとき、プログラミングスキルと知識に対する認識をできる限り正直にしようとしました。優れたプログラマーおよび開発者とみなされるコーディング能力と比較したコーディング能力に基づいて、知覚されるスキルを決定しました。そのため、私が提供された給料は当時満足していたものです。 仕事に就くとき、そしてその中にいる間は正直が重要だと信じているので、問題はありません。また、仕事に就いたら、雇用主に信じるように与えたものよりも上手くいけば、それが私の業績に反映されると信じています。 同時に別の開発者が雇われました。私たちは両方とも、同じプロジェクトで同じタスクセットを実行するために雇われました。数か月前、私はこの人が私よりもかなり賢明であることがわかりました。今、プロジェクトの中で、この人はプログラミングスキルやビジネスの知識においても私よりずっと下にいることに気付きました。プログラミングタスクで何度も彼を助け、彼のコードをレビューし、より良いソリューションを提供し、私たちが取り組んでいるプロジェクトについての概念を説明しなければなりませんでした。私たち二人が同時に始めたとしても。 自分の名前を直接言及せずに、または自分が何をしているのかを知らずに、少なくともこの人に匹敵するように（レビュー中に）給与を引き上げるにはどうすればよいですか。私がやった仕事に基づいてそれを正当化する場合、彼らが私に比較パッケージを提供しない場合はどうなりますか？もっと欲しいのか、それとも貪欲なのか？

33 management 

タイムシートは私が決して好きではなかったものですが、それでも私の会社の要件であるものです。彼らはあまり私を気にしませんが、彼らは本当に他の人々のギアを本当に磨くようです。いくつか質問がありますが、フィードバックは素晴らしいと思います。 あなたが請負業者ではないと仮定して、タイムシートを作成する必要がありますか？（それは私には理解できます）。 使い慣れている、または使用しているタイムシートの粒度はどのくらいですか？（例：すべてのエントリは2時間未満でなければなりません）。 タイムシートは、仕事を受け入れなかったり、現在の仕事を辞めたりする理由を考慮しますか？ クライアントへの請求を行わない場合、組織内の管理はどのようにタイムシートを正当化しましたか？

32 management 

私は3〜4人のジュニア開発者のチームを率いています。私の仕事は、コードを書くことに加えて、後輩に監督と指導を提供することです。 しかし、私は開発者が自分の仕事で自律性をどれほど大切にしているのかを完全に理解しており、自分の考えやアルゴリズムをスプーンで提供することによって彼らの本質的な動機を破壊したくありません。私は彼らに彼ら自身の方法で問題を探求し、彼ら自身でそれについて考え、彼らが本当に乗り越えられない問題に直面しているときだけ私に来てほしい。 彼らが私に来たとき、時にはアルゴリズムが十分に堅牢ではないため、問題を解決するために完全に異なるアルゴリズムを提案する必要があります（私はシニアであり、私は彼らよりも多くを見てきました）。もちろん、私は彼らの感情を傷つけないようにこれを素敵な方法で説明し、私の解決策が彼らのものよりもはるかに優れていることを優しく概説します。 それでも、彼らは私の提案を受け入れたがらない場合があります。その理由の1つは、独自のアルゴリズムに多大な投資をしているからです。どこにも行きません。しかし、私の心の奥深くでは、私のアルゴリズムが彼らのアルゴリズムよりもはるかに優れていることをよく知っているので、採用するだけです。 彼らが私の提案を採用しなかった場合、どうすればよいですか？彼らに自分の道をたどるように頼むべきなのか、それとも彼らに何度も頭を壁に叩きつけて、彼らが私に戻ってくるのを待つべきなのか？前者を実行すると独裁者になりますが、後者を実行すると貴重な開発時間がかかり、バグ修正コストが発生します。私は本当にここでジレンマに陥っています。

30 management  teamwork  team-leader 

多くの企業と同様に、私が働いている会社は、SMARTの目標に基づいたパフォーマンスレビューシステムに移行しています。私のチームは、Extreme Programmingのプラクティスを採用した高機能でアジャイルな開発チームです。私たちの大きな利益のために、私たちのアジャイルプラクティスの採用は、直属の管理職の完全なサポートを持っています。 作業を完了するために、私たちのチームは3週間の反復を利用します。即時の反復を超えて、四半期ごとに一般的な計画を立てています。これから数四半期で達成したことは、当四半期で達成することよりもはるかに厄介であることを意味します。私たちのプロジェクトがどこに向かっているのかは確かに一般的な考えを持っていますが、ここでのキーワードは一般的です。 私自身を含む私のチームのプロジェクト計画メンバーへのアプローチを考えると、具体的、測定可能、達成可能、関連性、および時間制限（SMART）の目標を書くことは難しいと感じています。 SoftwareEngineering.seに関する2つの既存の質問は、私たちの懸念のいくつかに対処するのに適しています。 プログラマーにとって良いSMART目標の例は何ですか？ SMARTの目標はプログラマにとって有用ですか？ ただし、アジャイル開発チームで作業する場合、質問はSMART目標を処理するための詳細よりも一般的な回答を引き出しました。アジャイル開発者として、具体的、測定可能、達成可能、関連性があり、時間制限のある5〜7年間の目標をどのように記述しますか？

29 agile  management  planning  review 

開発にうんざりしていて、心がそれ以上役に立たないときは（自宅で）、単に面白いことをするだけで、問題解決能力が高く、心が自由になります。しかし、開発者の生産性と効率を向上させるための手法としてこの手法をマネージャーに勧めたとき、彼は仕事が娯楽の場ではないという理由で受け入れることを拒否しました。私はこの式が私のために働くと思う。他の開発者にも当てはまります： 2 hours of productive work + 30 minutes of entertainment > 3 hours of dull work なぜ企業はそれを信じないのですか？ 更新：これがトピック外としてクローズされた理由がわかりません。これが関連していると思われる場合は、再度投票してください。

28 productivity  management  efficiency 

「許可を求めるよりも許しを請う方が簡単だ」という言葉はプログラマーの間ではかなり人気があり、IIRCはGrace Hopperによるものでした。これは通常どのような状況で当てはまりますか？また、そのような直観に反する命題が成立すると信じるのはなぜですか？

27 management 

これは私たちのほとんどに起こりました... あなたはいつか仕事に来ます。すべてが正常なようです-太陽は輝いており、鳥はさえずりますが、あなたは仕事中にいくつかの奇妙なことに気づき、それがマトリックスのデジャヴ猫を思い出させます。 あなたがオフィスに入ると、たくさんの電話が鳴っています-しかし、それは彼らが新しい販売促進をしているということだけかもしれません。暗い雲があなたの上に浮かんでいることに気づいたら、あなたは落ち着きます。 少し時間がかかりますが、クラウドがあなたの上司であることを認識しています。通常、彼は毎朝「Soooo Peeeeter、これらのTCP / IPレポートはどうですか？」であなたをチェックします。しかし、今日、彼は一般的なマナーについてすべてを忘れて、あなたの個人的なスペースに無作法に侵入しました。「おはよう」はなく、ただいくつかのよだれ、うなり声と呪い。彼は、サイバーボールの虎、恐怖、パニックからすべて逃げようとしているネアンデルタール人のことを思い出させます。昨日から彼が作成した新しい言語を解読しようとすると、何か悪いことが夜通し起こったことを理解し始めます-本番システムがダウンしました。 現在、システムは通常、クライアントによって9時から5時までの通常の営業時間に使用されますが、何らかの理由でブザーでアラートを受信しませんでした（30歳未満の場合-ブザーは鳴るだけの携帯電話のようでした）誰があなたにビープ音を鳴らしたか教えてください）。次回充電することを忘れないでください。 そのため、現在は午前8時45分であり、システムは午前9時でなければなりません。10秒ごとに、上司はさらに別の呪いを解き放ち、別の顧客がシステムに入るのに問題があることを伝えます。また、数人のアカウントマネージャーが上司にカーソルを合わせて、クライアントが本当に本当に苦しんでいるのかを理解させようとしています。 誰もがシステムをできるだけ早く起動することをあなたに依存していると同時に、常にあなたの注意をそらすことによってあなたの進歩を妨げています。 このような状況でどのようにクールに保ちますか？

26 management  production 

新鮮なチームリーダーのために、どの管理書を読むことをお勧めしますか？

26 management  team-leader 

私は、技術的なことや技術的な決定について、非常に非技術的なマネージャーに説明しなければならないことがよくあります。プログラミングに情熱を持っていない世界の他の人たちにとって、本質的な物の言えないことを減らす良い方法は何ですか？ 質問の例： Javaの代わりにDjangoを使用しているのはなぜですか（どちらも安いことを受け入れませんでした） 専門用語ではない言葉で言い換えることを求められたとき、私の文は「特定のHTMLタグは許可されていません」でした。どうすればそれを馬鹿にすることができますか？ 私にとって完全に理にかなっているが、それは非常に基本的であるため、それを説明する方法がわからないその他のもの なぜこれ、なぜそれ、なぜすべて！ また、「パイロンとは」など、Googleで基本的なものを調べるようにマネージャーに指示するにはどうすればよいですか。

26 management 

この質問は、Software Engineering Stack Exchangeで回答できるため、Software Quality Assurance＆Testing Stack Exchangeから移行されました。 昨年移行し ました。 プルリクエストの変更を確認すると、「TODO」のメモが付いたコメントに出くわすことがあります。 問題を解決するために使用されるソリューションは改善できますが、かなりの時間投資が必要になります。作成者はより迅速なソリューションを選択しましたが、より良いオプションが潜在的に利用可能であるというコメントを入れました すぐに修正する必要がある既存のバグを回避するための一時的なコードがあります TODOsが一般的にコードベースの存続期間中コードベースに留まることを知っているので、プルリクエストでそれらにどのように対応する必要がありますか？どうすればそれを避けるよう丁寧に要求できますか、またはそれが本当に正当化された場合、PRの作者が将来それをフォローアップすることをどのように確認できますか？

24 code-quality  teamwork  code-reviews  management  pull-requests 

私はアジャイルマニフェスト原則を読んでいました。1点を除いて、すべてが明確で合理的なようです。 シンプルさ-完了していない作業量を最大化する技術-は不可欠です。 これはわかりません。これは、行われなかった作業が何らかの形で誇張されるべきであることを意味しますか？もしそうなら、それは本当に意味をなさない。

24 agile  management 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 7年前に閉鎖されました。 毎週、マネージャーと30分間のミーティングをスケジュールして、ほとんど何でも話します。これまでのところ、私はそれらの一対一をあまり真剣に受け止めていません。新年の決議として、私はマネージャーと一対一で真剣に考えたいと思います。できる方法の1つは、事前に計画（質問のリストや議題を作成）することです（1対1）。 ステータスレポートを除き、1対1で上司と話し合うテーマは何ですか？一対一のアジェンダを見たことがありますか？

24 management 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私はスコット・ハンセルマンとロブ・コネリーのポッドキャスト「この開発者の生活」を聞いてきました。 最新のエピソードでは、人格特性について説明します。 1.0.4-平均であること。 業界で人々が意味することは何ですか？アグレッシブはどうですか？自信がある？違いは何ですか？むしろ、上司や禅師のためのドリル軍曹を持っていますか？サイラ・リチャードソンとジャイルズ・バウケットと話をします。 あなたが働いてきた最高のマネージャーに共通する特徴は何ですか？ 編集：明確にするために、いくつかの近い投票があったので、私は開発者のマネージャーに共通の特性があるかどうかに興味がありますが、必ずしも他の職業のマネージャーが必要とする特性ではありません。 これがプログラミング関連かどうかについては、プログラミングについてではないサイトでこの質問をしたくありません。率直に言って、私は生でスープの缶を作る人に興味がありません。開発者がマネージャーから何を望んでいるかに興味があるので、マネージャーから欲しい。

24 management 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私は約3か月前にプロジェクトに参加しましたが、それまで遅れていたため、新しく雇われた1人の開発者によって開発されていました。公平を期すと、このプロジェクトは、微妙な点が多く、比較的複雑な医療機器へのインターフェイスであるため、会社で経験のない人物を1人プロジェクトに配置することは、経営者の観点からはおそらく悪い決断でした。 とにかく、いったん作業を開始すると、...うまくいきませんでした。UIは素晴らしく見えましたが、実際には何もしませんでした。繰り返しになりますが、これは多くの場合、この開発者がデバイスへのインターフェイスを作成する準備が適切に行われていないためです。しかし、適切なコードが壊れやすく、保守が非常に難しいこともすぐにわかりました。 今、私は世界で最高のプログラマーであると主張していません。私は、私よりも優れた開発者である非常に頭の良い人たちと仕事をしています。しかし、できる限りシンプルで堅牢なコードを書くことは非常に難しいです。チェックインをテストします。コードが乱雑になり、作業が難しくなっていることがわかった場合は、変更します。私は同僚がより良いコードを書くのを手伝うために、同僚と何度か話をしました。a）彼は20年以上の分野での経験があり、私は5歳しかいません。b）彼はいわゆる「UXエキスパート」として雇われ、他の人は彼を経験豊富な個人と見なしています。 とは言っても、私はそれを見ないだけです。彼はとてもいい人であり、理にかなっていますが、壊れやすいコードを何度もチェックインし、最も楽観的なケースでのみ動作し、10回のうち9回は彼の作品のバグを修正します。彼のコードはアマチュアっぽいようで、明らかに、彼が雇われたときに持っていたと主張するレベルの経験を持っていません。彼のコードのリファクタリングとバグの修正に費やした余分な時間が私に負担をかけたというところまで来ました。私がそれを見る方法には、2つのオプションがあります： 何もせず、この製品が時間通りに出て、堅牢であり、将来的に彼が失敗するのを待つために、お尻をつぶしてください（最初のリリースの後、このプロジェクトで彼と一緒に仕事をするつもりはありません） 上司に彼のパフォーマンスについて話してください。私の上司は理にかなった人ですが、このアプローチをとるのは気まずいです。私は同僚を「バッシング」するのが好きではありません（より良い用語がないため）同僚と私は彼がそれを取る方法を知りません。 だから、それはそれについてです。彼の実装が機能しない理由や、コードをより保守しやすくする方法を説明することで、同僚とこれを解決しようとしましたが、彼は同じ間違いを犯し続けています。他の人が同じような状況をどのように扱っているのか、特に現在管理職の人たちがどのように扱っているかを聞くことに非常に興味があります。アドバイスをありがとうございます。

24 code-quality  teamwork  management 

ベンダーのロックインを回避するための一連の業界承認のルールはありますか？ つまり、マネージャーや他の意思決定者に見せることができ、理解しやすく、検証しやすいものです。 客観的で測定可能な方法でベンダーのロックインを検出および防止するのに役立つ、広く受け入れられているルールのセット、チェックリストまたは条件のセットはありますか？ プロジェクトの初期段階でベンダーがロックインするリスクについてマネージャーに警告しましたか？

23 management  decisions  risk