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