zeuux-universe  - 讨论区

标题:[zeuux-universe] 请教字体库问题

2009年09月10日 星期四 15:12

Zhang Weiwu zhangweiwu在realss.com
星期四 九月 10 15:12:53 CST 2009

Kermit Mei wrote:
>     不好意思,我不太理解你上面讲的 “真正重要的话题”,因为管理所认为的真
> 正重要的话题往往都在业务上,他们不关心技术,只关心用多少时间和人力成本可
> 以实现。 但是,我们怎么通过把我业务上的东西来赢得技术上的话语权呢?
>   
这个问题很大,最好通过案例说明。简单抽象地说业务和技术实现关系很密并且很
细,当我们通常谈“业务”的时候,我们谈的是一个百来字能说清楚的东西,但是为
了定义实现所需要了解的“业务”,则需分类细说,千余字说不清楚,同时,在发现
说不清楚的地方的过程中,参与的人都了解了他们对“业务”并没有把握。对需求把
握擅长的专家,能通过一些问题使参与各方了解他们对业务理解不一致和不理解的
地方。业务需求如果定义清晰,你就有一些主动,因为你知道你在讨论什么问题,
别人只知道问题的答案(42)但是不知道问题是什么。

只能小举两个例子,多的没时间,也不易讲清楚。例子一:如果部门不能对文档有
效管理(因为执行力),或者对文档有效管理产生的新问题会抵掉文档管理的便利
(比如提高了某部门的压力),那么在解决这些问题之前,上马文档管理易于把研
发队伍拖入不该由他们解决的问题上,不管是用VB还是用Python。这些不该由他们
解决的问题会变成他们能解决的形式(如:提高界面美观)出现在他们面前。例子
二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响
数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种
情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变
化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间
长篇大论了。改日如果做blog再说。

[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

2009年09月14日 星期一 10:32

Kermit Mei kermit.mei在gmail.com
星期一 九月 14 10:32:53 CST 2009

这个话题已经变了,我换了个主题,请理解。

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 



[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

2009年09月14日 星期一 10:57

Zhang Weiwu zhangweiwu在realss.com
星期一 九月 14 10:57:38 CST 2009

Kermit Mei wrote:
> 这个话题已经变了,我换了个主题,请理解。
>
> On Thu, 2009-09-10 at 15:12 +0800, Zhang Weiwu wrote:
>   
>> 例子
>> 二:如果缺少指导思想来稳定工作流程方法,则需要经常对工作流调整,从而影响
>> 数据质量,然而可能会表现为这种技术需求:系统应该适应灵活的工作流程。这种
>> 情况下,系统越合于用户要求,问题越严重,因为工作流程便于调整带来的经常变
>> 化制造的问题更多一些。和话题结合多的界面方面也能举出例子,但是今日没时间
>> 长篇大论了。改日如果做blog再说。
>>     
>
> 我们的工作流程管理方法是
报歉我可能没有说清楚,我上信整信都在讲需求,还没有涉及到开发方法,你回信
提到的项目管理都是开发方法和软件研发意义上的项目管理。当然最容易进入研发
人员眼帘的是工作方法而非需求。需求涉及到要做什么而非如何做,软件项目团队
一般对如何做很有经验或者兴趣,对要做什么就少一些了。我原文的意思是对“要
做什么”的理解可执“如何做”的牛角。就上面说的例二吧,我说的是用户的工作流
程,不是开发者的工作流程:)

需求和研发方法的关系我希望找个时间撰文来说。


[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

2009年09月14日 星期一 11:25

Kermit Mei kermit.mei在gmail.com
星期一 九月 14 11:25:23 CST 2009

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


[导入自Mailman归档:http://www.zeuux.org/pipermail/zeuux-universe]

如下红色区域有误,请重新填写。

    你的回复:

    请 登录 后回复。还没有在Zeuux哲思注册吗?现在 注册 !

    Zeuux © 2024

    京ICP备05028076号