朝着产品经理的方向
大步走去

第一个月的工作感受

产品经理的那点事阅读(566)评论(0)

再次返回工作岗位一个月了,对于我来说,这是一次崭新的工作机会,也拥有了全新的挑战。

我是非常非常幸运的,能在我入职后见证一个崭新项目的诞生,而也在接下来的几天,我也渐渐明白了,从无到有,是那么艰难的过程。

(1-7)项目的学习与交接,这个部分最大的困惑是提不出问题,其实上学的时候,老师讲提不出问题的看明白就是没明白,就是好多问题,思考的深度不够,可能也源于经验吧,不知道哪里会有坑,哪里需要注意。

(8-15)开始着手原型设计,感谢在我沉淀期看的小视频,以至于我不会一无所知,但也是手忙脚乱的。思考不全面,不知道理清所有的思路,只能想到哪点是哪点。而且三个系统交互,有时候在画第一个系统的时候,想到的想法,与其交互的部分,就完全忘记设计了。

(16-21)竞品好多啊,不知道该模仿哪个。失去了主心骨, 感觉哪个都不错,哪个也想模仿,最终,丢失了原本应有的理性分析,也就丢失了本该有的灵魂。

(22-28)周一暴露了我好多问题,并且好多是我没有想到的问题,可能归结于经验,在我看来是条件反射弧的形成,用编程语言就是if else。好可惜,这些都没有,只有一头笨鸟,飞到了玻璃房子里,一股脑的乱撞。还好,跟对老大很重要,在乱如麻的思绪里,剥茧抽丝了几条完整的思路。今天,学会了两个词,落地、闭环。不能落地的想法如空中楼台,不能闭环的设计如走入死路。

(29-35)一个周过的好快,转眼周五。原本乱如麻的思绪,抽出了几根思路,但都是不按照常理的思路。昨天晚上最后走一遍原型的时候,我突然间强迫症犯了,一个看自己设计产品看到强迫症犯了是一种怎样的体验?

还好,我还年轻,不是四五十岁,不是七老八十,还是一个可以学习的年纪,可以进步的年纪。

正好在等待一个时间点,写下这篇并没有什么思路的博客,总结下一个月来的点滴。

其实,我也突然明白了,做一枚好的产品汪,不在于会了什么技术,而是拥有了怎样的思想。

开发一个这样的 APP 要多长时间?

产品经理的那点事阅读(552)评论(0)

这是一个“如有雷同,纯属巧合”的故事,外加一些废话,大家请勿对号入座。开始了……

我有些尴尬地拿着水杯,正对面坐着来访的王总,他是在别处打拼的人,这几年据说收获颇丰,见移动互联网如火如荼,自然也想着要进来干一场,尽管王总从事的行当也算跟IT沾边,但毕竟太长时间不接触技术,有些东西不太熟,总要咨询下我这个在一线开发混了十几年的老程序员,十几年的开发,有好几种可能性,不过这不是重点,所以暂时忽略掉这个细节吧。

我之所以尴尬,是对王总的需求有些不知如何回答,仿佛陷入了某种习惯性的沉思中。

王总站了起来,把手机递到我面前,说:“你看看,就这样一个APP。”他不太熟练地在屏幕上划了几下,我并没有很认真地看,因为我知道这个问题很难,那就是所有的开发者都会被问,并且可能是被问得最频的一个问题:“开发这么一个APP需要多长时间?”我很想说不知道,这可能是最直截了当和准确的回答,但面对王总这位老朋友,我要是这么回答估计有些失礼,所以这个时候,我除了大致思量了一下他所指的那个APP大致涉及到哪些方面之外,还要组织下自己的语言,如何用非常得体的话告诉他,这个事情我估算不出。“你看,就这么简单的一个APP”,王总继续在屏幕上拨弄了几下,然后带着几分期待的眼神看着我。

我谨慎地说:“坦白说,我说不准,我这方面经验也不是很足,尽管做过APP开发,但又跟这个很不一样,得具体分析好所有的逻辑,才能估算出时间。”

王总对我的说法似乎不以为然,他晃了晃手机,说:“我要求不多,其实比这个还简单”,他指着屏幕上某些地方,继续说:“这个,这个,这个都可以不要,只需要这么一个列表,里面有详情,可以查看修改……”

我心里很自然地想到这是很典型的“想当然简单”的态度,我想我得让他认识到这个问题的复杂程度,我反问道:“需要登录吗?”

王总稍作停顿后,说:“那当然。”

“什么登录?用户名密码方式,还是手机登录,抑或像QQ,微博,微信这种可以借用的第三方登录?”

王总这回似乎想了一下:“作为移动互联网,我想手机登录肯定是要的,QQ,微博,对了,微信,微信最好也要……哦,你前面说用户名密码,这个应该也是要的吧。”

我很流利地接着问:“那总得有注册,如果你打算用手机登录,那得找个短信平台,还有微信登录,你得先做好企业身份认证,对了,有登录,有密码,那密码找回功能也得有吧。”

“这是肯定的。”

“同时有多种登录途径,你必须要想出一种合理的逻辑来将它们‘整合’,最常见的当然是账号绑定,例如给你的账号绑定手机号码,这样就能用手机号来登录同样一个账号,对微信登录也同理,但如今移动互联网的用户们都挺厌恶注册流程的,所以往往会要求直接手机登录或者直接微信登录,自动完成注册过程,那考虑这种情况,如果用户先用微信登录,然后再用手机登录,而不是绑定,那么就会产生两个不同的账号,而且无法将其再‘整合’起来,我们得想出一套比较完善的方案……”

王总对我所说的似乎有些缺乏耐心:“没必要这么复杂吧?你看看这个APP,这些不都有吗?”

“有没有我前面所描述的那个问题,你尝试过了吗?”

但王总似乎对问题并不关心,他只想知道做这么一个APP需要多长时间,当然要多少钱,这也是他关心的问题,他拿出了信心满满的语气:“有问题怕什么?困难算什么?这些我相信都能解决,但时间很要紧,得快,我们的竞争对手不会等我们,就这么一个东西,你想想看,要多久?”

看他的架势,像十足那种混得风生水起的成功人士,而我这种身份低微的程序员在他面前确实是有口难言,我本来还想继续告诉他细节的重要性,却被他打断:“不,不需要有多精确,你只需要估算一个范围,两个星期?或是两个月?”

我觉得我没必要再隐瞒什么了:“我真的不知道,也许一支优秀的团队两个星期就能做好(不过我自己可不相信有这么牛逼的团队),但我很明显不是那个能创造这种奇迹的人。”我心想其实就算说出了“两个星期到两年”这么一个开玩笑式的范围,也可能是错的。

王总似乎对我这样的回答很失望。但他是个执行力很强的人,想做一件事,就一定会行动,行动一定快,一定要有结果,这种雷厉风行的行事风格,确实,我挺欣赏,不过他的这个项目,我可真帮不上忙,但我还是出于礼貌,说道:“技术方面有什么问题,还是可以来问我的。”

====== 不怎么华丽的分隔线 ======

“做一个APP需要多长时间?”这个问题估计比测一个人还能活几天还难,一个条件如此不充分的问题,如何回答呢?

总体来说,需求越是明确,团队越是成熟,估算出来的时间就越是准确。而软件开发这个事情,不管发展多少年,不管提出了怎样的方法论,都没办法像传统制造业那样把“工时”算得那么精确,其内部错综复杂的逻辑关系使然,软件工程,绝无可能量产。

用户看到的只是一个APP,如果他用的是iOS系统,也许他根本就不会接触Android,不知道开发者除了iOS版之外,还需要做一个Android版,(有没可能还有Windows版?这样工作量无疑更大)或者,网页版搞定一切?也许你真正动手做过后就不会这么认为,再说微信小店那种模式真能适用于所有场合么?而且,如果不是网络出现异常的话,一般用户也不会注意到服务器的存在,服务器总是那么默默无闻地为用户全天候地工作,它的开发难度恐怕也不亚于APP本身,而负责APP运维的还需一些人力,大了之后甚至需要组建一个专业团队,他们需要一个“后台”,能随时查看和处理数据,如果需要随时随地都能查看和处理数据,恐怕还得给后台专门弄个APP。

这个道理就有点类似:我们看到了战机在天上华丽地完成了歼敌任务,以为只是战机本身很牛,往往忽视了战机相关的那些配套,如果没有娴熟的飞行员、作战指挥中心、地面雷达、预警机、补给、机场或航母、地勤人员等等,那么战机将失去战斗力。APP也一样,它不是一个只要能跑起来就完事的东西,支持它的配套设施和维护工作丝毫不比APP本身简单。

除开这些大的方面,细节上也带有许多的不确定性,所以一支成熟的团队尤为重要,一个经验丰富的开发者会知道,至少大致知道这个开发过程会遇到哪些问题,哪些问题比较简单,哪些问题则可能需要耗费大量的时间,这得依赖经验。我有一句话常常挂在嘴边,那就是:“没做过的东西别轻易说简单。”“想当然简单”的态度对项目没有任何好处,如果自己不确定,那么去咨询一个有这方面经验的人,就算得不到具体的答案也有大致的方向,沿着这些方向研究一下,就能知道会面临的那些问题,当然往往还不是全部。

关于“低估了难度”这事情,我过去的公司有个经典故事,当时有个小项目,就是准备把一套已经在仪器上使用的只支持英语的程序增加多语言支持,程序并不大,涉及内容也不算太多,工程师一开始认为这只是个简单的翻译工作,顶多两个星期就能完成,但一做下去就发现不简单,首先翻译得找专业人士来做,自己做不好,我们没人精通欧洲各国语言,接下来还有单位换算,有些国家用公制,有些用英制,这个得考虑,包括日期显示格式也得考虑,一下子不知道多了多少工作,这些都差不多了之后又发现了德语单词过长,我们的仪器的屏幕显示不下,超出范围,于是再调字体,做精简,前前后后开会讨论了N次,最后想Release的时候发现这么一改,程序的Size变大了很多,有些仪器的存储器装不下,这下大家可都傻了,优化呗,精简呗,程序开始有些凌乱不堪了,最后勉强通过质控部检验,总算发布了,发觉足足搞了半年。不过如今想想之所以耗费了这么多时间,一个很重要的原因是经验不足,对多语言,国际化这块不熟,走了不少弯路,所以我前面也提到,成熟的团队尤为重要。

我们在估算项目时间的时候,往往只算了“写代码的时间”,而把那些和老板或客户扯皮,做需求分析,设计,测试,和修复bug的时间不考虑进去,而这些时间加起来通常比写代码的时间多出不少,我个人是不轻易为了讨好老板而把完成时间说得很短的,为啥?——根本做不到嘛,干嘛要撒谎?如果一个需要一星期完成的新功能开发,我通常得把这个时间double,这已经算比较“不保守”的了。

即便只算写代码的时间,也往往会被低估,老板或客户对你开发的东西很可能不满意,或许你误解了他的功能需求,或者界面有点卡顿,或者这个图标颜色不好看,你是开发者,不是美工,虽然凑合可以当一下美工,但毕竟不专业,更重要的是做做UI设计,做做图这种事情,也得耗费不少时间,当你为“一个像素”焦头烂额的时候,是不是很渴望团队中有一名设计师?这时候得提醒下老板:你必须要在时间和功能之间,做点取舍。老板当然很不高兴,但也不得不在功能上做出了一些妥协。虽然这样做能让难产的项目早点上线,但却为来日项目的失败,给老板添加了一个很好的借口:我们的工程师太差了,没按我说的去做。

老板或客户除了会抱怨你做出来的东西不够好看之外,还会再提很多东西:这个界面能不能改成多选,能否增加通知功能,已读未读状态要有,界面能不能再流畅点,昨晚程序咋“闪退”了一次……需求只管提功能,但没说具体这个UI要多美观,也没说程序稳定性要好,更没涉及到要达到多大的吞吐量,当然,可能更重要的——安全性也没提,你心一惊:是啊,如果有黑客,不,只要稍微懂一点技术的恶意用户想刷爆我们的服务器,那简直太简单了,而这些防护措施我都没做!所幸的是项目名气太小,暂时无需考虑这个。(貌似大多数APP都活不到需要考虑这个的时候)

所有这些,你说功能也好,细节也好,稳健性也好,都不是能自动从土里长出来的东西,都得需要花时间去想,去做,有些甚至还是个“系统工程”,如果头痛医头脚痛医脚去做的话,系统里到处充满“飞线”,无疑会给将来的维护留下了许多隐患。攻城狮的你,都考虑了吗?更别说老板为了节省成本而给你购置的低性能电脑让你整天抓狂这些“无关紧要”的事。

====== 不怎么华丽的分隔线 ======

话说王总告别我之后就以迅雷不及掩耳之势注册了公司,注册了域名,搞到了办公室,还一下子叫来了一帮子人风风火火地搞了起来,这种发展势头,这种干劲,我只有自叹不如。心底里真有些后悔怎么没跟他去干事业,不过这只是感性的一瞬间,理性又在接下来的几百毫秒里将我拉了回来:还是别去好,跟他沟通不来的。

王总的项目后来以一飞冲天之势迅猛发展,而他如今已经是一家估值几亿的公司的CEO,我嘛,越来越觉得自己是个Loser,独自坐在办公室里,还是拿着那个水杯,懊恼不已——打住!这样是不是比较有戏剧性?可虽然一开始我就声明此故事“如有雷同,纯属巧合”,但也不能胡乱瞎编,真正的结局是:确实风风火火弄了几个月,后来就突然杳无音讯了,本来想打电话问问王总究竟怎样,无奈他变成了另一个超级忙人,再无心思跟我聊家常了。嗯,结局还是差不多,我还是那个继续苦逼地坐在办公室里的程序员,唉,别想了,开工吧!

产品需求文档(PRD)编写分享与参考之PMCAFF APP

产品经理的那点事阅读(1116)评论(0)

为什么写这篇文章?

第一:写PMCAFF 的PRD文档,大家都是用户,比较好参考与理解,方便大家来找我写的不好的地方。

第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。

关于这篇文章:

1.PRD本来就没有固定的版式,根据团队以及个人的需求有所差别,本篇力求简单,不累述。

2 .这篇PRD可以再写的详细些,因为怕内容太多阅读太麻烦,对于需求说明以及用例做了一些简化与合并。

3.此文档为 逆向文档 ,一般的文档中的界面示例应该是产品原型图(线框图,高低保真图)

修订记录:

一、 简介

本文档主要定义PMCAFF  APP的功能详细描述和前端页面的各个模块的内容和逻

1.    目的

此文档的目的主要是清晰、有层次的定义页面原型中各个模块的内容来源和相关逻辑。

2.    范围

此文档主要描述PMCFF APP中前端页面涉及到的功能点、相对应的后台管理功能支持、以及部分交互细节。本文档主要读者为技术部的前端工程师,以及视觉部的视觉设计师。

二、 用户角色描述

三、 产品概述

最大化满足市场和产品以及运营工作者对于产品学习、交流、讨论、社交、求职,以及开展与产品相关的组织和活动所产生的需求,为用户带来一个全面的 服务、组织与对接平台和优秀的用户体验,为公司带来固定的高粘度的用户,带给用户有价值的社区,构建帮助用户提升技能,拓展交际,快速学习与思考工具与平 台。

1.目标

构建全国最大的产品类社交、学习交流与求职线上平台。

2. 总体流程

3. 产品结构图

4. 产品信息结构图

5. 功能摘要

四、 产品特性

1.登陆注册

1.1需求说明

1.2用户界面

1.3用例流程

2.提问与搜索

2.1需求说明

2.2用户界面

2.3用例流程图

3.主题导航列表页

3.1需求说明

3.2用户界面

3.3用例流程图

4.问题(文章)内容页面及互动

(此模块可以再细分进行用例说明)

4.1需求说明

4.2用户界面

4.3用例流程图

5.个人资料

5.1需求说明

5.2用户界面

5.3用例流程图

6.消息中心

6.1需求说明

6.2用户界面

6.3用例流程图

7.个人中心(我的互动)

7.1需求说明

7.2用户界面

7.3用例流程图

8.设置

8.1需求说明

8.2用户界面

8.3用例流程图

8.3.1忘记密码

8.3.2修改手机号码与密码

五、 其他产品需求

1.    性能需求

前端阅读页面以及列表页面,需滚动流畅,滚动阅读时不停顿不卡顿。

后台数据处理能力应满足几十万用户的操作使用。

更改与设置密码与手机号时,后台应立即发出短信。

2.    监控需求

3.    兼容需求

需兼容iPhone4及以上机型,iPad2和iPad mini及以上机型、touch5,并且需支持iOS7.0或更高版本

六、 风险分析

七、 相关文档

APP UI原型文档、后台管理文档

如何减少软件项目的不确定性带给我们的惊讶

产品经理的那点事阅读(583)评论(0)

项目会有什么潜在风险

计划编制风险

计划、资源和产品的定义完全由客户或上层领导决定,忽略了软件项目组的意见,并且这些决定不完全一致。
计划忽略了必要的任务和活动。
计划不切实际。
计划基于特定的项目组人员,而这样的项目组人员得不到。
软件规模估算过于乐观。
工作量估算过于乐观。
进度的压力造成生产率的下降。
目标日期提前,但没有相应地调整产品范围和可用资源。
一个关键任务的延迟导致其他相关任务的连锁反应。

组织和管理风险

缺乏强有力、有凝聚力的领导。
解雇人员导致软件项目小组能力下降。
削减预算打乱软件项目计划。
仅由管理层和市场人员进行技术决策。
低效的项目组织结构降低软件开发的生产率。
管理层审查/决策的周期比预期时间长。
管理层作出了打击软件项目组积极性的决定。
非技术的第三方的工作比预期要长(如采购硬件设备)。
计划性太差,无法适应期望的开发速度。
软件项目计划由于压力而放弃,导致开发混乱。
管理方面的英雄主义,忽视客观确切的状态报告,降低发现和改正问题的能力。

开发环境风险

开发设施和工具不能及时到位。
开发设施和工具到位但不配套。
开发设施和工具不如期望的那样有效。
开发人员需要更换开发设施和工具。
开发设施和工具的学习期比预期要长。
开发设施和工具的选择不是基于技术需求,不能提供计划要求的功能。

最终用户风险

最终用户坚持新的需求。
最终用户对交付的软件产品不满意,要求重新开发。
最终用户不买进项目产品,无法提供后续支持。
最终用户的意见未被采纳,造成软件产品无法满足用户要求。

承包商风险

承包商没有按照承诺交付软件产品。
承包商提供的软件产品质量低下,必须花时间改进质量。
承包商提供的软件产品达不到性能要求。

需求风险

需求已经成为软件项目基准,但仍在变化。
需求定义欠佳:不清晰、不准确、不一致。
增加了额外的需求。

产品风险

错误发生率高的模块,需要更多的时间对它进行测试和重构。
矫正质量低下的软件产品需要更多的时间对它进行测试和重构。
由于功能错误,导致需要重新进行设计和实现。
开发额外不需要的功能延长了进度。
要满足软件产品规模和速度要求,需要更多的时间。
严格要求与现有系统兼容,需要更多的时间。
要求软件重用,需要更多的时间。

人员风险

招聘人员所需的时间比预期要长。
作为开发人员参与工作的先决条件(如培训、其它项目的完成等)不能按时完成。
开发人员与管理层关系不佳导致决策迟缓、影响全局。
项目组人员没有全身心地投入到项目中,无法达到所需的软件产品功能和性能需求。
缺乏激励措施、士气低下。
缺乏必要的规范,增加工作失误,重复工作,降低工作质量。
缺乏工作基础(语言、经验、工具等)。
项目结束前,项目组人员离开软件项目组。
项目后期,加入新的软件开发人员,额外的培训和沟通降低了软件项目组人员的开发效率。
项目组人员不能有效的在一起工作。
由于项目组人员间的冲突,导致沟通不畅,设计欠佳,接口错误和额外重复的工作。
有问题的项目组人员没有及时调离软件项目组,影响其他人员的工作积极性。
最佳人选没有加入软件项目组,或者加入软件项目组但没有合理使用。
项目组关键人员只能兼职参与。
项目组人员的数目不足。
任务的分配和人员的技能不匹配。
人员工作的进展比预期的要慢。
项目管理人员怠工,导致计划和进度失效。
技术人员怠工导致工作遗漏、质量低下,工作需要重做。

设计和实现风险

设计过于简单,考虑不仔细、不全面,导致重新设计和实现。
设计过于复杂,导致一些不必要的工作,影响效率。
设计质量低下,导致重新设计和实现。
使用不熟悉的方法,导致需要额外的培训时间。
产品使用低级语言编写,导致开发效率较低。
分别开发的模块无法有效集成,需要重新设计和实现。

过程风险

跟踪不准确,导致无法预知项目进展是否落后于计划。
前期的质量保证行为不真实,导致后期的重复工作。
没有遵循标准,导致沟通不足,质量问题和重复工作。
风险管理粗心,导致没有发现重大的软件项目风险。
风险影响多大

发生可能性

怎么应对

制定风险管理计划

针对各个重要风险制定风险管理计划,并确保它们的一致性;

 避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。

风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。

变化是可以控制的 纠偏

软件项目干系人管理

产品经理的那点事阅读(1026)评论(0)

什么是干系人

是指参与项目和受项目活动影响的人

软件干系人

干系人管理

项目干系人管理是对沟通进行管理,以满足项目干系人的需求并与项目干系人一起解决问题。对项目干系人进行积极管理,可促使项目沿预期轨道行进,而不会因未解决的项目干系人问题而脱轨。同时进行项目干系人管理可提高团队成员协同工作的能力,并限制对项目产生的任何干扰。通常,由项目经理负责项目干系人管理。

1、项目干系人分析

识别出项目的干系人,并对干系人的兴趣、影响力等进行分析,明确干系人真实需求和期望与贡献;

2、沟通管理

根据项目干系人分析的结果,制定相应的沟通计划,并执行,主动沟通达成共识;

3、问题管理

对沟通过程发现的问题,记录,并采取行动进行解决;

*

满足要求不代表满意,,无视潜在需求可能会导致项目失败

软件开发项目管理内容

产品经理的那点事阅读(918)评论(0)

软件开发项目管理内容

1、 项目范围管理
是为了实现项目的目标,对项目的工作内容进行控制的管理过程。它包括范围的界定,范围的规划,范围的调整等。
2、 项目时间管理
是为了确保项目最终的按时完成的一系列管理过程。它包括具体活动界定,活动排序,时间估计,进度安排及时间控制等项工作。很多人把GTD时间管理引入其中,大幅提高工作效率。
3、 项目成本管理
是为了保证完成项目的实际成本、费用不超过预算成本、费用的管理过程。它包括资源的配置,成本、费用的预算以及费用的控制等项工作。
4、 项目质量管理
是为了确保项目达到客户所规定的质量要求所实施的一系列管理过程。它包括质量规划,质量控制和质量保证等。
5、 人力资源管理
是为了保证所有项目关系人的能力和积极性都得到最有效地发挥和利用所做的一系列管理措施。它包括组织的规划、团队的建设、人员的选聘和项目的班子建设等一系列工作。
6、 项目沟通管理
是为了确保项目的信息的合理收集和传输所需要实施的一系列措施,它包括沟通规划,信息传输和进度报告等。
7、 项目风险管理
涉及项目可能遇到各种不确定因素。它包括风险识别,风险量化,制订对策和风险控制等。
8、 项目采购管理
是为了从项目实施组织之外获得所需资源或服务所采取的一系列管理措施。它包括采购计划,采购与征购,资源的选择以及合同的管理等项目工作。
9、 项目集成管理
是指为确保项目各项工作能够有机地协调和配合所展开的综合性和全局性的项目管理工作和过程。它包括项目集成计划的制定,项目集成计划的实施,项目变动的总体控制等。

软件开发过程模型

产品经理的那点事阅读(721)评论(0)

软件开发过程模型主要有:
瀑布模型(V模型、喷泉模型 )
螺旋模型
原型模型(锯齿模型、快速原型)
构件组装模型 (增量模型)
统一软件过程RUP模型

1. 瀑布模型

 

 

A. 瀑布模型特征

从上一项活动接收该项活动的工作对象,作为输入
利用这一输入实施该项活动应完成的内容;
给出该项活动的工作成果,作为输出传给下一项活动;
对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。

B. 瀑布模型的优点

通过设置里程碑,明确每阶段的任务与目标
可为每阶段制定开发计划,进行成本预算,组织开发力量
通过阶段评审,将开发过程纳入正确轨道
严格的计划性保证软件产品的按时交付

C. 瀑布模型的缺点

缺乏灵活性,不能适应用户需求的改变
开始阶段的小错误被逐级放大,可能导致软件产品报废
返回上一级的开发需要十分高昂的代价
随着软件规模和复杂性的增加,软件产品成功的机率大幅下降

2. 螺旋模型(图)

A. 螺旋模型的特征

每一圈是一个阶段,每个阶段里又有一些活动
阶段可分为:操作的概念、软件需求、产品设计、详细设计、编码、单元测试 、集成和测试、验收测试、实现
活动有:需求与计划、风险分析、设计与制作、用户评价

B. 螺旋模型的优点

风险分析可使一些极端困难的问题和可能导致费用过高的问题被更改或取消
用户评价为需求的变更带来柔性

C. 螺旋模型的缺点

需要开发人员具有相当丰富的风险评估经验和专门知识
要求用户参与阶段评价,对用户来说比较困难,不易取得好的效果

3. 原型模型(图)

A. 原型模型的特征

立项以后先提交原型给用户,在用户试用的基础上进行需求调查与原形修改
强调用户对软件功能和使用性能的评价
设计、修改原型与试用交替进行
一次迭代中的开发步骤:
*了解用户/设计者的基本信息需求
*开发初始原型系统
*用户/设计者试用和评估原型系统

B. 原型模型的优点

开发者与用户充分交流,可以澄清模糊需求,需求定义比其他 模型好得多
开发过程与用户培训过程同步
为用户需求的改变提供了充分的余地
开发风险低,产品柔性好
开发费用低,时间短
系统易维护,对用户更友好

C. 原型模型的缺点

开发者在不熟悉的领域中不易分清主次,原型不切题
产品原型在一定程度上限制了开发人员的创新
随着更改次数的增多,次要部分越来越大,“淹没”了主要部分
原型过快收敛于需求集合,而忽略了一些基本点
资源规划和管理较为困难,随时更新文档也带来麻烦
只注意原型是否满意,忽略了原型环境与用户环境的差异

4. 构件组装模型/增量模型(图)

A. 构件组装模型的特征

应用软件可用预先编好的、功能明确的产品部件定制而成, 并可用不同版本的部件实现应用的扩展和更新。
利用模块化方法,将复杂的难以维护的系统分解为互相独立、协同工作的部件,并努力使这些部件可反复重用。
突破时间、空间及不同硬件设备的限制,利用客户和软件之间统一的接口实现跨平台的互操作。

B. 构件组装模型的优点

构件组装模型导致了软件的复用,提高了软件开发的效率,面向对象技术是软件工程的构件组装模型的基础。
构件可由一方定义其规格说明,被另一方实现,然后供给第三方使用。
构件组装模型允许多个项目同时开发,降低了费用,提高了可维护性。
可实现分步提交软件产品。

C. 构件组装模型的缺点

可重用性和软件高效性不易协调。
缺乏通用的组装结构标准,而自定义的组装结构标准引入较大的风险。
需要精干的有经验的分析和开发人员,一般的开发人员插不上手。
客户的满意度低。

5. 统一软件过程RUP模型(图)

A. RUP模型特征

RUP 可以用二维坐标来描述。横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段 (Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的 术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。

RUP的时间轴

被分解为四个顺序的阶段,分别是:
初始阶段(Inception)、
细化阶段(Elaboration)、
构造阶段(Construction)和
交付阶段(Transition)
每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。

RUP的阶段目标

初始阶段的目标是为系统建立商业案例并确定项目的边界。
细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。
在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。
交付阶段的重点是确保软件对最终用户是可用的。

RUP的核心工作流

RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期 中一次又一次被访问。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。

核心过程工作流

商业建模工作流为组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。
需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。
分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。

核心过程工作流

实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。

核心过程工作流

测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现,识别、提出缺陷并确认缺陷在软件部署之前被处理。
部署工作流的目的是成功的生成版本并将软件分发给最终用户。

核心支持工作流

配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物,管理演化系统中的多个变体,跟踪软件创建过程中的版本。
软件项目管理平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。
环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。

B. RUP模型的优点

RUP 具有很多长处:提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的 开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构,为开发过程提供较大的通用 性。

C. RUP模型的缺点

一些不足: RUP只是一个开发过程,并没有涵盖软件过程的全部内容,例如它缺少关于软件运行和支持等方面的内容;此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。

流行的个人博客系统系统对比

产品经理的那点事阅读(793)评论(0)

一、WordPress博客系统

WordPress官网:http://cn.wordpress.org/

WordPress是基于PHP+MySQL开发的开源博客产品,是当前最热门的博客系统之一。不管是个人博客还是企业博客,多有着相当大的使用量!为什么有这么多的用户喜欢它呢?我认为有以下优点:

优点

1、安全性高
WordPress安全性高,勤勤恳恳的开发团队,程序的不断升级,WordPress已经到了非常完美的阶段,很少听闻WordPress被黑的案例。
2、模板多
就算你不会网页制作,同样也可以使博客变得很漂亮。因为WordPress模板众多,分分钟都有新的模板被制作完成并免费提供下载,国内也不乏优秀的WordPress模板开发者及模板下载平台。WordPress后台选择模板也非常方便,切换模板一键搞定。
3、强大的插件
插件是用来帮助WordPress扩展功能的,几乎你想要的每一样功能都能找到插件支持,并且往往不止一个选择。这一点是wordpress最强大的地方。
4、利于SEO优化
都说wordpress博客系统天生就受到搜索引擎的青睐,其实不难理解,博客系统结构简单,博客的性质也决定了网站文章原创度更高,还有WordPress简单的站内优化设置,后台生成伪静态。
5、安装简单
WordPress大概是最容易上手的网站程序了,程序安装5分钟搞定,就算是新手,也可以在半小时内学会搭建WordPress博客。后台傻瓜式管理,主题,插件,都可以在可视化后台按键完成,就算你不懂任何一句代码,也能轻松安装使用。

缺点:

1、不能真正意义上实现静态化,只能实现伪静态。

2、但是不能安装太多插件,否则会拖累网站速度和降低用户体验

3、由于wordpress是php语言搭建的,在windows主机空间上并不能完美支持 wordpress,所以一般只能在linux主机上运行。

4、Wordpress转移与备份麻烦,需要涉及到数据库

二、Emlog博客系统

Emlog官网:http://www.emlog.net/

Emlog是基于PHP+MySQL开发,致力于提供快速、稳定,且在使用上又极其简单的博客系统。
1、强大插件功能
支持强大的插件扩展功能,随意选择实用的插件,让你的博客无限可能
2、自定义页面
轻松创建留言板、导航条、博主介绍等个性页面 足够小巧简单。
3、体积小、灵活
emlog博客系统几百k的数据让我们眼前一亮,相对于其他博客系统的来说,它显得非常小巧。

三、Z-Blog博客系统

Z-Blog官网:http://www.zblogcn.com/

优点

1、程序环境
Zblog博客系统是ASP程序,而且不用独立的数据库。相对于WordPress、emlog这两款程序有明显的优势,因为那两款是PHP环境,需要MYSQL数据库的支持。
2、页面静态化
Zblog程序只需要简单的配置,就可以实现页面静态化,页面静态化有利于搜索引擎的收录。
3、网站迁移
因为zblog不依赖于独立的数据库运行,在网站整站迁移过程中,只需要使用FTP直接下载,到另外一个主机上传,即可完成了迁移,整个迁移过程非常简单;WordPress、Emlog依赖独立的数据库,在网站迁移过程中都需要正确的备份好网站程序及数据库,迁移完成后,还要重新配置网站数据连接等等,整个过程就比zblog复杂多了。

缺点

Z-Blog博客的asp语言,由于asp捆绑在iis上,对主机空间的受到限制,并不能多平台使用。

总结

三大博客系统各有千秋,不过本人推荐使用wordpress。因为使用wordpress的人多,很多人又愿意为它开发插件,使其功能上很强大。模板也多,就算不会程序代码,同样也也可以使博客做的很漂亮,是建立博客首选之一。

网站运营之身边的SEO

产品经理的那点事阅读(272)评论(0)

每天上网,或多或少,我们会用到百度。

不论是查资料,看电影,还是网购,都会第一时间去百度。

有没有想过这么一个问题:百度出来的网站,为什么有的排名靠前,有的排名靠后呢?

有人说跟网站点击量有关?

有人说是随机的排的?

这些说法是只知其一,不知其二。

我们把影响网站排名的因素,统称为seo。

Seo是Search Engine Optimization的简称,汉译为搜索引擎优化。

简单的说,seo就是通过对网站的优化,提升它在搜索引擎中的排名。

排名越靠前,得到展示的机会就越多,展示机会越多,商业价值就越大。

从它的字面意思,可以看出来。Seo是伴随着搜索引擎的诞生而诞生的。

试想,我们为什么在百度里可以搜索到其他网站呢?

这是因为百度收录了各种网站。百度里如果没有网站,我们还会去百度吗?

不会,所以,百度刚出来的是时候,就是拼命的收录各种网站。

那个时候seo是很好做的。

比如,你的网站是卖二手电脑的,只要在网站上,写很多关于二手电脑的内容。你在百度一搜二手电脑,第一页就能找到你。

有天,你又改卖沙发了,又在网站上写很多关于沙发的内容,一搜,又搜到你了。

这就是最早的seo。

后来,人们在搜二手电脑的时候,跑到了卖沙发的网页。慢慢的,用户体验差了,去百度的人少了。

为了改善用户体验,百度开始改变排名规则,让那些是符合大家需求的页面排到前边,偷梁换柱的排到后边。

于是站长们又开始研究,百度的排名规则,发现,只要尽可能多的添加加关键词链接,排名就可以上去。

这时用户体验又差了,百度只好再改排名规则,对网站在短时间内,添加过多链接的网站,进行处罚,降低排名,甚至k掉。

百度不断的改变排名规则,站长们也在不断研究。比如,有规律的、定期的更新文章内容、网址的静态化等都可以提高百度排名。

这里,我们发现百度排名规则的改变,都是围绕用户体验。而受到惩罚的网站,多是钻到了百度的漏洞。

靠钻百度漏洞提高排名,都是短暂的。试图通过黑帽seo,短时间内提高网站排名的,终究是不会长久的。

只有站到用户的角度,真真正正去做网站的排名才会越来越好。

理解了百度的两变,seo就会成为日不落的太阳。

百度的方向从来没变,一切都要符合用户体验,用户就是上帝。

百度的规则一直在变,一切试图靠漏洞提升排名的都不会长久。

我说过,网页制作将会成为人们找工作的一个基本技能。所以,只会做网站是不够的。

网站是什么?就是个工具。

学会了网站,还需要学什么,那就是营销。Seo则是网络营销的一个重要手段。

但是不要把所有希望寄托在它身上,如今我不会像09年时候,刻意的、疯狂的去做了。

应学生的要求,我说说,多年来,我对seo的认识。

第一是心态,以归零的心态,来做seo,会越来越好。seo是道,不是术。

如果你把它当成术了,就注定了,你很难做好。

第二,进行换位思考,围绕用户体验去做。

比如说,给网站添加友情链接,是有助于排名呢?还是不利于排名?

这里的关键就是把握好“度”。

我们把网站与网站之间的链接,理解成彼此间的投票。

网站多一个友情链接就是多一张投票。那是不是投票越多越好呢?

不是,班里选班长,全票赞成,可能吗?基本上不可能,不符合实际。

因为不符合实际,所以做链接也是这个道理。

再说个,首页title的定义吧。

网站关键词之所以可以取得好的排名,title里一定要首先包含这个词。这就要求,网站上线前,一定要把标题写好。

我的title是郭朋涛网页设计博客,从来没有在意过。一天在搜索的时候,突然发现搜“网页设计博客”,我的博客排名第一。

百度蜘蛛一旦收录了,再修改就费事了。所以,标题千万不要频繁修改。那是不是就一定不能再修改了呢?

也不是,首先上线之前一定要想好,其次,如果必须修改,偶尔修改,细微的修改也是没事的。

人都没有十全十美,哪个人没犯过错啊,何况改个标题呢?

Seo不要刻意为之,同时把握好“度”。

Seo还应该注意什么呢?

除了上述所讲的,网站内容保持原创性,定期更新,网站结构要符合seo,适当的出现锚文本。

做好这些,其他的什么关键词密度啊都是浮云。

Seo不是ceo,就在我们身边,差一个字母,就差了一个行业,与你与我,息息相关。