先看看软件公司一些常规的岗位配置
售前、产品、UI、前端、后端、测试、实施、售后。当然还有一些公司规模上去后才有的岗位如：交互设计工程师。这些大家熟知的岗位是做什么的就不在一一介绍了。
然后在聊聊有哪些该设立的岗位
岗位名称暂且没有想好，就从职能开始介绍吧。实际上在日常工作中没有这个岗位但职能一般是有人行使的，这种情况一般会产生什么问题就不言而喻了。
一、会议管理
原本打算单独写一篇文章来记录我对会议管理的认知，奈何文笔太差，就不单独列出了，以后写作表达能力提升后在考虑单独介绍。
先说痛点，会议成本高，产出低，产出质量也低。其实光这一点就很少有人能认识到。为什么笔者会这样认为呢？可以从一些大家熟悉的现象中去体会：一是资源冲突会议时间、会议地点冲突；二是资源占用多与会人员多、与会时间多；再者还有产出问题我见过好一点的会议纪要包含几十条结论，差一点的就一个结论。笔者见过最坑的一种做法是让见习生去做会议纪要。既然问题这边多，使用这么频繁，设立职能相关的岗位就非常必要了。
在没有这个岗位的时候，先给到大家两个建议吧。与会人员不要超过10个人，与会时间不要超过45min。
二、程序秘书
我们的软件程序在设计的过程中难免有一些缺陷。常见的有非正常输入输出、版本问题、环境问题等。出现问题就要解决，而我们平常最常用的手段就是前方人员所说的“找开发”，这里笔者认为这个方法虽然是最快捷的方式的一种，但其中的资源浪费也是非常严重的。所以这里就有必要诞生一个岗位来处理二者之间的事物，当然如果能保证程序的每个版本不会有BUG，不会因为已有BUG带来衍生问题，不会受环境影响出现问题这个岗位也没多大价值。
设立这个岗位的初衷就是来缓解前端压力和开发资源之间的平衡，当然在对产品有了一定认知后，能够对产品优化提出建议也算作附属效果吧。
具体来描述下岗位职责：
1. 反馈问题时提供的信息不全，信息不正确，需要近一步引导。引导过程中通常还伴随着网络带来的资源传递麻烦，客户资源占用等问题。
2. 基本操作都不会使得沟通不在一个频率。前方同学比方说售前、实施的人员流动是偏大的，能力水平也参差不齐。有一些本该传达到的信息无法准确传达。
3. A来问一个问题，不久B也来问。这是前端人员的另一大特性，分散性。如果出现一些特殊场景问题，其内部是很难及时沟通的。而且有些场景问题通过沟通是无法产生有效的QA的。
