项目沟通该不该透明？
有观点认为，项目沟通应高度透明，这样可以提高沟通效率、增强团队凝聚力、消除分歧。清代名臣曾国藩说，“谋可寡而不可众，利可共而不可独”。我赞同曾的观点。 团队是非常模糊的概念，没有明确的定义，也没有明确的衡量标准。的确，团队内部的沟通应高度透明。问题是，如何衡量团队的边界？团队具体包含哪些成员？治理一个国家尚且只需要十人左右的最高层级领导，我们一个小小的项目又究竟需要几人构成团队呢？ 正确的理解：项目团队内部的沟通应该高度透明，对项目团队外部应适当信息屏蔽。项目团队至少应具有强大的共同利益，且数
应禁止业务人员做技术决策
外行指挥内行是浪费的开始。业务人员通常为项目销售或用户代表。业务人员精通应用场景、用户需求，部分业务人员可能懂写技术，经常根据对业务场景的理解直接将其转换为技术实现方式，并将具体技术实现方式反馈给技术人员。 上述行为普遍存在，很容易对技术人员造成困惑。现实中，应尽最大可能将业务人员赶到应用场景中去，业务人员有应用场景决策权，但绝不允许其做技术实现决策。同时，应最大可能将技术人员赶到技术实现中去，技术人员有技术决策权，但绝不允许技术人员改变应用场景。 实现上述流程，要求在项目组织架构上应具备唯一
为什么技术和价值会分离？
理想中，技术含量越高的产品、工程，价值相应越高。实际上，价值由买方需求强烈程度决定，与技术的关系微乎其微。原因？ 1）价值＝需求，价值＝技术？ 前一个等式亘古不变。后一个等式只是技术人员的臆想，是乌托邦式的存在。 2）如果说商战是一局像棋，“技术”充其量算个“车”，而价值是整盘棋。 营销造就了技术和价值之间的横沟，甚至有可能非常深。 3）如果不谈论价值，技术一无是处。 技术是解决问题的方法及方法原理。解决问题是前提。 4）技术的核心是成本。解决值不值得的问题。 比如登陆火星。从技术上看，人类或
技术不应追求单体高利润
企业的根本目的是追求利润，不同企业的利润或低或高，但技术不应追求单体高利润。 1）利润是由“技术+营销”决定的 技术单独很难创造高利润，甚至连利润也无法创造。在企业经营中，技术和营销，如同一个硬币的两面，缺一不可。 2）高利润是营销艺术，与技术无关 高水平的技术竞争，不可能存在生产率差异很高的状态。技术与物打交道，价值由人决定，这也决定了技术研究者不可能精于价值研究，固然与高利润无关。 3）技术倾向于“薄利多销” 技术在单个用户层面应保持适度低利润。同时，将追求高利润的权力交给市场营销。
项目管控的人本三要素
从量化指标看，成本、进度、范围是项目管控的物化三要素。从人本角度看，组织形式、互动和目标构成项目管控的人本三要素。 1）组织形式 组织形式涉及权力分配、责任承担和利益获取，简言之，涉及人们最关切的责、权、利三个层面。如同下棋，组织形式就是排兵布阵、子力规定及行棋规则。 2）互动 互动是具体行棋。只有合理、有效互动才能赢棋。互动应在组织形式的规定下，向着目标稳步推进。考虑互动绝不应局限于物化范畴，应充分考虑人的要素，比如团队活力、配合顺畅度等。只在物化范畴考虑互动是十分悲剧的。 3）目标 项目过
该追求简单，还是追求正确？
如果这么问：该追求治标，还是追求治本？相信我们都会选择治本。治标只是暂时的。同样，在项目管理中，正确只是暂时的，正确与否由客户需求决定，客户需求永远在不停的变化中。我们认为“正确”只是暂时的一点都不为过。相比“正确”，追求“简单”才是治本，简单是内功的，具有很强的适应性和抵抗力。 治标不重要吗？不是。如果我们不能把事情做正确，还会有下一次的机会吗？如果撑不过今天，如何能看到明天的太阳呢，“简单”的内力又如何发挥呢？项目管理中，一方面要不断地追求简单，不断地优化、优化、再优化，包括代码、组织结构
故事：项目需求的最佳描述语言
如果要找一种描述形式，在小孩、大人、不同知识背景、不同文化背景、不同生活习惯、不同智力的人群中描述一种道理，这种形式非故事莫属。 我们对任何事物的学习几乎总是从故事开始，如果不通过故事，我们又如何让二三岁的孩子理解一些道理？ 在IT项目中，不懂软件的顾客对软件的理解或许还不如三岁小孩对简单道理的理解。如果我们试图用技术语言和客户沟通，与我们试图与三岁小孩将道理有何不同？ 或许，在项目需求层面，只有故事才是唯一能被客户、最终用户、开发人员、项目经理和公司高层等各方充分理解、沟通的唯一世界语。
如何使用 docker 部署前端应用
docker 变得越来越流行，它可以轻便灵活地隔离环境，进行扩容，方便运维管理。对开发者也更方便开发，测试与部署。 最重要的是， 当你面对一个陌生的项目，你可以照着 Dockerfile，甚至不看文档(文档也不一定全，全也不一定对)就可以很快让它在本地跑起来。
绝不能由同一人担任的项目角色
在项目管理中，某些角色天然互斥，绝不能由同一人担任。比如：开发人员和测试人员、需求人员和开发人员。 开发和测绘是互斥的，我们大都比较容易理解，不论如何强调开发和测绘的协作，本质上开发是防守，测试是进攻，如同矛与盾，一定不能由同一人担任。 此外，需求人员和开发人员也是天然互斥的角色，一方面开发人员容易以技术实现的难以为中心“微调”需求，另一方面需求人员迫于客户压力常常不顾开发人员的死活固守客户需求，毫不变通。如果这两种角色由同一人单位，如同水与火，必将引起激烈的自我对抗。更重要的，我们无法让客户
需求不应以树结构组织
项目需求不应以树结构组织，不应对项目需求进行诸如1、1.1、1.2、1.1.1、1.1.2之类的编号。项目需求应以堆结构组织。 1）需求必须保持独立性 2）需求必须体现用户价值 3）需求必须具备高度的灵活性，以支持应变 4）树形结构组织的需求致使需求之间存在人为的层级关系，这只是一种技术描述语言，实际上，需求并不存在这种关系；树形结构的需求表述不利于体现用户价值，不以用户价值为中心的需求描述是无效的，应舍弃。 5）堆结构的灵活性符合以用户价值为中心的需求组织形式。
用户真的知道需求吗？
如果这么问：病人真的知道自己得了什么病吗？相信答案都是否定的。但在项目管理中，我们常常迷信用户知道自己的需求，试图从用户的口中问出需求。 去年拜访一位公安局客户，对方表达了这样的苦衷：如果我知道自己需要什么，甚至直到想做成什么样子，那还我要供应商做什么？我需要的是你的意见和见解，你的创新。 诚然，我们应该聆听用户的声音，但我们绝不能认为需求是用户表达出来的。实际上，需求本是不存在的，需求是由行业咨询专家创造出来的，是用户声音、专家经验等多方因素聚合、升华的结晶。不要再迷信用户声音，更不要迷信客
Linux - 用户管理与文件权限
目录 Linux - 用户管理与文件权限 创建普通用户 切换用户 userdel删除用户 sudo 命令 文件与目录权限 Linux权限的解读 目录权限 查看用户权限的命令 文件权限 修改权限的命令 修改文件权限属性 Linux - 用户管理与文件权限 现代操作系统一般属于多用户的操作系统，也就是说，同一台机器可以为多个用户建立账户，一般这些用户都是为普通用户，这些普通用户能同时登录这台计算机，计算机对这些用户分配一定的资源。 普通用户在所分配到的资源内进行各自的操作，相互之间不受影响。但是这
Linux 环境下安装python相关
目录 Linux 环境下安装python相关 linux软件包管理工具之yum工具(如同pip3工具) yum源理解 下载阿里云的.repo仓库文件 ，放到/etc/yum.repos.d/ yum安装nginx软件 linux环境编译安装python3 在linux下安装Django程序 安装python的虚拟环境, 解决多个解释器问题 解决本地开发环境，和线上开发环境一致性的问题 virtualenvwrapper工具学习(方便) Linux 环境下安装python相关 linux软件包管
百度富文本编辑器整合fastdfs文件服务器上传
技术：springboot+maven+ueditor 概述 百度富文本整合fastdfs文件服务器上传 详细 代码下载：http://www.demodashi.com/demo/15008.html 一、前言 (1）适合人群 1,java服务端开发人员 2,初级人员开发人员 3,了解spring springboot+maven 3，了解小程序开发跟前端人员接口对接 (2) 你需要准备什么？ 1,积极主动学习 2,微信开发基本流程 3,java后端几大框架掌握如(spring spring
MySQL和SQLyog的配置-安装及遇到的问题
1. 安装MySQL 我先是参考了菜鸟教程上的#Windows 上安装 MySQL #版块的安装教程，不过经历了种种磨难，我最后是按照#此篇博客#安装成功的。 这两篇教程最大的差别是在于下载的版本不同。如下图： 前者下载的是 Other Downloads里的压缩包，下载后需要自己配置，过程比较复杂，适合深入学习，所以不推荐新手下载； 后者下载的就是 Recommended Downloads✔，直接图形化界面安装就好了，一路next，默认最基本的配置。 下载地址☛MySQ
今日推荐
周排行