标签: 技术人员

1，首先要有电路和电子的基础知识，这也是整个电学的入门课程;然后要有低压电气的知识，比如变压器，断路器，接触器，继电器等选型，安装尺寸，这样只是为了设计一个低压电气柜。 2，现在来看PLC部分，这部分内容最为丰富，拿西门子PLC来说吧，从编程语言来看，要熟悉FBD编程，就要对数字电子技术比较熟悉;要灵活运用LAD编程，对电气设计要有一定的功底;要想对STL语言达到灵活运用的程度，学自动化的肯定知道微机原理与汇编语言这门课，学好了这门课才能熟练操作STL里面的累加器，寄存器，指针等;要想学好SCL语言，这需要对中高级语言有一定知识积累，这在编制复杂数据和算法的时候还是挺管用的。当然整个结构化程序的思想是要深入程序员的心中的。 3，再来看HMI部分，如西门子的WinCC，触摸屏TP，操作面板OP等，光这些东西就又够我们琢磨的了，还加上有些公司自己要开发界面，用VB等高级语言，再加上数据库如SQL SERVER，这样说起来，又要花多大的心思去研究了。这里面还有与第三方控制器交换数据的问题，OPC，DDE等等，光想都觉得有点发麻。最终用户或设计院有时候指定其它上位机软件，比如IFIX，INTOUCH等，这些都交织在一起有够学的。 4，现在再看NET，相信大部分人读过或至少听说过西门子工业网络通信上下册，里面内容丰富，很多现场调试都因为网络数据交换延迟工期。如西门子的MPI，PROFIBUS，ETHERNET，AS-i，MODBUS，USS等等。不简单吧! 5，到现在我们应该能想到，还有一大块没有谈到，那就是驱动，一谈到驱动，我们就会想到电机，然后就又有交流电机、直流电机、伺服、步进等，这里面包含电机与拖动课程，电力电子技术，运动控制系统。这里可又大有学问了，光说西门子的驱动就有无数种，呵呵，现在又搞出个SINAMICS系列，不过，我个人还挺喜欢这玩意儿。 6，最后，还有传感器与变送器，现场仪表，机械基础等等要我们去学习的。这些够吗?不够还有算法呢，有PID呢，有那么多学者研究出来的先进PID控制算法，够了吧。     说到这吧，希望各位工控朋友继续补充，说的不对的地方，请指正。只所以很多人认为工控行业没有什么技术含金量。我个人感觉，因为我国的工业控制水平比较落后，所以很多我们接触的东西比较简单，仅限于是一些数字量和模拟量的处理。核心的模型和算法基本全靠进口国外的，大家去看看一些大型的钢铁厂里面，去看看一些大型包装印刷厂里面，去看看一些大型的石油化工厂里面，应该就明白一切了。

在互联网项目当中，相信每一个项目经理或者制作人，最头疼的就是技术部的管理。因为技术工作看起来是那么的棘手，一般人难以理解，而且技术人员大多数都似乎情商不高。管理人员既不能轻易了解技术工作的内涵，技术人员也觉得很难和管理人员沟通。特别是技术工作，难以在不同人之间交接，很多技术人员都声称无法继续别人做过的项目。这让管理者觉得技术人员特别喜欢耍大牌，而且他们要偷懒也非常容易。但正如军事中的定理，对付坦克最好的武器就是坦克，对付航母最好的武器也是航母，这条理论是通用的。要管理好技术人员，就一定要懂技术。这是任何一种其他号称完美的管理方法都无法替代的。 　　开发是一切——何时写文档 　　对于技术管理来说，很多公司会非常注重文档。虽然开发的结果是代码，但对于管理来说，代码往往难以阅读，也很少有人擅长接手别人的系统。为了让代码不至于被丢弃，公司管理人员就祭起文档这个法宝。我认为文档是很重要的，但也发现这些文档中很典型地存在几个问题：文档和代码不同步;文档的可读性差，需要的文档没写，不需要的文档写了一大堆;文档和代码脱节，文档很多，开发出来的成果很少。 　　我们应该何时写什么文档，这是需要有严格定义，并且有检查过程的，而不是任由大家自然发展就可以完善的。代码的编写需要按不同类型，定义好在各个阶段中所需要完成的部分。 　　 设计类文档—— 这类文档往往在项目、模块启动的时候，大家都会想到要去写，作为讨论和最后决议的成果，显然是很自然的。然而在项目进入开发之后，碰到实际问题时，往往就不能完全按照设计的初衷去做了，所以通常设计文档就在这个时候和代码脱离了联系。但有一点是绝对可以做的，就是在重构的时候，按照现有状况，重新增加重构前的系统状况说明，然后再添加上重构后的设计。这样就把重构的设计和文档的更新结合到一起了。 　　API(应用编程接口)文档——现代软件都希望能提高重用的程度，因此很多程序员都会自己构造自己的业务API，以便在之后的开发中使用。而这种业务API，也是很多分工合作的基础。这种代码的说明，会直接影响日常的开发，因此非常有必要保证和代码的高度一致性。 　　 使用文档—— 一般来说，一个软件的使用文档必须包含以下几个：《产品版本说明》、《产品安装和部署文档》、《产品使用教程以及例程》、《产品FAQ文档》。这里面的《产品版本说明》应该在每次发版的时候，作为发布流程的一个固有环节来设计。《产品使用教程以及例程》是我认为所有文档中，最值得花大力气去写好的。《产品安装和部署文档》内容越少越好，应该让安装部署尽量智能化、自动化。 　　了解什么是软件架构 　　了解软件架构的范畴，才能有针对性地去把握软件开发中的风险，从而管理好软件开发的过程。简单来说，软件架构就是应对需求所产生的“一系列决定”。软件会根据这些决定来开发。根据软件需要应对的需求，软件架构一般包含以下几个部分。 　　 逻辑架构 主要是为了明确“功能性需求”而做的设计，针对需求以及需求变化作为架构目标所做出的关于代码之间的划分、耦合、关联的决定。采用合理的逻辑架构，将会大大降低需求变更对开发的延迟作用。逻辑架构最直接指导代码中互相耦合的情况，仔细设计好耦合的规则，会让后续开发事半功倍。 　　 运行时架构 运行时架构是为了满足运行期的质量需求，所做出的关于对象行文、进程结构、通信协议、数据结构等方面的决定。运行架构一旦确定，等于大部分的“实现”代码都确定了，设计有足够扩展性和可用性的运行架构，可以为后续工作节省时间，也降低了系统在运行期对开发工作的干扰。 　　 开发架构 为了满足开发时的需求所做的决定，主要是软件根据分工开发、测试验证流程等需求划分的软件层次和区域以及各种接口设计，也包含使用的软件包、组件库、开发工具，以及编译构建的方法。一个好的开发架构，可以让沟通成本降低，开发速度提高。 　　 部署架构 现代软件系统，基本上都包括了客户端和服务端程序，如何快速、高效、稳定地部署和发布这些程序，如网络机房的分布、服务器硬件的搭配、监控和维护工具软件的安装、开发测试网络和运营网络的设置。可以获得安全性的配置，良好的部署能力，能推动软件进行更频繁、更全面的测试，从而提高软件质量和开发效率。 　　 数据架构 数据是软件项目的核心财富，关于数据的结构，数据的存放、备份、传输会直接影响到运行性能、业务功能、部署、安全等需求。在面向对象的开发模式下，数据到对象的ORM架构也是很重要的设计。一个完整的数据架构包括了数据流图、数据字典、ORM结构(如果需要的话)、数据索引和备份机制等几个方面。 　　 何时以及如何评审 　　相信大部分公司都有评审这个环节，评审可以包括方案评审、代码评审、项目专项议题的评审，比如对存留Bug的处理评审等。而这些评审，常常会变成一个挑毛病的会议。要解决评审给产品带来的负面影响，同时发挥这个活动的优点，我们需要关注以下几个方面。 　　 评审由谁发起 相对比较好的是，由负责此项目的“领导”来召集人员评审，并且一定要有负责开发的人员参加评审。参与评审的受邀请人员可能会与方案提交者就一些问题有分歧，但提交者有最终决定权。要把权力给有能力承担它的人。这样做可以让“防止风险”的一部分人和“注重效率”的开发人员形成平等的意见交换。 　　 什么时候做评审 应该在每个迭代、每个较大的版本开工前，或者仅仅是某个认为比较重要的决定做出前，都来一次简短的评审。如果开始时只是做一个DEMO，那么需要评审的东西也比较少，而随着不断的开发，评审也能遍历所有的开发。 　　 做评审的方法 真正对项目有帮助的，是了解项目的需求，分析面临的难点，思考方案为何这样做，提出自己的解决方案，给项目开发者以建议和启发。多说“我建议这样解决这个问题”，而不要仅仅去说“这样做可能有问题，应该添补这样的功能”。以建设性的心态和思路去做评审，而不是以找问题的思路去做，这就是两种做法的最大区别。 　　 分层开发，尽快运行 　　为了降低软件耦合给开发带来的负面影响，正确的做法是要高度重视软件开发方法，从代码风格、软件架构、设计模式、开发模式方面来提高水平。其中一个最简单有效的做法，就是分层。在经典的架构模式中，分层模式几乎是所有模式的基本模式：把代码按照你所需的范围划分层次，然后规定层次之间的耦合接口，层次之间只可单向依赖，而且尽量减少跨层耦合。划分层次的范围，由你的开发团队水平和项目的复杂程度决定。 　　 非功能需求决定成败 　　世界上类似的项目非常多，但成功的占少数，失败的占多数，这种现象的背后有一个重要的原因，就是非功能需求。非功能需求具体包括：软件开发效率的相关需求，比如代码结构、代码风格、内容开发工具、自动构建部署工具;软件的质量稳定性的需求，如测试方面的需求，产品结构对于缺陷的防范，代码质量;软件的运行承载力需求，包括可用性、容灾性、可维护性、承载力、运行性能和成本需求;软件的信息搜集方面的需求，如故障上报、数据统计和挖掘。 　　如何才能做好这些非功能需求呢? 　　首先是在项目成本规划时，分配足够多的资源，比如人力和时间，去做好这个事情;其次是要尽量合理地规划和设计这些非功能需求，既不能贪多求全，也不能无所作为。 　 　追求代码质量 　　 代码质量 不高带来的危害包括人员流动后没法接手、Bug频繁出现、效率问题难以定位、开发速度慢等。 　　 什么样的代码才叫高质量的代码? 代码质量存在一个唯一标准，就是可阅读性。可读性好的代码，结构通常更简单清晰，Bug也少;更多人愿意去阅读的代码，也会有更多的机会去改正Bug以及其他的缺陷。可读性好，也意味着你能更简单地去找到改进性能的方法，减少修改代码带来的风险。 　　提高代码质量的手段，最简单的两条，一是执行代码规范，二是进行代码评审。除了规范制定和评审外，组织学习代码质量的知识，提倡并奖励高质量代码的人员，也是提高代码质量的有效手段。 　　 搭好测试这个安全网 　　 单元测试 是最原始的工程概念之一。单元测试对于互联网应用来说，一般会有一个困难，就是需要大量的“脚手架”，比如为了测试数据库操作，必须要有一段代码 “重置”数据库的状态;为了测试网络打包解包，则需要用一个程序向某个网络端口发数据。而准备这些测试工具代码的时间往往会比较长，需要有足够的耐心去做，但一旦做好了，往往能让开发风险大大降低。 　　对于单元测试，我认为最少应该覆盖所有正确的路径，以及重点防御的错误路径。覆盖了这些重点关注的地方之后，放手重构代码就很方便了。 　　单元测试应该是属于代码的一部分，和源代码一起存放。自动构建时也应该进行检查输出结果。提交代码时都会自动运行单元测试，当“版本树”需要合并“分支” 时，单元测试尤为重要，而最重要的是在分支上建立的单元测试。这些测试会大大加强系统的稳定性，因为检验了“合并”功能产生的代码—这些代码是最容易出错的。 　　 自己掌控开发方向 　　开发工作往往被需求变化“牵着鼻子走”，需求往往会有很多来源：产品策划的想法、老板的意见、用户的反馈、数据统计的结论等。提出的各种需求，往往会对开发团队造成很大压力。这些问题都需要我们对需求做出有效的管理。然而我们应该如何去搜集、记录、过滤、实现这些需求呢? 　　我们需要很好地搜集记录需求。有的团队会设立两面故事墙，任何方面的需求，都可以减缩成一个故事，写到一张便签纸上，贴到故事墙上，专人处理，而不会石沉大海。 　　有的公司会试图把这个事情用电子化流程来做，但电子化流程有个显著的缺点，就是为了更多地自动化处理，会加入大量的字段，对于故事这种还未谨慎定义过的东西，要认真填写太多的资料，无疑会给使用者造成额外的负担。 　 　告别救火队员 　　在产品进入运营期间，最牛的程序员似乎总是在充当救火员，各种各样的突发事件、棘手问题中，我们的“高手”往往疲于奔命，永远都在做一些补救的措施。有经验的人员一直没空做开发，因此大量的代码由那些水平较差的人来完成，反过来埋下了更多的问题。然而，如果不是忙着亡羊补牢，我们的资深程序员就可以把更多的精力放在开发上，这些有经验的程序员所生产的代码，又会进一步降低出故障的概率，这才是走向良性循环的方法。 　　为了减少运营期间的压力，在系统设计时，就要特别注意关于可维护性的非功能需求。运营事故当中，因为部署错误所导致的占很大一部分，因此降低部署错误需要做到：全代码包发布，每个发布版本要包含所有的可执行文件;所有的服务器上部署的配置文件和数据文件都必须做到完全一致，降低更新文件的复杂度。本机IP地址应该用代码从网卡上直接读取，但应该提供可以配置的选择，预备多个IP的服务器使用;只使用命令行方式来启动不同功能，如选择配置文件路径、输入不同功能进程或服务器的配置;程序支持关闭、重载配置这两个信号。 在处理这两个信号时，都不应该让使用者感觉突然“掉线”;开发用于安全关闭程序、重载配置的脚本或功能;开发用户自动重启所部署进程的脚本，以及配置开机自动启动所部署的进程;每个进程都不应该强行锁定某资源，必须要能做到一份安装复制多进程并行运行等。 　　每天发版 　　如果你想知道项目每一天的开发进度，你就必须要做到每天发版，测试每天的工作进度， 如果要顺利地每天发版，就必须建立一个持续集成的系统。 一般来说持续集成系统会有以下的先后步骤： 单元测试—自动构建—自动部署—集成测试—自动发布。 　　单元测试关键是要能坚持覆盖所有新加入的代码;自动构建是由构建脚本、构建服务器、持续集成系统几部分组成。 　　对于美术、产品或者别的非技术人员，添加的数据往往也需要有自动部署的工具，而且因为通常他们产生的文件比较大，每次的全体打包然后覆盖，可能会非常没效率。虽然事情要做得完美不是很容易，但绝对是物有所值。 　　版本列车 　　我们时常只是对技术工作有版本管理的过程，而对于其他环节，常常停留在最原始的状态。我们需要在整个项目开发的每个环节，都进行合理的项目管理。在多个项目的经验积累之后，提出了全过程的项目管理的概念：版本列车。 　　版本列车的含义是按照项目的工作流程，为每个有产出的环节都定义一个版本“车厢”，然后按照工作流程的先后依赖顺序，形成一个完整的“版本列车”。第一个工作环节负责版本号，然后在这个版本号之下填充版本内容。当工作完成，此版本的工作内容则带着版本号进入下一个“车厢”，依此类推。 　　这样做的好处是，每个环节的每份产出都可以明确地知道其进度位置，安排在什么时候做。对于需要提前准备市场推广或者别的工作部门，有一个非常明确的长期计划。对于进度管理来说，各个部门也能知道整个项目的当前状态。 　　论功行赏(绩效评估) 　　不管是对被评的人，还是对评价别人的来说，绩效评估都非常难做。因为很多工作并非能很准确地列举出一二三来，工作任务也可能有大量临时变更。太过主观会让人觉得草率;非要去依据可量化的数据，又过于死板和片面。但没有一个公司敢不做考核，所以说绩效评估是“明知山有虎，偏向虎山行”。 　　绩效考核应该重点关注的是做了什么事，而不是做得怎么样。这个让很多按“结果”管理的老板很不接受。绩效考核应该是推动别人去做某件事的工具。对于已经明确的方法或者子目标，通过这种细化的方式去指导下属工作。因为是需要事后算账的，而且是量化的，所以下属会对这个事情很认真，同时那些不好量化的事情，管理者也很难执行绩效考核。所以“去做某些事”，是绩效考核最好的目标。 　　通过考核结果提供正式的工作方法意见。绩效考核本身有个反馈的过程，这个反馈的过程应该提供给下属针对每个具体事情的建议。这种具体地，单独地，一对一地指导，会提高团队的稳定性，而且也让团队成员获得“受关注”的感觉，这种感觉是形成高效团队的重要工具。 　　考核不能代替目标，不能阻碍目标，而应该是一个沟通工具。目标达成情况是考核的客观指标，但不应该作为主要绩效考核指标。最简单的绩效考核指标就是收入或者利润率。但这种简单指标除了在动机上提高下属的工作热情外，并没有从方法和经验上帮助团队成员。有效的考核应该是引导下属按照更有经验的方法去实现目标。 　　本文节选自《世界500强互联网产品经理管理笔记》一书，刊登时内容有修改。作者先后就职于多家互联网公司，经历横跨技术开发、产品设计、团队管理。通过梳理十年多从业经历，将大型团队管理和产品开发领域实践经验与读者分享。电子工业出版社授权刊发。

应一个客户邀请，昨天跟俊知老板去他们公司，这个客户是做带状锯片生产的，以前在自己亲戚那儿工作，熟悉了锯片行业，也掌握了生产、机械设计，因为一些原因，在07年获得一些投资后夫妻出来单干。做到现在，厂子规模还算不错，场地接近3000平方米。   去了之后，先看了老板（A）自己做的带锯磨刀机，我因为不是这个行业的，看的不是太懂，俊知老板（B）比较熟悉，基本上了解了一下后跟客户聊起来。B把自己看到的说了一下后，A比较得意的提出自己这台机器的几个特点：   1、用废钢材搭建的，速度快，成本低 2、关键点采用很好的材料 3、解决了同行原来存在的设计合理性问题，进一步提高了精度   A既想保密他的一些设计窍门，但又想显示一下自己的水平，说着说着，就把自己的窍门大概的说了一下，我因为不太懂，没听明白，B听了后，觉得没有A自认为的那么神奇。聊到了中午和A夫妇及他的两个供应商一起吃饭，A不停的抱怨这个行业的艰难、人员招聘的头疼及资金的压力，坦言这么多年，都没有赚到钱，都专注于做技术了，自认为后面会有很大的发展，而他的媳妇看起来非常的好，人略胖，话不多，并且很有耐心，可谓奉献自己而全力的支持着他。   我感到A是典型的技术人员，性格也比较直爽，有一些感触，并且毕竟今天我是蹭了一顿丰盛的饭，过意不去，想提醒一下他，于是就问了他几个问题： 1、他的技术管理如何管理？ 2、资金重要还是人才重要   第一个问题，决定了他这个带锯磨刀机研发出来后，如何维护的问题，因为我看过太多的公司，研发一款产品容易，维护一款产品却很难，都没人跟进，无法把研发的成果扩大，最后导致不停的投入而没有产出，通俗的说，就是“ 只关心生孩子，不关心养孩子 ”，生孩子不用一年，养孩子可是要将近20年啊。很多人都认为研发很重要，这个不能否认，但是，若不具备维护研发成果，尤其是后期的跟进及推广的话，还不如不研发，而他哪儿，我担心的是，老板有能力做出设备来，却无法解决小毛病让它成为真正的产品推向市场。   第二个问题，决定了这个公司老板的价值观，因为这个老板还停留在资金重要的层面上，所以很累，并且下面的人也看不到希望，公司的发展，全靠他们夫妇俩推动的，可以说公司的其他人都是跟他们对立的，这个太可怕了 。   我们提了一下意见后，包括A的另外两个供应商，也对他提了一些建议，A根本听不进去，总是说没有办法，没有办法。后来他们客户跟我们提到一点，A很聪明，这是他能做到现在的基础，但也因为太聪明，所以，一直这样，他给我们举了一个例子，他们租给他的一个设备，用了5年了，想让A买去，哪知道，A竟然把他的设备模仿了。A是技术人员，自己太能干了，所以总是看到别的设备的成本，里面的利润，为一些蝇头小利而花很大的精力，没有把自己的精力投入到他真正应该要做的事情上去，并且把这些精力产生的价值复用量产起来，A自己说他的客户有上千个，但真正上量的，没几个，所以很累很累。   离开A公司后我们很感叹，俊知今年以来，老板做的最多的，就是关心养孩子，而不是生孩子，这一点做的很对。  

我们可能经常听到，美国人创新能力很强，中国人就只会山寨，日本人、德国人做事就是细致、严谨，印度人就是懒、脏。说到技术人员的时候，大家都会觉得，技术人员之所以不如市场人员创业成功率高的一个很大原因是自傲，不会沟通等等。那么真的是如此吗？ 年初在天涯上看到一篇经济帖子，谈到中国与印度的经济问题，作者专门写了印度普通民众的情况，尤其强调了一点，印度民众并不懒，现在懒只是因为社会体制下，没有出路，这个如同国内西部地区一样，没有产业给你做，不懒又能如何。给我比较大的震撼。 我以前也一直区分人群的，比如那个省的怎么勤快，那个省的怎么怎么懒，但是，去看看各种哲学家的书可以发现，人家是从来不区分那儿人的问题，都是分析整个人类的行为，提出模型来解释的，比如一个地方今天很勤劳，跟他以前的历史，或者地域是有极大的联系的，这个本质上属于进化论的一种思想。任何一个生物群体在一个社会上出现的现象，都是属于进化论的一个表现，也就是说是当前情况下最适合大家生存的行为。 我以技术人员为什么创业不如市场人员概率高这个问题来说明感觉的不可靠，一提起技术人员成功率低，大家往往都把矛头对准技术人员自身问题，最多的就是性格，但实际上，大家都是人，性格都差不多的，就算有影响，那也不会差异太大，不然就不叫人了。并且改革开放的第一批创业者，大部分都是有一技之长的技术人员。因为他们有技术，而那个时期物资缺乏，拥有技术的人员很少，只要能造出东西，就能卖出去，所以创业大多成功，是技术人员的黄金时代。当物资慢慢丰富的时候，第一批创业者的规模也大了，于是一批有魄力的市场人员开始左右江湖了。到了今天，通过30多年的教育，技术人员泛滥，各种技术书籍大把，都来不及学的情况下，技术沦为一般资源，因为国内没有核心技术，大部分的技术工程师只是一个应用工程师而已，等价于做鞋的老师傅，做的产品都是大路货，电路是源头提供的，软件是源头提供的，自己就是修修改改一下而已，完全的同质化，根本没有技术人员应该有的创新和差异化，所以关键是如何把产品卖出去，并且技术人员创业，要钱没多少，要产品，就算功能上比普通的多一些，但因为没有量，成本太高，小毛病很多，进一步导致销售不出去，失败也就是难免的了，因为这是逆天而为，但是当一个技术人员在有具体需求和具体客户的情况下，一般都是比较容易成功的。 对比很多与我水平类似的技术人员，他们身上有的问题，我身上一样都不少，但之所以我能创业成功，根本上是我做的产品“电阻电容电感样品本”和“MTK手机平台在行业中的应用模块”有明确的客户需求，并且是创新需求，非用不可的，避开了竞争而获得了利润才支撑下来的，并且后面迅速的把网络营销做起来，才有了今天的稳步发展。 到了今天，因为android下很难再有创新了，而网络营销的功效也已经基本用尽，唯一的出路就是销售，狭路相逢勇者胜，只留下这一步棋了，那就不用再想别的招，冲吧！  

在对技术人员创业经深入探讨之前，我先介绍一下自己的经历，让大家认识一个真实的从技术工程师到研发管理者，再到创业者的人。从媒体可以认识马云、史玉 柱、牛根生很多成功的创业前辈，那一切对我们每一位工程师似乎又很遥远，他们是按照统计学规律，在人群中只有小概率的人才能达到的，但本文所写的这一切， 就发生在您的身边，并仍将被许许多多的技术人员继续实践着的技术创业之路的朴实与传奇。 我97年电子工程硕士毕业，之后在航天系统工作5年，辗转几个部门，再后来到一个机电设备制造类的创业型企业，做了6年多，随着企业的发展，从一个具体业 务方向的项目部经理做到负责研发运营的总监和事业部总监的职位，公司从二、三十人到了五百多，从零收入到几个亿，从国内区域客户到全球四十几个国家，然后 是我的天花板，下决心走出来开始自己创业。 我也有一些运气和机会，那要感谢前老板，他让我有了一个见识并亲自参与决策、实施使一个企业成长的过程，这个过程中的点点滴滴不是很多人能得到的，包括外 企高收入的高级白领们，因为企业不同的阶段会面临不同的问题，会有不同的解决方法，虽然我离开了，虽然不知道和前老板还能不能做成朋友，但我感恩，感恩于 6年多的职业生涯给我带来的一切。这是技术人员创业经的第一个理念。如果不感恩，或者不是发自内心的感恩，创业是很难成功的，修身先修心，相随心转，心灵 的很多东西会在相貌上体现出来，你的客户、朋友、员工都一定会感觉得到，这会影响他们是否愿意真心诚意的帮你，是否真正的信任你。 创业首要的问题是认识自己，认识自己是否具有商业思维和经营能力，技术人员创业容易走进一个误区，“我有产品有技术于是去创业，还得说了算，有控制权”， 需要明白一点的是，创业需要战略思维和商业思维，而这不是自己认为有就有的，真正有商业头脑的人就会较容易地感知并发现这类人才，并与之产生共鸣，所以创 业酝酿期最好能和一些投资商、创业成功的企业家接触一下，请他们来感知和判断创业者本人究竟是否具有创业特质的人，既然自知之明难做到，那就用他知作参 考。一般他们的感觉会是对的，不对的话他们就不太可能成功。为什么这里更多地强调商业思维而不是技术，因为创业的过程会面对很多变数，市场需求是变化的， 竞争对手、竞争产品、竞争技术都是随时变化的，关键资源也是变化的，能否成功应对这些变数才是关键的能力，而不是那一点点的技术。“企业家是资源”，此言 不虚。 比如我见到一位创业的技术型人才，公司初创时，开始时判断会有很好的前景，因为过去隔三差五就有人主动上门找私人帮忙做些设计服务，业务开始后，却突然发 现没人上门，自己也还没准备好如何去主动出击让客户知道自己，或自己能主动找到目标客户，这样就没得生意可做；后来还不错，朋友听说后有介绍客户来的，但 他签合同时要价很高，首付款比例又太低，对因为客户内部原因不能解决的问题也作甩手掌柜，明知道能帮上忙也不去帮，问起来还有句说辞“那部分没在我合同之 内”，最后的结果是客户原因合同执行不下去了，不了了之，首付款很小的比例远不能称之为收益，已收首付款额度太低，对客户的压力也不够，后来客户直接找了 另一家合作，用此合同的未付余款就把项目做完了还略有节余。这里面他犯了几个错误，一是做生意总觉得价高就好，孰不知回款才是重中之重，没回到款的生意等 于没做，尤其是在国内当前还缺乏诚信的商业环境下。二是客户内部是出了点问题，也和合同协议内容无关，但他忽视了别人的问题可能是你来买单的，对于别人的 事情，但要你来承担损失的话，还需要计较该谁干吗？三是首付款比例太低也没有对客户的约束力，客户的违约退出成本太低。同样是技术人员，一位从航天出来的 技术工程师就很无意地把这些问题都规避了，于是我认为航天这位朋友能做好生意，经过近两年的事实证明，这两位朋友的公司发展迥异，这些商业细节方面他俩有 很多的微小差异。这些细节上就体现了一个人的商业思维。 所以说，通过让成功创业的人评判您自己是否具有创业头脑，可以下一个结论，适合创业的话您可以做领导核心，主导创业，如果不适合创业也不必放弃，可以找合 作伙伴，心甘情愿的当小弟，贡献你的技术，让有商业头脑的人主导公司战略和运营，自己多听多想，但就是不要太固执了，执着于自己的思维，总觉得自己对，不 合我意就撂挑子走人。 确认了自己适合创业后，开始选择创业项目，技术人员的常规思维是我懂某个产品，掌握某项技术，就以它为方向，这个思路本身是没问题的，但是不全面，创业首 要的是做市场细分，研究商业模式，把东西卖给谁，他要什么样的东西，他为什么非要买你家的而不是买别人家的同类产品，最常见的分析是“这东西都是进口的， 我做出来便宜，一定可以替代它们的”、“我做的这东西还没有人做，市场空间广阔得很”，忽视了一点，假设您个人做出了一款手机，拿来卖给我，说怎么便宜怎 么好，我现在一定不会买，我不相信产品的质量。没人做的东西有几种可能，需求还没起来，那么就要培育需求改变用户的应用习惯，它是一个很漫长的过程，销售 的商品里面除了产品本身还有一个品牌价值在里面，切不可低估了品牌价值的影响；还有可能有需求，但这里面有本质问题，没盈利就不能维持公司运转，或者有投 资也行，但投资也不是一直投下去的，它也是为了快速高额回报而投的，博客中国最近的欠薪和倒闭就是个很好的例证。 创业前的项目选择有几点：一是不熟不做，不熟悉的东西看起来再美好，那也是因为我们只发现了其优点，还没有发现其缺点。而创业最大的风险绝不在于是没有前 景，而是在于风险会使我们失败，做熟悉的就能相对比较好的预见并规避风险；可以做自己熟悉而且能做的产品或服务，与原来的企业直接竞争或补充其未切入的市 场空间，例如我是监控系统开发工程师，创业可以去做个家庭监控或设备监控，弥补原来企业的市场未覆盖到的区域；二是以自己熟悉的为目标客户，还是监控系统 开发工程师，就去做监控软件开发商或监控设备维修，为监控设备厂商提供配套服务。这样的情况，创业者熟悉的是用户的需求，掌握了需求，发掘了客户，找到合 适的人来做的难度要低得多。 商业模式也是一个需要注意的事情，小池塘养不出大鱼来，一个局限性较强的细分市场领域，一个受限于资源条件的产品模式，一个不能被较大量复制的产品，均会 成为那个小小的池塘，这个问题在创业初期为活命挣扎的时候，容易被忽视。对于一个很有理想和抱负的技术创业型人才，需要提醒一下，选择了一个小池塘将来肯 定要面对第二次选择方向的问题。 项目有了，然后考虑整合资源，技术人员常慨叹自己没有没有机会接触外面，缺乏人脉，所以不敢创业或自怨自艾，其实不然，缺乏人脉并不是拓展人脉的机会没有 降临，大都是当事人没抓住或不会抓，有一次在丰联广场举办研发管理研讨会，邀请一位常和我慨叹没机会拓展人脉的技术人员去参加，他的回复是“太远了点，有 点阴天，我就不去了”，结果就是几年之后，他还在慨叹没机会走出去认识人。人脉是要积累的，也是要付出一些精力成本的，没付出就没有收获，这种现象也正 常。 还有一些朋友是有了人脉的机会，却不会抓住，我原来所在的行业是一个需要第三方机构强制检测的行业，检测机构的人是技术人员梦寐以求想拉拢的对象，有些工 程师也积极的去套关系，积极地交换名片，似乎觉得名片拿到就是人脉建立了，其实不然，在这场不对等的关系中，人脉并没有真正建立，真正可靠的人脉是要你在 对方那里有价值，他才会很配合的与你结交，才能互用互利。有位工程师去检测机构，见到他们做实验没工装，就建议如何如何做个工装，检测机构说了“挺好的主 意，你们给我们做吧，我们付点费也是可以的”，于是这个小伙子就轻松结交了检测机构的核心工程师和主管，并在以后的合作中颇为和谐顺利。所以说，创业的技 术人员一定要做个销售高手，也许不会喝酒、不会打保龄，但一定要有所擅长，有所发掘，使自己对别人有价值，这样销售才好做。创业初期，销售产品的同时也是 销售创业者本身。 创业看起来很简单，做起来很难，这我们都是知道的。但有一难是我们看不到的，就是合作伙伴团队达到和谐和信任很难，创业成功的家族企业占多数，核心原因之 一就是家族成员间不缺信任，沟通成本很低，大家一心于做事，而对非家族的合伙创业来说，这就是个问题了。这一点我走上创业之路后才真正体会到，毕竟在这个 企业中，大家的利益是不完全一致的，做核心者，必须做到无私，我很欣赏牛根生的财散人聚财聚人散，老大是付出最多的，吃最大亏的，能镇住一部分局面，如果 老大做到了这一点，和谐和信任就相对好建立的多；当然很有魅力和影响力的技术创业者，也可凝聚一批人，但毕竟大多数的还是普通人，不是具有超级个人魅力的 管理者，如果是应该也许已经做到了高管倒也未必出来创业了。做到和谐的办法有几个倒也简单，核心领导者不自私甚至多吃亏，坦诚直面问题，把问题摊在桌面上 谈，开始的时候确定决策议事规则，出现纠纷按规则办事。 另外一个需要注意的问题是风险，企业家精神的核心思想是冒险和创新，创业又是企业家精神的体现形式，冒险肯定是少不了的，毕竟每个人都不仅仅是为自己生 活，都有太太孩子，年迈的双亲，自己累点苦点无所谓，但家人是不能不考虑的。风险需要控制，开始的时候不要陶醉在挣多少钱怎么花上，而先分析清楚最坏可能 会赔多少钱，亏的风险自己能否承受，很多文章都在讲，胆子再大一点，太瞻前顾后就不要创业了，还拿出创业成功者高学历者比例很低的例子来说明。但这句话对 技术创业者的适用性要斟酌，创业是冒险，但不是找死，险一定是冒得，但冒险的底限不要过于保守，可以把可承受风险损失的数值适当调高一些，比如有5万的存 款，可以设定最多赔20万的门限，倒未必是亏到4万的时候就不干了。 做企业从思想上要杜绝机会主义，经常见有几个朋友聚到一起，谈论起来某位是做采购部经理的，在企业里能主导电子元器件的采购，就大家动议成立个元器件贸易 公司，从给他家供货开始起步，这种做企业的方式是典型的机会主义。毛主席说：机会主义就是这里有利就到这里去，那里有利就到那里去，无一定原则，无一定方 向。批评的是当时一种缺乏远见的军事政治倾向，其实对一个企业的方向来说，也一样适用。做企业必须坚持一个基本的价值理念，就是为客户挣到钱或省了钱，从 省下的或挣到的部分里分一勺羹出来作为报酬，不要将企业的命运寄托在一个所谓的机会上，而是稳扎稳打，始终坚持“通过创造价值赚取收益”的准则，始终通过 自己企业的核心能力来运营，通过能赚取利润的商业模式发展，有机会更好，不必拒绝，可以借机发展一下，但没有机会也一样活，否则就成了守株待兔的农夫。 创业初期的企业，规模虽小，但也要学着做品牌，别觉得这个题目太大太早，也不一定过于高深，在细节上去做，从起名字、建网站、产品外观、服务产品类型、公 司口号等等方面围绕着品牌定位去实施。如果是面向一般大众的产品，名字就要简单琅琅上口，面向某特定行业领域的，最好专业化一点，名字的传播本身就是品牌 认知的一部分，尤其对于新品牌。具体工作内容上，赋予产品的内涵要与品牌传播的口号相一致，比如安全可靠，那就在产品具体设计上，要通过各种细节体现安 全，在组织结构设计上，安全检测和设计控制方面就要有扎实务实的工作，在宣传上，要突出做过的安全试验、安全验证效果，甚至于在名称起名上也要是让人心安 的那种。 创业对创业者还有个突出的要求，就是平衡各种事物，挖掘各方资源的能力，创业阶段最突出的矛盾是缺这少那，经常抱怨缺少资金办事的创业者，有可能就不是适 合创业的人。做企业的过程中，资源不足是常态，比如缺少仪器、缺少人手、缺少资金、缺销售渠道、缺市场推广人员，创业者必须研究和学会的是在没有路没有工 具的地方，通过自己的努力来制造工具，发现或修出一条路来。这部分没有通用规律可言，全靠创业者的个人魅力、智慧、人脉储备了。 创业过程是艰苦的，但也是快乐的，其中最为快乐的是自由，晚上挑灯夜战的时候，那是自由的感觉；苦读技术资料、绞尽脑筋联络某位客户上层人物的时候，那是 挑战自我的舒爽；挫败的时候是让人成熟的沉重压力；有结果的时候是让人欢欣的痛快。这是只有创业者才可以体味的快乐，是不同于做产品研发过程解决了一个技 术难题的那种。随着中国经济结构的成熟，竞争的加剧，越来越多的创业将不再主要依靠几个良好人际关系的客户实现，而事依靠技术的提升和商业的创新，在不依 赖于纯粹销售创意而经济繁荣的商业季节，催生的必定是技术创业者的春天。