hursing的博客

Review可分为3个级别，高一级会包含低一级的内容。不熟悉相关代码，只能review是否遵守规范，以可读性为主。规范按照【语言>框架>系统平台>项目>公司>跟上下文相同】的优先级来遵守。

目录团队分工与意识规范工具与流程文档组织规范需求总表需求文档需求评审和工作量评估排期和立项延期和需求变更设计师规范开发规范提测流程和免测标准问题跟踪系统使用规范测试报告验收、发布、上线线上故障项目周报结项集体加班制度参考文章《从“结果导向”到“目标导向”！ 》《如何优化程序员的内部培训》 《如何做好迭代规划》《如何写出受技术欢迎的需求文档》《倒...

加班的标准及时上线能带来可观收入外力因素（政策、时事、市场、第三方故障等）延期了太久，要把进度赶回来别人过失导致的个人加班，应根据自己意愿决定是否加。不加是合理的，项目延期是符合流程的。如果选择加班，那是个人为项目顺利所做的努力，是高绩效的有力依据。加班完了最好有意识地记录自己的贡献，在述职时列出这些积极表现。决定集体加班需要由产品和项目共同决定，并且有邮件通知。不满足条件的，不...

1.结项会议时间：上线三天后，有两天的线上情况观察时间主持人：项目经理参会人员：实际参于项目的所有人员，主管酌情参与会前准备：把需要投影的东西给主持人，自己准备好发言提纲会议流程分为两部分第一部分，结果总结。按以下次序发言：项目：简单回顾整体项目进度，消耗的人力时长，偏差多少与原因产品：线上版本相关数据（脱敏）。主要目的是让大家知道劳动成果的意义。测试：简要说测试报告的重点，突...

原则有事起奏无事退朝项目经理可在周一上午召开站会收集信息，各职能负责人需积极配合。周一下午3点前发出邮件邮件接着立项邮件全体回复，每周接着上一周发直到结项收件人：项目组群标题：【项目周报】xxx（项目）mmdd（日期），例如 支付宝1018正文示例：Dear All，（1-3句话总结情况。）（当前进度，是否存在风险。有就说明异常情况与原因，提醒注意，请求协助。）本周项...

故障定义发布生产环境并验收通过，确认放量后，还发现的bug都算线上故障报告标准什么情况的线上故障 需要 报告？对营业额有大影响。例如无法打开页面，无法操作对用户口碑有大影响。例如无法支付或提现什么情况的 不需要 报告？简单的用户体验或纯UI的问题不影响用户使用核心功能的问题处理流程无论谁发现的，首先应该 反馈给测试同学测试确认重现步骤后，报bug给开发解决，并由 产...

验收者产品、UI、后台系统使用者（运营、客服、风控等）验收进入条件测试流程结束的下一步是验收。进入验收的最理想标准是所有bug都已关闭。如果时间紧张，可以放宽到 同时满足 这两个条件：优先级为“下次提测前解决”的bug都 已关闭优先级为“发布前解决”的bug 不超过人均2个测试环境验收测试向验收者演示主流程。验收者自己操作，或让测试演示更多流程。UI核对。主要是颜色值和像...

原则最终目标不是故意找茬，而是让管理者知道哪个环节有问题，能及时做调整要能反映质量，不要写成在描述需求或业务质量问题要具体到职能或人；不能模棱两可，看不出谁要为问题负责记录测试手段，为线上故障的漏测找依据邮件通知收件人：项目组群抄送：测试组群标题：【测试报告】xxx项目y.y.y（版本）[第z轮|release]例如【测试报告】微信1.2.1 t1报告模板与示例1....

报告规范指派：直接指派给你知道的负责人，否则先给测试负责人提优化建议应指派给产品经理模块/页面/类型：尽量选对，不同模块通知到的负责人可能不同不知道的话选其它，由测试负责人再修改标题：一句话总结出错的位置、现象；或者是建议做法思考一下要搜索出这个bug时会用什么关键字，这个 关键字应该存在标题里重现步骤：说明问题的现象是什么，为什么这算是一个bug可以补充说明...

规则有前端或客户端参与的需求，由他们来提测，否则是后端直接提测。提测记录可以写在IM群公告上，不要覆盖同版本的提测，每个版本发布后由测试同学剪切保存到ODS或测试报告中。如果有项目管理工具帮助或者研发有资源自己做一个提测记录系统那就更好了。（术语解释请参考《排期和立项》，tag的格式请参考《Git分支管理规范》）流程开发自测，确保主路径没问题。如果测试组有提供冒烟测试，必须冒烟都通过...

Gitgit的用户名为自己名字的小写全拼，邮箱为公司邮箱，方便追溯提交者。命令行操作示例：git config --global user.name mynamegit config --global user.email myemail@example.comgit commit的log原则：必须说明提交的意义，不能是简单无意义的文字bug fix应写上是解决哪个bug，可复制禅......

前置说明这里只关注影响合作的规范，跟“好不好看”有关的标准是设计师内部的专业规范，这里不涉及。对设计师的要求，可参考《程序员眼中最牛的UI设计师是怎样的？》设计图规范预审的目标是让负责人评估可行性，设计稿着重表达出样式的位置、形状和交互即可，是原型还是设计稿都没关系。全体评审的目标是让开发准确评估工作量。对工作量影响极小的东西可以不是终稿，例如颜色值、字体大小、间距。终稿可在各需求...

延期有延期风险时应及时通知项目经理，并由项目经理组织各负责人确认是否延期。最终由项目经理发出邮件，列明延期原因、修改后的里程碑时间，同步更新文档。邮件标题：【项目延期】xxx项目延期说明mmdd需求变更通知规则：必须在需求文档的修订记录上有所体现在IM群上@所有人 通知。如果增加的工作量超过1人天的，必须发邮件会导致项目延期的变更，必须产品主管（最高可到boss）确认通知...

术语解释里程碑（时间）：重要的时间节点，例如提测、发布。来自英文milestone。风险点：任何可能造成项目延期的事项立项：经过核心和高优先级的全体需求评审后，由项目经理收集各职能的工- 作量、风险、所需资源评估，协商得出里程碑时间，发出邮件。每轮提测叫t1、t2、t3，t = test每轮提测内提交的修改，叫patch。合起来看：第2轮提测打的第3个tag，叫t2p3全功能提测：...

两轮评审流程：预审：产品提前2小时发出通知和初稿（不需要完善细节，可以只是原型），召集主管或负责人预审。未必需要开会，只要每个人能确认需求没大问题就好。全体评审：产品提前1天发出通知和需求链接（设计师已出完初步设计图），全体人员参加。应该在会前审完大部分问题，而不是会后。会上只是查漏补缺。跟运营有关的需求，应该在全体评审前由运营先审核完毕。产品经理根据问题修改完毕后，逐个找负责人确认。...

写作说明写作思路和本模板的设计原理，请参考《如何写出受技术欢迎的需求文档》。实际的示例，可参考《倒推盒马鲜生App产品需求文档》。额外的要求：文档的标题是1句话，跟需求总表里的一致。需求描述的基本要求：条理清晰，逻辑严谨，用词专业，格式规范，易于阅读，重点词句标红全体评审时，需求文档上应该是设计稿，而不是原型图。如果是基于旧需求的补充完善，把旧需求复制到新版本，加上修订记录并标记修...

执行说明产品经理应该先写需求总表再写需求文档，需求文档的完善程度与总表的优先级是一致的，优先级低的需求还可以在核心需求开发过程中再完善。整个项目组都按优先级做。核心和高优先级的可以做完一个提测一个。迭代规划是产品经理的专业技能，超出项目管理的讨论范围，所以请参考这篇文章《如何做好迭代规划》。表格样式需求名称优先级产品UI前端后端测试运维评论核心刘xx、洪...

总则所有文档以在线文档系统（Online Documentation System，下文简称ODS）为中心进行管理，ODS不方便存放的东西才放到SVN（或Git）。因为ODS有URL链接可以点击直达，比起基于电脑文件系统的管理方便得多，且直接支持手机查看。ODS规范ODS通常以“空间”或者“目录”来区分项目，而“空间”会更独立。首先，由项目经理或产品经理为项目创建一个空间。空间内的目录规范如...

工具是高效工作的必需品，IM和电子邮箱肯定少不了。除此之外，可以辅助项目过程管理的工具还有这些：

团队构成本系列文章谈论的项目团队主要包括项目经理、产品经理、开发、测试、UI设计师这几种职能，也可以包括某些类型的运营人员，不包括商务、客服等。其中项目经理可以由其它职能的人兼任，也可以单独设立。单独设立时，项目经理通常会同时管多个项目或者兼任协调跨部门资源，否则会工作量不饱和。如果一种职能有多个人员，应该设立一个负责人（接口人）。如果管理岗位的人也参与，一般会由他直接兼任。职责定位一句话...

先划分出各端（前端、客户端、后端），每个端单独评估。需要时间最长的端即为研发所需的最少时间。对每个端评估时，列出参与这个项目的所有人员。为了便于描述，我们把其中技术能力最强或工作效率最高的人称为 A。A 一天（除去加班、小憩时间）能完成的工作量定义为 1 人天（也有叫”人日“的，注意两个字合起来是一个量词/单位），同时 A 的战斗力定为 1.0。这个需求按照 A 的标准要几天才能完成，则它的工...

互联网产品的迭代速度越来越快，大家都想抢占市场，那么怎样才是正确的打开方式呢？确定迭代节奏如果产品已经进入维护阶段，即无论搞什么都不会造成利润大幅变动，那大家可以轻松点，每个需求都不限时，做完为止。在前中期，为了配合快速迭代或敏捷开发，则需要限时。一般会把迭代周期定成两周或一月。固定节奏有助于提高团队凝聚力和协调度。请注意，是迭代周期决定周期内做多少需求，而不是需求数量决定迭代周期。这会要求...

评审的目标是在写代码前发现所有的问题。不要吝惜把时间花在前期的沟通上，这能减少中后期的意外，不耽误最终的发布时间。我们可从这些思路出发来发现问题。文笔错别字，特别是界面上的文案。例如，登陆->登录歧义表达不清，模糊没有统一术语，多处地方用不同词语来表示同一概念是否杂乱无章，不便于阅读和查找信息逻辑需求的目标都没想清楚，为了有新版本而做需求流程的出入口：是否明确，是否过............

UI设计师是唯一要和程序员合作的设计师职业，我们看多了相互取笑的段子，那么怎样的UI设计师会是程序员眼中最牛的呢？这其中有3个层次。1.懂UI没错，首先是懂UI。UI设计师设计的是人机交互界面，界面的载体是设备。这是区别于其他设计师的地方。不同设备又有它的特性和要求，了解设备知识是程序员和设计师共同的目标，也是他们找到共同语言的基础。设计师需要了解这些东西：可控制的基本属性：字体，字形，...

综述正如我们做出来的产品都希望受用户欢迎，开发和测试是需求文档的用户，产品经理也应该重视他们的想法和要求才能写得令人满意。“写需求文档”说专业点是把用户（或运营、客服等）的需求转化成技术部门的话语，因此了解技术术语是产品经理的基本素质。要做到需求文档受欢迎，了解术语是不够的。虽然不可能写得像开发人员写设计文档的一样专业，但产品经理如果能运用技术人员的思维多做些考虑，就能减少评审过程的反复沟通，...

基本原则分支命名不能包含中文，英文不行就用全拼，不要在乎长度。不同渠道或不同语种的版本，应该通过工程配置来区分打包，用架构设计来消灭“不同版本使用不同分支”的做法。分支既然叫“分支”，就是要被“修剪”的。达成目的后的分支都该删除，否则就像僵尸代码。命名格式总览 分支类型 命名格式，大括号表示可变 示例 master（主干） master mas...

本文的主旨是列内部培训的提纲，特别对培训他人和写作技巧写得细一些，让大家明白很多东西可以培训和怎么传播知识。虽然题为培训，但我还是想说一句：程序员其实不需要培训，只需要指点。原因有三： 1. 程序员的工作都必须去实践，几乎没有纯理论的领域。 2. 由于互联网的开放性，程序员能找到大量的资源自学。 3. 随着实践深入，会自然地遇到一些问题。解决这些问题除了靠智力外，大部分只需要知道答案的大致方位就能用时间来消

程序员的收入不低，但是加班多，大部分工作没有成就感。好的公司具有人性化的管理，特别是小型公司和创业公司，会在闲的时候组织各种活动，舒缓忙时的苦闷。因为追求高执行力并且工作安排合理，闲和忙都相对集中，所以闲的时候能玩得尽兴，这是留住人员的王牌之一。不过技术团队还是很多宅男的，因为乐于学习和追求极致，平时都不怎么玩甚至不知道怎么玩，假日仍然对着电脑，对长远的身心健康不利。技术男多是内向型，活动类型...