APP开发团队基本结构需要哪些职位 以及职位数?

1．产品经理软件公司职位结构图：具有通信、计算机等相关专业知识软件公司职位结构图，有独立软件公司职位结构图的软件开发经验软件公司职位结构图，能熟练使用网络测试工具，熟悉软件开发架构与流程；有良好的团队协作能力、沟通表达能力，有一定的项目管理经验；富有激情，有较强的执行能力和带队能力。

2．程序开发人员：计算机、软件工程等相关专业，熟悉开发框架，能够独立完成android开发；精通Java、C/C++等编程语言，熟悉 Http协议；有良好的编程思维和代码规范习惯，踏实好学，善于协作。

3．测试专员：计算机、软件工程等相关专业，有丰富的APP使用经验；了解android应用软件的测试框架和流程，熟悉QA标准，精通测试软件的使用，具有一定的数据分析能力、沟通表达能力和文档编辑能力；严谨细心，心思缜密，善于协作。

4．UI设计师：视觉传达、美术设计等相关专业，精通APP交互设计；精通Photoshop、Flash、Illastrator等专业软件;有较强的艺术感和较高的审美水平，了解市场对交互设计的要求，能够准确把握用户的审美需求；耐心负责，有较强的沟通理解能力、团队协作能力。

5．运营团队：营销策划、市场运营等相关专业，有丰富的产品运营经历和营销手段，能准确把握市场动向和社会热点；有项目推广、管理经验，较强的市场调查和数据分析能力，熟悉APP上线、维护流程；有较强执行力，热情善于交往，思维敏捷，良好的团队合作精神。

比如技术开发负责APP的程序编写,编写的过程中还要同UI设计进行交流,开发完成的APP需要交给软件测试人员进行测试来保证APP在正式上线时确保无BUG,这个过程也需要开发人员进行配合进行DEBUG;后期上线后还需要专门的推广营销人员开做市场调研。

公司让我做一个岗位架构图，用什么软件做好呢？

建议你用 Edraw 亿图软件来画，这个软件有很多这种模板和例子，你可以通过这些模板、例子快速的创建，如果有excel或者文本格式的数据，可以通过数据导入快速生成。如果说以后有职位、人员变动，用亿图软件修改也会比较方便。图表画好之后，可以导出为word、excel、ppt、图片、pdf、visio等格式，或者直接将文件分享出去，对方用浏览器、手机就可以进行浏览。

软件职业的职位

目前本国软件职位名称如下:1 程序员

2 初级程序员

3 高级程序员

4 软件工程师

5 项目经理

6 系统分析师

7 系统设计师

8 软件开发工程师

9 软件QA

10 软件配置师

11 软件测试师 软件职位重新命名和划分主力开发职位:1 软件需求师

每个项目或者是产品,都需要一些懂开发和交际软件公司职位结构图的人把需求做软件公司职位结构图的更明确,更完善.一般是由外向型男性和女性软件师组成.

2 软件架构师

架构师主要根据需求的结果考虑系统的构造,环境,性能,稳定,扩展性,维护性,友好性.并使用ROSE 画出UML图.

3 软件设计师

设计师主要是把构造师的UML的具体设计出来,

4 软件书写师

书写师把设计师的设计出来的东西实现化,并负责调试通过.其必须对算法数据,结构,逻辑思维.语言的精通,工具的熟悉是必要条件的.

5 软件测试师

测试师把做出的半成品进行检测,是否达到软件公司职位结构图了产品的要求!这个可不是一般人可以胜能的.现在有的公司一般招女性来做,说是女性更有耐心的.

其实出软件公司职位结构图了耐心外,还是要做过各种的软件书写工作才能胜能的.主力管理职位:1 软件进度师

进度师根据软件工程学,合理的高效配置人手,把握进度在计划中完成.PROJECT2000是其的日常工具.

他好比是建筑现场的施工员2 软件管理师

此乃师重量级职位,主要管理整个软件企业内部涉及到软件开发的系列管理.部门的划分,小组成员组成,团队成员的组成,人事制度,行政制度,薪水制度,培训等.

因为软件企业属于知识密集性企业,软件产品又不同工业的产品.人的因数对产品的影响最大.人件,人月神话,企业管理,以及各种开发模式都是其主要思考的问题.铺助开发职位:

1软件友好师

友好师不必说了 但是其还是要和 2和3 的职位分开的.如何搭配图片,音效.组件的摆放等学问

2软件美工师

美工师主要制作出各种图片和动画

3软件音效师

音效师主要制作出各种音乐.虽然目前在企业级和通用级软件中被忽视了,但在游戏中可重要了哦!

4软件优化师

优化师对产品的性能进一步的优化.铺助管理职位:

1软件配置师

该是新职位,本人不太了解.

2软件销售师

做销售的人员不懂软件是不行的

3软件文档师

这个职位一般由高中女生充当,五笔输入法,WORD熟练.负责整个公司的软件各种文档书写和管理.

软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

软件架构（software architecture）就是软件的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。

O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。

软件架构就是软件的基本结构。架构的本质是管理复杂性。 如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种：

1. 分层架构（比较传统的单体架构）

2. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）

3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）

4. 微服务架构（当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）

5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）

在原文的基础上，我按照自己的想法，进行了小幅调整。

分层架构（ layered architecture ）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

有的软件在逻辑层（business）和持久层（persistence）之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理，不能跳过其中任何一层。

优点

缺点

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

事件驱动架构（event-driven architecture）核心组件：

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

缺点

事件驱动架构在通信产品中应用得也非常广泛，典型的如状态机处理。 事件驱动架构不适于做顶层架构，但适合做局部实现，几乎遍布在通信软件的各个角落。

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

优点

缺点

微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

微服务架构分成三种实现模式。

现在开源的微服务框架比较多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

优点

缺点

云架构（cloud architecture，现在的说法是云原生-Cloud Native）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是可以基于云上计算资源弹性伸缩。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元（Docker容器）；访问量减少，就关闭处理单元（Docker容器）。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

虚拟中间件又包含四个组件：

随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。

云原生架构图的主要特征：

主要目标：

1. 让开发人员聚焦业务逻辑的实现，其他交给容器云平台来完成；

2. 支持业务系统的快速迭代，支撑业务的快速变化和发展；

3. 构建以共享服务体系为核心的业务中台；

下面是我针对某新零售企业设计的云原生架构图，以云和微服务架构为基础构建云原生应用，这里云可以是公有云、私有云、混合云等等。

以上是从不同的视角，对架构进行了分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程（比如自动化发布工具、自动化测试等等）能力的方法来规避，工具工程对软件架构非常重要。