关于项目的一些总结
收益：
项目收益想清楚，看下是否有其他项目功能可以替代掉该项目功能，收益对应的产出有多大，其他组是否有同类型项目。上游、下游可能发生哪些变化，变化后项目是否还有收益。
前期调研要足够，邮件出来，这样做完项目有个对比。
项目的收益要分类，是提高了速度，减少了成本，增加了系统的稳定性，还是扩大了系统的支撑范围。
上级是否认可你的这个收益，进而才能支持你的项目，有了关注度，项目才能推动起来。
人力：
项目的分工，对外涉及了哪些团队哪些人员，每个人员的工作前期明确下来。
如果有改动，会涉及到哪些人，也要说清楚。
工作明确下来后，排期让对应的人给出来，然后整体考虑把控给出排期，责任落实到人。
如果晚了，要说明原因。
内部项目的人力安排，对下安排要时间紧，对外承诺时间要尽量松。考虑好个人能力、是否有并行项目等其他耗费人力的可能性，这部分会占多少比例。
计划：
对外接口、内部各个模块的接口一定要提前定义好，特别是对外接口，文档的形式邮件出来，对己、对人都清楚、方便，后续争议少。
内部接口前期也要考虑完整，后续修改尽量少。
进度：
遇到的问题和进度及时通报出来，与上级和关注者同步下信息
问题：
上述问题难免，如果出了问题，不要着急拍板决定，多思考权衡再下结论、做修改。
以上是总结。
来现在的公司一年多了，断断续续做了两个项目，包括思考别人手里的项目，过程中成长与烦恼、困惑的地方都很多，说下感受。
项目delay是经常的事情，如期交付很难。原因看上去只有一个：人力。实际上原因却很多，比如估时间太过自信，沟通成本很大，依赖上下游，毕竟公司很大，每个组事务很多、优先级也不同，但怎么样避免呢？使用开源程序可以避免依赖别人，但无疑也是给自己增加了工作量，包括后面的维护也没法交给专业的OP运维该项目。很困惑。小公司工作时项目都是按时完成，大家鼎力配合，到了这里反而感觉障碍很多，可以理解，但也无法理解。
项目组之间责任的划分，交互密切的两组之间肯定有些灰色地带，该谁来做是个问题。因为本身灰色地带难以划分，具体是要做什么，很多人说不清楚，做成什么样子，也没有人有个明确的预期。要整理这种地带前，要花更多的时间前期调研。充足的调研可以防止后面踩很多坑，通过调研也才能够有个合理的、明确的预期出来。
项目何时交付?一个项目做到完美时交付太晚，但有些硬性的条件：已知bug修复、单测覆盖率、QA测试用例等还是得衡量一下的，我理解目前我们没有特别着急上线的项目，不是在做什么产品，要赶在竞品之前，赶在某个发布会之前。在经理压力下匆忙上线一定要禁止，至少项目负责人要能抗住压力。我用了3、4个月的时间来修改上个项目上线后的bug，可以理解压力很大，因为这个项目出于各种原因已经做了很久了，但是后期改bug的感觉实在不算美好，不得已增加许多trick的逻辑，让人觉得系统更加脆弱，通用性更差。eat your own dog food的法则，在这里好像不太管用。跟前面一样，我可以理解，但也不太理解，有些困惑。
说完了困惑，说下自己的成长和不足。创新很难，特别是在大公司。要成长，需要学习的东西很多，开源的程序了解也不够。但好在基础还算扎实，学习能力很强，也愿意花时间去了解和研究。不过别人给你指点这些和自己能够提前知道这些，又是完全不一样的层次。怎么样带项目是个很大的话题。按对象，自己、上级、下级、相关的外部组怎么定位、汇报、协调？按过程，前期调研，中期展开，后期上线，怎么得到有效执行？有很多值得自己思考和回顾的地方。只说缺点的话，第一个项目接收离职rd的模块，虽然问题千疮百孔，改动很大才得以上线，但属于后期才介入，前面的原因过程都不了解，第二个项目自己带人完成，虽然只是小的升级，但感觉问题更多，接下来要跟人做完一个完整的项目，有些期待，希望自己学到更多，也能做出更多成绩。