Mission Impossible?解决问题之道(四)

以前我在做编码的时候,意识到交互设计上会引起很多编码的问题,于是我投入了大量时间去研究交互和使用者心理、工作习惯,发现一个好的模式就是大量参阅那些广受欢迎的产品设计;后来我做设计的时候,意识到需求粗糙、开发水平偏差会导致最终无法产生完美的产品,于是我投入了大量时间去跟踪分析需求的变更和基础框架的编写;再后来我做项目管理的时候,意识到沟通信息的不对称、不合理的授权与决策均会导致项目的失败,于是投入了许多精力去研究一致性表达、排除干扰因素与结构化决策过程。

这些,都属于同一个范畴之:“软件开发项目”。这种经验告诉我,许多问题的解决,最终你不得不离开你本来的位置,从另一个完全陌生的领域去寻找解决方案。

在读《人月神话》之前我读过《人件》,只给了它一星的评价,因为作者的眼光实在是肤浅。21世纪的信息化工人阶级不会上街游行声讨良好的工作环境和福利,而是以书、贴子等更IT的方式,但这并不是什么新鲜的思想。然后我对《人月神话》等IT类的管理书籍评价都不很高。上周花时间快速阅读过这本书后,在综合同期未读完的《文化VS技术创新》这本书的章节上,我有了一个全新的视角。

《人月神话》的作者与大多数软件项目的从业人员一样,视野和手段过度束缚在软件开发领域内部。

《文化VS技术创新》里有一个很好的例子,这个例子也是回溯半个世纪的半导体时代。化学家们在实验室中致力于解决半导体纯度而遇到瓶颈时,没有发现晶体增长的奥妙,而这对于物理学家来说,却是普通的知识。如果在那个团队中有物理学家,结果可能就完全不一样了。晶体管的出现是电子产品的一个飞跃时刻,造就了诸如索尼这样的一批世界级企业。

软件开发也一样。在许多项目中,开发者为解决编译型语言在修改、发布时的诸多麻烦而“发明”许多配置文件和解藕容器、反编译加载(这个我已经快三年不用,原有的名称竟然想不起来了),把项目的体系弄得极端庞大而复杂;而日本人松本行弘转而向语言开刀,弄出了兼顾面向对象而又勿须编译的Ruby语言。这就是从问题引发点着手而根本解决的一个例子。

而离开技术,再来看看项目,关于对质量、效率同时兼顾的问题。首先我认为这是一个难题,但随后我得告诉你,你得离开产品本身,去思考“项目如何才算成功?”即项目的第一目标。如何与Stakeholders谈判,把握客户的心理接受曲线,将产品做到用户接受的平衡点上,这些,才是项目成功的关键因素,而非质量和效率这么简单。而更多关于实际的沟通、团队协作,这需要与专业的管理人员一起工作,请他们参与到项目中来,寻找合适的沟通模式,你会发现:原来事情就是这么简单。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero