一次关于项目管理实践的讨论
下面是周末时候，群内兄弟讨论的一些内容的整理，涉及了项目管理、敏捷实践等实际情况。有兴趣的朋友可以参考。观察者(1) 11:02:54
大家在项目开发的时候有没有用到项目管理工具啊？比如TargetProcess，CQ？
winston(2) 11:04:09
项目管理工具对于管理是必备的
winston(2) 11:04:17
但是各种工具各异
winston(2) 11:04:22
按需要用
观察者(1) 11:05:01
winston你们用的是什么啊？
winston(2) 11:05:42
因为我经手的基本都是互联网项目，所以重型的工具用不上
观察者(1) 11:05:55
agile？敏捷的哦？
winston(2) 11:06:11
一般也就是Project、Test Track等
winston(2) 11:06:18
敏捷只是开发过程
winston(2) 11:06:25
决不是项目管理的全部
winston(2) 11:06:31
我深有体会
观察者(1) 11:06:36
基于敏捷过程的工具
观察者(1) 11:06:52
TP，versionone
winston(2) 11:06:59
在公司你只搞敏捷，不搞全面的管理，要栽跟头的
winston(2) 11:07:20
所以认清了敏捷的范围和适用性
观察者(1) 11:10:16
全面和敏捷结合
winston(2) 11:11:32
不准确
观察者(1) 11:11:54
敏捷中的测试驱动和结对都是很难的，需要一定技术基础支持
winston(2) 11:11:58
我认为，敏捷只是开发过程，属于软件项目管理中的子集
winston(2) 11:12:20
不能把这个过程化的东西，提升到更高的地步
winston(2) 11:13:00
从我学习过和已有的经验角度看，项目管理涵盖的东西比敏捷广泛太多了。
winston(2) 11:13:21
随便给你举个例子，如何制定开发日程？
winston(2) 11:13:36
敏捷往往没有答案，或者说没有准确的答案。
winston(2) 11:13:45
可是，这正是BOSS们最关心的！
winston(2) 11:13:52
我就吃过亏
winston(2) 11:13:57
因为敏捷坚信
观察者(1) 11:14:17
我们需要一个敏捷顾问
winston(2) 11:14:27
计划要短，1-2周一个细计划，长期计划要模糊
winston(2) 11:14:31
不断迭代发展
winston(2) 11:14:41
可是，公司BOSS们不会接受的
winston(2) 11:14:52
他们需要知道更为准确、可靠的时间表
winston(2) 11:14:57
这个时间表如何制定？
Linker.Lin(3) 11:15:00
这个就是忽悠了
winston(2) 11:15:03
敏捷回答不了的
winston(2) 11:15:15
反之，项目管理的知识就能回答
Linker.Lin(3) 11:15:18
我觉得和老大开会说的不一定是下面实际的计划
winston(2) 11:15:21
而且控制的相当准确
Linker.Lin(3) 11:15:27
否则很多事情很难搞
观察者(1) 11:15:35
敏捷并不是不做计划啊，而且长期计划的模糊并不是由于敏捷导致的
Linker.Lin(3) 11:15:41
比如迭代这种事情
Linker.Lin(3) 11:15:53
很多老大觉得迭代就是风险
观察者(1) 11:16:00
？？
Linker.Lin(3) 11:16:03
这个就没有办法和他解释了
winston(2) 11:16:08
敏捷的计划和管理的计划不同的
Linker.Lin(3) 11:16:17
可控性其实很虚
winston(2) 11:16:35
一般老大发话，说我们要在某月某日完成什么什么东西
winston(2) 11:16:39
你怎么想？
winston(2) 11:16:57
其实这种限定，99%错误，无法完成
winston(2) 11:17:08
因为这是从空气中抓来的计划
观察者(1) 11:17:08
是啊，所以可以不去理会
winston(2) 11:17:22
你不理会，就是不尽职了
winston(2) 11:17:36
真正的时间表，要从下到上来制定
观察者(1) 11:17:41
我觉得敏捷所谓的长期计划模糊只是让我们认清了计划的不可靠
winston(2) 11:17:43
而且要计算关键性通道
Linker.Lin(3) 11:17:46
还是忽悠吧
Linker.Lin(3) 11:17:50
否则没法混了
winston(2) 11:17:53
这决不是忽悠
winston(2) 11:18:04
你能忽悠一次两次，多了就被人看穿了
winston(2) 11:18:13
人出来混，早晚要还的
winston(2) 11:18:27
所以要想法具备真才实学
winston(2) 11:18:37
吃亏要学乖，有长进才行
winston(2) 11:18:53
你计算了关键性通道后，就知道时间表了。
观察者(1) 11:18:58
在敏捷里面有预测花费时间和实际花费时间两个东东
winston(2) 11:19:09
而且，项目管理中，重要的是金三角原则
winston(2) 11:19:23
敏捷的那个太简单
观察者(1) 11:19:36
经过多个项目的考验后预测时间会接近实际时间
winston(2) 11:19:46
金三角，就是时间、资源、功能的约束关系。
winston(2) 11:20:01
再考验，你也难以确定
观察者(1) 11:20:15
而且敏捷有个观点是如果超期是砍掉一些user story
winston(2) 11:20:18
我有所体验，主要是BOSS根本不接受
winston(2) 11:20:26
对
winston(2) 11:20:47
但这不是敏捷的专利
观察者(1) 11:20:50
所以推行敏捷是一个需要高管支持的
winston(2) 11:21:06
我提个问题
winston(2) 11:21:34
如何避免软件开发中，程序的功能，由程序员自作主张，导致与需求、习惯不符？
winston(2) 11:21:40
这个是常见的毛病
winston(2) 11:22:01
程序员自己做的东西，自以为完美，其实经常糟糕透顶
观察者(1) 11:22:37
这个有两个问题，一个是需求不明，一个是沟通不畅
winston(2) 11:22:55
我认为这不是答案
观察者(1) 11:23:21
需求明确，如果满足要求的前提下程序员自己发挥是可以接受的
winston(2) 11:23:38
NO
winston(2) 11:23:47
你如果这样做，一定吃大亏
winston(2) 11:23:54
因为我就吃亏过
观察者(1) 11:24:00
说说
观察者(1) 11:24:19
我感觉你对程序员已经不信任了
winston(2) 11:24:22
1、需求这个东西，是需要专门管理的。即使在冻结期间内，程序员做的东西，在细节方面，经常偏离原有轨道。
winston(2) 11:24:36
我对程序员从不信任 - 尽管我自己就是
winston(2) 11:24:47
没有经过测试的程序，根本靠不住
winston(2) 11:24:54
无论是谁写的
winston(2) 11:25:48
对于刚才的问题，我的答案，其实就是敏捷过程中的
winston(2) 11:25:56
当然，也是其他过程中都有的
观察者(1) 11:25:58
加强沟通吧，引入客户代表
winston(2) 11:26:12
你的办法太泛泛，谁都会说
winston(2) 11:26:18
却没有实际意义
winston(2) 11:27:00
就是用故事板的办法，写用户案例
观察者(1) 11:27:01
理论是指导实际行动的啊
winston(2) 11:27:42
回答问题必须具体
winston(2) 11:27:55
一两句，改善需求，加强沟通，根本无济于事
winston(2) 11:28:18
要有切实可行的办法和措施
winston(2) 11:28:31
只有吃过亏才明白
winston(2) 11:30:54
给你举个实例
winston(2) 11:30:57
避免抽象
观察者(1) 11:31:10
其实敏捷的核心是人
winston(2) 11:31:25
一会再讨论这个问题
观察者(1) 11:31:41
不论是userstory还是其他的需求收集方法，最终都是为了沟通，让程序员知道该做什么
winston(2) 11:32:00
嗯。
winston(2) 11:32:46
我原来做一个产品，里面有个文件传输功能，我自认为告诉他很清楚，可是界面给我做的非常糟糕。
winston(2) 11:32:51
这是一个小例子
winston(2) 11:32:57
敏捷的核心是人
winston(2) 11:33:09
难道其他的方法、管理中，就不是人了吗？
winston(2) 11:33:40
在现实环境中，不能指望团队成员水平整齐划一
观察者(1) 11:33:41
人是核心，这个不用争论
winston(2) 11:33:44
那是不可能的
winston(2) 11:34:02
所以，即使你费尽口舌，告诉某个人怎么做，也必须经常监督
winston(2) 11:34:03
检查
观察者(1) 11:34:06
信任自己的团队是基础
winston(2) 11:34:14
而且要用规范书进行控制
winston(2) 11:34:24
信任不等于放任
winston(2) 11:34:29
两码事
Linker.Lin(3) 11:34:31
说的好
观察者(1) 11:34:44
但是你自己说的是不信任，不是不放任
Linker.Lin(3) 11:34:47
如果手下的经常离职,什么事情也干不成,
Linker.Lin(3) 11:34:54
不同行业的处理不一样
winston(2) 11:35:04
电视中经常有说 - 用人不疑，疑人不用
winston(2) 11:35:12
那是哥们义气才这么干
Linker.Lin(3) 11:35:14
对于游戏行业,如果对手下太苛刻,说不定人家就走人了
winston(2) 11:35:21
搞公司，一定吃亏
Linker.Lin(3) 11:35:26
不像死气成成的ERP行业
winston(2) 11:35:27
这个不是苛刻
winston(2) 11:35:29
是规范
winston(2) 11:35:32
必要的规范
Linker.Lin(3) 11:35:36
游戏行业的工作机会太多了
winston(2) 11:35:51
我带团队的时候，核心成员一直很稳定
winston(2) 11:36:08
反而是放任，才会导致下面无所适从
观察者(1) 11:36:09
规范是重要的，但是如何规范，规范的力度是很考究的，并不是说什么事儿都规范了就能做成
winston(2) 11:36:15
那是自然
winston(2) 11:36:21
你天天要求大家加班
winston(2) 11:36:26
肯定团队崩溃
winston(2) 11:36:36
这里面自然有个度的关系
winston(2) 11:36:55
也许这就是大师们所说，管理是艺术吧
winston(2) 11:36:59
我们才知道皮毛
winston(2) 11:38:07
我栽的跟头多，了解人性的方面就深了一些
观察者(1) 11:38:51
我也遇到过很多问题，甚至一起开发的团队带着项目直接跳槽的
winston(2) 11:39:10
都有
观察者(1) 11:39:21
但是我还是相信人性本善，要相信人
winston(2) 11:39:24
所以说知易行难吧
winston(2) 11:39:35
这个其实不用讨论
winston(2) 11:39:41
我考虑的是
观察者(1) 11:39:49
有书说过，没有不好的程序员，只有不好的项目经理
winston(2) 11:40:04
这个太牵强了
winston(2) 11:40:12
差的人，干啥的都有的
观察者(1) 11:40:14
正确的人做正确的工作
winston(2) 11:40:23
无论人性善恶，都要有合理的管理
winston(2) 11:40:38
用正确的办法，建设好团队
winston(2) 11:40:43
才能有成效
JIMMY(4) 11:40:44
大捧与胡萝卜一起用
winston(2) 11:40:52
这个太简陋
观察者(1) 11:40:53
管理既要管，更要理
winston(2) 11:41:00
我也碰见过这样的
winston(2) 11:41:07
平时天天请客吃饭
JIMMY(4) 11:41:14
细节要搞清楚
winston(2) 11:41:16
工作天天骂人骂街
winston(2) 11:41:26
这个大家也难以接受
观察者(1) 11:41:33
要用规范去约束，更要因地制宜的去调理
JIMMY(4) 11:41:38
项目经理也要关心细节嘛
winston(2) 11:41:42
对
JIMMY(4) 11:42:09
其实应该这样.详细设计的时候.要尽可能详细
JIMMY(4) 11:42:39
这样.程序员就不会偏离航道了.定死了如何做.
winston(2) 11:42:44
这同样有个度
winston(2) 11:42:55
过于细节，会导致另外一个问题
winston(2) 11:43:06
大家认为产品完美了，不想改进
JIMMY(4) 11:43:12
程序员觉得没有发挥空间?
winston(2) 11:43:30
一般是控制到大体的UI和流程
JIMMY(4) 11:43:33
不会的.产品与需求会与时俱进的
JIMMY(4) 11:43:44
看MS OFFICE就知道了.
winston(2) 11:43:54
能符合用户案例和推出的细节
winston(2) 11:44:04
测试部门，能根据规范，制定测试计划
winston(2) 11:44:11
敏捷管不了测试
JIMMY(4) 11:44:17
MS的想法很好的.看他们的结构.很多都考虑到以后.都有RESERVED的
观察者(1) 11:44:21
我看过一个文章讲的是治理迟到问题的，公司分为两个部门，行政和销售，开始的时候迟到现象严重，老大就出台政策严惩迟到的，重罚。结果是行政部门的迟到现象明显改善，而销售部门的迟到现象却越演越烈。
winston(2) 11:44:32
只能是程序员自己写测试驱动
winston(2) 11:44:48
有点意思
okmmno1<5> 11:44:53
同意winston 我一向的观点就是: 人是最不可靠的。
winston(2) 11:44:55
结果是什么？
JIMMY(4) 11:45:09
敏捷开发.不是先写测试.再写代码么
Linker.Lin(3) 11:45:12
恩
winston(2) 11:45:13
对
JIMMY(4) 11:45:16
人是最不可信的
Linker.Lin(3) 11:45:22
测试确实要跟上
winston(2) 11:45:23
但是，那个和测试部门的测试，两码事啊
观察者(1) 11:45:29
后来老大采取，销售部门的人先来先挑客户的办法，然后销售部门的迟到就解决了
winston(2) 11:45:37
呵呵
Linker.Lin(3) 11:45:39
不过单元测试太费了
winston(2) 11:45:41
有创意
okmmno1<5> 11:45:41
信任不等于放任， 放任的结果只有一个， 人心涣散，不知所从
okmmno1<5> 11:46:00
单元测试一定要做。 这个应该和开发的重要程度放在一个层面上。
winston(2) 11:46:01
我带过开发、测试、运维、设计几个团队
winston(2) 11:46:13
栽的跟头太多了
winston(2) 11:46:17
深有体会
JIMMY(4) 11:46:18
其实.软件工程和公司管理息息相关
winston(2) 11:46:22
是啊
JIMMY(4) 11:46:31
道理是一样的
winston(2) 11:46:36
回到刚才的问题，老大发话，要大家什么什么时间，搞成什么东西
winston(2) 11:46:42
比如第二版本
猴子笨的(6) 11:46:47
观察者(1) 11:46:47
我觉得敏捷里面将设计的难度转嫁到写测试上去了，写出好的测试实际上就是做了好的设计
okmmno1<5> 11:46:50
呵呵 其实说到底， 所有的软件工程 不外乎一个东西：治人
winston(2) 11:47:03
你作为老大的将，怎么办？
猴子笨的(6) 11:47:06
我还在程序员里混
JIMMY(4) 11:47:16
应该不能说是治人.应该说是榨干人的价值
okmmno1<5> 11:47:24
所以看看 社会心理学还是比较好的， 哈哈。
Linker.Lin(3) 11:47:26
winston(2) 11:47:30
如果你跟老大一样，去鼓励、压榨下面的人
winston(2) 11:47:34
拼命加班，去搞
winston(2) 11:47:38
就完蛋了
winston(2) 11:47:50
因为BOSS为了一些目的
JIMMY(4) 11:47:54
我反对加班
okmmno1<5> 11:47:57
治人不等于榨人啊我最不赞成的就是长时间的加班深有感触， 效率太低。
winston(2) 11:47:58
会故意压低时间
JIMMY(4) 11:48:01
从不加班
Linker.Lin(3) 11:48:13
加班很容易引起跳槽的
JIMMY(4) 11:48:16
而且我加班最少都是要1.5倍
winston(2) 11:48:18
有的老板，本来2个月做的事情，他非得说1个月搞完
winston(2) 11:48:31
所以，你必须头脑清醒
观察者(1) 11:48:35
对winston(2) 11:47:03
你作为老大的将，怎么办？
这个问题，首先必须对自己团队有个清楚的认识，知道什么时候能做出什么样的东西来，你才能回答老大的问题
如果时间太紧，确实无法完成，那么可以和老大谈谈缩减功能
winston(2) 11:48:46
对！
winston(2) 11:48:53
这点咱们认识一样
JIMMY(4) 11:48:59
凡事.可行性需求设计都要考虑清楚.
winston(2) 11:49:11
你必须认识到时间、资源、功能的约束关系
JIMMY(4) 11:49:22
是啊.不然没法搞
okmmno1<5> 11:49:27
恩， 这个平衡不好取啊，
JIMMY(4) 11:49:31
就是做出来也会问题多多
winston(2) 11:49:34
如果说时间卡死了，那好，要求公司增加人力、资源，减少功能
观察者(1) 11:49:42
不光是我要认识，老大也必须要有这个认识才行
winston(2) 11:49:52
否则你强行推行，往往失败，人心散尽
观察者(1) 11:50:00
说服老大是你的工作之一
JIMMY(4) 11:50:12
所以沟通很重要
winston(2) 11:50:14
问题在于，作为投资者的BOSS，对这种规律，往往缺乏认识
winston(2) 11:50:28
什么BOSS都有
winston(2) 11:50:41
有的CEO是销售出身
winston(2) 11:50:49
我碰见过
JIMMY(4) 11:50:53
缩减功能喽.先做最重要的.
观察者(1) 11:50:53
有本书叫管理上司的艺术
winston(2) 11:51:01
觉得程序开发，简单无比
Linker.Lin(3) 11:51:12
winston(2) 11:51:14
无法理解那么多人，连这个破功能也做不出来
Linker.Lin(3) 11:51:22
winston(2) 11:51:29
这个就靠你自己解决了。
Linker.Lin(3) 11:51:31
Linker.Lin(3) 11:51:42
估计只能换老板了
okmmno1<5> 11:51:47
呵呵
winston(2) 11:51:51
有时候身不由己
JIMMY(4) 11:51:56
okmmno1<5> 11:52:02
好的项目经理， 最重要的时间应该是和上司的沟通
winston(2) 11:52:02
换老板，也要看时机 啊
JIMMY(4) 11:52:07
看在钱的份上.忍了?
观察者(1) 11:52:10
实在不行就炒他鱿鱼
winston(2) 11:52:10
不全面
okmmno1<5> 11:52:23
还有呢？
观察者(1) 11:52:52
应该这样说，没有上司的支持，再好的项目经理也只能干瞪眼
JIMMY(4) 11:52:54
VISTA延时多多.功能大减.不知道MS是如何处理的
winston(2) 11:52:55
项目经理的职能，不能只是重点和上司沟通
winston(2) 11:53:03
对，boss看不上你
winston(2) 11:53:07
你赶快跑吧
winston(2) 11:53:09
没戏了
JIMMY(4) 11:53:19
VISTA的项目管理应该算是失败吧?
winston(2) 11:53:21
至少上面的人支持才行
winston(2) 11:53:31
没法评论
winston(2) 11:53:48
再说说加班的事情
JIMMY(4) 11:53:54
MS的项目都失败多多,所以大家的项目失败了.也不奇怪了
winston(2) 11:53:58
我这个人，最反对无效的加班
观察者(1) 11:54:00
特别是在在大公司，项目经理算个屁啊，随便一个部门都不把你放在眼里，还不是看你是给哪个boss办事儿的
winston(2) 11:54:09
天天加班
JIMMY(4) 11:54:10
你们加班.有加班公交么
winston(2) 11:54:17
那就涉及到公司政治了
JIMMY(4) 11:54:20
有加班工资么?
winston(2) 11:54:24
不再我们讨论的范围
猴子笨的(6) 11:54:28
哎,加班,程序员没法回避的现实
winston(2) 11:54:30
天天加班的效果
winston(2) 11:54:33
我认为是负值
JIMMY(4) 11:54:38
肯定了
Linker.Lin(3) 11:54:39
我也这么看
winston(2) 11:54:40
道理如下
观察者(1) 11:54:48
但是这个会影响你的项目有时候忽略它是致命
winston(2) 11:54:50
1、天天加班，相当于时间偏移
Linker.Lin(3) 11:54:54
加班多了,手下离职率马上上去
JIMMY(4) 11:55:04
脑力过度利用.程序员身体变差
winston(2) 11:55:07
你原来9点来、6点回家
Linker.Lin(3) 11:55:23
一个人走了,对进度的影响超过加班的好处
winston(2) 11:55:25
天天加班，会变成，12点来，9点回去
winston(2) 11:55:31
算起来，毫无意义
winston(2) 11:55:41
而且，和不加班的那批人，无法协作
JIMMY(4) 11:55:42
没有时间去学习是程序员最大的问题
winston(2) 11:55:55
如果你强令，要加班，而且要早9点来
观察者(1) 11:55:56
你是在说华为吗？那个加班厉害哦
winston(2) 11:56:00
那大家都跑路了
winston(2) 11:56:06
人不是钢铁
okmmno1<5> 11:56:07
哈哈
okmmno1<5> 11:56:09
说得好
winston(2) 11:56:11
钢铁还疲劳呢
观察者(1) 11:56:13
但最后不是跑人是跳楼
winston(2) 11:56:14
何况人
Linker.Lin(3) 11:56:23
JIMMY(4) 11:56:25
WINSTON.你说的加班好象不一样哦
Linker.Lin(3) 11:56:29
这个情况我遇到过
JIMMY(4) 11:56:41
12点来.9点回去只是上班时间不同了
winston(2) 11:56:46
另外一个，加班带来的后果是，体力、脑力透支
winston(2) 11:56:56
严重透支后，质量大幅下降
winston(2) 11:57:02
系统的bug和各种问题
JIMMY(4) 11:57:04
平常人说的加班应该是9点来.10点回去
winston(2) 11:57:09
层出不穷
winston(2) 11:57:26
会大大延缓后面的发布和测试时间
JIMMY(4) 11:57:36
很多老板还是把程序员看成了流水线上的工人的.认为时间长.做的东西就多
winston(2) 11:57:38
所以天天加班结果，一定是负值
winston(2) 11:57:44
对啊
winston(2) 11:57:57
本群没有华为的兄弟吧？
JIMMY(4) 11:58:03
没有
JIMMY(4) 11:58:09
我不是华为的.哈哈
winston(2) 11:58:09
华为在这点，就非常变态
Linker.Lin(3) 11:58:09
我以前是
观察者(1) 11:58:08
观察者(1) 11:58:35
华为的兄弟，辛苦了
winston(2) 11:58:36
我没去过华为，但是有几个同事，都呆过
Linker.Lin(3) 11:58:50
我在华为带过队伍
JIMMY(4) 11:58:55
任正非是军人.军人嘛.服从管理
观察者(1) 11:58:57
我有个师兄就是华为疲劳死了的
winston(2) 11:59:03
天天加班，经常11点后回家
winston(2) 11:59:07
周六不休息
Linker.Lin(3) 11:59:08
上面的意思就是周周加班
JIMMY(4) 11:59:10
实际上.华为的收入现在也不算高了
Linker.Lin(3) 11:59:12
周日也加
winston(2) 11:59:19
那个兄弟，1年身体就不行了
Linker.Lin(3) 11:59:22
最后,我自己先跑路了
winston(2) 11:59:24
立马辞职
观察者(1) 11:59:32
华为的情况不止他一家
winston(2) 11:59:39
而且他反应，加班无效
观察者(1) 11:59:42
很多研究所也是这样
winston(2) 11:59:47
关键是做事不对路
观察者(1) 11:59:52
其他行业也有更变态的
观察者(1) 12:00:00
比如建筑设计行业
JIMMY(4) 12:00:05
想法最重要.想好了做起来就快了
winston(2) 12:00:05
他搞软件的，还是沿用华为传统的搞硬件的那一套
JIMMY(4) 12:00:16
没有IDEA.天天拼命加班都没有用的
JIMMY(4) 12:00:35
想比做更重要
观察者(1) 12:00:40
华为的利润是相当相当高的哦，这点还是很成功的
页:
[1]