常州软件开发中，产品、设计与研发的“铁三角”协作

　　常州软件公司的办公室里，经常能看到这样的场景：产品经理拿着刚画好的原型走进开发组，开发瞄了一眼说“这个做不了”，产品说“客户就要这个”，设计在旁边补了一句“那要不我改个视觉稿先让客户看看？”三个人你一句我一句，音量逐渐升高。这种画面在很多公司都出现过，但那些项目做得顺的公司，往往已经找到了让这个“铁三角”平稳运转的方法。在常州，由于项目周期普遍偏紧，客户需求变化快，产品、设计、研发三方如果各管各的，很容易出现信息断层。产品按自己的想法画原型，设计按自己的审美出图，开发按自己的理解写代码，最后拼在一起发现根本不是客户要的东西。

　　解决这个问题的关键，在于把“铁三角”的协作点往前移。常州一家做智慧园区软件的公司摸索出一套方法，在产品还没有画出完整原型之前，就会拉上设计和开发一起开一个“对齐会”。产品先用白板把核心流程画出来，开发当场评估技术可行性，设计同步思考交互和视觉的呈现方式。这个会可能只有半小时，但能把很多后期才会暴露的矛盾提前消化掉。比如开发会说“这个数据接口目前还不稳定，建议先做离线缓存方案”，设计听完就会调整界面上的加载状态设计，产品也会据此调整需求的优先级。这样一来，三个人在项目开始之前就已经形成了一套共识，后面各自推进的时候，不需要反复沟通就知道别人是怎么考虑的。

　　另一个在常州实践中被证明有效的做法，是建立统一的“需求语言”。很多团队之所以协作困难，是因为产品说的“用户体验好”在开发那里无法量化，设计说的“视觉冲击力”在测试那里无法验证。常州有些团队会建立一份简单的术语表，比如把“响应时间不超过2秒”写进需求文档，把“按钮在移动端可点区域不小于44px”写进设计规范。这些看似琐碎的约定，实际上是铁三角协作的润滑剂。此外，物理距离也很重要，我发现常州做得好的软件团队，往往会让产品、设计、开发坐在同一片区域，而不是分楼层办公。遇到问题站起来喊一嗓子就能当面沟通，远比在钉钉上发一串消息效率高。协作不是靠流程文档管出来的，是靠日常这些微小的互动磨合出来的。当产品愿意多了解一点技术边界，开发愿意多问一句设计意图，设计愿意多听一下用户场景，这个铁三角才能真正从“三角鼎立”变成“三角合力”。