2009年09月10日 星期四 15:12
Kermit Mei wrote: > 不好意思,我不太理解你上面讲的 “真正重要的话题”,因为管理所认为的真 > 正重要的话题往往都在业务上,他们不关心技术,只关心用多少时间和人力成本可 > 以实现。 但是,我们怎么通过把我业务上的东西来赢得技术上的话语权呢? > 这个问题很大,最好通过案例说明。简单抽象地说业务和技术实现关系很密并且很 细,当我们通常谈“业务”的时候,我们谈的是一个百来字能说清楚的东西,但是为 了定义实现所需要了解的“业务”,则需分类细说,千余字说不清楚,同时,在发现 说不清楚的地方的过程中,参与的人都了解了他们对“业务”并没有把握。对需求把 握擅长的专家,能通过一些问题使参与各方了解他们对业务理解不一致和不理解的 地方。业务需求如果定义清晰,你就有一些主动,因为你知道你在讨论什么问题, 别人只知道问题的答案(42)但是不知道问题是什么。 只能小举两个例子,多的没时间,也不易讲清楚。例子一:如果部门不能对文档有 效管理(因为执行力),或者对文档有效管理产生的新问题会抵掉文档管理的便利 (比如提高了某部门的压力),那么在解决这些问题之前,上马文档管理易于把研 发队伍拖入不该由他们解决的问题上,不管是用VB还是用Python。这些不该由他们 解决的问题会变成他们能解决的形式(如:提高界面美观)出现在他们面前。例子 二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响 数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种 情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变 化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间 长篇大论了。改日如果做blog再说。
2009年09月14日 星期一 10:32
这个话题已经变了,我换了个主题,请理解。 On Thu, 2009-09-10 at 15:12 +0800, Zhang Weiwu wrote: > Kermit Mei wrote: > > 不好意思,我不太理解你上面讲的 “真正重要的话题”,因为管理所认为的真 > > 正重要的话题往往都在业务上,他们不关心技术,只关心用多少时间和人力成本可 > > 以实现。 但是,我们怎么通过把我业务上的东西来赢得技术上的话语权呢? > > > 这个问题很大,最好通过案例说明。简单抽象地说业务和技术实现关系很密并且很 > 细,当我们通常谈“业务”的时候,我们谈的是一个百来字能说清楚的东西,但是为 > 了定义实现所需要了解的“业务”,则需分类细说,千余字说不清楚,同时,在发现 > 说不清楚的地方的过程中,参与的人都了解了他们对“业务”并没有把握。对需求把 > 握擅长的专家,能通过一些问题使参与各方了解他们对业务理解不一致和不理解的 > 地方。业务需求如果定义清晰,你就有一些主动,因为你知道你在讨论什么问题, > 别人只知道问题的答案(42)但是不知道问题是什么。 > > 只能小举两个例子,多的没时间,也不易讲清楚。例子一:如果部门不能对文档有 > 效管理(因为执行力),或者对文档有效管理产生的新问题会抵掉文档管理的便利 > (比如提高了某部门的压力),那么在解决这些问题之前,上马文档管理易于把研 > 发队伍拖入不该由他们解决的问题上,不管是用VB还是用Python。这些不该由他们 > 解决的问题会变成他们能解决的形式(如:提高界面美观)出现在他们面前。 你说得太准了,我现在就正在承受这这种痛苦! 我们的文档确实很没有用,至少对 我没有任何帮助,相反浪费了我的时间和工作的灵活性。最后,很多问题还都真的 是以“提高界面美观”的形式出现在我面前。 > 例子 > 二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响 > 数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种 > 情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变 > 化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间 > 长篇大论了。改日如果做blog再说。 我们的工作流程管理方法是老大让我们把自己要做的工作陈列出来,写成一个 worklist,最后按照这个worklist分优先级和时间来完成工作。 其实,我们的管 理者就是想明确我们要做什么,要多长时间来做,以什么顺序来做。但是很遗憾, 我往往只有今天做好了,才知道明天要做什么,后天可能要做什么,还有昨天和前 天做得对不对。 当然,我得承认这和我的工作经验有关系,因为我目前没有办法 预先清楚地知道我这一个月甚至更长的时间有多少东西要做,怎么做,要多长时间 来做。 管理者的思路我很清楚,他不了解相关技术的实现,但又想要更好地管理 我们,管理这个项目。他希望在会议上能够给出高层一个准确的时间。 …… 再说下去就收不住了,我就此打住吧。 我记得以前ZQ发过一个讲软件工程管理模式的链接: http://www.zeuux.org/pipermail/zeuux-universe/2009-January/003234.html 当时没有实际经验,没太看懂。今天再回头来看,上面所讲到的大部分问题我都遇 到了。 金锤子: 最开始时,我们的老大希望我用txt文本来管理所有数据,因为他比较擅 长这种技术。但是我坚决拒绝,并使用sqlite3,因为我自己以前写过这种用txt管 理数据的程序,这种实现势必会要求我做很多低技术含量的编码工作,而且扩展性 极差。 资源滥用:我们现在UI和底层的配合过程中这点尤为突出,因为急于给上层和市场 部看到效果,缺乏从整体上的协调,因此上下层都开了线程(我坚持认为很多实现 只要一方开线程就够了)。 大泥球:代码依赖问题比较严重,具体表现在各个模块之间的依赖问题,我认为各 个模块是应该可以独立编译和调试的,但现在我离开底层的代码集就不能直接编译 了…… 英雄模式:这以前使我一直期望看到的软件开发模式,但现在才认识到,这个模式 也是有缺陷的——尤其是当我们无法得到一个英雄的时候…… 非自动化:这个问题就更明显了,如没有用宏管理调试代码,没有用svn/git等管 理工具等等,就不细说了。 当问题很多的时候,当我们没有找到更好的解决途径的时候,我觉得就是要跳出科 学管理方法的思维的时候了。此时,项目成功的唯一的希望就是团队的每一个人都 希望这个项目成功,大家暂时不计得失,全力以赴——这或许已是我们目前唯一能说 的上成功的地方了,呵呵。 To Zhang WeiWu: 感谢您不厌其烦的帮助! 你所提出的这两个问题都是我所遇到的,但是我还没有找到解决这些问题的方法。 其实我还有很多问题,但不好意思再在细节问题上浪费您的时间,很期待看到您的 blog再做思考。 Regards Kermit
2009年09月14日 星期一 10:57
Kermit Mei wrote: > 这个话题已经变了,我换了个主题,请理解。 > > On Thu, 2009-09-10 at 15:12 +0800, Zhang Weiwu wrote: > >> 例子 >> 二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响 >> 数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种 >> 情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变 >> 化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间 >> 长篇大论了。改日如果做blog再说。 >> > > 我们的工作流程管理方法是 报歉我可能没有说清楚,我上信整信都在讲需求,还没有涉及到开发方法,你回信 提到的项目管理都是开发方法和软件研发意义上的项目管理。当然最容易进入研发 人员眼帘的是工作方法而非需求。需求涉及到要做什么而非如何做,软件项目团队 一般对如何做很有经验或者兴趣,对要做什么就少一些了。我原文的意思是对“要 做什么”的理解可执“如何做”的牛角。就上面说的例二吧,我说的是用户的工作流 程,不是开发者的工作流程:) 需求和研发方法的关系我希望找个时间撰文来说。
2009年09月14日 星期一 11:25
On Mon, 2009-09-14 at 10:57 +0800, Zhang Weiwu wrote: > Kermit Mei wrote: > > 这个话题已经变了,我换了个主题,请理解。 > > > > On Thu, 2009-09-10 at 15:12 +0800, Zhang Weiwu wrote: > > > >> 例子 > >> 二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响 > >> 数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种 > >> 情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变 > >> 化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间 > >> 长篇大论了。改日如果做blog再说。 > >> > > > > 我们的工作流程管理方法是 > 报歉我可能没有说清楚,我上信整信都在讲需求,还没有涉及到开发方法,你回信 > 提到的项目管理都是开发方法和软件研发意义上的项目管理。当然最容易进入研发 > 人员眼帘的是工作方法而非需求。需求涉及到要做什么而非如何做,软件项目团队 > 一般对如何做很有经验或者兴趣,对要做什么就少一些了。我原文的意思是对“要 > 做什么”的理解可执“如何做”的牛角。就上面说的例二吧,我说的是用户的工作流 > 程,不是开发者的工作流程:) 抱歉,是我没有理解到位! 我确实很容易陷入“如何做”的思维中。其实有这种思维也很正常: “要做什么呢?”->“哦,可能需要做这个”->“怎么做?” -> “……%¥#%……(循环 在这里)” 或者: “用户的工作流程”是由用户和我的manager决定的,而他们可能都不是做技术的, 所以到开发者这里就只能思考“怎么做的问题”,也就是“开发者的工作流程问 题”。 我感觉开发者很少会思考一个问题:“需要这么做吗?” 有时是因为我们没有习惯,但是更多的情况下则是因为想了也没用,这不是我们能 决定的…… 这可能也是我一开始没能正确理解你所讲内容的一个原因。 > 需求和研发方法的关系我希望找个时间撰文来说。 很期待! Thanks Regards Kermit
Zeuux © 2024
京ICP备05028076号