博客园_songtitan

在Android模拟器上安装和卸载APK包

2011-07-05T06:05:00Z

在Android模拟器上安装和卸载APK包
【安装APK】
    安装APK当然首先是要有模拟器，和要安装的APK包。
首先，将模拟器执行起来，直到正式进入系统。
    接下来，打开一个cmd窗口，路径切换到模拟器目录下的tools目录。
    输入：adb install 你要安装的apk文件的路径。
如果看到一行类显示传输速度的文字，那说明安装成功了。如下：
    C:/Documents and Settings/Administrator>cd D:/andriod/tools
C:/Documents and Settings/Administrator>d:
D:/android/tools>adb install c:/NetScramble_1.1.apk 100 KB/s (0 bytes in 164464.001s)
回到Android模拟器的界面，我本来以为可以看到刚刚安装的APK程序图标，结果，却根本没有...后来研究了一下，发现这根APK包自身有关。使用自己编写的HelloAndroid安装，图标就可以显示在桌面上，而NetScramble_1.1.apk安装后却显示不出来。具体原因是来自于 AndroidManifest.xml文件的内容。
view plain print ?
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android "  package="net.xiashou.android">
    <application android:icon="@drawable/icon">
    <activity android:name=".HelloAndroid" android:label="@string/app_name">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
       </intent-filter>
    </activity>
    </application>
</manifest>
xml文件中，红色一行是表示这个apk属于哪个归类里，如果不正确的填写这个信息，Launcher将不会将其显示在桌面上，因为它会认为这个应用部署以自己的归类。
那么，是不是我们就无法执行缺失了category的apk了呢？
后来，在一个老外的blog上，查到了方法：在shell内使用am来加载android应用
view plain print ?
usage: am [start|instrument]
       am start [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>] [-c <CATEGORY> [-c <CATEGORY>] ...]
                [-e <EXTRA_KEY> <EXTRA_VALUE> [-e <EXTRA_KEY> <EXTRA_VALUE> ...] [-n <COMPONENT>] [-D] [<URI>]
       am instrument [-e <ARG_NAME> <ARG_VALUE>] [-p <PROF_FILE>] [-w] <COMPONENT>
比如启动一个manifest为如下内容的apk
view plain print ?
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android " package="net.xiashou.android">
     <application android:icon="@drawable/icon">
     <activity android:name=".HelloAndroid" android:label="@string/app_name">
          <intent-filter>
              <action android:name="android.intent.action.MAIN" />
              <category android:name="android.intent.category.LAUNCHER" />
          </intent-filter>
    </activity>
    </application>
</manifest>
使用的指令为：
am start -n net.xiashou.android/net.xiashou.android.HelloAndroid
还有一些很有用处的用法
    直接启动浏览器打开一个网址 # am start -a android.intent.action.VIEW -d http://snowyrock.spaces.live.com
拨打电话 # am start -a android.intent.action.CALL -d tel:10086 启动google map直接定位在天津 # am start -a android.intent.action.VIEW geo:0,0?q=tianjin
am很可能将来成为第三方lancher的基础。
【卸装APK】
与安装类似的，卸妆是利用adb执行一个卸妆指令：
D:/android/tools>adb shell rm data/app/NetScramble_1.1.apk
这里，也可以看出，Android系统是将第三方应用放在data/app目录内的。
本文链接

[ZZ]产品经理的核心价值

2011-07-05T03:47:00Z

在足球场有那么一群人，他们凶狠的拼抢不断的传球、他们思维敏捷视野开阔、因为处于兵家必争之地所以往往血溅当场、他们是球场上的发动机，控制着全场的节奏、他们调配团队的资源，把球精准的传送到最有机会的队友脚下，这群人就是中场核心，西班牙的中场核心，大师级人物—哈维。

在现今的互联网行业中也有这样一群人，他们被称为“产品经理”。

互联网并不像世界杯具有80年的历史，所以团队中的人员分工和定位相对模糊。特别是近几年才在互联网出现的产品经理这个工种，已经有越来越多的人参与到讨论产品经理的核心技能、核心职能、核心价值是什么的问题中来。

在此，仅和大家讨论一下产品经理的核心价值，我想，只要认清了自身的价值所在，其他的迎刃而解，或者根本无需解。不管黑猫白猫只要能抓到老鼠就是好猫，无论你用什么方法、无论你是否有职权。

用了大量的内容来把产品经理的核心价值一层一层的剥开。

首先，整理一下互联网中的产品生命周期都会经历哪几个阶段。

需求收集、设计规划、开发、上线、运营推广或者市场销售、在市场和运营过程中产生新的需求、新功能的设计规划、开发、上线…… 一直迭代下去。“产品经理往往需要贯穿在产品生命周期的这整个流程中。”这是现在很多产品经理的理想。

好的，我们继续往下剥。将产品的每个阶段逐个分解，看看产品经理在这个过程中所起的作用。这是很重要的一步，所以我会说的尽量详细。

一、需求分析

在这一步，很多的产品经理花大量的精力去承担文案撰写的角色，这是误区！因为还有更重要的事情需要产品经理在这个时候去做。

1、了解公司的战略目的

也许“战略”这个词有点冠冕堂皇，可是产品的未来与这一步息息相关，所以不妨提到这个高度来讲。以我的经验，互联网公司要推出一款产品的动机大致四种

A复制：看到市场上同类的产品比较成功，结合自身的资源觉得可以效仿。对于这类产品公司仅能看到眼前利益，远景不明朗，需要一边做一边调整，结果多数是大起大落。例如最近狂热的团购。

B干扰：商场如战场，很多企业会玩声东击西的策略，用一些无关痛痒的产品吸引竞争对手的注意，以欺骗或者干扰对手的注意力，掩护自己的核心业务平稳的发展。此类产品往往成为炮灰。

C打圆场：对于上市公司而言，为了给资本市场一个好看的答卷，经常会用一些莫名其妙的产品来滥竽充数，虽然对用户和行业没有任何意义，但是可以让股东和股民看到企业的产业链条是圆满的。此类产品多数是企业的纯消耗品，因为没有实际的盈利模式，所以都是其他产品在养着他，其结果是没有地位。

D战略性产品：很多互联网企业从大众市场纷纷开始进入细分市场，这就要求企业敢于创新，在创新的过程中往往伴随着很多改革，企业会从新定义市场、制定新的目标，推出新的产品，希望改变现有的盈利模式和业务框架、市场格局。这便有了所谓的战略性产品，例如腾讯的拍拍、百度的有啊、新浪的博客、阿里的支付宝，其中有的成功、有的还不明朗，这也正是此类产品的特性。创新和改革的路上异常艰难，很可能这个产品与现有的很多业务冲突、与现有的部门利益不协调。而且企业不会像中央政府那样搞十一五计划给你5年时间，也许你只有半年，所以这要求产品经理要具有很强的把控能力和坚强的毅力。

作为产品经理只有去了解这些才能预想到今后的工作中可能遇到的问题、可能争取到在资源、可能投入的精力、可能组建的团队规模、可能遇到的瓶颈和坎坷，未雨绸缪才成为可能。

所以，不建议一开始就埋头设计精美的PPT、华丽的demo，应该去了解公司做这个产品的目的和动机。

2、了解市场需求

这里也有个误区，很多产品经理通过所谓专业的分析方法例如swot和大量的百度搜出来的数据做出来一个东西，就算交差了。而很少去考虑为什么要去做市场分析，如果我们每天把很多时间花在应付那些不知道为什么做而做的事情上，将很容易被淘汰。

我认为的目的有三个

A、试探自己的思路与公司的思路是否有偏差，适当的在公司原有的想法上做扩展，加大公司对产品的兴趣。

B、给相关部门吹风，特别是业务团队和运营团队，他们手上正在卖或者正在推的产品可能有很多，你的产品市场优势在哪里？也许不能让他们马上兴奋起来，但是至少应该让他们关注或者积极的反馈意见。

C、自我梳理，写的过程就是想的过程，想的过程就是辩证的过程，很多思路会在写的过程中迸发出来。

所以，市场分析可以包含以下内容：产品对于行业的价值、在市场发展的环境下产品可能的生存空间、产品在市场价值链中所处的环节、预期的市场回报。

关于用户需求这里就不多说了，有很多这方面的文章。

到这里，需求分析阶段算是尾声了，总的来说，产品经理在这个阶段最大的意义就是给产品建立意识形态，有点类似军队出征前的誓师大会，虽然很虚，但是对将来的工作很有帮助。

二、设计规划阶段

在这个阶段，开始有越来越多实在的交付物出来，例如：产品规划方案、产品demo、需求文档等等。

1、产品规划方案

无论这个方案是不是由产品经理本人来做，产品经理都应该要求这个规划方案中说明白几个问题：

（为什么做）产品背景和需求说明
（做成怎样）功能说明
（如何实施）里程碑和时间计划
（回报）投入和产出比
（如何经营）运营策略
这是产品从虚到实一个很重要的过渡，把之前天花乱坠的产品思路通过这个方案告诉大家如何实现，并且是有计划有里程碑式的实施。

如果把产品经理比喻为一枚陀螺，这个方案BOSS拍板的一刹那将成为陀螺的分水岭，在这之前鞭子缠绕着陀螺在蓄力，拍板声一响鞭子猛的抽开，产品经理就开始疯狂的忙开了。

2、产品demo

有了需求，自然就有了功能，各种功能组合生产了功能模块，功能模块就搭建起一个产品的框架，在这个产品框架下有哪些系统提供支持，最终画出产品大概的样子。于是功能模块、产品框架、系统架构、低保真原形打包起来就生成了一个产品demo。

产品经理可以拿着产品demo去评审验证了。听取交互设计师的意见、听取视觉设计师的意见、听取前端工程师的意见、听取开发工程师的意见、听取业务和市场的意见、听取用户的意见，陀螺陀螺疯狂转吧！

如果你发现这群鸟人，之前鸦雀无声，现在忽然噼里啪啦的开始拍砖，不要觉得奇怪。眼见为实，大家只有看到你产品的样子才能发表各种意见，而且这些意见还多数是在抠细节。听取意见的过程中，产品经理不会忙于辩解，思维像陀螺似的转起来，意见是否采纳，更多的决定权还在于产品经理，所以你要能够识别各种意见的出发点。有的人会从专业角度、有的人会用改变功能实现方法减少自己的工作量、有的人会站的自身利益的角度、有的人会站在伪用户的角度。如果你应付不来，可以把大家的意见记下来，回去好好的考虑。如果一些问题非得会上就定结果，先明确轻重缓急，实在不行就中场休息借机场外求助。陀螺陀螺效率的转起来吧！

关于需求文档，这个就不用说了吧！

在这个阶段，产品经理除了协调各方，还应该想办法建立一种沟通机制，让团队高效的工作。在很多互联网企业，产品是没有独立团队的，都是线条式的贯彻在各部门。

三、开发阶段

这里的开发是广义的，包括UI设计、前端制作、程序编写、运维支持

这阶段提几个建议：

做设计和开发的都不是好惹的鸟，要么极具个性、要么孤傲、要么执拗。其实这和他们的工作性质有关，创意是需要时间和空间的，建议产品经理们能尽量的满足他们，也许时间是公司敲定的，但是一个良好的发挥空间还是可以提供的。在上面说的广义开发过程中，产品经理往往会遇到很多新的需求，要么是BOSS直接发话、要么是市场部门临时兴起、要么是产品经理自己遗漏。怎么办？要不要加进去？衡量一下吧，如果是影响到核心功能的可以加，如果是边缘化的东西建议放在第二版再加，否则有新的需求就加，这个产品很难在原定计划上线，而且干扰了开发人员的发挥空间，好不容易安下心来思考，又忽然来了新的需求要做，谁都不乐意的，何必呢？相互多一点理解，就少很多抱怨的。

人无完人，没有哪个产品经理能把产品的方方面面想到100%的程度，所以开发过程中，开发人员会有很多问题需要确认，这些问题需求文档里面被遗漏了，所以产品经理需要留有足够的时间给开发人员，如果自己很忙也需要安排一个专人负责协调。

此时沟通的事情占用产品经理的时间不多，所以可以开始花时间考虑产品相关的文案了，这部分我在之前的文章《构建完善的互联网产品文案体系》中有讲到。这个体系的内容如下：

产品上线之后再做就耽误了，也许这些文案不用产品经理本人来做，但是需要把你的想法和对产品的理解灌输给做事的人。不是所有产品都需要这些文案，相信大家能区分。

四、测试阶段

相信有很多互联网公司没有专门的测试团队（QA），甚至忽略了测试这个环节，所以更多是要求产品经理在短时间内协调分工来完成。问题就产生了，没有专业的团队所以测试的结果可能会有遗漏、测试的周期很短所以有的问题即使发现了也需要放到产品上线后解决，这些仍然需要产品经理来协调和分工。

不要抱怨了，把精力放在解决问题上。这里有几点建议：

A、让自己专业起来：在没有专业的测试队伍之前，产品经理就是最专业的测试人员，只有这样要求自己，上线的产品才能做到尽量完善。

产品的测试包含三个重要的环节—功能测试、性能测试、用户测试

功能测试的内容有很多，曾经在某集团任职的时候，公司推出一个SNS社区，其中测试用例一共7130个，QA部门至少需要测试7130个功能点。朋友们可能很疑惑，觉得怎么会有怎么多的功能点需要测试呢？这里截个图了解一下专业测试团队是怎样测试的，特别是对每个测试用例的描述。

虽然专业，但是仍然无法避免问题的出现，所以微软的团队也在不断的在给产品打补丁。提这个的用意在于，不要因为测试的问题成为产品发展的牵绊。作为产品经理仅需要在五个方面做功能测试就差不多了：

A功能流程：根据之前定义的功能模块，以模块为单位分担出去，分担给谁？部门总会有些机动的人，如果没有可以找前端或者UI，引导他们在测试样式和界面展现的时候以功能操作为前提。系统的流程就不多说了，一个功能从头到位走一遍。
B前端与数据库响应：在我们的影响中，一定能够找出数据存储量最大最频繁的功能点，例如个人空间的日志、相册、视频、签名、好友动态等等。测试的时候需要做的仅是操作界面发布看看前端页面是否及时响应，如果之前要求的是同步，测试的时候发现延迟5分钟，说明前端提出数据的时候出现问题。
C浏览器兼容：万恶的浏览器，没有更好的办法，一个一个测吧，可以交给前端开发去测，谁希望自己辛苦做出来的页面用户看到是变形的呢？
D系统规则和机制：在产品设计的过程中，会有很多的规则和机制穿插其中，例如排序规则、录入和显示的字段最大长度、用户的积分经验值等等。注册几个账号开始模拟用户的角色测试吧。
E模拟用户角色：这里的用户是虚拟的，我们只需要关注其是否能达到目的，暂不去考虑过程的体验。

性能的测试，需要产品经理预估一个用户的峰值，然后可以让开发人员去做评估，看看在这个可能的峰值下系统是否还能正常稳定的运行。

用户测试不细讲，网上有很多相关文章。

在一个月黑风高的深夜，产品上线了！有的人告一段落、有的人兜里揣着项目奖血拼去了、有的人休假旅游，唯独有一个人，产品上线对他来说仅仅只是开始，他需要从一个战场转移到另一个战场，这个人就是产品经理。

这里出现了第二个分水岭，有的产品经理会在这里停下，回头负责另一个新的产品。而对于另一部分产品经理来说，公司给他制定的KPI不仅仅只是产品上线，还可能是诸如用户量、活跃度、信息量、转化率、购买率、续费率等等被量化的数据。所以这也成为产品经理积极讨论的问题。因为产品经理被细分了

A、规划型产品经理：只负责产品前期的规划，然后把规划交给需求部门梳理，完事！这类产品经理表达能力很强，无论是语言还是文字图表。但是因为无法参与产品核心的设计，所以往往成为BOSS的代言人。

B、需求型产品经理：更多的负责收集和处理各方面的需求，并且从设计和开发角将讲需求转化为需求文档，完事！这类产品经理协调能力很强，往往能成为产品对外沟通的枢纽。但是因为没有深入到产品的业务和市场方面，所以在需求的权重排列上会很踌躇和痛苦，往往成为背黑锅的人。

C、设计型产品经理：更多的负责产品的可视化设计，例如产品demo、交互设计甚至是UI设计等等，完事！这类产品经理善于把握细节，而且思维活跃。但是往往因为太注重细节和完美，导致很多想法被强势的业务和市场团队压制，很多想法无法实现，非常痛苦和挫败。

D、市场型产品经理：主要负责产品在市场环境下的运作，承担了大量的市场指标。这类产品经理拥有很强的市场嗅觉，而且市场资源丰富，产品上线之后交付给他们打理。但是因为此类产品经理在前期很少参与产品的设计和规划，所以其对产品的理念以及卖点与产品初衷会有偏差，而且会出现利益为先的情况，影响到产品长远的发展。如果此类产品经理把控能力不强，很容易出现产品频繁的调整方向，最终被其他业务合并或者被公司搁置。

从产品经理的分类来看，要找到产品经理准确的定位和定义，并赋予其核心价值真的不是容易的事情，何况每个企业都有自身的特点和组织架构。

我们把思路拉回来。产品上线以后就到了第五个阶段

五：运营和市场销售

我经常把运营分为四大块内容：

A、产品包装：产品要面向市场，就需要做包装，例如建一个网上展台（产品专题）阿里的诚信通 263的企业邮箱腾讯儿童频道。除了这些还有宣传材料（宣传彩页、海报、易拉宝）和公关软文。

B、对外合作：包括推广合作、数据对接、功能整合、利益分配

C、公关推广：媒体互换、寻找G点（市场的兴奋点）

D、策划活动：会议营销、网民线下活动

以上这些工作，也许不需要产品经理本人去实施，但是必须产品经理提出来，并辅助具体实施的人完成。

不是所有产品都有市场销售行为，因为有的产品更多的是支持核心的业务发展，例如论坛、公司内部OA、统计系统、CMS系统等等，但是对于业务要往外出售的产品来说，市场销售这个环节产品经理至关重要，有很多事情值得做。

A、植入业务体系：很多企业的业务体系并非只销售你这一个产品，所以如果利益关系不处理好，很容易出现好产品没人卖的现象。例如：公司给销售员的考核时每月30万，也许你的产品定价5000而且属于年费，而销售员卖一个广告售价10万，那么对于他们来说要完成本月业绩是去强攻3个广告还是卖60个你的产品呢？答案很显然。所以产品经理必须努力的推动产品最终深入到业务体系中去，调整产品的提成也好，捆绑打包也罢，总之好产品是卖出来的，而绝非设计出来的。

B、协同作战：与业务体系一起，找出产品的卖点，包括产品销售过程中的一些话术、容易遇到的问题、客户对产品的兴奋点，都需要产品经理去发现，并且努力做到可复制性。

C、参与制定产品定价：产品的价格能不能根据不同的客户类型进行分档，分档的依据是什么？功能如何区别？

D、建立市场需求反馈通道：市场需求的反馈有通道么？畅通么？如何应对这些需求？是定期和销售员沟通还是参与市场行为？如何识别哪些是客户的需求、哪些是销售员从自身利益出发的需求？

陀螺陀螺转啊转！

对于产品经理的核心价值，在这个层面我们剥了很多内容，朋友们是否隐约感觉到了产品经理核心价值所在？如果还不能确定咱们继续剥。

说完了产品生命周期中的几个阶段，现在提一下产品经理在这个周期中所要沟通的对象，关于这方面我在《产品经理的前世今生》一文中有较详细的说明。这里仅用一个图来说明

蓝色的线条代表了产品经理需要沟通的对象。这也是产品经理核心价值的一部分。

现在咱们回顾一下，产品经理在产品的整个生命周期中其实就做两件事情。

第一件事情是“合”：表现为收集各方面的想法、需求、资源、工作内容和节点

第二件事情是“分”：产品可能涉及到的部门和角落通过产品经理这根导管精准顺畅的传输出去，传输的对象可以是各部门、市场、用户、合作伙伴等等

不要再纠结下面这张图了

本文链接

[ZZ]我理解的产品经理

2011-07-05T03:27:00Z

我理解的产品经理
本文，我从一个新手的角度去记录我所理解的产品经理是什么。仅代表个人观点，仅从一个没有UED支撑的从业者所思所想出发，肯定会有错误，欢迎批评探讨。
前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……
首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。
1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。
第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。
产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。
记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下
1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。
2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。
在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。
3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。
满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。
4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。
你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。
5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！
6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。
没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的
本文链接

【ZZ】产品经理如何推进团队执行力

2011-07-05T03:21:00Z

按，前天参与了一次Podcast的录音座谈节目，其中聊到如何推进团队的执行力，略有心得分享，整理以记之：

1、产品经理首要确定的工作原则：战略决策产品，产品驱动开发；

2、结合实际情况，设计可执行的工作流程，明确各职能环节的工作成果输出（原型/界面设计，需求文档/思维导图或流程图）；

P线：产品管理，产品设计，界面设计，交互设计，及其它
T线：项目管理，技术架构，技术Leader，开发人员（前端，页面，后端，服务端，数据端，运维等）

3、尽可能的明确可度量的工作成果标准，由P线经理提供需求要点纲要，表明要做到什么，不用做到什么，T线经理根据需求与相关人员共同设定工作目标和标准；

虚拟示例：某功能模块，进行V2版本优化，2周为一次迭代周期，共2个周期

需求要点是：功能性流程与V1版本相比无增加点，重点是实践前后端分离的开发模式重构该功能模块的实现代码，交付给用户更有惊艳效果的操作流程，强化每个操作环节的引导或提示体验

第一个周期的关键是：需求明确，各职能角色的充分交流

第1周目标是：P线成员完成产品细节需求策划，T线成员相关技术架构的预研
第2周目标是：需求策划完成交付，二个关键展示页面的技术功能性开发完成

第二个周期的关键是：保证质量，在进度内完成既定目标

第1周目标是：所有技术功能性开发完成，关键业务流程可以走通无误

第2周目标是：所有需求策划细节开发完成，重点是用验设计、界面设计无损实现

此产品开发组团队共4人：责任产品经理1人，技术骨干兼项目经理1人，相关技术开发人员2人；周边支撑资源：界面设计、、交互设计、页面制作，约6人/天

4、抓住一切机会点，在团队内告知及说明工作原则和流程标准的重要性，特别关注对老板的告知；

5、对于执行过程中的各职能环节协调问题，保持高度的敏感，最及时的处理此类问题；

6、对不同职能角色的沟通技巧，产品经理本身需要在思考上有相当的弹性来去适应不同的角色思维模式，老板，技术Leader、成员，界面设计、用户体验、前端开发、客户等

在和P线角色沟通时，要适当的讲解技术实现相关原理，能做为什么，不能做更要为什么，并在满足需求本质的前提基础上，提出妥协或更合理的解决方案；

在和T线角色沟通时，尽可能说明该功能需求的来源，用户反馈次数和态度，分析其合理性，以具体案例和模拟用例来推演出合理性；

虚拟实例：项目管理=》项目成员管理与授权功能=》产品提出需要可以增加部门为项目成员

已有功能流程：进入项目成员管理，可选择部门下拉框=》员工下拉框，点加入成员

产品的思路：选定部门后，即可直接将该部门加入项目成员，让项目经理操作减少，当部门员工离职后也无需再取消该员项目成员身份

技术的思路：该需求技术可行，需要涉及到的功能点有，项目成员管理界面可增加部门，部门绑定的权限角色被授权，3个其它功能模块中类似的人员选择区做同样的处理，约2-4人/日工作量。

我的分析：能理解该需求思路，选部门的出发点在于减少项目经理操作次数，这个能认同，但一个项目经理在此项目里选了部门为成员以后，如果该部门有人员增加而又正好不是参与该项目的，岂不是还要再回来把这个项目的成员里去掉这个部门，再加上原有的员工；其二，这个漏洞虽然很小，用户实际操作中碰到的几率很低，但既然我们提供出这个功能，就一定会有用户使用到出现问题，那岂不是违反了我们做这个修改的目的：改善用户操作，获取用户认可。须知，对于用户而言，我们做的更好是应该的，大部分用户未必感知到，感知到的用户也未必会传播；但如果我们做了一个会出某问题的产品，大部分没出现该问题的还是沉默状态，出现问题的就一定会进行传播反馈（抱怨不爽投诉。。。），影响到本来没此问题的用户群体了。

结论：需求决策的原则：产品环节对没有问题的解决方案进行判断或优先级选择时，可以按关注用户几率的多少来进行，但如果有问题的方案，就不能按用户关注几率来判断，哪怕只有百分之1的用户有可能出现问题，就是致命。该需求应该寻求其它解决方案。

我的方案：项目经理选择部门后，人员下拉框里第一项是“加入该部门所有员工”，产品认为可以满足需求的出发点，技术认为需要投入的工作量约0.5人/日，达成共识；

7、以合理的方式展现团队的各阶段工作成果，一则收集需求反馈，二则收获公司及客户的认可提升团队士气；

综上，主体的思路是：确定原则，明确战略，设定标准，统一思想，持续沟通，修炼技巧，展现成果。此次主要是对设定标准和沟通技巧分享两个例子，其它的环节有机会再谈谈。

本文链接

[转载]我在QQ邮箱的这四年

2011-07-05T03:11:00Z

恍惚间已经工作了四年有余，很幸运刚毕业就遇到一个很好的锻炼机会，05年7月份刚成立的腾讯广州研发中心，主要负责腾讯的邮箱业务，我是在06年2月份加入到这个团队，也算是见证了QQ邮箱的整段发展经历。有些记忆隔的太久，可能时间和细节上不太准确，尽量去回忆吧。

写这个系列的文章也是对自己过去四年工作的一次回顾和总结，我会结合自己的经历和感受来写，视角不会太开阔，用平铺直叙的方式吧，就像讲故事，我是一个没有太多故事但却喜欢讲故事的人：）

也许大家都听说过腾讯做邮箱的那段往事吧，创业团队太自信了，觉得把邮箱放到客户端上依赖QQ巨大的用户量自然就会成功，但是结果却恰恰相反，纠正错误认识，在04年紧急做了QQ邮箱的Web版，也就是QQMail 2.0版本，这个版本明显过于仓促，和网易等其他邮箱应用相比，差距很大。腾讯在05年中旬收购了Foxmail及其团队，成立了广州研发团队，主要负责QQ邮箱的开发和运营。很明显，公司非常重视邮件这一块，也基本承认了之前的判断错误，所以打算下大力气做好邮箱业务，这为之后QQ邮箱能够取得优异成绩奠定了政策基调。

在计算机软件领域，一款成功的产品背后一般都会有一个明星人物，QQ邮箱也不例外。QQ邮箱的这个关键人物大家应该也都知道，他就是Foxmail的作者张小龙。09年赖勇浩同学在一次技术交流中谈过他心目中的几个国内顶尖程序员和其成功的软件作品，有求伯君和WPS，有鲍岳桥和UCDOS3，有王江民和KV100，有梁肇新和超级解霸3，有张小龙和Foxmail，有侯延堂和FlashGet等等。小龙被认为是国内第二代程序员中的领军人物，他曾经是国内顶尖的程序员，然而他在QQ邮箱的整个发展过程中不是以技术人员的身份在指导，如果要用一个最合适的身份来形容他，我觉得是产品经理。小龙曾经在内部发表过一篇文章，这篇文章讲述了他对互联网团队管理的一些观点，他认为互联网团队中的管理不是管人，而是管理产品体验，以产品体验为核心，产品设计和开发人员与产品共同提升，共同进步。小龙之于QQ邮箱的影响正如乔布斯之于苹果的影响。

QQ邮箱3.0版应该是广研自主研发的第一款邮箱产品，2.3版是从总部继承过来的，3.0版的后台很多代码也是从2.3版继承过来的。3.0版的UI有点像Hotmail和Outlook的综合体，思路很明显，把邮件客户端做到Web上面，做一个富客户端的邮件应用服务。当时国内的邮件应用第一梯队是网易和雅虎中国（中国雅虎是之后的事情），第二梯队的是新浪、搜狐、tom在线、21cn等门户，第三梯队是一些独立的邮件服务商。当时大家经常上艾瑞网看排名，QQ邮箱当时排名在12左右，还进入不了前三梯队，市占率低到可以忽略。当时的目标是在一两年内进入第二梯队，我想，如果当时确定目标是超越网易成为国内第一，估计是没人相信的，包括我们自己。

3.0版是广研的处女作，投入了全部的人力物力，采用了当时业界最先进的技术方案和最好的UI设计，并且创新的采用Outlook的三栏结构，很像邮件客户端，这是一次软件服务化的尝试。

我是06年2月份加入广研，当时3.0已经渡过了最繁忙的开发阶段，进入了小范围的公测阶段，用户可以在2.3版和3.0版之间切换。3.0版的集中开发大概是半年多时间，05年中旬广研招兵买马的时候，大部分人没有邮箱产品的相关开发经验，当时是在摸索中前进。然而，当时的团队却采用了业界最先进的ajax技术架构，当时的javascript代码有很重的面向对象的味道，用传统的软件工程思想构建了整个Web框架，从软件的开发流程来说，这并没有什么问题，但是产品却有很大的问题出现了–慢，不是一般的慢，当时除了较快的电信网用户可以登陆进邮箱之外，其他的用户基本上都被卡在登陆上。06年的大部分时间，整个团队都在解决速度慢的问题，尝试了很多方法，把js容量压缩掉了一半，js混淆之后又压缩了很多，js文件分开为多个，但始终没有根本的转变，速度的提升仍然不能被用户接受。现在回过头分析这个问题，我觉得物理上的压缩和分割js文件之所以解决不了问题是因为问题的根本在于js的逻辑架构上，当时的js有明显的基类和继承类结构体系，这种结构并不适合物理上的分割，即使分割开，渲染消耗的时间是节省不下来的。

3.0版的后台基本上是继承的代码和开源代码的综合。最重要的邮件投递模块采用的是当时最好的投递引擎postfix，web端采用的是apache。邮件存储是简单的单文件存储方式，用户数据存储也是比较简单的，帐号和邮件列表是合并存储在一起的。这个架构对于支撑当时的用户规模是足够的。

06年之前广研在做QQ邮箱开发和运营的人数是比较少的，所以06年吸纳了不少的毕业生，我就是第一批广研接收毕业生中的一员，当时3.0版的主要开发人员集中在两个小组：QQMail小组和系统架构组，从名字上看，应该是QQMail小组负责产品层面的开发，系统架构组负责后台架构的研究和开发，不过我当时感觉两个组差别并不大，都是在做产品开发，都同时做前台后台，可能是人手紧张的缘故吧。QQMail小组除了做产品开发之外，还负责产品的运营工作，人数上稍微多一些。我加入的是QQMail小组，最初是以实习生身份参与到3.0的开发中，工作任务比较杂，写一些cgi，做一些内部系统和统计的工作，其余的大部分时间是在读代码，也就是上面提到的那些js代码，后台代码和cgi的代码。这近三个月时间是我有史以来精力最旺盛的一个阶段了，把所有的代码梳理了一次，写了好几本笔记，现在回忆起来觉得真是太不可思议了。

QQMail小组当时的组长是ted，系统架构组的组长是harvey，两位老大对我的影响都很大，我后来分别在两位老大麾下做了两年，从两位老大身上学到很多东西，他们也给了我很多锻炼的机会。

ted老大当时主要负责QQ邮箱的产品开发运营方面的管理，在我进组之后，当时的3.0已经过了集中开发阶段，开始进入优化阶段，对运营质量提出了更高的要求，当时整个QQ邮箱的运营只有一个粗糙的数据统计系统和一个nagios系统，数据的收集和统计的方法比较简单，cgi写日志然后收集起来之后再运用shell统计入库，甚至数据的页面表现也是shell做的。ted安排aoger为我的导师，我跟着aoger边熟悉系统边做一些数据统计方面的尝试，偶尔也会写一些产品cgi。aoger是一位相当有耐心的导师，尤其是面对我这种打破沙锅问到底类型的学生，aoger在最初给了我最多的帮助，没有aoger的帮助，我不太可能在3个月理清整个QQ邮箱的架构。aoger解答不了的问题，他会推荐更合适的同事给我，不过我比较取巧，遇到这种情况一般就去问ted老大了：）也正是在这些和ted老大的问答过程中，增加了彼此的了解，这为以后ted能够不失时机的给我最恰当的尝试机会奠定了基础，不过最重要的还是ted的信任。

跟着aoger先后做了运营监控系统和一些相关的统计系统之后，ted给了我第一个机会独立完成一个系统，那就是广研的业务数据系统，这个系统包括数据的收集、整理分析、报表展示和数据波动报警等功能，这个系统至今仍然在使用，后台架构也基本没有什么改变，我在做这个系统的过程中，熟练掌握了两门新的语言：shell和python，熟练的程度足够我运用任何一门语言做整一个系统。在shell编程方面，很感谢felix的帮助，在python方面，很感谢vincent的推荐和帮助。两位都是领域内的高手，对编程语言的运用驾轻就熟。shell帮我在数据收集的自动化方面做到炉火纯青，收集、纠错和报警一条龙，而且代码相当干净，值得反复阅读（请允许我陶醉一下）；python是一门我非常喜欢的编程语言，让我痴迷了2年，甚至在去年还阅读了一些剖析python源码的书籍，我主要用python做内部系统的表现网站，报表、图标、趋势图无所不能，而我最满意的是用python设计实现了一个轻量的模板语言，这个语言帮助我通过简单的配置就可以做出一个统计页面的表现和数据提取，非常方便，现在还有同事在使用这个模板语言，代码也是相当干净（我又陶醉了）。

一个合格的程序员不会满足于做重复的事情，虽然后续接了不少的内部系统开发，本来都是可以简单的拷贝前一个系统修改一下就了事的，不过我把每一个系统都做的不一样，每个系统都要有至少一个新亮点，ted后来觉得我有点过于埋醉于技术疏于组织方面的锻炼是有证据的。不过ted还是很信任我，陆续又让我参与到产品层面的开发中，这次我又几乎独立完成了QQ邮箱的自助服务系统，包括faq及其查询、最近登陆记录查询、最近收发信查询和最近删信查询等若干辅助用户查询的功能。这是我首次做后台服务，后来这个服务相当稳定，其后台就成为了发信状态查询的后台，现在仍然在运转着。也正是由于这个发信状态查询服务的成绩，小龙把我调到了架构组参与到阅读空间的开发中去，虽然那个服务是我自己认为做的最差的一个服务，但是却有很大的意义。这也验证了互联网开发是结果驱动而非过程驱动的一个实证。

虽然06年的我得到了很多的锻炼的机会，做出了一些成绩，但是QQ邮箱这个时候仍然徘徊在速度和功能的博弈中，当时公司内部在进行hummer计划，广研这边除了QQ邮箱之外，要另外做一个hummermail，架构组为此把后台的架构进行了一次彻底的重构，把用户数据存储模块做成了一个通用性更好的存储服务，事实证明，这个存储服务成为了广研最核心的一个服务，支撑着绝大多数体验的数据存储；把帐号信息独立出来做成一个新的帐号系统；由于新邮件提醒的重要性，特别为邮件提醒做了一套后台，实现实时稳定的邮件提醒功能。这次重构虽然没能挽救3.0的失败和hummermail 的流产（后话了），但是却成为全新版本QQ邮箱的最核心后台，相当了不起的一次重构，足以载入史册。

至于3.0版的失败，那是一个更惊心动魄的历程，凤凰涅盘，浴火重生。

本文链接

关于草根小团队创业的一些看法【转】

2011-07-05T02:49:00Z

关于草根小团队创业的一些看法【转】

2011-02-07 23:50

作者：付恒

来源：http://www.fallhunter.com/p/10333

一年多以来，在创业路上摸爬，没有什么经验，有的只是一些点滴的认识，其中很多大家都在说，但我相信不同的人有不同的理解。
点子约等于空想
互联网有太多一个点子一夜成名的故事，为什么？因为这样的故事大家喜欢看，这样的故事吸引眼球，对公司是个很好的广告，对媒体是很好的收入。这样的故事，现在有很多，以后还会有更多，媒体是要赚钱的，不是给大家指导创业的。作为创业者，大家要冷静的看待各种传奇故事。
很多时候，我们发现互联网上涌出的东西我们早就想过，很多年前都想过，甚至连某些细节，某些操作方式，跟我们曾经设想的一模一样，于是，我们痛心疾首，找各种机会跟别人说：这东西我x年前就想过，blablabla... 我认为，如果一个东西我们想到了，那么一定也会有别人想到，大家都是人，都从同一个互联网的获得信息，都在同一个世界里生活，即便你的圈子再特殊，也一定有跟你相仿的人。那么问题就不是你想到了这个点子，而是你没有实现它。曾经我认为知识产权不保护脑子里的想法是因为很难实施保护，现在觉得确实也没必要保护，点子只有实现了，才有价值，否则就是空想。
计划约等于屁话
对于小团队，计划出一年内甚至几个月内达到什么程度，无异于瞎猜。因为团队小，资源少，经不起任何波动，有可能某天在网上认识一位朋友，介绍了一个合作，一下子收入翻了几倍；有可能一次版本更新有个问题，用户瞬间消失，甚至再无回春之力；有可能说依赖的技术平台一个新的变化带来十倍的用户；也有可能行业的一则新网让同类产品都面临道德和法律的质疑而进退不能。
小团队就像一个小水坑，有点雨就满了，雨停了就干了，不是撑死就是饿死。小团队只是行业潮流中的一叶扁舟，大浪把你打到哪里，你就在哪里，面对行业潮流试图力挽狂澜，无异于螳臂挡车。
看起来有些消极，其实不是，小团队并不是只能随波逐流，我想说的是，不要受计划的限制，都说坚持就是胜利，如果没胜利，坚持就是固执。看准时机，大胆的调整方向，失败了叫多变，成功了，就叫机智。
加班约等于自慰
恩，我说的是自我安慰。创业需要努力工作，但努力工作不等于加班。作为创业者，我们要密切关注瞬息万变的行业和市场，把握每个细节，不断做出决策。创业者要埋头工作，更要抬头看路，过度的加班，弊大于利。
加班影响团队士气，加班让所有的工作都显得重要，也就是让所有的工作都显得不重要，容易丧失工作节奏，影响团队执行力；加班所带来的疲惫，是创业者的大敌，创业者要不断做出决策，以保持团队在做正确的事情，这需要清醒的头脑和冷静的分析。加班带来虚假的成就感，每天忙忙碌碌，做了很多事情，这会有很强的创业的感觉，可惜的是，这种感觉却是虚假的，几乎任何事情，都可以让人忙忙碌碌，而一个正确的决策，则可能整个团队节省数月或数年的工作。
接受现实，资源永远不足，人手永远不够，实现永远达不到预期
小团队创业，几乎什么都会缺，在这种情况下，就不能安装正常的模式来工作。从大公司出来创业，好比是从城市生活来到荒岛求生，这时候吃饭是最重要的，要什么煤气灶和抽油烟机！
小团队要利用手里现有的资源，看看能做什么，而不是学者大公司的方式来做事。面对一个荒岛，有果子就摘果子，有鱼就抓鱼，这样的条件下，如果顺利活下来了，有一天在同样的环境下竞争，我们会发现那些城市人完全不是对手。
做好了再发布
搞互联网的人总说，快速上线，快速迭代，没错。但是对于小团队和个人开发者来说，我更想说：做好了再发布。很多时候，我们上线的东西都算不上一个完整的产品，而一个不完整的产品一定很难达到一定的用户量，没有用户量，就没有足够的反馈来指导下一步的方向，更重要的是，没有用户量，团队得不到阶段性的鼓励，容易沮丧而失去信心。
注意细节，享受过程
我一直认为，创业不是十年寒窗苦读日，一举成名天下知，不是吃得苦中苦，方为人上人，不是传统的中国式的先苦后甜。创业更像是一个艺术创造，描绘一副画卷或弹奏一曲，每一次落笔均有深意，每一次按键都饱含感情，这个过程，才是创业最大的魅力。

本文链接

狗日的腾讯对蛋疼的360

2010-11-04T08:25:00Z

最近互联网真是热闹非凡，高潮迭起，真是精彩，这里先感谢2个无知公司真诚的入戏。

从一个QQ的用户，我首先对这场对决的第一个倾向是QQ公关太粗暴。因为360老板的关系，从来就不喜欢用这家公司的产品，虽然看到身边很多人用的方便(FREE)，自己还是宁愿傻傻的掏200买个卡巴一年用。QQ的话，大家都知道了，从没有选择到被选择，丢不掉的朋友和亲情，也丢不掉这个狗日的QQ。但这次QQ的做法太STUPID了，典型的国内简单粗暴式，完全没大公司的份。截止到11月4日，腾讯的港股市值是3291亿；从这个数字看，腾讯在中国互联网是当之无愧的老大。可就这个老大做处这么低级的反击，让我等充满悲挟持的不爽。

从一个业内者的角度，我个人还是很欣赏腾讯。虽然有人大骂腾讯的山寨化策略，但在目前的国内的游戏规则中，这个做法让腾讯成功做了老大，并且还有更大的趋势。马云说过：现在的商业没有秘密，核心技术不是秘密，人员不是秘密，盈利模式不是秘密；唯一能战胜模仿者的只有不断前进的决心和努力。多方面山寨成功的腾讯让我看到了这家公司强大的执行力和市场敏锐性。与之对比的就是现在的微软，缺乏执行力，周边产品创新性的扼杀，越来越官僚的组织结构。

本文链接

使用Doxygen来自动化生成项目代码文档

2010-10-26T04:29:00Z

又到了项目结尾的时候，文档的需求又成了人民的最大矛盾了。

看了Doxygen 才发现原来之前看到很多以网页方式展现的开源项目代码都是通过该工具生成的，赞之！

关于 Doxygen 的安装文件，帮助，源代码都可以直接访问sourceforge获得：http://sourceforge.net/projects/doxygen/

初次接触还是需要了解很多关于Doxygen 的注释公约，简单搜了一下常用的贴在下面，后面使用到了再不断补充成自己需要的：

Doxygen语法

1. 模块定义（单独显示一页）

/*
* @defgroup 模块名模块的说明文字
* @{
*/
… 定义的内容 …
/** @} */ // 模块结尾

2. 分组定义（在一页内分组显示）

/*
* @name 分组说明文字
* @{
*/
… 定义的内容 …
/** @} */

3. 变量、宏定义、类型定义简要说明

/** 简要说明文字 */
#define FLOAT float

/** @brief 简要说明文字（在前面加 @brief 是标准格式） */
#define MIN_UINT 0

/*
* 分行的简要说明 \n
* 这是第二行的简要说明
*/
int b;

4. 函数说明

/*
* 简要的函数说明文字
* @param [in] param1 参数1说明
* @param [out] param2 参数2说明
* @return 返回值说明
*/

int func(int param1, int param2);

/*
* 打开文件 \n
* 文件打开成功后，必须使用 ::CloseFile 函数关闭。
* @param[in] file_name 文件名字符串
* @param[in] file_mode 文件打开模式字符串，可以由以下几个模块组合而成：
* - r 读取
* - w 可写
* - a 添加
* - t 文本模式(不能与 b 联用)
* - b 二进制模式(不能与 t 联用)
* @return 返回文件编号
* - -1 表示打开文件失败
* @note 文件打开成功后，必须使用 ::CloseFile 函数关闭
* @par 示例:
* @code
// 用文本只读方式打开文件
int f = OpenFile(”d:\\test.txt”, “rt”);
* @endcode
* @see ::ReadFile ::WriteFile ::CloseFile
* @deprecated 由于特殊的原因，这个函数可能会在将来的版本中取消。
*/
int OpenFile(const char* file_name, const char* file_mode);

5. 枚举类型定义

/** 枚举常量 */
typedef enum TDayOfWeek
{
SUN = 0, /**< 星期天（注意，要以 “<” 小于号开头） */
MON = 1, /**< 星期一 */
TUE = 2, /**< 星期二 */
WED = 3, /**< 星期三 */
THU = 4, /**< 星期四 */
FRI = 5, /**< 星期五 */
SAT = 6 /**< 星期六 */
}

/** 定义类型 TEnumDayOfWeek */
TEnumDayOfWeek;

6. 项目符号标记

/*
* A list of events:
* - mouse events
* -# mouse move event
* -# mouse click event\n
* More info about the click event.
* -# mouse double click event
* - keyboard events
* -# key down event
* -# key up event
*
* More text here.
*/

结果为：

A list of events:

mouse events

mouse move event
mouse click event
More info about the click event.
mouse double click event

keyboard events

key down event
key up event

More text here.

代码示范：

/*
* @defgroup EXAMPLES 自动注释文档范例
* @author minidxer
* @version 1.0
* @date 2007-2008
* @{
*/

/*
* @name 文件名常量
* @{
*/

/** 日志文件名 */
#define LOG_FILENAME “c:\\log\\debug.log”
/** 数据文件名 */
#define DATA_FILENAME “c:\\data\\detail.dat”
/** 存档文件名 */
#define BAK_FILENAME “c:\\data\\backup.dat”

/** @}*/ // 文件名常量

/*
* @name 系统状态常量
* @{
*/

/** 正常状态 */
#define SYS_NORMAL 0
/** 故障状态 */
#define SYS_FAULT 1
/** 警告状态 */
#define SYS_WARNNING 2

/** @}*/ // 系统状态常量

/** 枚举常量 */
typedef enum TDayOfWeek
{
SUN = 0, /**< 星期天 */
MON = 1, /**< 星期一 */
TUE = 2, /**< 星期二 */
WED = 3, /**< 星期三 */
THU = 4, /**< 星期四 */
FRI = 5, /**< 星期五 */
SAT = 6 /**< 星期六 */
}
/** 定义类型 TEnumDayOfWeek */
TEnumDayOfWeek;
/** 定义类型 PEnumDayOfWeek */
typedef TEnumDayOfWeek* PEnumDayOfWeek;

/** 定义枚举变量 enum1 */
TEnumDayOfWeek enum1;
/** 定义枚举指针变量 enum2 */
PEnumDayOfWeek p_enum2;

/*
* @defgroup FileUtils 文件操作函数
* @{
*/

* @note 文件打开成功后，必须使用 ::CloseFile 函数关闭
* @par 示例:
* @code
// 用文本只读方式打开文件
int f = OpenFile(”c:\\test.txt”, “rt”);
* @endcode

* @see ::ReadFile ::WriteFile ::CloseFile
* @deprecated 由于特殊的原因，这个函数可能会在将来的版本中取消。
*/
int OpenFile(const char* file_name, const char* file_mode);

/*
* 读取文件
* @param[in] file 文件编号，参见：::OpenFile
* @param[out] buffer 用于存放读取的文件内容
* @param[in] len 需要读取的文件长度
* @return 返回读取文件的长度
* - -1 表示读取文件失败

* @pre \e file 变量必须使用 ::OpenFile 返回值
* @pre \e buffer 不能为 NULL
* @see ::OpenFile ::WriteFile ::CloseFile
*/
int ReadFile(int file, char* buffer, int len);

/*
* 写入文件
* @param[in] file 文件编号，参见：::OpenFile
* @param[in] buffer 用于存放将要写入的文件内容
* @param[in] len 需要写入的文件长度
* @return 返回写入的长度
* - -1 表示写入文件失败

* @pre \e file 变量必须使用 ::OpenFile 返回值
* @see ::OpenFile ::ReadFile ::CloseFile
*/
int WriteFile(int file, const char* buffer, int len);

/*
* 关闭文件
* @param file 文件编号，参见：::OpenFile
* @retval 0 为成功
* @retval -1 表示失败

* @see ::OpenFile ::WriteFile ::ReadFile
* @deprecated 由于特殊的原因，这个函数可能会在将来的版本中取消。
*/
int CloseFile(int file);

/** @}*/ // 文件操作函数

/** @}*/ // 自动注释文档范例

本文链接

[转载]Visual Studio统计有效代码行数

2010-09-15T07:05:00Z

Visual Studio统计有效代码行数

2009年5月22日

看看评论评论一个

看网上有人专门做了一些小工具，用来统计代码行数。感觉不是很必要。因为Visual Studio中的搜索功能支持正则表达式（虽然语法比较诡异），我们完全可以通过正则表达式来遍历整个解决方案从而获得代码行数。

^:b*[^:b#/]+.*$

需要注意：#开头和/开头或者空行都不计入代码量。

如果需要只统计代码文件的代码量，可以按住Ctrl+Shift+F之后选择查找文件的类型。

还有自己写插件的办法：http://www.cnblogs.com/sifang2004/archive/2006/06/26/436076.html

本文链接

把东西写下来是一种神奇的力量

2010-09-12T09:03:00Z

看到《影响力》中有这样一段话，“把东西写一下来有一种神奇的力量”，心中突然某个角落突然产生了一丝和谐的共鸣。That is it!
作者也忠告到：“制定一个目标，并把它写下来”。
现在想想自己，代码是写的越来越多，计划是写的越来越少；重复性的COPY&PASTE越来越多，创造性的设计越来越少；插上手柄的冲动越来越多，拿起笔的动力越来越少。
想起以前学生时代，很多知识的积累和突然的质变其实都在于平时点点滴滴的写。现在该是我重新找回这种神奇力量的时刻了。
动手写下来！

本文链接