精华内容
下载资源
问答
  • 研发部文档目录结构
    千次阅读
    2020-07-06 15:24:28
    项目目录结构
    序号目录名称目录说明
    101_Documents项目文档目录
    201_Management项目管理文档
    301_会议记录项目组会议的会议纪要
    401_周会
    502_反思总结
    603_临时性会议
    702_项目进度计划
    801_年规划
    902_季度规划
    1003_月规划
    1104_月规划
    1205_模板
    1303_项目进度追踪
    1401_追踪模板
    1504_项目报告
    1601_项目周报
    1702_项目月报
    1803_项目阶段报告
    1904_项目状态报告
    2005_项目总结
    2101_个人总结
    2202_项目组总结
    2306_工作总结
    2401_日总结
    2502_周总结
    2603_月总结
    2704_年总结
    2805_KPI
    2907_立项结项
    3001_立项申请
    3102_结项报告
    3203_项目变更申请
    3304_软件更改申请
    3408_风险管理
    3501_页面登录
    3602_服务器登录
    3702_Business项目合同等商务相关文档
    3801_会谈纪要与客户会谈纪要
    3902_客户资料客户方资料和需求收集的资料等
    4003_项目合同项目合同
    4104_验收记录
    4201_验收测试报告
    4302_验收申请报告
    4403_验收评审记录
    4505_维护记录项目组外出维护项目记录单
    4606_客户反馈用户对产品的反馈和满意度调查
    4703_Requirement项目需求类文档
    4801_需求评审项目需求评审记录
    4902_业务需求业务需求文档
    5003_需求分析业务需求的分析文档
    5104_需求规格需求规格说明书
    5205_需求跟踪和变更需求跟踪、需求变更等
    5304_Design项目设计文档
    5401_设计评审项目设计评审记录
    5502_技术方案项目技术方案文档
    5603_概要设计项目概要设计文档
    5704_详细设计项目详细设计文档
    5805_数据库设计数据库设计文档
    5905_Development项目开发类文档
    6001_开发规范项目开发规范
    6102_开发评审项目开发评审记录
    6201_代码审查项目组内代码互查记录
    6302_代码评审
    6403_单元测试单元测试文档
    6506_Release项目发布和用户手册类文档
    6601_发布说明发布历史、说明书、版本、发布检查表等文档
    6702_帮助文档联机帮助和用户手册等文档
    6807_Deploy部署及用户培训类内容
    6901_用户培训给用户作培训的资料
    7002_部署手册现场施工方案、项目部署手册
    7103_部署文档部署日志、部署报告、部署统计数据、部署过程检查表等
    7208_Configuration项目配置
    7301_项目目录结构项目文档目录结构说明
    7402_用户权限配置项目组各成员权限配置
    7503_服务器配置软件开发过程中对项目的管理计划及其配置
    7601_服务器环境配置
    7702_软件搭建
    7802_Development项目开发
    7901_DataBase数据库开发
    8001_Tables表结构
    8102_Views视图
    8203_Programmability数据库编程:包含函数、存储过程等(若数据库为Oracle,目录名可改为Packages,并将函数、存储过程等封装在包里)
    8301_Functions用户函数
    8402_Procedures存储过程
    8504_Inits数据库初始化(基础数据表初始化数据)
    8602_FrontEnd前端程序开发
    8701_SourceCode源代码
    8802_Release运行程序
    8903_Server服务端开发
    9001_SourceCode源代码
    9102_Release运行程序
    9204_References项目引用的类库
    9303_Testing项目测试目录
    9401_测试方案
    9502_测试用例
    9603_测试数据
    9704_测试结果
    9805_测试报告
    9906_测试工具项目组开发的测试工具的代码和文档
    10007_测试环境测试环境配置
    10104_Integration项目集成版本目录
    10201_一键发布
    10301_发布脚本
    10402_发布流程
    10599_Others其他内容
    更多相关内容
  • 根据技术的职能描述,技术主要是负责企业的技术研究、新产品开发和对企业产品生产实行技术指导,并规范工艺流程、制定技术标准、抓好技术管理、实施技术监督与协调的专职管理部门,受技术总监领导
  • 研发部人员结构优化方案.doc
  • 技术研发部组织结构及岗位职责大全.doc
  • 技术研发部组织结构和岗位职责大全.doc
  • 技术研发部组织结构与岗位职责大全(doc135页).doc
  • 计算机、程序员其实是一门“科学”工作,它不只是增删改查,它涉及到很多点。只有“想清了才能少返工”,因此本人以最常碰到以及最实用、马上拿来可以用为出发点讲透一篇通用设计文档需要怎么写。

    内容概要

    我们今天先从最最常用的平日工作中经常要用到的你的主管、老板让你留文档这种常用技术文档(含设计文档)入手来入门吧。

    第一大段-虎头

    哎,这个名字起的好。今年是虎年,祝愿各位虎虎生威。

    为什么叫虎头?虎头威武吧?虎头是不是很美?它有金黄色的毛发、额头有着明显的“王”字,用国家地理杂志形容老虎,那真是“一头美丽的动物”。

    从感观上来讲是不是夺人二目

    老虎吼一声,那是自带次声波的,一般狗啊、猫啊、其它食草类动物包括人类听到老虎如果近距离吼直接四脚是“瘫软”的,是不是。。。“先声夺人”啊?

    回到正题来。

    业务需求你要对它进行设计、或者是出于某个创新目的你要做设计,上手先说一下这个需求的背景。

    业务需求背景属于“虎头”。

    你不要无脑只是copy一下业务的需求简介,笔者近10多年来包括接触的好多供应商讲标,一般这个需求背景写的好的往往者是深入研究过业务需求和了解本行业眼下潮流知道基本痛点的,那是一种基于自我理解后对业务需求的“再翻译”

    要写一下:

    1. 业务是出于什么目的出的这个需求;
    2. 这个需求解决了本企业、运营中的什么痛点;
    3. 我是如何理解这个需求的;
    4. 我准备怎么去满足这个需求;

    这个很重要,这就是“业务理解”能力。我是一个搞技术出身的,可是为什么近10年来变得口口声声业务、业务呢

    哎,各位!再回到我在10年前写过的博客里你们可以去翻一下。什么叫业务IT界的业务是运用技术手段去解决企业在运营中的重复工作和痛点,为企业在运营和生意上形成不对称竞争优势的手段而己

    我10年前就写过了,对于科学家来说他的业务可能是:天体运动。对于医生来说它的业务是发现早期癌变组织。

    业务就是“解决方案”,解决方案不纯粹是打单、跟单、做财务,而是一个企业要如何引流、挣钱、增单的一种“实际操作的抽象逻辑”,这个抽象逻辑去用IT的语言再实现。因为业务本身=技术实现+企业运营抽象逻辑一切都是业务方案你把性能提高是为了顶住更多的流量、更多的单量,性能优化其实也是“业务解决方案”,一切都是业务解决方案。

    请自动把业务和解决方案划上等号吧!

    借此多说一句:运营逻辑=市场销售=挣钱手段

    这点很重要,技术团队的“业务方案”都要符合运营逻辑。如果两者大相径庭,你这个方案是不合格的。那么我要做设计前我写一下我对你提出的业务逻辑的理解。这个理解可以错、可以对、可以有偏差、也可以有争议。

    这正是业务和技术相互进一步沟通、融合的手段。我从来没有看到过技术解决方案一次就可以满足业务需求的。

    这本来就是一个团队工作,双方就是就这个业务理解和业务需求进行互相进一步探讨才能形成“接地气的解决方案”。

    技术通过这个“需求理解”的虎头可以借此告诉业务方,你的这个需求有90%可以满足,有10%因为等等诸因素需要另一种满足手法。

    有问题就说,有问题才是好事。碰撞才能出火花!

    业务借着技术写得这个“需求理解”也能知道技术是不是可以100%满足或者是有我不知道的坑存在?业务不是万能,业务的话也不是100%必须听,业务也是人,是人他是想不全,是人都有自己擅长的领域和自己不擅长的领域局限。

    因此,需求理解是非常非常重要的。

    设计原则属于“虎头”

    在上手写完业务背景理解后,写上你的设计原则。

    什么叫设计原则?为什么这篇要写在业务需求理解的后面。

    这叫“因为。。。所以。。。”因为有了这样的需求,所以我准备使用如下的“方法论”来设计,它们分别为1、2、3、4等等等。。。。。。

    不需要多,以1,2,3,4控制在100-150字了不得了。

    需求如果不能满足或者业务提出的这个构思有风险也属于“虎头”

    前面说了,业务也是人、业务有自己的领域局限。比如说业务对于某个需求存在“网络个人信息安全法”上的知识的欠缺,此时IT有Information Security也有架构,一眼看出你这样做的话或者你没考虑这些因素,这种需求做出来后你的网站都要被“干掉”。或者说你这个需求不能找开发而是要去找大数据找BI否则APP或者网站会被你搞垮。

    此时你就需要把这些内容写出来,并且以相关风险,或者是“进一步需要澄清”,或者是“需要业务确认”,然后以1,2,3,4这样的方式列出来就行了。

    虎头的内容不会太多。它起到的作用就是:

    1. 有事拣重点说;
    2. 有问题有风险早点报;
    3. 我想要干什么、怎么干抽象总结一下列在最前面以起到重要告知为目的以引发进一步可能的探讨,不要怕探讨,群策群力才能把方案做了更完善;

    这也是一种向上或者向下管理方法中的“管理心理学“。

    有一些领导或者平级是综合能力专家,有一些是技术专家,它们有时看前面那300来个字就知道你这样走下去是否可行、是否有偏差甚至后面可以不用多看就知道你的思路对不对或者你的方案靠不靠谱,亦或者直接觉得这个需求在眼下来说太占资源又不能带来直接经济效应那也就把优先级降低了。

    说白了一点这叫“不要浪费大家时间”。大家想一下,比如说有一个方案,我看过建筑、造房子的方案还,非常非常有意思,给你们说一下:

    当地要造一幅48层的标志性建筑,设计书BLA BLA BLA说了一堆有140多页,最后两页告诉你地下土质疏松只适合建造不超过4层楼的房子并附上地质探测报告。140多页啊?come on,一群人要看多少时候?你不能把这件事放在一开始就说呢?那边挖土机已经调了15台过来了都,油费,运费,高速公路过关费。。。唉。。。

    还有一件事也是很好玩,一个医生对着家属讲了3小时的近乎于“免疫学入门”级话术,最后只花了1分钟来告诉家属这个人已经救不了了

    你们说,这种“沟通”这种“话术”。。。碰到的很多技术人员如果没有经过专业培训都会陷入这种上手给你BLA BLA BLA,而这样的人如果成为了习惯、不自我认知,随着时间一长、次数一多,领导或者平级的同事真的不需要再多听他说话了或者干脆不再多用他去做设计了。

    因此,虎头的本质是体现让沟通更高效

    第二大段-猪肚

    当然,猪头猪后半部一般我们是不太会去吃的,至少普通大众是不会去吃的。

    大家想想猪肚子,有哪些可以吃的?

    1. 麻酱爆肚;
    2. 上海还有一道本地名菜叫青椒炒肚皮,大火一开、小锅一翻,那叫一个嫩呀,那叫一个爽口呀,就热吃,咪上一口“石库门”,那叫一个鲜呀;
    3. 炒肥肠?霍。。。伴着花椒,炒一大碗,看了口水都流下来了;
    4. 夫妻肺片;
    5. 猪排,淮海路著名的存在了近90年的老克勒炸猪排+罗宋汤;
    6. 里脊肉;
    7. 还有很多很多,能举几十种菜出来;

    猪肚是不是很丰富哈

    因此第二大段内容叫猪肚,是代表了第二大段里的东西绝对少不了、且很丰富还“很好吃”

    因此我们会把如下内容都归于第二大段中,它们分别为:

    1. 技术栈

    准备使用的技术栈,它可以为一个“表格”,分成3列:

    • 第1列为:序号
    • 第2列为:使用的技术栈名如:JDK版本、组件版本
    • 第3列为:技术栈说明或者是为什么要用这个组件,很简要的说明一般不超过20个字;

     

    2. 架构设计

    有些需求、模块会比较复杂,那么你的架构图是需要上的。

    架构图掌握好“组件该有逻辑不该有原则”:

    • 该有,把该有的且一定会用到的按照“上下-南北向”数据流走向、“左右-东西向”横向不同组件间的交互以“概要、粗略”的手法画一下。
    • 不该有,逻辑细节、数据流放到下一章不放在架构图里

    (简单架构图示例)

    (复杂架构图示例)

     

    3. 数据流

    各个需求点每一个需求点的“数据流”,即棱、框、图。数据流很重要很重要,它是代码的一种导读,数据流理解错了开发出来的东西不会好到哪里去的。因此在数据流上是要非常的清晰标注出以下内容:

    • 这个数据来自于前端哪个按钮点下去时触发的然后走到什么地方去。
    • 经过了controller层哪一根api。
    • 落到了哪个service。
    • 在这个service里怎么走的redis、redis里有值如何、没值如何。
    • 匹配逻辑的必要条件Y/N分支。
    • 然后跑到了数据库里哪个表进行了什么样的条件(>1、<1、=101)查询。
    • 图、图片下部居中加括号简要这个图的说明性代表性标题-又叫图标题、图片上完如果这个流程图、逻辑图、数据流比较复杂辅以1、2、3的简要说明
    • 必须对每一个需求点进行数据流的说明
    • 当然后期水平高了可以把数据流+泳道就成了流程图又叫“BPM”或者是“Workflow“图,一张图里表示。当然你也要分情况的。如果系统交互一多导致了你的word在15寸屏幕甚至是投影打出来这个字都要凑到屏幕前5公分才看得清,或者把个文档的局部放大300%以后才看得清,这种效果就不好了。
    • 适当切割、适当合并你的图。

     (简单数据流图-其实是一种逻辑图)

    (复杂逻辑图)

     

    4. 核心技术/算法

    有些系统、模块是含有比较复杂的算法的如:卷积神经网络-CNN算法或者是“希尔排序”或者是“令牌环桶限流”。你要写出这个算法、或者是你使用的第三方开源的算法库的调用是什么、为什么、原理、使用场景在哪些地方;

    5. POC

    poc不是说要求把每个代码都写出来,如果是每一行代码都写出来这就变成了直接上代码了不用设计了。POC指的是一些影响面非常大的、核心的框架级别、原理验证报告放在设计文档上。POC、POC,即Proof Of Concept的缩写。有时一个模块看看很大其实它的核心原理和技术点只有3个POC,那么每个POC不会消耗你3个例子-5天时间的。

    举例来说支付超时后的补偿,它可以有周期性跑JOB来补偿也可以有“延时队列”来跑补偿,那么这两者的优缺点是肯定有的。

    • 一个容易造成并发场景下的数据库锁。
    • 另一个高效当然增加了额外的MQ组件但是不会存在数据库在多个应用服务器跑批时互锁的问题。

     (POC结果-两种注册中心的POC结果对比)

    为了证明这两个优缺点和性能,你是不是需要做一个POC,这个POC当然也要涵盖这两种技术呢?

    当然此时因为是POC,你可以模拟数据、模拟场景、代码和工程甚至可以unit test case级别的就可以了;

    6. 数据库表设计

    请把每一个涉及到的数据库表以如下形式列出

    字段名类型长度是否必填默认值字段涵义
    xxxxint8Y-主键,使用分布式自增主键
    xxxxnumber
    xxxxvarchar32Y-
    xxxxtimestamp-Ycurrent_timestamp()

    如果表和表之间(物理上或者逻辑上)存在ER,那么你必须要画ER关系图,如果你的ER图有多达几十张表,那么请根据“业务领域”分类分开成一个个ER图附上(太多开源工具可以根据数据库表逆向生成ER图,我就不一一介绍了,我还真没看到过有人用手把几十个、上百个表手绘的)。

     (ER图示例)

    7. 网络拓扑设计图

    到了这点我又要说了。我不知道为什么现在的“程序猿”们从不关心网络结构设计的。这个点我不想展开了,TCP导论、TCP概要、TCP原理、网络基础,这些大学都是学的。IP隔离、IP分层、这些是计算机大一、大二的课程,是基础。

    至少。。。哎。。。兄弟,你把这些点写了,就是这个组件要用到以下:

    • 几号端口
    • 只进不出还是只出不进还是in & out
    • TCP还是UDP还是Both

    为什么要画这个呢?我看到太多太多。。。真的。。。我这边能看到50%左右的猿或者是一些公司给到的网络拓扑设计上写的是“开放所有端口”。没有分层概念都放在一起好了。没有告诉我哪个部件是最吃流量。也没有告诉我需要百兆、千兆、万兆带宽的。

    对于Mbps、Gbps甚至TPS和QPS都搞不清的。

    一个正规的企业它至少有“南北向、东西向”的网络分层原则,这是等保2的内容啊更不要说是做电商、零售类的是需要等保三级证书的啊,如果等保证书拿不到这个公司就直接可以“被关门”了。

    因此,都是有:“原则上close to all”,而需要时:再“按需开放端口”的。

    一个典型的基本防火墙申请是有如下内容:

     所以网络拓扑图里至少要包括:

    1. 网络的分层设计
    2. 防火墙端口列表

     (简单的网络结构拓扑图)

    要不然:IT运维、DEVOPS自己去设计这个结构喽?那要你架构干什么?要你研发、开发干什么?

    要是你防火墙端口来个open to all,直接公司里搞IT Security也会把你“毙”了。

    8. 模块、系统达到的性能指标

    从不考虑的?是吧?我们坚持的是要“程序员”不要“猿”。

    你的设计或者要求达到24*7?10*5?每个接口、API响应时间、多少个CPU、峰值使用内存,这你必须要写的吧?

    不写,运维说我给你一台2核2G内存的VM你去用好了。

     (一个简单by门店商品查询的性能要求设计例子)

    9. 安全设计

    • 非法字符要不不要过滤?你准备怎么过滤?使用前端的javsscript、APP、小程序前端过滤?过滤方法使用“黑名单过滤”还是“白名单过滤”。
    • 验证码重试次数?4位字符还是6位字符?底图打斜杠还是数字错位显示还是点选文字?
    • 至少不要有log4j漏洞吧?
    • 权限矩阵,就是到菜单级别还是按钮级别+角色?还是+用户还是到字段级别权限并且要把敏感字段内容mask掉?
    • 数据查看权限是by省、by市、by部门?
    • 需要对哪些db schema是读还是需要写还是both需要开发?
    • https还是http就够用?泛域名证书还是单域名证书?
    • 有没有跨域问题?
    • 用jwt还是web basic authentication(用户名密码登录)就够了?
    • 加解密你用bouncycastle还是jdk标准的?密钥算法?长度?

    猪肚!对吧?很丰富!

    以上9大点把它们写清了。有些图我是有颜色的,甚至画的有点“beautiful”,这些都只是“浇头”,刚开始写根本不需要关注这些beautiful。如何beautiful我会在后续的章节特别花费时间传授。你甚至可以用文字、表格+黑白图,1、2、3、4的讲清,enough了。

    第三大段-豹尾

    哎,这个“豹尾”很好玩,为什么叫豹尾呢?

    大家注意看哈,豹子的尾巴一般是翘起来的,它的尾尖指向了它的“头”。

    这叫“点题”、“回到主题”。即:总结啊

    各位看我在写“猪肚”部分时,列了很多点,每一点下面我都会有“说白了。。。”,“总结一下。。。”,“敲黑板。。。”一类的话术对吧?这种就是总结。

    你不要写了一堆,最后没有结论。这就不是豹尾了,这是“蛇尾”甚至“没尾”,你以为是诺兰的“烧脑片”留给观众的是一个“开放式结局”呢?

    要总结,因为。。。所以。。。因此。。。

    这边就是“因此。。。这个东西怎么怎么样,可以怎么怎么怎么满足你的需求”。

    千万记得,不要把风险或者根本不可行的这样的内容放于“豹尾”处

    豹尾处可以放上这样的一层意思:“因为基于上述需求、设计。因此我需要多少硬件、开发、资源,甚至需要买点什么样的工具、商业组件”。

    所以在豹尾处,我们经常会放什么知道吧?

    1. 放项目计划、甘特图;
    2. 放财务计划(预算);
    3. 人员或者是团队的组成;
    4. 甚至也有一同放上的招聘计划;

    领导、董事会、或者相应的leader看完。。。嗯嗯。。。写了不错,不过有几个错别字(领导很喜欢挑错别字)。。。然后拿出笔或者是私人图章来,哈一口气,“梆”一声,那这就给确认了。或者邮件回一个“go”。

    这事就搞定了。

    总结

    当然,上面有一些半开玩笑的话术(当然平时大家也碰到很多哈),设计文档的主要目的就是:

    1. 形成团队知识库的积累;
    2. 使得企业、团队可持续发展;
    3. 想清楚再做(这点是最最重要的);

    因此,一个标准的程序员所需要涉及到的知识、技能点其实也无外乎上述这些“小标题”,可惜的是很少有人并且在我看来少于10%的市面上的公司、团队是这样操作的。

    但是我告诉你们呀,BAT等一些公司对于碰到“汇战”、“攻坚战”、“重大项目”、“中型模块开发”时就是需要这些设计的。

    并且,一点不夸张的告诉大家:为什么一些公司面试有6-8轮,每一轮就是在面这些不同的点。

    随便举例来说,鹅厂的面试好了:socket通讯、TCP原理、C++、数据结构、基本OWASP TOP10、百万级并发秒杀场景设计、4亿条URL里去重。唉。。。就是这些技能点的集中表现。

    这是“基本”,基本中的基本。

    95-2010年间的“中国程序员”分为4个级别考核,用现在的话说这个证放在现在的作用就是如果你拿到高级等级证书,那么你在北京、上海居住证申请时是可以加分的(现在已经没有了,主要是因为技术已经普及了)。4个等级里的程序员第二个级别(中级)时已经要求到了DB设计、程序设计、数据结构设计、网络TCP原理设计这些基本要求了。

    如果还只是认为程序员是增、删、改、查。。。我建议你快点改行去。

    现在明白了我说的:计算机、程序员其实是一门“科学”工作,它并不是像现在外面的“沦为了X农”这种东西。你一直以来觉得是“X农”只是因为你没有看到正规的操作而己。

    最后是结束本篇内容。后面会进一步讲文档能力=软实力的另外一种表现手法。

     

     

     

     

    展开全文
  • 研发部 svn git中的的项目管理目录

    千次阅读 2019-01-04 14:55:06
    项目目录结构 序号 目录名称 目录说明 1 01_Documents 项目文档目录 2 01_Management 项目管理文档 3 01_会议记录 项目组会议的会议纪要 4 01_周会 5 02_反思总结 6 03...
    项目目录结构
    序号目录名称目录说明
    101_Documents项目文档目录
    201_Management项目管理文档
    301_会议记录项目组会议的会议纪要
    401_周会
    502_反思总结
    603_临时性会议
    702_项目进度计划
    801_年规划
    902_季度规划
    1003_月规划
    1104_月规划
    1205_模板
    1303_项目进度追踪
    1401_追踪模板
    1504_项目报告
    1601_项目周报
    1702_项目月报
    1803_项目阶段报告
    1904_项目状态报告
    2005_项目总结
    2101_个人总结
    2202_项目组总结
    2306_工作总结
    2401_日总结
    2502_周总结
    2603_月总结
    2704_年总结
    2805_KPI
    2907_立项结项
    3001_立项申请
    3102_结项报告
    3203_项目变更申请
    3304_软件更改申请
    3408_风险管理
    3501_页面登录
    3602_服务器登录
    3702_Business项目合同等商务相关文档
    3801_会谈纪要与客户会谈纪要
    3902_客户资料客户方资料和需求收集的资料等
    4003_项目合同项目合同
    4104_验收记录
    4201_验收测试报告
    4302_验收申请报告
    4403_验收评审记录
    4505_维护记录项目组外出维护项目记录单
    4606_客户反馈用户对产品的反馈和满意度调查
    4703_Requirement项目需求类文档
    4801_需求评审项目需求评审记录
    4902_业务需求业务需求文档
    5003_需求分析业务需求的分析文档
    5104_需求规格需求规格说明书
    5205_需求跟踪和变更需求跟踪、需求变更等
    5304_Design项目设计文档
    5401_设计评审项目设计评审记录
    5502_技术方案项目技术方案文档
    5603_概要设计项目概要设计文档
    5704_详细设计项目详细设计文档
    5805_数据库设计数据库设计文档
    5905_Development项目开发类文档
    6001_开发规范项目开发规范
    6102_开发评审项目开发评审记录
    6201_代码审查项目组内代码互查记录
    6302_代码评审
    6403_单元测试单元测试文档
    6506_Release项目发布和用户手册类文档
    6601_发布说明发布历史、说明书、版本、发布检查表等文档
    6702_帮助文档联机帮助和用户手册等文档
    6807_Deploy部署及用户培训类内容
    6901_用户培训给用户作培训的资料
    7002_部署手册现场施工方案、项目部署手册
    7103_部署文档部署日志、部署报告、部署统计数据、部署过程检查表等
    7208_Configuration项目配置
    7301_项目目录结构项目文档目录结构说明
    7402_用户权限配置项目组各成员权限配置
    7503_服务器配置软件开发过程中对项目的管理计划及其配置
    7601_服务器环境配置
    7702_软件搭建
    7802_Development项目开发
    7901_DataBase数据库开发
    8001_Tables表结构
    8102_Views视图
    8203_Programmability数据库编程:包含函数、存储过程等(若数据库为Oracle,目录名可改为Packages,并将函数、存储过程等封装在包里)
    8301_Functions用户函数
    8402_Procedures存储过程
    8504_Inits数据库初始化(基础数据表初始化数据)
    8602_FrontEnd前端程序开发
    8701_SourceCode源代码
    8802_Release运行程序
    8903_Server服务端开发
    9001_SourceCode源代码
    9102_Release运行程序
    9204_References项目引用的类库
    9303_Testing项目测试目录
    9401_测试方案
    9502_测试用例
    9603_测试数据
    9704_测试结果
    9805_测试报告
    9906_测试工具项目组开发的测试工具的代码和文档
    10007_测试环境测试环境配置
    10104_Integration项目集成版本目录
    10201_一键发布
    10301_发布脚本
    10402_发布流程
    10599_Others其他内容
    展开全文
  • 研发部的人员素质要求及自我培养

    千次阅读 2022-04-20 08:45:12
    纵观世界经济发展,信息化已成为全球化的迫切需要和必要保证.,由此可见,IT行业极具发展前景。本篇文章针对研发人员的素质要求及自我培养进行系统讲述。

    IT行业发展已经走的很远了,纵观世界经济的发展,经济全球化进程明显加快,信息化已成为全球化的迫切需要和必要保证。世界范围的产业结构调整和信息技术进步,必将对中国信息产业的发展产生深刻影响,所以IT行业的前景还是不错的,但由于IT发展很快,所以要知道研发人员的素质要求及如何自我提升。

    一个好的研发人员自我培养,需要从不同角度出发,工作能力是一个方面、对自身定位和了解也是一个方面,程序员的工作能力修养包括需求理解、功能设计、沟通确认、代码规范、成果验证、代码重构优化等,对自身定位和了解是要对自身的优缺点需要自我剖析,去除劣根性,意识态度端正,提升自己的核心竞争力等。

    1整体介绍

    了解行业的发展,了解自身的不足,了解自身的那些优缺点,了解自己更合适做什么工作,知道自己做什么才能发挥出自身的优势,意识态度端正、去除劣根性,这样你才能在你工作中发光发热,你在你的职业生涯里才能走的更远。

    1.1行业发展

    IT行业在我国经济中是一个相对较新的行业,但已经为国民经济做出了显着贡献。信息就是力量。没有最新和正确的信息,人员和组织将无法及时做出适当的决定。信息是发展的基础。它是人类生活方式的基层。信息改变了整个社会。没有人可以否认信息在现代瞬息万变的世界中的重要性。

     

    1.2自我剖析 

    一个技术人员想要走得更远,需要对自己理解,尺有所短,寸有所长,每个人都不是完美的,都会有自身的不足,而这些确定很有可能就是你职业生涯里的绊脚石,所以你要把它踢开,所以要了解自身的不足,如果你的基础差你就加强基础知识,补全自己的知识体系,如果你沟通不行你就经常联系,常与人沟通,但不要说一些没有营养的话题,找一些与自身行业相关的话题,这样你既增长了自己知识储备,也提升自己的语言表达能力一举两得。 

      

    1.3能力体现 

    了解了自身,知道了自身的优势和不足,明确了自己的发展方向,就要提升自身的能力了,首先要了解研发人员的述职要求,人员从5个能力体现: 

      

    1.文档能力:体现自身逻辑能力,加深自己的思考,体现自身的知识积累。 

    2.沟通能力:是每个人都要具备的能力,因为人与人交流是无时无刻不在进行的。 

    3.专业能力:是指产品开发能力,检验代码质量,代码逻辑等。 

    4.业务能力:研发人员不能只是技术好还要懂业务,因为懂得业务才能把产品做好,客户才能应用。 

    5.宣讲能力:产品交付发版也需要演示宣讲的,还有研发部门也有可能会给客户进行演示产品的,所以也要具备宣讲能力。 

    2文档能力 

    上述所示文档能力是提升自己的逻辑能力,提升自己的思考能力,加强自己的对事情的宏观把控能力。 

    2.1能力体现 

    一篇好的文档有如下体现: 

    1.拟定的标题必须讲究逻辑性,标题都要符合一定的逻辑关系,做到层次清晰。 

    2.文档要是先整体,再细分,内容要有深度、也要有高度。 

    3.文档都要对外发布,写的时候就要考虑到读者,要换位思考。 

    2.2自我检验 

    如何检验自己的文档能力: 

    1.文档大纲是否符合逻辑,大纲代表你的逻辑思维,大纲逻辑不对就是不会写好文档。 

    2.不能长期写一个类型的文档,长期写一个类型的文档是无法提升自己的能力的。 

    3.文档的高度、深度是否一直没有提升。 

    2.3如何培养 

    1.如果是在办公室正处于工作中,可以拿起手边的纸笔,随手记录;如果是在上下班的路上或是在处理其他事件时,可以用手机的备忘录随时记录。 

    2.多看一些资料,了解相关技术的内容、API等这样能更好的完成自己的文档,同时也能给后续功能的完善打下相应的基础。 

    3.阅读他人的优秀文档,将自己处在一个学习的视角,来学习他人文档中优秀的部分,进而提升自己的文档能力。 

    3沟通能力 

    沟通是每个人都要具备的能力,因为人与人交流是无时无刻存在的,研发人员是需要与技术人员交互、与领导交互、与同事交互,也会直接面对客户交互的,所以研发人员也需要具备沟通能力素质模型。 

    3.1能力体现 

    沟通能力体现的是语言表达能力,如何让人理解你说出的话,并且快速理解别人说的话就是沟通能力。 

    1.研发工作一般是由一个团队完成的。只有沟通顺利,整体完成的研发效果才会符合客户的要求,客户整体满意,不断地增加订单整个公司才会更好。 

    2.领导也是一种资源,只有与领导交流清楚自己的问题,领导才能更加明确指出问题在哪,你才能更快地完成自己的任务。 

    3.与同事沟通交流你能明确表达出你所说的话意思,并且对方也能够快速地理解你,让一次交流畅通无阻进行,快速传递任务需求。 

    3.2自我检验 

    1.当你拥有较差的沟通能力,那么研发工作最开始的需求交流将是一场灾难。 

    2.当你跟领导沟通的时候无法说清你要请教的问题时,领导会无法明确指出你问题,会消耗很多时间。 

    3.倘若沟通能力较差,你和同事们就好像隔了一道墙互不相通,交流起来会越来越急躁。 

    3.3如何培养 

    1.保持真诚的态度:平常跟别人聊天或者谈工作的时候,必须保持真诚的态度,这样别人就会感觉你是真心待人的,让对方感受到你的诚意,双方一定要保持平等的关系,切记不能给别人一种高高在上的感觉。 

    2.多和别人交流:要想沟通能力有所提升,必须多跟别人进行交流,学习再多的沟通技巧都是纸上谈兵,最终还得通过实践才能看到效果。平时可以多跟家人、朋友坐下促膝谈心,分享自己平时的生活,经常交流语言表达能力自然就得到提升了。 

    3.善于倾听别人:语言表达能力的技巧就是善于倾听,花时间多听别人是怎么说的,并且提出自己的见解。这样的话,在一定程度上也能够提高我们的沟通能力。 

    4专业能力 

    专业能力是代码开发能力,这是研发人员的饭碗,所以它是研发部门必要的能力素质之一。 

    4.1 能力体现

    一个优秀的程序员的专业能力体现在: 

    1.:编写代码能力强,能在研发工作遇到困难时,准确地给出相关的解决思路,解决方案。

    2.:查看代码的问题能力突出,当程序中出现问题的时候可以快速地定位问题、发现问题。 

    3.:代码知识扎实,能阅读某框架或技术的源代码,能看懂好的代码也是一种能力的体现。 

    4.2自我检验 

    如何检验自己的专业能力: 

    1.工作效率是否够高,工作交流低会导致任务进展缓慢,导致使用产品人员无法按时完成他们的工作。 

    2.代码的bug率,代码bug太多会导致较低使用人对产品信任度。 

    3.对优秀的源代码能阅读的程度。 

    4.3如何培养 

    1.多多利用工作之余的时间,用可用的时间最大限度地丰富自己的知识储备量,拓展自己的编程思维。 

    2.拒绝摸鱼,工作时间也要最大地利用起来,每一次功能的开发或是完善都是对专业能力的一种提升。 

    3.多多阅读优秀的源代码,最简单的提升方式莫过直接吸取别人分享的精华。 

    5业务能力 

    开发人员通过业务了解需求、了解功能,才能把功能做好,开发人员在需求分析、功能设计、功能开发阶段都需要了解业务才能更好的完成产品开发,才能有核心竞争力。 

    5.1能力体现 

    一个优秀的程序员的业务能力体现在: 

    1.能时刻的站在客户的角度上去完善产品。 

    2.能在自己的产品中给客户很好的用户体验感。 

    3.能在公司的项目中予以技术组的同事,产品售前的帮助。 

    5.2自我检验 

    如何检验自己的业务能力: 

    1.产品是否能达到客户的认可。 

    2.了解自己的产品,能将自己的产品以最好的方式展示出去。 

    3.能否快速理解客户的需求。 

    5.3如何培养 

    综上所述程序员也需要了解业务,只有了解业务成员才能不会被时间所淘汰。 

    1.开发阶段经常沟通,需与项目组技术人员沟通,他们是第一现场是比你更多接触业务的,所以不懂的一定要问。 

    2.开发时候经常要记笔记,把不懂的记录下来,然后问明白人,了解清楚后写一篇文档加深自己的理解。 

    3.参与项目了解客户的第一手需求,每次开发时想想之前客户提出的需求,调整自己的功能。 

    6宣讲能力 

    对于研发部门而言不是你在项目现场不会直接接触客户就不需要宣讲,因为每次的发版演示、售前的产品演示都是需要研发部门的,所以宣讲能力也是研发人员的素质模型之一。 

    6.1能力体现 

    1.在整个介绍过程中要注意效果,并突出重点,给客户眼前一亮的感觉。 

    2.使客户了解产品价值,以及效果是否满足当下提出的需求等,良好的演示可以增加彼此之间的信任感。 

    3.与客户交流时也能快速反应,说出功能具体作用,表现出你非常了解这个产品,并且说出产品的价值。 

    6.2自我检验 

    1.如果对产品了解不足,会导致被客户问到的时候无法快速响应,会导致客户对你质疑。 

    2.演示的时候不分重点,没有层次,会导致听众无法理解你讲述的是什么,导致本次宣讲没有突出产品的亮点。 

    3.演示前没有准备充分,没有预制好数据,导致添加数据时间过长,出现冷场现象。 

    6.3如何培养 

    1.演示时候前期准备,可以拟一份演示方案,有了演示整体流程大纲,在演示时才会有底气,做到心中有数。 

    2.梳理演示思路演示不能东扯西扯,要有一个连贯的逻辑,从哪里来到哪里去,并且要明确哪些需要重点演示,关注哪些重要信息点,有针对性的演示才会事半功倍,达到预期的效果。 

    3.练习演示内容,练习时要梳理好演示的话术,以及需要演示哪些界面效果,同时对于执行缓慢的部分,要配有话术介绍,避免长时间卡顿带来的尴尬现象,只有前期准备的尽可能完善,才能在演示中不失去思路,不慌乱,成功将功能呈现在他人面前。 

    7总结分析 

    所以一个研发人员入行后,要对自己负责,要知道自己的今后的发展方向,要了解自身,掌握上文所述的能力,所以要不断的努力提升自己能力,端正态度、意识到位、找到合适方法,自我定位。 

    7.1自我定位 

    认清自己是每个人很难做的事情,也是必须做的事情,知道自身的优缺点,从而进行对症下药,知道自身长处,就会以这个长处为起点,不断扩大自身的优势,把其变成自己的核心竞争力,所以要找到一个自己擅长的领域不断学习,这样才能进步才能有大的发展。 

    7.2能力提升 

    每个人初入职场时都是一张白纸,时间的画笔在纸上留下痕迹,后来,有的白纸变成一幅五彩斑斓的画,有的白纸成了一张中规中矩的表格,有的白纸只是一笔笔杂乱无章的线条。一幅画的成型,需要观察、构图、定稿、着色等多重步骤,工作中的成绩亦不是轻易就能取得。会总结的人经常反思自己、提升自己,不会总结的人就一成不变,只为了完成工作,当经历了学习成长、总结反思,改变就会在工作中一点点体现,差距就是由能力高低而逐渐形成的。 

    7.3如何发展 

    产品研发人员编程只是IT行业最基本的一个环节,这对于每一个程序员,都必须要认清的事实,所以我们对自身的规划不能只考虑编程,你的工作最终都是服务于一个核心业务,人的一生有很多阶段,努力去选择目标,要了解自身优势,加强自身能力,是多学多看的阶段你根据以前的经验,找到一个适合自己的领域去发展,你不可能只能为了编程而编程,你要有自己的职业规划,有自己的目标,要在自己擅长的领域发光发热,成为上面提到的某一方面的专家,这才是我们大部分程序员在职业生涯中,不断累积的真正财富。 

    产品研发人员都要懂业务,研究业务模式,知道生意的痛点是什么。大部分的用户往往不知道自己想要什么,所以很难提出准确真实的需求,开发人员学习业务知识,用软件工程的方法,将各种想法变成产品让用户使用,收集反馈并且快速改进,越来越接近用户的真实需求,学习业务,成为业务专家,也以最佳的状态投入到激烈的市场竞争当中去。 

    展开全文
  • 软件研发部管理制度

    2020-04-14 18:00:00
    为加强对公司软件研发部门工作管理,缩短开发周期,提高软件开发质量,降低开发成本,提高开发效率,特制定软件研发部管理制度。 第一章、总则 为保证日常工作正常有序的进行,让开发中各个环节更紧凑,更可控,需要...
  • 测试管理之--文档管理

    千次阅读 2018-05-05 17:46:13
    测试文档是整个测试中的重要输出;测试文档同时也贯穿测试活动的始末;在测试计划、测试设计、测试执行、测试验收等过程中会产生各种各样的文档。测试文档的最终目的是为了更有效的测试及保存测试组织资产。我们在...
  • 5数据库设计规范.doc

    2022-06-16 15:27:54
    " " 编制部门:产品研发部 发放范围:产品研发部 目录 1. 概述 5 2. 数据库设计的基本原则 6 3. 数据库建模 7 3.1 数据分析 7 3.2 数据关系分析 7 3.3 数据量分析 7 3.4 扩展性分析 7 3.5 数据字典(参考) 7 3.5.1...
  • 如何提高团队的研发效率呢?

    千次阅读 2021-04-25 00:09:03
    研发效率是在现代企业都关注的,注意是因为靠谱的工程师是有限的,而且软件工程师的人力成本较高,时间成本更高。在大多数情况下,软件工程是一个团队活动,通过协作实现突破。好的想法从不匮乏,但高速...
  • 测试部门属于研发部副总裁直接管理,见如下结构图  公司研发部的组织结构图  对于从事软件研发的组织来说,工作类型至少包括项目管理、产品设计、编码、测试、质量保证和软件配置管理,以及其它人员,如文档编制...
  • 蒋杰 三影塔CIO之家 目前腾讯数据平台的技术团队规模和结构是怎样的 目前我们数据平台共有200多人整个数据平台是按照基础平台核心应用产品包装和质量监控的思路分为四部分 数据中心负责建设管理腾讯大数据基础...
  • 智能环境控制系统.doc

    2022-07-01 21:47:43
    (2)低温低湿对档案材料的影响:使纸张水分过度蒸发,导致纤维内 结构破坏,使得纸张变脆,机械强度下降;(3)温湿度波动幅度过大或过快对档案 材料的影响:使得档案材料因胀缩不均而产生内应力,易使其强度...
  • HTML制作入门教程.ppt

    2020-05-14 10:16:42
    技术研发部 蒲小龙编写 陕西电力信通有限责任公司技术研发部 蒲小龙编写 陕西电力信通有限责任公司技术研发部 蒲小龙编写 HTML制作入门教程 介绍的内容 1HTML语言简介 2标记写法 3HTML 语言的结构 4构成网页的基本...
  • 开发单位:研发部 1.4 编写目标 本系统局限于个别企业的模式,具有通用性,简便易懂,符合企业一般的管理模式。 1.5 定义 简要说明本系统设计说明书中涉及的专门术语、容易引起歧义的概念、关键词缩写及其他需要解释...
  • 开发单位:研发部 采购管理子系统与库房管理子系统、财务总帐子系统、成本核算子系统 1.4 编写目标 本系统应不局限于个别企业的模式,应具有很强的通用性。系统的各项功能及处理方法应满足不同管理模式的需要。处理...
  • 技术研发团队管理计划方案书

    千次阅读 2021-03-17 17:23:17
    平台研发部计划按岗位划分成立4个小组:产品设计组、前端研发组、后端研发组、测试支持组,4个小组分别设立组长(主管),组长需在本周提出小组管理思路,要求如下: 思路 小组工作任务管理:组员任务分配、任务...
  • java开发工作总结.docx

    2020-07-24 23:19:18
    java开发工作总结 篇一研发部java开发工程师20XX年工作总结 20XX年年度总结 尊敬的领导 您好在20XX年11月我很荣幸地进入公司加入了研 发部Java技术开发团队认识了友善严谨的领导热心和 睦且技术优秀的同事很是开心在...
  • java工程师工作总结 篇一研发部java开发工程师20XX年工作总结 20XX年年度总结 尊敬的领导 您好在20XX年11月我很荣幸地进入公司加入了研 发部Java技术开发团队认识了友善严谨的领导热心和 睦且技术优秀的同事很是开心...
  • 浅谈软件研发管理体系建设

    万次阅读 多人点赞 2018-12-08 21:40:52
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,...关于研发管理,百度百科中这样定义:研发管理就是在研发体系结构设计和各种管理理论基础之上,借助信息平...
  • Eplan绘图软件:EPLAN 中的项目结构

    千次阅读 2021-01-02 23:34:15
    EPLAN 中的项目结构 有很多电气工程师不清楚 EPLAN 中的“项目 结构” 为何意,亦不甚清楚“高层代号(=)” 和“位置代号(+)”的含义及用途。当拿到别人的图纸都是“=CA+A1-F1″这样的标注时,很难或根本无法准确地...
  • 24 讲座内容 一项目管理相关概念 一项目管理相关概念 Q二软件项目管理系统 觀 三项目管理层次结构研发部的建设方面 一项目管理的相关概念 1?1什么是项目? 根据美国项目管理协会(PMI)的定义项目是为完成某一独特...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,300
精华内容 5,720
热门标签
关键字:

研发部文档目录结构