数字化管理类
生产控制类
研发设计类
AIoT类
鼎捷雅典娜
话题与应用
制造业
流通业
资源中心
服务
直播活动
地区活动
会议活动
了解鼎捷
新闻中心
企业荣誉
加入鼎捷 
联系我们与工程有关的问题
文：鼎捷ERP
作者：Z6·尊龙「中国」官方网站 | 发布时间：2012-11-30 14:50:34
第六节工程
? 较狭义的工程，是描述“做什么”和“做到什么”。
? 也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是
“过程”和“方法”的事；而有效、快速地实现“过程”和“方法”所需的，就是“工具”。
??? 这种软件工程体系层次(SoftwareEngineeringArchitecturalLayers)被描述成一张图，我很有幸地在第一次画它的时候，将它画成了一堆牛屎。因此我从此都把它叫“牛屎图”：
??? 过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的呢?
??? 很显然，软件规模的不断增大是根本的原因。所以你会看到在几年前，开发一个工具可以不讲工程；或者现在在你的WORD中，为了将半角替换成全角字符而写的那个宏，也不需要工程。
??? 接下来，即使协同软件规模增大，如果有一个牛人中的超牛人，愿意用20年来写一个任意庞大和复杂的操作系统，他也是能做到的。然而现实中不会有软件公司给他这样的机会。
??? 项目的“复杂”可能要求不同知识领域的角色参与，而“庞大”则要求更多的(人力、技术与管理)资源。? “团队”作为开发行为的模式，是软件规�：透丛佣冉ゴ卫刍慕峁�。
??? 团队必将越来越庞大，因为(与工程对应的)软件规模必将越来越复杂。没有团队意识的软件公司在高度过程化、通晓方法理论、拥有大量工具的集团军面前，必将一触即溃。
第七节 组织
??? 工程理论其实是包含组织学的。然而我在上面的那张图中，将组织与工程分离开来，并在二者之间画下了一道纵向的线。
??? 即使如图上所表现的那样，工程关心的是“需求”、? “配置”和“文档”等等这样一些要素，那么这样的工程还是停留在技术层面的：关注的还是工程的实现细节，而非目标。从角色的角度来看，这是项目经理和技术经理所共同关注的那一部分。
??? 作为那个解结的人，你应该知道这个图例上的需求管理决定了你的阶段性目标，配置管理决定了你检测的方法，相关的文档化工作是沟通的渠道，以及协调团队矛盾的手段。? ‘‘需求”、? “配置”和“文档”等等不仅仅是你每日一成不变的、模式化的工作步骤，而且也是解结的工具与方法，或者是你实施管理思想的道具。
??? 此外，你(项目经理)还必须关注于人力资源、项目资金及多个项目之间的协调等。这些与工程本身并没有直接关系，而是“组织”方面的内容。
??? 所以在工程环节中，“文档管理”和“配置管理”等中的那个词汇“管理”，是管理的具体技术和方法；而在“组织”这个环节中的这个“管理”，才是真正的管理学上的用词。
??? 我在这张图上，试图从这个角度上来说明：作为项目经理，你必须有一部分的工作是非技术性的。甚至，你可能绝大部分的工作是非技术性的——因为与技术相关的管理技能(需求、配置、过程管理等)可以由开发经理来做，或者公司对于这一方面有较统一且成熟的规范，因而无须投入过多的精力。
??? 你必须更关注于对这个(或这些)工程的组织与计划。站在“组织者”这个角色上，你现在要考虑的内容可能会是：
??? 》??? 为项目的各个阶段建立计划，并逐渐地细化计划的内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度；
??? 》??? 确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目?的质量目标及其评核办法；
??? 》??? 对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；
??? 》??? 为每二个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512M内存变成2G，还包括准确地评估他的工作量，以及决定是否为他增加一个(能协同工作的)副手；
??? 》??? 决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；
??? 》??? 习惯于开会、组织更短而有效的会议，以及建立激励机制，? 当然也刀、要忘记让每一个成员意识到这一项目的风险；
??? 》? 不要乐观。
??? 即使你做好这一切，可能项目的结果仍然不够理想。但是你应该知道，好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。
??? 无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。——在—个团队中，失去了组员的信任比失去老板的信任更可怕。
? 所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
第八节BOSS
??? 很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由以下三个角色来做出的：
??? 》??? 部门／团队经理：你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。
??? 》??? 纪效经理：如果你的公司有这个角色的话，那么他总是盯着你的错误以决定你薪水的扣除比例。
??? 》??? 财务经理：有钱?没钱?没钱?有钱?……
??? BOSS并不决定你的薪水。
??? BOSS在公司中解决的是‘‘经营’’问题。这其实是在比“组织”更靠外侧的一层——在前面的图例中并没有给出，这也意味着“经营者”与“工程”基本没有关系。
??? 在一个更大规模的组织机构里，你可以更直接地观察到“经营者”与“组织者’’之间的差异。例如公司的大小股东是“经营者”，董事会通常是解决经营问题的地方；而总经理、执行经理及各个部门经理则是各级的“组织者”，经理办公会则是解决组织问题的地方。
??? 你应该清楚，真正的BOSS是经营者。这有助于你明确你被雇来的原因，你的工作是面向哪一个层面的，以及你或者你的上司有没有权限来决定一个项目是否应该立项，或者中止。
??? BOSS(经营者)决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。
? 工程中没有BOSS。
第九节上帝之手
??? 从较初的简单编程开始，到现在工程团队的组织开发，实现(一个软件)都是较终的目的。所以可以这样说：实现，是软件开发的本质需求。
??? 我们看到，正是出于实现的需要，我们才设计了一些数据结构或逻辑结构来映射物理模型。因此类似于过程、单元、记录(结构)、对象等的出现，其实都是出于编程实现的需要：
??? 而后，基于某种数据结构的编程实践(的不断积累)，决定了软件开发方法理论的产生。
? 从这一点可以看出：方法，是对既有行为的归纳总结。
? 因而实现方法总是较先出现的，而后才有分析和设计方法。
??? 可以看到面向对象分析(OOA)、设计(OOD)与编程(OOP)的出现顺序，与它们在工程过程中的实作顺序正好相反，而与编程实践行为的顺序则正好相同。
? 为了实现更大规模的软件供应链管理系统而有了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了(模型化)语言的出现。如同编程工具中的编译器和集成开发环境(1DE)一样，开发中的编程语言、过程中的建模语言都只是一种工具。
? 工具的产生仍旧是出于‘‘(软件)实现’’的需要。不可能从工作流软件开发实践中产生出轮子和指南针，因为那不是‘‘软件开发的本质需求’’可以推动的。软件工程的体系中，? “实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。
上一页：协同软件工程语言
下一页：项目实施过程中的工具
相关新闻
-
项目实施过程中的工具
秦国中兴到秦王朝建立的三百年时间里，史书中的秦国，就是两条法令：决裂阡陌、军功受爵；一个结果：耕战。秦国不看重“同时舞弄七把剑”这样的技艺，而注重能否以剑尖快速地刺杀敌人这样的技术。
-
项目管理者和技术者的成才之路
《墨子·公输》中记载了一段故事，说楚国想去攻打宋国，鲁班就为楚国造了攻城的云梯。他要么顺着代码铺就的道路，亦步亦趋地成为良匠大师；要么就看透工具的本质，把关注点转移到“团队”的圈子里去。
-
协同软件工程语言
愚公在数千年前就在用类同的行为做编程实践，而几十万年前的智人，也在循环与分支所构成的逻辑中打转。长期的编程实践，自然的归演与总结，必须沉淀为某种(软件开发)方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。
产品方案 
预约演示 
价格咨询
官方公众号 
1v1专属客服 
扫码添加专属客服
