[reading]高调做事，低调做人之–做事要有条理和秩序

文中建议你：

• 不要总是风风火火
• 镇静、平静和祥和
• 各样东西都摆放的有条不紊
• 每天都要整理自己的办公桌
• 对于重要的新建立即回复
• “今天的世界时思想家、策划家的世界。唯有那些办事有效率、有条理的人，才会成功。而那种头脑混乱，做事没有秩序、没有条理的人，成功永远都和他插肩而过”

—————-分割线———————————————

ok,谈一点个人工作中和这个原则相关的事情，就是项目管理中的条理和秩序。

作为项目经理的你，你可想过有哪些重要的事项时能够保证你的项目得以有条不紊的推进？ 当然，肯定有很多工作要做，但我们是不是常常因为事情很多以及工作很忙的缘故，只是忙于当前“救火”的事情，而并没有太多注意力放在比较长远的原则性内容，比如相关的文档记录，相关的回顾和总结以及跟踪，过了一段时间后有一些事情逐渐失控？

在最近的一个项目中我们的管理相对还是比较松散的，将需求和变更以及bug都写在google doc上（就这一点客户一开始也不习惯，非要用传统邮件的方式发送附件，但是我还是坚持用这种方式，因为传统方式无法跟踪版本，容易扯皮）;另一点就是做定期的项目情况说明，包括当前哪些地方需要双方配合以及存在的问题，以及阶段性风险提示。 主要是这两点，其他的见面的沟通的结果仍是记录在google doc上，不过我仍然感觉我们还是缺少一些东西来有效跟踪以及如何更有条理，因为实际过程中对于某些讨论较多或分歧较大的item我们最终没有有效的跟踪方式，也许这类的该做专题跟踪（maybe wiki?）

确认和跟踪包括两个层面，一个是甲方的需求和变更，另一个是技术开发实现的跟踪；二者都容易出现问题，对于技术开发最容易出现的问题就是同一个问题容易反复出现，当然，作为我自己也是从开发人员过来的，我理解出现这些问题的可以理解之处，不过这次出现的外包人员的敬业精神让人难免有些失望，更加难以理解的是还有很多的“理由”，我把它理解为“无能者的辩解”。   —–所以，我要考虑的问题便是，在这样的情况下，如何来做到更加的有条理和秩序？

期待你的建议

项目经理的职责

纯粹意义上的项目经理是不用管技术的问题的，只负责管理，但是在一个中小公司可能出入就很大了，比如，在我所在的公司，项目经理=客户需求+项目管理+软件架构+程序编码+部署+测试+项目验收，如果需要的话也可以兼个DBA ,还好，我以前的功底相对比较扎实，从linux到windows server到sqlserver 到oracle到jboss到websphere算不上精通也都基本能独立搞定，但要说效率有多高可能就不好说了.

我个人还是倾向于“分布式”，即各司其职，有人设计，有人实现，有人管理，有人维护，我还是欣赏我当初参加工作时在北京网通小灵通账务管理的项目中的人员分配的方式，现在想来还是比较合理，在我们B/S组分配是：一名项目经理，主要负责总体和客户的沟通，一名需求管理人员兼DBA；一名技术经理带2个 后台开发人员；后台开发人员各带一名前台开发人员；一名测试人员负责测试，同时负责用户平时的基本修改意见的汇总，如果有较大的变动则通过项目经理。而反观我们现在的一些项目会发现，程序员居然和客户沟通起来了，真是不怕天下大乱，用户A提一个问题，程序员A修改了，过一段时间A又提一个问题给B，B也修改了，有一天程序员A和程序员B都走了，客户觉得我的好多以前提的东西你们怎么现在的人都不知道啊？ 双方都受伤害。其实，合理的架构才能保证有序的结果，一个小打小闹的团队怎么能应付日益变化的客户需求呢。

如果条件允许，我建议一个具有竞争力的团队应该是一名架构设计人员，一名DBA，3-5名中等水准的开发人员，一名美工，一名测试，其中DBA和美工是共享人员，临时参与，测试放到一个更重要的位置，即，始终跟踪全部的客户需求，所有的修改变更都是通过测试人员，程序员和客户之间隔离开。其实这不就是“面向对象”么？ 松耦合和紧耦合肯定不是一回事。现在很多的公司的高层人员普遍比较短视，所谓的理由就是“成本”，我的回答是：出来混迟早要还的！ 现在不这么做，迟早要付出代价。

项目内部评审

1.项目经理在正式开始项目开发之前需要将需求提交评审组进行评审

2.评审的核心内容

• 现有展示的功能能否满足客户需求
• 为了满足客户的需求，我们的代价是否超过预算

3.第一项由市场销售经理把关

4.第二项由项目经理把关，因为给项目经理的预算是确定的

5.大多数的时候的风险是需求大于合同承诺的范围

•  通知市场经理，增加合同额，一般比较难
• 让客户缩减需求，本着双赢的原则，让客户同意

成功的项目是一样的，失败的项目也是一样的

1.人们都说 ： 成功是一样的，失败各有不同

2.其实应该换成: 成功是一样的，失败也是一样的

3.成功的项目的特点”

• 与项目各参与分共同决策
• 项目各方的责任和承担的风险明确划定
• 项目所有的采购和设计、实施都进行了多方案比较论证
• 对项目规划阶段进行了潜在的问题分析
• 委托了非常敬业的项目经理并给予了充分的授权
• 项目团队精心组织，能力、沟通和协作好，集体讨论项目重大风险问题
• 制定了针对外部环境变化的预案并及时采取了行动
• 进行了项目组织建设，表彰和奖励及时、有度
• 对项目组成员进行了有计划和针对性的培训

4.失败的项目的特点:

•  项目提出非正常程序，从而导致项目业主缺乏动力  (就怕这一点，基本没戏)
• 沟通不够，决策者远离项目现场，项目各有关方责任界定不清 (扯皮)
• 规划工作做的不细，计划无弹性或缺少灵活性 (僵硬)
• 项目分包层次太多 (天高皇帝远)
• 把工作交给了不称职的人同时又缺少检查、指导 (傻B干活干个球啊)
• 变更不规范、无程序，或负责人、责任、项目范围、项目计划频繁变更 (不怕计划，怕变化)
• 决策前的沟通和信息收集不够，未征求各方意见 (独自去偷欢，独自去痛苦)
• 未能对经验教训进行分析 (死了再来)
• 其他错误

5.以上资料摘录自风险识别的课程里，即项目风险识别技术与工具里：

• 检查表 （很老土，但很有用）
• 流程图 (描述工作逻辑，而网络图是排定工作时间)
• 头脑风暴法(现在都用滥了，什么玩意都来一个头脑风暴)
• 情景分析法
• 德尔菲法(Delphi?)
• SWOT分析法(这个分析法不错，推荐)
• 敏感性分析法

项目管理，从MS Project开始

1.项目管理三要素TCQ (time,cost,quality)

2. 微软的东西其实感觉一般，不过微软的project值得使用，就跟office套件一样，我们基本不能离开。

3.WBS分解，分解的最小单元建议： 0.5人日,即最小的一个功能点对应一个WBS编号，其消耗的时间是0.5日，这样，便于跟踪和控制。通过project server可以看到整个项目的具体进展情况，而不是没头苍蝇乱飞。

4.跳出项目管理的理论，看看你平时的工作和生活能否用WBS的方式管理起来，或者你可以联系GTD的方式来看看,也许会有收获.

关于吃饭这个项目

key words:项目管理

项目，是一个范围很广的概念，三峡大坝是一个项目，IT企业的一次开发任务也是一个项目，个人某个时间段的活动安排仍然可以看作是一个项目.

这次出差到广东来开发项目,公司租了3居室的房子，但是平时吃饭是一个问题，便宜的不卫生，卫生的不便宜，埃，东莞这边的条件真是不咋的，过了N久大家终于觉得应该自己开伙,讨论的结果是大家一致认同。

立马去买了锅碗瓢盆，油盐酱醋米，原以为一帮大老爷们对做饭应该是外行，其实不然，5个人中有4个人都会做饭(这年头都是女人逼得 ),而且配合很好，有人做菜，有人焖饭，吃完还有人主动洗碗,天天如此。而且，每顿平均4个菜
如果把吃饭这个事情算是一个项目的话，那么这个项目真的算是很成功

项目需求:解决吃饭的问题，要求是既实惠又好吃

项目实施: 由于是大家共同的需求，每个人都很主动积极，每一个环节都落实的很好

项目效果:大家的需求都得到满足，而且还感慨，早就该自己开伙了

一次大家吃完了闲聊，一人说道，ＮＮＤ，项目做的不咋的，饭吃的还不错。一语把大家都笑翻在地

[zt]如何做需求分析

come from here

如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。获取用户需求

　　这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动（如图1所示）。

　　● 了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。

　　● 对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。

　　● 需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：

　　⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；

　　图1 获取用户需求的活动

　　⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；

　　⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。

　　● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：

　　⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；

　　⑵使需求符合系统的整体目标；

　　⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。

分析用户需求

　　在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：

　　● 以图形表示的方式描述系统的整体结构，包括系统的边界与接口；

　　● 通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；

　　● 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；

　　● 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。

　　图2 DFD示意图

　　用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。图2描述的是某个项目的DFD示意图。

　　ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。

　　在面向对象分析的方法中通常使用Use Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。Use Case方法最主要的优点，在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能的测试用例。

编写需求文档

　　需求文档可以使用自然语言或形式化语言来描述，还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求（功能性需求和非功能性需求）。

评审需求文档

　　需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。

管理需求

　　图1 需求变更流程

　　需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。需求变更流程和需求跟踪矩阵分别如图1和图2所示。

　　图2 需求跟踪矩阵

　　常见问题及建议

　　Q、客户与最终用户的区别是什么？

　　A、可以借助图3来说明它们之间的区别。

　　图3 需求获取渠道示意图

　　软件需求来自系统工程与客户两个方面，其中客户是主要的需求提供者（系统工程需求也来自于客户）。客户需要搜集其最终用户的需求并考虑自身的需求，然后再提供给开发方。假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。

　　Q、如何进行用户访谈？

　　A、首先，一定要事先确定访谈的目的和提纲。其次，因为用户往往并不知道应该提供哪些方面的需求，所以需要开发人员引导。

　　Q、用户访谈内容是什么？

　　A、首先，请用户描述他们如何完成自己当前的工作，并与用户一起抽象出一个工作流程或工作模型。然后，在得到用户的认可后，向用户解释自己是怎样来实现这些功能的，并说明哪些环节可以用自动化方式实现等。

　　Q、采用哪一种方式做需求分析最好？

　　A、不同的需求分析有不同的特点。还没有哪一种方法可以完全替代别的方法，否则，现在就不会存在不同的需求建模方式了。一般来说，可以使用DFD＋ERD来描述那些功能层次比较清晰的需求；而USE CASE则适于描述功能结构复杂的需求。做需求分析的目的是为了建立需求的模型，不同的子系统有可能使用不同的建模方法。

　　Q、怎样做原型，原型的目的是什么？

　　A、通常使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个可视界面作为原型，并在界面上布置必要的元素以演示用户所需要的功能。可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。

　　原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。

用jotSpot做项目管理应该不错吧

key words:jotspot,wiki,项目管理

最近听说了jotspot,这个东西确实很好，原来一直打算自己建立一个wiki,作一些公司项目资源的管理，进度管理，以及提供其他团队成员了解项目信息的窗口，原来打算用jspwiki,可是建在哪呢？ 在我的笔记本上还是公司的服务器上，似乎都不是很好，还是建在jotspot上比较好。zheng
给我看了一个截图:

功能还挺强大，我想做我的日常项目管理应该够了