#项目管理# 多授权少微管理

多授权少微管理

---

steven sinofsky 说了五条：

• Delegate the problem, don't solve it.

  Manager在告诉你项目出现问题的时候，同时也把解决方法告诉你，意思就是让你按照他的方法做。这样的模式一来抑制创新，二来如果你的实现办法和manager的想法有出入，他会觉得你就是没做好。所以我们建议，条条大路通罗马，经理不必拘泥团队成员用什么方法完成任务。

  另外这个模式对员工培养技能也没啥好处。

• Share experiences, don't instruch

  员工遇到的问题，manager很可能也已经遇到过了。和第一条一样，授之以鱼不如授之以渔（中国古人叼炸天！）。方式一：告诉员工你当时在github找到一个开源项目，然后查阅CLR via C# 把这个问题解决了。方式二：直接告诉员工通过Nuget下载一个模版就能把问题解决。

  我个人还是倾向于方向一。

  当然啦，如果时间紧，任务重就另当别论了。

• Listen to progress, don't review it

  简单来说，就是让员工来自动反馈进度，不用自己去问去追。一方面提高团队成员对项目的积极性，另外就是自己负担也少。

  这点有个前提和关键点，就是要如何实现。暂时想到的是利用类似于Team toy这样的协作工具，或者Dashboard，kanban。如果是让员工每天或者隔天写邮件汇报，也是一件相当蛋疼的事情。

• Provide feedback, don't course correct

  出问题了，manager不能只能对下面的人来一句“你去把他搞好”，然后就撒手不管。这个时候相互沟通，给团队成员需要的协助很重要。

• Communicate serendipitously, don't impede progress

  这点的意思是：项目成员之间沟通可以不那么正式，不一定要用开会这么“重型”的方式。Facebook COO说了，和她开会不要做PPT，那是浪费时间。私底下聊聊，每天看看进度版或者kanban，多邮件同步就可以了。

  之前项目经理就老说：“项目最大的问题就是沟通！”。我想：就等着每周一两次项目成员集体会议想项目，项目成员之间的沟通会好吗？

最后总结一下，如何避免微管理：steven sinofsky说了一个观点，manager要将心比心，己所不欲勿施于人。

另外，博文也做了一个调查，有一点结果挺有趣的。

有一半人不知道最近一次会议算不算成功。

的确，谁知道会议算不算成功呢，也没个标准是不是，也不知道会议对接下来项目的进展又没帮助是不是~

原文：Delegating or micromanaging, threading the needle