根据需求去设计产品，而不是异想天开地搞呀，产品定位是？主要用于干什么？莫生气。。。。做好自己就好

如果你确实不清楚队友的工作范围和流程是什么, 当场问一下不丢人的

当面强行懂背后又各种意见, 这样不容易得到信任, 不仅是技术人员的信任

需求要落实到纸面呀，研发之前双方就要讨论出一个大家都同意的spec。
那最后研发做出来的东西达不到spec的要求，自然就是研发的锅了。

1楼 @zhxq871653 嗯，已经不生气了，主要是沟通后没有达到应有的结果。跟开发说话一直是好声好气的，要沟通是不能带情绪的，会影响判断。如 3楼 @amosji 所说，我们并没有spec这个东西。spec是什么，我写了PRD，对于发生的这种错误，我只知道表象，并不知道出错的原因。

2楼 @jokester 我并没有强行懂，是真不明白，我的意见都在肚子里，没跟谁说。下次开会会首先把这些问题发生的原因和解决方法，都弄清楚了

给我的感觉是少了上线流程，测试版的东西就直接当成正式环境在用了。

5楼 @bocar 是在测试，木有上线之前，不分测试和正式。

再好的程序员，自己也很难测试出来自己的错误，这倒不是开发者态度的问题

这是一个人都是主观的问题

这就是一般公司，都是开发和测试分开的原因

7楼 @tinyfool 我之前在中兴，我们部门2014年的时候正式才开始敏捷开发的。从那时起，就非常注重自测了，每次开发之前会把测试场景说清楚才动手，团队行动多过单打独斗，整个上班的气氛都被盘活了，版本质量提升了。现在到小公司，团队小，非常想推。但是上次提出，可能我说的不好，被老板否了。

8楼 @bradon 你要适应具体的情况啊，素质不同，流程就不可能相同

我还是那句话，你的问题始终是在跟人沟通的层面，另外你是去公司吐槽的，还是去解决问题的？

不能光看到别人的问题，要把每一个同事当作一种资源，没有完全没用的资源，只有配置不合理的资源

9楼 @tinyfool 这句话我会好好理解的

10楼 @tinyfool 嗯，我这样想：抱着解决问题的心态去沟通，每个人都是一座宝藏，要开采得当

从题主的描述来看，完全把这事推给程序员了。所有的问题在于“程序员听不懂需求”。看到题主的潜台词是在怀疑程序员的工作能力和工作态度。

那么反过来说，如果程序员达到了题主的质量要求，到底需要多久来完成任务呢？是不是开发任务太紧张了？是不是前提根本就是你，或者产品，或者老板定的目标就不对呢？

如果时间也够，人也够，那程序员就不会犯错了吗？如果我们可以通过规范个人的行为，提高个人的敬业度，就能保证没有bug，那为什么公司还要配测试？如果公司没有测试，你是否需要肩负起测试的职责？

解决问题，优化流程弥补人的缺陷这才是目标。

这个问题通常有两个答案： 需求不会说人话，开发听不懂人话。

你喜欢哪个？你的伙伴们呢？

14楼 @pinxue 第三个答案是……， 唉

13楼 @cuijin007 我觉得确实流程上有欠缺，公司老板的那套流程是快捷的，但是并不能解决所有问题

15楼 @tinyfool 第三个答案是什么？