在软件开发行业中，要成为成功的程序员需要更多的技能和能力。比如向上管理、处理和同事们的关系、处理和外部组的关系，向上管理是指在组织中不仅仅专注于自己的工作，还能积极主动地与上级、同事以及其他相关团队合作，从而实现卓越的工作成果和职业发展

你不必喜欢、崇拜或憎恨你的老板，你必须管理他，让他为你的成效、成果和成功提供资源。这种积极的做法，就叫作“向上管理”（Managing Up）” — 彼得·德鲁克

下面是我工作过程中，总结的一些注意事项：

技术上推荐这么做

1，每天带电脑回家，方便处理线上问题

2，对上级准确汇报自己的工作状态，尤其时上级想要推进的那些。比如上级想推进某个预案，关于这个预案，上线之后完全可以做成文档，然后用单实例测试，测完告知上级。如果在一些对于跨部门合作比较多的公司，你需要更加频繁的向上级汇报进展

如果等到老板主动来问你的时候，已经释放了一个危险的信号，即，他已经开始跟你要结果了，在这种被动前提下，你做的事情就很难达到他的预期

3，写 bug 是一个很普遍的事情，但是要减少自己的出错概率。线上出现问题时，可以先告知组内同学。看问题大不大，优先止损，比如做一些回滚、扩容、摘流、关开关之类的操作。再进行问题排查

排查问题要有思路，不要慌不择路，排查完毕后可以详细的写一个排查问题文档，有些问题是你上线导致的，但是只要止损做的好，上级也会觉得你能干。更何况大多数问题上级根本不关心是谁写出来的，只关心最后解决问题的汇报人是谁

4，可以做的慢，但是需要做的准确。如果时间不够，记得及时提出，并且向上级申请增加人力资源

5，提出问题的同时，提出解决方案，可以给出多种方案，就算最后一个都不被采纳，也只是上级与你的意见相左，而不会让上级觉得你不行。在争论的过程中，可以提出自己观察到的细节点进行深入讨论，如果上级的方案最终可行，可以适当提供一些情绪价值。对了，你的方案和你对系统的考量其实一点都不重要，所以从一开始就不要抱着你的方案最终会上线的心情去争论

6，自己可以不拼，但是需要让上级看到你拼命，上下班时间间接的展示你是一个比较勤奋的人

7，关于创新和技术需求，则要求你对业务的精准体验和考虑，可以总结一些产品使用上你觉得不太好的点，起技术需求集中优化，这样不会让产品抢了你的功劳。关于创新点，则需要你具有产品思维，比如做个答疑机器人、做个链路迁移、做个监控大盘、做个系统优化，这些功能一定要有具体的数据支撑，方便你吹流弊

8，年终总结要给自己凭 A，并且尽可能详细的说明自己做的技术优化、技术细节、业务考量、收益增效等等，这是领导了解你的重要途径之一（如果是那种小作坊模式可以忽略这一点，因为上下级的交流没有 lag，你的技术水平会被同事完整的反映，但是如果是大公司，就要考量这一点了）

9，如果业务流程较长，需要画一个图来让他人知道流程，最好画三张图，流程图、时序图、状态流转图

10，站在领导的角度看问题，你大概可以从日常中看到，他是个什么样子的人（他可能希望项目进展顺利、希望锅不甩在自己身上等等），了解这些目标后，你的一些决策和行为大概率会符合他的要求了。反例是担心自己没有对应的能力，担心自己的能力在这个业务线留不下来

11，一些活执行的时候不要打折扣，如果没听清，可以让领导再重复一遍，或者自己复述一遍，再问：是这样吗

12，该说的，就要说；不该说的，绝不说，尤其是你还没搞清楚部门的工作方式之前。这也是我个人不太喜欢官场氛围的原因，有些部门就是以个人裙带利益为主，互相甩锅。你在入职一段时间后大概可以总结出可以说啥不能说啥，有些在前司合理的行为在新的部门会将锅带给你自己，这些就要注意一下，但是你要是干的不开心，建议尽早离职，毕竟身体健康最重要

13，对于一些明显有问题的抉择，给出合理分析建议，反馈给领导。这里有几个前提——与自己部门相关的，重要决策（小事就算了），明显有错（而不是你自己都拿不准的），满足这些条件，你可以冷静反馈自己的不同理解，但是不要去跟老板吵。你的责任就是给他清晰的分析，理性反馈。最终决策还是得交给他

14，做需求需要调研很多东西，梳理并且获取所有的依赖项，外部给的接口等内容，需要明确参数，避免需求做一半发现某个依赖项中的字段不能用的情况。同时一定需要问产品想实现成什么样子的

沟通能力

1，可以在群里和合作方聊技术实现、拉需求评审会以及拉排期会、解释这个会的目的、和某个单独的同学对排期与时间、在已经确认的情况下回复别人问题，作为 rdo 时，会议后的 todo、风险与解法。这样沟通更高效一些

2，及时拉齐沟通到的每件事情，是推进需求的好办法。及时周知每个人项目的最新进展

3，一些会议纪可以及时留痕，写到 ddp 的评论和技术方案中

4，内部团队先拉齐再给外部团队回话

5，十句话对不清就换沟通方式，比如语言说不清就开会议聊。协调各方时间时进展不顺利，或者某个问题没人回的话需要拉会讨论

不推荐这么做

1，注意不要让上级觉得你不靠谱，而最让上级觉得你不靠谱的事情就是，他给你派活了你到时间了说没有干完、有风险项不及时抛出或者他交给你的任务你做完了但是经常出 bug 2，不要觉得你的同事和上级的观点都是错的，也不要因为你的各种方案被否决了就放弃与同事沟通，一段良好的关系一定是要有充足的沟通和交流，而沟通一定是带着自己的观点的 3，不要把情绪带入工作，不要对任何同事生气，会让大家觉得你不成熟 4，没有被授权的事情不要做，永远记住你只承担流程里规定你必须负责的责任。不要帮别人推进一些事情，帮别人汇报问题。别人突然交给你的事情，如果没有详细的说明也尽量不要接手，大概率你会干出问题

当上级给你派活的时候

处理问题可以从以下几个方面考虑：

1，这个任务需要处理的根本问题是什么。比如我们其实需要解决 lag 的问题，但是你给出的方案是迁移到工作流，辛辛苦苦调用一堆工具，最后了解详情后发现，需要迁移的任务根本不重要，可以直接丢弃 2，目前自己手上的任务已经很多了，这个时候上级给你派活根本不必接！只要是诚恳的沟通，有理有据，凡是一个明理的上级肯定会接受的。甚至反而会对你的条理性、做事有主次印象深刻 3，可以做的慢，但是需要做的准确，活干完后需要汇报（我做了什么预案+做了什么测试）

减少写 bug 的概率

1，新增的功能，重视程度和影响面比较小，但是切记新增功能时，不要影响原来的功能，不要修改或者删除原来的数据 2，修改的功能，影响面比较大，可以从以下几个方面考虑：

• 改动时做一个放量开关，有问题直接切回去
• 修改时需要做好日志记录，确保自己插入 db 的数据或者修改的数据没问题
• 上线后，需要理清这个功能，数据到底怎么变化，才符合预期。并且验证，一定要验证，这一步不能省！做好日志、监控、告警，这一步一定不能省！
• 修改老代码时，走流程，找 qa

关于验证数据，下面三点应当至少做两点，一定不要怕麻烦怕累，很重要！

• 对比变更前后的关键指标监控（响应时间、错误率、打点数量等），评估变更的实际效果
• 对比多数据源（redis、日志、监控、db）中的数据，看看量级、数据是否一致，符合预期
• 修改时日志应当完善，便于发现问题

更棒的工作能力

1，配置监控报警的时候，看过去的数据，调整一个合理阈值 2，字段扩容的时候，看异常数据的大小，进行扩容 3，修复线上问题的时候，请根据影响面，再三验证 4，主动沟通问题，主动推进问题，完成后主动周知 5，危险值需要设置上限控制 6，业务上使用次数需要打点计时

技术深度积累

能不能跳出自己是一个程序员是一个被动执行人的角色，而是将自己当做产品当做技术负责人的心态去做这件事

1，从需求角度有没有思考产品设计当中的缺陷，能不能反向为产品设计提供建议 2，技术角度性能优化 3，技术扩展性，从点到面：单个问题如何处理，问题根因（5 why 了解最终根因），同类问题如何处理。如果是一个需求则要考虑需求实现，需求是否支持横向扩展 4，问题后续预防措施 5，数据驱动：用监控数据证明问题影响和优化效果（如错误率下降50%）