零九年似乎一直都在赶项目，而这次和阿软 UED 合作的项目情况尤为特殊，但这次项目让我获得良多。

不同风格和节凑的团队如何融合一起

每天都在用阿里旺旺，这次让我更近得了解了 他们的开发团队 。 本以为阿里系 UED 都是差不多风格，但我发现还是有各自的特色。搬到阿里软件的头几天， 就碰到如何相互分工合作的问题。

首先，我们花了些时间熟悉对方的产品以及代码产出物，以便熟悉其代码和设计风格。 然后，在大范围的空间中，约定了些大框架的规范（包括视觉规范、DPL、代码规范 等）。流程方面情况比较特殊，我们尽量简化和精简了开发流程。

然后，在产品分模块以后，明确了小组对应每个模块开发的负责人。前端和视觉不同的负责 人将对应的开发模块逐渐的连线，这样在方便了各自了解进度的同时，也可以让身处不同小 组的人员相互的熟悉。

经过一段时间的磨合，两个不同的团队已经可以很默契的配合了。顺便在这里惊叹于， 在出发点以及目标一致的情况下，各小组的人员的动能是如此的强大。

人件

项目进度的瓶颈在于我看来，不是时间、不是技术而是人。天时地利，还需要人和。这里所 谓的「人和」，指的是小组各成员的士气以及状态。在这段「特殊时期」中，我能想到些措施

1. 放音乐，缓解下气氛
2. 自由上下班时间，只要不是「太过份」即可
3. 适当调整下工作内容，不要让组员太枯燥
4. 小的练手的技术点，可以使用「竞标」政策
5. 在群里贴美女照片 :^)

进度和质量之间的博弈

尤其紧急的项目，PM 和 PD 对于项目进度就抓得越紧。这有时候未必会是件好事， 开发们会以为，可以因进度就可以抛弃些更为重要的点。

我曾经不止一次在邮件列表中将这一情况加入到「风险点」中，好在经过沟通我们的 PM 站在了我们这边。项目的开发人员也逐渐明白，在核心质量的代码上现在花些时间， 对于以后维护而言是有好处的。

如何避免因赶进度而带来的产品质量下降等风险，这说到底其实是个博弈问题，这就看开发 人员以及 PM 对于该项目是如何定位的了。

对于加班的态度

几乎每个管理人员都会认为，加班是赶项目进度的救命稻草，我个人对此持保留态度。坦白讲， 每个人都不喜欢加班，尤其是无偿无理由的加班，更不期望看见因为 KPI 而加班。

让员工每天朝九晚九以及周六都过来加班，他们的个人时间受影响不说，还可能使他们的士气受 挫，甚至会因此而产生抵触情绪。长此以往，这种情况得不到解决，那么后果将会很严重。

对于管理者而言，都恨不得项目第二天就上线，但毕竟罗马城不是一天就建成的。与其做好我们 这些底层开发人员的思想工作，还不如让那些管理人员想明白些这些事理更能治本。

最后，还是期待公司能有套更为合理的奖励体系，毕竟每个员工对于公司的付出，他们总是期望能得到肯定的。