通信&政企产品
PMP考试
摘要: 刚给大辉发完邮件准备去上班，微信群里热闹不已，原来是pmp成绩出来了，尽管考试完后心里基本有底，但听老师说这次考试偏难，等在待结果出来的前夕，还是不免忐忑。
2013年年初报名直到2014年3月份才考试，倒也是好事，实际工作中的那些事和那些人，总能在复习的过程中让自己反复思考和碰撞。而4m1p的成绩单，算是给自己交了一份满意的答卷，在这里简单回顾一下，有兴趣的同学可参考：
【复习历程】：
1、 关于教材划分（含：1本教材（2012版）、3套模拟题、1本辅导书），自己是按下面四部分来分批阅读：
第1章 项目引论、第2章 组织影响和项目生命周期、第3章 项目管理过程
第4章 项目整合管理
第5章 项目范围管理、第6章 项目时间管理、第7章 项目成本管理、第8章 项目质量管理
第9章 项目人力资源管理、第10章 项目沟通管理、第11章 项目风险管理、第12章 项目采购管理、
阅读全文
posted @
2014-04-19 09:35 cheng 阅读(1114) |
评论 (2) 编辑
产品上线期间的那些事
摘要: 这段时间以来的产品使用过程，界面性能和易用性成为关注的重点。相比运营商项目不同，政企项目验收过程相对简单，没有严格的测试用例，以是客户组织的项目评审会，公司汇报阶段进展、客户做业务测试的方式开展。
简单回顾上线期间一些工作：
1）公司侧提供《需求规格说明书》、《产品使用手册》、《角色权限清单》
2）业务部门整理《用户申请表》、《业务制度管理办法》
3）业务部门组织上线前项目例会
3）业务部门发布系统上线公告
4）业务部门组织用户培训
5）公司和业务部门提供产品使用支持，解答最终用户的操作疑问、收集产品反馈。
阅读全文
posted @
2014-03-26 22:05 cheng 阅读(1342) |
评论 (3) 编辑
需求管理和进度管理的一些体会
摘要: 项目进入试用阶段，版本节奏也相对平缓，对于需求&开发&测试过程中的一些管理，分享一些个人体会，欢迎指正。开始正文之前，存在下面前置条件：
1.本轮版本要交付的功能及时间已已评估并与客户达成一致，是以交付时间倒推来管理《需求规划》和《研发计划表》的方式。
2.团队资源：有测试组长，开发组长是临时支持（同时兼顾其他项目）。
3.开发4人、测试2人、需求1人，迭代周期1～2周。
4.需求、开发和测试在一起办公。
阅读全文
posted @
2014-01-19 22:40 cheng 阅读(1909) |
评论 (5) 编辑
开发过程笔记
摘要: 项目接近尾声，需求也逐渐收敛。面对需求变化频繁、迭代版本周期较短的客观情况，传统模式已不能在此生搬硬套。虽现有的开发过程谈不上正规敏捷，也算接近小步快跑的节奏。下面分‘需求开发&代码开发、版本控制、版本发布、增量升级’几个部分，记录一些体会，欢迎指正：
（1）需求沟通&代码开发：
1、针对有可以复用的现有模块时，和开发人员沟通主体思路，由开发人员着手开发，开发人员在开发期间与需求人员充分沟通，碰到疑问及时澄清、解决。
2、针对没有可复用的模块且涉及较复杂的业务流程时，需求人员画原型图（紧急情况手绘草画），开发人员按原型图或草图着手开发。
3、需求人员记录开发过程中和开发人员、客户沟通的需求变化点。
4、功能开发完成、客户验收后，及时补充到《需求规格说明书》。
（2）版本控制：
1、代码提交前做比较再合入版本库（严禁合入非自己修改的文件）。
2、合入代码需填写修改信息，新版本开发只填写修改信息，优化修改还需在BU
阅读全文
posted @
2013-12-27 20:47 cheng 阅读(1303) |
评论 (0) 编辑
平台软件需求分析和设计实例
摘要: 5W1H原则：
what：用户需求是什么，要做什么功能。
why：产生这个需求的背景是什么，原因是什么，能帮助用户解决什么问题。
who：功能需求做出来了，哪些角色会参与使用。
where：功能需求的使用环境是什么（如：操作系统、浏览器环境，分辨率环境）。
when：功能需求何时交付（基于交付时间，考虑实现方案的选择）。
阅读全文
posted @
2013-12-01 16:30 cheng 阅读(1804) |
评论 (0) 编辑
项目规划与管理记录2
摘要: 8、9、10三月，需求依旧爆棚，相比纯业务功能的开发，数据的汇聚、整理、分析、统计成为重点，具体细节不一一展开，按如下关键词：任务计划、项目沟通、项目流程、客户汇报、业务关注、时间评估、管理笔记做一些笔录，持续更新：
1、任务计划：
1.决策前考虑充分，决策后不再怀疑。
2.任务精细、描述清晰，对内分解针对到负责人、给外汇报针对产品功能。
3.计划制定时，请成员预审任务量，再和开发、测试确认时间，由成员承诺时间。
4.安排任务多人完成时，指定一个牵头人。
5.大的需求，组织讨论，小的需求，点对点沟通，最后要全部闸口到文档。
阅读全文
posted @
2013-11-09 22:48 cheng 阅读(2160) |
评论 (3) 编辑
项目规划与管理记录1
摘要: 6、7两月，时间很快，周末的时间来做些梳理、小结，好的要继承，不好的去改进。下面，分日报管理、计划管理、客户管理、需求管理、客户汇报、团队建设几个方向，梳理一些记录，欢迎指正。
1、日报管理
1.项目启动会召开，介绍项目背景，时间计划和项目目标，使团队成员有共同的认识。让团队成员之间互相介绍，以彼此熟悉。
2.根据收集和掌握的需求任务，编写项目计划、安排日报（体现当天任务在项目计划中的完成百分比、当天任务完成百分比）。首次发日报前，与日报汇总人员点对点沟通编写格式，注意事项，重在量化指标。
3.根据日报汇总人员汇总的内容，了解各开发、测试成员的工作饱和度及工作质量，以针对性安排后续新任务。
阅读全文
posted @
2013-08-04 10:38 cheng 阅读(1864) |
评论 (2) 编辑
小网站交付体会
摘要: 接到任务，开发一个用于项目管理的小网站，功能比较简单，目的在于方便会议纪要、文档资料上传、查阅，消息发布和消息反馈。从需求沟通、时间沟通、需求分析、原型评审、软件开发到产品交付，历时8天，2轮用户需求，2次加班冲刺，可以说是阶段性的完整交付使用。
时间回顾：
客户期望的时间：1天
沟通争取的时间：2天
产品交付的时间：延期1天（开发测试历时4天，算上周六）
新需求期望时间：2天
沟通争取的时间：2天
新需求交付使用：2天
阅读全文
posted @
2013-06-23 12:24 cheng 阅读(2513) |
评论 (1) 编辑
项目化运作思考
摘要: 新的环境、新的成员、新的客户和新的文化，过去的2个月更多的时间忙于应战，周末难得的梳理时间，来做些回顾和总结。
加入之初，项目启动已经开始，对于陌生的一个产品和团队，尽快熟悉掌握的方法莫过于通过文档和产品环境的方式、通过日常的沟通熟悉人员。和成员一起，对产品全流程进行了验证和记录。市场类的项目，通过会受到直接客户的一线压力，尤其是新业务的项目，开始阶段往往是客户主导、公司研发，项目计划的时间变更也相对频繁，疲于迎战的局面开始凸显，但项目初始为了市场占有率，赶工和加快进度的项目方式是需要的。
阅读全文
posted @
2013-06-16 13:57 cheng 阅读(2581) |
评论 (2) 编辑
产品升级过程的一些活动
摘要: 对于新型产品，工程支撑力度在初期会较弱，在产品升级期间会需要产品规划人员参与，作为牵头人的角色，协调于工程经理、研发项目经理和工程团队之间，扮演产品顾问的角色。同时，会参加客户召开的需求升级讨论会，和各平台厂商的人员沟通升级计划和安排。其中，对需要产品规划人员亲赴现场参与升级工作的情况，谈谈个人的一些经验：
1）了解产品研发进展
2）安排前方工程团队了解此次升级背景、升级业务（不限于现网的物理组网图、现网的业务种类、现网的业务运营时段、升级后的现网业务种类、升级后的业务运营时段、业务涉及各个网元的IP地址、端口、接口模块的帐号密码）和客户的升级方案。
阅读全文
posted @
2013-04-17 21:01 cheng 阅读(1387) |
评论 (2) 编辑
需求研发过程的一些活动
摘要: 项目生命周期中，变更和纠正错误的代价在项目接近完成时通常会显著提高。所以在项目研发过程中，需求分析师要参与到产品研发过程，与开发人员、测试人员保持紧密沟通，讨论和澄清在实现过程中的需求疑问，保证产品产出和需求意图的吻合。软件项目中的需求变更，相信做需求的人员再熟悉不过，需求变更率的高低，也是反应需求工作好坏的一个重要KPI。对于需求变更的发生，唯有面对和解决。通常的做法：了解需变更背景、评估影响程度，考虑与各干系人的沟通（客户、市场、研发、工程和领导），将评估结果作为变更请求，提交给项目管理团队，获批准后，按新计划开展产品研发。
下面是在项目研发过程中需求端会参与的一些活动：
阅读全文
posted @
2013-03-29 11:55 cheng 阅读(1479) |
评论 (0) 编辑
产品工作中的沟通与协调
摘要: 1）明确目标：
会议室及电话会议，开会前列出会议章程（最好可以先发个邮件或者打个招呼，告之这次参会人员的大概情况），会议后要有会议结果（及时输出会议纪要）。
会议纪要可以包含下面几个部分：
1.参会人员、日期、时间
2.会议议题（讨论要点）
3.会议纪要（讨论过程的概括及描述）
4.后续策略及关键事件跟踪（后续事件及对应负责人和时间点）
阅读全文
posted @
2013-03-10 13:36 cheng 阅读(1772) |
评论 (0) 编辑
浅谈需求分析
摘要: 开始接触需求工作时，在对用户需求的沟通基础上，多依据于做软件开发的结构化思维方式来编写需求文档，这种方式易陷入实现细节的陷阱。如何在用户需求和软件需求之间找到平衡点，使得做出的产品即是用户想要的又在技术可行和成本上性价比最高，甚至超出用户期望，给用户惊喜，开展需求工作时需认真考虑。
业内谈得比较多的‘六何法（what、why、when、who、where、how）’，在需求分析工作中同样适用，可作为问题分析的基本习惯。下面谈些自己的理解：
1、信息收集和初步分析：
what：需求是什么，解决什么人的什么问题（用户群体、用户规模、业务场景、性能指标和组网）？
why：背景是什么，为什么有这个需求（高层领导思路、团队主动规划需求、竞品分析需求）？
when：需求的市场时间（实验室验收、试运营和正式上线等各阶段时间）？
who：需求的用户对象是谁（如：技术部门），是否与其他用户对象（如：业务部、内容部、运维部门等）有关联？
where：哪里做（现场开发还是团
阅读全文
posted @
2013-02-18 22:53 cheng 阅读(2665) |
评论 (2) 编辑
产品规划这两年
摘要: 互联网发展速度是惊人的，回首从博客—>微博—>微信的这几年，自己也从Java软件开发转到了产品规划工作。期间经历了大小不一的各类运营商的平台规划工作，选择在此时来回顾，一方面是给自己这两年的忙碌找个借口。另一方面，更多的是一种经历过后的感触，就先从产品规划工作的定义开始，分享自己的理解吧
指通过在了解市场、了解客户需求、了解竞争对手、了解外在机会与风险、了解市场和技术发展态势的基础上，根据公司自身的情况和发展方向，制定出可以把握市场机会，满足用户需要的产品的远景目标以及实施该远景目标的战略、战术的过程。
1）技术角度：负责需求沟通、收集、分析、评估、澄清、转换、评审、版本规划、研发跟踪、版本发布。
1.沟通，从市场价值、技术可行性和时间&人力成本方面综合考虑以确认是接受还是引导客户。
2.收集，从客户的市场、技术、业务、运维人员、友商人员和公司内部市场人员，多渠道获取CI信息。
3.分析，采取自底向上、透过现象看本质以抓客户的核心需求。
阅读全文
posted @
2013-01-13 23:07 cheng 阅读(1749) |
评论 (1) 编辑