第一次当开发负责人的流水账

        2013年7月份，部门接了个小项目。部门领导决定让我担任开发负责人，尝试一下，不过领导怕出现风险，所以指定了一个经验丰富的开发负责人L带着我。

       在我们公司，开发负责人主要做的工作有：

       1. 深入理解业务，理解需求文档，有歧义的地方，与项目经理沟通并确认。

       2. 完成核心模块的设计。

       3. 根据需求文档和项目上线时间点，制定开发计划（什么功能，由谁在何时完成）。

       4. 组员遇到技术难点或者需求不理解的地方，开发负责人给予技术支持，讲解需求。

       5. 在项目的开发过程中，及时检查组员的完成质量和进度，发现潜在的问题。

       6. 模块上线时，到现场支持，主要是在现场解决紧急的反馈，协助实施人员完成上线、培训工作。

       7. 收到项目经理的反馈时，和项目经理沟通确定反馈内容，消除歧义，再分配给组员完成，控制反馈的质量和修改进度。有时候也会直接与客户沟通反馈内容。

     在开发前3个模块时，开发计划都是由L制定的。同时他教我根据工作量和开发人员的能力来安排进度，每天四五点左右，就询问开发人员的进度，让组员提交代码，有bug或者漏洞就及时让组员修改，这样每天把握进度和质量，可以及时发现基础性问题，减少风险，减少模块开发完成后的测试反馈量。

       在这期间，最让我困扰的是，我们3个人做这个项目（L不参与开发），另外2个同事都是比我早进公司，都是有工作经验的员工，年龄比我大，而我只是一个刚毕业一年的90后程序猿，却担任开发负责人的角色，我怕他们有想法，于是就小心翼翼地在QQ上面问他们做得咋样了，是否做完了，做完了就提交代码，我简单的测试一下，测出来的问题直接截图，让他们修改。后来我发现，我不喜欢别个一个劲儿的在扣扣上面发截图让我改，我不知道他们是否讨厌这个方式，于是我就截图整理成文档，再发给他们改。

        9月份，3个模块开发完了，只剩下最后一个模块，虽然这个模块的业务是核心业务，但是却设计的很浅显，听项目经理说，是因为那个客户他们院管理非常松散，很多业务流程不够规范，全凭他们的习惯，于是，核心功能就没要求那么深入，做深入了，他们也接受不了就不会用。这个模块我没有参与开发，没有多少技术难点和业务难点，全由另外一个同事完成，9月底做完之后，我才知道，原来这个同事早已提出了离职，吃了散伙饭就散伙了。

       10月份，迎来我人生中第一个出差。在客户现场，及时修改项目经理提出的问题。某天晚上在酒店修改反馈，发现了一个重要功能点的设计不太合理的地方，虽然原有的方式可以使用，但是会给后续的维护增加麻烦，于是我晚上加班，花了2个多小时修改了那个功能点，填补了这个坑。出差5天，几乎每天晚上都是搞到12点多。项目经理还说：“跟我出差是最不辛苦的，千万不要回去跟他们说和我出差最轻松。”我心想，这叫轻松啊？！虽然我不喜欢被迫加班，但我喜欢主动加班，可能这是程序猿的通病，发现了bug就一定要忍着饿憋着尿解决掉，要不然睡觉之前满脑子都是那个未解决的问题。

       5天的出差，收获非常多，在现场才真正的理解客户的需求，才知道我们做的那些功能有什么作用，在他们实际业务中解决什么问题，也明白那些功能实际的价值所在。当然，也促成我不自觉的找出系统设计不合理或者不人性化的地方，思考用什么样的方式让客户更方便使用，从根本上解决问题！

      11月之后，这个项目的开发就全部由我来负责了。虽说都是我负责，也就是一些反馈和新增的需求，没有大的变动，都是一些小问题，我一个人轻轻松松解决问题。按照公司的规定，开发修改之后，应该由项目经理或者实施人员测试之后更新，但这个项目业务比较简单，都是点小问题，我修改了之后，测试没问题就直接给更新了代码，没有通过实施人员，也算是减少了实施的工作量。不过对于大项目和复杂的系统，我这样做就不好了，增大了风险。

       这个项目让我成熟了很多，没以前那么急躁了，淡定了许多，技术提高了，业务和沟通能力也有进步，得到了客户、项目经理和部门领导的肯定。

       2014年5月份，项目经理在做这个项目验收方面的准备工作，验收之后，就要转交给另外一个同事了，我就不负责这个项目的开发了。虽然这只是个小项目，但是却让我成长了，非常感激领导给我机会，感激L和其他同事的帮助支持。希望这个项目顺利验收，也算是对我工作的一个肯定吧。

        路漫漫其修远兮，吾将上下而求索！