三五个人十来条枪 如何走出软件作坊成为开发正规军

差不多有半年没有写文章了。这段时间比较忙。忙得自己都不知道自己在忙什么今天上网突然看见一片文章觉得写得很好就抄录下来了。如果原作者看见请谅解大家从各个开发语言的优缺点和适用领域，一直讨论到设计模式、框架、重构、单元测试，乃至敏捷编程，最后都讨论到了软件开发过程管理，甚至都谈到了盈利模式和中国软件的悲哀。最后不了了之，都觉得改善中国内地现在的软件生产状况不可能。为什么呢？我重新把这几天大家的讨论留言翻了一遍，发现大家的软件团队都存在着这样一种普遍现象 1大部分人所在的公司，开发人员仅3-5人，多的在10人。别看就这几条枪，还从售前支持，软件开发，测试、打包发布、文档编写、实施安装、培训、技术支持都做。这还不算什么，而且几乎是一个人负责一个产品或一个项目，一个人从头跟到尾，而且负责多个客户的维护工作。这还不算什么，而且随时老板会找来八竿子打不着的新活，要的还挺紧，突然要开发，打乱了所有的计划，最后都懒的按计划行事，每天撞钟，老板有事就吩咐，没事就上网，还不让听歌，当然更不让打游戏。甚至还不让看技术书籍，呵斥不干工作。只能上网装作在工作。 2老板和员工互相斗智斗勇，在年终奖、报销、出差、平时福利上啊，都明争暗斗。老板卡的紧，员工就在项目和产品上下药，还不知道是谁占了谁便宜，谁给谁打了工。 3员工一边在刻苦钻研各种开发工具，阅读源代码，学习做DEMO例子，阅读UML、设计模式、单元测试、敏捷编程等等，一边却懒的修改现在公司的产品，有问题就打补丁，客户不嚷嚷就懒的修改，代码不优化，界面不友好，架构没架构，代码不封装但是，在讨论中，我时时都强烈感觉到，大家是想把产品开发好，把开发过程管理的井井有条，但是都心有余而力不足。阅读了N多软件工程的书籍，从重型方法到轻型方法都阅读了，但都无法把现在的开发状态一点点扭转好。许多人想闹革命，把现在这些产品和团队都砸塌，然后重新来过，但这只是梦想，说说而已。只能希冀下一次跳槽，能找到一个好的公司，把自己平生所学全部发挥出来，但这好像也只是梦想，因为交流了一下，大家彼此的境况基本相同。一些极端主义者自己开了公司，才发现不持家不知道油盐贵，现在自己和手下变成了老板和员工的关系，走了过去的老路。更有一些极端主义者辞职，自己做软件，最后由于生活拮据或做做发现这个软件没什么意义，就丢弃了自己的梦想，随便找一家公司开始沉默撞钟。一些聪明的家伙，有的入了外企，有的进了大的网游公司，有的进了外包公司，有的进了大网站公司，都是讲究大规模开发的公司，希望能找到一条中国式团队开发产品保证之路作为小软件公司，我们真的无能为力了么？我们真的成为炮灰了么？但是，中国软件行业大部分都是这样的公司。从每年的CSDN的程序员调查都可以看到，中国软件公司大部分都保持在这种开发团队规模，开发人员大部分都在毕业1-3年。我们是在等待时间让人变得成熟么？我们是在等待时间让人变得技术综合实力增强么？依笔者看，作为中国软件群体最大的小软件公司，需要的不是UML/RUP/CMM这些重型方法，不是前几年大家关注的小组开发方法，也不是敏捷编程这样的结对方法，我们都无法有这样的资源实现这样的方法。但是，想想，星星之火可以燎原。红军能从爬雪山过草地起家，最后解放全中国。我们就没有方法？那我们就需要想，就我们目前能拥有的权力和资源，我们如何一点点改进。我们需要的是从游击队到兄弟连，从兄弟连到正规军的方法。我们现在还处于游击队，一个队长领了一帮游兵散勇，有的人甚至没有枪还背着大刀，有的人还没杀过鬼子。首先，要把我们自己变成兄弟连。我常常观看国际著名的CS战队的比赛录像，他们配合的多好啊。如果他们都单兵作战，那么早就死翘翘了。这和咱们的软件开发多么相像。我们多么神往这种默契的配合，打的多么流畅。我们要的就是这个。他们也不几个人么。那让我们来分析分析吧。我们想好好专职的开发软件，但我们的时间都被实施安装、培训、技术支持占去了。为什么我们要做这些？是因为我们软件没有操作说明，其他部门人都不会用。而且我们也没有培训机制，其他部门人更不会用。而且我们的软件不稳定，其他部门人都拒绝实施。由于我们软件不稳定，老出问题，出了问题其他部门人也帮不上忙，只能我们自己去做技术支持。从以上来看，主要矛盾就是在：操作说明、培训机制、稳定性。如何保证这三点。而且从以上来分析，稳定性是最重要的。不稳定，你即使有操作说明和培训机制，其他部门人都躲着实施，谁想去客户那里尴尬丢脸挨骂呀。所以，其他部门人会找各种理由向老板告开发部的状，以躲避实施，说软件太烂，根本无法拿出去。这也就是开发部往往和其他部门关系都不好，开发人员老抱怨自己就闷头辛苦开发解决问题，没有人说好，却被奸人陷害。天长日久，积怨颇深。其实说起来，根源还在开发部自己这里。如何保证稳定性？大家第一想到的就是招测试人员。当然，一些公司的老板是拒绝养测试人员的。另外，如果你只想到招测试人员，其他方法不配合测试人员，即使有了测试人员，软件稳定性仍然不会有提高。所以，有一些工作，是不管有没有测试人员，都必须是我们开发人员要做的：每个人的技术水平都参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，他作为公共代码开发员。每个产品或项目的修改需求，必须首先经过他的思考，能做成公共代码，能封装成函数，就他来做。其他的程序员只管调用函数，实现客户UI操作和辅助功能。这个公共代码开发员必须具备以下能力：A参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合的把握。如果队伍中没有这样的人，只有开发经理一个人有这样的经理，那么接到客户需求，分析客户需求，分解析辨是公共代码员来做还是其他开发人员来做。B公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位内存创建释放有头有尾，代码优美，代码可阅读，代码重构，代码性能和稳定都高C公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上最好应该说，找一个技术能力好的，工作认真负责的人，应该是不难找到的。而且专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。刚才还讲到一件事，那就是开发经理要熟悉客户需求，而且是深刻理解客户需求。客户需求，客户需求。这个让开发部最头疼的字眼。每当想起客户需求，就想起了以下这些话：1 程序员说：这是你们家个性的需求，太邪门，我们不做。客户说：不做我们找你们老板去，我们是花钱买了你们的产品的。2 客户说：我不会用鼠标，你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通，你们给我们做一个吧。程序员：我晕。3 程序员说：等你们内部斗争完，你们协调完了，我再调研需求。似乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。最后，我们发现，我们的软件无比复杂，谁也不会用了，连开发部门都不会用了，谁也不知道这个需求当时为什么是这样的。因为无比复杂，所以实施、培训、技术支持都成了问题，稳定性更成了问题。代码互相交叉，根本无法理清有多少交叉影响点。维护的程序员都快崩溃了，天天在祈求，千万别接到客户电话，千万别接到客户电话。这个问题终归是问题，而且是软件开发最大的问题。虽然我们也动用了这样的技巧：1 客户业务部门不能随便提需求。必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司2 客户IT部门的需求，必须客户方负责IT项目的老板签字才能生效，才能报给软件公司3 不能随时报，每3个月集中报一次4 不能口头报（即使在现场实施支持也不行），不能电话报，只能MAIL或传真来报5 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。6 软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。经过这么几招，客户也疲了。需求是不提了，开发部欢呼雀跃。但我们真的做好了么？难道客户真的满意了么？客户为什么要用我们的软件？难道仅仅是为了把他们现在手工做的，然后转到计算机去做。让计算机的查询统计计算速度代替人工？客户为什么要提这样的需求？客户要根本解决什么问题？这些问题谁来想，谁来想解决办法？ OH，My God!我们无能为力，因为我们是技术人员，我们不懂业务。那这个问题谁来解决？程序员苦笑了：没有人解决，也没有人能解决。客户就要，你不做他就要给老板打电话。噢，那就让程序员的噩梦继续吧。谁也救不了你，能救你的只有你自己。要救我们自己，必须我们自己走出我们自己。谁让我们就处在这样的处境呢？我们都想过的好，只能我们自己救我们自己。那我们就鼓足勇气，走出来，从我们的设计模式、OO、软件工程、虚拟接口、反射、持久化、框架中走出来。开发经理来承担起客户行业研究来：1 客户行业这个群体有多大？大中小规模各有多少家，各分布在什么省？我们面对的最佳客户是什么规模什么信息化程度的？我们的次佳客户是什么规模什么信息化程度的？2 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？他们各自的优点是什么？他们各自的缺点是什么？我们应该突出的优点是什么？我们的缺点是什么？3 客户行业的过去5年，现在2年，未来3年的发展历史和趋势是什么？他们面临哪些挑战和机遇？4 我们现在所做的典型客户，他们的组织结构，人员规模，每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程，每个岗位每日每周每月季每年的输入表格，每个岗位每日每周每月季每年的常用数据查询，每个岗位每日每周每月季每年的统计报表5 针对以上的了解，客户面对未来挑战和机遇，未来应该如何变更他们的岗位和职责和流程，尽量流程少，效率高，运转快？其实，开发经理就相当于业务架构师（因为我们还是游击队，不可能有专职的业务架构师），公共代码开发员就相当于技术架构师。柳传志说的非常好：搭班子，定战略，带队伍。你班子不行，上什么需求管理软件、版本管理软件、项目进度管理软件、自动测试、自动集成软件，都是无法落地执行的。有了夯实的业务+技术，功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求，就都能满足了。这时候再招测试人员，就能把质量再夯实了。而且，测试人员由于熟知产品，他们还能做技术支持呢，这样可以有更多的开发人员来专职开发，开发的专业性就能越来越提高了。好的产品，还需要有好的文档和培训，否则其他部门还是不会接开发部的产品的。那就招一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试（这个很重要，否则文案人员不熟知产品，无法写出有质量的文案）。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于他自己写文案自己用自己的文案做培训，在培训中会有各种提问，会更加增进他对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。好了，开发部的四套马车终于起来了，这就是我要讲的开发模式：从游击队转变为兄弟连，从软件作坊走向记住：业务架构、技术架构、测试兼技术支持、文案兼培训，四套马车。我们一直用它，效果很好，搭建团队容易，循序渐进不革命。有了这么好的团队，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。其他部门也愿意接软件了，软件的实施和培训和技术支持都被其他部门接过去了。开发部门也终于专职专业起来了，整个公司都很协调了，部门间也不互相陷害抱怨了。公司发展速度蹭蹭的。老板看着形式这么好，也不抠门了。奖金福利随之而来。老板看着公司产品销售这么好，也不用再为公司生存发愁了，不用随处找单子养活了，给开发部门更带来了专业理顺的计划发展。老板也开始重视研发部门了，研发部门在公司的地位高多了，给与研发部门的资源和支持也更多了。 OH，My God!第二章我给总结在一个页面里面了。实施模式是：1一个实施项目，大约50万的签单额，做完验收后给最后的20%-30%的尾款。2他们是一家小公司，为了多做项目多赚钱（企业都希望利润保持的很高，如果毛利低，做软件就不合适了，受的苦和压力和不规律性比其他行业多的多），所以一个项目只派一个人去，而这个人需要培训、辅助导入旧系统数据、清洗合并数据、规范化数据、报表制作、需求协调、推动切换上线、现场运行监控、个性化定制修改代码。3如果不能推动客户上线，就无法验收结项。不结项，就无法去追尾款。4一个项目这个人，身兼项目经理、开发员、需求调研、软件设计、功能测试、实施培训、定制化开发，还有时候写培训文档。因为公司里都是这样的人，根本没有分工出专门的文档人员，所以产品根本没有培训手册和帮助手册。除非客户必须要，这个项目的这个人才写一份草稿应付。而公司又没有人来做文档管理工作，所以各个项目各个人写，也没有人合并，也没有人来统一收集。每个文档都在项目每个人的移动硬盘里。5由于项目就老哥一个人全活儿，所以自己答应了客户修改什么需求就自己修改，根本没有啥需求调研方法和版本管理方法，就看这个老哥和客户之间的博弈了。每个项目一套源代码，而且都在各个项目的各个人手里。返回公司后，往公司的服务器上一扔做个备份。以后谁的项目出了问题或需求，就谁负责继续修改。但是，很有可能这个人已经在做其他项目了，还需要修改前几个项目的需求或BUG，还需要接听前几个项目的支持电话。如果这个老哥是在顶不住压力和焦虑而跑路了，只能把这些所有的活交给现存活的人的手里，啥也没有。无法交接也得交接，反正人要跳槽。6由于每个人都是这样一人挡一摊或数摊项目，而且项目周期长，每个项目都需要2-3个月的时间。老板也想把公司做大，但是每个项目能去实施的人，要求都非常的高，新人来了一年也上不了前线干不了活。所以，对招新人也是不愿意招，干花钱没见起作用，小公司培养不起人。而对项目游刃有余的人，都是跑单帮跑惯了，带着个新人，还干不了活，还浪费出差费用，真是气死人了，还不如自己亲自动手三下五除二搞定爽。于是，公司五六年了也就那么大规模，老板员工都干的很辛苦，当然老板得到的钱要多一些，赚个500多万没啥问题，自己后半辈子算是有靠了。所以，老板也得过且过，反正现在赚钱速度已经比较满足了，这样也熟练习惯了，经验路径依赖，就这样顺坡下驴做吧。我的朋友是个理想和现实总是不断冲突的人。一方面，他确实想把项目做的很是顺畅，另一方面，他却觉得一切都像是被各种因素牵扯，根本无法转变模式，于是只能认命继续现在。我说，你这种情况其实在中国很普遍。中国大部分软件公司都是从事行业信息化，因为这块技术难度最低，而且只要有人脉关系就可以做销售开干。而很多软件公司的成立，就是由于老板有一个关系，接到了某个项目，于是拉住了某个客户，小活不断，于是成立了公司。这是很多老板成立公司的原因。既然这类公司成立就没有目标，其目的就是认识几个人多拉一些项目多赚一些钱，所以如何复制模式，他们其实关注性也不大。原因很明白，就是自己不认识的客户，要想打入这个单子，很难，每个客户庙前都有N多关系户。对于自己有关系的客户，也就那么多个，有多大关系就能做多大的摊子，那就尽量从现有客户中持续做项目。维护好客户关系是最重要的。这类模式非常常见，并不是你这个行业特殊。老板的生活已经趋向于小康稳定，而你呢？你还在挣工资。你也在一线客户那里天天呆着，要么你把老板的客户抢过来你做，要么为了你自己工作能轻快些，你必须自己给自己找方法。我的朋友说，抢过来不可能。自己虽然天天在第一线和客户天天在一起，关系也处的不错。但现在人先认的是钱，后认的是感情。而老板给他们这帮人都持续吃喝玩乐送东西分回扣，自己只是一个干苦力的。自己只能找方法。但你说的方法是针对一个公司的变革，不是针对我个人而言的，所以不适用。我想有一个方法能帮助我自己的方法，你帮我想想。我想了想我过去写过的文章，确实是，自己一直从事职业经理人操盘产品研发管理，也统管咨询、实施、培训、支持，但都是在公司管理的层面上看问题分析问题解决问题，而没有从一个个体上去思考。而中国，大量像我这样的朋友，他们需要帮助，而我写的却是公司层面的，无法帮助他们，所以他们老说我的文章空洞、理想。我说，咱们俩一起分析解决。也是给大量像我朋友这样辛苦的人带个福音。咱们首先先说一下你想达到什么效果。我朋友说：我现在在这里待的很烦，出差时间太长了，我就想早点回家。那你什么地方费时间了，需要2-3个月在客户现场？我朋友说： 嗯，我看完你的那篇文章，我也做了一下反思和总结。我感觉有三个方面特别费时间：客户需求，数据准备，报表制作。一去客户那里，你是见不到客户老板的，也是看不到用户的，你主要面对的是客户信息科的人。他们一开始要求你先做演示，看看是否符合他们本企业使用。在这个演示过程中，就不断提出需求让你修改。而且，你不修改完，他们没法接受你以下的演示，说想象不出后来的样子，对着你画的界面图想象以后的功能变化，有点纸上谈兵的感觉。而且，往往演示的时候必须信息科科长在，否则底下的科员都做不了主，演示了也是白演示。而信息科科长却老不在。而他们上班时间也极为规律，该下班时立马下班，根本不加班。所以边演示变修改再边演示。好容易修改完了，也演示完了，时间一俩个星期就过去了。信息科算是通过了，就需要录入基础数据了。问题又来了。现在大部门企业都已经上过一套软件了，可能是Foxpro的，也可能是PB的。人家要求你把数据倒进新系统中，但是一看过去的数据，都乱七八糟的，过去上线都是没经验，后来也用的乱了，积腋成疾了。现在要导入，真是要把垃圾输入，得出来的也是垃圾。你苦口婆心的说服让他们重新录入，但是他们一看都好几千条，不想录入，让你能导多少导多少，然后在基础上再维护。这一松口不要紧，你不仅忙活了一个多星期写各种SQL导数据，而且往往旧系统也没有文档，数据结构需要你自己理解，理解有误也是你的事。好容易导完了，再维护，发现数据是通过SQL导入的，在界面上却不能维护，因为很多校验都是写死在程序里的，而不是约束在数据库。磕磕碰碰，自己边后台修改数据，边让他们信息科维护。他们信息科首先先检验导进去的数据对不对，没有填写齐的字段填写齐。然后把没有导进去的数据录入进去。然后再打印出来，统一对一遍，看看哪些数据录入的有错误。这样折腾，一个月，22天工作日就过去了，用户还没培训呢。第二个月开始用户培训了，但一培训就发现了问题。用户的需求和信息科所的需求，根本不是一码事。原来一个企业，信息科也和业务科室是两张皮，就和在软件公司一样，开发部和销售部是两张皮。于是，用户和信息科开始吵架，各说各的道理，谁都在维护自己的利益。而且用户部门有业务在身，也不可能天天大部分时间泡在IT讨论上面，开会不来人，或者要来人也来了个小兵充数，根本起不了决定，还提自己的意见，过几天开会，用户部门的主任来开会，又把需求再推翻。业务部门主任是站在主任的层次上看IT管理， 而业务部门科员是站在自己轻松使用的角度上提需求，而信息科是为了自己以后维护着想。不断的讨论不断的推翻不断的扯皮。讨论扯皮推翻再讨论再修改。终于消停了。开始培训了。但问题来了，用户上机一操作，发现基础数据很多不是平常现实那样的。计算机数据过去就和现实数据脱离了，现在想借新系统上线再回到计算机管理上。于是，一边培训一边修改数据，有人报告数据错误就修改。而培训没有文档，培训也没有课程，培训也没有专业训练。培训如何层层开展，培训如何组织，都不知道。反正就老哥一个被订在这里了，只能这么上手了。人没有来齐，也得开始。等来了再重新讲一次。一次不会，再讲一次。有人年龄大打字不熟练，有人看不清屏幕，需要调整大字。一调整，界面发生错位了。有人不会用鼠标双击和单击，有人不会控制打印机。过去是UCDOS系统，还没用过WINDOWS的，用不惯。从基础培训起吧。否则怎么办呢？人家不上线用起来，人家不给验收结项啊，尾款回不来啊。用户也培训完了，该上线了，就需要初始化库存了。先得现实盘点，然后再录入计算机，还必须一边得继续营业。于是，真实库存和计算机库存肯定对不上去。由于品种太多，所以只能一批批盘点一批批录入。由于操作不熟练，特殊业务不知道如何处理，只能瞎处理。处理完后发现不对，想冲抵回去。没有冲抵功能，只能修改数据库中的数据。由于前期修改，根本没有测试，就是老哥自己一个人改。改完了有时候烦了连自己都不想测试。于是上线用着用着就不能运行了，需要当时就立即修改，中午晚上的连续作战紧急解决，否则第二天一早还需要开门迎客。好容易业务录入了，但是报表不对。一检查，原来是前段时间录入的非法业务数据造成，功能没想到没拦住。怎么办？偷偷自己修改数据，然后使报表平账。过段时间，发现报表又不平了，发现还是非法数据进入造成。怎么进来的呢？想不明白。只好蹲点现场，直到客户都运行正常了才能走人，算是上线成功。这个累呀，两三个月都是紧着过的。好不容易回来休息会，另一个项目就要启动了，就这么几头能干活的蒜，老板笑着脸让你去。于是，遭遇再次上演，日子就是这么过来了，一月又一月，一年又一年。顶不住的就跑路。我听完了我的朋友的诉苦。我说咱们一件件事情的排查。第一件事，边演示边修改，还得信息科长在，还得他拍板。这段时间的浪费如入缩短。我过去也作过灯塔客户的实施，我过去一去了客户那里，并没有一开始就这么做。我先是调研此次项目组的人员构成、能力、职责、上线时间、用户计算机能力、用户部门对上一套系统的最突出的抱怨，信息科对上一套系统的最突出的抱怨，现在还有哪些系统在持续运行，上一套系统用户部门和信息科觉得哪里好，上一套系统的功能结构和操作流程。这样，我就确定了我该如何开展项目实施。这就是项目调研阶段。人往往很眷恋自己已经习惯的事情。而且人的想法，人的能力，各个部门的利益冲突，人和人的私人关系和恩怨，都有助于项目的推进。亚洲人做事，需要面上的和面下的都得下功夫。纯粹都是正式的或者都是不正规的，都无法做好一个项目。我会在项目调研后，重新建议项目组人员构成、职责、流程、项目阶段时间、各方面负责人、本项目的最突出要解决的前5个目标问题。人常说，上下同欲者胜，庙算者胜。你一开始必须界定好项目的边界和目标和执行标准和责任人，否则大家谁都想管或者谁都不管，大家没有目标，或者大家各有各的目标，肯定无法项目很好的推进。有了目标，责任人、标准、时间计划，就要按照这个目标来分解做。基础数据的校验，需要用户参与先来校验原有系统的数据。不要认为用户现有这套系统就没有问题。如果没有问题，企业也不会用你这套来代替他现有这套。所以校验现有基础数据很有必要。没有的数据，先让他们做准备，但你要书面把要准备的规范写好交给要参与的各个用户，而且要做好培训工作，不能讲讲就认为他们理解了。有了的数据，需要校验。地基打好，才能上面很快盖房子。而且，信息科和用户对老系统很熟悉，校验数据比你快的多，而且准确的多。只有经过他们的确认，你可以导数据，也可以不负责导数据。其实，基础数据，虽然多，但只要有5-10个人，2-3天就能录入完毕。比你导更快更准确。在用户嚷嚷需求的时候，一定要以系统目标为约束。因为每个人看法不一样，站的利益角度不一样，每个人的计算机应用水平也不一样，所以每个人都有看法。你让百家争鸣，而且什么需求都可以提，没有目标没有边界，就让你一个人修改，那么你结果不会好而且你会心身疲惫，你会很快就厌烦了项目。吃力不讨好，就是方法不对。需求，一定要围绕时间阶段和目标为约束，大家要一个目标。还有你刚才讲到的没有培训方法、培训文档、培训素质，说明必须要有专人来做培训。这块是项目实施非常重要而且工作量大的一块。这才是真正的项目实施。项目实施不是让你来修改需求来了。培训做不好，上线会出一堆麻烦，软件再约束不强，报表就是平不了。而培养一个培训的人员还是容易的。如果想培养一个会协调推进来事的、会修改软件的、懂得业务需求的、会SQL语句导数的、会培训的，这样的专业神人确实很难。而且这样的神人一定不专业。所以，要带人，先要让他搞培训，而且让他编写针对不同用户的培训手册，有培训时间课程、培训规范、考试考核、模拟练习环境、模拟数据。这是这个培训专员可以做到的。软件修改，尤其项目型软件，不修改是不太可能的。我不赞成在客户处修改软件。因为不仅仅你只会以事论事的修改，容易陷入到这家客户具体的需求中，而不会考虑其他客户的需求兼容，所以你修改的软件有很大局限性，最后形成只能一家维护一套代码，最后客户越多越累成本越高越不赚钱，被客户多而拖累死。而且你在现场那么多事情，那么多人打扰，你根本无心踏实下来修改软件，只想着赶快改完上线回家，你急躁，潦草，应付，软件质量就没法保证了。你想改变这种现状，你必须把需求整理好，交给在家里专门编写代码的程序员。你在现场，你也很懂业务，你和你本公司的程序员沟通肯定比客户沟通要顺畅的多。这样，你在现场，你的任务就是当好一个项目经理，专门协调，控制，理顺，制定流程、规范、目标、时间，保证执行到位。现场还有培训专员分担你的培训工作，可以帮助你校验数据，测试功能。公司里还有专门coding的程序员分担你的开发测试工作，而且人家写的代码更加多家客户兼容使用，而且质量稳定性比你高。只有专业分工合作，才能转成正规军。否则，你只能把自己熬倒了，心力交瘁，最后心灰意冷，跳槽而走。从民兵，到武工队，到土八路，到正规军。这条路有好几个阶段。不能想着一步到位。现实情况也不容许我们一步到位。我们只能是能改进什么就改进什么，天天进步一点，我们就会大变样。如果从心里就认为不可更改，直到心冷不想改进，那么我们永远不会进步。为了我们自己心身愉快，我们也要进步。记住，你是项目经理。你是这个项目的领头人。你决定这个项目的成败。如果你连这个定位都没有，那么你什么都决定不了，你这个项目的成败只能随波逐流，那样你真的很失败了，你什么作用都没有，要你干吗