标签：验收 统一 申请 包括 数据 过渡 完整性 一个 资本市场
这篇文章讲述的企业对象是互联网企业，其他行业的企业也可借鉴认为好的地方。
阅读此章前，建议先阅读：https://blog.csdn.net/Su_Levi_Wei/article/details/89313778
阅读此章前，建议先阅读：https://blog.csdn.net/Su_Levi_Wei/article/details/94206222
从自身和身边朋友经历来看，发现现有的大部分小型、中小型互联网企业管理出现的是无所适从的状态。
从企业在资本市场的需求来看，资本市场由于无法对所投资的公司进行时刻的跟踪，也无法得知究竟这家企业具体落地的企业管理，项目管理是如何的；资本市场只能从团队的建立背景、学历背景、经验、经历去考察；因此企业会给市场上拥有以BAT为代表的简历背景或高学历背景的工作人员开出高薪，甚至给予股份期权；而这些工作人员有一些之前可能是在BAT等企业做技术攻克或技术专家，来到新的公司，可能担任的是技术总监，参与到企业战略决策及整体化管理上，进而出现水土不服的情况；也有一些公司也清楚聘请高学历背景的工作人员是为了提高公司资质、及市场价值，或投标需要，因此一开始不会赋予较为重要的岗位。
曾经遇到过的是，BAT出来的测试人员，担任企业事业部负责人，这个事业部采取的市场策略是打电话，但这有个问题，如果打出去的电话，报的是BAT的名称，会有一定客户愿意了解此产品，而如果报的是一家在市场知名度不高，大众化普及度不高的企业名称，转化率可想而知。
从企业自身发展历程来看，从几人、几十人，到上百人的发展过程必然是艰辛的，在这个过程中，企业在市场上找不到合适的管理人员，只能从内部提拔，而内部提拔起来的老员工管理人员要做到独当一面的去担任一个地区分公司的总经理还是有点难；内部提拔的员工还具有个特点就是跟着公司一起成长起来的，并在这套管理办法和行为准则下，看到了公司不断的往上发展，慢慢的壮大，自身也有一定的成就感，但在壮大的同时，可能未发现这套管理办法和行为准则可能已经不适用了，即便发现了，却发现自己一直在这家公司待了那么久，不知道外面其他公司是使用什么管理办法和行为准则，因此也想不到别的管理办法和行为准则，那么可能开始询问身边的朋友其他公司是怎么样的，进而进入试错阶段，因此给公司发展带来了一定的阻碍。
项目生命周期图
1.无论是做客户方产品项目还是自家公司产品，都要对产品行业背景做一定的了解及对行业背景做一定的分析，如果对行业背景都不了解，在与客户方沟通或设计产品时，很难界定到此需求覆盖的用户画像、功能设计取舍，及UI主辅色调的决定等一系列的问题。
2.在对行业有了一定的背景了解后，据项目的产品战略方向，拟定初始的用户定位，对市场进行调研，并对调研结果进行分析，从而进一步的了解现今的市场，避免设计出来的产品不符合时代潮流及用户思想。
3.在进一步了解市场后，基于产品战略方向，可以开始界定及设计产品范围层，进而对用户的需求进行调研。
4.对需求调研结果形成需求调研文档，并进行分析，形成需求分析说明文档（PRD），同步的生成产品框架图（思维导图），进而基于需求分析说明文档（PRD），进行原型设计，而后给予客户方或公司内部进行首次评审，对未清晰和疑点进行讨论、梳理，在此过程中，如果有专业术语，需要在文档中说明对应的专业术语及意思，避免出现理解不一致的情况；如果是有数据埋点的系统，那么产品需要出一份埋点方案文档；
5.如果是做客户方的产品项目，那么此时需要给予客户方领导签字，确认以此文档和原型作为基础进行开发，并确定项目开发周期及计划，避免客户方在项目开发周期中提出新的需求或对需求进行改动，从而带来大量的成本损耗；一般是在UI设计稿确定下来，未进入开发之前，都可以给予客户方修改，因此在UI设计稿确定下来，也要给客户方的领导签字；
6.在需求分析文档出来后，系统架构师就可以开始进行系统的概要设计、技术选型等工作，并在UI进行设计的同时，系统架构师就可以进行系统详细设计，在完成这些设计后，形成文档，在做客户方项目时，需给予客户方确认，避免后期的技术改动所带来的成本。
7.在进入前后端开发时，系统的硬件采购清单，也要确定下来，并提交申请，走流程，具体视实际情况而定。
8.在开发组完成第一个阶段性开发任务后，就要安排对应的测试环境，给予测试组进行测试；在开发组完成此次交付的开发任务后，测试组进行全面性测试，功能性测试、逻辑性测试、压力测试、安全测试，进而完成黑白盒测试等工作，并出具对应的测试报告。
9.在测试完成后，项目团队需要准备部署文档、维护手册、使用手册、项目验收文档、源代码，交付给公司或客户方。
10.对项目的文档需要形成对应的管理方案，避免人员流失带来的额外成本。
以客户方的产品项目角度出发，从项目开发到项目上线，对一些重要人员的功能职责描述。
产品经理一般会兼任项目经理，对整个产品最了解的是产品，且在产品上线后，产品还需要跟进新的需求及产品上线运营的相关指标。
产品经理可以说是整个项目中轴，特别在做客户方的产品项目时，产品与客户方的沟通和接触是最多的，并且在协调双方问题时，产品有着天然的优势。
产品的工作职责包括对项目产品的市场背景了解、市场调研、需求调研、需求文档输出、产品框架输出、原型输出，及据项目的产品战略、定位等信息指导UI设计。
产品需要在产品项目在测试环境上线期间，时不时的上去体验，并提出修改意见，如果产品自己都没有花一定的时间去体验自己的产品，而是依靠开发、测试来提出交互等优化意见是不现实的，毕竟看待事情角度不同。
产品经理兼任项目经理的工作职责包括项目计划管理、客户方沟通、资源协调、断定争议性问题、项目全套文档管理、项目交付性资料撰写和管理，及确保项目有条不絮的进行。
具体的产品必备知识，可阅读：https://blog.csdn.net/Su_Levi_Wei/article/details/89313778（只懂画原型，不懂设计产品架构的，只能作为一个产品助理。）
据产品背景、产品需求、产品原型设计，以此为基础，对UI色调进行调配、设计，进而凸显出产品的特点及用途，并对交互设计做出专业性的评论。
目前很多系统架构师，就是出几张架构图，出一些字段，或对一些技术进行攻关就没了，更有甚者对项目流程都不清晰。
系统架构师的职责包括，对企业代码进行有效性的维护，并形成代码公用库，制定代码编写规范，对企业的系统架构进行完整性分析，并形成文档落地，在产品项目方面，需要对产品进行了解，并出具对应的系统概要设计文档、系统详细设计文档、系统技术选型文档，及与产品沟通、协定系统性能规格文档，并在项目需要时，对技术难点进行攻关，且在必要时，对服务器环境进行搭建、优化。
开发人员有分初、中、高，这里就不做简述了，百度一下一堆。
据产品需求分析说明文档（PRD），对产品系统进行全面性测试，功能性测试、逻辑性测试、压力测试、安全测试，进而完成黑白盒测试等工作，并出具对应的测试报告。
一般做客户方产品项目的话，运维人员可能是开发人员兼任，主要的职责是出具产品部署文档，并与客户方的运维人员共同完成部署。
项目管理混乱是必然的，但项目还是可以进行下去的，更多的问题在于，无人对项目进行负责人，导致项目出现信息不对称，可能各方的了解信息都是按照各自的理解去做的，并且无规范性文档。
现在市场上很多产品经理，可能毕业刚出来找一家公司过渡后，也没有经历过一个真正的互联网项目，就换一家公司干产品经理，或是运营其他人员转型过来当产品经理的，也没有经历过一个经验丰富的产品经理带过，进而出现对产品的误解。
可能会出现对产品框架、产品业务架构等设计都不会，甚至可能出现对这些产品名词都不了解，或产品五层架构设计都不懂。
产品相关性文档的撰写，目前也有一些产品对产品相关性文档的撰写也不会的，导致出现的是，产品文档是东一块，西一块，加上微信沟通记录拼凑起来的，专业术语理解不一致，也导致开发在设计时，所用的英文名和实际的专业术语意义不一致等情况。
因此一个称职的产品经理，需要了解产品框架设计、产品业务架构设计、产品相关性文档的撰写，并了解产品的基础知识。
目前很多系统架构师，就是出几张架构图，出一些字段，或对一些技术进行攻关就没了，更有甚者对项目流程都不清晰。
公司分配到的项目，是得过且过，没有坐完整性的梳理和技术选项等工作，更有甚者看到市场流行什么技术就使用什么技术，并直接把旧的项目搬运过去，导致项目出现底层技术框架和技术规范不统一，未根据新项目的产品定义，产品需求进行梳理，最后可能出现字段名和专业术语意义不一等情况。
标签：验收 统一 申请 包括 数据 过渡 完整性 一个 资本市场
原文地址：https://www.cnblogs.com/-levi/p/11401918.html
