今天主要是想分享一下我当初在小公司第一次担任项目负责人的经历，在小公司是没有产品部门也没有专门的项目管理团队，一般都是由核心编程人员以及技术负责人来负责起项目管理，我因为在之前为公司研究出来一个核心的项目帮公司将竞争对手产品的实现方式研究透彻并破解了对方的产品，所以新的项目便由我来负责，但那时的我也仅仅工作一年半没有任何项目管理经验以及知识，噩梦便从此开始。
被指定为项目负责人：
由于公司逐步发展，项目越来越多，研发团队负责人欠缺，由于我的表现在团队中比较突出，于是仿佛理所应当的被指定为一个项目的负责人，一开始我以不懂项目管理为由拒绝领导的要求，但是无效，小公司都是推着你上承担起责任，所以只能硬着头皮上了，这里有个前提，我们是小公司，所以我们项目小组每个人都身兼多个项目。
项目工作量的预估：
当时在做工作量预估的时候参考了像《程序员的职业素养》、《网易一千零一夜》等书上描述的工作量预估方法，将模块细分并采用理想人日来估算，当时算完的时候还觉得估算挺合理的。但是结果不如预期，大大超出了项目的预期完成时间。我并没有考虑到项目的缓冲时间，如需求改动以及其他优先级更高项目任务开发导致的时间延迟等，在项目管理中时间的把控是主要的风险把控因素之一，可我却在预估上犯了一个严重的错误，这时关于敏捷软件开发的知识也很薄弱。
缺乏沟通导致的项目失控：
在确认迭代的工作内容后我们开始了二十天的第一次迭代开发，在这期间我们很少沟通除了有依赖的部分确认下，在我完成工作内容时发现另一模块的开发停止了，他们被指派去做其它优先级更高的任务，项目组的其他成员并不知情。这个时候的我并未发起会议向上层领导反馈协商开发的时间，而是选择催促他们，直到又过了礼拜我发觉他们的开发还是停留在原地于是才让我的领导发起协商。
将近耽误了一个月的时间，很明显责任在于我，之后我开始觉得站会、周会等的重要性，并开始实施，效果比较显著。这些会议能让项目组所有成员清楚的了解项目的最新进展、各成员的开发状态以及项目风险的评估。
质量无法保证：
我认为对于代码的质量是研发人员必须保证的，我们需要以让测试人员找不出Bug为目标，目前公司没有代码review、单元测试等机制来保证项目等质量，仅仅靠测试做的一些黑盒测试。事实也证明，我们公司产品的质量比较差，经常会有客户反馈问题，虽然前期看起来项目推进会快一些，但实际后续的维护成本却很昂贵。
有效会议的重要性：
公司大大小小的会议可能都需要最高层领导来参加，根据我最近一段时间参与的会议以及这次项目过程中发起的一些会议，我们在会议前总是没有把会议想要讨论的内容、通过会议我们想实现什么目标、我们需要与会人员什么帮助等，并且会议中没有意识到时间的把控，我们知道会议的成本是非常昂贵的尤其是在有最高层领导的会议上，会议的把控也是要努力的一个方向。
总结：
在本次项目管理经历中，心路历程不止这些，但这些点是我印象最深刻的，包括现在的公司也有存在这些问题，尤其是沟通方便，我认为一个会沟通程序员会让你原本只能达到六分的工作达到9分，极大的提升你的工作效率。
