2010年1月9日 的存档

• 前端开发流程浅析

  日期：2010.01.09 | 分类：前端技术 | 评论数：0

  流程，通俗来讲，就是许多人，在做一系列的事情时，怎样相互协调，安排好这一系列事情的先后顺序，有什么事先的约定，需要达到怎样的预期目标。

  在UED里，前端同学需要处理的需求比较多，早些时候，前端这里的开发流程还是比较模糊的，UED以外的同学也不清楚这边的工作具体是怎样进行的，所以难免会有需求插队的情况发生，打乱了大家的计划，因此今年Q3的时候，在与SCM团队同学的共同努力下，形成了一个前端的ASSETS发布流程。

  这个流程主要针对ASSETS发布的需求做了一些约定，制定了相关的几个时间点，包括审核需求、提交代码、daily测试、预发测试、正式发布到线上确认的时间。

  ASSETS流程简述

  需求审核

  在提需求之前，需求方一般都会先找PM或者相应产品线的前端咨询一下，如果可行的话就会在周四之前将需求提到平台上，到了周四的时候，前端会结合自身的工作情况，将平台上的需求接收并纳入自己的日程中，预估完成时间、发布时间以及相关的发布简述。

  编码开发

  周四需求评估完以后，就会按计划开始处理需求，将涉及ASSETS发布的需求优先处理，不涉及ASSETS的放在靠后的时间处理，一般这段时间是从周四到下一周的周二。SCM会在每周四开一个新的ASSETS分枝供前端在下一周开发使用。

  提交代码，合并到daily测试以及预发测试

  如果有涉及到与后台开发相关的需求，前端的同学会在周一就把代码提交，这一天会有一次合并代码，方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交，在周二，会有多次合并代码到daily的操作，每次操作完后，SCM的同学会在前端的群里通知到大家，方便大家测试。

  周三早上，SCM的同学会将代码发布到预发环境，此时就可以在HOST中绑定IP，换用线上的地址来测试。

  正式发布

  周四上午，SCM的同学确认后，将没有问题的代码发布上线。

  流程的作用

  在团队不断成长的过程中，处理的需求数量也在增长，需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素，这个流程能为我们解决很多相关的问题：

  督促需求方做好相关的规划

  有些时候，一些需求的细节还没完全确定，但需求方总希望能将他想到的各种细节都实现出来，然后再挑选其中一种做为他的方案，所以需求的变更会有些频繁，然而这样的成本有些高，一切应该在计划后再去实现，而非反其道而行。现在需求方会在提需求之前，会花时间地去考虑他们的需求，将尽可能多的情况都想清楚，做好必要的沟通工作，权衡各种利弊之后，再给出一个比较成形的方案。

  保证需求安排的有序性

  在一个大的团队中，不同部门的同学在一起合作，因为沟通及一些特殊情况，效率或多或少会受到一些影响，良好的规划能有助于提高开发的效率。

  通过每周的需求审核，安排好下一周的日程，由于需求的优先级和先后顺序都已排定，工作的条理性会更加清晰，需求插队的现象也有明显减少。当然我们也有紧急流程，但是它仅限于处理线上bug以及一些经过多方确认的紧急需求，有其自己的适用范围。

  统一测试，归避风险

  之前的日常处理中，可能会遇到这样的情况：甲、乙两个同学分别需要处理两个日常需求，他们的需要改动到的代码会有重合的部分，如果他们并不知道这个情况，那么在他们本地的单独测试中，一切都是OK的，然而当发布到线上去时，发现出了bug或者一方的改动没有同步到线上，查原因后发现是提交的代码相互覆盖了。

  现在要处理的需求数量越来越多，为了避免上述情况，新流程实行以后，大家会统一来做多次测试，这样就更容易发现bug，可以大大降低协作开发而产生的风险。

  流程本身就是一把双刃剑，有利有弊。一方面，它使我们的需求变得有序，使前端能够在处理一个需求时，不会频繁被其他插队的需求打断。并且因为发布有时间点的设定，所以测试工作会更加严谨，这有助于提升代码的质量。因此对于我们来讲，流程带来的好处是显而易见的；但另一方面，它额外地增加了做事的成本，涉及ASSETS发布的需求，就像赶某班火车一样，错过了就只能等下一班，所以也给需求方带来了许多不便，有待改进，不过这可以通过长期的合作而慢慢被弱化，双方达成了一种默契以后，情况会好很多，现在这样的情况已经比较少了。

  尽管在流程使用之初，会带来诸多不便，但是从长远来看，流程有助于使一个团队形成统一的工作方式和态度，将繁杂的事情化整为零，有条理地去处理它们。因为流程，每一个人的责任感都会增强，对风险考虑得会更多一些，这一切都会使产品有质的提升。而我们所有与这个流程有关的人，都会不断地去推动流程改进的工作，这其中还有很多需要思考的：

  * 如何将我们的流程推广到整个公司，让大家都能了解我们的流程，这样在未来需要合作时，需求方需要注意些什么，相关的时间点以及开周时间的预估等，他们就会心中有数。
  * ASSETS的发布还不够灵活，如果把和应用相关的ASSETS独立划分出去与应用一起发布，这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程，根据实际情况来发布。
  * 如何来简化流程上的一些细节，在保持效率的同时，降低实际操作中的成本。
  * 每周二是一个特别的时间点，为了赶在这最后时间提交代码，之前的开发会有些紧张，这种情况也有待改善，比如未来可以一周有两次发布。

  流程不是生来就完美，但从现在它带给我们的好处来看，遵循并使用它，对我们的开发会起到很大的帮助作用。我们对待它的态度，决定了它对我们会有怎样的反馈，如果觉得它不合适了，就发出自己的声音，想办法去改进它，不要只是被动地等待。

  ———————————-

  部分名词解释：

  daily环境：UED的一个日常测试环境
  预发环境：外网IP，需绑定访问，供内部使用测试
  ASSETS：脚本和样式存放的目录
  SCM：软件管理配置
  PM：项目经理

• 如何运营出好的互联网产品？

  日期：2010.01.09 | 分类：互联网 | 评论数：0

  我从事互联网已有一年多了，做了、看了很多的互联网产品，最多的是网站，各种类型的网站。然而随着互联网的发展越来越明显，想要在互联网领域创业的人越来越多，但究竟怎样才能打造出成功的互联网产品，一直存在着理解的误区，也困扰着很多创业者。

  从我个人多年的实践中，我认为互联网产品有几个容易被忽视的特点：

  第一，互联网产品要有一个灵魂，要符合相关领域的游戏规则，能打动用户的心。如果这一点没做好，产品外观做得再华丽，后台再强大，也很难成功。打动用户的心，这好像是废话，但也最质朴，很多产品其实不是在真正满足用户需求，而是在发明或幻想用户需求，甚至逆着用户需求在做。像国内很多SNS网站都模仿Facebook，尽管很像，但都不太成功，而开心网摸对了用户的脉，中国互联网用户上SNS实际是以开心、娱乐为主，简单、容易上手、好玩的小游戏就打动了用户。

  第二，互联网产品需要不断运营、持续打磨，好产品是运营出来的，不是开发出来的。而传统的软硬件产品都有个物化的载体，不可能经常改，比较稳定。互联网产品的本质是服务，就是通过某种形式的桥梁和窗口把服务传递给用户，由于用户的需求不断在变，产品就要随时调整。早些年微软的Windows XP比较成功，因为在传统软件时代，用户需求不多，厂商很容易能了解到；到了互联网时代，闭门造车出来的Vista就不可避免的失败，用户需求变化太快了，厂商对此没有把握。

  产品一定是让人去用的，不断根据用户反馈去修正。现在很多人都在讲“以用户和市场为中心”，但实际上还是“以公司为中心”。我曾经看过一家大公司的内部报告，说要做一个IM产品打败腾讯，说可以为自身带来什么价值，可以整合内部产品等，但从头到尾没有涉及能为用户创造何种价值。这种出发点必然决定失败的结局。

  我认为自己做客户端的资历比马化腾要深，但如果真的做一个IM产品，在产品细节和技术上可能比他做得好，但很难比他成功。我们俩的背景不一样，我做传统软件出身，而腾讯的创业团队是从做传呼的润迅出来的，之前就在做服务，这一点给了马化腾很大的帮助。这是一个分水岭，马化腾很早就掌握了互联网产品的规律，把它当成服务来做，持续改进。

  无论你的想法高明与否，我认为都不如用户的选择高明。有了任何想法，不要奢望做到完美再推向市场，不如先简单地做出一点点，就拿到市场上做实验，一旦对了就迅速跟进，一旦不对调整的成本也很低。把用户作为试金石，集小胜为大胜。

  从前面两点可以推出第三个特点，大家都说产品要做到专注和极致，对于互联网产品我感觉是“伤其十指，不如断其一指”。在产品方向上，一定要先学会做减法，而不是做加法。要先找对一个点做到极致，否则你什么功能都做，最后都不突出，没有鲜明的卖点。

  如果你掌握了互联网产品的规律，可能你不用太多的人力，只要瞄准用户的需求点，同时在技术开发方面，采用“小步快跑，循序渐进，不断试错”的思路，我觉得就有可能会超过大公司。