この管理動作のリストは、実際にはソフトウェア開発者にとって魅力的ですか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 3年前休業。 私はこの管理行動のリストに出くわしました(http://suven.posterous.com/dos-and-donts-leading-software-development-te)。 いくつかの宝石があると思いますが、それらのいくつかは100%ではありません。斜体と私の名前でそれらをマークしました。 ソフトウェア開発者として、これらは魅力的だと思いますか?あなたの経営陣からのあなたのトップの「お奨め」アイテムはどれですか? しない 人を追加してチームを垂直方向に拡張しないでください 10人を超えるチームを作成しないでください 人のリソースを呼び出さないでください、それはクールではなく、本当に不快です チームのメンバーが交換可能であると思い込まないでください 弱点を強調するときにチームを互いに比較しないでください チームを互いに対戦させないでください 偽の締め切りを作らないでください チーム間でツールとプロセスの標準化を強制しないでください(これは、状況によっては議論の余地があると思います-Todd) ソフトウェア開発の手掛かりがない製品マネージャーを雇わないでください KPIを排他的に使用してチームを推進しないでください(効果がないだけでなく、開発者はKPIメトリックを推進する方法を見つけます-「コード行が必要ですか?コード行を持っています!」-トッド) チームに時間外労働を強要しないでください。要求は緊張を生み出すものです。 人々の2倍が半分の時間に等しいと仮定しないでください 行う 約5〜8人のチームを作成して、水平方向にスケーリングします。 製品とチームのビジョンを持っていますか チームごとに違いがあるため、プロジェクトを適切に割り当ててください。 チームをやる気にしてください(うわー、これは滑りやすく、定義が難しいものです。私はその意見に同意しますが、それはガイドラインなしで「効果的である」と言っているようなものです。-トッド) チーム間の移動を許可する 製品のビジョン、戦略、テクノロジー、プロセスについて話し合うセッションを持っている チーム/製品名を決定するときにチームを関与させる チームが専門知識を持つチームである場合は特に、チームが独自に決定できるようにする チームがどのように、または何に取り組むかに影響を与える決定にチームを関与させる チームとプロジェクトに合った開発方法論を奨励する すべての個人の自己啓発計画に注意を払う