从你的描述中，可能心中有很大不愉快，这会影响你的判断和工作效率。趁中午午休时间简单聊一下：
1、你的岗位和你现在说的工作问题不矛盾，是你职责所在，份内的工作而已，这没抱怨的必要。我们公司技术部门也会出现这样的问题，一个BUG，要连续加班几晚上，不停修改。这是你这个岗位的工作性质决定的。
2、你现在面临的是无法完成工作，中途接手，不熟悉，心里烦躁，这个可以理解。但入职一周了，还没了解自己公司开发的一个游戏逻辑，这有点说不过去，再怎么忙，熟悉了解的这个过程所需的时间总有的吧。
3、找不到问题，就虚心请教，向前面的同事向其他高手求教，三人行必有我师，这个应该不难吧？
4、摊牌，，，，，这个太过激了。
或许是你的一时气话吧，但很不恰当！说严重点就是不负责任！在我的理解中，工作中发生问题一点都不可怕，完全可以坦然面对。难以接受的是问题发生了，没有穷尽人力没有千方百计的去设法解决它，而是投降，撂挑子或不干了，，，，这真的是职场大忌！
不要灰心也不要意气用事，谁还没遇到过麻烦事吗？
端正态度 然后 去执行！
就这么简单！
与你共勉。
希望对你有所帮助。 来自职Q用户：邢先生
新官上任三把火，新员工入职三个困难，这是第一个吧？降临一个艰巨的任务在你的头上，公司的陈旧问题希望得到解决，这是老板的期望！先别急着投降，也先别摊牌，认真思考一下问题在哪里，评估同事和你个人有没有这样的能力能力，带上一两套方案，跟老板商量这件事怎么解决~《白日梦想家》主角米提华特的经历说明，只要你尽全力，甚至突破自己，希望和机会总是会在最后出现的~ 来自职Q用户：匿名用户
最近跟客户谈的时候，经常会听到这样的话：&lduo你们美工不就是做图?除了做图还能干吗&rduo&lduo那样的图我随随便便花两三百块就能找人做出来&rduo 等等，而且客户在炫耀自己()实力的时候都会以&lduo我花了多少多少钱从某某大挖了个技术回来&rduo而不是&lduo我花了多少钱挖了个设计回来&rduo。 反正给我的感觉就是在大众眼里，程序的身价地位总是要比设计高。你做的图，别人也做得出来。 按理说做项目的时候，设计要做的工作量不比程序少多少，甚至为了个极致视觉效果挖空心思反反复复修改，结果出来的时候给别人印象也仅限于&rduo这图不错&lduo。 人艰不拆，说多了都是眼泪。虽然这些话早已习惯，但是我还是很矫情地想：我们做这行的也花心思花时间花精力做，为毛会这么卑贱。 对于设计师的地位，我说几点： 1. 设计师，由于其职业特性，更容易遭到外行人的随意评判。 虽然我们知道设计的大部分功夫(用研、思考、决策等)都在最终的图稿之外，然而最终给外人展示的，却通常只有外在的「皮」。 虽说从表象上看，「技术是里,视觉和交互是外」，然而事实上，「设计」对于产品价值的实现，以及塑造差异性、传递品牌价值等更高层面的要求是具有核心意义的。但设计终究是面向普通用户的工作，其最终的产出(不管是平面，还是用户界面)必然会直接面对用户。而他们中的绝大多数，只会对设计的直观表现作出感性的认识。在这种感性认识的影响下，人们很容易误以为设计的全部内容就是塑造他们所感知到的直观表现。这就造成了对于设计「谁都可以指指点点」的事实。 而人员不同。他们的工作主要是关于产品内部的技术细节，而这些技术细节对于普通人是不可见的，于是普通人自然也就无从评判这些内容。 这一点是由职业特性决定的、无法改变的事实，然而我认为这正是设计的魅力所在：我们为普通人服务，而普通人可能不理解我们。那么如何将我们认为好的、优美的东西在这些普通人中推行出去?这是一项非常有趣的挑战，它需要的不仅仅是设计师自身的技巧、美感和品位，还有对人、社会和文化的理解。 2. 设计师(包括美工)，由于行业门槛非常低，造成了过分平庸的现实，也造成了设计可替代、低价值的特性。 关于这点，需要强调的是，现在的设计师大部分是商业设计师，它们的一部分主要价值是为产品和带来收益。然而商业思维恰好又是现在设计师所欠缺的。事实上，由于种种原因，很有可能发生的事情是：商业设计师们不仅不会带来商业价值，还会增加成本。这也是其地位不高的原因之一。 3. 从产品的角度考虑，设计师(这里将产品设计师也归为设计师)决定了产品做的好不好，而人员决定了产品能不能做出来。 他们的关系就好似温饱之后思淫欲。对于那些连温饱都没法保证(连实现都没法保证)的产品，苛求它们去重视设计岂不是强人所难么? 依然从产品的角度考虑，对于那些不愁温饱的、成熟的产品，随着自身的发展，在对设计有了更高需求的同时，技术方面也会面临更大的挑战。而对于软件来讲，应对技术挑战，最具价值的资源依然是人才。而此时，技术依然是整个产品向前发展的基础保障。这也就决定了在很多时候，人员对整个产品的价值是高于设计师的。这是一个事实。 4. 整个社会的需求层次还不足以让设计师的工作获得足够的承认。 这点大家应该都深有体会，我就不废话了。 设计是有逻辑的，就如同程序员设置的变量一样，每个变量都应该有它存在的理由。所以设计师和程序员一样重要。但问题就出在： 1)程序的背后对于非程序员来说就是天书，没人会要程序员去解释(除了程序员们)。 出问题的时候，若是个不懂编程的上司，除了向程序员施加压力以外，只能暗自着急。不管出不出问题，这都捎带一种依赖的微妙关系。但若是设计，似乎谁都可以自信满满地扔几个鸡蛋烂番茄过去，因为，设计是直观的，长了眼睛就能看见，还都觉得自己看得懂。 2)设计从业人员大多有艺术背景。 艺术是对情绪的表达，艺术是天马行空的，而设计却产生于要求与限制。就如同程序员设置的变量一样，每个变量都应该有它存在的理由，若非如此，则是不够简洁不够巧妙(而只有同行才可知)。设计也是如此，如果你说不出这个按钮为什么用了蓝色，或者你觉得答案就是「我觉得就该是蓝色」，那么你不可能是客户眼中的好设计师。但我可以告诉你，很多时候设计没有什么黄金定律，真的就是「我觉得就该是这样」，但即使如此，就算你编，也得编出个理由来。客户付钱，不是来题名「无题」的艺术品的。 我不是说提问者，但那些常常被客户否定的设计师，是否想过，我们的作品都是出于我们的双手，包含了我们的理解，采用的是我们擅长的表达方式，我们是否考虑过什么是客户会喜欢的?什么是客户的顾客们易于接受的?若是全部算在设计计划之内，那么客户喜欢的方案，很抱歉，也许就是最艳俗的那个——再次抱歉，这是我们的工作。设计不是搞艺术，不是个人去参加比赛。 那么我们该如何让自己进步呢? 设计需要创意，程序员也需要创意，但即使是 out of the box thinking，巧妙的创意也是用来达到一个目标，一个可以写下来的，可以用额、利润、未来潜力来衡量的目标，甚至有可能是是直抵人心的一场场心理战。而漂亮的展示，我不认为是设计师最重要的能力。漂亮的展示，可以交给真正的艺术家——美工——来完成。 另外，要懂得沟通。比如，客户不明白为什么这里要放丑陋的二维码，你怎么解释二维码这东西?「扫一下就行」、「方便」、「直接」都不如「不用打字」这四个字直击科技小白的心。(这是沟通的例子，重复，是沟通的例子不是设计的例子!) --- 最后，对所有设计师的建议： 最核心的事，依然是提升自己能力。君不见也有程序员被称作码农，也有产品经理实际上是打杂工。唯有让自己成为一个各方面成熟的设计师，才能让设计职位的价值得以真正实现，进而获得尊重。 对于产品本身，从更多方面考虑。例如成本，例如场，例如产品需求，例如运营数据…… 考虑得尽可能全面，设计决策才会尽可能完整，方案也会更加成熟。 想要被人承认是设计师，那么自己就需要先成为设计师。美工们津津乐道的 pixel-perfect 是应该的，然而对于设计师来讲，这还不够。在技法、细节上辛勤劳作是很好的，然而对于设计师而言，更重要的应该是思考。 最后，一个不太「正确」的事实：很多抱怨设计师地位不高的人，其实并不能被称作「设计师」。产品汪和程序猿
一、产品经理和程序员最讨厌的三句话
产品经理和程序员,就像一对情人，若即若离，有时还会撕逼，和谐的时候一切都好，撕逼的时候两败俱伤。
你知道程序员最讨厌的三句话是什么吗？
1、这个需求很简单，改一下就好了
2、你先大概弄一个，我看看再说
3、我先下班了，加油啊
我想任何一个程序员听到这样的话都会气炸了，不撕逼才怪，你作为程序员会如何回答这三句话？
1、这个需求很简单？你行你来啊！
2、大概先弄一个？请问先生（女士），什么叫大概？
3、你大爷的
你知道产品经理最讨厌的三句话是什么吗？
1、这个需求做不了
2、这个需求工作量太大了，估计要搞3个月
3、这个变更没时间做，往后排吧
产品经理在前端，有用户、有老板、有销售，版本发布的压力很大，听到这样的话估计心情也好不了哪去？
1、这个需求做不了？又不是我提的，还不是那个2B用户提的
2、要做这么长时间？养你们有什么用，还不如我自己来
3、变更没时间搞？随便，等老板来拍你吧。
二、产品经理和程序员本质上的差异是什么
奶爸干过程序员，也干过项产品经理，深知这两类工作的差异，各有各的不易。
总体上来看，做产品更侧重于创造和方案能力，不需要精密的逻辑，所以试错成本相对比较低，大不了改改原型，改改方案，这个成本是可承受的。
程序员的工作是非常精密的逻辑，一个看似很小的变更有可能对代码产生很大的影响，所以试错成本非常高，弄不好可能会因为需求的变化导致系统的重构，这时候程序员的挫败感是可想而知的。
三、产品经理和程序员友好相处的清单
1、产品经理收集需求后，在需求分析阶段，需要把一些不合理的需求尽量和用户沟通去掉，避免不合理需求造成产品发布时间延迟和没有必要的成本浪费，当然这需要产品经理去说服用户，不能只做用户的传声筒。
2、需求分析时，产品经理应该根据经验，敏锐的发现一些在技术层面实现有困难的需求，及时让研发介入，评估技术可行性，避免后续出现需求定下来，研发说做不了的情况。
当然这需要我们的产品经理对软件技术架构有一定了解和预判能力，你不能所有的需求都要在需求分析阶段让研发介入，这个成本也是极高的，所以要把握好这个度也是一项能力。
3、原型还是需求沟通的最好方式，这样是避免产品和研发在需求理解上有差异的最好手段，只靠写一些文字的需求说明书很难达到好的效果。
但这里面要注意一点，产品经理绘制出来的原型一般是非高保真原型，是为了更好的沟通需要，所以不能完全按照原型做，需要基于我们自己的前台架构进行定制。
4、需求评审的时候，研发可能会有一些不一样的意见，他们做了很多年的开发，会有很多好的经验，好的经验要虚心接受，不能觉得自己是产品就是老大，就是要按我说的做，这样很容易造成矛盾，求同存异，目标一致，这个是最好的结果。
5、研发说这个需求做不了的时候，有两种情况，一个是觉得这个需求实现起来比较麻烦，故意骗你；另外一种情况就是他的知识盲区，他可能确实不知道这个事能做。
产品经理需要有能力和研发进行谈判，比如采用类比法（类似的需求在其它项目上咱们就做过），比如去找架构师探讨技术可行性。
6、研发有时候评估的工作量会比较大，整个上线计划拉的比较长，产品经理可以要求研发出详细的资源配置清单，这样能清楚的看到一个需求被分解成了多少个研发任务，每个任务的起止时间，由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理？工作量是否合理等。
产品经理绝不能说，这么简单怎么要搞这么长时间，类似的话一出，绝对会激怒对方，还是要有理有据进行谈判。
如果实在无法压缩工作量，如果增加人力能解决问题的话，可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。
7、在版本计划定好的情况，尽量不加需求，这样很容易打乱开发的节奏，如果一定要加进来，一定要和研发说清楚，这个是用户领导或者老板的强制要求，转移矛盾。如果可以的话，增加了需求尽量推迟上线计划。
8、开发过程中如果需求有改动，需要及时更新需求文档，同时发给我们的研发同学，否则只是靠嘴说一下，很可能研发的同事就不做了，所以一定要落到纸面上。
9、上线的时候要坚持和研发同事一起加班，这样大家才是一个团队，赢了一起狂，输了一起扛。
10、最后一点，就是要多交流，没有什么问题是一顿火锅解决不了的，大家关系好了，很多事情沟通起来自然容易，而且也会更信任对方，这样就万事OK了。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）