虽然有些重叠，但其实PM 和架构师的职责还是能够清晰区分的：
PM 主要职责在保证项目的进度，特别是对于一些为期数月 乃至数年、涉及人员众多的大项目。。PM 侧重管理团队、组织协调、任务分解、长期规划，他可能不需要懂很多专业技术。 也不需要很多财务知识，但是需要保证项目的顺利交付。
不同行业、公司、部门 可能对PM 要求不一样，比如有的需要参与实施，有的是需要参与设计，有的需要参与业务需求。
pm 可能也需要带团队，但不需要太多。更需要管理客户，让客户满意是PM 的关键。他也需要管理方方面面， 软件架构师是专注于技术方面，但是也会有 权责的重叠。
架构师侧重解决技术问题。要求是技术方面的有足够的深度，当然也要有广度。
但是对于小公司而言，特指技术团队人数小于50人，其实没必要区分那么细，那么 PM 也就是架构师，也是负责人。要考虑全局，考虑技术的方方面面，要技术上独当一面。
还有各种称谓，什么 PM、架构师、CTO、技术负责人、产品总结、交付经理， 也好， 其实都只是个头衔，
因为小公司甚至不需要项目的概念， 只需要持续不断的开发新需求，持续不断的升级优化，提高性能、用户体验，维护客户即可。
小软件公司 其实真的不适合设置PM的岗位，因为大项目比较少，大都是 技术性的工作，所以， 小公司就一个技术负责人即可， 他关键是带领好技术团队，尽量不要走弯路，被忽悠，带偏了。 无须PM、CTO、产品总监这样的岗位了。
带领好技术团队，涉及一些团队管理，但是其实一般而言，团队管理容易做，因为 你是上级 掌握 绩效、发工资的权力、甚至下属的留存， 下属能不听你话？ 但是上级至少需要给中层leader一定权力啊，要懂得放权啊
那么，怎么做呢？
如果我是技术leader，给我适当的权力，我一定要把控好下面几点：
技术框架
牛B的底层的技术框架很重要，它就是开发框架的基底。 我们不一定要自己重写写一个，但是一定是开发效率最高的，它应当能够避免很多低级bug，避免很多重复开发的工作的框架。
他 需要尽量考虑高可用性（availability），高可扩展性（scalability），高性能（performance），可拓展性（extendability）； 同时 最好是容易入手、容易维护， 但是这个是次要的，不做强求。。
当然，这个可能需要不断打磨，需要更新，研究前沿科技，。 但同时应当保持谨慎，要平衡成本和利益。做适当权衡和取舍， 不能过于激进。
要研究 试用最新技术，来提高效率…
要致力于 简单的 零bug，消除一切技术债务，怪味道… 不断的封装，提炼出 统一的写法， 不写重复代码… 提高内聚，降低耦合
这些个主要是 架构师的个人能力。
主导技术
包括技术选型，一定是技术负责人完成的，他一定要很熟悉，技术也有难有易， 很多技术其实还是有一定的使用门槛的。
你让一个初出茅庐的涉世未深的没有很多开发经验的小伙子使用一个新的技术框架，或者让它修改某个基础的涉及很多项目代码的配置， 你放心吗？
所以说， 关键的技术，很有难点的技术， 不能放手。
一定要让非常靠谱的人把持。
制定和完善技术规范
统一命名方式，不断新增 命名规则，统一 术语的使用… 新增 约定俗成… 完善规则制度…
注重代码质量，效率提升到极致
技术规范也不是一成不变的，它需要不断丰富、完善，简化。
同时最好让它容易遵守，容易实践
团队建设
稳健的、高效的团队，离不开高级人才，密不可分，骁勇善战的、指哪打哪。
团队建设 包括很多方面，比如人员的招聘、 磨合、工作安排、沟通管理、留存。
首先是 不断的招聘，找到最合适的人选。
有的人很low，通过几天、周的沟通就可以发现其能力的深浅，但是有的不是，
但是辨别是不是真正的人才很难，因此我们需要不断的考察成员的能力，定期做测试，给与适当的分工。
最好是像军人一样的机密作战。
内部应当建立好信任关系。具体怎么做呢？ 如下
快速入手
公共方法的提炼… 破除一切 不合理…
打造技术知识库，业务知识库， 持续 上升发展…
提高 代码可读性，一看就懂，尽量 低代码，可维护性，让新人快速入手
快速让新人融入团队， 熟悉公司流程、规则制度。有的公司有培训，有的公司坑得一批，丝毫没有培训。但是大部分公司的培训都是随便搞搞，虽然有2天的培训时间，但是也是形式主义，讲一下没用的公司文化，就是说 “努力奋斗、 拼搏进取” —— 喊这些口号， 真的有用吗？ 大家早已经麻木了好不好，很多时候，根本不是大家不努力， 不进取，而是扯皮的事情太多了， 效率被。
应当极力的减少团队的磨合时间。
计划、安排
涉及很多人的工作的时候， 他的工作怎么安排 才能够相互完成有效合作 是 需要 花很多时间 好好想想的。 他的工作怎么考察？
工作质量如何衡量？是leader需要关注的。这个其实是团队管理的范围，但是它很重要，这里单独拿出来说明。
当一个人成为了团队领导的时候，它就需要对团队的成员负责，对他们的工作成果负责，它的。
要有亲和力，但是也要有权威。
当外界需要做一个事情的时候， 绝对应该是首先找leader ， 而不是说，名义上的leader，其实啥事管不了，啥事不知道，然后说你去找xx。推卸责任，甩锅的事情不应该出现。
管理一词其实太宽泛， 应当减少这种词语的使用。 作为 负责人 至少要有 奖罚的 权力。 监督、问询的权力。
给他权力，出了问题， 他负责， 谁让它是负责人。
不那么扁平的组织架构
这个涉及到 公司的组织架构， 虽然不能左右，但是如果公司创始人能够意识到就最好了。
经常听到扁平化组织结构，这个是个好概念，但是真正做好的有几家？
看到很多公司就是一个人管理十几个人、甚至几十个人，都向他汇报，这个就是扁平化组织结构？ 我很怀疑，一个上级他时间精力管这么多人，他能管理这么细？
其实我觉得，员工直接适当的层级，还是非常有必要的，一般一个人最好 最多管理不超过7个人，多了，就应该下面细分团队了。 就是说一个L1级别人员 管理 N个 L2 级别人员，一个L2 管理 N个 L3 级别人员，
但是L1 级别人员， 不应当操心 L3级别人员的任何工作内容，过问都不需要，也不应该..
从下到上的沟通路线也是如此， L3 一般情况下应当只和L2 做沟通，比如汇报工作等，但不 越过L2 和L1 沟通。
人人生而平等，只是一个理想，现实中不平等的事情太多了。
良好的技术氛围、互帮互助
大部分技术人都有向上爬的期望，都想学习更多，都得到快速的成长，但是奈何很多知识点晦涩难懂或者本身涉及很多方面难以快速搞懂，这个时候如果有人这方面指导，那么最好不过。 公司经常有培训、每个人都能得到最大的成长， 是我一直以来的理想。
但是呢，应该给与培训者一定的物质奖励，或者其他人也参与无保留的分享。互帮互助才能维系感情，不可能是单方面付出。形成一个氛围，每周至少一次的技术讲解。
团队成员间彼此赋能，当然，培训可以跨部门，也可以同部门，最好有录制，要有质量。最好能够技术互补，相互帮助成长
岗位分配、分工合理
这个其实也很关键， 避免出现职责不明确，甚至 冲突。 这个是应该极力避免的。
岗位的设置需要仔细考虑。
不要搞一些莫须有的岗位，
在其位谋其政，每个人的能力恰当，工作内容
团队合作
团队合作 其实是个大话题，和前面的也有很多重复，但是这里仍然拉出来讲，因为它很重要。
它涉及很多方方面面。关键是：
注重培训，注重分享，… 错误分类总结… … 一个人踩过的坑，浪费了大量时间，都分享出来， 其他人应该能够吸取经验教训，绝对避免 反复踩坑， 特别是对于那种经常遇到的、很容易犯的错误。
凝聚成一股绳，共同的奋斗目标，一起努力
有话直说，不要隐藏太多秘密
前途光明
避免工资倒挂
劣币驱逐良币，
老油条 阻挡新人上位
不专业的人挡道。
合作效率… 发挥 团队合作，化学反应… 个人的主观能动性 创造力
良好的沟通、坦诚相见
初级人员往往害怕沟通，害怕分享，这个其实存在误区。
人员的合作，特别是人多的时候，虽然应该尽量避免各种沟通，
但是一般而言，沟通还是必不可少的。只不过是 多和少的问题。
沟通的 管理， 其实也是大话题
怎么样相互之间沟通无任何障碍、？
怎么建立流畅的沟通机制？
可以每天中午一起吃饭
定期沟通，关心 下级的成长。 所有的员工都有了巨大的成长，害怕公司不会迅速发展吗？
害怕员工都有了巨大的成长就走吗？ 那是公司没有能力留住他们， 那也只能说明公司做的不够。
避免 夸夸其谈、吹马拍须的人。
提高沟通效率，不惊群，炸群… 研究如何提高效率…
重视不同的意见
需要重视反对的声音
反对的声音 往往不敢表达，但是如果别人意见表达了， 你做为领导 却淡淡的忽视，
那么 ， 恐怕少了很好的 改进的机会。。
应该给他一个激励， 让他提出解决方案，完善他的设计，让他开始进行改进。
管理冲突
小团队管理靠情商，大团队管理靠制度，因为在一个人数很少的团队中，项目成员其实更加希望的环境是一个人情味十足，同甘苦共患难的团伙氛围，而随着团队人数的增多变成“团队”的时候往往会变得“人多是非多”，而且团队成员步伐和频道难以统一，这个时候就需要使用和依赖各项制度和规则来介入了。
意见不一致的时候，冲突在所难免。如果是上级对下级，那么可能就是上级说了算，但如果是平级，那么就 谁也难说服谁了。
管理 冲突、不一致的意见、谁的为准？ 需要好好考虑。 不是谁是老员工就听谁的，而是要讲道理、有逻辑，分析合理通顺。
离职管理
某员工走了，应当做好管理，避免留下大坑。 一定做好交接工作。
这都需要监督、跟踪..
绝不能让某一个人的走，让他的代码无人理解，或不好理解，然后让很多人维护，然后还维护不了，造成很大bug。
不管他是不是关键开发人员。
规章、制度、流程
这个很重要，必须单独出一个章节。
良好的流程、才能快速行动
专注于工作，不会其他琐事分心
需求 澄清后，需要一个反 串讲，让开发者自己说出来，这样才能表明，他理解了怎么做… 然后 对一遍…
每个人都应该对其专职负责的部分模块非常熟悉， 它应该能够快速的说清楚其中的流程、逻辑道理。要做到通透的理解。
职责分明、不相互扯淡甩锅
每个人都自己应该是高要求，而不是随便搞搞。
做好规范，设定基准，才能够开始进行考核，有了比较和考核，然后才能评估绩效。
合理化、规范化，而不是形式主义
逐步 形成 各种标准，完善 流程
小团队管理靠情商，大团队管理靠制度。 团队想要发展壮大，一定离不开规章制度的完善。
高层人 高级工作。 如果一个公司发展到一个高级的阶段，就不应该总是遇到低级的错误。
低级的错误应该可以通过某些技术的检查等 非常低成本就能够检查出来。 而不是。
敏捷开发
其实属于团队管理，但它很重要，必须单独拿出来
敏捷开发 绝对是好东西，但是 很多团队总是实行过程中 就变味了。任何事情都是 说得容易做起来难。
这个其实关键还是在于leader 对敏捷开发的理解程度了。
我曾经仔细看过相关书籍，当我看第一遍的时候觉得泛泛而谈，当我看第二遍的时候觉得收获满满，当我看第三遍的时候，觉得相当有道理，那些前人真太有智慧了。
但是，很多公司做不来。why？
敏捷开发，敏捷团队，极限编程，冲刺，
敏捷团队，坐在一起，紧密作战…
极度的重视技术
软件虽然比不上原子弹，但是还是有一定技术含量的。而且呢，软件也可以做得非常复杂，非常庞大，这个时候就涉及很多各种各样的技术了。
但是软件不同于原子弹， 对技术没有硬性要求，很多软件，不需要特定的框架也能够跑起来，能运行，但性能就差别很大了。
简单来说， 技术含量越高，那么自动化程度越好，机器运转效率越高，就越能够提供生产力，降低成本。
技术公司不重视技术就像金融公司不重视经济一样，不敢想象。
现代的开发人员的能力素质也是差别巨大，参差不齐，一个公司的开发人员，是他们的质量的保证，开发得狗屎一样的代码，测试人员怎么测试都还是臭烘烘，坏气味满天飞。产品经理怎么设计都是难以理解。
这样的产品能卖好价钱吗？ 实施人员去客户现场安装部署也是很痛苦，可能已经发布了，到了线上，还是漏洞百出。
这样的产品，客户能够满意吗？
君不见 阿里的程序员是何其高的地位，产品经理、PM这种虚职都完全靠边站。 正因为如此，阿里的技术才能够独步中国，横行世界。
重视 设计
前期设计好，后期开发工作量小，然后bug 少， 相当于是磨刀不误砍柴工， 是十分划算的工作开销。
业务逻辑的实现很重要，但需要事先设计好，否则容易留一堆问题给别人。代码的烂摊子是 巨大的负担，是公司 技术负债， 可能会让公司一蹶不振， 业务无法扩展， 更难以发展壮大。。
控制离职率
这个一般不算是大话题，因为很多公司都这样。但我认为其实它很关键，所以单独拿出来一讲。
其实我认为 除去说 现在年轻人的浮躁，行业的不稳定，还有一点很重要就是，公司出了问题。
但我说，离职率高的公司，一定是本身也有各种很大的问题。
为什么留不住人，是值得好好讨论的话题。
如果我是leader，一定要稳定住团队。让它保留公司的继承。
同时，它一定是一个leader 的 硬性的考核指标。
如果说一个leader 带领一个团队，一直没什么发展，人员来了就走，一天就走、3天就走、一周就走，一个月、两个月、半年就走，不停走走来来，公司一直半死不活，产品部署到了客户，还一直各种线上问题，
那么谁的问题？ 那么一定是 他没有带好团队。
我不是说离职率越低越好，因为公司也需要保持一定的活力，但是绝对不能太高。
最后的小结
看过很多的博客、视频， 跟过很多的大佬、大牛、大侠，却仍然做不好技术，不会 。 喝过很多鸡汤，却仍然只是市井小民。 总之，技术负责人应当明白并实践 精益管理、知道向上管理、清楚向下管理。 懂自我驱动。学习能力。。。
