小团队产品研发管理V0.0.1

序言

之前做研发的时候非常鄙视管理，觉得管理的那些人就知道搞政治，后来做了开发主管，以及到部门经理之后，管的人多了发现管理真是门大学问，真的应该每个人都要学习一些基本管理知识，特别是刚入社会的打工人。

具体的管理理论就不在这篇文章里多说了，这篇文章的目的是针对最近的新组建的团队做了一些最最基本的管理规范，由于我本人又核心负责产品的管理工作，所以习惯性把管理规范也当做产品来做，当前版本就叫v0.0.1吧，之所以起了个这么小的版本号，是因为这个管理规范只有最基础的框架，在后续的管理过程中会持续迭代，补充里面的细节。

1.会议管理

月度会议

会议时间：最后一周，一般30~31号
会议内容：上个月工作情况总结，下个月计划确认
会议材料：下个月规划内容清单
会议产出：下个月详细计划

每周例会

时间：星期一上午 9点半
会议内容：上周的产出总结，本周计划
会议材料：本周计划，上周产出物
会议产出：到日和人的任务分解

2.产品管理

产品需求流程管理

产品版本管理

版本的目标

每个版本需要有明确的目标，这个目标不是来自产品经理的单方面猜想，而是需要结合市场部门的需求制定当前产品的版本所满足的市场目标，在版本管理时候不仅目标要明确，范围也要明确，只有确定了需求的目标和范围产品和研发人员才知道大概版本是什么计划时间点发布。

产品版本规范

版本号管理

标准的版本号必须（MUST）采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止（MUST NOT）在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须（MUST）以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：大的版本升级，已经不兼容当前版本了（包括样式、底层功能等），

次版本号：当你做了向下兼容的功能性新增，例如新增了一个模块，

修订号：当你做了向下兼容的问题修正，一些小的问题改善，bug修正。

先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

2.技术管理

技术选型

小公司小团队一个合格的CTO需要做好技术选型其实并不难，很多难不是难在技术上面，而是难在脸面上，技术选型一定不是追求技术的时尚程度，也不是技术的性能，而是目前公司人力资源是否擅长的，招聘人力成本上，因为很多小公司很难活到技术架构需要微服务，分布式这样的普适性面试都会问的问题要求。

案例：一开始的技术选型，我们就是最普通的java，springboot框架+一个mysql，前端vue & element ui， redis？微服务？高可用？这些都没有，因为系统在很长一段时间内每天的访问量不超过1000人，技术的前期就是如何最小的成本把业务跑起来，后面再持续迭代优化，需要什么再加什么。

参考引用

产品版本管理：https://semver.org/lang/zh-CN/

关于作者

作为曾经的程序员，现在的产品经理，有时候狠起来自己给自己提需求的，曾经作为程序员我是快乐的，现在作为产品经理我也是快乐的，偶尔撸撸代码陶冶情操，不忘初心，通过技术和产品不去改变世界，只是表达点什么，微信公众号 产品经理与狗，主要写一些产品、技术、管理等文章，欢迎关注。