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

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

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

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 

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

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

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