目前，我相当大一部分工作的时间花在了管理上，但却成效一般，我觉得我并没有把管理工作做好。但是，为什么要做好管理工作呢？我的看法是这样的：
- 精力有限：人的精力是有限的，你不可能把所有事情都揽在自己身上，这样你很难走得很远，很难做成所谓“大事”；
- 时间有限：管理工作的目的是把团队打造成一个稳定运行且能自适应、自调整的系统，这时候你就大大节省了自己的时间，有了更高的自由度（这时候你可以做一些更有价值的事情）；
- 业务需要：假设因为管理的问题导致项目无法正常推进，那么管理必须变革，亦即“好的”管理工作应能使事情推进得更好；
- 有趣：这本身就不是一件容易的事情，不容易才有趣不是吗？
那么，我为什么会觉得自己没做好管理工作，我遇到了哪些问题呢？其次，我又该如何解决这些问题呢？
我遇到了什么问题
问题的背景是，这两个多月以来，我们整个团队（本团队4人，借调2人，共6人）都忙于一个项目的上线。从结果上来看，我们比承诺交付时间滞后了半个月，而且交付当天还有一部分功能没有完成。首先，我必须承认工作量是巨大的，但是怎么都不应该出现如此长时间的滞后，甚至是部分功能没完成（原计划的工作大概还需要5个工作日才全部完成）。也就是说，原本按我的评估，团队的战斗力绝对是可以拿下这个项目的，那为什么没有做到呢？我认为是我的管理上出了问题，而不是某个员工偷懒误事，或者说我的领导中断我临门又插了一脚其他事情进来。
那么，我的管理到底出了什么问题？
- 员工并不知道自己一个整体的计划：在整个项目行进过程中，其实已经有一两次员工问我接下来该做什么了，我没有予以足够的重视，总是给了他一个周的工作计划就把他打发了。而且我给的周工作计划是非常具体的事务，站在员工的角度，只是把事情做完就行了，很多信息他都不知道。那么问题来了？假如我是一个员工，我就会想：我这部分工作对整体有什么影响？我是慢慢做呢还是得加班加点做呢？假如我这部分工作滞后，应该也没问题的吧？我下星期又该干嘛呢？下下个星期呢？结果是怎么样呢？确实，有那么一段时间，员工确实工作得比较散，虽然我后面及时的提出了我们整体进度滞后，整体的节奏加快了，但还是按照周工作计划的方式来推进事情，并没有提及整体。结果呢？竟然有一些非常重要的事情，假如我不提醒，员工可能会忘记（例如一个重要的服务承诺：运行日报的自动生成），我当时想，不是吧你竟然不知道这是服务承诺的一部分？但转念想，我真的有交待清楚吗？员工并不清楚自己做的一件具体事情对于整体而言是什么价值，或者说，他从来就没有清晰的知道，自己接下来这一个多月项目上线期的工作目标是什么，应该做到什么程度。假如员工对自己的工作目标不清晰，其自我控制就无从谈起了，因此他会在最该咬紧牙关的时候放松（因为他没有意识到），然后在临近交付时忙得焦头烂额。总结一句：我没有充分的调度员工。
- 员工的成果缺乏质量把关：管理学中有个概念叫PDCA环，P即Plan计划，D是Do做事情，C是Check检查，A是Action调整（根据检查的结果）。其实我上一条说的问题可以归结为Plan上的问题，那么这一条要说的就是Check和Action的问题了——我把很多Check和Action都放到了最后，而没有及时的去检查和修正。这非常要命，因为这些问题在悄悄吞食项目的剩余时间（我自认为给予的时间是包含了Check和Action的，而员工认为只是包含Do）；
- 我没有一开始就做进度跟踪：一开始，我只是“觉得”能完成，一个星期才做一次进度跟踪，因此并没有准确的感知进度。等到时间节点临近（临近交付的后面两三个星期），才被逼着去做以日为频度的进度跟踪。
- 工作量估计错误以及没有合理利用资源：原本临时借调了运维团队的同事帮着做一些事情的，但中间时候他们临时又被指派去做其他事情了。好了，我这边原定由他们负责的工作就暂时落下了，我甚至还答应帮忙把原先指派给他们的事情接过来，问题就出在这里。且不说承接过来的工作量大不大，我的团队由于我没有调度好，已经是工作滞后的了，事实上，我反而需要运维的同事反过来帮我才对，因为后面一段时间我发现我的团队的人都需要加班到很晚，而运维的同事却相对而言比较轻松。一方面我没有对团队的工作量负责（已经滞后还增添新的），另一方面我没有请求支援（当然，我存有一些私心，想通过这么一件共同作战的事情来提升团队的凝聚力。现在想来却是荒谬，凝聚力是靠大家共同辛苦加班来提升的吗？）。
我该如何解决这些问题
- 针对上面的第一个问题，我必须让每个员工清晰的知道：他近期、中期、长期的工作目标是什么，以及我们为什么要做这些事情。这也意味着，我必须对所负责的项目的未来（软件部分）有明晰的规划（包含一些必要的明确的流程），否则员工的工作目标无从谈起，目前看来，我这方面是欠缺的。
- 针对上面的第二个问题，必须把质量检查纳入过程中，在过程中及时的发现问题，而不是集中堆积到项目的末期。这一点可以引入一些工具辅助，如引入一些代码的质量检查工具、交付代码的测试用例等等，但更重要的是要形成规范。
- 针对上面的第三个问题，进度必须在过程中跟踪，且需要精准的度量，而不是“觉得”应该是这么多，显然甘特图能比较好的解决我这个问题，及时的发现过程中的问题并做出调整。
- 针对上面的第四个问题，我必须拿进度数据说话，而不是“觉得”能行就把任务接了过来，这是对自己团队的负责，也是对总体进度的负责。另外，需要借调同事就尽早提出而不是死顶，现在想想简直太愚蠢了。
反思下来，其实以上问题影射了我一直以来存在的几个问题：
- 不善于规划；
- 逃避一些繁琐的事情，但最终还是得面对，既然是迟早得面对的那应该一开始就想清楚该如何应对（比如工作中的结果检查，比如交待清楚工作背景）；
- 不是特别理性，总把一些事情想当然了，实际上根本不是那样的。保持理性是多么的重要啊！
还有，更要命的是，可能有些问题我自己目前都未必意识得到，发现多少改多少吧。另外，其实我应该立即去找一本软件管理的书来看，我相信自己能做得越来越好的:-)
网友评论