叽歪一下：技术部 6.14 至 6.20管理小结

管理多个人，果然不像管理好自己一个人那么容易。第一个只是用于试手的游戏频道项目就出现了一些意想不到的事情。

引起大家的重视是第一步

虽然上周已经和项目参与者沟通过，本周我们会开始g项目。但是周一看到相关参与者的“本周工作计划”都没有g项目相关内容的出现。当时，我有些沮丧。如果一个项目的开始就没有引起参与者的重视，那么这个项目的进行可想而知了。因此项目开始的第一件事情，就是我要想办法让他们重视起这个项目来。我采取的方式是：开一个项目启动会，有所的参与者，坐下来，我们郑重的申明一下：g项目启动了。并简要的说一下，这个项目的必要性和重要性，以及项目的优先级。这样，大家在项目开始的时候就能对项目有一个较为统一的认知。效果不错，每个人不仅了解了项目的情况，而且，还给出了每个人的项目时间安排。

“越快越好”、“紧急”和工作优先级

说到项目的优先级。技术部这边好像有点问题。就是很多人对自己手头上的工作，不知道哪个最重要，哪个次之，不知道手头的项目的优先级顺序。结果就导致很多人根据自己的喜好来安排工作的优先级。喜欢的就先做，不喜欢的就后做。当然，这也不能怪技术部人员。因为每个工作在告知他的时候，都是“越快越好，这个很重要”，提交的bug全部都是“紧急”类型。如果全部都是“越快越好”，bug全都是“紧急”。那就没有“越快越好”、“紧急”了。我也再思考这个问题，如何客观的告知技术人员一个项目的紧急程度。如何让他们合理的安排工作的优先级。我一般的做法是：自己先定一个deadline，在这个deadline之前必须完成此项目。但是考虑到一些风险因素，我会将deadline提前1/4到1/5时间后告知项目参与者。例如一个专题必须在4天后上线，那么我会告诉参与者3天后要上线。一般情况下，3天后虽然能勉强上线，但是一定会有很多bug和问题要修正。于是还有一天时间可以弥补。
当然，有时候能定下一个deadline还是有些困难的。特别是商务部提过来的任务，一般都是“越快越好”。因为我也不知道所有的“越快越好”哪个应该更快些，所以，有时候，我要对项目参与者手头的其他项目有所了解。甚至有时候，要去了解这些项目的具体情况，从而帮助参与者确定手头所有项目的优先级。
g项目启动会，项目的一个参与者告诉了我，他现在手头对调查通的修改，优先级很高，本周没有时间进入g项目中。我觉得这也很正常。客观的评估负责的各个项目的优先级应该是技术部助理的责任。不能像以前以前那样，自己负责的项目，就把优先级提到最高，然后也要求配合者也把自己负责的项目的优先级提到最高。即使它不一定是个很重要的项目。
考虑到他手头的d项目的工作优先级更高，所以对g项目做出了更为合理的调整。

统筹运算和工作安排

和技术部其他人一样，我手头的工作也不是只有g项目这一个。其他很多项目项目、工作也在同时进行。如何更合理的安排和推进各个项目、工作的进行，的确需要很多技巧和实战经验。以前，我自己工作的时候，安排起来比较简单。就是根据优先级一件接着一件往下做就好了。但是现在很难这样做了，因为很多工作，并不是我自己在做，而是需要他人的配合。所以，不能仅仅考虑自己的时间安排，还需要考虑别人的时间安排和整体的时间安排。
对于这个问题，我的做法很简单：先把需要别人配合的工作，安排下去，然后再做自己需要做的工作。这样自己和别人的两条线都在走。对于项目就是“多线程”了。从而提高项目的整体效率。
以前在日企的时候，我们部长说过一句话：“工作就怕等”。你等我完成，我等你完成，等到最后整个项目就完成不了了。所以，如何合理安排每个线程，使之不要出现或者少出现你个线程等另一个线程的情况。对于一个项目的按时完成有重要影响。
对于如何合理的安排线程和时间，当手头的项目多起来的时候，我仍然有很多安排的不合理的地方，但是，我想这个随着实战经验的提示，应该会做的越来越好。