1.从产品到项目
2.一切从Kick off开始
3.关键的青春期,又见需求
4.成长一步一个脚印
5.山寨级项目管理
6.物竞天择适者生存
1.从产品到项目
产品是什么?任何东西都可能是产品.有好的产品有坏的产品 .产品是解决某个问题的东西.
项目是什么?只会进行一次,包含多项互相关联的任务.并且有时间,成本,绩效和范围限制的一项工作.是过程.
做产品VS做项目
从三方面比较:
1.从生命周期的角度. 产品的生命周期较长.从规划到消亡整个过程.项目有特定的目标.生命周期较短.有明确的起始和结束时间.通过验收则生命周期完成.
2.从具体要做的事情来看. 做产品的过程:探索,创新,随着内外部信息变化修正自己的判断.做项目的过程:计划和控制.一开始就明确了目标.像执行一个任务.
3.产出物的角度. 产品:批量的,提供给大量用户的,满足更多的需求;项目只进行一次,定制的,个性化的,满足特定的需求. (裁缝做一件衣服是项目,建厂批量是产品等)
做产品经理VS做项目经理
产品经理product manager:靠想,做正确的事,是否符合市场需求,是否带来利润. 判断力和创造力,决定做不做,做什么,做多少,保证方向正确.产生想法并实现
项目经理project manager:靠做,把事情做正确,做完美,在时间,成本,和资源约束的条件下完成目标. 执行力和控制力,决定怎么做,谁来做,何时做.保证方法得当.接到任务并完成.
为什么让产品经理管项目
能对商业目标进行掌控,能够在商业目标,项目资源,用户体验各限制条件下取得平衡,解决目标不一致的问题.
2.一切从Kick off开始
KickOff是足球比赛的开球.也就是项目启动大会.
立项阶段的工作内容:需求筛选之后-立项(团队组建-计划确定-Kick off)
帅哥美女我们需要你
团队组建.跟不同团队的人去要人.邮件抄送是个好方法但是慎用..降低团队组建难度:1.产品会议得到老板认可,资源有所保证.2.经常合作的都是相对固定的人沟通顺畅.
别忘了最初的约定
什么时间做什么事情.再次评估推算出工期.常用工作量的公式:工作量=(最乐观+最悲观+最可能)/3 或者 工作量=(最乐观+最悲观+最可能*4)/6 瓶颈期在开发阶段,所以记得设置里程碑和监控点.
沟通从头开始
沟通的目的:项目成功
常见的沟通方式:周期,渠道,发起者,参与者.通用沟通方法如:项目晨会,项目日报,评审会,项目变更申请.发布预告以及公告.
不可或缺的誓师大会
项目KickOff会议.KO我也认为很重要.心理上的作用.
KO要传达的信息:项目背景;项目的意义,目的,目标;需求,功能点的概述;项目组织架构(项目成员互相认识);项目计划;沟通计划.
任何时候心中都要有树
做项目的目标:多快好省:范围大.时间短,品质高.资源省.
在保证质量的前提下,在时间要求,人物财花费,项目范围要做一个平衡.
可对比经典项目TRQ:T:time项目时间;R:resource项目资源;Q:quality项目质(数)量.
WBS:work breakdown structure.工作分解结构.
任何时候心中都要有树!自顶而下的优化并套用.无经验的项目可以自下而上.
3.关键的青春期,又见需求
需求开发,也就是写文档
真的要写很多文档
BRD:Business Requirements Document 商业需求文档(市场分析,销售策略,赢利预测.PPT演示没有产品细节争取资源) 老板看
MRD:market市场需求文档(实施阶段,更细致的市场和竞对分析,商业目标到技术实现的转化文档) 老板看
PRD:产品需求文档
FSD:functional specifications document功能详细说明.用例文档,包含在PRD.大都技术内容 一般的就写BRD和PRD.BRD实际是包括BRD和MRD的核心内容;PRD实际上包括PRD和FSD的核心内容.
产品需求文档PRD
通常一个项目会有一到多份的PRD.开始是一些总体说明:历史修订,项目概述,功能范围;用户范围,词汇表,非功能需求,其他说明.总体说明之后是用例文档部分,首先要对PRD的所有的用例进行说明.给出用例的可视化表示.说明各用例关系.例图最为关键.接下来是用例的正文,由一个个的用例组成.也就是用例文档UC(use case).最后对单个UC的说明也就是一些注释.
(接下来用例文档部分UC)
学一点UML:类图,用例图,状态图
UML:统一建模语言.
类图:描述系统中各个对象之间的关系,以及和外部系统的关系.业务领域的描述.让外行一看就懂.
用例图:各用例之间的关系.比如include或extend.用例包,用例,行为者之间的关系.
关系图:实体的状态转换.贯穿多个用例.
简洁明了受众是老板没时间看细节.整体部分说明结束
用例文档UC
UC是需求人员写给开发人员看的最基本的文档.
UC里要写的东西有哪些: 1.UC概述 2.UC主体
UC概述:1.用例的唯一标识(写不写关系不大); 2.用例名称(短语); 3.业务描述:商业/用户目标; 4.需求描述:实现哪些功能点; 5.行为者,该用例的行为者; 6.前置条件:触发这个用例的前提是什么? 7.后置条件:用例完成后的后续动作是什么? 8.其他说明:针对UC的特殊说明,没有不写.
UC主体:1.界面描述2.业务规则:通用规则;3.流程描述:分主干分支异常三种.尽量用时序图和活动图.模板式总结. UC一般只描写功能需求.非功能需求写在PRD的总体说明里.
UC对语言要求:无歧义.完整,一致,可测试.
再学一点UML:时序图,活动图以及其他
时序图:也叫顺序图,描述事物变化在时间维度上的先后顺序,善于表达用户的交互. 多页面多角色.
活动图:描述各个动作如何引起系统变化.善于表达泳道(工作流程)较多,分支较多的情况.
协作图:表达不同对象之间是如何相互影响的.理论和时序图等价转换.时序图关注交互在时间上的步骤,而协作图关注各个对象之间.
以上的UML大都是用visio画的.
DEMO也要我们做吗?
demo:产品原型,演示版,Mockup.
纸面demo--线框图(只考虑框架而不是细节/visio,ppt,word,画图板)--视觉效果(Photoshop做效果图)--交互细节(Axure.Dreamweaver制作页面) 最重要的不是工具.
概要设计与详细设计
1.不以写的东西是需求还是设计区分职责.而以业务和技术区分. (比如公司名称长度限制PD决定,公司名称的数据在数据库如何储存工程师决定)
2.常常重复的细枝末节,应该和工程师沉淀出产品规范.
需求活在项目中
需求写完了,为保证质量,需求还要各方评审,再进入开发阶段.
评审:一个头,两个大
评审是为了统一认识消除误解,及时发现偏差,防止问题随时间放大.
评审按照项目阶段分为:
1.需求评审:PRD评审,UC评审,Demo评审总称.PRD评审重点关注商业内容/叫上老板,销售,服务,用户等,PRD评审通过以后细化UC和Demo.Demo评审决定了产品的外观.UC偏重技术实现.
2.设计评审:概要设计和详细设计之后进行.是开发工程师把对需求的理解以设计文档的方式说给PD,测试.
3.测试评审:TC评审test case.由测试工程师把对需求的理解以TC形式说给PD.开发听.
需求评审会上不能漏掉的参与者:1.能够拍板做决定的人,能负责.2.与项目有关的产品接口人.他的参与可以避免发现与其他系统有冲突.
再看需求的生老病死
项目开始前:分析商业价值的需求讨论会.
项目中的需求阶段:PD抓紧时间完成需求的而开发,召开需求评审会.
项目中的需求阶段之后:进入开发之后,PD需要不断和开发,测试人员确认各种细节.
4.成长一步一个脚印
开发阶段旁观者说
开发阶段开发团队的工作内容:设计-设计评审-编码-单元测试.
测试阶段,大家一起上
测试阶段的主要任务:TC编写-TC评审(开发人员和PD都要参与评审)-冒烟测试(确认软件基本功能正常)-功能评审(产品演示会)-测试
Bug眼中的项目
bug的描述关键点:
缺陷级别:一般大于三级的bug被认为是严重的问题;
所属产品,项目:有的人需要同时处理很多的产品和项目;
bug名称:bug的简单说明;
bug描述:执行某操作,期望出现什么情况,实际出现什么情况.
任何人收到open的bug,确认并修复,状态变为Fixed;否认,也许提出者理解错了,也许不打算修改.改状态为rejected.不认为是自己的问题就转交. deferred的bug意味着暂不修订,技术做不到,时间不允许,或者性价比太低.
项目发布的时候所有bug必须closed或者deferred.对于1.2级的bug,没有这么严格.
测试过程使用Quality Center来管理.好处在于,每个bug重要的状态转换点,系统都会有邮件通知到相关人员.防止遗漏.
那一夜,项目发布
发布阶段的工作内容:发布评审-预发布(模拟生产环境上的真实状态)-发布-线上验证
对于影响较大的发布,采用分流发布或者灰度发布,即一小部分用户先用上.
以终为始.项目小结
项目结束,写项目发布公告.写项目小结(通过每天写项目的日报或周报随时记录情况)
怕什么来什么,只能拥抱变化
变更事件;紧急事件;搭车事件;(遇到项目人员人手不够时,最好的方式是向老板表明问题,帮助他减轻压力,千万不能有告状的低级行为)
5.山寨级项目管理
计划于控制,就是项目管理.山寨精神.
文档只是手段
建立自己的文档规范
PD常用的文档模板:
商业需求文档.
产品需求文档.
需求规范类:1.PD做什么?PD的工作内容总结,了解自己的工作职责;2.用户体验规范:交互规范,视觉规范,文案规范.3.通用原则.不断优化.
需求管理类:1.用户调研,调研的前中后要做什么,有哪些内容;2.产品需求列表(含需求管理流程):模板,流程图等.3.产品信息架构:描述产品页面或功能的关系.
流程管理类:1.日常发布流程;2.变更事件流程;
项目管理类:1.项目管理制度:原则性的东西,一些权责利;2.项目任务书;3.kickoff的PPT;4.项目组织结构:填几个名字就可以了;5.项目WBS(可生成进度):可用WBS Chart Pro小软件;6.项目发布预告与公告:大龄的重复内容模板化. 日常工作类:1.会议记录;2.个人日报周报.
模板作用知多少
模板的作用:1.让经常看同类文档的人提高效率;2.让写文档的新人尽快上手;3.让写作者不会漏考虑某些内容;
多人协作与版本管理
产生文档版本管理的本质需求是多人合作,协同办公.比如:SVN,权限控制,保密;VSS;Wiki;
养成版本号管理的好习惯.
玩转office足矣
word.excel.ppt:字-表-图; mindmap:思维导图.mindmanager,freemind,xmind;
visio:所有的图都能画;Outlook:部分邮件;project:复杂项目的安排;OneNote:时间管理工具;access:简单数据库管理;
流程也是手段
有远见的人把流程当手段,短视的人把手段当目的.
项目VS流程
项目和流程的关系:项目只做一次,追求可行解;流程反复做,最优解;(新人结婚对他们来说是项目,对婚庆公司来说是流程)
通用的做产品的流程:1.概念;2.方案;3.开发;4.验证;5.发布;6.生命周期维护;
流程的本质和目的
流程的目的:无论谁来做这个产品都能达到80分;流程的好处是人走了,事儿还能做,减少了特定人的影响.
当年的英雄把自己的个人经验转变成显性知识表达出来,而对于经常做的事情,就可以用流程这种东西固化,传承,后人在做这些事情的时候起码不会太无助.在这点上,规范,模板的作用也类似,这就是团队的核心竞争力.
核心竞争力:个人的核心竞争力是把显性知识转化为隐形知识的能力,团队的核心竞争力是把隐形的东西变成显性的知识的能力.
那么多评审可以省吗
产品会议:必须有; kickoff会议:最好开一下,鼓舞士气; 需求评审:如果kickoff之后只做一次评审那就是需求评审; 设计评审:开发人员实力很强省略; TC评审:仅次于需求评审; 功能评审:也是必须的,开产品演示会; 发布评审:开发经理决定;
评审会议不产生价值,尽量简化.
商业评审与技术评审
评审分两大类: 1.商业评审决定做不做;2.技术评审决定怎么做;
商业评审的三个决定:项目继续,重新定向,项目终止; 目的:砍项目.
技术评审的三个决定:项目继续,有风险的继续,必须解决某问题再继续; 需要避免技术评审的三部曲:抓壮丁,科普会,批斗会.
商业评审和技术评审两者最好分开. 没关系的人不要来参加,浪费时间.
敏捷更是手段
互联网就是快节奏,为了响应互联网的节奏,必须学会使用敏捷方法.
从书本到实践
几种经典的敏捷模式: 1.有计划,更要拥抱变化; 2.迭代周期内尽量不加任务; 3.集中工作,小步快跑; 4.持续细化需求,强调测试; 5.不断发布,尽早交付.
项目中的敏捷沟通
1.即时通讯IM群,事实沟通,群公告; 2.项目邮件; 3.项目看板,项目墙(保证进度,滞后有压力,滞后有人帮助); 4.吼.
与外包团队的敏捷尝试
1.强行敏捷会失败; 2.敏捷理念冲突有代价;但是,任何情况下,我们都要做好手头的事情,确保"这件事儿就算是凉了,我也要通过做这件事有所收获."
6.物竞天择适者生存
生小孩容易,养小孩难,少生优生.
亲历过的特色项目
如何做好老板项目
项目在保证质量的前提下,均衡时间T,人财物花费R,项目范围Q三点; T是给死的,给自己预留一段时间; R是丰富的,越多越好,省R往往不仅不讨好,反而觉着你没劲儿,思想不开阔. Q是可变的.合理算出巨大的R,老板无法付出R就会砍Q.排出各功能优先级和耗费的资源.
秘密行动,封闭开发
特别的项目,临时团队集中在会议室办公.称之为封闭开发.算敏捷方法的一种.
开发外包,项目外包
任何一个项目开始的时候,明确合作模式,划分权责.权责对等.
一路坎坷,你我同行
聪明人不会被同一块石头绊倒两次.
几个项目的成败
80%项目是不成功的; 小孩子越小越容易教,容易影响. 早一步是先驱,再早一步是先烈.
一次只有7天的战斗
临时下任务,一起战斗的感觉真好.
