老大，您好：
我们的网站是2008年7月正式开始的，当然前面还有一段时间的准备和调整期。到2009年2月，在历时7个月之后，网站才基本满足您的要求，所以就正式上线了。此后，我们对网站的主要目标也从对功能的开发转为对市场的推广，因此我们技术团队也退居二线，其主要职能也从纯粹的根据设计需求开发功能，转变为根据市场需求调整原来的功能、开发新的功能、对客户和销售的管理、以及对网站进行日常维护等。我从大学毕业到现在，已经在IT技术领域工作了7个年头，您熟悉我的经历，应该知道我有比其他技术人员更多的东西值得总结。现在已经是2009年4月中旬，我想有必要回顾一下我们在2008年7月到2009年2月的这段时间的技术团队的工作情况，作为那些总结的一部分，也为以后工作中的合作和沟通奠定一个更好的基础。
我从一个单纯的技术开发人员，成长为一个带领技术团队的领导人，其中的经历，不可谓不丰富。这么多年下来，我对管理技术团队的诀窍就只有一个，就是事实求是，换一种说法就是善“变”——根据客户不断更新的需求而变，根据团队每个个人而变，根据外部的客观条件而变……而不拘于定式（我会在其他文章里总结我的技术和带团队的方式）。我在2006年开始接触敏捷方法，并且在2007年在一个美国工程师的指导下，用敏捷方法中的极限编程思想，结合中国团队的实际情况，成功的带领团队往前走。可以说，敏捷方法非常符合我本人的性格。最近看了软件工程管理大师Robert C. Martin的著作《Agile Software Development》之后，感想颇多，所以这里想围绕这本书中提出的敏捷开发的4个基本教义来总结我们过去7个月网站开发中的种种冲突、问题以及解决方法。
其实这4个基本教义，我认为也只是敏捷开发专家们从另外一个基本的原理从引申到软件工程管理中的4个范式，这个基本原理就是——实事求是或者善“变”。我们先看看这4个教义（我自己的翻译的，但愿您读起来也觉得通顺才好）：
1. 团队中的每个个人和他们相互之间的沟通和协作远胜任何过程和工具；
2. 一个可以实际工作的成果远胜任何完善的文档；
3. 客户的充分沟通和协作远胜合同的磋商；
4. 与时俱进远胜死抱计划。
虽然您不是技术人员，但是我想您对上面这4句话也不难理解，是不是还觉的这4句话不仅仅适用于IT技术项目领域？我也有同感，所以在总结完我们那7个月的开发过程后，我还想聊聊对我们现在公司管理上的一些建议。现在，让我根据上面的教义逐条和的我们那7个月的部分行为（每天都发生很多事情，我不可能每件事情都记得，也不可能把每件记得的事情都放在这里）进行一一对比，看看我们能从这次总结中得到什么真金白银。您也能找发现：为什么我们能在不长的时间内，用不多的人（大部分都是刚毕业不久），以及低的成本就能完成我们这个规模的网站？
一、团队中的每个个人和他们相互之间的沟通和协作远胜任何过程和工具
问题一：在我们一开始，我建议并且决定用兼职的方式筹建团队（只有我是全职），我的初衷是，大家都有网络，而且部分人都有不错的工作，所以通过兼职如果能够完成网站的开发，可以皆大欢喜，而且可以降低成本。可后来的经历告诉我，我想简单了：面对这样一个复杂的项目，大家都在不同的地方，不能面对面的开发，白天因为工作，不能时时的沟通，导致部分人对其工作要求了解的不清楚，我对他们工作的情况了解的也不清楚，而且在他们因为本身的工作，有时候会耽误其他成员需要的模块的开发……最后计划时间到来的前一个礼拜，经过我没日没夜的奋战，才把基本的原型搭建好——那时对我真是个噩梦——您不是技术人员，对这个原型非常的不满意，也不理解我从基本原型每周叠加需求我们网站的方式，您想看的就是网站最后的样子。
解决一：我们后来召开了会议，结束了兼职的方式。团队所有技术人员全职以后，我们经常在开发周期内，每天早上召开晨会，每周都有周会，保证团队充分的沟通和协调，效果非常好；我对于每个功能的实现，都给予最终合理的界面显示，而非裸页，这样，您也能充分理解我们完成的工作，以此提出下一步新的叠加需求。
总结一：我们这个团队有两种沟通，一种是技术人员之间的沟通，还有一种是技术人员和您的沟通。上面的问题在于兼职的方式导致技术人员之间沟通的不畅，从而导致在开发一个相当复杂系统的时候，不能达到预先设定的结果；另外，在技术人员和非技术人员沟通的时候，非技术人员并不能理解什么是敏捷开发方法，也不知道原型叠加开发到底是什么，他们想看到的就是最后的产品，而我应该去明确您想看到的到底是什么。项目开发的沟通，要充分考虑这两方方面的沟通，而且都要满足这两种沟通。
问题二：在开始选择开发语言或脚本，以及技术架构的时候，团队中有一个老程序员推荐用Spring，Hibernate等Java技术来开发网站，因为这是这个老程序员当前工作中所从事的，而且他很喜欢Spring；而我却反对，我认为应该以PHP（我自己上一个项目是基于EJB3的）为主，另外考虑部分Java技术，甚至以后可以考虑重构的时候用C/C++，另外不用开源的MVC架构，自己搭建框架。因为除了他和我，其他人都是刚毕业的，都只有C语言的基础，开发过部分PHP的页面；另外我们的网站相当复杂，我们那时候谁也不清楚我们最终的模块功能会是怎样，只知道最初的需求，然后实现一个阶段的需求之后，您再看了之后，再考虑下一步的需求，所以需要开发需要充分的灵活性和扩展性。
解决二：最后我们用PHP搭建了自己的简单直观、而且扩展性强的三层架构，在这些架构中，保留了对其他，如Java，C/C++等模块的扩展支持。后来，我们扩展了相当一部分的Java模块，还有一部分Linux Shell的部分。
总结二：团队的第一因素是人，必须以人为本，我们在开发项目的时候，一定要考虑整个团队开发人员的组成情况，如果选择了学习门槛较高或者团队大多数人员都不擅长的框架和技术，那么我们必须要花费一些时间去培训他们，当然某些只有某项技术和框架才能实现的项目除外；另外还要考虑，我们不是一个一次性就能写出需求分析的项目，随着后面需求的不断叠加，我们选择的技术和框架是否能够灵活的拓展和修改，并且对其底层能够可控。对于一个项目使用什么技术和框架，往往是我们最后才考虑的。另外，一个复杂的系统，往往是多种技术和框架的组合，需要考虑很多方面，而且特定技术和框架的应用，不可避免的就是降低了灵活性。当一个项目是长期的，那么就必须意识到以后不断重构的不可避免性，每个当前阶段就集中考虑当前的需求。
二、一个可以实际工作的成果远胜任何完善的文档
问题三：最早，我只用UML和一些文字描述了您的需求，并且形成了粗略的文档，因为您不懂UML，所以我必须给您描述。在给您描述之后，您说我考虑的比您还周到。然而，我们在按照这个文档实现之后，您看到东西之后，往往说这不是您想要的，然后又让我写更详细的文档，并且说我们现在的文档不够多，不够详细……如此反复之后，我们有了一个200多页的文档——这是我在考虑再三后决定先满足您说有文档的需求之后所作的，后来又被我精简到160页。在花了几个礼拜之后，您看到了文档，非常满意，但是我们严格按照这个详细的文档实现系统之后，您又提出很多和文档不符的地方……我们继续原来的重复。我觉得这里有两个原因导致您这么做，一个是您认为文档可以描述清楚您的需求的，我们系统不符合您的需求，是因为文档没有写好；另外一是您太忙，没有仔细去了解和整理这160页所描述的功能，就认同这个文档描述的您要的东西。而我本身是反对越来越多的文档和规定的，最后做出来的东西才是最好的文档。
解决三：后来，在那个160多页的文档之后，我们每隔一段时间，就直接给您看我们实现了的东西，然后再让您说说哪里需要进一步修改、删除或者增加的。对于还没有实现的，我们还是提供粗略的文档，然后在会议上讨论之后，再让美工把页面做出来，让您看是否是您想要的，然后再实现，然后每个阶段在给您检查是否您想要的……虽然还是那种重复，但是这种重复已经从非理性的噩梦变成了理性的开发过程——最后我们的网站上线了，皆大欢喜。
总结三：其实，所谓客户，不一定是公司的客户，更本质的定义：客户其实就是提出需求的人。所以您就是客户——一个不懂技术的客户。任何人都不能把复杂的系统一开始就把细节100%的想仔细，而且后面不会有调整。所以，开始的设计文档，应该比较粗略的描述了客户的需求，然后再逐步叠加的实现中，让开发人员和客户进行充分的沟通，让客户不断的检查、并且修正可以看到的成果，这样才是一种比较实际的方式。换一个角度来说，作为客户，您既然强烈需要一个很详细的文档，那么为了这个项目，即使这个文档并不促进开发，那么我们也要专心准备这个文档。我原来经历过一个北美的客户认为，一个外包公司是否有详细的设计文档，就能决定其是否专业——也就决定了我们是否可以拿到这个项目，在这种情况下，我们用了2个月准备了一个详尽的文档，然后我们拿到了这个项目……。
就我的经验而言，再详尽的文档，到最后都无法维持和项目的同步，任何项目都是随着时间、环境和人而变的。所以，一旦一个详尽的文档制定出来，在开发实现过程中和完成后，就都不要维护了，一方面维护的代价很大，另一方面，开发过程中和完成后的项目本身就是最好的文档。
三、客户的充分沟通和协作远胜合同的磋商
在上面的定义中，您已经作为客户成为这个团队的一员了。
问题四：我们在那7个月，很频繁的发生一系列类似的事情，比如，您提了一个新的需求，我们按照这个需求做了，结果原来您发现我们做的不是您的新的需求；又比如，您提了新的需求，但是我们发现这个新的需求从业务逻辑上都走不通，结果我们花费了一些精力才能向您证明某些东西不可行……最后作为客户，您和开发人员逐渐的走向对立——有些东西即使不合理，您也让我们必须做；有些东西即使合理，我们也做的很勉强。另外，您每天只有很少的时间和团队在一起，所以对开发的进展，业务的深度等方面的了解都不够深入。
解决四：我们加强了相互了解和沟通，我会主动去了解您提出新需求的背后的出发点，然后考虑应该是和您讨论可行性还是讨论如何实现。您后来提的新的需求和想法，我们都先进行详细的研究和分析，并且把分析的结果拿给您看，然后让您自己去否定或者去改变，如果没有问题，我们才开始开发，最后通过开发的成果，您再提出新的需求或者改进的意见。后来，您每周都至少保证能参加我们的周会，去了解团队的进度和发生的事情。
总结四：任何沟通的双方，如果不去试图理解对方，也不认真、仔细的去考虑对方的需求，那么这种沟通是场噩梦，往往就算一方知道是错的，还是顾及脸面，去坚持错误的。另一方面，如果对一件事情或头脑闪过的新主意，只有初步和粗略的想法，没有深层次的去思考是否可行，以及如何贯彻，就拿亲率的拿着这个想法让别人去实现，这是一种对人和对事情都不认真负责的态度。当双方沟通的时候，就要同时考虑前面两个方面，而且要包容对方，控制自己的情绪，就事论事。沟通，也是协助对方了解自己的一个过程。
四、与时俱进远胜死守计划
问题五：您在我们开始阶段处在艰苦的开发的时候，就多次不耐烦并且失望的问我有没有对我们网站多个阶段的详细计划，我们以后会用多少个服务器，准备支持多少个客户，每个功能几月几日能够完成……对这些问题，我非常反感，我反问您现在我们连网站应该有哪些功能也没有明确（包括您那时候都不能明确，也都是每周来提一些新的需求），您的商务计划我也没有看到，而且我们根本不知道网站出来以后，我们的市场拓展是如何规划的，是专注于一个城市，还是一个区域等，试问，谁能给您清晰的答案，告诉您我们在6个月后，将会有几台服务器，分别是什么配置，他们可以支持多少用户，几十个功能都能分别告诉您实现的准确日期……我能告诉您近几周的精确计划和比较粗略的2～3个月的规划。但您不满意，对我发了几次这样的牢骚，但我还是坚持我的做法。
解决五：我能理解作为销售人员出身的您，并不能明白实际规划和开发的整个有条不紊的过程，也不能明白对一个极度依赖外部环境的系统做精确预测的困难性和无必要性（销售人员的工作往往是根据企业制定的月度、季度、年度等单位的销售任务资金额度来完成的，而IT项目的开发没有一个统一的额度）。当我们多次就这个问题沟通之后，我还是坚持团队的循序渐进和实事求是。终于，随着您和我们开发团队在一起时间的加长，您逐渐了解到了那个过程，并且逐渐提出了越来越符合实际并且有益的要求和建议。
总结五：外部的环境在变，市场在变，客户的需求也在变，我们开发人员只能在一个很短的时间内（这个时间极限编程推荐是2周，我在2007年带团队的时候，也是两周），明确一个不太会变的需求，然后实现之；之后客户再给予这个实现，可以看的更远一步，提出新的需求，或者修改原来的需求——这是一个比较切实的过程。制定计划的时候，应该把当前的计划制定的明确和详细，后面的计划就逐渐的粗略，给变化的需求留有余地。
其实在《Agile Software Development》中，对敏捷方法及其各种实现的方式，提供了很多规则可以参考。国内我也见过一些人拿着这些东西作为教条来死板的执行，然后失败，然后说这些方法不行——其实他们一开始就没有理解敏捷方法的初衷，并且用和敏捷方法背离的方式去使用敏捷方法（我会写一篇文章说说国内IT技术圈的一些乱象，名字还没有想好）。我认为，敏捷方法的实质就是然让我们明白IT项目开中如何实事求是，如何与时俱进，然后在根据实际客观的条件，灵活的应用敏捷方法所提供和建议的各种规则、方法，甚至也可以加入自己的技巧，再结合自己的经验，低成本、高效率、高质量的去完成项目。其实这不仅在开发IT项目是如此，在做任何事情的时候，都理应如此。引申到我们创业，我们管理公司，也是如此。举个例子，我们是根据公司的实际发展需要来决定公司需要什么，还是拿别人现成的公司框架来硬套我们的公司——别人有，我们没有的就要硬加进去……
实事求是的关键在于那个最终的目标是什么……
此致
敬礼
小弟
2009年4月15日
扫一扫
133
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
