接上文创业期的软件开发管理(一)

软件队伍

技术主管

　　决策者对软件开发可能一知半解，他们会想当然地认为软件开发过程比较“简单”：从市场上找一个技术带头人，然后组建一个开发队伍，其余的事就是下达需求，你给我开发出软件来。这对于技术主管来讲面临的局面会非常尴尬，即需要向领导非常困难地解释一些他们根本不能理解的问题。又需要承担起巨大的压力。“先天不足”的需求也是一个非常大的挑战，因为创业团队根本没有一个成型的现在可操作的流程可以让技术主管去参考。这需要技术主管有非常好的市场前瞻性，同时也要有非常好的架构延展性。

　　创业期，团队知道要做什么，也知道要怎么做。然而一旦细化下去之后，问题会非常的多，非常的复杂。要使这些业务流程条理化，清晰化，还需要技术主管进行指导。缺少指导的技术实现会远低于预期效果，而且软件系统可能存在严重的延展性不足。

　　技术主管要面临的另一个辣手的问题是，是来自上层的非软件开发领域的管理方式的影响。开明的老板不会过多的关注技术主管的管理方式，但在管理一支新军时，战斗力可能会比较低，在一段时间过后，上层可能表示不满，他们可能以一种更为自信的态势来插足软件开发的管理。这时，技术主管最好不要过多地去计较，我们不排斥一种新的管理方式，但需要技术主管密切观察这种管理方式，可以吸纳一些好的方法，但也要及时发现负面影响。这不是一天两天能发觉的，但越早越好。尽早树立起自己对管理的话语权，否则技术主管只得背负起“能力有限”的评价。

　　还有一件事情是技术主管无法把控的，那就是不断膨胀的细化的需求，老总下达的需求只是方向性和概括性的。即使你做了比较细致的文档，他也只是扫一眼而已，因为他不懂这玩意；其次他也没有精力和耐心；再次，他认为这是技术主管应该把好的关。对老总来讲最好的方式是让他看到软件原形！

　　由于是创业阶段，很多东西都没有可借鉴性，随着一个个原形的出现，超出预期的时间会累加的越来越多，这会让上层感到不安，更为可怕的是，为了实现最终目标，决策层在实现 “路径”上争论不休，使得需求忽左忽右，时间的浪费也是很可观的。这样企业不得不在指定的期限内精简功能集，但还是有可能会造成延期的情形。

　　在这种紧迫感的驱动下，软件的管理可谓是一种挑战，因为我们可能忽视软件的“质量”，即使临时渡过了难关，后期也可能会有很大的维护工作去做。甚至很多设计都需要推倒重来。所以技术主管的工作将任重道远。

需求文档

　　需求文档对于创业阶段来讲是一种挑战。不断变化的需求及没有细化的需求，使得你不能够在开发阶段拥有一份完整的相对稳定的需求文档版本。如果按照规范的文档来书写需求文档，那将是一件相当痛苦的事情。此时最好不要用正规的诸如Word之类的文档格式来存储，我们需要一个可以灵活组织内容，变更内容的工具象UML建模工具，MindManager等都是不借的选择。

　　需求文档的整理需要开发团队中的大多数人员同时进行，技术主管会将需求分成几大块，由不同的开发人员去主导。不过有一件另人沮丧的事情，这些开发人员做程序没有问题，做设计也没有问题，理解你要做什么也没有问题，帮助你规范业务流程也没有问题。有问题的是，他们可能不善于表述！由于专业性的不足，及以时间紧迫为借口很有可能他们写的需求文档形同虚设。虽然如此，他们中的部分人还是希望得到这方面的锻炼的。此时最重要的产物不是他们文档上写下来的，而是通过交流大家了解到实际的需求情况。

　　技术主管有必要对核心业务流程进行详细的阐述，使其清晰与明确，对于其它简单需求或相对独立的附属需求则可以宽容对待，不需要严格的文档约束，也没有办法和精力去使全部的需求文档内容详尽。

软件设计

　　在创业阶段，拿ISO的标准来规范现有的软件开发流程就象在开玩笑一样。但80-20原则还是执行的倒是非常的透彻。我们必须相信开发团队中的每一个人的能力，我们必须充分放权以给他们充分的发挥。团队中的每一个人都需要独挡一面。我们假定每一个人都有能力处理在开发中遇到的细小问题。因为我们分配的任务是按需求一大块一大块的分配的。每个人都是设计的主导者，也是代码的实现者。在这样的情况下，我们去寻找规范和自由的平衡点真的不是一件容易的事。这里就应用一下80-20原则：

　　我们重点关注20%的需求的设计，这20%是业务的核心，其余的80%是辅助或次要的。我们不是只对20%的需求进行设计，而是要对100%的需求进行设计，只是对核心业务要格外关注而已。

　　每个设计用20%的时间书写文档，用80%的时间讨论问题。

　　文档的内容为规范性文档所要求的内容的20%，其余80%不需要。

　　另外需要接受下面的事实：

一、是所有这些设计中只有20%是优秀的，80%是有“缺陷”的。而这些有缺陷的设计主要是指：

1、 缺少延展性

2、 设计过于理想，有些可能根本用不到

3、 实现方法不是最优的。

二、80%的设计是可以工作的，即使那些有“缺陷”的设计也是可以工作的，他们可能直接被应用到编码中去！只有20%的设计必须重新设计的。

三、设计文档并不能很好的指导别人进行编码，而只能指导设计者自己去编码。有下面的原因：

1、 设计文档不完整

2、 开必团队中的职责划分没有那么明细，没有专门的编码人员和专门的设计人员。

3、 不同组员之间的设计思想及设计习惯的不同，使得他很难接受别人的设计。这是新团队缺少磨合造成的。

　　技术主管必须在设计环节严格把关，但不要拘束于形式，只要透彻的明白设计者的思想即可，否则今后苦果不断。设计的产出其实有很多的缺陷，但这些缺陷是可以容忍的。技术主管完全可以让架构师设计好所有东西，然后再去编写代码，这样设计会浑然一体。职责也明确，但会有下面的问题：

一、我们有少数的特种部队，而不是大量的正规军。

二、架构师在设计时，其它人做什么呢？

三、每个人都有表现欲，且他们能够做事情，只是经历上可能没有你丰富。他们也希望在这种环境中成长，这也是最好的成长环境。

四、我们的时间还是少得可怜！

五、我们希望团队中的每个人都有能力带领一支部队。

六、我们需要彼此了解每个人，取其精华，去其糟粕，最后形成我们的共识。

　　对于有缺陷的设计，技术主管可通过团队会议来巧妙解决，但不是所有的问题都会令你满意，只要不是本质上的问题，还是可以继续的。这里面有很多“缺陷”是个人的习惯、经历、性格等形成的，对于这些“缺陷”在创业阶段需要有足够的“包容”心。

未完待续……