测试编辑问题

（一）  程序和美术/策划的协作

　　项目刚开始的时候，可以感觉出与我合作的策划与美术都很想将产品做成精品。他们时常在琢磨，不时会提一些很炫的点子，希望我能实现。不过一方面大家从未磨合过，策划与美术可能吃不准程序能实现到什么程度；另一方面，可能很多第一次直接与程序合作的设计者会高估程序的实现能力或低估一些设计的实现难度，并且过早将精力放在了许多细枝末节上。这样一来，作为客户端新手的我有时就比较悲催。为了赢得伙伴的信任，我只好拼上自己几乎所有能用的时间精力，身心接近透支状态——Trust is earned。

　　后来我和主管UI的美术同事聊过几次。他也提到，刚开始合作时确实不知道程序的实现和承受能力如何，所以的确也是在试探。对于这个想法，我大致还是认可的，尤其在项目初期阶段，什么都没有的情况下使劲做加法未尝不是好的做法，这样可以在项目内树立起产品设计上的高度或标杆。

　　不过当项目进入后期，程序的精力要逐渐转到程序健壮性和运行效率的时候，我就不太希望策划和美术还会提出超越我既有经验、需要我花很多精力在前端表现上的需求。还好UI美术总体上还是比较配合，而且下半年有一位经验丰富老练的系统策划加入项目，并在后来成为主策，很大程度上解决了UI美术和程序之间的协作问题。协调能力真是衡量策划价值的重要指标。

      我曾就被打断的问题请教过主程和老东家的领导，他们均表示这是国内的常态，需要克服自己情绪去适应。这样也能锻炼出记忆需求和思路的能力。另外，实现功能时不要过于纠结方案是否完善；先写，把功能实现出来，以后再完善；在写的过程中思路也会越来越清晰。纠结于我而言是个大问题，我会另写文章总结。

　　虽然我读过好些文章论述程序员被打断的代价，但理想很丰满，现实很骨感。在一个初创且快速迭代的项目和团队里，很多我从文字资料中读到的软件工程观点都不再适用。

　　的确被打断的节奏在项目中前期尤其明显。项目进入后期，随着大家对项目相关的工具、代码和技术逐渐熟悉，随着各人岗位逐渐固化，随着各个模块逐渐稳定，被打断的节奏也就不那么频繁了。不过预计项目上线后，这个节奏又会紧张起来，而且到时候被打断的就不仅仅是编程过程了，休假也会被打断。