关于文档的一些看法

关于文档的一些看法

手头上的项目,无论大小,想做的好,最好有一些文档来支持。文档又分为技术类的文档和设计类的文档。

当我在做文档的时候,我尝试着把两者合并起来发现其结果是不好的。而从技术的角度去出发写出来的东西总会让人觉得让团队的其他人看不明白,所以我认为最好还是分开处理。

 

技术文档

规定相关的简单api,无论用什么语言,你要告诉程序开发人,我要这样的一个接口来实现功能。

我们以一个商城类的网站作为说明

 

数据模型拥有的基础属性。

Class Base {

Function index(){ }  //列表,首页

Function edit(){}  //编辑操作

Function new(){}  //新建操作

Function save(){}   //新建保存

Function update() {} //编辑保存

function delete() {}  //删除操作

Function …..//延伸操作,暂不考虑

}

 

具体拓展

//会员中心

Class member_base extends base{}  //继承

Class member_index extends member_base{}  //会员中心首页

Class member_order extends member_base{}  //会员中心订单类

Class member_good extends member_base{}  //会员中心商品类

Class member_profile extends member_base{}  //会员中心个人信息类

………以此类推

 

同样道理我们也可以继续做管理中心的一些规定设计,其实这个规定是给技术总监去看的,具体实现由他来把控,但是这些方法不要出现纰漏,也不要出现增加,如果需要讨论,可以听取意见对该方案进行修改。方案一旦确定就不允许超出。规定数据的边界。哪些是边界,到这里结束,不必要多走一步。框出一个范围,在第一个版本v1的时候,不去尝试考虑其他的设计。

 

设计文档

相比技术文档的艰涩难懂,设计类文档要开放很多。主要是针对需求进行整理。由此我们可以得出,设计类文档要做在技术文档之前。考虑的一个标胶全面的设计文档,我们就可以用来写技术的相关接口和大致规定以及边界。

 

理解需求

你要做一个什么样的项目,他的需求是什么,左后需要做到的目标如何,还以商城为例。

  1. 管理中心

a) 管理审核用户

i. 会员等级

ii. 会员操作(审核)

iii. ……

b) 管理审核订单

i. ……

c) 管理审核商品

i. 商品属性描述(分类,名称,价格,单位……)

ii. 商品操作(审核,删除,)

d) 系统设置

i. 杂七杂八的时间,

ii. 数据库简单管理

iii. ……

e) 新闻管理

i. 新闻属性(分类,名称……)

ii. 删除

iii. 推荐

  1. 会员中心

a) 订单管理

b) 资金管理

c) 个人信息

d) 商家服务

  1. 商家中心

a) 商品管理

b) 资金管理

c) 订单管理

d) 个人信息

e) 商家服务

  1. 前台页面

a) 首页

b) 商品列表

c) 商品详情页

d) 新闻,通用列表

e) 新闻,通用详情

f) 会员中心页面

g) 商家中心页面

 

  1. 以此类推

 

在规定这个文档的时候,我们要对属性有一个清楚的认识。商品的属性,直接影响数据库的设计。还有就是订单的状态和商品的状态。我的建议把属性,和流程状态单独做出流程图来详细处理,描述,当然所有的一切你都有必要和技术总监进行沟通,让他能够很好地理解你的想法。从而在其设计数据库的时候能够比较到位的处理。避免中心思想发生变化。沟通和理解是必须的,否则这个V1文档即使出来了,也没有很强的作用。更多的参与,会解决交付的困难。

 

我的理解,文档涵盖以下几个方面

  1. 需求文档(产品雏形理解需求)
  2. 设计文档(概要)—-设计文档(v1版本详实记录)
  3. 技术文档(概要)
  4. 项目综合文档。(给投资人看的。过程,结果,准备。)通常到第四个文档出来的时候,就是这个项目究竟做不做的关键了。
  5. 用户体验文档
  6. FAQ文档
  7. 时间规划文档
  8. 设备以及资金投入

 

这些东西在说的时候很容易,但是真正去实施和交付,其实还是比较庞大的工程。做任何一个项目,都是方方面面的成功才能做好。前期安排的妥当,后面就容易把控产品的品质。

 

需要技术总监提供,详实的技术设计文档,包含数据库设计,方法实现。

需要市场营销总监提供,预期市场推广方案,和资金投入,以及v1版本的用户体验

需要产品设计总监提供,原型线框图和界面设计文档

需要用户体验小组,提供技术的问题,和faq的维护提交

最后需要产品经理,追踪产品进度,把控总体方向,协调各部门修改,想vc汇报产品开发进程,推进v2版本的加速进行。

 

 

就先到这里吧,我太懒了,要全写完太多了,改日吧。

 

闲聊初期的产品

世界上没有两片完全相同的叶子。
互联网长河中的几十年,革新的例子屡屡出现,但是我们也不能说,乔布斯的苹果就一定是和以往的通讯产品有着多么本质的不同。想起很早以前,实体按键还是主流的时候,有人嘲笑,苹果的虚拟触屏根本不可能成为主流的时候。现在看,耳光被打得响亮。
别人做过的东西,如果非要另辟蹊径再去找寻一条完全不同的路,那是非常困难的。事物总是相生相克的。而且即便你找到了一款这样的产品,怎么样去让他更加推广开来,是一个很严肃的问题。作为产品的开发者,对自己的产品往往具有强于用户的上百倍的信心,然而这并没有什么用处。
对于经验尚浅的产品开发者而言,我想可以通过一些简单而又容易模仿的例子来运营自己的产品。当然你还要做到以下几点:
1.产品的一般属性。
2.产品的易用性。
3.进度的控制,风险的评估。
4.客户的维护。

继续阅读“闲聊初期的产品”

杂念(关于微信)

之所以说是杂念,必是有感于斯。

偶有时间,亦算是吐槽一番。这次主要还是想说说微信。

说微信就要说互联网,互联网是什么,上网,游戏,看小说,看视频资源,了解各种各样的吐槽。

在这个圈子呆了五六年的时间,芝麻开花节节高,按道理说这样一个新鲜事物应该可以茁壮成长的,可是偏偏在小城市就是发展不起来。数不胜数的惨痛教训,一次次在警告着我们这些做互联网的凡夫俗子,太天真。

技术上从C到C++,到MFC,从CS到BS,从php到node.js,从javascript到jquery,从css2到css3,以至于现在流行的html5……

看问题我说过要抓住本质,无论是哪种语言,前端,后端,哪种服务器,linux和windows都不会是一沉不变的,互联网也是如此,而掌握互联网变化的关键是那些大佬们,他们引领的是中国互联网,当一线城市早就把微信营销做透的时候,我再回头揣着这样一个理念回到洛阳,能成功多少?

继续阅读“杂念(关于微信)”

新浪微博二三事

简单的说明下,其实新浪微博目前的市场占有量已经是拔尖的优势,从其拥有的受众和影响力来看,新浪确实走到了很多其他想做“白社会”的网站的前面,虽然后面的腾讯微博在不断地追赶新浪,但是无奈好像有点吃力,也正是由于腾讯的压力,所以才使得新浪的微博越来越好。

继续阅读“新浪微博二三事”

腾讯“平台开放”这一步要走的稳千万别闪着

自打3q大战之后,好像没有什么大事情来打扰我们这些互联网的平头百姓了。像小澎一样过着简简单单的互联网生活的人确实又多了起来。所以才有闲心来照看照看“家里的事情”,注诸如“关心关心女朋友啊什么的。”不敢说劈柴喂马,也算是平静怡然。

最近,腾讯做出了一个开放平台的决定,马化腾同志做出了“八个选择”,不可谓不够给力,只是小澎想腾讯这样做了之后(或者说说出了这样的话语之后)得到的是真的像他所说的更大的场面呢,还是更大的利益?这两个“更大”如果搞清楚了,对于中国的互联网的发展之路也许就简单明了了。

继续阅读“腾讯“平台开放”这一步要走的稳千万别闪着”

腾讯将会成为手机平台上的主角

我觉得运营商打来打去,其实谁也消灭不了谁。未来真正颠覆运营商的是腾迅。每个终端都是智能手机就是个PC了,语音短信彩信都在IP上跑了,更不要说互联网服务了,号码没有意义,传统语音短信服务的信令也没意义了,大家买包月上网,运营商退居后台管道化,QQ成为最大的虚拟运营商直接控制用户。(周鸿祎)

继续阅读“腾讯将会成为手机平台上的主角”

互联网的弹窗大战

以前是QQ一家弹窗,可能大家都还觉得没有什么,弹下说不定还能方便用户呢,可是自打今年开年,暴风影音,飞信,搜狗拼音,pps,迅雷等等相继弹窗,这究竟是谁的错?用户们就在这样的情况下被一而再再而三的惊扰,一时间,开开电脑,窗口不断,要重复的去找究竟关闭按钮的小“X”在哪里!烦透了,也伤透了。

继续阅读“互联网的弹窗大战”