认识达内从这里开始

在日常工作中，我们常常会遇到各种各样的问题，而你认为是一些不重要的小事的时候，恰恰相反，对于有些人来说这些就是大事，也就是说，你可能在不经意间犯了人家的忌讳。那么我们在工作中如何才能避免这些问题呢？

合作方面

1、合作过程中多积累

产品经理经常需要和不同的人进行沟通和对接需求，例如公司领导层、运营、投放、商务、业务、设计、开发、测试等。

不同的人，都会站在不同的立场、出于不同的目的，向你提需求或者反馈意见。

在大前提他们的需求合理的情况下，你是直接根据他们的做了呢?还是多多向他们请教一下呢?

运营投放们需要你配合的时候，不要以为自己不相干，要多看看他们的活动类型、多思考他们的投放渠道、多问问为什么这么选择;

开发们围在一起沟通技术细节的时候，不要以为不关自己事儿，要多听听、多了解下他们是如何实现需求的;

设计们出设计稿给你的时候，不要一味着收到稿子完事了，多和设计们讨论和请教一下，为什么这么做的原因;

老板觉得要提前做某个需求，不要只把自己放在执行的位置，要多想想为什么这么做，对公司有什么好处，公司最近有什么变动，如果想不明白，可以尝试问问看;

……

这些都是宝贵的各个角度的实践知识啊，都是需要看专业书才有可能看到的东西或者有可能连书里都没有。现在，你通过一个个需求，就慢慢都了解了，这么一个大好的补充各方面知识的机会摆在你面前，怎么能浪费呢?

不说好处的都是耍流氓，这么做的好处如下：

对其他和你合作的人以及他所在的岗位有更深入的了解;

慢慢积累自己对各方的大概知识框架;

基于前2点好处，相互之间的沟通会越来越顺利;

在之后的需求时间预估和项目排期上会更加有把握一些。

合作过程中，多问为什么，这个在之前的文章里有解释过，这里就不在多说了。

2、摆正和各方关系的心态

产品人要端正几个态度，那就是：

不要把设计师们、开发们、测试们当做实现需求的机器;

不要把运营、投放、商务、老板等人当做只会提需求的臭傻逼。

经常在各种地方看到产品人在各种吐槽，例如：

就是简单的移动一下位置、放大一下，想不明白为什么美工做不出来;

一个简单的功能，代码狗们都搞不清逻辑，实在是太弱了;

老板只会哔哔哔的提需求，太坑了;

……

你用这种对立的心态去看待你的伙伴、你的组员，那么你和大家的关系怎么会好呢?人家跟你关系不好，更是不可能愉快的共事啦。

想让别人尊重你的前提是，你得尊重别人。

这么做的好处：

伙伴们能够在愉快、相互尊重的气氛中工作;

对于个人，是一种素质的提升。

产品工作本身

1、多从整个产品的角度考虑问题，而不是仅从产品岗位角度考虑问题

举个例子，这个版本的需求都已经确定，版本上线时间也已经确定了。但是，运营和投放因为某种原因，要在下个版本做一波大活动和投放，需要产品这边配合开发一些东西，这个时候怎么办?

如果仅从产品岗位考虑问题的话，会觉得这个太临时了。如果应承下来做的话，不但要临时给自己增加工作量，还需要和设计师们、开发们重新沟通时间、调整计划。他们也可能因为临时的工作量而导致一些负面情绪的出现，你还得理性/感性的进行安抚。

但是，从整个产品考虑的话，这又是一件需要并且最好做掉的事情。毕竟，在整个团队有数据压力的情况下，需要用一些外在方法来带来新增和日活，这样对整个团队都好。

再举个例子，一些小白产品们总是会纠结在一个公司里，到底产品更重要还是运营更重要的问题。总觉得公司重视运营，不重视自己，从而很难过。

其实，这种想法并没有什么意义，如果站在整体考虑的话：需要强运营的产品，自然偏重运营;需要强功能的产品，自然偏重产品。

偏重问题，只是量的问题，并不是质的程度。考虑怎么对产品好，这才是最需要纠结的问题。

这么做的好处：

对整体产品比较好，不会因为产品的私人考虑而有所偏差或者停滞;

对个人发展比较好，不断的锻炼自己的全局观思维。

2、多和团队伙伴沟通业务

有时候，能看到产品人抱怨他们的团队成员。比如，我们组里的人都不关心需求、他们只知道做，做了又做错，真是无语。

这个时候，其实你要反思一下，是不是你从来不和他们沟通为什么需求要这么做，才慢慢导致这种情况的呢?

当然，我也清楚，不是所有的开发们、设计们都对为什么要做这个需求有兴趣，但是如果连懂都不懂，你怎么指望大家设计、开发出你想要的东西呢?

不妨在每个版本沟通需求的时候，顺便把每个需求这么做的原因也和他们沟通一下，不管是从数据分析结果、用户反馈，还是公司高层出于战略考虑，都可以说一说。

毕竟，我还是坚信，基于理解基础上的需求实现，从长远上看比较“安全”。

这么做的好处：

基于理解的设计和开发，可能能够在照顾到现有需求的前提下，考虑到一些可能的坑和未来的改动;

长久，大家会更有团队的感觉。

3、看数据结果前，辩证数据的真伪

很多产品经理会经常说：

从数据结果可以看出balabalaba……

这都快成为一种口头禅了。

但是我要告诉你，如果数据本身就是错的，那么你所谓的数据结果就是个无稽之谈。

可能你会很疑惑，数据怎么会错呢?当然会啦：

可能因为不同平台的不同算法，导致数据和你真正想要的算法不同，从而出错;

可能因为开发埋点的时候不小心弄错了，从而出错;

可能因为开发实现某个相关功能的时候，实现方式的不同，导致连带影响到数据偏高或者偏低，从而出错;

……

数据出错的可能性很多，因此，在说出“从数据结果可以看出”这句开场白之前，先去了解清楚数据本身是否出错。

这么做的好处：

不会把时间浪费在错误的数据上;

对数据分析会有更深入的理解;

更容易得出真实的数据结果。

4、产品材料一定要文字留档

这是个非常非常非常重要的事情，请一定要记住。

刚进公司的时候，我发现公司里居然么有产品文档可以共享。了解产品基本靠多使用;要修改某个功能，基本靠经手人的记忆力。

这样是非常传统并且不科学的方法。一旦出现经手人离职的情况，接手人分分钟懵逼，说不定得让开发们找对应的代码才能仅仅解决了解概况这个问题。

而其中最重要的是，产品的增删演变历史以及对应的需求文档。

这么做的好处：

出现问题或者需要相关需优化的时候，可以根据文档找到具体参考;

从历史中了解变迁，有助于需求的管理;

有助于项目的交接。

5、需求要对接完整

工作中，会经常出现要和第三方沟通对接需求的情况，这个第三方有可能是公司外部的，也有可能是公司内部其他小组的。

有些产品觉得既然是技术对接，那么所有的事情就都可以等技术对接的时候再去做咯，然后就把所有的东西都丢给技术了。但实际上真是这样吗?

也许流程可以先梳理起来;

也许对接文档可以让对接方先准备起来;

也许测试环境可以让对方先搭起来;

也许要配置的接口可以让对方先设置起来;

……

和第三方对接，本来就存在很多坑(文档不齐、接口不ok、对接时间超长等等)，产品最好要能够在对接前期先准备起来，这样开发们在对接的时候也会比较方便和省时间。

尽量把对接控制在可控制的范围内，而不是任由发展。

这么做的好处：

和你合作的开发们会比较舒服一些;

对接完成的时间相对可控一些，从而计划好的上线时间也相对可控一些。

6、要做好准备再拉人开会/讨论

越是工作到后面，越是讨厌开会，有时候甚至讨厌小撮人的讨论。为什么呢?

往往没有一个讨论重点

有重点，但是都是头脑风暴

没错，头脑风暴是好的，但是同一件事，如果每次开会都是头脑风暴形式的，那么是非常让人心烦的。

因此，无论是开会还是讨论，都应该在之前就列出讨论的主题、围绕主题的一些点。这样大家就可以根据列的内容进行有条理性的讨论了，从结果上，也更容易有效果，搞定事情。

达内时代科技集团致力于培养面向电信和金融领域的Java、C++、C#/.Net、3G/Android、3G/IOS、PHP、嵌入式、软件测试、UID、网络营销、网络工程、会计、UED、web、Unity3D、大数据、童程童美等17大方向中高端软件人才课程与少儿教育课程。选择运城计算机培训，不再孤军奋战，轻轻松松做IT高薪白领。运城达内培训带领有明确目标的学子迈向成功之路!想找工作的求职者可以加QQ：3373924515（太原达内就业服务部）咨询了解。