この管理動作のリストは、実際にはソフトウェア開発者にとって魅力的ですか？[閉まっている]

私はこの管理行動のリストに出くわしました（http://suven.posterous.com/dos-and-donts-leading-software-development-te）。

いくつかの宝石があると思いますが、それらのいくつかは100％ではありません。斜体と私の名前でそれらをマークしました。

ソフトウェア開発者として、これらは魅力的だと思いますか？あなたの経営陣からのあなたのトップの「お奨め」アイテムはどれですか？

しない

• 人を追加してチームを垂直方向に拡張しないでください

• 10人を超えるチームを作成しないでください

• 人のリソースを呼び出さないでください、それはクールではなく、本当に不快です

• チームのメンバーが交換可能であると思い込まないでください

• 弱点を強調するときにチームを互いに比較しないでください

• チームを互いに対戦させないでください

• 偽の締め切りを作らないでください

• チーム間でツールとプロセスの標準化を強制しないでください（これは、状況によっては議論の余地があると思います-Todd）

• ソフトウェア開発の手掛かりがない製品マネージャーを雇わないでください

• KPIを排他的に使用してチームを推進しないでください（効果がないだけでなく、開発者はKPIメトリックを推進する方法を見つけます-「コード行が必要ですか？コード行を持っています！」-トッド）

• チームに時間外労働を強要しないでください。要求は緊張を生み出すものです。

• 人々の2倍が半分の時間に等しいと仮定しないでください

行う

• 約5〜8人のチームを作成して、水平方向にスケーリングします。

• 製品とチームのビジョンを持っていますか

• チームごとに違いがあるため、プロジェクトを適切に割り当ててください。

• チームをやる気にしてください（うわー、これは滑りやすく、定義が難しいものです。私はその意見に同意しますが、それはガイドラインなしで「効果的である」と言っているようなものです。-トッド）

• チーム間の移動を許可する

• 製品のビジョン、戦略、テクノロジー、プロセスについて話し合うセッションを持っている

• チーム/製品名を決定するときにチームを関与させる

• チームが専門知識を持つチームである場合は特に、チームが独自に決定できるようにする

• チームがどのように、または何に取り組むかに影響を与える決定にチームを関与させる

• チームとプロジェクトに合った開発方法論を奨励する

• すべての個人の自己啓発計画に注意を払う

私の推測では、このリストは実際にはソフトウェア開発者にとって魅力的です。なぜなら、彼らの自己イメージは、釘のような問題解決者（ウィンストンウルフ）ではなく甘やかされた創造的な歌姫として検証され、結果として専門的に扱われることを期待しているからです。

また、建築家、弁護士、医療専門家などのように、私たちの取引が認定できるレベルまでソフトウェア開発技術を改善した場合、ソフトウェア開発者の管理方法をより適切に指示できるようになると思います。