心流汇聚之地

要做好汇报，需要先理解汇报的意义，这是根源上的指导。直接地说，满足上级的需求就是汇报的价值，而上级需求来自企业运作的需要，这也是各级管理者职责的组成部分。各级管理者的职责（倒序引用）：CEO：决定方向、监督执行、全球化、激励员工集团高管：财务预算、人员规划、新业务、业务投资策略、资源和核心能力建设事业部总经理：业务规划、部门利益分配，协调人和组织、信息顺畅透明、扩视野、分析市场。人员能力：经验、技能、视角、思维组织能力：架构、工作设计、流程、权利配置、人员配置。

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

2019年起不少中小企业跟风建立了中台，然而到2021年末就很少呼声了，从招聘网站的岗位数量上也可观察出来。中台的撤销，很大程度源于财务部的核算：建中台后支出剧增。如果业务收入未能如期增长，那么中台肯定在降本大战中首当其冲。反观这波浪潮起伏，笔者总结出3个建中台的条件。注：本文仅讨论小中台，即人员由产品研发构成，不包括人资、财务、法务等职能。1.业务线超过三个且多业务之间有足够的相似度公司业务已经多元化，这是最大的前提。单一业务下也按职责来划分中台，那就徒具形式化了。而只有两三个业务或项目组的话，也还

我从事移动开发始于2011年春节后。这一年iOS和Android正式登上舞台，使得塞班和WinPhone进入了维护阶段，而Java预装系统则直接萎缩。身在移动开发最前线，直观的感受就是这5个平台的开发团队人数变化，而到了2013年，就只剩下iOS和Android了。2012年Q4我开始了写博客，也正好在2013年的博文里提到，iOS和Android程序员终会像Windows程序员那样像个“标配”般“平凡”。就让我姑且认为大厂们取消大小周加班算是个标志吧，这一天来了。虽然我很早就渗透去了非客户端开发甚

本文立意紧接前文《互联网外行创始人的团队问题和解决方案》，但不需要先阅读它。团队的问题，更深层的原因是来自掌权创始人即老板自身。行内出身的创始人也可能存在本文提到的问题，他们可能也在互联网行业呆了很多年，但很少亲临一线岗位，以指挥和外部交际为主，所以第一个问题最为常见。问题一：不懂产品、研发/技术、运营一些老板具备市场、商务、供应链管理以及其它有门槛但比较低的能力或资源，这些是互联网项目中后期发力的职能，而中前期的基础建设需要“产研运”技能。执行层的不可行，会倒逼战略层的不可行。老板们可能会犯这

一般人对招聘的认知主要就是写JD和面试，但是对管理者来说远不只这两项。一个完整的招聘流程包括：确定用人需求、写JD（Job Description，职位描述）、发布、筛简历、约面、准备、面试、评价、审批、发offer、入职准备、试用期评估、转正。这么繁琐的流程会占据管理者较多的时间精力，如果想快速正确地达成招聘目的，那就绝不能只依赖HR和上级，要掌握好高效的方法论。......

文章目录1.团队的重要性2.团队成员3.人才战略4.空降高管5.组织管理6.裁员7.人才画像8.创始人自身的突破1.团队的重要性互联网创业成功有5个因素：时机、创意、资本、团队、商业模式。如果公司能活下来，说明这5个因素都得到了一定的满足。当公司到了瓶颈期，如何突破它还是能从这5个因素来寻找解决方案的。根据我了解到的创业，包括亲身参加和通过交流知悉的，发现问题很多是出在团队身上，因为其它因素在创立公司的时候就应该有大致的定论。明确一下这里讨论的团队是指企业一把手和核心负责人团体，其中互联网方面的负责人

先确认KPI合理在达成之前，首先在制定时就要确认KPI是否SMART，即：S=Specific，具体的M=Measurable，可衡量的A=Attainable，可达成的R=Relevant，多目标之间在相关的T=Time-bound，限时的如何达成这里肯定不会示范具体的专业例子，而是讲普遍性的原则。先明确一点，你100分，合作者是60分，你也是60分，结果是最重要的。所以要自己尽一切努力甚至补位他人来推动结果符合目标。自己推进具体事宜，先尽力。解决不了的困难可以反馈给上级，在指导

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天发出通知和需求链接（设计师已出完初步设计图），全体人员参加。应该在会前审完大部分问题，而不是会后。会上只是查漏补缺。跟运营有关的需求，应该在全体评审前由运营先审核完毕。产品经理根据问题修改完毕后，逐个找负责人确认。...

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

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

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

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

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

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

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

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

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

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

一句话总结2013，就是挣脱了高级程序员的桎梏，看到了更高层次的职业形态，或者说我对自己的目标定位更清晰了。简单来说，就是要做更多的管理工作。这是说的管理不仅仅是带团队，还有管自己。1.职业规划：技术能力发展终得做管理按照自己的职业规划，近年都不关注管理，全力锻炼技术。这种“一边倒”的做法有其成效，就是技术能力提升快。但技术能力强也就意味着要承担更有挑战的任务，而这些任

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

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

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

文化 文化一词，涵盖的是设计思想/理念、工作原则等精神领域的追求，也可以说是技术情怀，它是如此大型的Chromium项目能良好运作的基石，所以单独做一个总结。 1.竖立宗旨 把开源项目也运作得一家公司，对应于企业文化，Chromium提出了自己的宗旨：为用户创造更安全、更快速和更稳定的上网体验。阅读后面的章节你会发现

“只要把任务做完做好就行，为什么我还要考虑自管理这个琐事？” ——这估计是很多管理者在推行“自组织自管理”时被提问的问题。幸好会有人提，憋在心里那就永远解决不了问题。实际上，“把任务做好”这种结果导向的口号，和自管理的推行并没有冲突。我们用实际的例子来释疑。老大给了菜鸟一个任务，原话是：你写些东西向新人介绍svn这个工具。于是菜鸟写了这么一句话：svn是subversion的缩写，它是一个版本控制

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

理想状况当然是找到有管理能力且还在写代码的架构师了，然而如果有这样的人，他自己能发起项目了，你要拉上他还真难。满足一定条件就行了，别追求完美。还有比这更完美的吗？请生产这样的机器人：性格开朗（开朗≠外向），平易近人表达能力好，易于沟通交流有设计能力，有攻关能力知识范围广，跨职能团队合作顺畅在业界有一定视野或影响力，有好的人脉资源有管理能力（经验≠能力），中后期能管好团队，顺利成长为管理者没身体和家

Chromium是一个开源的浏览器项目，官方网站列出了许多文档。 官网最值得学习的地方：许多指引写得非常细致，能以老师教导学生的态度去叙述如何工作，而不是为了写文档而写文档，例如“不要害怕问问题，总有人会在IRC上帮到你”。多数文章写得很好很凝练，没法抽取主要信息，全文翻译又太耗时，不如直接看原文。所以只需要筛选出有用的信息，而不用自己总结什么。虽然一些文档会偏旧，但胜在齐全，特别是工作规范类的文

越写越多，整理不完，也许思维导图都不是最好的承载工具了，以后再继续补充。分辨率为2042*3917，点击查看大图：转载请注明出处：http://blog.youkuaiyun.com/hursing

hursing所在的公司推行敏捷开发有两年多了，其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新，令大家由抵触变成积极响应，这个过程真的很花费心思。09年12月，hursing开始在自己的团队推行晨会。当时团队是刚成立的，很小，包括hursing自己在内的2个老人+2个新人，基本上hursing得指导所有的事情。事实上，团队小到不开晨会hursing也知道他们在做什么，所

企业文化是大公司必须注重的一环，而同事间的称呼是企业文化最直接的体现。从自己的经历和道听途说出发，分析一下这些称呼的优劣。纯属个人观点，浅显愚论，请莫见笑。

最近看到不少文章都建议程序员写技术博客，可是这事儿有时候不是程序员一个人做得了主的，公司是否支持也是个问题，因为技术博客的内容会牵涉到公司的利益。只说软件技术，我想到有三点：1.担心泄密。最容易写的技术博客内容自然是当前工作的总结，那么就有泄密的可能。最直接的泄密，是公开了一个软件产品的源码。当然，能当程序员的人都不笨，不会做这样的事情。然而有很多隐性泄密是较难意识到的，这也正是公司最

1 出发本地出差的地方是京畿道（Gyeonggi-do）水原市（Suwon-si）。“京畿道”：京是首都，畿指靠近国都的地方，道相当于省。京畿道是包围着首都首尔和仁川的省（就像河北包围北京和天津），省会设在水原市。办理韩国的旅游签证需要7个工作日左右，允许停留时间是30天。我停留了满满的一个月。入境是限制携带水果的，也许是防止外物种入侵。再次访问的话，不妨带点猪肉干、牛肉干送给他们，他们估计会很感

0.前言看到过几篇程序员的职业生涯过程，我也来当一回写手吧，希望对和我一样曾经磕磕碰碰过的人有帮助。纪念大学毕业五周年。1.从校园启程我的大学专业全称是无机非金属材料工程，这专业多与玻璃、水泥、陶瓷打交道，高大上一点的是各种珠宝，前沿一点的是纳米材料。想先声明的是，我不是在黑自己的专业，只是每个人都会有自己喜欢和适合自己的工作和生活状态。我尝试过为了完成一个程序而废寝忘食后就爱上了这个职业，即使知

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

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