研发的那些事
1--两项核心工作的关系http://www.cnblogs.com/Chaos/archive/2011/02/20/1959100.html
曾经有一群人，将自己的想法变成一个个小孔，打在纸带上，他们把这纸带叫做Program——程序。将它塞入被称为Computer的机器中，然后恭敬的等待机器重新吐出一段纸带，拿着欢喜地去了。这群人被称为Programmer——伟大而光荣的程序员。
后来，两个叫斯蒂夫的人搞出了个叫Apple的小家伙，PC——个人电脑开始燃起星星之火。但是这些小东西需要被称作Software——软件的摸不着的东东才能使用。所以，有人开始专门编写它们。其中一叫做比尔 盖茨的人，认为Software可以独立，而且有知识产权，不能随意复制，必须付$。所以，他建立了个叫Micosoft的公司，搞来了DOS，又自产了Windows，拉上一个叫安迪格罗夫的偏执狂，乘着蓝色巨人的东风，开创了软件工业。从此，那些编写Software的人，被称为Software Engineer——软件工程师，他们开发的软件又称为Software Product——软件产品。
然后，不断有人凭借Software，改变世界，名利双收。最近的一个叫扎克伯格——一个80后，用一个叫“脸谱”的东东，改变了人们的社交方式。
我们也免不了有这样的梦想…但是，一个软件要能挣来$|￥，首先要满足客户需求。要大卖，还得满足客户都没想到的需求。扎克伯格们都是市场+工程的复合大牛，而且今天，单靠一人可以取得一时之成功，但想长久，非得依靠团队的力量，通过系统性的工作才能基业长青。所以，凡人，还是先立足当下，或可它图。
软件工程师的日常工作通常称为研发，可用下面的简单研发模型表示：
http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102201710023217.png
实际上分为两种工作，研究和开发。
研究的哲学说法是：探索客观世界，发现其运行规律（详细的可看维基百科），被发现且被验证的规律便成为了人类的知识。研究一般分为两类：
1.基础研究：以获得新知识为目标，不关心其是否有实际应用价值。
2.应用研究：以解决实际为目标开展的探索活动。其结果一般以技术论文形式发表。
基础研究，特别是国内，都由大学、科研院所进行。大企业为保持竞争优势，则建立研究院开展应用研究。中小企业，则开发人员就是研究人员，所以统称研发。
开发人员的研究，不同于专职研究人员，主要探索的是他人已知但个人未知的世界，通过不断的搜集、学习，积累个人的知识，拓展知识边界，从而能顺利完成开发工作。如果能拓展到产品、市场等领域，可以看看那儿有钉子http://images.cnblogs.com/cnblogs_com/Chaos/201102/201102201818378775.png。而有些极具科学精神和智慧的同学，触碰到了所处领域的前沿，那么可以试试专职的研究员。
开发的目的是生产产品、工具解决实际问题，满足大众的需要，丰富大众的精神和物质生活。像Web2.0理念下的各种产品，极大的丰富了我们的生活。开发任务由需求驱动，工程师接到一系列需求（文档记载，详略不一，甚至有口述的），联系已经学到的知识，开始设计，实现。期间很可能发觉缺乏某些知识，如对某个技术不熟悉甚至不掌握，必须要先通过研究，习得新知识，才能继续开发活动。如何运用已有知识，写出合格的程序，就看各人的智慧了，有赖于99%的汗水+1%的灵感，当然1%灵感是决定性的！而灵感来自于，通过坚持不懈的研究对客观世界的观察得来感悟。机会只垂青有准备的人，没有锤子，即使看到钉子也只能扎手。练得千斤力，方能开顽石。
作为研发人员，能不断的创建、创造，享受带给他人改变第一重的幸福。同时研发人员又是悲哀的，因为你得学习、学习再学习，不断的研究，积累知识，历练智慧，才有可能享受哪种幸福。否则……
2—设计之惑
原文: http://www.cnblogs.com/Chaos/archive/2011/02/27/1961167.html设计真是件奇妙的事情，能造就璀璨的明珠，也能带来一堆万年不去核废料；能让人享受释放智慧的乐趣，也能品尝挫败的沮丧。Why？
设计的过程
工程角度，设计是一个过程,包含三种不同层次的活动：架构设计，概要设计和详细设计。三者由全局到局部，依次展开，逐渐深入细节，最终完成一个技术解决方案，给出可行的如何实现需求的答案。此三者的一般性过程如下：
架构设计
目标：定位全局，确定技术方案的方向、后续技术活动策略。
输入：需求文档。敏捷过程常常是是一组用户故事。
输出：架构设计文档。敏捷过程称之为应用全局视图Application Overview。
角色：架构师
任务：
1.分析需求，识别关键功能、质量需求和约束
2.分析目标系统为达成以上目的，需要哪些流程，流程中有多少环节，各环节涉及哪些角色，这些角色的职责及他们之间的协作关系。
3.将角色按逻辑分类抽象，变成子系统。角色的职责即是子系统的接口，角色间的协作关系即为各子系统间的关系。
4.各子系统内部，根据职责拆分模块，确定它们的交互方式。
5.针对关键功能，确定完成这些功能的流程，在时序上由各子系统，模块协同工作的顺序。
6.考虑各子系统的部署方式。
7.将各子系统、模块转换成实现语言的元素。如对于.net，规划各子系统有哪些namespace，namespace如何分配到assembly,assembly之间的依赖关系。再将assembly分配到project中。期间需要注意避免循环依赖，明确接口(作为接口的assembly和project)。
8.规划project在SCM中的组织结构。
9.根据质量需求确定全局性的技术策略（方案）：如线程控制，错误处理，数据存储等。
10.分析其余需求，验证当前方案是否能支持，根据发现的问题做必要调整。
概要设计
目标：在具体实现语言层面上展开工作，确定每个project的主要类及交互过程和总体算法。
输入：架构设计文档和需求。
输出：概要设计文档。
角色：高级程序员
任务：
1.设计提供暴露服务的接口的具体实现类，补充所需的相类，通常可按界面（接口）、活动和存储三方面考虑。进一步落实对项目外接口的依赖关系和位置。
2.设计算法实现接口暴露的相关功能。
详细设计
目标：确定概设提出的每个方法的具体实现。
输入：概要设计
输出：伪代码。
角色：程序员
任务：用伪代码描述每个方法。
这里看到的是一个按需求->系统->子系统->模块->类->方法，自顶向下逐步求精的过程。
设计的技术
技术角度，设计是一系列方法和工具，通过应用这些方法和工具给出一个可行解决方案的描述。常用方法有：
OO：面向对象方法。其目的是统一问题的描述与解决方法，通过一致的抽象提高开发效率。核心思想是，将问题空间映射到计算机模型上，在计算机中建立一个同我们日常感知世界相同的模型，解决问题。实践中，通过类描述问题空间的概念，通过类的消息描述这些概念的交互形成一个模型，再将模型落实到OOP的语言中，如C++，C#，Java等。
AOP：面向方面的方法。期望将主要业务同这些业务中散落的支撑功能（服务）如日志，权限等分离。结合OOP应用时，通过横切点定义跨多个类的支持服务，由方面（特殊类）实现这些服务，再通过切入点连接方面与横切点，达到运行时自动提供服务的目的。
DDD：领域驱动的设计。采用传统OO方法时，一般的需求分析结果是用自然语言描述的与OOD存在脱节，容易生造出问题域中不存在的概念，建立与实际需求不一致的模型。因此，从需求分析起，首先为问题域即领域建模，完全不考虑如何设计、实现，用客户能理解的方法仅描述问题现状。常用的建模方法是OOA，模型可用UML表达，也可以用类似框图联系，总是以能让用户明白这就是问题的描述，方便沟通为原则。
在不断使用这些方法的过程中，一些大师们发现了某些经常重复的解决方案，便对它们进行了提炼和总结，以便后来者这能利用这些经验，提高工作效率和质量，少走弯路。这些经验有：架构风格，架构模式，设计模式和反模式。
架构风格
架构层次的，根据系统的架构呈现出的总体特点进行架构分类的方式。主要的风格有：
1.客户-服务器：系统分为客户与服务端两部分，客户端发送请求，服务端执行并响应。
2.分层（级）架构：系统按关注点水平分层，每一层为上层提供一个抽象。近一步，可将层分布到不同计算机上。
3.面向对象：系统分成单独的可重用的对象，每个对象包含数据及处理它们的行为。
4.基于消息（事件）：系统各部分通过发送和接收约定格式的消息工作，无需关心实际的收发者。
5.面向服务(SOA)：系统通过约定的契约暴露功能，并根据这些契约工作。
6.基于组件：系统分解为逻辑的可重用位置透明的组件，通过明确定义的通信接口工作。
7.管道-过滤器：由管道连接过滤器一组，处理流经的数据。
8.微内核：分离最小功能核心和可扩展部分。
它们在最高层次根据问题的类型给出了一般的解决方向。如：
1.通信问题:基于消息、管道-过滤器
2.部署问题：客户/服务器、分层架构
3.重用与可扩展：OO、基于组件、SOA
但是，不同风格并不是互相排斥的，相反，一个实际系统通常同时呈现出多种风格。如一个分布系统，功能可通过语言无关的契约暴露，用OOP实现这些契约，实现对象又被组织成一个个组件，每个组件定义了彼此的通信接口，而通信又可是基于消息的，组件本身运行在一个支持插件的容器中，可随时添加新组件，提供新服务。这里表现出了SOA、OO、Component、Messaging和Mico-Kernel多种风格。
架构模式
一系列可重用的架构设计方案，每个方案在满足适用场景的前提下，解决一种或一类问题。经典的POSA给出了一些常用的模式分类：
1.服务访问和配置：包装器(Wrapper Facade)、组件配置器(Component Configurator)、截取器(Interrceptor)、扩展接口(Extension Interface)
2.事件处理:反应器(Reactor)、主动器(Proactor)、异步完成标记(ACT)、接收-连接器(Acceptor-Connector)
3.同步:界定枷锁(Scoped Locking)、策略化加锁(Strategized Locking)、线程安全接口(Thread-Safe Interface)、双检查加锁优化(Double-Checked Locking Optimization)
4.并发:主动对象(Active Object)、监视器对象(Monitor Object)、半同步/半异步(Half-Sync/Half-Asynce)、领导者/追随者(Leader/Followers)、线程特定存储器(Thread-Specific Storage)
5.资源获取:查找(Lookup)、懒加载(Lazy Acquistion)、预加载(Eager Acquistion)、分步加载(Partial Acquisition)
6.资源生命周期:缓存(Caching)、池(Pooling)、协调器(Coordinator)、资源生命周期管理(Resource Lifecycle Manager)
7.资源释放:租约(Leasing)、清除者(Evictor)
此类模式给出了全局性问题的一般处理方案，大都是关于子系统、模块及相互之间关系的粗粒度的描述。
设计模式与反模式
设计模式指OO的设计模式，是可反复使用的代码经验总结。通过GoF经典的《设计模式》广为人知。GoF将它们分类为：
1.创建型：简单工厂(Simple Factory)、工厂方法(Factory Method)、抽象工厂(Abstract Factory)、创建者(Builder)、原型(Prototype)、单例(Singleton)
2.结构型：外观(Facade)、适配器(Adapter)、代理(Proxy)、装饰(Decorator)、桥接(Bridge)、组合(Composite)、享元(Flyweight)
3.行为型：模板方法(Template Method)观察者(Observer)、状态(State)、策略(Strategy)、职责链(Chain of Responsibility)、访问者(Visitor)、调停者(Mediator)、备忘录(Memento)、迭代器(Iterator)、解释器(Interpreter)
它们在代码层面给出解决上述三类问题的一般做法及使用场景。
设计模式如红日般普照大地，光芒万丈，导致做OO的言必称设计模式，不用上几个都不好意思拿去见人。免不了被乱用、误用，明明需要避光保存的，偏偏加个LED增加照明，还曰节能、低碳。所以不得不需要反模式来拨乱反正。反模式说明了，当在错误的时间，错误的地点，使用了错误设计模式后，出现的严重后果，提醒人们过犹不及。
设计的人员
今天，从人员角度，设计是一系列扮演不同角色的人员的协作，他们通过某种过程，应用某些技术，相互配合，共同完成一个解决方案。一个采用传统设计过程的大型系统涉及的角色通常有：
1.架构师:一个人或者一个团队，负责将系统分解成子系统和模块，去顶它们之间的关系（开发期、运行期）并制定相关的技术决策，如部署、开发、性能等。
2.高级程序员（设计师）：负责完成一个或多个子系统、模块的概要设计。
3.程序员：负责详细设计。
4.项目经理：负责整个活动的任务协调，并根据架构安排开发任务。
其中，架构师是核心，其工作成果是后续管理和实现的基石。有什么样的架构，便会有什么样的开发组织结构。如分层架构，必然会存在界面、业务、持久化及公共模块的开发职责分配，由不同人（团队）完成不同层的工作。
现代软件，因为规模和复杂性，再也无法由个人独立完成所有工作，必须依靠协作。协作首先需要分工，明确各工种的职责，个人依照职责行事。分工之后便有了工作的先后次序，不同次序的串联需要一定规则，便形成了一些过程规范，大家依照规范协同。所以，才有了那么多的软件工程方法论，开发才有了架构师，设计师和程序员的细分。不能简单的认为架构师>设计师>程序员，他们主要的区别在于工作范围的广度和深度的侧重点不同。架构师更广，程序员工作的更深入。
为了使用一致的思维考虑问题与问题的解决方法，诞生了OOP。为了分离业务与支持服务，让不同的人在不同的时间和地方分别解决不同问题，诞生了AOP。为了便于开发人员与用户达成待解决问题的一致认识，诞生了DDD。
设计时无论采用何种种过程、技术和人员组织方式，根本目的只有一个：给出关于需求的技术解决方案。
实际工作中还会碰到一个严重的问题，常常发现，要解决的问题，并不是地上的石头，静静的躺在那儿，等你照剑谱挥剑的。经常是，哦，我要砍的不是这块，是那块，甚至不是碎石而是需要劈柴，一身武艺无处使。不由怒从心头，不时问候需求人员或者客户，干嘛不一次说清楚，写的仔细点。害我改这改那儿的。对此，Brooks在《设计原本》说：设计的本质是帮助客户发现他们想要的需求。
设计的本质！
根本上，解决方案和问题是共同变化的，甚至会相互影响。现实中，需求阶段给出的需求，往往是初始需求，随设计过程的推进，它会奇妙的发生一些变化：
1.需求描述更精确了：随着设计深入，发现原来的描述存在模糊的方，需要更精确才能做出设计决策。
2.需求描述错了：设计着，突然，卡住了，一交流，发现，哦原来这不是用户要的，他们要那样的，其实很简单。
3.出现新需求：会发现之前不曾注意的需求，会加入系统性的需求，如缓存等。
设计必须能适应这些变化，有些需要通过技术方法，柔性的容纳新变化，将变化点抽象成接口，隔离变化，新需求只要设计成新的实现了即可。有些则只能通过总体过程来适应，如敏捷过程的高迭代，分批交付，在每个迭代间能响应变化。企图一次就做出美妙的设计是不现实的，设计必须具备响应变化的能力。因此，设计人员需要：
1.KISS：时刻注意保持简单性，简单的方法往往也是最正确高效的。
2.关注需求：时刻注意什么是真正的需求，遇到困难，不妨先想想，真的需要解决这个问题吗，能换种方式吗？
3.适度的远见：预见同类需求发生的可能性，并提前考虑对策。如看到报表需要导出成excel，想想是否有生成pdf的可能性，如有必要尽早隔离这种变化。
4.系统性思维：时刻注意用需求去验证设计，确认设计是否满足需求，满足的是否牵强，是否因假想了需求而增加了额外的复杂性。
5.全局性思维：思考设计会对开发、测试和部署运营造成什么样的影响，因为这些方面往往存在致命的隐含需求。
6.提升抽象层次：从一次一个系统转换到一次一个系统族，考虑所有同类系统的共性和可变性，将共性做成框架，可变性提炼成配置，DSL留到具体项目实施时完成。
3--接口之本
原文: http://www.cnblogs.com/Chaos/archive/2011/03/05/1971498.html从前，有个程序，
http://images.cnblogs.com/cnblogs_com/Chaos/201103/201103052218105986.png
只有一个模块，自己搞定所有事情，简单又快乐地生活着。
后来，干的事多了，需要划分职责，
http://images.cnblogs.com/cnblogs_com/Chaos/201103/201103052218128362.png
加了新模块，不过他们需要彼此沟通协调工作……好在是进程内的，如C#,Java之类的写几个Interface就搞定协作规范了。
不过，再后来变成了两个程序
http://images.cnblogs.com/cnblogs_com/Chaos/201103/201103052218148688.png
这下麻烦更大了，因为你说话时，对方可能睡着了zzZZ。甚至，你可能需要同老外交流，更甚至，对方可能来自遥远的半人马座。
很明显，接口不是简单的”interface”。
接口的本质是一个协议——双方交互的规范，是双方为完成某件事情而事先做的一系列约定。约定分为三个层面：展现、业务和通信。业务层是核心，承上启下，需要考虑如何直观自然的表达业务。通信层是双方的沟通方式。展现层则重在考虑沟通双方的使用方式。如下图：
http://images.cnblogs.com/cnblogs_com/Chaos/201103/201103052215377041.png
业务层（这是核心）
一、协议的形式
[*]命令式：通过一连串的指令进行交互，指令序列规定了具体执行的步骤，即先1，再2，而3。 如：TCP的三次握手：SYN,ACK,SYN,ACK。
[*]文档式：通过文档形式进行交互，文档只说明要什么即目的，不规定任何执行细节。如：REST形式的接口。
二、协议的内容
[*]命令式：请求命令有哪些，具体内容如何。对应的响应命令有哪些，内容又是怎样的，正确结果如何表达，错误又如何表达。
[*]文档式：如何表达请求，如何表达响应，包括正常情况与错误情况。
通信层
一、通信方式
完成交互，还需通过一种通信方式为载体，传递具体协议的信息。通常通信环境有以下三种：
[*]进程内 ：如一个进程内的两个模块。通常将命令直接映射成一个个API，采用普通的API调用，协议设计直接简化成API设计。
[*]进程间 ：两个进程间交互，如果有要求较高的性能，一般采用管道方式。如果需要多进程交互，可采用消息队列方式，解耦发起方和处理方，并简化互相间的连接管理。对于文档风格的协议，在简单的生产和消费的情况下，也可采用直接文件传递的方式，一方读，另一方写。
[*]机器间：进程分布在多个机器上，可以考虑：
[*]文件：在一对一的生产-消费模式下，最“愚蠢”文件方式有时反而是最简单的高效。特别是异构系统间的一对一通信，可使用此方式，一次传递批量命令。
[*]数据库：多个异构系统间的通信，也能通过中央数据库进行。但是，频繁的修改和读取同样数据会带来性能瓶颈和死锁。
[*]基于消息：通过一个消息系统传送命令、结果和文档。能从空间和时间上解耦发起者和处理者，两者可以互相不知晓对方的存在，发送和处理消息可以异步进行。可以实现点对点或发布/订阅方式。
[*]RPC：直接模仿本地调用，将一个方法调用转换成一个数据块，使用一种基于TCP/IP的传输协议进程点对点传输。
二、数据格式
确定通信方式后还需要考虑，传输时的具体数据格式。
[*]API方式：方法的签名及参数
[*]文件方式：文件格式（如XML，TXT，领域专有的文件格式），通常还可定义一个描述格式的元文件，供对方根据它自动生成解析程序。如XML，需要考虑其具体Element，Attribute，通常用XSD定义。
[*]数据库：数据库Schema。
[*]消息：在MOM系统中使用的消息头和消息体的具体内容。
[*]RPC：自定义传输通道时需要考虑，传输数据包的格式。可采用：
[*]应用层叠加：在已有TCP应用协议上再增加一层专有业务数据格式。简单，无需考虑TCP传输层的编码与解码。如传统WebService是 SOAP over HTTP的，在HTTP中传输SOAP格式的数据（如果需要也可）。
[*]开发新应用层：直接在TCP层上增加业务专有的应用协议。需要考虑传输层的编码与解码，涉及数据分包、校验等。如Remoting。
展现层
无论业务与通信如何设计，使用者最终需通过一个API，完成交互。这个API即我们通常说的“接口”。存在两种方式：
[*]业务无关API：直接暴露下层协议细节，通过一个一般化的API完成工作。好处是对提供者而言所需工作小，可轻易跨平台，当然消费者需要了解协议细节自行完成解析。一般用作文档风格的协议的提供方式，如RESTful接口，可直接通过本地HTTP API使用。
[*]业务专有API：即Wrapper。通过包装器，封装掉所有协议细节，在API上直接表达业务，简化使用。缺点是需要提供每个目标客户端平台的API实现。
使用范围也会影响接口的设计。如果是公司内产品的交互，无论下层如何设计，通常会考虑提供包装器，供相关团队使用，因为客户总是需要写类似代码的，不如由一个人（团队）干了造福大家。如果是公司间产品的交互，在Java和.net上，大Web服务还是不错的选择。一方面，虽然重，但因为有工具可以自动生成接口代码，所以也轻了点。另一方面，大Web服务容易达成共识，因为WSDL是标准元数据格式，沟通方便。至于互联网上，各式Open API都是类REST的，因为Web是天然面向文档的，暴露的又都是资源，如此最自然，提供者所作的工作最少。至于消费者，天知道他们用什么语言平台来访问，只能请他们自己解析了：）
SOA中的接口
单看技术层次，SOA的核心是服务，服务有三个基本要素：契约、实现和绑定。契约是服务所提供功能的一个规范，重在表达业务概念；实现是服务的具体在语言和平台的落地，包含提供者的实现和使用者的API；绑定则是服务之间的具体通信协议。分离了使用、业务表达和通信。
最后再看看经典的ISO模型
http://images.cnblogs.com/cnblogs_com/Chaos/201103/201103052213024847.png
如来神掌……
4--2个PM的游戏
记得刚工作的那会儿，提到PM就是指Program Manager 或 Project Manager,是带领一群程序员去开发软件的家伙。而另一个PM产品经理(Product Manger)则多少不为人知。但是最近几年，随着几个互联网大佬的爆发，产品经理开始风生水起，PM的第一解释逐渐被其取代了。现在，整个IT行业，但凡做产品的，皆有产品经理的身影。产品经理需要确保做正确的事情，开发的东东有高ROI，满足市场、客户的需求。项目经理则要保证正确的做事，能按期做出符合要求的东东。在绝大多数企业，这个过程就像是一个2人三方的游戏。
首先，作为神一样存在的BOSS宣布：一系列财务、市场指标和一些与长期战略有关的目标。还常常会提出要出XX产品（当然，BOSS的产品只是个商业概念），XXX时间必须发布，画下一条红线，越线则死，成功则生（赏）。下图，“神”画下了红线：
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104171707239163.png
游戏开始，产品经理先登场，将BOSS的愿望图纸化，绘出血肉筋骨。一般需要从商业，市场和产品三个层次考虑，主要有：
[*]商业，需要遵从公司的总体商业目标，考虑具体的投资回报和产品的商业模式，并绘制一个产品的高层愿景。
[*]市场，需要根据公司总体业务，分析目标行业和客户，理解他们的业务，工作流程，发现问题（有什么新问题需要解决，以处理的问题解决的是否满意），确定机会。
[*]产品，确定产品针对的细分市场，目标客户。针对的市场机会要做的具体功能，及路线图、版本计划、运营规划等。
以上内容主要变成三分文档BRD、MRD和PRD（也有公司会根据需要合），作为立项时的需要双方遵守的契约。下图：立项及契约。
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104171707268276.png
接着，产品经理开始推动立项过程，固定具体的产品范围要求项目经理对发布结果承诺哦。通常产品经理会在PRD中塞入尽可能多的功能，因为：
[*]要求多多益善是人类的弱点
[*]他们代表了客户，得为他们争取竟可能多的利益^_^
[*]尽可能多的写下来，当出问题时，可以转嫁责任给项目经理（研发团队），先求无过。（博弈论，人性的弱点，潜规则，天知道…）
过程中，项目经理则尽可能减少、简化功能，因为：
[*]实现太复杂，会影响发布
[*]少做是人类的弱点
[*]没有要求做，当客户愤怒时，可以转嫁责任给产品经理，先求无过。（$#@%$^…）
双方通过一轮轮的评审，不断在产品范围上拉锯，时间则在向红线不断逼近…下图，立项的时间在评审中不断游移：
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104171903591312.png
终于，双方达成共识了（虽然实际很可能是双方都累了，无暇再考虑细节，就这么模糊的定了)。产品经理长舒一口气，他只需等待发布，其余交给项目经理了。
但是，从立项到发布，期间还有N长时间，似漫漫长夜，让人恐惧，因为将发布的东东，现在还是一堆纸 …后续都是技术活，产品经理有心也无力了。
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104172025057241.png
立项结束，项目经理接过指挥权。熟练的将任务分解为分析、设计、编码和测试阶段，逐步明晰需求，细化设计然后实现，期间可能还会输出诸如SRS、HLD甚至LLD等文档，确认是否走在正确的路上。但是，通常会发现：
[*]产品需求模糊且广大，细化需求工作力量巨大，导致需求分析时间冗长。
[*]需求分析累了或用时太多，必须加快进度，不得不开始设计。
[*]然后因为需求模糊，导致设计时再需求和设计间来回摇摆，耗时同样冗长，还可能因为设计问题缩水、遗漏需求。
[*]因为时间原因，急忙开始编码，期间发现很多需求、设计问题，导致时间冗长，压缩了测试时间。
[*]因为发布日期临近，匆匆测试，急忙上市
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104172025097892.png
终于，产品发布了，但是客户不满意，缺少重要甚至必须的功能，性能不佳等等，问题一堆。游戏终局常见情况是：
http://images.cnblogs.com/cnblogs_com/Chaos/201104/201104172025124530.png
当然，神也是会发雷霆之怒的…
页:
[1]