【编者按】本文系“波波侃项目”系列文章的第二篇，旨在结合自己成为项目负责人一年多来的所见所想所感，对自己一年来的工作有一个简要的总结，也把其中的快乐或是不快乐与大家分享，新人新思想，说的不尽之处，还望各位看官不吝赐教。
初次成为项目经理啥感觉？对于久经沙场的大虾们似乎早已淡忘，然而对于我这种刚刚带了一个项目的小菜来说却还记忆犹新。那是一个没有下雨的下午，在弥勒，没有什么仪式（呵呵，一般也不会有什么仪式），没有太多的嘱托，只有部门经理的一句“人力资源系统交给你来接手了。”先是兴奋，终于要独立承担一个项目了，一个“我的”项目，从小就受孔老夫子“出而仕之”思想影响的对于自己的虚荣心毫无任何的掩饰能力，接受任务时尽然不经意的得意起来。兴奋之余，内心深处也掠过一丝丝的彷徨。
年轻人做事向来不拖沓，翻过年来，马上就开始了项目的规划，也许是项目催的太紧，也许是邀功的虚荣心在驱使，概要设计尽然只做了3天就想匆忙进入实现，好在经理明察秋毫，铁面无私，没有容许我这种草率设计的举动，几次返工，才勉强完成了概要设计的任务。我文档写的不错，这点我从不否认（至少从格式上是，不怕拍砖，呵呵），但是似乎所有的开发人员都更倾向于及早用代码来表达自己的思想，我当然也不例外。简单构思之后便匆匆开始了编码。边写边想，肯定难免出错。记得有时为了赶项目，写完了才发现设计不对，又重新再来，几次反复，总算看着搞定，抬表一看，尽已是凌晨4点，睡两个小时，继续上班，清醒起来在看昨天写好的代码，居然又错了。
痛定思痛，好好反省，明白了第一个道理：项目经理，要冷静。
稍微调整好了自己，却马上要到了项目这个阶段的deadline,加班加点接着做，总算看着该要的东西都有了，满心欢喜的拿着程序给用户进行演示，得到的答复却是“我们想要的不是这样的”。虽然以前对于需求变更也有准备，但大的变更对于内心来说还是显得有点难以接受。重新调研，重新开发，一头扎进了如何实现用户提供的报表中，结果原定5月结束的第一阶段，一次就拖到了9月，直到老大问起项目进度以及项目滞后的原因时，说起一些报表原本对于计算机来说不必要时，才陡然发现，只是一味的接受用户的需求，却好久没有和用户坐下来面对面的交谈了。
经过此事，明白了第二个道理：项目经理，要沟通。
薪资系统基本稳定后，总算勉强进入了人力资源系统开发的第二阶段——绩效考核阶段，吸取第一阶段的失败经验，确定了项目组内部的“设计要稳，编码要准”的原则，花了长达1个月的时间来进行业务学习和业务设计。满心欢喜的提交了需求评审，结果却被活生生的批了回来，对象不明，目的不清，没有站在用户的角度来考虑需求。在多次思考和斟酌后，第二次评审才勉强通过。
评审过后，拿出自己的项目经理手记，端端正正的写上了几个大字：项目经理，要思考，而且，要比别人思考的多一点。
笔锋一转，已到了今年的3月，绩效考核的模块已开发完毕，测试完毕，功能评审完毕，带着自己的得意之作再一次满怀信心的来到了红河，见到了客户的领导，正打算“炫耀”一下我们绩效考核的灵活性，可配置性，还没开口，就被否掉了，原来他们要的绩效考核远不是我们那么复杂的，而为何当初给我们的需求却是360度考核，立体考核呢？客户方信息中心主任的一句话道破了玄机：“绩效考核，本来就属于一个大家都还在讨论的话题，每个人心中也许都会有一套绩效考核的实施方案，当还没有确定的业务流程进行支持时，你们应该按照合同优先开发其他模块。”我不知道当初公司出于什么考虑而将绩效考核模块优先到了第二阶段，然而当初没有去询问和协商开发计划的确是作为项目经理的我的一个失误。
由此也得到了第四个道理：项目经理，要协调。
马上要进入人力资源系统的第三阶段，一些功能，培训，考试，招聘，学习等，对于开发来说，可以做大，可以做小，开发代价都会有所不同，尤其是原先的搭档调入卷烟组后，新进人员的不熟悉也会直接影响项目的进度。做哪些，不做哪些，重点做哪些，弱化哪些，都是项目经理需要一直关注和考虑的。记得吴成军开玩笑说自己是个“Perfect Man”,对于技术也许可行，然而对于我，一个项目经理，确是万万不可“Perfect”路线的。
第五个道理：项目经理，要权衡代价。
心得分享了那么多，我们再回到理论上来，什么是项目经理？先来回顾一下第一篇《项目，原来如此简单》中的项目定义：“项目是既定的资源和要求的约束下，为实现某种目的而相互联系的一次性工作任务。”那么项目经理就是合理安排“既定资源”，明白项目的约束，有目的针对性的满足任务要求的人，针对这个定位，个人觉得，明白我所悟到的“五项原则”，并加以发扬光大，足矣。
定位好了，那么项目中要有些什么样的细节需要管理呢？请看波波侃项目第三篇《一寸光阴一寸金——项目管理之时间管理》。
