周末的失声
记得有个周末，我人本来就不舒服，急性咽喉炎，嗓子话都说不出来，说起话来一会儿有声音，一会儿像蛇的嘶嘶声。可没办法，台湾的一个项目release出去的deadline时间是下周一，人病成这样也得上。来到公司之后，同相关研发、系统工程师以及测试人员一起查了下调试日志，我发现是某个中间模块对询价这个消息处理不当，问相应的开发不清楚如何做，他们也是接手没多久。我耐心地同他们讲之前实现的那些方案和相关的场景，可人家却说你又不是系统工程师，不能听我一个人的，而系统工程师不清楚情况就直接安排我这边做些改动，想将这个问题绕过去。这个气得。。。。。。本来说话都说不出来，还费了这半天劲，就愣是让他转不过弯来。我这个人平时脾气都很好，标准的老好人，这次都急了，放出话来：“叫系统工程师的头来，其他人免谈，就是叫研发老总来我都是这个态度。”后来，系统工程师的头过来，找了个小会议室，我再将相应的消息流程及要求完完全全地讲了一遍，最后那个中间模块的同事才答应修改。
本来很普通的一件事，愣是周末找来十来号人一起搞，当时项目经理的小孩还在旁边不停地哭。
为何出现这样的事？是没有相关的设计文档吗？有的，至少我这儿是有的。这个功能早在一年前就在另外一个项目中已经实现过，当时包括研发和测试前后差不多花了两个月才将该功能相关的十几个测试场景跑通。
设计文档没有分享？或者是交接工作没搞好？这多多少少是个问题。说实在话，搞研发的同事做事情一般都很认真，至少要知其然和知其所以然。可并不是所有研发都愿意搞清楚上下游各模块的相关实现逻辑，而测试人员也可能存在这样的想法，这不可避免地让研发、测试、系统工程师在周末的加班时的方向都出现了偏差，导致后面方案有争议。另一方面，组织过程资产如何管理也是要改进的。对于设计文档及测试场景，最初的版本并不翔实，没有得到及时的更新，而且没有很方便快捷地让相关人员能查询，有待改进。
如何才能做得更好呢？一是设计文档和测试场景要充分地review，适当扩大参加review的人员，这样可以避免只有极个别认真的同事才知道如何做(自我夸奖一下^_^)；其实公司质量部也提倡要做code review，但没有体现在制度上，做得好的和做得差的没有什么差别，要活用激励机制来鼓励大家积极参与。尤其对于新员工的培训，各部门应该维护并更新相关的知识库。
提高相关人员的工作意识，不要老想着自扫门前雪，要尽量有系统的认识；提高项目管理的能力，下周一要release，周末还在测试相关的场景，这是用赶工来避免影响进度，在项目定期检查时，不光是要发现目前项目中还存在的问题，还要想办法让每一问题落到实处，还要想办法推动每一个问题的解决进度。
如何处理项目中的冲突？记得当初的项目经理在我发脾气时，一直要求我冷静下来，实在不行出去喝口水走一走，她也答应我立即将系统工程师的经理找过来，这样我的心情慢慢地平复下来，让后面的讨论方案及解决问题我都尽心尽力。当有一方不冷静是，让其离开现场冷静下来是个好办法。另外，当有冲突发生