管理思路 about how-to-manage HOT 26 OPEN

2、代码修改以后，所有的依赖进行确认。比如，axios拦截器修改了以后，所有使用axios后接的 then 和 catch 都需要修改。

from how-to-manage.

3、需求文档上的内容，包括前端页面展示，后台接口返回信息，在需求文档上，都应该明确。不然开发和测试都不知道什么是正确的行为，根本走不下去。

from how-to-manage.

4、开发之前，定死测试环境！提测之前，定死上线环境！

from how-to-manage.

5、需要以项目或任务为单位，将所有涉及到的人都组织起来。遇到的问题是：上线过程中，后端上周部署好了API，需要运维做端口跳转，到了下周，运维已经忘记了。前端告诉运维要做，运维已经不知道后端的地址了。然后重新挨个找人问。也许用jira的方式管控会更好，或者还有更好的流程管控的方式。需要研究一下，不然效率太低了。

from how-to-manage.

6、利益相关方评价法。绩效考评的方式，比如说，开发应该要严格按照分支管理的方案，进行开发工作。如果测试A在测开发B提测的分支，A已经全部测试完毕，然后B在测的差不多的时候，且！所有bug均已修复。此时，开发B再去改被测分支代码的话，是要严格禁止的。这样会导致测试很迷惑，到底算不算通过，能不能写测试报告。

如果做评价呢？就是这样的利益相关评价。测试可以评价开发是否按照分支管理的方案做开发。不符合的话，直接低评价，扣工资！

类似的情况还有：开发完全按照要求做开发，但是测试没有测出问题，这是测试的责任。利益影响方为业务部门。业务部门直接可以低评价测试！

业务提出的需求，是否足够清楚，如果不清楚，导致开发重复修改，开发可以直接给业务低评价！

你一定以为，做这么负面的操作，都没什么人会做吧？！
NO！低评价扣掉的钱，直接打给利益相关方！
打50%。剩下的50%留着。如果再被低评价，这次的 50% 被扣掉。下一次再留 50% 。

from how-to-manage.

接上条：为了防止负面活动不积极，每周会主动推送询问。问你，给这个人的评价怎么样，有没有不符合条件的操作。要不要给低评价。
然后！由直属上级督导，该给低评价，而没有给的话，这个员工将被上级低评价。

from how-to-manage.

7、绩效考评人明晰！每个人都需要知道自己的绩效考评人是谁。登录工资查询系统的时候，把绩效考评人高亮展示出来。不然都不听领导说的话，管理起来很麻烦。

from how-to-manage.

8、为什么要走流程？！
1）因为流程让员工舒服！
2）因为流程让工作可视化

流程如何让员工的工作更加舒服？如果员工的工作不是来源于流程的话，那一定是来源于个人。个人受到情绪、场景、面子、经验等主观因素的影响，很容易在非冷静的情况下，做出不合适的操作。
走流程的话，能够让情绪平静下来，能够让所有工作有据可查。

什么是有据可查？流程中牵涉到的，无非就每个人的工作。流程出来以后，员工就需要根据流程，去做这做那。高效的企业，不能够让被动工作不被看到。工作量一定要量化，让人看得清清楚楚，真真切切。这样做可以避免一大问题：我做了很多很多，但是却不被人看到，太委屈。

借用张文宏的话：不能欺负老实人！！！！！

from how-to-manage.

9、客服意见权重最大的值，要放在服务全生命周期结束以后。
至少可以给 51% 。
因为整个服务生命周期结束以后，客户不会因为担心客服不帮忙处理问题，而束手束脚，不敢差评。
只有在这个节点客户的评价才是全面的，也是最真实的。

此处需要给客户实质性补偿。差评越多，补偿越高。补偿从差评涉及人员的绩效中进行扣除。

比如公寓退房以后，进行满意度评价。全开放式，客户想说什么就说什么。这就可以保证，在服务的尾声，质量也有所保证，而且是强保证！

10、当然，面对无赖客户，也要给与员工合理的申诉权。只要员工有理有据，可以免于处罚。在数据中，将无赖客户标记出来。

from how-to-manage.

11、做决定的时候，要**。众口难调是很普遍的情况。如果是一言堂的话，可能当前任务的效率看起来会高一些，但是会导致决定的片面，错误率升高，导致组织的整体走向不稳定，如果是复杂任务进行返工的话，大范围的效率反而更低。而且如果员工在不认可这个决定的情况下，去执行，会影响工作氛围，降低工作效率。

from how-to-manage.

12、哎这糟心事的涉事人就不提了。取证这一块，很有意思。如果发生了事故的话，就应该像发生了交通事故一样，保护现场，并且进行现场取证。然后根据取证，来做责任认定。

from how-to-manage.

13、如果你不给人家加薪，就不要给人家升职。咱丢不起这个脸。

from how-to-manage.

14、
KPI必须要落实：
主张团队精神：
一荣俱荣，一损俱损。
主张个人因素：
责任落实到位，任何问题必须影响KPI。

15、KPI必须影响收入，收入中受KPI的影响，必须清晰可见！

from how-to-manage.

16、响应时间纳入KPI。在工作当中，发现国人，特别是外包人员，在工作沟通当中，回复非常被动。比如A负责的工作，C因为不清楚状况，在群里问了B，问题很明确是指向A的，A也不会及时回复。所以，响应时间需要添加到KPI当中。全年通过响应次数，响应时间长短，响应时为工作时间还是非工作时间的方式，统一来做评估。季度末进行评奖。

from how-to-manage.

17、国企交接是最致命的。新来的人不会去找要走的人去做交接。而是找自己最熟悉的人去问，这个人可能和他交接的工作完全没关系。。。要走的人也是两手一摊，没事人一样。
交接工作非常重要，最好能够做到一事N人（N≥2），如果做不到的话，即便是一个星期，也都要交接的人把手上的事情通通放下，全力交接。
做交接停工。手上的活全部停止，专注于交接工作。
所有与离职人员，有业务沟通的，全员做交接配合。
公司全体群发邮件，确认平时工作相关的内容。

如果离职人员与你工作上有交集，但是你没有让接手同时了解清楚状况的话，
交集人员负全责。

from how-to-manage.

18、赏罚一定一定要分明。你一会儿要罚，一会儿又要说，之后给你评级打高点，把钱补回来。这TM就等于在说：你的绩效和实际情况无关，我想怎么评就怎么评。整个管理变成了一言堂。还有什么公正可言。只要可以取悦评价人，不干活也能拿高评级。
此言一出，管理已费！

from how-to-manage.

19、ok 非常好，真的非常好。突然被祥哥点醒，如何才能评估程序员的工作量，难易度？
我的想法是：类似于业务的做单量，这个操作，

方案：需求完成时间，由需求提出方（通常指的业务，但实践中，也有很多非业务人员提出需求）确定需要需求完成的时间，这肯定是需求方的理想时间。但是提出归提出，能不能在需求方的理想时间内完成，需要结合实际情况来判断。如何情况来判断呢？

1、对于需求提出方来说，有固定的接收需求的人员，比如特定项目组。
2、项目组对需求进行评估，如果能够在需求提出方设定的理想时间内，完成的，则顺利进行。
3、如果需求出现难度，无法在设定的时间完成的话，就提出 绊脚石 需求。可选地给出：
1、难度评分（如果无法估计，就填写无法估计）
2、需求可能完成时间（如果需求可能完成时间无法估计，就填写无法估计）
有的需求，比如我的规则流，确实很难，需求完成时间确实无法估计，那就填写无法估计，没有问题。
4、会给同level的所有同事进行群发邮件，告知有这样的事件。也可以有页面去列出所有 绊脚石 任务。所有群发的邮件中，存在一半的人数，随机选出，必须进行评估。超过1个工作日，没有人可以给出可行性方案，就升级事件到上层。以此类推。
5、收到事件的同事，根据自己的实际情况，进行评估。难度评分可以按照其他人的评分去打。在所有评分打完以后，所有人都没有主动接手的话，会交给评分最低的同事执行。
6、如果觉得这个问题，自己能够在理想期限内，实现解决方案，可以接收，并反转任务。这个操作方式，不但展示了技术，又保证了需求，我认为这个评分应该是最高的。
7、如果不能在理想时间内，完成任务。也可以接收任务，并给出自己能够给出的时间点和方案。这个评分保证了任务的非及时完成。但是，这也要看任务的难易程度，不能简单地比6的方式低。可能任务就是很难，而需求方给的理想时间又太短。
8、如果有多人主动申请任务，可以任由各自发挥。在完成以后，发起需求评审和代码评审。研究一下，是不是可以集二者之长。关于这一点，我非常喜欢。这种对于技术上，当仁不让，互相切磋，取长补短的精神。我要鼓励，必须鼓励。

缺点：
1、对于产品经理或需求方的要求较高，需要能够不管和任何对接人，都能够清楚表达需求。
2、对于audit要求较高，因为同一个项目，会有很多不同的人来进行操作。任务的 scope 如何正确表达，才能够让接手的程序员，在完成任务的同时，把风险限制在可控的范围呢？比如，申请文件权限。B来做A一直在经手的项目，如果B只是做增量的话，个别文件还是可以的。如果要对存量文件进行修改，则需要申请存量修改权限，由A进行授权。并且由A通知测试，旧有需求重复验证点。在B完成任务后，需要由A进行review。保证高难项目完成的同时，旧有项目的改动不会太大。

优点：
1、B在做A一直经手的项目的时候，一定会去阅读A的代码，这样，就起到了 code review 的目的。一旦A离职了，B也能够以一定的熟悉程度来接手A的项目。
2、B在做A的项目代码的时候，因为有权限问题，不能大改A的代码。但是如果看到有问题，或者有可以改进的地方的时候，可以提出完善请求。只要请求合理，一样可以作为业务需求方，提出需求。分配任务，并实现验收。只不过此时，验收时间是由程序员B来定的。感觉这个时候，时间应该就能制定地比较准确了。
3、上级必须要能够完成下级无法解决的问题，只有这样才能够服众。这就解决了上级不作为，或者上级做了，但是下级看不到的问题。在管理上，更有说服性，更有依据性。
4、这个任务，最大程度地解决三大管理上的问题：1、无法充分发挥现有战斗力。2、任务分配不均。3、
5、从指标来判断的话，绊脚石的数量能够判断程序员是否缺人。从而判断是否需要招人。
6、利于宣传企业文化，让所有人都能够清楚，我们公司更倡导什么操作。更倡导精益求精的工匠精神，而不是简单地完成需求那么简单。优秀的代码，经过多人的打磨，互相的评审，各抒己见，结合场景。必定会形成非常优秀的技术风范。

from how-to-manage.

20、公平邮箱！对所有部门进行随机排序。每周强制公司最年轻，或者入司时间最短的人，填写公平邮箱。为了获取公平，你说，你说，你说说说！邮箱默认匿名，可以主动实名。并且C级别人物，可以自主触发公平邮箱填写。C级别自定义规则。此乃HR一大指标。这个操作必须操作好。公平是我们公司最渴求的东西。

from how-to-manage.

21、开发过程中，发现存在懒开发的情况。比如，后台随便写了一个能调通的API，就完事了。具体返回的内容逻辑是否正确、格式是否正确、内容是否可用，是否符合前端需求，通通都不做考虑。等着前端和后端进行联调。由前端作为后台的测试，这对于前端的开发体验非常糟糕。同样的，前端也存在，做了一个基本显示功能后，就什么都不管了。由后端进行点击测试。后端发现问题后，再反馈给前端。

这些都是懒开发造成的。

所以，需要提出一个制度，来限制懒开发。提前思考，提前沟通，提前做好自己的本职工作，多为对方思考，这样的合作体验才能让开发的工作更加舒适。

前端和后端，发现对方的问题后，都可以提出jira任务，或者其它方式，实现工作评估和绩效考核的限制性操作。逼迫事先为对方考虑。同时，提出任务，也可以作为提出者的绩效。发现问题总比隐匿问题要好。也应当作为绩效考量。当然，如果提出的问题确实不用解决，那就不去解决了。这一块由大家（包括测试）一起评估。

from how-to-manage.

22、冤有头，债有主。不是某人的锅，坚决不让他背。不然背锅的人太委屈了。如果现有员工没有一个人对此事负责，那就是管理者的责任！

from how-to-manage.

23（技术管理）、联通测试！每次对于现有的接口，被调方对代码的改动，都会让调用方一头雾水，并且莫名报错。如果被调方每次修改代码，都预估到所有可能的影响，并认识到所有调用方有哪些，一一通知到位还好。如果被调方无法充分预估可能影响，复杂系统情况下，就会存在很多不确定性。
严重影响团队和谐！

引入 https://json-schema.org/
可以对被调方，比如前端可以对后端返回的 json 进行校验。

一个项目，比如有版本 1.0 和 版本 2.0 ，
2.0的任务完成，必须是基于 1.0 项目中，前端给后端写的联通测试通过以后，才算完成。

除非你提前和调用方知会一声，说哪个现有接口发生了修改，请调用方修改连通性测试代码。

否则，连通性测试凡是失败，都扣绩效。

具体实现可以看这里：
https://json-schema.org/implementations.html

或者看一下 vscode 是怎么实现的。

from how-to-manage.

24、在团队当中说话，一定要服众。你可以有独到的观点，但是一定有理由能够说服人。
如果连你自己都觉得这话说出去不靠谱，那就别说了。
记一次因为自己的小私心，给出超长排期被怼的惨痛教训。

from how-to-manage.

25、和后端小哥的聊天当中，给了我一点启示。一个任务或一个项目，会分前端和后端。往往会变成，前后端相互撕扯。
如何解决这个问题？
小哥给了我一个启示：哪边 loading重、难度大、更关键，就偏向于哪边。
我大概列一下判别方式，不过这一块还需要逐步完善。
1、列出两边的实现方式，哪个实现方式更简单，就用哪个。
2、如果迭代方式一样，比如说：对一个大对象做递归，前端和后端的代码逻辑是一样的。那么来判断执行次数。执行次数少的来做。比如说，前端每次打开浏览器都要计算一次，但是如果这个东西在后端的话，只要每次修改的时候计算一次。那么就放在后端。
3、如果计算次数雷同或无法基于现有条件进行判断，看运算的复杂度。复杂的话，放在前端，理由是减少服务器的负载。毕竟，如果都在浏览器上计算的话，就类似于是分布式计算了。
4、判断剩余任务和排班周期。如果前端还剩很多任务没有做，由后端接。
5、如果后端还有很多没有做，则由前端接。如果剩余的任务还是差不多，则看前端和后端，分别有什么后续任务。如果已经安排了任务，且已经可以着手处理，则由另一方进行处理。

但是！！！处理完了绝对不是就完了的！！！
前端和后端，每次接受争议任务，都已经绩效。而且是逐层向上影响！！！
事情就会发展成，前端架构和后端架构的问题了。

前端架构师发现绩效少了，就会去研判是不是推给后端的事情太多了。
后端架构师发现绩效少了，同样也会做相应的处理，并对下属进行宣导。

如此一来，大环境的问题，就相对可以缓解了。

from how-to-manage.

26、整体技术端的管理，把任务进行拆解。
拆到轮子上。
帮帮帮地给我打轮毂。

整体需求向下打，打到轮子团队。
然后由轮子团队向上反馈需求实现方案。

一旦有需求是无法实现的，
就帮帮帮地改轮子。

整体能够看到的局面就是，一个项目有很大概率会涉及到整个公司的所有技术团队。

继而导致你的轮子越打磨，越精细。
一个需求下来，可能是几百个组件出实施方案，完全可以去复制粘贴文档。

组件负责人和组件负责人可以继续往上，形成二级组件团队。
二级组件又可以再和其它组件结合，形成三级组件团队。

在我这边看来，负责人并不是说职位高，职级高。
因为越往上，可能越简单。

产品、需求，直接根据组件方案，就可以出产品。

其职级的高低，应当由需求实现次数、需求实现的工作量、版本的迭代、技术方案的提升，代码的抽象和缩减，进行综合评定。
原则：活不但干得多，更要干的精，精是重点。

from how-to-manage.

27、除了组件级别的组织以外，还有代码逻辑的复用。
有一段代码逻辑，想要判断是否已有，可以复用。
在大平台上直接提出。
所有人可以评审代码，也可以给出方案。

产品和需求分开。
产品归产品，需求归需求。

需求需要对整个公司可复用性非常熟悉和了解。

产品可以天马行空，任意设计。
需求不能提出任何反对意见。
仅仅是进行需求拆解，并寻找复用。

每次需求完成之后，需求都应该进行总结。
以至于说，到需求方出完需求以后，其实代码原型就已经有了。
而且应该是可以跑，可以运行的了。

from how-to-manage.

28、产品需要完全靠自己去想，自己想要的是一个什么样的产品。你来说服我，你需要什么样的资源。
自己没有 idea，想要仿造别人的产品？
完全可以！
别人的产品都是垃圾，想要仿造自己的产品？
完全可以！
没东西可以造了，自己拍脑袋了！
完全可以！

但是，你要让认同你，更要所有同事认同你。

另外，要说的一件事是，我们公司没有产品。每个人都是产品。

只要你想做一件事情，不管和什么有关。尽管提。

产品需要组织自己的需求分析部门，实际上，在理想状态下，有了需求部门，产品就已经出来了。

from how-to-manage.