<meta charset="utf-8">

<title>豪情 › 做为一个前端工程师，是往node方面转，还是往php方面转</title>

<meta name="author" content="豪情">

<meta name="description" content="文章背景，来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。文章版权属于群内发过言的任何一位同学，我只是做了简单的梳理或整理。

技术人员了解产品这个岗位所需要做的事情，然后试着从产品的角度出发，考虑当前页面功能的真实需求，挖掘更深层的可扩展需求，从而在另一个方面去引导产品。比如：一个注册页面，">

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">

<meta property="og:title" content="做为一个前端工程师，是往node方面转，还是往php方面转"/>

<meta property="og:site_name" content="豪情"/>

<meta property="og:image" content="undefined"/>

<link href="/favicon.png" rel="icon">

<link rel="alternate" href="/atom.xml" title="豪情" type="application/atom+xml">

<link rel="stylesheet" href="/css/style.css" media="screen" type="text/css">

<header id="header"><div class="meta inner">

<h1><a href="/">豪情</a></h1>

<h2 id="header-h2"></h2>

<nav id="main-nav">

<ul>

<li><a href="/">首页</a></li>

<li><a href="/archives">文章归档</a></li>

<li><a href="/links">友情链接</a></li>

<li><a href="/about">关于</a></li>

</ul>

<div class="clearfix"></div>

</nav>

<div class="clearfix"></div>

<div id="content" class="inner">

<div id="main-col" class="alignleft"><div id="wrapper"><article class="post">

<div class="post-content">

<header>

<h1 class="title">做为一个前端工程师，是往node方面转，还是往php方面转</h1>

<time datetime="2014-05-02T02:15:02.000Z">May 2 2014</time>

</header>

<div class="entry">

<p>文章背景，来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。文章版权属于群内发过言的任何一位同学，我只是做了简单的梳理或整理。</p>

<li><p>技术人员了解产品这个岗位所需要做的事情，然后试着从产品的角度出发，考虑当前页面功能的真实需求，挖掘更深层的可扩展需求，从而在另一个方面去引导产品。<br>比如：一个注册页面，当前产品想到的是一个普通的用户注册，但是在整个的平台中，可能还有vip邀请注册，这时候可以试着想两个能不能合在一起，如果不能合在一起，就要分别处理。</p>

<li><p>有的公司没有专门的产品，则有项目经理兼任。但如果项目经理不懂技术，且在职权范围内有决策权，这个就比较难沟通。<br>这样可能导致的情况是：从产品看，提出的需求确实可以使用户体验更好，但是做起来就要很多时间，项目周期就要拉长。<br>这种问题，个人感觉：应该从全局考虑，做某个模块或栏目内容是充分的给项目经理讲清开发周期，所需要的人员配置，然后复杂的他就妥协了。<br>因为项目经理只是单纯的提了一个产品需求，他并不能充分的了解开发的周期，所需的人员，以及开发完，到测试回溯完的时间段。<br>一句话，他并不真正的清楚做这个需求的成本，了解这个成本之后，果断的妥协了。<br>他可以选择不信任，但要委婉的可以建议他找另外组相关人员重新评估这个时间。<br>这个环节最主要还是详细的沟通，耐心的站在对方的角度来考虑问题。<br>当然还有一种情况，如果双方都坚持自己的观点，不能妥协，这需要上报更高级别的上级，进行更高级别的评审。<br>简单说，需要老大来拍板，这时候问题就简单了，把球T出去。<br>乐观的估计，如果项目经理或产品觉得你说的有理他还是会接受的，首先要用自己的专业见解与产品沟通，达不成共识说明你的观点没有专业性。<br>当然这个建立在扎实的技术功底或丰富的行业经验上面。<br>最后一点建议：一个产品的立项到设计开发测试上线，其实周期是挺长的，乐观的自以为的压缩开发周期，<br>以为技术是简单的，以为平常看到的就是一个开发的结果，忽略了开发背后所做的种种劳动。<br>主观的认为开发是不耗时间的，然后就是时间还很紧张。这样就需要更多的技巧，更多的沟通策略来达到目标的一致。<br>这只是一种极端的情况，有的产品刚入行或没有经验，固执的以为，他代表着用户，假想自己是用户。<br>并没有真正的站在用户的角度，也没有在全局的角度来考虑问题，忽略了公司成本的重要性，以一个一项情愿达目的的想法做事，就会拖垮众人，<br>这时候如果没有一个真正的项目把控者出现，就会让项目走入误区。</p>

<li><p>不同公司不一样的，技术驱动还是产品驱动甚至商业驱动的公司氛围都不一样<br>产品驱动的公司产品非常强势，说啥就是啥，你说不行啊，按你那么做时间会很长的，他们笑眯眯得说没关系。然后某个周末leader问，产品现在什么进度？他们就开始添油加醋了。<br>这种情况个人的建议是所有的沟通要以会议的形式正式的沟通，会后有专门的一致邮件发给相关人员，并抄送给相关leader。<br>避免被动情况的产生。</p>

<li><p>产品上线后，后期的维护成本，新需求的产生，如何应对？<br>产品上线后，后续的维护同样重要，用户使用一段时间后，提出自己的想法。<br>这个时候就可以更新一个新的版本，把一些新的建议或想法加进去。<br>这就完全是拼经验的，改的多了，在写代码的时候就已经做好的预防修改的接口或代码容错性。<br>一般有个不成文的规定，就是写过的东西再写的时候时间缩减<br>一个产品/项目经理需求改的太多，然后开发人员一天备份一个，后果就是拖慢了开发周期，造到更高层的责备，然后开发悄悄的闪了。<br>然后在新补一个人进来的周期是1-3个月，对整个团队或产品造成了不可估量的损失。</p>

<li><p>老是在前端这个层面来修改东西，修改完了在去让领导抉择，选择。<br>其实这是一个真正流程上的失误，在产品出原型稿的时候，就需要评审一次。就算没有原型稿，在设计出高保真效果图的时候，再需要评审。<br>这样做的目的不就是早期把一些视角上的问题消化掉。<br>如果出现让前端修改效果来大面积的达到需求，这时候需要完整的设计效果图，否则后期没办法收尾。<br>这样也方便测试统一做回滚测试。<br>当然这需要灵活有一些简单的东西，可以直接吃掉。</p>

<p>最后总结收尾，引用自下面网址：<br>产品经理需要拥有很高的产品设计、用户体验感知能力，这里所说的产品设计和体验感知都必须围绕公司战略和产品方向进行展开，初级产品经理最容易犯的错误是把太多的时间抠在产品的设计细节上。说具体些，就是把产品的交互设计和UI设计看的太重，几乎大部分的时间都花在axure原型图的设计上了，而忽视了理解钻研公司战略、产品方向、以及产品本身应该重点考虑的地方。<br>在很多产品相关的网站和博客，你会发现讨论和分享的绝大多数都是围绕体验和交互设计相关的内容，这个怪像容易让初级产品经理陷入泥潭，会造成产品整体感觉丧失。产品经理需要具备产品的整体嗅觉，需要具备站在高度对产品有全局的把握能力，任何不站在整体生态、产品方向和公司战略下讨论体验设计都是耍流氓。</p>

<p>这段话个人认为引用的这段很是经典，分享给诸位，消化一下，说的很实在。<br>链接在这：<a href="http://www.zhihu.com/question/25657351" target="_blank" rel="external">http://www.zhihu.com/question/25657351</a></p>

</div>

<footer>

<div class="alignleft">

</div>

<div class="clearfix"></div>

</footer>

</div>

<section id="comment">

<div class="clearfix"></div>

</div>

<footer id="footer"><div class="inner"><div class="alignleft">

<p>

&copy; 2014 豪情

</p>

<p>

Theme By <a href="http://jiabin.tk" >Byron</a> based on <a href="https://github.com/willerce/hexo-theme-noderce" >Noderce</a>

</p>

<div class="clearfix"></div></div></footer>

<script type="text/javascript">

<article class="post">

<div class="post-content">

<header>

<h1 class="title"><a href="/2014/05/02/3/">做为一个前端工程师，是往node方面转，还是往php方面转</a></h1>

<time datetime="2014-05-02T02:15:02.000Z">May 2 2014</time>

</header>

<div class="entry">

<p>文章背景，来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动。文章版权属于群内发过言的任何一位同学，我只是做了简单的梳理或整理。</p>

<li><p>技术人员了解产品这个岗位所需要做的事情，然后试着从产品的角度出发，考虑当前页面功能的真实需求，挖掘更深层的可扩展需求，从而在另一个方面去引导产品。<br>比如：一个注册页面，当前产品想到的是一个普通的用户注册，但是在整个的平台中，可能还有vip邀请注册，这时候可以试着想两个能不能合在一起，如果不能合在一起，就要分别处理。</p>

<li><p>有的公司没有专门的产品，则有项目经理兼任。但如果项目经理不懂技术，且在职权范围内有决策权，这个就比较难沟通。<br>这样可能导致的情况是：从产品看，提出的需求确实可以使用户体验更好，但是做起来就要很多时间，项目周期就要拉长。<br>这种问题，个人感觉：应该从全局考虑，做某个模块或栏目内容是充分的给项目经理讲清开发周期，所需要的人员配置，然后复杂的他就妥协了。<br>因为项目经理只是单纯的提了一个产品需求，他并不能充分的了解开发的周期，所需的人员，以及开发完，到测试回溯完的时间段。<br>一句话，他并不真正的清楚做这个需求的成本，了解这个成本之后，果断的妥协了。<br>他可以选择不信任，但要委婉的可以建议他找另外组相关人员重新评估这个时间。<br>这个环节最主要还是详细的沟通，耐心的站在对方的角度来考虑问题。<br>当然还有一种情况，如果双方都坚持自己的观点，不能妥协，这需要上报更高级别的上级，进行更高级别的评审。<br>简单说，需要老大来拍板，这时候问题就简单了，把球T出去。<br>乐观的估计，如果项目经理或产品觉得你说的有理他还是会接受的，首先要用自己的专业见解与产品沟通，达不成共识说明你的观点没有专业性。<br>当然这个建立在扎实的技术功底或丰富的行业经验上面。<br>最后一点建议：一个产品的立项到设计开发测试上线，其实周期是挺长的，乐观的自以为的压缩开发周期，<br>以为技术是简单的，以为平常看到的就是一个开发的结果，忽略了开发背后所做的种种劳动。<br>主观的认为开发是不耗时间的，然后就是时间还很紧张。这样就需要更多的技巧，更多的沟通策略来达到目标的一致。<br>这只是一种极端的情况，有的产品刚入行或没有经验，固执的以为，他代表着用户，假想自己是用户。<br>并没有真正的站在用户的角度，也没有在全局的角度来考虑问题，忽略了公司成本的重要性，以一个一项情愿达目的的想法做事，就会拖垮众人，<br>这时候如果没有一个真正的项目把控者出现，就会让项目走入误区。</p>

<li><p>不同公司不一样的，技术驱动还是产品驱动甚至商业驱动的公司氛围都不一样<br>产品驱动的公司产品非常强势，说啥就是啥，你说不行啊，按你那么做时间会很长的，他们笑眯眯得说没关系。然后某个周末leader问，产品现在什么进度？他们就开始添油加醋了。<br>这种情况个人的建议是所有的沟通要以会议的形式正式的沟通，会后有专门的一致邮件发给相关人员，并抄送给相关leader。<br>避免被动情况的产生。</p>

<li><p>产品上线后，后期的维护成本，新需求的产生，如何应对？<br>产品上线后，后续的维护同样重要，用户使用一段时间后，提出自己的想法。<br>这个时候就可以更新一个新的版本，把一些新的建议或想法加进去。<br>这就完全是拼经验的，改的多了，在写代码的时候就已经做好的预防修改的接口或代码容错性。<br>一般有个不成文的规定，就是写过的东西再写的时候时间缩减<br>一个产品/项目经理需求改的太多，然后开发人员一天备份一个，后果就是拖慢了开发周期，造到更高层的责备，然后开发悄悄的闪了。<br>然后在新补一个人进来的周期是1-3个月，对整个团队或产品造成了不可估量的损失。</p>

<li><p>老是在前端这个层面来修改东西，修改完了在去让领导抉择，选择。<br>其实这是一个真正流程上的失误，在产品出原型稿的时候，就需要评审一次。就算没有原型稿，在设计出高保真效果图的时候，再需要评审。<br>这样做的目的不就是早期把一些视角上的问题消化掉。<br>如果出现让前端修改效果来大面积的达到需求，这时候需要完整的设计效果图，否则后期没办法收尾。<br>这样也方便测试统一做回滚测试。<br>当然这需要灵活有一些简单的东西，可以直接吃掉。</p>

<p>最后总结收尾，引用自下面网址：<br>产品经理需要拥有很高的产品设计、用户体验感知能力，这里所说的产品设计和体验感知都必须围绕公司战略和产品方向进行展开，初级产品经理最容易犯的错误是把太多的时间抠在产品的设计细节上。说具体些，就是把产品的交互设计和UI设计看的太重，几乎大部分的时间都花在axure原型图的设计上了，而忽视了理解钻研公司战略、产品方向、以及产品本身应该重点考虑的地方。<br>在很多产品相关的网站和博客，你会发现讨论和分享的绝大多数都是围绕体验和交互设计相关的内容，这个怪像容易让初级产品经理陷入泥潭，会造成产品整体感觉丧失。产品经理需要具备产品的整体嗅觉，需要具备站在高度对产品有全局的把握能力，任何不站在整体生态、产品方向和公司战略下讨论体验设计都是耍流氓。</p>

<p>这段话个人认为引用的这段很是经典，分享给诸位，消化一下，说的很实在。<br>链接在这：<a href="http://www.zhihu.com/question/25657351" target="_blank" rel="external">http://www.zhihu.com/question/25657351</a></p>

</div>

</div>