说说来公司做的两个项目

 

关于项目的一些总结

收益:

项目收益想清楚,看下是否有其他项目功能可以替代掉该项目功能,收益对应的产出有多大,其他组是否有同类型项目。上游、下游可能发生哪些变化,变化后项目是否还有收益。
前期调研要足够,邮件出来,这样做完项目有个对比。
项目的收益要分类,是提高了速度,减少了成本,增加了系统的稳定性,还是扩大了系统的支撑范围。
上级是否认可你的这个收益,进而才能支持你的项目,有了关注度,项目才能推动起来。

人力:

项目的分工,对外涉及了哪些团队哪些人员,每个人员的工作前期明确下来。
如果有改动,会涉及到哪些人,也要说清楚。
工作明确下来后,排期让对应的人给出来,然后整体考虑把控给出排期,责任落实到人。
如果晚了,要说明原因。
内部项目的人力安排,对下安排要时间紧,对外承诺时间要尽量松。考虑好个人能力、是否有并行项目等其他耗费人力的可能性,这部分会占多少比例。

计划:

对外接口、内部各个模块的接口一定要提前定义好,特别是对外接口,文档的形式邮件出来,对己、对人都清楚、方便,后续争议少。
内部接口前期也要考虑完整,后续修改尽量少。

进度:

遇到的问题和进度及时通报出来,与上级和关注者同步下信息

问题:

上述问题难免,如果出了问题,不要着急拍板决定,多思考权衡再下结论、做修改。

以上是总结。

来现在的公司一年多了,断断续续做了两个项目,包括思考别人手里的项目,过程中成长与烦恼、困惑的地方都很多,说下感受。

项目delay是经常的事情,如期交付很难。原因看上去只有一个:人力。实际上原因却很多,比如估时间太过自信,沟通成本很大,依赖上下游,毕竟公司很大,每个组事务很多、优先级也不同,但怎么样避免呢?使用开源程序可以避免依赖别人,但无疑也是给自己增加了工作量,包括后面的维护也没法交给专业的OP运维该项目。很困惑。小公司工作时项目都是按时完成,大家鼎力配合,到了这里反而感觉障碍很多,可以理解,但也无法理解。

项目组之间责任的划分,交互密切的两组之间肯定有些灰色地带,该谁来做是个问题。因为本身灰色地带难以划分,具体是要做什么,很多人说不清楚,做成什么样子,也没有人有个明确的预期。要整理这种地带前,要花更多的时间前期调研。充足的调研可以防止后面踩很多坑,通过调研也才能够有个合理的、明确的预期出来。

项目何时交付?一个项目做到完美时交付太晚,但有些硬性的条件:已知bug修复、单测覆盖率、QA测试用例等还是得衡量一下的,我理解目前我们没有特别着急上线的项目,不是在做什么产品,要赶在竞品之前,赶在某个发布会之前。在经理压力下匆忙上线一定要禁止,至少项目负责人要能抗住压力。我用了3、4个月的时间来修改上个项目上线后的bug,可以理解压力很大,因为这个项目出于各种原因已经做了很久了,但是后期改bug的感觉实在不算美好,不得已增加许多trick的逻辑,让人觉得系统更加脆弱,通用性更差。eat your own dog food的法则,在这里好像不太管用。跟前面一样,我可以理解,但也不太理解,有些困惑。

说完了困惑,说下自己的成长和不足。创新很难,特别是在大公司。要成长,需要学习的东西很多,开源的程序了解也不够。但好在基础还算扎实,学习能力很强,也愿意花时间去了解和研究。不过别人给你指点这些和自己能够提前知道这些,又是完全不一样的层次。怎么样带项目是个很大的话题。按对象,自己、上级、下级、相关的外部组怎么定位、汇报、协调?按过程,前期调研,中期展开,后期上线,怎么得到有效执行?有很多值得自己思考和回顾的地方。只说缺点的话,第一个项目接收离职rd的模块,虽然问题千疮百孔,改动很大才得以上线,但属于后期才介入,前面的原因过程都不了解,第二个项目自己带人完成,虽然只是小的升级,但感觉问题更多,接下来要跟人做完一个完整的项目,有些期待,希望自己学到更多,也能做出更多成绩。