1）使用明确的文档（产品说明、效果图、修改单）给程序员，细节越丰富效果越好。

会让程序员暴走的场景：

产品：我们公司目前需要有新电商平台，年底要上线。

程序：哦，具体是什么样的？

产品：照天猫那样就可以了。

程序：…………&*（）

很多的内容口头上说明，未必就能让程序员与产品规划人员的想法一样，毕竟程序员不是产品规划人员肚子里的蛔虫，这些理解偏差会造成最终交出得产品与需求不相符，直接影响就是延后进度。

一份清晰明确的文档，会令产品（运营）人员和程序员的效率提高很多。我把清晰文档定义为程序员一眼就能看出需要制作（或修改）的产品是在做什么事，其中逻辑是什么，以及最终呈现结果效果。

2) 分拆项目细节，给出每细项明确的需求时间。让程序员给出细项的优先次序及完成时间，然后商量确定最终完成的日期。

会让程序员暴走的场景：

产品：新的系统下个月中要给我哦。具体时间你自己抓吧。

程序：你妹……

产品：我妹挺好看的

程序：…………&*（）

通常，程序员并不善于预估完成的时间，但老板、客户一定会有一个需求时间。因此项目一开始就告诉他们需要完成的时间目标与终点，由程序员判断其实现的复杂程度制定优先级，会让项目更好控制。光看一眼标题，很多细节让程序员全部考虑进去，在实践中是较为困难的。细节越丰富，程序员就越能给出准确的时间。

3) 缩短会议的时间，让程序员有连贯的时间能够做事情。

会让程序员暴走的场景：

下午1点10分 A产品会

下午1点30分 B产品会

下午2点 各部门协调会

下午3点 需求调研

下午4点半 XXXX

程序：…………&*（）

程序员们通常效率最高的时候，是在有思路并可以安静连贯做事情的时候。而疲于应付各种会议，会让他们的时间变得零散，效率也因此下降。为了完成进度，不得不用加班时间去做一些白天的开发。假设这种开发的时候与到了某些技术坑，就没有了多余的时间可以去解决问题，项目自然而然被耽搁了。如果有可能，尽量缩短会议的时间，把要讨论的内容提前整理好，并且集中性讨论完，真能做到，程序员们也会很感谢你这样做。

4) 未接触过的新技术领域，慎重强压程序员，另需要留出更多的时间。

会让程序员暴走的场景：

产品：这是新的产品，我们想在诺记上面开发超级宝。

程序：诺记的开发我不会啊。

产品：没关系，老板已经决定让你做了。月底前做好吧。

程序：…………&*（）

再牛逼的程序员也有自己擅长与不擅长的开发领域，在没有碰过的技术上，通常会花费一定学习成本，这些学习成本很大一部分就是时间。所以当有新项目的时候，建议多问一句类似的案子你有没有做过，如果是没有做过，让程序员尝试也未尝不可。但注意这个时候试错的成本比较高，需多留出更多时间给程序员。

5) 多数程序员是直性子，他们会很直接的向你抱怨，抱怨完后他们会把东西做完。

会让程序员暴走的场景：

程序：这个页面怎么能这样做改呢，时间不够，逻辑也不通。

产品：我就要这样子的，客户需要啊。滚。

程序：…………&*（）

一个项目在项目周期内，修改需求是再正常不过的一件事情。可能一个微小的细节修改，程序员不得不把所有写过的程序都重新写一遍。长此以往，产生抵抗情绪，抱怨随之而来。抱怨完了，你理解了，并且商量出合理的软件逻辑后，就会帮你去修改了。

6) 理解和确认某些技术的困难性，帮助程序员提出解决方案，如果没好方案不如分阶段实现或砍掉需求。

会让程序员暴走的场景：

程序：这个做不来

产品：我就要麻

程序：…………&*（）

某些技术困难未必不能克服，但是要考量解决的成本，人力与时间。这个时候可以找些你认识的牛人，沟通下技术复杂性，以及他觉得花得时间，如果可行，向程序员建议。实在没有好方案，考虑分阶段实现或砍掉需求个人认为也是选择之一。