站在老板的角度：

大部分中小公司，目前依然还是业务或项目驱动型的，而非类似大公司诸如华为，苹果那种科技驱动的。这就导致了中小型公司不会考虑太长远的产品规划，更多的是关注现在的每个客户，每个单子。 另外由于要处理的事情太多，老板一般都只关注结果，没有结果的过程，对老板来说是没有任何意义的，相反那还是一种成本（时间成本，机会成本，人力成本)。加上公司的业绩压力，老板和管理层更是追求研发团队的产品要：多，快，好，省。

产品需求方面，因为老板或业务负责人看问题的视野角度比较高，接触的人，客户，合作伙伴会很多，因此更多在用户需求，行业前景，战略规划等方面有很多见解，对产品的需求方面可能会常常调整。

站在程序员的角度：

其他人看看似很简单，应该一两天就开发出来了的东西，程序员内心却本能的会梳理用户场景种类，部署环境，及上线后遇到数据量变大后系统是否还能用的问题。稍微有追求的程序员还得考虑架构，可扩展性，可维护性，稳定性，性能，安全，用户体验，可重用性 。有的甚至，因为公司没有配套的美工，网页设计，弄不好还得成为全栈工程师。连切图，网页，后台，数据库，接口都要一起做了。所以压力是很大的，工作理还乱，进度每天都在催。

涉及需求这块，工程师因为长期专注一个个具体的问题,平日工作不是在加功能，就是在改bug... 时间久了程序员大部分厌恶需求变更。

做好需求沟通：

给程序员传达需求时，多展示下来自客户的原始需求，经过团队讨论，头脑风暴后再制定方案，可以做到同时兼顾需求和方案，成本等问题，避免外行指导内行而引发不良后果和情绪。

适当的配合下个工具，原型，草图，思维导图等，避免沟通二义性。毕竟每个人的生活阅历不一样。

科学设定工期：

工期这个问题，不管有多急，沟通完需求后，可以听下程序员的真实评估，时间接受不了再想办法，而不要命令式规定多少，引起逆反心理，不服众。即使强制让大家去执行，最后也是会舍弃很多必要的东西，而带来很多潜在风险。

引入他人测试：

最好让其他职能人员，或自己亲身以及愿意合适的老客户去测试下，程序员自己开发的产品，很多时候习以为常，不认为是bug。

优化激励制度：

如果是短期无法盈利的项目，则以产品的进度，稳定性，用户体验等作为参考进行评估，分别对尽心尽力的程序员进行奖励。

如果是在盈利的项目，适当拿出一定比率的利润作为给研发人员的激励，这个不要在工资中体现，而是跟业绩挂钩，让公司和研发团队建立命运共同体。

多沟通，拉近距离：

有空聊聊天，程序员大都单纯，你若真诚以待，他必加倍努力。

达成研发共识：

1.商场如战场，竞争对手做起来了机会就没了。企业看重结果，没有好的结果，再努力也不会给企业带来业绩的。

2.重要又紧急的问题高效解决，重要但不急的问题有计划的逐步解决。 注意好问题排序，不要一件没做完，又来一件，到头来那件都做不好，还怨气冲天。

3.绝大部分好产品都是运营中迭代出来的，而不是一次性开发出来。切记过度设计，盲目追求技术新潮，架构宏大而延误时机。

提前规避风险：

1.技术人员流动是普遍的，涉及域名，云服务器，开发者账号，客服邮箱，统计账号，等都以老板的账号或手机进行注册。

2.技术人员普遍是不爱写文档的，因此需要在平时阶段性的让程序员补充文档，提交代码，交接时把好关。做到心中有数，别断档。

关注我，每天分享一篇中小公司，创业者遇到的问题及解决经验。希望能多结交相关朋友，交流，互助。