作为研发人员，我们的产出就是企业的弹药，我们的组织效率，是企业在市场上竞争的底气。为了提升效率，我已经在技术层面做了一部分工作，整理有关于软件研发生产效率的几点心得，在这里，我尝试着思考的是，如何从组织流程层面，去进一步提升效率。
在市场上，我们是以企业为单位去提供价值的，但是在企业内部，我们是有专业分工的组织和团队的，分工协作一方面有利于从专业层面提升价值，另一方面会带来沟通成本，分工协作的组织或个人都有自己的诉求，如果组织流程不畅，弊端丛生，就会削弱我们的生产能力，影响企业在市场上的发挥。
组织流程对生产效率的影响，主要在于利益相关者的关注点是否都得到了满足，在此基础上，我们采用科学的优化原则，从流程/工具/组织结构等方面着手，寻找适合自身的改进方向。
人是利益驱动的，要梳理一个组织流程，我们首先要发现利益相关者，检查一下是否所有人都在桌子上。
在研发生产活动中，一般流程是从市场部门提出需求，交给研发部门研发，研发部门完成研发后，把产品移交给运营部门，最后一起维持产品运转，这是企业层面的基本流程。
具体到相关角色，有产品经理、项目经理、设计、研发、测试、运营等，产品经理负责市场分析、用户研究和迭代设计，项目经理负责协调资源、控制成本、推动进度，设计负责保障产品的视觉呈现和交互体验，研发负责技术实现，运营负责把产品推向市场，并分析用户行为，推动产品持续迭代优化。
产品经理：深入理解市场/用户需求，理解人性与生活，梳理逻辑、优化体验。有理解用户的同理心；有深化产品的专业性；有追求体验的审美与敏感，有良好的沟通和足够的抗压能力。
产品经理的关注的是：功能能不能满足业务需要、体验能不能满足用户、版本迭代的节奏能不能满足市场要求，相对竞品能不能建立和保持优势。
项目经理：在有限的时间和成本下，协调内外部资源，合理安排工期、推动项目进度、管控质量风险。
项目经理关注的是：项目四要素（范围、时间、质量、成本）是不是得到了合理的平衡，资源是不是够用、排期能否优化、成本（人月）有没有超支、质量是否合格、有没有潜在的风险，是否需要设立多个里程碑来分摊风险。
设计：利用外观、交互等手段，体现、创造和提升企业/产品/服务的品牌价值，设计出优雅而切合企业定位的美感，清晰的业务流程、舒适可信赖的交互感受，良好的有引导性的产品印象等。
设计关注的是：配色、布局等效果是不是美观、能不能起到突出重点、引导用户的作用、能不能建立品牌形象，用设计打动人心。
研发：开发业务功能、解决软件bug、提升质量、优化性能等。
研发关注的是：明确的需求说明、设计在技术实现上的可行性、尽早或尽量少地修改需求、充裕的开发时间、合理安排的工作优先级、尽早反馈bug。
测试：检查软件功能、发现逻辑缺陷、发现软件bug、确保每个版本质量可靠
测试关注的是：明确的测试用例，充裕的测试时间，合理安排的测试节奏。
运营：通过内容/社区/商务等手段，寻找用户、吸引用户、留存用户
运营关注的是：产品怎样吸引用户，吸引到多少用户，留下多少用户，怎样持续增加用户。
上文发掘了这么多角色，尽管都有共同的目标（创造企业价值），但是每个角色都有自己的关注点，需要有一个清晰的分工设计和流程划分，内部沟通尽量内部完成，实现高内聚，外部沟通划分好业务边界，减少沟通成本，具体要考虑的因素如下：
1.人与人的沟通
组织流程的重点在于沟通，尽一切手段提高沟通效率。
要达成这个目标，一方面要标准化，确定好每个角色的职责，这样每个人每个系统有明确的分工，除了问题知道马上找谁，避免踢皮球。另一方面要简化，流程的每个环节只涉及必要的角色，不干扰其他人，避免出现文山会海。
2.小团队
人的脑容量有限，能维系的关系也有限，所以大团队的沟通成本会呈指数级增长，亚马逊有个两个披萨原则，说的是团队规模不能过大，最好两个披萨就能喂饱整个团队。
从效率的角度，尽量根据业务需要，维持一个与业务对齐（内聚）的小而美的团队，事实上，大的团队组织一般都会因为沟通/成本/管理的问题，被拆分为一个个的小团队。
3.高内聚低耦合
如果要分小团队，团队内部的沟通成本就比团队间的沟通成本低许多，所以我们要尽量在团队内部解决问题，实现团队内部高内聚，团队之间低耦合。
一个高内聚的团队应该是自治的，最好按业务来划分，把沟通成本维持在系统内部，团队实现内聚，这样，每个团队就能对自己模块的整个生命周期负责。
低耦合的团队之间，会有明确业务边界，明确哪些问题确实需要与外部沟通，这其实就减少了和外部的沟通成本。
4.持续优化
一口吃不成胖子，给再多的时间，也没有完美的方案，我们要先解决能解决的问题，然后在时间的维度里不断迭代，持续优化。
有效的迭代优化，就需要引入戴明环模型，Plan(计划)-Do(执行)-Check(检查)-Action(纠正)，其实就是在计划和实施之后，要有一个回顾和评价，找到缺陷，优化下一个计划，这样周而复始的迭代下去，我们就能不断地提高效率，更好地创造价值。
实际上，持续优化就是拥抱变化，不光是我们的国家要改革，企业自己也要持续改革才能生存。
要改进组织流程，首先要寻找改进的方向，个人认为，改进的目标在于提升效率并减少失误，工具的效率比人要高，自动化软件的可靠性比人要好，简洁明确的手册的传播性比人要好，如果一定要用人，抽象的角色比具体的个人要可靠（人会怠工跳槽，角色不会），所以，应该是自动化工具>工具 文档>文档>角色>个人，也就是说自动化工具效能最高，具体的个人处理效能最低。
以上下班打卡为例，全自动化的打卡系统基本是最可靠也最方便的，单一的打卡机就有信息难以备份和查询的问题，用签到本每人签字就不只是效率低下的问题，还需要有个专门的角色来进行监管了，如果这个监管角色是个明确的个人，有操作空间，那么整个打卡工作就算是千疮百孔了。
那么具体到上文提到的角色，我们主要从他们的输入输出来寻找改进方向。
产品经理：输入的有市场需求、竞品分析、公司战略等；输出的有产品设计、版本迭代计划等。
输入的市场需求等尽量有专门的角色来扮演客户，从市场部门/运营部门（高效的运营也需要产品的功能支持）向产品反馈需求，不一定必须由某人统一反馈需求，而是鼓励以更加流畅、更加规范、也更加重视的形式进行反馈。
输出的需求设计尽量文档化，最好工具化，可以操作的原型>文档>语言描述。
输出的版本迭代计划等尽量公开到固定区域，方便利益相关者提前准备好节奏，也有利于尽早发现问题。
项目经理：输入的有各项目的资源要求、时间节点、当前进度和面临问题等；输出有工期安排、风险处理、里程碑设计等。
输入尽量以直观的方式展示，例如用Scrum看板和燃尽图等形式，直观展示当前工作任务和项目进度，有利于统一团队目标，在尽量短的周期内发现和解决问题。
输出也尽量采用直观的方式，把待完成任务、已排出任务、已完成任务等直观展示出来，把距离下个里程碑的剩余时间和面临的问题展示给整个团队，推动项目前进。
设计：输入有业务需求和视觉效果要求等；输出有产品效果图和UI切图、UI交互方式等。
输入里包括产品经理输出的需求设计，也包括其他角色乃至公司管理层给的意见建议，如前所述，这些尽量文档化，即便是简单的文字记录也有利于梳理产品定位。
输出的UI切图是供给研发使用，应尽量贴合产品的需要，如标注布局尺寸、切成9patch格式、png格式、缩小体积等，这些尽量用工具（如APP设计神器Sketch）自动实现。
研发：输入的有需求设计、美工设计、待解决缺陷等；输出有软件产品和代码文档等。
输入里包括产品经理输出的需求设计、也包括设计输出的配色、布局、交互和图标等文件。
输出的软件产品要按照产品经理规划的迭代计划提供相对应的功能，研发在一定程度上要像产品经理一样深刻地理解最小可用产品、非过度设计等概念，所以在输出上鼓励有懂业务的角色（产品经理）和懂代码的角色（研发同事）对产品和代码做检查和评价。
研发应当尽量输出规范的代码，并编写对应的代码文档。输出规范的代码及代码文档是有很多好处的，一般认为规范的代码能降低至少20%的缺陷率，而且也有利于团队合作开发时其他同事对代码的理解和复用；而代码文档特别是对代码逻辑的描述，能在一段时间以后极大地帮助研发回忆和梳理代码逻辑（没有人能记住自己一个月前写的代码）。
另外，研发还可以输出一些通用的代码库，通过复用来提升效率。
测试：输入的有产品原型、软件产品等；输出有缺陷描述及测试报告等。
向测试输入产品原型，是因为在产品研发上，越早发现缺陷越节省修复成本，所以应尽早进行测试，对产品原型也可以测试。
向测试输入的软件产品，最好与产品迭代的节奏保持一致，尽量留出足够的时间完成测试，测试人员也应该尽量依靠自动化工具去覆盖大部分测试项目。
输出缺陷描述其实是个沟通效率的问题，一般做法是直接通过自动化软件（如Jira）向研发反馈，双方直接沟通细节就能很好地提高效率，从组织上和业务上还可以进一步明确业务边界，明确哪些缺陷属于哪些责任人，这就能进一步提高沟通效率。
运营：输入的是软件产品和运营工具；输出的有运营数据和意见建议。
输入的软件产品一般是定期迭代的，所以相应的角色应该是产品经理，最好由产品经理提供产品，再用某种自动化工具去实施和监控对产品的推广。
输入的运营工具一般会逐渐丰富，应当有个统一的自动化平台，根据运营遇到的提供工具；至少应该有个持续更新的文档，作为运营QA库，指导运营如何选择工具；运营每次遇到问题都直接找到研发寻求帮助是比较低效的做法。
运营输出的意见建议是非常有利于提升产品价值的，即使是对运营工具的意见建议也有利于发挥产品价值，所以对应的角色也应当是最了解产品的产品经理，产品经理也应该有监控运维意识，并在产品设计规划上有所体现。
企业的目标在于获取长期利润，而不是完美的管理。
著名的敏捷宣言是这么说的：
1.个体和互动高于流程和工具。
2.工作的软件高于详尽的文档。
3.客户合作高于合作谈判。
4.响应变化高于遵循计划。
所以，优化组织流程的目的，不在于找一个完美的管理模式，而在于解决实际问题，如果一个流程能解决问题，就采用这个流程；如果不能解决问题，完全可以打破所谓流程，保持适度的混乱，以高效解决问题为目标。
我们并非要求严格按照流程和文档做事，我们只是把流程和文档作为工具，使工作更加高效和舒适的工具，如果流程和文档有利于工作，就采用；如果不利于工作，我们鼓励直接的沟通。
我们优化组织流程的目标，在于更好的为企业提供价值，所有的分工协作和环节步骤，都不能忘记统一团队成员的认识，建立共同的目标，明确努力的方向，并让所有人（包括企业）从中受益。
我们的目标也不是建立一个完美的组织流程，世上不存在完美的组织，最好的做法是马上从能做的事情开始做起，通过不断迭代优化，在时间维度上持续调整为更高效的组织流程。
每个架构师都应该研究下康威定律
微服务架构的理论基础 - 康威定律
Scrum敏捷开发实践
质量管理经典理论｜PACD戴明环
本文转自：简书
联系客服
