接手一个新项目，面对以下情况，该如何解决:

1 .代码很脏很乱:

冗余度高、
废弃的太多、
编写质量差、
技术栈陈旧松散、
风格百样、
临时性 一次性的hack逻辑、
难以确认哪些代码在生效 以什么方式生效。

2 .leader们不大重视代码质量，只重开发速度和可靠度。

程序员拿代码质量不当回事，或者早已没有能力写出漂亮的代码，各种将就、凑合。

3 .架构水平不够。很多项目拆得不合理，拆完以后，变成九龙治水的局面，一个信息，多处维护，同步负担承重。

4 .迭代速度高，核心项目每周平均4个发布。

5 .各种不合理的要求。

有时候、一期工程和二期工程并行开发……
老板为了抢占市场，不惜一切代价提高迭代速度。
比如某个业务做坏了，有12天的坏数据，修复这个坏数据，依赖不可控的外部接口。
上面下死命令，要求在8小时内修复。
（最后也只能是一个折中方案，上面勉强接受）

6 .加班严重，有同事连续工作38小时。

7 .没有文档或者文档太旧，公司没这习惯，各种迷雾，只可意会不可言传，老员工脑子里的东西，信息不对称严重。

8 .部门壁垒严重，跨团队做项目，异常低效，各种踢皮球、资源不给足、进度滞后。

9 .人员流动很大，每年换掉60%的人。

10 .产品巴不得大而全、又催活如催命。

公司高层在每个时间段，会提出一个主题、若干副题。
产品围绕这些做需求，多个idea互相竞争，抢夺开发和QA资源。
过了阶段，再想做这方面的idea，就难了，不会给你足够多的资源。
所以，产品一抢到资源，就巴不得狠狠地干一票。

11 .业务模型混乱、耦合度高，从来没有整理过，绑架项目设计。

多数产品经理出需求，都只求局部最优，不考虑对整体业务结构的影响。

12 .项目基本靠几个老leader和QA扛着。

13 .项目在赚大钱，对可靠性要求很高。
重构代码，面临巨大内部阻力，特别是QA的阻力。

总之就是:

基础设施差、
coder懒惰且无责任心、
项目不养人（技术类员工发展慢）、
开发速度越来越慢（扩张的无底洞）、
可靠性越来越难保障（如何狂风中的蜡烛）、
监控报警昼夜响个不停，每天提心吊胆、
越来越没有成就感，天天干烂活儿、
整个公司都疲惫不堪

公司目前的应对办法，就是:

1.加工资
2.加人
3.加机器、降低单机利用率
4.加监控报警，人肉不分昼夜盯着，一有动静就去查
5.产品天天去分析数据，导报表，看哪里可能有问题

我看的一份比较好的解答

以上的情况，都遇到过。

典型的一个业务导向的公司，糙猛快的开发习惯，缺乏懂技术通产品，能控场能抵抗业务压力的技术话事人。随着时间流逝，开发无规，代码堆积，人员流动，能力下滑，架构腐化，逐渐走向结构性崩溃的场景：业务压迫带来了贴膏药的代码，膏药代码导致更大的技术压力，人才流失，疲于奔命，然后带来更大的业务压力。就像飞机掉入了失速螺旋，怎么也改不出来。

曾经花了半年时间，带团队花大代价改出过这样的恶性循环，花了大几百个人日全面重构一个有7、8年历史的老系统，代价是自己的当时绩效对外不好看。

所谓善战者无赫赫之功，此之谓也。

前人栽树，后人乘凉。 干这种活，没有识货的老板，是吃力不讨好。

千言万语，凝聚成一句话：全公司要有靠谱的技术管理和技术文化。这是CTO的职责。

给你归纳翻译一下，问题简化为这些：

1.如何提高代码质量？【开发能力】

2.如何提高架构水平？【架构能力】

3.如何控制产品需求的合理性和迭代节奏？【项目管理-需求分析/项目规划】

4.如何降低加班强度？【项目管理-资源管理】

5.如何积累知识库，降低口传心授的依赖？【团队建设-知识库建设】

6.如何提倡团队合作文化？【团队建设-价值观建设/绩效设计】

7.如何培养团队技术梯队，不强依赖几个核心员工？【团队建设-梯队培养】

8.如何避免自有通过QA才能保障产品质量的困境？【开发能力-质量保障】

9.如何提升系统稳定性和可用性？【架构能力】

10.如何通过产品大图整理出清晰的业务模型？【架构能力-产品规划】

11.如何拒绝业务方的不合理需求？【项目管理-需求管理】

12.如何降低人员流失率【团队建设-可惜离职率】

13.如何在飞速发展的业务环境下回答以上问题？【可落地方案】

自顶向下，依次需要解决的点是：

1.价值观建设

a.提倡团队合作。提倡合作？然并卵，谁鸟你，一句现在很忙就把你憋死。作为leader，还是要搞好人际关系，靠刷脸去推合作。

b.提倡敬业和激情。自己先要成为榜样，不过重要的还是看激励政策。

2.绩效设计原则

a.重视拿结果，更重视执行过程。发现、表扬、提拔代码写得好，业务也玩的溜的人。管理不能停留在表面上，要到代码里去。

b.重视个人技术能力，更重视技术传承、培养人。诶，说你呢，没带过人的同学别想加工资，想晋升给我先带3个徒弟出来。

c.重视技术创新。天天重复自己的人，再老资格也要给他敲警钟，该fire就fire。挤出项目的时间余量给有想法的人做点不一样的事；必须要有一支发明家队伍，而不是码农队伍，所以，搞条鲶鱼进去动动风水，会有好处的。

3.产品研发流程

a.流程保护。和产品团队、业务团队磨合出固定的迭代流程和节奏，并能坚持下来，坚决抵抗不合理的需求和节奏，有理有据地向上反馈。

b.产品话语权。一个产品设一个技术owner，要具有对该产品的需求评审，设计评审权，开发人员要参与业务调研/业务分析，影响产品设计，争取产品规划和业务模型的话语权。避免成为单纯的技术资源，疲于奔命。

c.跨部门沟通。提前和产品部门沟通双方的预期和能力，将产品规划和技术规划结合起来考虑，3个月协调一次。

4.团队建设

a.人才梯队建设。高手不能太多，也不能太少。微妙，自己意会，橄榄形社会最有活力。

b.hire and fire。60%流失率，这窟窿！还是先加工资要紧，狠狠加，先把队伍拉起来，才有余力做重构的活。

c.团队文化建设。不管是美国还是中国，哪个总统/主席，都得有个施政口号，让人知道你要干什么，分清敌我。

d.团队技术能力发展。先把人找齐了。。。

5.项目管理

a.敏捷也好，瀑布也要，反正要找个合适自己的项目流程，并严格灵活地执行下去。

b.加强项目复盘环节，code review。

c.维持一个合适的工作松紧度。

d.项目管理的精髓是什么》》》我个人认为是制度化，制度化的坏处其实非常多，但有一条好处，就值得我们采用：那就是有强大的理由能按我安排的时间、我安排的地点来打仗。优秀的pm无一不是时间管理的高手，敢于向试图越过制度胡乱插手的领导说不，这就是项目团队的福音。

6.系统架构

a.与实际需求相关，无非就是提升稳定性，可用性、可维护性、安全性的那些架构招数，譬如SOA、服务治理、中间件、负载均衡、降级等等。一个简单清晰可靠、可快速横向扩展的系统架构是基石。

7.业务架构

a.业务模型重构

b.模块化，插件化设计

c.平台化架构

8.产品质量

a.编程规范

b.设计模式

c.单元测试和自测

d.QA 和 code review

e.故障复盘

9.组织发展

a.知识传承

b.挖掘技术深度和创新意识

c.内部培训和外部培训

d.鼓励创新的机制

写完回顾一下，自己都觉得好笑，有点空列大纲无法落地的感觉，呵呵，实际的困难肯定远远超出预期。要想改变一条船的航向，首先你得有舵手的影响力
（成功资历，直接管理技术团队），其次获取船长（老板）的支持，再次你得真的知道正确的航向（怎么做），接着得到船员的支持（公司其他团队的理解），优化
调动自己的力量（所有开发都认同你的理念，招聘合适的人才），然后还要避开暗礁（别让项目失败），通过一次次的胜利来巩固你的正义。

太他妈的难了，所以很多人都劝你开溜，他们是对的，因为99%的老板都看不懂以上这些文字和它们的价值，但老板还知道加人加工资，说明有希望。~~

问问自己，有这个实力吗，确信，扑上去。

[转]

标签: 产品经理,临时性,leader,程序员,赚大钱