摘要: 互联网，从今年5月~7月的准备，再到8月入职至今的半年以来，感受和经历有很多。年末岁尾、空闲之余，来梳理那些日子里还记忆尤新的片段。
毕业后开始做程序员、工作第3年转做了系统分析师，第5年转做项目经理，1年之后投入互联网产品至今。7.5年的职业生涯里，在收获各阶段经历的同时也在感受着互联网行业带来的各种变化。而对于转互联网的初衷及时机，概括来说有如下几点：
1.互联网产品更加贴近生活、更有趣、更喜欢
2.积累了软件开发、产品及项目管理工作经验
3.积累了互联网产品规划、设计、管理及运营等书籍阅读和笔记
4.积累了对一些互联网产品的看法和见解
从开始关注互联网产品，到感兴趣和不间断关注，到最后加入这个圈子，那些过往的情景还历历在目：  阅读全文      摘要: 高速发展的世界，需要我们迭代地开发和改进业务问题的解决方案，我们需要一些方法来持续探索业务及其问题，将这些要求告诉技术专家，他们为业务提供技术解决方案。
许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这些业务活动，定义一些需求，开发一部分解决方案，定义更多的需求，这样增量式交付发行版本，直到解决方案被判定完成。这种迭代的方式意味着，业务环境和开发环境中的关注点、想法和变化更加同步。使开发者更了解今天的业务问题，工作的产品适合今天的业务环境。
这种持续的工作探索意味着，业务分析师持续地将新故事或需求加入分析列表，这个列表又持续地按价值进行分析，最重要的是按业务价值来分析。列表根据价值和紧急性来排列优先级，最高优先级的需求交给开发者开发。  阅读全文      摘要: 今天的大多数软件都不是拥有它的组织机构开发的，而是购买的。考虑到这些开发和解决方案选项，今天的业务分析师有一项额外任务：即决定最佳的策略来发现和沟通需求，不论组织机构决定采用哪种方式实现自动化。
以需求策略作为指导，决定从哪里开始，是否有足够的细节，你需要哪个迭代循环，记录知识时采用哪种形式，何时复查，何时让哪些利益相关者参与，何时构建原型，何时以及如何做大量的事情，让你的工作更接近为业务产生最优价值，每个项目的情况不同，有必要采用不同的做事顺序、做事细节、沟通形式。  阅读全文      摘要: 需求评审环节检查了单项需求，确保它表述正确、无二义性、在范围内、可测试、可追踪、不是镀金需求，从而确定制有正确的原子需求才包含在需求规格说明中。
接下来，必须考虑需求规格说明是否完整，这意味着将规格说明作为一个整体来复查，确保应该有的部分都有。
这种复查可以在任何时候进行，而不只是在发布之前，它可以是一项持续的活动。
  阅读全文      摘要: 需求来自于人，人们并非总能确定他们需要什么，并非总能解释他们想要什么，需求也并非总是编写地很小心，完整无二义。
需求工作的要点是要确保交给开发者的东西是准确的、完整的、无二义的，陈述了真正的需求。任何不足都有违需求工作的初衷。开发者可以构建任何东西，但他们首先必须知道他们必须构建什么。  阅读全文      摘要: 如果产品有一项需求，要执行某个功能或具备某种属性，那么测试活动必须展示产品确实执行了该项功能，或具备了该项期望的属性。为了进行这样的测试，需求必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。要注意的是，这里的验收标准既不是测试，也不是对测试的设计，而是测试提交的产品必须采用的测试基准，是构建测试用例的输入信息。  阅读全文      摘要: 为什么所谓的‘非功能需求’也很重要？请考虑一个真实发生的故事：客户拒绝了交付的服务台软件。功能是正确的，但客户不想要它。为什么？因为客户拒绝使用它，更愿意采用原来的人工过程。这就是需求团队几乎没有注意非功能性需求。
只所以需要这些非功能需求，不是因为它们是产品的功能活动（诸如计算、操作数据活动），而是因为用户希望这些活动以特定的方式执行，并达到特定的品质。
例如，亚马逊网站很容易导航，这让客户容易找到对象，它也很友好，让你觉得自己是尊贵的顾客，你可以写评论，通过购物伙伴和亚马逊推荐得到指引，很容易查看和安排送货，等等。  阅读全文      摘要: 通过产品用例（PUC）场景展示和确定了解决方案后，下面就需要PUC场景转换到功能需求。
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行的一些动作。需求分析师理解了产品必需的功能后，他要用功能需求告诉开发者要构建什么。
  阅读全文      摘要: 当需求人员和客户之间针对需求沟通中的业务本质问题达成一致时，接下来就是沟通和确定多少业务将通过产品来实现自动化。作为需求分析人员，需要在业务需求、包含的功能、用户体验、非功能需求、开发成本、技术可行性、限制条件这些因素之间取得平衡和折中来完成解决方案的确定和发布。
没有公式化的方法能得到最佳的解决方案，需要实际过程中考虑和权衡。  阅读全文      摘要: "我知道这是我提出的,但这不是我想要的。”你不必在IT这行待很长时间就能听到这句话，看着期待的笑容从开发者脸上消失，因为这事经常发生。开发者交付了客户提出的需求，但结果却不能解决他们的业务问题。为什么？因为真正的问题从未阐明，所以从未正确理解。
在做需求调研和收集时如果听到的都是客户关于解决方案的想法，而不是描述背后要解决的问题，这可能是个好的解决方案，但更有可能的是，它受限于客户的经验和想象力。而且，你不清楚它是否解决了正确的问题。所以，作为需求分析人员，你的任务就是解释客户所说的内容，揭示它的本质。  阅读全文      摘要: 不论哪种工作，试图改变之前先对它有充分的理解，如果一头冲进去，对你要改变的东西几乎没有理解，就进行‘改进’，那么结果不如意也不奇怪。当你开始理解原有的工作时，肯定会产生一些想法，知道如何改进它。
这里探讨的比较常用的Brow Cow模型和一些用于发现业务过程的调研方法，而实际过程中不可避免地需要多种调研技巧组合使用，具体情况需要具体应对。  阅读全文      摘要: 项目启动过程建立了工作的范围，即要研究的业务领域，业务领域其中的一部分将通过预期的产品实现自动化。而实际上，这个工作范围可能太大，难以作为一个单元进行研究，正如吃东西之前先要将它切成小块一样，需要将工作范围分解为一些可管理的部分，然后再来研究它以发现产品的需求。这里将需求过程中涉及到主要对象以及它们的分工界面通过一张关系图来展示：  阅读全文      摘要: 从通信行业的产品工作到政府行业的项目工作，一直在和‘需求’打交道，不同的行业特点和项目环境需要针对性的需求发现和实现方法，但围绕需求调研、分析、编写、评审、验证到需求交付这几个过程基本是相通的。经历从瀑布型项目需求策略到迭代型需求策略的转变和实践过程，回过头来看《软件开发方法学-掌握需求过程》，进行摘录和梳理的同时，也加深和沉淀一些对需求的理解和认识。以此片文章开始，分享一些读书笔记：  阅读全文      摘要: 刚给大辉发完邮件准备去上班，微信群里热闹不已，原来是pmp成绩出来了，尽管考试完后心里基本有底，但听老师说这次考试偏难，等在待结果出来的前夕，还是不免忐忑。
2013年年初报名直到2014年3月份才考试，倒也是好事，实际工作中的那些事和那些人，总能在复习的过程中让自己反复思考和碰撞。而4m1p的成绩单，算是给自己交了一份满意的答卷，在这里简单回顾一下，有兴趣的同学可参考：
【复习历程】：
1、 关于教材划分（含：1本教材（2012版）、3套模拟题、1本辅导书），自己是按下面四部分来分批阅读：
第1章 项目引论、第2章 组织影响和项目生命周期、第3章 项目管理过程
第4章 项目整合管理
第5章 项目范围管理、第6章 项目时间管理、第7章 项目成本管理、第8章 项目质量管理
第9章 项目人力资源管理、第10章 项目沟通管理、第11章 项目风险管理、第12章 项目采购管理、  阅读全文      摘要: 这段时间以来的产品使用过程，界面性能和易用性成为关注的重点。相比运营商项目不同，政企项目验收过程相对简单，没有严格的测试用例，以是客户组织的项目评审会，公司汇报阶段进展、客户做业务测试的方式开展。
简单回顾上线期间一些工作：
1）公司侧提供《需求规格说明书》、《产品使用手册》、《角色权限清单》
2）业务部门整理《用户申请表》、《业务制度管理办法》
3）业务部门组织上线前项目例会
3）业务部门发布系统上线公告
4）业务部门组织用户培训
5）公司和业务部门提供产品使用支持，解答最终用户的操作疑问、收集产品反馈。  阅读全文      摘要: 项目进入试用阶段，版本节奏也相对平缓，对于需求&开发&测试过程中的一些管理，分享一些个人体会，欢迎指正。开始正文之前，存在下面前置条件：
1.本轮版本要交付的功能及时间已已评估并与客户达成一致，是以交付时间倒推来管理《需求规划》和《研发计划表》的方式。
2.团队资源：有测试组长，开发组长是临时支持（同时兼顾其他项目）。
3.开发4人、测试2人、需求1人，迭代周期1～2周。
4.需求、开发和测试在一起办公。  阅读全文      摘要: 项目接近尾声，需求也逐渐收敛。面对需求变化频繁、迭代版本周期较短的客观情况，传统模式已不能在此生搬硬套。虽现有的开发过程谈不上正规敏捷，也算接近小步快跑的节奏。下面分‘需求开发&代码开发、版本控制、版本发布、增量升级’几个部分，记录一些体会，欢迎指正：
（1）需求沟通&代码开发：
1、针对有可以复用的现有模块时，和开发人员沟通主体思路，由开发人员着手开发，开发人员在开发期间与需求人员充分沟通，碰到疑问及时澄清、解决。
2、针对没有可复用的模块且涉及较复杂的业务流程时，需求人员画原型图（紧急情况手绘草画），开发人员按原型图或草图着手开发。
3、需求人员记录开发过程中和开发人员、客户沟通的需求变化点。
4、功能开发完成、客户验收后，及时补充到《需求规格说明书》。
（2）版本控制：
1、代码提交前做比较再合入版本库（严禁合入非自己修改的文件）。
2、合入代码需填写修改信息，新版本开发只填写修改信息，优化修改还需在BU  阅读全文      摘要: 5W1H原则：
what：用户需求是什么，要做什么功能。
why：产生这个需求的背景是什么，原因是什么，能帮助用户解决什么问题。
who：功能需求做出来了，哪些角色会参与使用。
where：功能需求的使用环境是什么（如：操作系统、浏览器环境，分辨率环境）。
when：功能需求何时交付（基于交付时间，考虑实现方案的选择）。  阅读全文      摘要: 8、9、10三月，需求依旧爆棚，相比纯业务功能的开发，数据的汇聚、整理、分析、统计成为重点，具体细节不一一展开，按如下关键词：任务计划、项目沟通、项目流程、客户汇报、业务关注、时间评估、管理笔记做一些笔录，持续更新：
1、任务计划：
1.决策前考虑充分，决策后不再怀疑。
2.任务精细、描述清晰，对内分解针对到负责人、给外汇报针对产品功能。
3.计划制定时，请成员预审任务量，再和开发、测试确认时间，由成员承诺时间。
4.安排任务多人完成时，指定一个牵头人。
5.大的需求，组织讨论，小的需求，点对点沟通，最后要全部闸口到文档。  阅读全文      摘要: 6、7两月，时间很快，周末的时间来做些梳理、小结，好的要继承，不好的去改进。下面，分日报管理、计划管理、客户管理、需求管理、客户汇报、团队建设几个方向，梳理一些记录，欢迎指正。
1、日报管理
1.项目启动会召开，介绍项目背景，时间计划和项目目标，使团队成员有共同的认识。让团队成员之间互相介绍，以彼此熟悉。
2.根据收集和掌握的需求任务，编写项目计划、安排日报（体现当天任务在项目计划中的完成百分比、当天任务完成百分比）。首次发日报前，与日报汇总人员点对点沟通编写格式，注意事项，重在量化指标。
3.根据日报汇总人员汇总的内容，了解各开发、测试成员的工作饱和度及工作质量，以针对性安排后续新任务。  阅读全文