技术和管理

技术和管理简述

对于IT行业，我们看到的一个普遍情况就是没有纯管理，而是技术型管理者。

做技术和研发的，究竟是先广再深，还是先深再广呢？可以看到偏技术型人才基本思路是广度和深度反复迭代的一个螺旋上升的过程。在学校你学习了所有的计算机技术和软件工程的基础知识，这是广度；工作后开始从事一些专门的工作岗位，朝专业化发展，这是深度；而IT新兴技术层出不穷，在某一个专业化方向积累后很容易切入到新的知识和技术领域，这又是广度。

广度往往对应的强烈的学习欲望和兴趣，大量的课外学习，对新知识和技术的高度关注，大量的泛读，这些都是广度积累的重点，所有广度上的知识都是有用的，必将用于到后续深度的拓展。知识面足够的广度才能够支撑专业化深度的拓展，否则在专业化的时候讲感觉举步维艰。

技术型人员最终的价值一定是体现在专业深度上面，不要期望技术人员各方面都是全才，但是他们必须对专业领域有足够的独到见解和创新能力。而技术朝管理转变 的时候往往则不同，技术管理者在专业软件技能上的深入度可能不及技术人员，但是他们需要有足够的宏观建模和架构能力，能够把握大的技术方向和发展趋势；在 这一点的基础上他们需要不断的培养自己沟通，演讲，管理和领导等各方面的软技能。

IT行业不懂技术基本无法做管理，太热衷和沉迷于技术也无法做管理。技术管理者又不同于普通的管理岗位，他们根据强调领导力和教练能力。技术管理者关注的重点应该在团队和产品两个关键点上，即打造一个能够作出优秀产品的团队，或者是为了得到一个成功的产品不断的塑造和凝聚一个团队。技术管理者相信，团队掌握了关键技术并高效协作是打造一个成功产品的基础。

IT项目技术建议书核心内容

第一部分：概述部分

该部分的重点是理解标书，理解项目建设的背景，建设该项目的初衷究竟是什么？需要解决的核心关键问题是什么？基于对项目的理解然后明确项目建设的目标，项目建设的原则，项目本事的定位，项目建设完成后期望达到的效果和解决的问题。项目目标本事又包括了业务目标和系统建设目标，业务目标驱动系统目标。

第二部分：业务解决方案部分

这一章的重点实际为进一步细化项目目标，业务需求就是进一步明确和细化项目的范围。在整理业务需求前需要进一步明确业务目标，根据业务目标来梳理和归类业务需求。找到业务需求的几天大的主线，在细化到具体的业务需求功能点。业务需求梳理清楚后即需要给出业务解决方案。

第三部分：系统解决方案

这部分内容需要和业务解决方案紧密配合，首先是业务目标推动系统建设目标，通过业务需求整理对应到系统的功能架构模型，然后对系统核心功能逐个展开描述。功能架构后需要进一步描述系统的技术架构，关键技术特点，系统的部署架构等内容。系统解决方案还可以专门增加一个系统亮点功能描述。

第四部分：实施方案

实施方法论相当重要，从前面的需求调研，到需求分析，二次开发设计，上线前的数据初始化，系统部署，运维应该有一整套的方法和规范支持。

第五部分：项目管理

应该理解为项目管理方法论，对于IT项目我们的项目管理方法论，最佳实践有哪些？包括了项目计划，项目组织架构，沟通汇报机制，变更管理，风险问题管理，质量管控等都需要提供相应的成熟方法和经验参考。

技术和管理杂谈

风险

我们意识到有风险，但是风险还是转化为问题了。所以有风险意识还不行，还必须将风险转化为行动。对于风险必须关注两个问题，第一是关键的风险是否已经识别出来？第二是对于风险的应对是否有效？最害怕的是关键风险没有被识别出来，最遗憾的是虽然识别了关键风险，但是风险仍然转化为了问题。

一开始可能你并不清楚风险应对是否有效，所以必须去关注和跟踪风险应对的情况。关羽大意失荆州，虽然有修建烽火台的风险应对，但是风险仍然转化为了问题，所以只能说是一种遗憾的事情。

产品

产品的的最终实现要通过多个迭代的项目版本进行。当时做产品还是做项目是必须要回答的问题，项目是阶段目标，而产品才是终极目标。关注产品才可能形成市场和客户导向。因此在做项目过程中随时都应该融入产品意识？

而什么是产品意识？产品意识首先是一种客户意识，要认识到做项目最终仍然是形成产品，而产品的最终作用仍然是使用并为客户带来价值；其次是团队意识，要意识到团队力量才能够最终形成产品，虽然个人只负责了产品的很小一个零件，但是实现过程中仍然要从产品的角度去考虑和设计；最后才是产品的设计意识，要意识到产品设计是一个较为独立的活动和流程，产品设计是从用户的角度来看产品而不是从内部实现机制上来分析产品，这是产品设计之基本。

WBS分解

为什么要分解？分解是我们面对大型事物或问题的一种思维和解决问题方式，通过分解逐步理清楚问题，通过分而治之逐个解决。这是我们谈分解的总体思路，再细化下分解的原因。

1.通过分解进行问题的分析，实现大问题向小问题，大目标向小目标的转化。

2.通过分解体现高内聚，松耦合的组件化思想。最大限度的考虑复用，更好的响应变更。

3.通过分解将串行工作转化为并行工作，减少等待时间，让团队成员有事可做。

4.通过分解将大版本拆分为迭代版本，实现最快速的首版本交付。

要知道分解和集成都会增加额外的工作量，如果不是为了上述目的，就应该尽量减少不必要的分解。前面两点是从技术上和问题解决层面来考虑分解的目的，而后面两点则是从项目管理和计划上来考虑分解的目的。在分解的过程中两者必须要兼顾。

团队

团队和分解密切相关，没有计划和分解就谈不上团队和执行。而团队是项目目标真正的执行者，对于团队的考虑就是通过分解让相关人员都能够很好的胜任各自的工作。所以要做好项目管理，先了解团队成员知识和技能是必须的。如果对团队成员都不足够了解，就很难更好的进行工作和任务的安排，如果多技术不了解，又很难从技术层面去考虑分解工作。

团队的高效和核心竞争力体现在哪里？首先要意识到团队的高效的基础仍然是个人的高效，但是个人的高效并不代表团队一定高效。如果个人的高效都是在为团队最终的目标服务，有很强的目标意识才可能带来团队的高效。团队高效一方面是分解后并行工作中的高效性和按期完成，减少等待和空闲；一方面是集成过程中的顺畅性和高效沟通。

量化

很多工作如预研究等确实很难计划或量化，但是这并不代表我们不应该形成以数据说话的意识。任何事物都不是一开始就能够量化的，但是走的路多了，见识多了自然就慢慢由定性转化为了定量。定性是大方向，而定量则是精细化；定性是全凭经验，而定量则是经验+逻辑；定性是宏观把握，而定量则是精细化控制。

量化的基础是数据，强调数据的基础是关注数据，而关注数据的重点则是可视化。

计划

计划本身就是对项目的预测，如果等所有的事情都明确了再来做计划，那么可能你始终都无法去做计划，当你期待的东西明确后你又发现了新的不明确的东西。因此计划本身就是基于假设下的某种确定性，再简单点说就是如果人员，团队，环境和技术怎么样了？项目团队应该可以完成哪些事情。而假设即是风险，所以计划是基于风险的一种对事物发展趋势的预测。

当你面对一个大的不明确的事物的时候，首要工作仍然是分解，只有通过分解才能够把确定的东西和不确定的东西分离出来。对于确定性的事物可以先行，对于不确定性的可以考虑风险应对和替代方案。当我们面临一个关键技术没有解决的时候，我们往往第一反映是无法做计划，但是我们需要的却是基于假设和风险的计划。比如：

假设关键技术A能够在一周内预研成功和解决，项目应该在6周左右时间完成。如果关键技术在一周内无法解决，我们需要启动替代方案2，当采用替代方案2时候项目在8周左右时间能够完成。这种陈述方式本身就是计划，并且可以看到如果这样描述让我们会根据高度关注风险和不确定性。

范围

我不得不再回顾下教科书的内容，计划是渐进明细的，而范围是一开始就确定的。计划可以渐进明细，但是范围不能蔓延。但是实际的情况往往确实就是项目范围在蔓延，范围完全不变动基本很困难，所以项目管理者根据应该关注范围受控这个概念，范围可能会发生变化，但是一定要受控。

范围通用涉及到两个方面的内容，一个是产品范围，如果产品范围发生变化必然会增加项目范围，所以首先要控制产品范围和用户需求。其次是项目范围，当产品范围没有变化的时候，由于我们采用的过程管理策略同样影响到项目范围。即时产品范围和项目范围都没有变化，如果我们采用的技术实现方案不同，仍然会影响到工作量，而工作量直接影响到进度目标。

我们无法控制范围完全不变化，那就转变思路，尽量让范围的变化尽早的被识别出来并解决掉。即使是资深的需求分析师也无法保证完全能够通过需求规格说明书和原型覆盖用户的所有需求，因此唯一的方法就是短周期迭代，尽早的交付首版本，尽早的获取用户的范围变更信息。

进度

很多时候我们是知道进度会延期，但是却无能为力。由于导致进度延期的原因，涉及到的人，团队环境等因素太多了，导致我们无法快速的作出相应的应对决策。那好吧，还是抓紧时间赶进度吧，连沟通都免了，而最后结果往往确是进度恶化。如果我们只是发现问题，而不去解决问题，那发现问题本身也就没有了意义。进度都知道要延期了，还需要开会浪费时间吗？答案往往是暂停并集体思考和决策比贸然前进更加重要。

从软件开发生命周期来说，软件开发包括了需求，设计，编码，测试等诸多过程。前面需求，设计，编码都没有延期为何测试延期这么多呢？测试应该来背这个责任吗？要知道测试的时间长短首先是跟前面各个阶段的工件质量相关，其次才是和测试人员本身的效率相关。进度延期的根源往往是前面各个阶段不切实际的进度，我们采用可视化项目管理和增量迭代，冒烟测试和每日构建都是为了让前面阶段的进度尽早的可视化。

平衡

平衡是我们在项目管理中谈的比较多的一个词，平衡也是项目经理的一个重要能力。但是平衡仍然是相对的，很多时候我们谈平衡是项目目标驱动的，但是更应该谈平衡是用户满意驱动的。一个项目延期交付2个月，投入增加了30%是否就一定不成功呢？显然不是，因为在这段时间可能是用户驱动增加了一个关键需求和功能，而且也增加了投资，及时晚交付仍然可能是用户满意。

平衡不能牺牲质量，因为质量的一个衡量本身就是用户满意，要意识到其余都可以变化而质量不能变化。很多时候项目失败的原因就是去降低质量，导致了钱也花了，项目也延期了，最后仍然是用户无法满意。