=Start=
缘由：
整理一下前段时间看的《极客与团队》这本书。其中有很多地方对我还是很有启发的，首先是最基本的HRT（humility-谦虚、respect-尊重、trust-信任）原则；其次就是对事不对人、团队氛围的重要性和建立等技巧和方法。这种好书看一遍是肯定不够的，为了加深印象，所以看了之后在此先整理一遍，方便以后快速查阅和参考。
正文：
参考解答：
第一章 天才程序员的传说
- 没有人是完美的，但是在给同事挑错之前，你得先知道自己的毛病。
- 本章的主旨是要理解软件开发是集体项目（这一实际）。要在团队里获得成功，你必须以谦虚、尊重和信任为核心原则。
- 真正做出产品之前不愿分享好创意实际上是一场很大的赌博，你很容易在一开始就犯下很基本的错误，你有可能是在重新发明轮子。还有你完全丧失了合作的好处。
- 原则——“确保失败尽早发生，尽快发生，经常发生”
- 程序员是最需要不断反馈的：写一个新函数，编译，加了一个测试用例，再编译一下，又重构了一部分代码，再编译一下。这样就能在生成代码的时候尽快地改正笔误和 bug。
- 本质上，单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话，你更应该担心自己是不是在错误的方向上浪费了大量时间。
- 软件开发是集体项目。
- 一个人躲在自己小黑屋里抖聪明是没用的。光靠自己神神秘秘地搞创造发明是不可能改变世界，令千百万用户受益的。你需要合作，告诉别人你的想法，让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。
- 学习理解所谓的社交技巧“三支柱”。这三项原则不但是人际关系中的润滑剂，更是所有良性互动与合作的基本。
- 谦虚——没有人是宇宙中心。谁也不是万能的，谁都会犯错。你必须不断地提高自己。
- 尊重——你必须真心实意地关心同事。他们都是活生生的人，他们的能力和成绩都需要得到肯定。
- 信任——要相信别人的能力和判断力，在适当的时候懂得放权。
- 不要低估社交的力量。社交不是勾心斗角，或是操纵别人，它是通过建立起人与人之间的关系来把事情做成功，而且这种关系延续的时间肯定比项目本身更长。
- 自负这个东西有很多种解释，就看你怎么理解，但很多时候它都会妨碍你的工作，让你进步缓慢。
- 所以学着尊重对方，礼貌地给出建设性批评吧。如果你真的尊重一个人，那你就会自发地选择有技巧有帮助的措辞——这种技巧需要很多练习才能学会。
- 你的自尊和你的代码不应该有什么联系。换句话说，你和你写的代码是两回事。你应该不断地告诫自己，你和你写的代码是两回事。不但你自己要相信这个观点，还要让你的同事也认同它。
- 我们俩都在Google工作，而我们最喜欢的Google的格言之一就是“失败是可以接受的”。广泛的认识是如果没有经历过失败的话，就说明你的创新还不够，或者你承担的风险还太小。失败是更上一层楼的绝佳机会。
- 从错误中学习的诀窍是要记住自己摔倒的地方，按商业用语来说就是“事后检讨”。但是要特别小心，千万不能把事后检讨的文件变成一堆无用的道歉和借口——这不是它的目的。真正的事后检讨应该包含有关“学到了什么”以及“怎么改正”等经验教训的详细注解。然后要保证把它放在一个随手可及的地方，并且认认真真地按照上面所写来实施改进。记住，正确地记录错误还能让其他人（不管现在还是将来）方便地了解事情的原委，以避免重复历史。
- 一份出色的事后检讨应该包含以下内容：
- 简要
- 事件的时间线，从发现到调查，再到最终结果
- 事件发生的主因
- 影响和损失评估
- 立即修正问题的步骤
- 防止事件再次发生的步骤
- 得到的教训
- 偶尔应该跳出自己的舒适区，在更大的舞台上接受各种挑战。这样你才能长久地保持愉快的心情。
- 你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮。
- 记住这一点：接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了，要别人听你说话，首先是要学会当一个听众。
- 重要的改变要由自己做起，然后慢慢影响其他人。
第二章 培养出色的团队文化
- 要是团队不在意自身的团队文化，那么不仅构建强烈的团队认同感以及对自身工作的骄傲感会变得十分困难，而且会很容易受新人影响而引入糟粕。
- 尽管创始人和负责人通常会关注团队文化的健康情况，但其实每位成员都是团队文化的一部分，都要为定义、维护和保护它作出贡献。
- 所谓“强壮的文化”，是指能接受有益的改进，同时又能抵御有害的激进变化的团队文化。
- 强壮的文化能为你提供专注、效率和力量，这些东西都能让团队更快乐。
- 团队文化有意思的地方就在于如果你清楚地定义好它，它是会进行自我选择的。在开源世界里，那些构建在HRT之上，专注于编写干净、优雅、可维护代码的项目会神奇地吸引拥有相同价值观（即尊重信任他人，并且致力于编写干净、优雅和可维护的代码）的工程师加入。然而，如果你的团队文化是侵略性的、欺凌性的，或者是感情用事地进行人身攻击的话，那最终吸引过来的也只能是这样的人罢了。
- 如果你在招聘的时候不重视团队文化的契合度，结果招了一个不合适的人，那最后无论是让他融入团队还是请他走人都要耗费你大量的精力。不管结果如何，其代价都是非常高昂的，还不如在招聘的时候就确认新成员能够和现有团队一起工作。
- 如果你想要优秀的工程师为自己的团队工作，首要的就是雇佣出色的工程师！
- 所谓的“共识”，是指每个人都对产品的成功抱有强烈的主人翁精神和责任感，同时团队的领袖也真的愿意倾听团队的意见（即HRT中“尊重”的部分）。
- 团队作为一个整体必须在大方向上达成一致，不管你信不信，要做到这一点，关键就是要为它设立一个章程。
- 建设性批评是任何工程团队成长发展的基石。接受批评是需要一定的自信心的，而我们觉得建设性批评是最容易接受的一种。另一方面，给出建设性批评要比直接批评嘲笑对方困难得多。
- 让所有人认同团队的方向并完全了解团队要做什么是很花精力的，但是这些努力的回报是生产力的提高和更快乐的团队。
- 沟通的指导原则之一就是在同步沟通的时候（比如开会），人越少越好。而在异步沟通的时候（比如E-mail），涉及的听众越多越好。
- 有一件事是肯定的：如果你不花精力好好沟通，最终一定会浪费更多的精力去做一些没必要的工作，或是团队里别人已经做过的工作。
- 对工程团队来讲，撰写任务宗旨就是要准确地定义产品的方向和范围。好的任务宗旨不是轻易写成的，但是它或许能为你节省数年的时间来澄清哪些是团队应该做的，哪些是不应该做的。
- 没用的会议和折磨没什么两样。
- 有关开会的五条小贴士：
- 1．只邀请一定要参加的人；
- 2．开会前要决定好议程，而且要事先通知所有人；
- 3．达成目的后应提早散会；
- 4．注意别跑题；
- 5．尽量把会议安排在休息时间前后（比如午饭时间，下班前等）。
- 我们在做Subversion项目的时候有一句座右铭：“邮件列表上查不到的讨论等于没发生过。”
- 设计文档一般由一个人负责，两到三个人撰写，审核的人数则更多一些。它不但勾勒出整个项目的前景，也直白地告诉整个团队你想做什么以及打算怎么做。而且这时你还没有花费几周（甚至数月）编写代码，比较容易接受意见和建议，帮助你改进产品和优化实现。另外，当设计文档定型之后，它能帮助你安排划分项目的工作量。
- 很多非常成功的项目都有好几个邮件列表，把开发讨论、代码审查、用户讨论、公告发布、调度邮件，以及各种管理琐事区分开来。
- 最好的做法其实是从一个列表开始，当信息量太大无法管理（通常是列表成员开始抱怨求饶的时候）的时候再逐渐增加数量。好好花点时间培养邮件讨论的礼仪——文明讨论，不要被那些“嘈杂的少数人”所阻挠。
- 注释应该尽量解释为什么代码要那么写，而不是去解释代码做了什么。
- 因此我们推荐在项目层面而不是代码上认可大家的工作。如果需要更多的细节，可以在版本控制系统里找到答案。一切都会随时间散去，就像雨中的泪滴。
- 代码改动应该尽量短小以保证审查的质量——若改动涉及几千行代码，那么除了挑挑格式的毛病外，基本是没办法进行审查的。
- 尽管为团队招募到合适的人才和为团队注入正确的价值观都是非常重要的事情，但最后绝大部分能真正成为文化一部分的努力其实都是来自沟通。
- 有的人认为只要雇佣一个超级架构师，再配几个普通程序员就可以做出好产品了。我们承认这的确是可行的，但是和一群能激发你的灵感、挑战你、教导你的优秀同事一起工作比起来，这种方式实在是太无聊、太无趣了。
第三章 大海航行靠船长
- 传统型经理关心的是怎么完成任务，而主管只关心完成了什么任务……（并且相信团队能自己想出解决问题的办法）。
- 经理要关心怎么干，而主管只负责设定大方向。
- 唯一要担心的就是……好吧，所有的事情。
- 量化管理工作比数数要困难得多，而你也不用把团队的成果据为己有，相反，让他们开心有动力才是你的主要工作。
- 反模式：雇佣听话的人
- 反模式：无视表现不佳的人
- 在Google，负责所有服务正常运行的那支团队有这样一句座右铭：“希望可不是一种策略。”
- 反模式：无视人际关系
- 反模式：和谁都是朋友
- 千万不要把友谊和怀柔搞混了：当你掌握了别人的生计时，他可能会感受到压力，主动表现出友好的姿态。
- 反模式：降低招聘标准
- 找到对的那个人的成本（不管是付给面试官的钱，还是花在广告上的钱，还是寻求推荐的费用）比起招到一个不应该招的员工的代价来绝对是微不足道的。后者包括了团队丧失生产力，导致团队压力，耗费时间去管理这名员工，以及解雇员工过程中涉及的各种书面工作和压力等。
- 没有人才是打造不出顶尖团队的。
- 反模式：把团队当小孩子
- 领导的人越多，保持淡定和冷静就越是重要，因为众人都会（不管是不是有意识地）看着你，看你在面对事物时的态度和反应是怎么样的。
- 工程师来问你建议通常不是要你去解决他的问题，而是要你帮助他解决问题，所以最简单的方法应该是问问题。
- 让你的团队了解到你帮助他们解决障碍的意愿和能力是非常有价值的事情。
- 在帮忙扫除障碍的时候，你用不着通晓一切，往往认识能解决问题的人就足够了。很多时候认识正确的人比知道正确答案要有价值得多。
- 催化团队的另一种方法是给予他们安全感，这样他们就愿意接受更高的风险。
- 在Google我们常说的一句话就是，若明知不可为而为之，那么成功的机会肯定是渺茫的，但即使失败了，你的收获也比只尝试那些你知道自己肯定能完成的事情所得到的要多得多。
- 成为导师不需要接受什么正式的培训，也不用做太多的准备工作。事实上，你只要具备三个条件就基本可以胜任了：熟悉团队的流程和系统，向他人解释事物的能力，以及估计被指导的人到底需要多少帮助的能力。最后一个条件或许是最重要的——你要做的就是给你的学生提供足够的信息，但是假如你解释得太多，或者无休止地东拉西扯，那么你的学生也未必会领情，他可能会直接忽略你，而不是礼貌地告诉你他已经明白了。
- 只要表现出亲和力和同情心，无需诉诸三明治赞美法，同样可以提出建设性的批评。
- 想要知道团队快乐程度最有用的一招就是每次在一对一会议结束的时候问问你的队员“你还有什么要求吗”。
- 不管有没有说出来，大多数工程师心里都会有抱负的。要是你想当一个好领导，就应该考虑一下怎么帮忙才能够实现这些愿望，让你的团队知道你真的放在心上了。
- 工程师也像是植物一样：有些需要更多的光照，有些则需要更多的水分（还有一些则需要更多的牛粪，哦不对，是肥料）。而你身为领导的任务就是要弄清楚每个人的需求，然后满足他们。
- 只要能给予以下三样东西就可以达到内部激励的目的：自主、精通、目标。
- 工程师拥有自主权的意思就是他可以独立工作，不需要别人盯着才能干活。对有自主意识的工程师，你只要告诉他们产品的大致走向就行了，至于具体怎么操作，完全可以留给他们自己决定。这是很有激励性的，因为他们更了解产品（比你更清楚怎么打造产品），而且这样更能激发他们的主人翁精神。
- 从本质上来讲，所谓的精通就是说你要让工程师有机会学习新技能，在现有的基础上继续磨炼提高。大量地提供这样的机会不但有助于激励工程师，还有助于工程师进步，进而令团队变得更强。
- 说到底，要是一个人不知道为什么工作的话，不管有多大的自主权，不管精通多少技艺都是没有意义的。因此你需要给他一个工作的目标。
- 结语——不管你有没有领导团队的意愿，我们都希望这一章能帮助你理解什么才是优秀的团队领袖，并且解开一些有关主管究竟要为团队做什么的谜团。
第四章 对付害群之马
- 本章我们要讨论的是一个非常重要的话题，防止那些捣乱的家伙破坏你的团队辛辛苦苦建立起来的合作氛围。更重要的是，我们要探讨一下怎么对付那些已经在团队里的害群之马。
- 如果你打算打造一支高效敏捷的团队，那么知道自己不要什么也是非常重要的。
- 一般来说，一个人总是让自己沉浸在负面情绪里是不健康的行为——长远来讲，它会侵蚀你的一切，制造更多麻烦
- 在带领团队的时候，不要把自己想成是一帮精英，众志成城地要把所有的烂人都轰走，而是要培养一种拒绝容忍负面行为的文化氛围，这才是正确的态度。要剔走的是行为本身，而不是人，单纯地区分好人和坏人是很幼稚的想法。规定好哪些是不可容忍的行为，然后予以惩戒，才是更有建设性的务实态度。
- 如果容忍了不良行为的存在，不但你的生产力会受到影响，还会渐渐侵蚀团队的文化。而对抗它的最好办法就是通过一系列强有力的最佳实践和流程来提高团队的抵抗力。
- 写一份明明白白的任务宗旨。这样可以随时保持专注，知道哪些是目标，哪些不是。
- E-mail 讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人”。
- 所有历史都要有记录。这不单指代码历史，还有设计决策、重要的bug修复，以及过去犯下的错误。
- 有效地进行协作。利用版本控制，代码改动要尽可能的小，方便进行审查，扩大“公车因子”，避免出现领地感。
- 修复bug，测试，发布软件要有清晰的政策和流程。
- 降低新人加入时的壁垒。
- 依赖基于共识决策，在无法达成共识的时候也要准备好化解矛盾的方法。
- 无知和冷漠其实比蓄意更严重。绝大多数出格的行为都可以归结为缺乏基本的HRT。
- 俗话说，过犹不及。在打造高效团队的时候，一定要时时警惕不要过于追求完美，否则只会适得其反。
- 你的任务是写出漂亮的软件，没有义务讨好所有人，也不需要一再去证明自己存在的价值。你越是情绪化，就越容易浪费宝贵的时间去写一些激昂的回帖，而那些都是不值得你关注的人。应战之前应该谨慎一点，时刻保持冷静，知道哪些人是值得回应的，哪些人是可以无视的。
- 应该尽量把争执再次引向技术讨论。
- 有时候，当无论怎么努力都是徒劳的时候，你就应该果断放弃，继续向前。
- 把注意力放在重要的地方，不要被眼前的东西迷惑。
- 不要把用愚蠢可以解释的行为归结为恶意的。
- 不管怎么样，你的任务不是要培养傲慢的态度，把那些没有那么聪明的普通人赶出项目；你的任务是拒绝容忍毁灭性的行为，明确自己对 HRT的期望。有智慧的人才能体会其中的差别，而有能力的人才能真正予以执行。
第五章 操纵组织的艺术
- 只要经理够开明，失败其实是快速成长的最佳手段，认识自己的极限，然后逐步提升它们。
- 如果你从来没有失败过，那说明你太保守了。和追求更多责任一样，勇于冒险也是展现自己有能力做大事的一种方法。
- 对不确定的事情提出疑问。如果经理的决定让你觉得难以认同，千万不要害怕和她争论，或是对她决定的出发点提出质疑。尽管这不是说你就可以肆意制造障碍，但是盲从对于领导来说也是毫无帮助的，特别是当你掌握了一些她不具备的知识和经验的时候。
- 公司环境里阻碍你成功的事情有很多，但是基本上可以分成两大类：糟糕的人，还有糟糕的公司。
- 这和我们在第三章里提到的仆人式经理完全相反，坏经理只想要知道你为她做了什么。而那些团队里表现不佳的人呢？根本没人关心，只要他们不闯大祸就可以了——对坏经理来说，和那些人打交道实在是太麻烦了。
- 我们的建议是对这种办公室政治高手最好敬而远之：没什么事的话就躲远点，但不要口没遮拦地在公司里跟人说他的坏话，谁知道对方是不是清楚他的为人呢，或许他也被蒙蔽了。
- 首先最简单的一个现实就是，大多数公司都不是以工程师为核心的。这就是说，工程师只是实现商业目标的工具，而商业目标本身通常不是技术性的。
- 和演示程序一样，公司也是由规则组成的，有些可以变通，有些还可以打破。如果你老是把注意力放在公司“应该”怎么做事上的话，最后除了挫败和失望什么都得不到。相反，若能接受现实，然后从中找到利用它的方法，就能完成工作，还能在公司里找到一片立足之地。
- 创意是非常吸引人的东西，如果你不在意是不是一定要让别人知道是你原创的话，创意往往能变得非常有活力！
- 在做承诺的时候要谨慎，而干工作的时候要尽最大努力。
- 身为工程师，应该把精力放在发布产品上，而不是其他的事情上面。
- 尽管在清理代码和重构上面花大力气是非常有诱惑力的想法，但是经验教训告诉我们，不要花太多时间在这种防御性的工作上，很少有人看重这些，到时候你会发现自己的处境很尴尬，因为花了那么多时间，你却拿不出什么（政治上）看起来很重要的成果。这样你不但得不到别人的认可，还很容易导致自己的项目被取消。
- 有了这次糟糕的经验后，Ben开始把所有的工作分成“进取性”和“防御性”两大类。进取性的工作通常是指用户看得见的新功能；而防御性的工作主要是着重产品长期的健康状况（比如，代码重构、特性重写、修改数据库模式、数据迁移，或是改进紧急监控等）。这些防御工作能让产品更稳定可靠，可维护性更强。然而尽管这些工作至关重要，却得不到任何政治上的好处。
- 不管技术债务有多少，团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性的工作，否则就等于政治自杀。
- 如果你只是逐字逐句地完成任务，除了自己的工作对其他事情都漠不关心的话，是很难看到什么机会的。如果有机会有条件帮助别人完成工作，即便那不是你份内的事情，而且他们也不一定会回报你（你也不应该期望对方投桃报李），但是很多人还是会很乐意在将来有机会的时候回报你的。
- 大多数工程师都觉得，只有工作成绩优秀才是符合逻辑的晋升条件，然而这种事情只有在最牛的公司里才会出现。其他大多数公司通常都需要你（在出色地完成工作的基础之上，）再耍一点手段才能如愿。
- 在公司里的位置越高（不管是作为负责具体工作的人还是担任领导职务），你就越能掌控自己在公司里的命运。
- 仔细研读公司的晋升流程，和你的经理聊一聊，看看哪些事情是有助于晋升的，然后有条不紊地完成它们。即便晋升是个很主观和不确定性很大的事情，你还是可以去做很多事情来提高概率的。
- 记住：万一发生什么坏事，你的位置越高，全身而退的希望就越大。
- 当有机会改正错误的时候，那些在权位上的人都是非常乐意那么做的。
- 事实上，经过多年的试错后，我们发现越短的邮件就越有机会得到回复。
- 写得好的三个论点和一个行动的邮件（最多）包含三个点，让你解释问题的细节，然后一个（只能有一个）行动请求，绝不能有其他的内容。
- 如果你改变不了整个体系，继续投入精力去改变它是没有意义的。你应该把精力放到怎么离开它上面去：更新自己的简历，去问问周围的好朋友，看看有没有机会到其他公司就职；自学一点新知识。今时今日，身为工程师的最大好处就是优秀的工程师永远是紧缺的，因此你完全有能力掌握自己的未来。
- 如果你不努力去学习、了解引导公司的方法，那就等于是拿自己的命运去赌博。
- 如果你期望对方回复，那么就应该尽量简化，让他能直接在问题下面作答。不要一口气问五六个问题——尽量一个段落里只放一个问题，最好是一封E-mail只问一个问题。
第六章 用户也是人
- 软件开发流程并不是到软件发布就终止了，事实上它永远不会结束。人们在使用你的软件，而你也需要作出反馈，然后逐渐改善自己的产品。如果你不去学着掌握这个反馈机制，软件就会消亡。
- 承诺的时候要谨言，做产品的时候要超出预期。
- Google有一句非常著名的格言：关注用户，其他的东西自会随之而来。
- 使用产品的第一分钟是至关重要的。 当然，摧毁第一印象的方式还有很多，比如在初次启动软件的时候让用户去填一张巨大的表格，或是强迫他们设置一大堆偏好。强迫用户去创建新账户也很让人讨厌，因为这暗示了用户在还没有做任何事情之前，就要被迫签长期协议一样。这些细节都会迫使用户远离你的产品。
- 不要在意下载数量，找到衡量活跃程度的方法才是正道，这才是帮助理解软件的真正指标。
- 优雅的设计应该保持简洁，化困难为可能。即便你的软件在处理复杂的逻辑，它也应该让人觉得流畅简洁（我们关注的是用户的情绪）。 这就是所谓的“隐藏复杂性”。
- 不管界面有多优雅，软件都不应该绑架用户。由于用户可以取得自己的数据，做任何想做的事情，这就迫使你老老实实地竞争：人们选择你的软件是因为他们想要那么做，不是因为被（软件）绑架。
- 程序员犯的最大的一个错误就是把做完的软件丢在一边，不再去听取用户反馈。
- 越是让他们参与到讨论和开发过程中来，他们就越忠实、越开心。你不一定要同意他们说的东西，但是你一定要听。
- 要求普通大众懂电脑是不公平的，很多聪明人只是把电脑当作工具，仅此而已。他们对调试没有兴趣，也不想用科学的方法诊断问题。别忘了，我们大多数人也都不知道怎么拆开并修好自己的车；把你的用户当作笨蛋就好像汽车机械师觉得你是笨蛋一样，毕竟你也不懂怎么自己造一个变速箱，甚至懒得去想怎么诊断变速箱的毛病。汽车对你来说就是一个黑盒——只要能开就行了。对大多数人来说，电脑（包括你的软件）同样是一个黑盒，用户不想参与你的分析过程，他们只想要完成自己的工作罢了。这和智力没有任何关系！他们应该得到尊重。
- 信任是最神圣的资源，必须悉心呵护、步步为营。任何举动都要三思而行。决策的时候，眼光要长远，不要只注重眼前利益。
- 亚瑟·克拉克是英国著名科幻作家，他提出了克拉克基本定律。第三条是任何技术只要够先进，看起来都和魔术无异。其他两条如下。一，如果一名资深科学家说某件事是可能的，那么他基本上不会错；如果他说某件事不可能，那么他很有可能错了。二，要知道可能和不可能之间的界线在哪里，唯一的办法就是越过那条线。
结语
- 我们先不要把事情想得太复杂。假如你要从我们的故事里学到点什么的话，只要记住HRT就好了：谦虚、尊重、信任。
- 如果能在工作中一切以HRT为导向，就可以事半功倍地发挥影响力。
- 有人的地方就有江湖。
参考链接：
=END=
《 “[read]极客与团队” 》 有 35 条评论
全业务90天机房迁移小结
https://mp.weixin.qq.com/s/BgDqp0OSltoABZyd2AXvQg
`
1. 抛弃经验，空杯心态
经验固然重要，但被经验坑，相信也是常有的事。
设立共同的目标
借助团队的力量
尽可能详细的规划
`
从技术到管理——团队建设
https://mp.weixin.qq.com/s/ARObrn2BvoNgap9Np1_r9Q
我当初是怎么管理技术团队的
http://www.cnblogs.com/zhengyun_ustc/p/7047366.html
https://paper.tuisec.win/detail/e68e58d36de5251
安全，不可或缺的一员–安全项目经理
https://mp.weixin.qq.com/s/ZxJx8p-3G3WMx5tc_wu3Hg
`
不得不说的是，每一个项目都有自己的特性，都是不同的，每一个项目都存在一定的风险，项目经理负责找到项目的核心因素，将整个项目串联起来，规避风险，让项目成功上线运行。
安全项目经理有自己的特性：
项目管理的同时深入安全业务。
实现安全需求的同时，将安全项目的意义传递，在产品线将安全需求推动到具体的业务中实现。
紧急快速处理问题，执行安全决策要有一定的力度。
对内，各个团队在运作的时候互为输入输出，特别是一些需要多团队协作完成的安全项目上，对方方面面的工作进行整合，对外进行推动。整合资源推动的执行的过程，又要将安全意志传递，同时深入业务，跟的上变化。
`
产品经理宝典
https://blog.devopszen.com/pm_bible
https://www.kennorton.com/essays/how-to-work-with-software-engineers.html
`
1. 记得邀功
作为 PM，要让大家知道自己的成果。要理解，公司的管理者通常只会赞赏整个产品团队。这时候你要警惕：是因为你产品才获得成功，所有荣誉都应该属于你。这种荣誉是职业发展的基石，只有你自己维护自己的 Linkedin 履历，而不是其他人。
2. 避免背黑锅
什么事情都会时不时的会出一些问题。在软件开发中，出问题的基本是软件本身。当软件出错的时候，程序员才是需要责备的人。这很合情合理。确保当别人责备你的时候，将矛头指向程序员，必要的时候要先发制人。要记住：“我们出错了“的“我们”中不包含自己。
3. 不要纠结细节
简单的技术细节要留给程序员去做。你要去做更重要的事情。过多解释会导致失望，或者陷入”可能性“的讨论。如果你过于纠结什么难做、什么简单，你将难以做出改变世界的产品。避免思考细节。任何你想做的事情都只是 10 行代码而已。当然，哪 10 行并不重要。
4. 让程序员后期参与
软件工程师写代码，这是他们的工作。他们经常会厌烦各种产品设计影响到自己的发挥。所以，为什么要在需要写代码之前让他们参与呢？你从来没见过建筑工人闯进架构师的办公室胡闹吧。再所有设计完成只剩下编码后再让程序员介入。
5. 增加流程
在团队中展示自己的价值的最佳办法是引入流程。寻找机会开进度更新会，建立每日摘要和回顾制度。通过让程序员填写日报、月报、进度更新报告、跨部门执行报告邮件的方式保证程序员的生产力。这些事情如果你不去做，就没有人回去做。要明白：语言留言、短信之类的对程序员来说根本不起作用。
6. 避免说明原因
工程师非常聪明，意思是，他们倾向于去做不太复杂的事情，经常依赖支持数据和关联逻辑，而不是靠远见和蓝海思维。做决策的时候要保持一种神秘色彩，这样他们才会愿意去做。无论他们怎么抱怨，都不要让他们抓住具体的细节。
7. 保证团队进度
作为产品经理，代表的是自己的整个团队。领导力的核心是设置高门槛，然后让每个人完成它。展示自己不需要跟团队很多沟通就能做进度保证的能力。人们在许诺和承担责任后会迅速提升自己的能力。想想约翰肯尼迪，他随便选了个日期登月，但是 NASA 却完成了。
8. 随时打断
你是个繁忙的知识工作者，只不过需要最后等工程师完成你的工作。你立刻需要结果。只要工程师现在正在做的事情没有你现在要做的重要，就去打断他们。聊天窗口和电话起作用，但是什么也比不上走到他们什么拍拍他们的肩膀提醒他们。假如他们刚刚开始做你 1 小时前分配的任务怎么办？也没关系，优先级更重要。
9. 含糊其辞
在职业发展中，没有什么被证明自己的错误更危险了。为了保证自己不犯错误，就需要含糊其辞和不精确。在任何时候都可以改变自己的想法。不要保留任何书面证据，或者在文档中长篇大论没人想去读它。
10. 程序员总在撒谎
工程师总喜欢说这个不可能做，那个不可能做。他们在撒谎。如果你想出来了，就可能做到。莱特兄弟从来没想过可以飞跃大西洋。软件工程师总是在欺骗你。所以，当你听到 ”技术债务“ 或者 ”在家工作“ 这些词汇的时候，就可以。。
最后
如果你朝这十条的反方向去做就对了。
`
项目经理如何理解客户的真正需求
http://www.mypm.net/articles/show_article_content.asp?articleID=30778&pageNO=1
`
做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题
2. 这个项目里牵涉哪些方面的人
3. 了解自己公司各方面对这个项目的看法
4. 在做整体项目计划前，还要大致计算一下你手上的资源
5. 现在是做项目说明书的时候
6. 确定是否到做总体计划的时间
7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略
8. 和项目干系人沟通项目计划
9. 开始制定项目实施计划
10. 进入项目实施阶段
11. 如何面对客户的需求变更问题
12. 开展项目收尾工作
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。
通常，项目经理有以下几个档次：
最差的项目经理：项目过程中总是出现意外，然后自己又解决不了，结果成为烈士；
二流的项目经理：项目也经常出现意外，但是他一马当先，奋勇向前，解决了一个又一个问题，最后，勉强算把项目结束了，获得了领导的一致好评；
一流的项目经理：平时很少见他做具体的事情，整天找人聊天，然后就是写报告、做计划，最后项目顺利结束，整个过程平淡无奇。
项目管理到底是一门科学还是一门艺术呢？所谓科学就是经过反复论证，输入和输出有必然规律的东西，种瓜得瓜，种豆得豆；而艺术就是思想火花的闪耀，主要靠灵感。
项目管理，据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感染能力等东西。仁者见仁，智者见智，所以，加强很多方面的个人能力，如练就出色沟通能力、提升自己的个人魅力对于项目经理来都很重要，无论是对内还是对外。作为一个一流的专业人士，在顺利让客户签字的同时，如何让自己的领导知道你的价值，这也是体现自己能力的一种途径。
`
为什么华为的质量体系发挥作用，我们的质量体系形同虚设？
https://mp.weixin.qq.com/s/2NwwUp42Lcu1Il77vSSjzQ
`
1. 将产品质量视为生命
2. 质量体系改进是有计划，有目的，一步一个脚印地进行
第一阶段：引入IPD+CMM加强软件质量控制
第二阶段：建立集大成的质量标准
第三阶段：引入零缺陷的质量理念
以客户满意度为中心的质量体系建设
3. 质量管理措施有效，特别是让中层管理者发挥作用
学习华为必须更加深入，学习他们如何将管理要求落地的措施和方法，这样才能使得组织的质量体系改进真正发挥作用，帮助组织提高产品的质量。
`
你应该雇佣老程序员的五个理由
https://mp.weixin.qq.com/s/5xmPxe9oR0TeHqRazarEHw
https://joshondesign.com/2017/07/02/hireoldprogrammer
`
1.经验
2.判断力
老程序员拥有判断力。他们知道在何处可以将系统进行模块化拆分，并保证是可靠和可测试的。他们可以从架构图中看出系统可能的瓶颈在哪里。（你是拥有大量的数据还是大数据？这一点很重要）。他们知道如何为特定项目选择哪种技术，以及如何优化可靠性，性能和开发速度（三者中任选二）。他们知道如何做出权衡。即使他们从来没有为你的项目实际写过一行代码，但老程序员还是很有价值的。他们懂得如何建立质量保证，从长远来看，高质量意味着更低的维护成本。
3.知识的深度
老程序员对特定领域有深刻的理解。这些知识使得他们知道从哪里可以找到系统的 bugs，以及如何完全避免这些错误。
4.知识的广度
我知道如何有效的和其他领域的人交流。正是这种沟通能力使得我成为一个富有成效的团队成员，而不仅仅是编写代码的。
5.沟通技巧
任何一个四十多岁的程序员都必须具备良好的沟通技巧。这些能力和他们的编程能力一样有价值。一个新的 API 如果不能有效的传达给它的使用者，那么它是毫无价值的。大多数大型软件项目的失败不是因为代码不好，而是因为沟通相关的问题。
没错，老程序员需要花费更多的薪资，而且看起来工作时间更少，但实际上我们完成了更多的工作。我们可以正确的评估并按时发布代码。我们能够构建出更少 bug 的系统，同时拥有合适的性能。我们可能写的代码更少，但产出更多的商业价值。这就是我们值得高薪资的原因。
`
共识就是执行力
https://mp.weixin.qq.com/s/K9Q3kbmW5ZPPTqqb0NcVQQ
`
传统的跨团队讨论，往往是各方只看到自己想看到的东西，每个团队拼命捍卫自己的利益。到最后争得精疲力尽，也难以达成共识。所以只好找官最大的人去拍板。看似找到了结论，但因为是被拍出来的，所以也不会有100%的执行效果。
这其中的症结就是「共识」。共识是什么？我们有一个非常形象的比喻，让参会的每一个人，把自己所看见的和利益诉求在白板上画一个圈。当所有人画完之后，就能看到所有圆圈交集部分，就是所谓「共识」。我们要做的第一步，是鼓励大家说出心声，把自己心中的小圈子画出来，让大家看到真实的现状。
大家知道OKR和KPI的最大区别是什么？OKR关注人，而KPI关注事。在OKR体系中，目标一定是所有关键利益方通过开放式的讨论达成的共识，而KPI体系中，目标都是「聪明的老板」或者「牛逼的管理层」自己拍出来，让团队去自己拆解执行的。
`
需求变更控制要注意的几个问题
https://mp.weixin.qq.com/s/G6_l0XiGjHJIF9MaH6Fv5Q
`
需求的变更通常是不可避免的。所以，敏捷的宣言就提倡拥抱变化。但是，虽然变更是不可避免的，但对于变更一定要进行控制，不受控制的变更可能会提高项目的成本，迟滞项目的进度，甚至给项目带来失败的风险。
这说明需求变更控制这一实践不容小觑，可是经验教训表明，这一实践在具体实施的时候，总是浮于表面，很难取得有意义的效果。
加强需求变更控制，要注意以下几个问题：
1、必须做好需求变更影响分析
即使软件过程管理体系文件中规定了需求变更影响分析的内容，这个影响分析也会做不好。那是因为管理者和设计师都没有了解清楚变更影响分析的意图。需求变更影响分析包含两个目的，一方面是分析变更会给软件带来哪些影响，包括好的方面，也包括坏的方面，这部分内容将会成为需求变更审批者进行决策的一个依据；另一方面，需求变更影响分析要分析清楚变更的方案，供CCB决策。设计师理解这个意图能更好地分析，决策者理解这个意图也能更好地决策。所以软件过程管理体系文件中也要讲清楚这个意图。
2、再小的变更也要履行正式的变更流程
变更控制就是要杜绝随意性。因为每一次变更都会对软件带来或大或小的影响，改变了计划、推迟了进度、影响了功能、颠覆了架构……。所以在软件开发过程中，不允许随意改动需求。变更控制的另一个目的是，让需求的变动以及受其影响带来工作产品的改动，都应该让各利益相关方知悉。如果变更不走正式的流程，很有可能这个软件被更改了，但只有少数人知道，一些利益相关方未能及时发现、及时了解软件的变更，将会极大影响后续的工作。
3、变更决策要慎重
需求变更在某种程度上是开发方和用户的博弈。对于变更的决策一定要慎重。
决策要基于理性而非感性。要考虑清楚变更之后，对软件来说是弊大于利还是利大于弊，以此来判断变更是否实施。变更的决策应尽可能地基于量化的数据，这些量化的数据主要来自于变更申请单中变更影响分析。
管理者在审批需求变更的时候，一定要衡量清楚利害关系，才能批准变更的申请，不能不闻不问，只是机械的签字通过了事。
4、必须做好变更的验证
每一次变更都有可能引入新的缺陷，所以，在变更完成之后，对变更的验证非常重要。尽管已经分析出了变更对于软件是利大于弊，这个变更值得进行，但是如果变更后没有对软件进行充分的验证，让变更后的软件又引入了新的缺陷，那就是事倍功半，得不偿失。
需求变更控制是需求管理的重要实践，不容小觑。
`
为何90后员工只谈钱？
https://paper.tuisec.win/detail/0ddc99965d88ef7
http://www.woshipm.com/zhichang/1614721.html
https://mp.weixin.qq.com/s/jDq4hHbo5fU2xHvOklt76w
`
我们如何更好的留住90后员工呢？
我们需要从四个方面着手：
工资平衡
自我发展
公司愿景
自我成就
`
软件开发工作过程中的一些总结
http://www.youmeek.com/java-sofaware-engineer/
`
声明
本文还在不断完善中，更多的是希望能引起思考，不要照搬。
核心
尽最大可能帮助企业更加高效协作，以更好的数字化体验吸引客户，同时让维护更加容易、低廉。
每个公司的组织结构都有其特点，本文无法直接套用，需要根据其结构优化调整
持怀疑态度对待任何问题，包括本文任何字眼，多思考。
有序、规范化不等同于要失去灵活，它们之间有一个度，而我们再寻找那个度、平衡
理念
敏捷：快速响应市场的变化，争取活下来，再谈盈利。
DevOps：开发运维一体化，目标一致，高效沟通、配合。
测试驱动开发（TDD）：有助于做更好的开发质量，协助开发量化指标，从而有更高效的响应。
无状态：保证 API 接口可伸缩性
功能开关：开关多样化可以尽可能避免回滚和多次发布
分享精神，促进沟通，凝聚力根本（必须）
`
团队使用 OKR 的十个最后建议
https://mp.weixin.qq.com/s/YYdC47HLaTSjVDOhcc23Zg
研发团队如何使用OKR
https://mp.weixin.qq.com/s/C3CPb4ybJoGIfE_oO97fCw
OKR 工作法简介
https://mp.weixin.qq.com/s/BWXw2d646zK9ZfUTr0tKUQ
研发团队如何使用OKR
https://mp.weixin.qq.com/s/Vj8U7tYhlT6iiTztQTGNvQ
浅谈团队管理最佳实践
https://jingwei.link/2019/02/05/team-management-methodology.html
`
用合适的管理方法提升团队效率
团队管理是否存在最佳实践？
一、每个人都需要关怀
二、公平公正公开的价值评判标准
三、团队沉淀——文档与流程标准化
四、具象化团队这台机器的样貌
再谈领导者的价值
小结
参考
`
为什么选择使用 OKR 进行项目过程管理
https://mp.weixin.qq.com/s/5H3I1Y04Dtx3N9ob5fhmuA
`
三、OKR 不会孤立地对待目标
OKR 与 SMART 有所不同，因为 OKR 是在一个框架内创建的，并描述了与组织层次结构及其与组织时间框架的关系。
最终 OKR 位于 OKR 层级的最顶端，可运行 5 年、10 年甚至更长时间，这个目标结合了公司的愿景 (我们希望在长期未来的哪个方面？)和使命 (我们的目的是什么？)。
公司 OKR 构成 OKR 的第二层级，运行 1 年。代表了公司的战略，转化为整个组织努力的 3 至 5 个目标。公司 OKR 在整个组织的协调工作发挥着重要的作用，为所有员工设定了明确的重点，并为团队 OKR 提供了参考点。
团队 OKR 构成了 OKR 里的第三级，可以按季度运行，代表团队或部门执行的策略，以推动公司 OKR 的进展。
项目 OKR 构成了 OKR 里的第四级，可以按月度运行，代表跨团队协作、个人的行动方针，以推进团队、公司 OKR 的进展。
与 SMART 相比，OKR 提供了目标在其中工作的额外级别的组织架构和上下文，相比之下，SMART 只是孤立地考虑目标的形成，而 OKR 则整个组织的目标之间的关系是明确的。
`
透过 OKR 进行项目过程管理
https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455759377&idx=1&sn=de5cfb7f337b523d35cad711b4370b8b
如何打造有战斗力的团队
https://mp.weixin.qq.com/s/cSk1GK21f7B2zEfCrGJcEQ
`
*责任感、主人翁意识
*执行力、崇尚行动
*创新力、化繁为简
*勤回顾、自我批评
*多付出、赢得信任
*肯钻研、刨根问底
*有气量、选贤育能
*重交付、达成业绩
`
如何成为优秀的技术主管？你要做到这三点
https://mp.weixin.qq.com/s/0LVj1IcWMWAuUeY6U7r4hg
`
曾经有一段时间我也在思考技术TL的核心职责到底是什么？技术TL应该具备哪些素质？
首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL肯定是不合格的。首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。
第二个，我认为最最重要的是架构设计的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了技术TL这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。如果没有很细腻的感知能力，很多的决策会有偏差。
如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。
关于技术层面，技术TL需要具备如下素养：
技术视野良好，解决问题能力与架构设计能力出色。
技术TL要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。
动手能力要强，学习能力出色。
技术TL并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，技术TL不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，技术TL也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术TL的。
技术TL除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等，这样以要求技术TL也同时也需要具备良好的沟通和管理能力，以上观点仅是个人的一些思考和观点，仅供参考。
`
陈春花：向上管理，就是与你的老板相互成就
https://mp.weixin.qq.com/s/d8hJHBe1O66GT26YdqpmTw
`
彼得·德鲁克在《卓有成效的管理者》一书中说：“工作想要卓有成效，下属发现并发挥上司的长处是关键。”
我们大部分人对于管理的思维定式是向下管理、向上负责。
我觉得应该修改我们的管理思维定式，正确的是：向下负责，向上管理。
向上管理，简单地说，就是迎合上司的长处，尽量避免上司的短处，自问：“我/我的下属怎么样做才能使得上司的工作较为顺利？”为了实现建立并培养良好的工作关系这个核心目标，做好向上管理，主要包括五个方面。
1.要建立和谐的工作方式
2.要不断提升相互的期盼
3.要确保信息流动顺畅
4.要有诚实和可靠的关系
5.要合理利用上司的时间与资源
`
我们应该如何给需求排序？
https://blog.fundebug.com/2019/03/05/how-to-sort-requirements/
`
以用户为核心确定优先级
BUG 的优先级高于新功能
需求管理是一门艺术，需要考虑和权衡的东西很多，暂时给大家一个简单的优先级排序，仅供参考：
用户反馈的 BUG
自己发现的 BUG
用户反馈的需求
自己想出的需求
严格按照这个顺序操作是不可能的，这是给大家提供 2 个思考维度。实际工作中，每个需求的影响范围、紧急程度、难易程度也需要考虑。
`
产品需求优先级的艺术 – Kano 模型
https://mp.weixin.qq.com/s/l8VOj0ofnUAojFgaymi_IQ
如何成为优秀的技术主管？你要做到这三点
https://mp.weixin.qq.com/s/0LVj1IcWMWAuUeY6U7r4hg
为什么美国程序员工作比中国程序员工作轻松、加班少？
https://mp.weixin.qq.com/s/eLl-juu6faqPwfBzAwc29Q
如何领导自我管理的团队-上篇
https://mp.weixin.qq.com/s/BGQG5SaIy2ZMtjlfzRV4ig
如何领导自我管理的团队-下篇
https://mp.weixin.qq.com/s/yNYMr-qhjDMY_-nxMLO1aA
技术人该有的的六个意识
https://paper.tuisec.win/detail/19f6205b25d69f6
https://toutiao.io/posts/ccm6ac/preview
`
这篇文章讲的是百度在数年前要求每个入职的工程师必须被灌输的六个职场意识，这六个意识非常有价值，不管对技术 leader 还是职场小白都应该非常有指导意义。 这里分享给大家，与同在职场中奋斗的同学们共同参考。
1. 质量意识
1.1 流程意识
world class procedure：用流程解决具有共性的、重复性问题，提高效率
既有的流程应严格遵守；没有流程的应创建流程
1.2 要对自己的工作质量负责，不要期待别人来发现自己的问题
1.3 “稳定”压倒一切，线上服务最重要
用户体验最重要
工作安排：二八原则
优先解决线上服务稳定性问题
1.4 不要“想当然”
不要默认“没问题”，而是缺省认为“有问题”；“肯定没问题”一定有问题
反复核实(double check)十分重要
“我以为他们已经开始做，但我也没有跟他们确认一下” —— 导致项目延期
“我以为这个接口是这样定义，但谁想到是那样的” —— 导致程序崩溃
“我以为发出邮件，他肯定就知道了” —— 实际上，他/她根本不在相应的邮件列表中
2. 时间意识
2.1 目标管理、结果导向
弹性工作制：上下班时间自由支配
关键是要按时保质完成工作
2.2 只争朝夕，争分夺秒
激烈的产业竞争环境
不要拖到最后才开始工作，因为总可能会有意外
能今天做完的绝不拖到明天
2.3 自我管理，自我推动
每件事情都有完成时间表，给自己一个约束，给别人一个承诺
每件事情有始有终，设立一些里程碑，在里程碑上检查进度，主动向其他人通报进度
建立个人品牌，树立别人对自己的信心
3. 沟通意识
3.1 平等沟通
在沟通上没有级别概念
不要碍于面子，不要怕犯错误：报喜亦报忧
CC文化
3.2 及时沟通
邮件是最主要的沟通形式，但有时不是最有效的
当面沟通，电话沟通，召集会议都是有效的形式，但要留下文字
3.3 有效沟通
沟通要达到效果
如果没有效果，应让更多人知道，尤其是你的老板和对方的老板
4. 团队意识
4.1 集体荣誉感
用你的成绩为你的团队带来光荣
4.2 互相帮助，互相学习
乐于给别人提供帮助
也勇于向别人学习：有问题不要憋在肚子里
互相理解
把周围同事当作你的资源，包括你的经理
4.3 对事不对人，尊敬身边每一个人
5. 求实意识
5.1 科学求实是技术发展的基础
5.2 用数字说话，用事实证明，不要有“想当然”的思想
大胆假设，小心求证，不放过每一个细节和疑点
客观公正
杜绝“可能”，“大概”，“应该”这样模棱两可的用词，而是用准确的数字和事实来论证
5.3 每个工作能用量化的指标来进行衡量
性能、容量、准确性、召回率、死链率，etc.
没有量化，就没有绩效
通过这些指标衡量自己的成长和进步
通过这些指标知道工作的方向和重点
6. 进取意识
6.1 永葆激情，积极主动
热爱你所从事的工作
不要等别人为你分配任务，你就是自己的老板
6.2 与时俱进，不断学习
在高速成长的公司，你才会有高速成长的可能
要有和公司、团队的同步成长的意识
6.3 对技术、对质量的追求永无止境
没有最好，只有更好
目标远大，不固步自封，自我满足
6.4 忧患意识
6.5 Case study和自我总结，自我学习和提高
Case study是一种文化，从事故中吸取经验教训
容忍失败，但不容忍重复失败
经常反思一下自己
不放过任何一次问题，勇敢地剖析自己
`
工作日报不简单
https://mp.weixin.qq.com/s/5MeZPBZFw8Ykp3VhtGSZvw
`
1. 与OKR关联，把目标导向融入每一天，提升个人工作效率
2. 快速传递高价值信息，增进沟通，促进信任
工作日报的具体写法很简单，有如下要点：
1、每周一写「本周要事」，通常包含3-5件最重要的，与季度OKR、月度计划相关的要事。
2、每天早晨写「今日要事」，包含1-3件今日内最重要的事情，通常要求保持与「本周要事」的关联性。
3、每天晚上下班前写「今日完成」，包含对「今日要事」的回顾总结，也包含思考和困难。同时建议写出「明日要事」，包含自己对于明天最重要工作的预测与规划。
4、每周五（六）下班前，不仅写「今日完成」，也要写「本周要事」的总结和「下周要事」。
这些信息，在写完之后都要在第一时间「群发」，无法群发的工作日报，其价值至少折损50%以上。
工作日报强调的是「连接」，让每日与季度OKR、月度计划、和周计划连接。让每个人和更多人连接。这样工作日报就能把孤立的每一天与长期关联，把孤立的每个人与团队关联。这就是工作日报的核心奥秘！
`
OKR 和 KPI
https://www.v2ex.com/t/582503
`
OKR 和 KPI 对于大家应该都是耳熟能详的绩效考核方式，因为部门在推行 OKR 和 360 度绩效考核，我阅读完《 OKR 工作法》这本书后在组内也做了分享，结合我们小组的实践过程记录下自己的心得体会，我也非常赞同左耳朵耗子大大的观点: 绩效分应该打给项目，打给产品，打给部门，打给代码，而不是打给人。
一句话讲清楚 OKR 核心：制定一个较长期的目标（ Objective ），并且将目标分解成为一些关键的结果（ Key Results ）
`
https://wsgzao.github.io/post/okr/
读《 OKR 工作法》
https://www.barretlee.com/blog/2019/05/16/book-reading-about-okr-working-methods/
华为的 OKR 实践心得 – 读《绩效使能 – 超越 OKR 》
http://blog.devtang.com/2019/03/29/okr-exp-from-huawei/
OKR 工作法简介
http://blog.devtang.com/2018/11/22/okr-introduction/
微软、IBM 纷纷取消绩效评估，如何做员工绩效管理
http://www.sohu.com/a/118995624_376476
谷歌的绩效管理
http://www.ruanyifeng.com/blog/2016/03/performance-management.html
我看绩效考核
https://coolshell.cn/articles/17972.html
百度工程能力的提升之道
https://www.infoq.cn/article/zPd74ESPQRMGy*g6p7yV
`
一个技术公司，研发工程能力的高低直接影响公司的持久创新力和公司在市场上的作为。长期以来，百度在大量的软件开发经验中总结了体系化的工程能力提升之道，有效帮助提高软件开发效率 和产品质量。本文整理自百度资深产品经理王一男在 QCon 全球软件开发大会（北京站）2019 上的演讲，他分享了百度在软件工程能力人、技、法、数据方面的建设经验，希望能对你有所启发。
# 助力业务成功是提升工程能力的目的
我们做工程能力工作的同学经常被问到这个问题：提升工程能力的目标是什么？为什么要做工程能力提升？提升了以后会带来什么效果？
提升工程能力的总体目标是助力业务的成功，提升业务前进中的研发能力，让业务更快速、更高效的发展。
# 如何提升工程能力？
百度提升工程能力的策略模型可以用“人”、“技”、“法”、“数据”来概括。下面我给大家详细介绍一下围绕着这四个方面我们具体做了哪些实践。
一、人：
招聘优秀的工程师
工程师能力培养
工程师文化建设
二、技：
研发工具
管理协同工具
DevOps工具
工程复用
平台复用
源码复用（开源）
三、法：
工程实践
管理实践
平台治理方法
开源方法
四、数据：
研发现场大数据
工程能力地图
工程师画像
工程复用大数据
平台化指数
开源贡献度
DevTools -> DevInfra
`
会向业务“砍需求”的技术同学，该具备哪6点能力？
https://mp.weixin.qq.com/s/43_X-FXSZ1dB0uedaKmuMQ
`
产品同学的关注点主要在于：
1、理解业务。具体一点讲，明白当前业务的现状，目标和方向，核心KPI是什么，为什么我们要做这个事情，以及做了以后对业务带来的价值是什么？
2、了解技术实现的细节。当前的业务产品在系统中是怎么实现的，有哪些能力和局限，与上下游的关系是怎样的。如何能够快速的实现目前的产品需求。很多时候同一个问题可以有多种技术实现，每种实现都有自己的优缺点。优秀的技术同学能够基于对当前业务问题的理解，作出最恰当的选择。
3、能给到产品有效的输入。对产品设计不合理的地方提出挑战和有建设性的意见。对产品设计遗漏的地方给予补充，对稳定性、安全性，以及资损、舆情、PR等潜在的风险给予意见和建议。
4、积极的沟通和推动项目落地。帮助产品一起管理好业务的预期。能够换位思考，理解业务面临的压力，管理好项目的风险，保持信息的透明，想尽办法帮助业务实现需求。
一些理解和执行的误区：
1.非理性的挑战
2.Technical Debt and Over-Engineering
3.脱离技术实现的细节空谈业务
4.Over communication is better than no communication
技术同学的诉求集中在以下几点：
1.参与需求的生成
2.产品设计要有全局视野
3.既要管生，也要管养
4.用有限的资源做最有价值的事情
技术同学怎么去培养自己的商业头脑呢？下面给出一些简单的建议：
1.产品是我们最好的学习伙伴
2.培养数据意识
3.深入了解自己的业务领域
4.拓展自己的知识边界
5.补充专业的知识
`
如何解决90%的问题？10位阿里大牛公布方法
https://mp.weixin.qq.com/s/kX6EsY90hnpSHUUrtk_4aw
https://files.alicdn.com/tpsservice/a3eafb12d315e3363de1e7dfd1daa0b7.pdf
`
世界在变，技术在变，需求在变。
唯一不变的是变化。
面对变化，技术人如何在不确定性的世界中寻找最优解？
查理芒格说：“掌握一定数量的思维模型，能解决这世上90%的问题。”与其在重复的“增、删、改、查”中消耗能量，不如培养举一反三的能力。在不确定的社会中用尽可能小的消耗，找到最优解决途径，做尽可能多的事情，撬动尽可能大的资源。
`
架构师技术图谱，助你早日成为架构师
https://github.com/toutiaoio/awesome-architecture
`
分布式
前端
大数据
存储
微服务
推荐系统
框架
消息队列
编程语言
设计模式
重构
集群
`
《浅谈技术管理》
https://mp.weixin.qq.com/s/j60RAc1rkKNjOWvgbbb02g
`
一、合适的工作
# 敲门砖决定你去哪
简言之就是：优秀的人可以选择工作、反之就只能被安排工作！最直接的表现就是你会发现有很多猎头打电话给你！
# 可持续的职业发展
有点安全经验，找份安全岗工作不难、难的是一份喜欢的且可持续发展的工作，借用一下生涯规划师常用的三叶草模型：能力、兴趣、价值观==>完美职业生涯；兴趣产生快乐，努力产生能力，而价值观帮助你发现热爱的领域，过好人生其实是一种能力。如同谈恋爱一样，你的兴趣决定你喜欢什么类型，能力决定你能搞定哪个妹子，而价值观则帮助你了解谁能与你长久走下去。你是否真的喜欢安全这个行业，而且有能力一直胜任并可以一直成长不被淘汰；我想越是在这种长期稳定的环境下，自驱力越是容易让人跟人之间拉开差距！
# 不断的丰富自己
能力怎么来的！能力的三个核心 = 知识、技能、才干
知识最易习得。技能与知识最大的差别就在于,技能是以是否熟练为判断的，当一门技能被反复操练，就会进一步内化成为才干。才干是自动自发的能力，例如吃饭自然张口，骑单车不用想着保持平衡，收放自如，仿佛与生俱来。
二、技术管理的工作
# 初期梯队搭建
这部分我想分享一些关于管理工作的心得和体会，总结起来就是四步：团队目标-梯队模式-人员配比-招兵买马；展开说篇幅太长，说一些基础的感悟。
1）少恃才放旷 多倾听理解
2) 少事必躬亲 多培养赞扬
3) 少抢功夺利 培养全局观
总结：心态要稳、不卑不亢、不骄不躁
# 中期团队融合
大部分的团队融合会有四个阶段：组建-动荡-融合-产出-(倦怠) ，我认为还有个倦怠期， 而倦怠期优势就是大家都轻车熟路、熟悉信任、配合默契 ，而不足就是太稳定了，大家很熟悉，团队中基本没人离职入职，缺少新鲜事物的刺激，容易责任心下降；所以华为、百度、阿里都有轮岗和末尾淘汰的机制；可以通过一些团队融合课程和沟通技巧解决；当然团队的倦怠期其实可能是管理者的迷茫期，在变化环境中没有想清楚团队的定位跟目标，“鲶鱼效应”不一定非得来自外界的刺激，自我驱动来的会更主动，避免内耗。当然作为技术管理者最重要的需要承上启下、把控各类技术项目的任务拆解、执行监督、技术指导、交付售后等。分享一些融合过程中实际心得：
1）团队建设
2) ‘熔’合为一
3）知人善任
# 后期团队管理
管理自己-管理下属-管理管理，这三个阶段是大多数职场人必经之路；说一些可以复用的共性。
1）多授权和培养
2）预期管理
三、合作共赢
# 三想一思
想想能为部门或公司做什么；
想想能为兄弟或团队做什么；
想想能为自己做什么；
反思复盘一下 还有什么可以提升的？
# 资源争取及共享
在日常管理团队中，要学会更好提炼总结成果汇报给老板；也要学会争取更多的资源和机会，只要对团队有利、公司有利，都是可以争取的。学会资源整合如引进内外部资源作分享，共同学习，让兄弟们感到这样的机会并不是每个团队都有。有一天 我问我的兄弟咱们搬到独立封闭的办公区了、感觉怎么样，他说：我感觉我们团队一直有特权一样！我说 ：这也是你们自己争取的！
# 变化
– 想法的转变：学会换位思考，多思考的用户的需求、行业的痛点 、市场的需求。
– 心态的变化：佛系、多微笑！要成为有能力没脾气的人。
– 工作的担当：凡事有交代,件件有着落,事事有回音。
– 以身作则：以专业服人、知行合一，做好带头示范作用。
总结：路远虽艰，先成就他人、再成就自己、合作共赢！
`
MEGAEASE的远程工作文化
https://coolshell.cn/articles/20765.html
`
以目标结果为导向，而人在哪里工作，是不是坐在身边并不重要。
# 宏观管理
一、努力找到好的人(能独当一面、沟通能力强、具备自驱动)
二、设定共同的目标和使命(上下同欲)
三、倾向使用小团队
# 微观实践
文档驱动
owner文化
目标承诺
自我管理
# 工具支持
开发环境(靠谱的公有云/GitHub/…)
协作工具(IM/Document/Zoom/…)
远程工作并不是目的，但是远程工作会逼迫管理者面对管理的本质问题。远程工作趋向于找到优秀自驱的人才，守护团队的共同目标，并打造精悍高能的团队，并要求我们在需要沟通和协作的地方使用更为科学和有效的手段，在各个环节中提升工作效率，降低组织内耗……你的团队管理模型是否最优，在远程工作下就会一览无余！远程工作只是一个手段，提升管理水平才是真正的目的！
`
在家办公，最大的困惑不是工作方法和工具……
http://blog.sina.com.cn/s/blog_62f256ba0102z5r4.html
`
一、场景锚定效应
1、划出一个物理空间专门用来办公。
2、穿你上班穿的服装。
3、选择平时高效的时间段来工作。
二、干扰源。
每个人面对的干扰源不尽相同，基本原则是有其他成员的（不管是家人还是合租伙伴），多沟通和协商，获得他们的支持和帮助，攘外必先安内嘛；如果是一个人在家办公的，需要更多的自我管理，也就是第三个因素。
三、自我管理技能。
一是精力管理；二是项目管理；三是利用清单。
`
破局：技术视野与规划
http://jartto.wang/2020/03/08/breaking-the-game/
`
1.2019 CTO 发展报告
2.技术团队模型
3.技术视野
4.技能发展与规划
`
技术管理者标准管理模板
https://mp.weixin.qq.com/s/pU3eSWinzGbRdRnfDCMGsA
`
# 看方向
* 向上级明确团队的职责
* 基于职责确定团队的使命、目标
* 把职责、使命向团队成员传达清楚
* 做好团队规划，包括：规模、分工、梯队、资源盘点等
* 建立团队的WIki，包括：职责、使命、目标、团队规划、人员分工、规章制度等
# 管事
* OKR
** 制定团队OKR，对齐公司和部门OKR
** 跟进团队成员的个人OKR制定和进度跟踪
** 跟踪OKR进展，识别高绩效人才
* 技术管理
** 技术评审规范
** 代码风格规范
** 代码开发规范
** 代码管理规范
** CodeReview规范
** 参与技术方向决策，将研发规范、例会等信息明确传达给团队成员并推进
** 组织技术评审、CodeReview
** 制定学习分享机制并切实推行
** 团队所负责维护的系统的周期巡检
** 公司层面基础技术以及成熟开源项目的引入和推进
* 项目管理
** 技术调研文档
** 方案选型文档
** 需求文档
** 系统设计文档
** 系统、模块、功能的设计以及简述
** 参与的研发人员以及分工
** 预估工时
** 预计完成时间
** 关键时间点、里程碑
** 确定会议机制：晨会、周会
** 技术选型
** 技术架构
** 技术难点
** 性能瓶颈
** 上下游系统
** 功能模块
** 技术方案确定
** 根据技术评审的结果预估开发工期并做好关键时间点的把控
** 创建并保持项目文档的更新
** 项目风险管理
** 项目质量管理，包括代码质量把控和监控告警设施的接入
** 协调资源推进项目进展
* 技术产品运营
** 提炼团队项目的公共抽象部分，组件化和平台化
** 组件、技术平台的推广
* 成本管理
** 技术选型时把成本做为重要考量项
** 提升团队资源的利用率
** 关注团队的人力成本和技术成本
** 关注团队的产出价值
* 流程改进
** 定位阻碍研发的流程节点，寻找有效的解决方案
** 寻求有效工具或者方案提升关键流程效率
* 制度建设
** 明确公司和部门的规章制度并推进实行
** 根据团队需要，制定团队规章制度
** 制定SOP，保障下限水准
** 明确团队例会制度
# 管人
* 定期的一对一沟通
** 你所负责业务的完成情况到现在怎么样？目标完成情况怎么样？
** 这段时间自我评价绩效如何？什么原因？
** 你个人有没有什么你觉得我应该知道的？
* 关注团队成员职业规划和能力成长，给与指导和建议
* 关注团队成员工作状态
* 组织团建，提高团队凝聚力
# 管理仪表盘
建立自己的管理仪表盘，关注关键数据
* 系统监控数据（QPS、硬件资源使用率、错误数等）->提前发现系统瓶颈，消除隐患；提高资源利用率，降低成本
* 项目构建报告（单元测试覆盖率报告、代码质量报告、构建失败与成功概况）-> 关注项目研发质量，保障持续交付
* 项目/任务进度->保证项目/任务正常进行
* 业务关键数据指标->关注业务价值，提升团队成员成就感
* OKR进度->关注OKR实现状况，识别高绩效人员
* 团队成员的每日/周的工作状况->关注团队成员状况
`
技术团队的工程师文化：效率与价值
https://mp.weixin.qq.com/s/TY3BpVC6mCPeVTm9rcXBqA
如何打造高效团队？网友：要有家一样的感觉
https://mp.weixin.qq.com/s?__biz=MzA4NTU2MTg3MQ==&mid=2655170331&idx=1&sn=58d43425460f969e70cc59c74431e2ac&scene=21#wechat_redirect
团队空间：敏捷团队的办公室设计
https://mp.weixin.qq.com/s?__biz=MjM5MjY3OTgwMA==&mid=2652464825&idx=1&sn=8c96e15643f8d46615eb0a1c67cf2740&scene=21#wechat_redirect
谈一谈算法工程师的落地能力
https://mp.weixin.qq.com/s/ABBd-vJ2EBB43NFjrz8Cog
`
但可以肯定的是，无论你在哪个公司，一个算法工程师都不太可能只做纯「算法」，不要忘了「工程师」三个字。对于要做产品落地的工程师，搞算法的时间很可能不到10%，其他技术部分可能占据你40%。要增强自己落地能力中的技术水平，除了算法要基础打好，你还需要：
学会数据获取
构建特征
可视化数据
会用服务器
技术是逻辑的艺术，业务也是，所以只搞技术不管业务的，不能算是逻辑能力出众的。
2.业务层面
宏观业务指的是行业的「共性」
微观业务是指不同部门/公司在实践上的不同。
做这个系统的真实需求是什么？
有什么制约因素？
对于机器学习系统，落地时的制约因素主要包括（但不限于）：
* 开发时间。即使项目刚开始，你还不知道要花多久，你也得计划开发时间出来，你计划不出来，领导也会给你设定期限。毕竟做产品不同于做研究，做产品大家都喜欢确定的投入和可预估的汇报。
* 计算资源。因为机器学习系统使用是需要成本的，你得知道用户能承受怎么样的成本或者自己服务器能承受怎样的成本。
* 算法性能。算法落地不同于打kaggle比赛，并没有时间能把性能压榨到极致。只要比预期好些，基本就「先用着再说」了
要在这三个限制因素里面取得微妙的平衡，才能使得产品落地。我刚做数据科学工作时，总喜欢搞算法调优来炫技，但其实压榨算法的边际收益很低，你用一个月把算法准确率从70%提升到80%，可能还不如提前一个月把系统上线使用起来的收益高。
沟通和思维等软实力包括（但不限于）：
* 和客户沟通的能力。听你讲的客户并不一定是算法工程师或者数据科学家，你是否能把自己的方案原理讲清楚？设计到技术的概念，是否能让非技术的听众也能大致理解？
* 思考能力。例如结构化思维和批判性思维。其实有一定套路，只要多加练习就能掌握。推荐书籍有《金字塔原理》、《批判性思维工具》等。
* 推动团队的能力。和个人魅力息息相关。
# 总结
算法工程师的「落地能力」包括技术能力，业务理解，还有软实力。但对自己要求不要太苛刻，就好像你玩游戏时很少能用到每个维度的能力都满分的英雄一样，人的能力是有个频谱的，不可能方方面面都能做得满分，所以不要对自己感到挫败。
就拿我自己说，大家别看我说的头头是道，但是说实话，说了这么多，其实我自己也并不能每个方面都做得好。这个「落地能力频谱」就像是一个打分卡，帮助你从更全面的角度来分析自己的能力频谱。有的人技术不那么精湛，但很懂业务，很会带队，也能使得产品顺利落地；有的人技术满分，但业务和沟通能力欠缺，但配合其他团队成员的优势，也能使得产品顺利落地。
所以，接受自己的不足，尽可能动态平衡自己的能力频谱，总有一日，你能成为具有超强「落地能力」甚至能独当一面的算法工程师。
`