项目要素：
S：范围(目标)创造的产品，服务等
Q：质量，完成后被验收满足的条件和标准
S：进度，认可的进度内
C：成本，在一定的预算内
项目也要计算投入和产出，同时也有三个作用：
培养人才；
拓展客户关系；
构建可重用的模式/平台/构件
项目也要认识相关方，并做出具体分析：
CTO,项目经理，用户，客户，不感兴趣的，可以忽略的，it人员，竞争对手；尤其是用户和客户不是同一伙人时，比如说ATM的银行采购方和使用的老百姓，这时候用户就是老百姓，而客户就是银行；
适合企业自身的估算模型：
y=f(x)，WU即work unit的缩写，比如说1人1天；
根据经验制定合理的估计模型，并根据项目团队的人员能力的提升或者人员的变动每隔半年调整一次；
举例来说，网站的开发，可以根据需求估算出来大致要做多少个页面，并根据页面功能的复杂度做出WU的微调，比如说单独的一个页面需要1WU，那么当需要和后台数据库打交道时需要增加0.5WU，需要有复杂的业务逻辑运算和处理时增加0.3WU等等，当然这些都是要根据历史项目的分析得出来经验值才贴近实际情况；还比如说金融软件里面增加期货业务功能时需要多少WU，增加期权业务功能时需要多少WU等等
项目的运作：
启动----> 策划---->监控
|
----->执行------>关闭
即在执行的过程中需要实时的监控执行的过程是否合理，代码的质量是否合格(单元测试执行的如何，代码review如何，代码静态分析如何)，所有的业务功能点是否都已经覆盖实现，相应的测试执行结果对应上没有等等
项目报告：
当前的工作进展；
存在的问题；
存在的风险；
后续可执行的计划(一般三个计划，即诸葛亮说的上中下三策)；
描述风险有如下方面：
发生的条件
可能造成的危险/故障/后果
比如说项目的进度延迟，协调的难度提高，GUI的兼容性，成员的离职，质量保证是QA的工作，而不是开发人员关注的等等，意外的需求；这些都是问题，而不是风险，风险举例来说，比如说项目的实施过程中，对方的负责人是从别的分局调动过来半年的，那么这时就要遇见到这种风险，假如那个负责人回原单位，项目肯定实施不下去了，所以可以想降低风险的办法，比如说，每周把实施的进展和问题及操作都文档化汇报给负责人，这样即使负责人走了，新接手的看到这些东西也能够很快的上手，随着项目实施的进行，文档的完善机制，这个风险度在慢慢降低，假如后续这个负责人真的不走，那么这个风险度就重置为0
风险----发生了才转换为----问题，这个过程是需要实时监控的，并且作为计划的一部分，而且对项目负责人有预见性的要求；
外包----只能把非核心的业务外包，并且需要注意管理外包的成本和自己公司内部做的成本几乎一模一样，最重要的是工作量虽然可以转嫁，但是责任是转嫁不了的，比如说项目出了问题，负责的还是我们，甲方还是找我们算账，我们再找外包方算账；
自组织的团队/松结对编程的139原则：
xxx
|
xx--------------------xx-----------------xx
| | |
x-----x -----x x----x-----x x------x-------x
xxx即为既精通业务，又精通技术的负责人；xx为精通业务或者精通技术的小组长， x即为真正的具体开发人员；
早上定计划，下午看进展，下班前检查进度，感觉不太好实施，想想每天小组长都检查这么细？发现问题的处理方式：第一次师傅改好，然后问下，“你以前都是这么做的么？”然后问，“你以后还会这么做么？”假如小组的其他人又遇到同样的问题，小组长就可以说，你去问下AAA看看你的代码错误的原因是什么，我给他讲过原因；即小组长可以不做重复的劳动；其实这个时候可以让犯错的人把这种错误放到知识库里面去，这样新人只要熟读知识库就可以避免这类问题了。
创造力 = 能力 X 热情 X 思维方式
明朝那些事儿里面提到的心学的创始人王阳明，活法，在东吴相对论里面也提到过。
具体实施方法有：
每日例会
共同估算
先估算后分配
方式有：敏捷扑克和评分考核卡，强分工的人共同评估出合适的人做合适的事情
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
