标签：比较 笑话 简单的 项目管理 培训 bug 选择 沟通 逻辑
对于很多人来说，技术管理是一件非常头疼、痛苦的事情。技术团队从开始搭建时，往往会发生自己想留的人留不住，不想的留的人一直在的情况。有一句话叫“铁打的营盘流水的兵”，如果说自己能有一个骨干团队，那么它就是我们铁打的营盘。而非骨干边缘正常流动，实际上对于企业和团队来说，是一件好事情，因为它能给团队补充新鲜的血液。
比如一个技术团队大概有 100 人左右。由于公司业务流程比较长，我们按照语言分为多个团队，有 Java、APP、PHP 等，包括还有单独的测试部、项目管理部。还有一些支撑部门，如技术委员会、DBA、配置经理、质量经理、运维部。同时，我们选择了矩阵式管理作为公司的组织架构形式。
这个架构看上去比较理想，但实际上有一个最大的问题是，这一套东西完全不落地，最终导致发生了以下几个情况：
1. 项目经理、开发经理和产品经理没有有效配合。在与员工沟通时，大家通常会有很多抱怨，如需求变化太频繁，上线失败率很高，人员流失严重等；
2. 遇到问题，开发人员不知道找谁协调。矩阵式的管理会导致多头管理，如果出现问题，应该找主管领导或项目经理？还是找产品经理？大家都非常迷茫。
那么该如何解决这些问题呢？当时我想到的第一个解决办法是，做大量一对一的沟通，包括走动式管理，详细了解跨部门之间情况。通过这样的方式，我得到了一些反馈：
1. 由于需求变化很频繁，东西刚做出来，需求就变了，导致技术人员不能明确阶段性目标是什么；
2. 不够了解技术团队的痛点和诉求。
如果我想要满足团队的需求，我们一定要建立核心的骨干团队。让核心骨干团队成为中坚力量，带动整个团队。
首先，我们需要给团队信心，告诉大家，我们在技术团队里做什么样的事情是正确的，能得到大家的认可。
1. 技术为本
我们既然是一个技术团队，那么一定要技术实力过硬，无论是一线团队，还是管理者。
2. 沟通能力
作为一个技术负责人，我们需要与业务部门沟通，与市场执行讲”人话“。讲“人话”指的是，把技术性的数据转变为非技术人能听懂的话。
3. 人品
我们需要有一个理念，无论是在任何场合，我们都需要明白平等、尊重、沟通、互动的重要性。
招聘无非有三个渠道，对外招聘、内部提拔和淘汰，那么我们该如何让招聘变得更高效呢？
1. 会问问题，具有打破砂锅问到底的精神
通过学会问更好、更多的问题，挖掘面试者的潜力，考察他的技术深度。
2. 考察三观
在团队里肯定要面对自己的同事、下属和领导。即使招聘的是一位普通开发人员，我们都应该问他三个问题：
1. 你喜欢什么样的领导？
2. 如果你是领导，你喜欢什么样的下属？
3. 你喜欢什么样的同事？
这三个问题能让我们大致了解他是如何理解团队协作，和我们所提倡的理念是不是一致的，三观一致更有利于大家之间的合作。
3. 人员优化要果断
我认为，人员的优化一定要非常果断，尤其是你刚接触一个新的团队。
因为从优化的角度来说，特别是针对管理层而言，我们肯定要看结果的，职场稍微残酷一点，对于团队来说是一件好事情。
4. 提拔和培养
除了组织架构里面的经理层管岗位，我觉得小组作战也是非常重要的。我们在公司里会成立多个 4-5 人的小团队，其中会指派一位小组负责人，他可能技术能力比较强，同时也比较负责任。通过这样的形式，相当于把比较大的部门逐渐拆分成各个小组作战，我们遇到的问题时，也会比较机动灵活。
另外，我们无论是作为经理，还是小组负责人，不管负责的人数是多少，都要善于问下属问题。比如在分配任务时，问某位开发同学是否清楚自己所做的内容是什么，技术方案该如何落地，什么时候能完成等，这些都是很关键的问题。
1. 需求变化过于频繁
我们曾经发生过这样一件事情，某个规则在一个月内变化了 5 次，APP 里的页面改了 7 版，这完全是一个失控的状态。由于当时的项目经理比较弱势，在面对强势的业务部门频繁提出需求变更时，没有做到控制。我们要快速响应合理的需求，对不合理的需求应该加以管控。
很多时候，我们都希望软件工程师不仅有阶段性成果，而且能够快速响应业务部门需求时，那么该如何处理呢？我们设置了一套解决办法：
1、常规需求：每两周做一次上线；
2、紧急需求：立即响应；
3、线上 BUG：第一时间解决。
通过这 3 种不同的处理方式，既能缓解需求，又能把需求进行了分类。除此之外，我们需要告诉项目经理，在对外时一定要做好沟通，如果沟通中出现问题，那么会导致项目很难落地实施。
技术对业务部门一定要讲“人话”，这是一个很实际的关键点。
2. 开发流程不落地，流于形式
我们公司开发流程好像没问题，部门也比较健全，为什么还会出现这么多问题呢？那是因为开发流程不落地。
开发流程上，无论是做敏捷，还是做迭代，我认为最关键的是分工一定要清晰。
其次，大家在合作的过程中，不能出现甩锅的情况。比如，PMO 需要及时管理和接受需求；技术总工需要确保整个技术方案；开发人员的功能性 BUG 一定为 0，保证代码一定要通过。
在解决了技术团队常抱怨的两个问题后，我们团队从原来的上线成笑话，到现在我们每次上线，基本 2 小时内都可以完成。
很多技术工程师都不太明白，绩效考核到底是什么。对于我来说，绩效考核可能是一把双刃剑，如果做得不好，它将会扼杀很多技术工程师的创造性。那么我们该如何做绩效考核呢？
我觉得，关键是需要有一些理念进行支撑，让大家明确绩效考核的目的。我们不是为了把做得好的骨干团队绩效打低，而是甄别出其中还需要改进的同学，让他们知道自身有哪些方面做的不足。具体我们可以通过两方面让他们了解：
1. 数据说话
我们现在每周都会做一个次数据统计，通过具体数据给大家一个相对公平的绩效考核，比如：
计算实际工时，假设这个任务要求 8 小时完成，可你只花了 6 个小时就完成，那么你的绩效肯定高。
任务数，做了多少任务，出现了多少 BUG，在测试阶段出现的 BUG 数量。
2.OWNER
我们曾经发生过一件事情，某个应用需要搭预上线环境时，由于搭建环境过程相对比较复杂，中间出现了很多问题，导致测试和运维吵得不可开交。
其实这件事很容易解决，运维负责预算环境，测试作为使用者，在搭建预算性环境中，你可能需要研发，那么就自己去找人。如果在找各个部门协调的过程中，得不到配合，你可以找相应的负责人，让他去进行协调。如果负责人把整件事情捋顺了，那么就不能再找任何借口说，这个事情因为某个原因导致最后没有做成。
在团队落地的过程中，我会要求大家持续改进研发文化，希望能帮助大家每天进步一点点，那么具体该如何做呢？
1. 经常做复盘
每次项目做完后，我们通常会花一个小时左右的时间做复盘。把项目过程中所遇到的问题列出来，并说明为什么不该出现问题的原因，最后指定到相应的人进行整改。
2. 述职
在试用期结束后，需要写一份转正报告，那么报告中具体需要体现哪些内容呢？
1. 总结试用期期间你做了哪些事情，形成了什么样的成果；
2. 分析自己做得不足的地方；
3. 下一个阶段的计划。
述职会参与人可能是同事，以及相关的领导。你可以在述职过程中做一些自我否定，因为一个人只有在自我否定后，别人才敢给你提意见。我们希望通过这样的方式，让大家在工作中沟通不再有隔阂。
不少程序员可能对新技术、新工具会比较感兴趣，但时间长后，由于业务逻辑十分乏味，不少人失去了原本工作的激情，这时候该如何处理呢？
朱彬：通常大家都喜欢做一些有挑战性的事情。所以面对这个问题时，应该给开发人员一些正向的引导，让这个事情变得更有趣一些。
举个例子，最近我们正在做组织架构调整。首先，我们取消了配置经理的职务，把原本无聊的工作通过工具去完成。其次，事情完成后需要进行跟踪，这是关键的一步。在过程中我们如果发现代码不提交，其中肯定是有原因的。我们需要发现原因、跟踪原因，并及时改正。这个事情做起来会相对比较有意思。
当下我们也会出现类似的情况，很多程序员写了大量的业务代码，导致工作热情极度下降。因此，我们采取了相应的措施，如定期组织培训。我们要求所有的技术经理，每个月至少要做一次有深度的技术培训，主要围绕 3 点：
1、引导大家让事情做得更有趣，简单的事情深入去做，这个过程会让它变得更有意思；
2、让工程师选择自身的技术栈；
3、组织一些技术分享活动，让大家觉得在这里还能有一定程度的成长。
目前，我所在的公司想通过日报、周报的形式加强与员工的互动。想请问一下，盖闻是否也有日报、周报制度？日报、周报制度对于技术性公司是否合适？有没有存在的必要呢？
朱彬：我觉得日报、周报制度得从不同层面上来看。
对于一线开发员工来说，开发人员的精力不是去做日报和周报，而是集中做技术，从项目中就可以体现出他们所做的事情。而日报、周报制度更适合于管理岗，尤其是项目经理。
我的管理方式更倾向于走动式管理，可以更直接的处理员工的工作问题，及时了解员工的工作状态。
我想最重要的应该是计划，特别是月度计划和周计划。因为它们，你自然而然就有了周报，周报的最终目的是为了帮助你做总结。
如果遇到一些比较听话的员工，但他的个人能力不足的话，有没有其他更有效的方式，能够帮助提高他们对项目的贡献？
朱彬：态度不错，能力较差，我们称之为小白兔员工，我认为他们并不是企业所需要的，但是一个企业不可能说没有这样的员工，这时候该怎么办呢？
我觉得，首先理念是很重要的，我们需要告诉大家做什么样的人是正确的。技术和能力是每个公司都需要的，如果你的技术能力不强，态度再好，都不能解决问题，你在整个部门里，排名一定是靠后的。所以需要帮助他们意识到，想要往上走，就要想尽一切办法提高自己。
那么该如何提高呢？
1、主动，要求组长安排任务时，多关注他们；
2、给予一定的空间和压力，一定要有压力，如果没有压力就没有动力；
3、通过培训给予机会，这种机会可能不是很多，因为企业想要生存，肯定是需要有能力的人。
转自：https://infoq.cn/article/2kJpJl8*CPK3UZXHm2By
标签：比较 笑话 简单的 项目管理 培训 bug 选择 沟通 逻辑
原文地址：https://www.cnblogs.com/laoxia/p/10172455.html
