1.我直接说结论:设计可以改,功能不能改,具体情况具体判断。
2.团队的配合不是谁对谁错的问题,我们每个人都对产品和公司方向都有自己的理解,基于这点产生的矛盾都是正常的,没必要带着情绪去看待双方。这种情况,如果出现在产品初期,特别是对于我们创业公司,在做取舍决策的时候,只要坚持一个原则:产品能够如期上线,且功能使用没有大问题。这意味着会牺牲部分用户体验,部分代码质量。在这个阶段这样的决策都是极其合理的。
3.程序vs策划,产品vs研发这是很经典的矛盾。化解这样的矛盾,得从两方面入手:
1>.了解对方的知识体系。这很重要,了解内核和观察表面是差异很大的体验。最近这点体会很大,我是运营出身的产品,虽然之前也小打小闹做过网站,但其实这很浅。最近重新开始学习前端知识,发现自己对设计的理解更深了,更重要的是,你理解了对方的工作,也理解了对方的心态,这对团队管理和计划安排非常有帮助。准备后期再学一些后台开发和iOS开发的知识。
2>.多为对方考虑,减轻对方的负担,让对方参与决策,提供给对方更多有用的信息。这个不用我多说,但是这点却很容易走偏。当出现问题后,如果这个责任是多人平摊,则负罪心理就少很多。当然,现实生活中,这个时候肯定会产生一个“责任人”。
4.PM碰到的大多数程序都可以分为两种,产品型程序和技术型程序。产品型程序有一定的开发经验,除了对代码,也对其它方面比如设计,功能都有自己的理解。技术型程序则只关心自己的代码,自己的技术能力能否成长。
5.产品型提的意见一定要虚心接受,从经验和技术提的意见里面包含着他们的抱负。梦想不能轻易践踏对吧?这个时候矛盾解决方法就三个字“讲道理”。这是一句很难做到的废话。很多时候我们听到的话是这样的:“我觉得就应该这样。”“你不懂,这样做没问题的。”或者,讲了道理没讲清楚。很不幸,我属于后者。我的体会是,光有道理也是不全的,你得让对方明白理解。强行要求,就是下命令了,可实际我们是平等的。好消息是,产品型程序一般都很愿意听道理的。
当然,自己的问题得虚心改,对吗?
技术型程序比较难处了。这对产品评估功能开发周期的经验要求很高,技术型程序的代码洁癖或者惰性很难搞定的。只能说功夫在平时,好好相处,搞好关系吧,人情这个东西很怪。
6.每个人都有自己的方法论,我们在模仿别人。就像创业一样,真正给社会带来价值的没多少。我们在学习,在模仿别人的规则,学到最后发现精髓都是“潜规则”。
7.产品人的责任是什么了?对产品的责任心是基本的,这会让你关心运营,关心代码等等问题。得适度,别越俎代庖。我有个坏习惯,一旦出现问题了,我会从历史发生的过程去寻找解释。最近发现这样做,其实意义不大。比起真相,更好的做法其实是先承担责任,为自己错误的买单,挺幸运的,趁还年轻。
前者是解决问题,后者是成长,并承担更大的责任。做到后面,你才真正成长了。
8.如果公司是一辆赛车,你越靠近发动机,你能犯的错就越少,就这么简单。
9.再说一次结论:功能不能改也是瞎扯淡。
10.标题里面的角色之间互换,同理可解。
爱因斯坦的鞋很调皮,设计也应该偶尔调皮。