因为公司战略调整,今天下午我正式把手上的工作内容交接给了其他同事.  

     来阿里1年多的时间里都在做这个系统,虽然碰到很多困难,但是经过很多人的努力,现在看来这个产品正在朝好的大的方向发展,感觉是非常不错的.记得刚来的时候,minisite的故障投诉接连不断,现在,crazy gao几乎都不来找我麻烦了,呵呵.接下来希望他们能把这个东西做大做强,也对得住之前这么多的投入了.

    这次战略调整变化蛮大的,我将要投入新的产品研发中去,非常庆幸有机会做一个能影响到很多人做生意方式的项目.记得有句广告词说的:世界因你而变.呵呵,是的,世界因我而变.

  这是需求方给我的评价：

  “我很庆幸，我们有一个好的项目经理-徐平同学，在发现了问题后，总能最及时的安排资源解决问题；”

  好吧，forget it！我回忆一下这个有史以来我带的第一个最作儿八正经的商业项目，记下些教训。

  这个项目从9月17号到今天11月10号总共投入了35个工作日，1个PD，2个UED，2个核心开发（另外还有3个外围开发），1个DBA，1个测试，1个需求分析，外围涉及的人员包括copy，service可能更多。整个项目流程遵循标准的开发过程：需求分析，DEMO设计，系统设计，TC编写，开发阶段，Review，测试阶段，发布。

  1.上述资源基本是fulltime在这个项目中，他们在主观意识上要达到我们项目目标是这个项目有条不紊的进行下来的首要保证。我观察到这种行为是基于阿里巴巴在流程，制度，以及些许企业文化影响为前提的。每个人潜意识有这样的一种行为基准在那里。

  2.我低估了项目的复杂度以及技术上的可行性，原本以为很宽裕的时间表在最后被用得一分不多一分不少，刚刚合适，包括我留了一手的缓冲时间。假如没有那3天的缓冲时间，我想后面我们一定是被缓存问题打个措手不及。

  3.项目看似有条不紊，但是发布时数据库索引调整协调上犯下的错误暴露了前期需求分析，系统设计阶段以及发布计划评审就应该考虑的性能问题。尽管后来这个性能解决方案确实不好做而放弃，但是如果事先考虑好要比项目做到最后暴露出来强，我还是掉到了这个坑里，尽管我自认为前期准备得很充分。

  4.项目组成员性格各异，如果协调好各方的关系，保证气氛和谐是很微妙的事情。其次是说要注意 厌烦，缺乏耐心，粗心，懈怠心理这些不好的因素，这些缺点埋下了很多隐患。严重一点，还有成员对你的不信任，甚至挑战等等，当然，这些没有出现在我的项目中。

  5.很重要的一点，项目经理得是个万金油，它能撮合各方的资源来配合你做这件事情，把不熟悉的人捏合起来，把互相有那么点不愉快的人们团结起来，然后都朝一个方向前进。

  6.对危机的预感和处理体现了项目管理人员的优秀与否，无比正确的废话，要做到那个份上还是需要有点功力的。

  7.过程的管理，对每个阶段都要设置一个review的点，这是促使项目成员把握时间的一个关键。也是实质推动项目前进的关键。

  8.关于会议。我向来反感会议。那些教条，走过场的会议。but我这里说的会议是那些能激发大家讨论欲望，暴露问题，并且快速商量出对策的会议是非常有必要的。这种生命周期短，不用拘泥于场所形式，高效的会议在这个项目当中开了很多次，高效的解决了很多问题。我同时感谢团队成员配合的做了这个工作，及时向我提出问题暴露问题，这是我最幸运的地方。

  我知道那些只是官方的客套而已，于我，只是有那么点幸运的拥有些资源以及优势。当这些利好在这个过程中不存在，我打包票，和我以前见过的那些案例一样，这个项目会做得很难看，死得很惨。