我一直处是在做应用软件，之前是做企业，后来回济南以后是医疗，但也属于应用软件的范围。这个行业软件特征就是：
1、技术不是首位的，大量的都是增删改查这些基础数据，大量的定制，较长的实施、售后周期，整个售后周期内也会产生不少的定制。
2、行业知识，这个任何想做行业软件的都应该深有体会，大到国家、国际标准法规，小到行业细节知识。
3、行业关系，这个懂的都懂。
总的来说行业软件公司就是项目多，人也多，对技术能力要求不高。只需要了解了行业细节知识，做起开放、实施、维护来都可以做到顺心顺手，而且有时候甚至也没有明确的产品和项目的界限。这就需要开发团队有批量作业的能力，说白了就把应用软件当成流水线，开发、测试当成流水线上的不同工种。
普通人可以通过使用一定的方法和准则来保证把事情做到一定水平。整篇系列文章的一个核心就是怎么保证团队最低质量输出，这篇文章也不例外，也更偏重于单个人在团队中任务的分配和培养。至于那种特种兵式的队员，能力强，有什么问题都能嘁哩咔喳给搞定的员工，属于可遇不可求的类型，虽说每个管理者都喜欢这样的员工，但这样的人培养周期长，没个一年半载根本培养不出来，而且一年也不一定遇到一个好的苗子，这样的员工不适合大规模的培养使用。
每个人都有自己的特点，有的人喜欢钻研，有的人沟通比较好，有的人做东西快，也有的人做东西喜欢偷工减料。团队种每个人的确定都有可能拉低团队的整体输出，对人的管理也就是要对他们的缺点进行管理。因为人的特点千差万别不可能一一穷举，我就按初中高三个级别说一下，首先初中高没有一个明确的划分标准，一般大致会参考工作年限，但也不是很严格，有的人刚毕业就能达到很高的水平了，而有的人工作几年除了空长年龄外也没有多大的进步。
初级工程师大致从毕业到两年的时间，这个级别还处在求知欲比较旺盛也很容易被规范的阶段。他们做事情最大的特点应该就是顾头不顾腚了，做事考虑的不全面，尤其是对一些边缘判断、验证判断做的不够详细，在遇到技术点时很容易陷于执着。对于他们分任务的时候一定要细，所有的点都要说一遍，说完还要让重复一遍，技术点和解决方案也都要说到。对于有点难度的技术点最好提前找到解决方案，让他按照方案去做，另外他们的代码要仔细的review，一些关键的函数，如果觉的写的不好，最好的方式就是在他写的基础上自己重新写一遍，然后拉过来一行一行的讲，为什么要这样写，这样的好处是什么，遇到知识点就展开讲一下，像深拷贝，浅拷贝这些比较散但比较有用的知识点。讲完以后把自己写的代码删掉在让他按照讲的重新写一遍。输出的成品作为项目经理最好自己先跑一遍，最低限度是保证能把流程跑下去，然后再提测。
中级工程师就比较复杂了，大致从工作2到好好几年了，大概的有的人这个阶段就像济南的春天，还没感觉就过完直接就是高级了，另外一些人就跟济南的冬天一样不光来的晚走的时候也是磨磨唧唧，经常还会来次倒春寒。这个级别的有了一定的技术和业务积累，做的东西也大致比较稳定了，他们的代码可能在项目初期需要review一下，主要关注的是对项目通用标准规范的遵守程度，另外就是一些核心代码需要审核一下。对应他们的任务分配和验收按照标准流程走就行了，不应该有太多操心的，如果有需要操心的员工，考虑淘汰就行了（这个很重要）。
这个级别的员工差不多也该有职业目标规划了，但无论将来想做技术、管理、产品还是其他的都要首先让他们明白一件事情，无计划不执行，做事情之前一定要把自己要做的事情搞明白，比如对外提供接口，需要提供那些接口，每个接口都是做什么的，如何鉴权，内部对接口的要求是否需要可追溯，异常怎么处理。都要让他们列出里，然后一条一条的过，过的时候给他们指出其他的漏洞。在分配任务的时候也倾向于提要求，而不是给解决方案。
高级工程师是比较少见的，放到单个项目里就是浪费了，跟他们只要能把自己想做的事情以及目标说明白就好了，他们会给你方案和验收标准。只要做到能够理解方案并看出方案能不能满足自己的需求就够了。
另外无论什么级别的员工，尤其是自己想要重点培养的员工，我都会要求他们对一个问题，无论是他们自己发现的还是我分配的，至少要给出两个不同的解决方案。我感觉这样能培养他们全面考虑事情的能力，最差也能培养主动思考的能力。
团队里面的人除了用以外，另一个就是培养了。我觉的对人的培养不能寄希望与技术培训，效果不好不说，还要浪费大量的精力去准备培训的东西，团队里人的水平也不一样，一块培训浪费一些人的 时间，分开培训又不利于团队团结。另外有的人就算不培训也会主动的去学，有的人就是耳提面命也不会主动去看一眼。
我觉的最好的办法就是直接分配任务，项目开始前先和团队成员聊聊，看看他们的想法，了解一下他们的水平。在项目期内根据要用到的技术点给员工制定一个切实可行的，一段时间内可达到并且可以验收的目标。这样他喜欢就会主动愿意的去做，不喜欢也可以用验收手段去强制去学习。但不喜欢的人除非特别缺人，一两次以后就不要再分配这样的任务了。
想做管理的人也差不多相同的套路，给一个可以单独管理的模块，先让他主导着把要做的事情梳理出来，然后根据工作量，给出相应的人力资源，在一段时间周期内这几个人就让他去分配管理。我要做的就是监督他的输出成果和管理成果，比如进度、产出的功能。
剩下的一个就是团队成员的招聘了，刚才也说过应用软件开发对技术的要求并不高，而且有开发框架和框架维护人员。所以面试的时候技术么反倒不是优先考虑的事情了，找些常规的java面试问一下，大致了解一下对基础技术的掌握程度，以及平时对学习的态度就行了。我最看重的是沟通能力，能准确理解我问的问题，并根据自己的理解做出回答，比如我开始都会问“说一下项目经历，从项目主要功能模块、使用技术、你主要负责那些模块这三个方面说一下就行了。”能用简单的语言不混乱的把这些说出来的人基本上都没有什么大问题了。
另外一个就是情商了，这个一般都会交给领导去把握，只要技术大致过关，交流能准确的理解我的话并思维清晰的把我的问题回答出来，都会提交给领导，由领导去把我情商。如果情商没什么大问题，就招进来，反正有试用期。