果见案例库
根据「管理全景图」汇总相关模块案例。
内容来自小酒馆、小茶馆、小咖馆和小饭馆内，群友们真诚热情的讨论。
案例详情
问题关于明年的部门规划，我的第一想法的规划是：产品组、前端组、UI组、开发组、测试组和运维组，在此基础上进行项目制管理。
这样的划分是否过时了。或者大家是否有更好的部门工作流程，给点建议。
为什么这么问呢？因为领导觉得测试和运维不需要，说运维让开发承担下。
我们是SaaS系统的开发，领导一直想跟一线城市的产品开发看齐，引进新的理念和管理思路。
群友互动1
Eagle那就对开发的要求特别特别高了。
群友互动2
Paullin看你规划的组不少，应该是中层管理者。也可以考虑下从业务目标出发，拆业务目标，再分解成产研对应要支撑的技术指标。这样大家往上就有一个共同的目标了。
你上面不是说要做规划嘛，我看你是按职能组来做的，建议在职能组之上，加一个大的整体业务目标，这个和人员配置没有关系。
人总要升级嘛，死守一块技能，迟早都要被淘汰的。
群友互动3
李德鹏那领导可能会觉得分的越细成本越高。
应该是开发在搞SRE吧，上云对研发要求比较高。
如果没有想清楚业务，没有和领导达成一致，最好不要乱动组织架构，还不如混沌状态。
群友互动4
天下布武开发人员数量能够满足产品的要求吗？
想把开发和产品分开的原因是什么？
群友互动5
麦田内部系统，确实可以不用运维，不然运维整天都没啥事的。我们本来有三个运维，上了自动化以后，全开掉了……
自动化是我们自己弄的，就是简单的CI/CD。我们来了以后，是优化了好多人，老员工说我们这样会把自己饭碗干没了……因为没啥问题，老板就觉得不需要你了。
是老员工说要弄点问题出来，让老板觉得开发很重要。然后发布也要故意到晚上很晚，然后第二天早上不来，这样考勤也很好看……
我们现在发布都白天发，准时下班，感觉快要被优化了……
之前都是手动打包，给运维发。说实在，我也不清楚之前运维具体在做什么，除了发布外
好像还搞过一个发布的平台，自己上传文件发布那种。还有搞个jumpserver啥的，反正都没用起来。
大家不觉得中小公司，运维都比较闲么？除了极少数有上进心的。我这说的实话。
群友互动6
大董代码权限，配合国家安全审查等，运维还是能出力的。
群友互动7
大刘哥真是应了那句话，太方便了反而丢了饭碗。不过可以在这个自动化上面再引进更高级的一些东西去做，避免这个情况出现。在智能范围之内引入别的东西，提升整体目标。
如果一觉得员工可以被替代就开除，那这样的老板，员工怎么去给他们拼命提升效率呢？
想起来阿里造中台和拆中台。
群友互动8
mondge是不是可以可以拆分为大前端，大后端，产品组，以内部成立虚拟小组的形式，一人多职（比如：核心开发承担一部分运维的工作）。
测试这块是可以看看对交付产品的质量要求，如果要求不高可以从流程制度上让rd保证研发质量，如果要求高的话，还是独立测试组或先放在大后端内部，后续演化。
控制运维，测试的人力后，工作都压在研发这了，对研发的素质要求会比较高。
还是需要结合明年规划的合理规划人力。建议先别谈分组的事情，先和领导聊聊明年对技术这边的期望，需要支持的业务，业务的规模，质量的要求等等，再做分组和人力的安排。
先调研，搞清楚业务规划，再论证技术的人力配备和规划。
群友互动9
达!如果项目小，没必要专门运维人员，所以会被优化。项目大而复杂，没有运维人员，那问题大了。
小公司没有运维。
群友互动10
hyx运维的工作：稳定，成本，效率，标准，协调。
人数少，项目小，是可以研发干运维的活的。简单的部署，上线，研发也够了。
群友互动11
达文无西运维的人是开了，但是运维的事儿还得有人来cover，研发的人顶起来？
那这是不是之前运维都干的是上线的事儿了？
部署和上线，研发可以完全搞定。
全景图分析诊断团队的组织架构是无法凭空想象的。也没有一定最好的组织架构，一定是管理者经过再三思考权衡后，最终选择此时最适合的组织结构。
如果有当前的组织架构是什么样子，会更便于了解「因为领导觉得测试和运维不需要，说运维让开发承担下」这个描述的背景。
应对思路管理规划
根据管理者的描述，相信管理者最终想要产出一个团队组织架构图（如下）。也就是有哪些业务划分、需要多少人等。
那么我们需要做好哪些工作，才能产出这么一份组织架构图，且说得清楚为何如此划分和需要的人力资源？
作为管理者我们需要非常清晰「管理规划四要素」。
职能：回答团队是干什么的。
目标：回答团队要产出什么。
团队：回答团队是什么状态及未来会是什么状态。
路径：回答所需要投入的资源及理由。
职能
团队职能有两个层次，即基本的职责和升华的使命。
首先案例中的管理者需要清楚，自己对部门内每个单独团队的期待是什么？持续存在下去，其独特价值是什么?我们最终会用什么维度来衡量团队价值的高低?
非常清晰肯定的回答以上问题，是这些团队存在与否的基础。
目标
设立这些团队后，我们希望这些团队在一段时间，比如三个月、半年、一年后，有哪些成果呢？
我们期待这些团队有哪些业务目标、团建目标、专业目标？
团队
此案例的核心重点来了，我们从哪些角度来做团队规划。
目标视角
团队都负责哪几块业务，每块业务配置了多少人力，以及这些人员如何分工，人力分布和业务目标是否匹配等。
如果分工体现了员工在业务上的分布，那么梯队就体现了员工在能力上的分布。
最后注意团队规模，要理清楚其中有多少人是现有的，有多少人是接下来要新增的。
资源视角
你对业务的理解，以及你希望达成的目标。需要投入的人力和目标是息息相关的，和手段的选择也是密切相关的，你的各项决策都影响着资源的估算。
可以参照行业资源配比情况。但仅仅是一个参考而已，更多还是要看这样的人员配比是否可以达成团队目标。
人才视角
到下一个时间节点，你需要重点培养出哪些人，给他们什么样的平台和空间，以及你有能力提供给他们什么指导和支持，期待他们能够胜任什么职能和角色。
更多完整内容可参考：管理规划手册，不仅适用于小团队的规划，也适用于查阅或帮助下级团队制定规划。
向上沟通
我们作为管理，而不是一个单纯的传话或者执行机器。或者说我们不想成为执行机器，那么沟通是必不可少的。
尤其是一个从上传达下来的信号或者指令，我们觉得困惑，需要各种脑补揣测的时候。
我们需要认识到作为管理者，勇敢的去向上沟通也是我们职责的一部分。我们要避免因为以下想法，而放弃沟通：
性格使然，和上级能不聊就不聊
拿捏不好该不该和上级聊的分寸和尺度
很难领会到上级的意图
无法影响上级的一些观点和决策
希望以下的一些建议可以帮助到有以上问题困扰的管理者。
厘清沟通目的：大多拿捏不好「该不该聊」这个问题的情况，都是由于还没有厘清自己想通过这次沟通拿到什么，即沟通的目的和初衷不清晰。
回放确认：如果不能确认上级意图，不如用一些「回放」的句式来确认，也是个好方法：「你是不是这个意思，……；你看我理解的是否准确，……」
输出影响：如果你要想有效地对上级实施影响和说服，你的影响力是至关重要的。
我们可以短期内做好的可以是，根据上级的风格去选取合适的沟通方式，根据上级的关切去选取合适的内容和呈现逻辑，并根据上级的状态去选取合适的沟通时机。
更多内容可查阅图书《知行：技术人的管理之路》。
期待你的案例分享！