中小团队的技术负责人如何做好技术团队建设

五斤半 發表於 2022-4-7 23:23:00

中小团队的技术负责人如何做好技术团队建设

<img src="https://img2022.cnblogs.com/blog/641760/202204/641760-20220407232103880-137241491.jpg" alt="What is Management? Definition, Characteristics, Levels and Importance -YouTube" loading="lazy">
<h1 id="写在前面">写在前面</h1>
最近跟好些同是技术的朋友聊了下，发现其实很多规模不大的技术团队，在从开发流程到项目管理，到日常的各项工作，不同职能部门的协作上都有不少的问题。我也尝试动了动我这被技术腐蚀掉的小脑袋思考：
作为一个中小团队的技术负责人应该怎样做好团队建设提高生产力
<blockquote>
本文是我日常脑子放空时的臆想，请辩证阅读，欢迎讨论和批评指正、补充；
</blockquote>
<h1 id="中小团队的定义">中小团队的定义</h1>
我这里给出的中小团队是：10-100人的技术/研发人员，产品、运维、dba等对应该规模若干；
中小团队的技术负责人(下称技术负责人)：大部分可能叫技术总监，一般下辖若干研发小组或者若干个项目组，零到若干个架构师；零到一运维支持部门；若干测试；
<blockquote>
注意这里的技术负责人不是CTO，只负责技术相关，不负责制定公司战略的那种；
</blockquote>
<h1 id="技术负责人职责">技术负责人职责</h1>
技术负责人在不同类型的公司（传统或者互联网），不同类型的业务（2b或2c），职责都有一定的差异，这里总结他们共同职责：
<ul>
<li>人员管理：发掘同事的才能，把正确的人放在正确的位置，给制定正确的OKR，正向激励团队；</li>
<li>日常项目管理：多项目、多产品线管理和资源协调；</li>
<li>团队目标与文化：制定技术团队的年度OKR，中短期目标，长期目标和愿景，明说或暗示确定团队的文化；</li>
<li>提升开发效率保证软件交付质量：设计软硬件架构，确定各项目环境的具体定义；制定不同技术团队的开发规范和生产、部署规范；提升项目；制定适合公司的软件开发流程；提升开发效率和保证软件交付质量；</li>
<li>提升跨职能协作效率：确定各种情况下的协作流程，提示团队内协作效率，避免协作问题的无意义内耗；</li>
<li>演讲职能：向上汇报，向下引导同事理解技术团队的共同目标/上面的要求；</li>
</ul>
其他的暂时没有很多分享，我想简单说说人员管理和重点说说如何提升开发效率保证软件交付质量怎么提升跨职能协作效率
<h1 id="人员管理">人员管理</h1>
<ol>
<li>
组内成员有异议时，用“权力”或者说“上级”身份来胁压是一大忌，应认真跟同事沟通，认真听取对方意见，鼓励表达不同意见，以理服人；
</li>
<li>
从心理认同开发者和管理人员只是工作职责不同；
</li>
<li>
善用deadline倒逼生产力；
</li>
<li>
部署下去有严格交付日期的任务不要等到最后一天才过问进度，自己心里在各个时间点的进度情况都要有个谱；
</li>
</ol>
<h1 id="怎么提升跨职能协作效率">怎么提升跨职能协作效率</h1>
<h3 id="首先是确定组织架构和人员编排选择最有战斗力的方式组合团队">首先是确定组织架构和人员编排，选择最有战斗力的方式组合团队</h3>
产品经理：确定产品是跟研发小组/项目小组混编，还是单独一个产品部门动态的方式跟不同的项目？单独的话会不会增加沟通成本呢？混编的话会不会导致产品功能重叠/项目重叠呢？
研发：前后端/App等是按不同的产品线/项目固定小组，还是根据项目需要动态组合？还是用Scrum思想的指导动态根据项目组合？用固定小组方式偏僻会不会导致不同小组件技术闭塞不交流，重复造轮子呢？会不会导致不同小组间技术前景不一致而影响研发同事的流动性呢？
设计/UI：设计Ui这边应当单独部门，而不是混编；
运维团队: 运维这边也应该是单独部门，注意控制好运维与开发的权限，规范两者的沟通。
测试： 测试这边也应该是动态跟项目，不要跟研发或小组固定混编；
<h3 id="开会">开会</h3>
<ol>
<li>如果是每天都开的晨会，建议不要超过15分钟；最好就工位站立讨论；</li>
<li>规定例会讨论范围，超过讨论范围的，相关人员私下召开；</li>
<li>不要把无关人员拉入无关的会议；</li>
<li>开会过程不要太严肃，要让同事能表现自我，可能有意料之外的发现；</li>
</ol>
<h3 id="需求问题沟通">需求/问题沟通</h3>
<ol>
<li>大部分问题，最好当面沟通，不要在通信软件上大费周章的打字沟通；需要多方参与的，小会议室来个快会；但如果有需求变更等之类需要留底的，一定要在PM(项目管理系统)上留底，哪怕寥寥几字；</li>
<li>口头表述的需求，尽量让研发同学简单重述一遍；</li>
<li>避免口述的需求层层传递，产品需求提给研发A，研发A转述给B，最后是研发C来做。应当产品直接对接到研发C；</li>
</ol>
<h1 id="如何提升开发效率保证软件交付质量">如何提升开发效率保证软件交付质量</h1>
<h3 id="需要个技术团队的wiki平台">需要个技术团队的Wiki平台</h3>
理由：一定要搭建个团队内部的Wiki平台，平时内部流程，技术文档需要个统一的文档平台提供不能东一拉西一拉；
推荐：如果没有很强的权限管理的需求可以用Markdown支持很好的docsify，docsify直接提交Markdown文件就可构建；
其他：BookStack也不错，整体和Gitbook、看云比较像
备注：有的公司甚至多个不同地域的办公点之间没有专线搭自己的局域网，这点其实有必要的；
反面案例：没有wiki平台没有统一管理文档手段，甚至你找某份需求文档久经周折找到对应的负责人后对方你发来一份word文档，真“传不过三代”；
<h3 id="选择合适的代码管理平台">选择合适的代码管理平台</h3>
理由：这个不用说了
推荐：使用Gitlab，多年使用，体验非常不错；
反面案例：svn；
<h3 id="请使用接口管理平台">请使用接口管理平台</h3>
理由：一定要搭建一个统一的Api管理平台，避免各种Api重复编写，没有文档、文档到处放，几经交接后找不到对应的维护人员等，混乱不堪；
推荐：使用YApi , 带有丰富权限管理、可视化的接口管理、Mock支持、自动化测试、特别好用的是和Swagger和postman的数据相互转换；
其他：另外是要去开发人员一定要维护好自己负责接口的Swagger，参数返回都必须是强类型的并且备注清楚；
反面案例：还是word文档；
<h3 id="选择合理的git分支策略">选择合理的git分支策略</h3>
理由：
<ol>
<li>什么时候hot but fix分支，什么时候是feature分支等；什么情况适合用什么类型分支，什么时候要打tag等，并把命名规则给定下来；避免新人来手忙脚乱，开发自己回溯也方便；</li>
<li>应由架构师或资深开发结合现实情况选择一中适合团队的分支管理策略并写到wiki上；</li>
</ol>
<blockquote>
这块需要单独讲，待我慢慢填坑；
</blockquote>
<h3 id="定义程序环境">定义程序环境</h3>
理由：明确的给出软件开发的整个生命周期的各种环境定义，并部署好公共测试环境，在开发、协同开发过程中很重要；避免开发人员各方老在处理问题的时候因环境不同鸡同鸭讲（也就是统一环境这个无关变量）；
示例：
<ol>
<li>
一般从开发=>测试=>上线，有对应的环境变量：Development(dev)=>Staging(stag)=>Production(prod)
</li>
<li>
Staging(预生产) 一般是是要提供给测试和产品等测试的，一般要使用局域网公共服务器；
</li>
<li>
Development环境又因目前都是前后端分离的无论web和App或小程序，且前后端几乎都要同时开发的，所以dev也是要使用局域网公共服务器的；所以dev环境可以拆分成：local=>dev；
</li>
</ol>
反面案例：
干脆没有Staging环境，甚至dev环境也没有公共服务器，前端需要等后端开发完才对接；且因为没有dev公共环境，对接过程极其痛苦，甚至需要前端运行起后端的代码才能开发；
如此做法经常导致对接各方经常导致：“我这里没问题啊，要不要我帮你看看？”做无用功；
其他：
预生产环境维护的总体成本还是很高的，需要尽可能跟生产环境一模一样，但带来的回报也是客观的，几乎能避免大部分环境不一致忽略导致的问题；
<h3 id="单元测试集成测试">单元测试集成测试</h3>
请尽量写好单元测试和基础测试，预生产环境上线要求，须通过测试才能打包/部署；
请衡量业务/团队情况做出测试覆盖率要求；
脚手架项目须给出单元/集成测试写法的示例；
<h3 id="须有开发规范">须有开发规范</h3>
理由：统一的开发规范，可以极大提高代码的可读性和可维护性，降低维护成本提示开发效率；规范的开发可保证团队的专业性，减小开发人员的流动性；
推荐：无论什么语言，都可以参考阿里巴巴Java开发手册https://github.com/alibaba/p3c，编写出适合自己团队的规范；
简单举例：
命名：方法用大驼峰还是小驼峰，类、接口、枚举、文件、项目命名；私有、保护、公共方法、变量命名等等；
格式：if后面的大括号要不要回车；单语句的if要不要加大括号等；
数据返回格式：统一的返回格式，正确使用Http语义；
其他：
轻约束：用统一的插件配置格式化代码，Visual Studio 推荐插件CodeMaid(码楸)，配置保存就格式化；
强约束：用统一Ide插件规范代码格式，格式不统一就编译不通过，Visual Studio推荐EditorConfig；
前端的也一样，可选工具更多；
<h3 id="数据库使用规范">数据库使用规范</h3>
<ol>
<li>定义好各种命名规范；</li>
<li>定义安全规范；</li>
<li>文档给出索引使用注意点；</li>
<li>做好权限控制，生产账号只允许服务器使用，开发人员只读权限等；</li>
<li>常见的各种错误用法集锦等，由资深开发或架构师整理好放到wiki；</li>
</ol>
<h3 id="前后端对接注意点">前后端对接注意点</h3>
推荐：
有统一的返回格式，统一的异常处理等：
<pre><code>{
"code": 1,
"message": "success"
}
{
"code": 1,
"message": "success",
"data": {}
}
{
"code": 0,
"message": "fail"
}
{
"code": 40000,
"message": "exception 1"
}
{
"code": 40001,
"message": "exception 2"
}
</code></pre>
要能做到前后端同时开发，要求后端先定义好接口，必须给出自文档Swagger并部署到局域网dev的服务器；前端自己mock数据(浏览器插件)或后端配合mock数据，前后端同时开发；
使用统一的接口授权逻辑，禁止每个人用不同的签名/授权逻辑；这里推荐用OIDC(OpenId Connect) 也就是OAuth2.0拓展，.net的话使用 IdentityServer4；
<h3 id="快速开发框架脚手架有必要">快速开发框架(脚手架)有必要</h3>
无论前后端还是App来说来说都需要一个快速开发的框架(或者说脚手架)，一条指令生成模板项目；让开发者把把精力放到业务开发上，同时模板项目已经写好了很多遵循开发规范的示例，让使用者快速上手，风格统一；
另外，模板项目里面已经引用了很多公司内部的组件/中间件和基础库，快速集成使用；
另外还应有很多高频代码的快速生成，比如curl生成对应前后端语言的Api调用代码；
反面案例：
开发从写代码到搭好每人各异的项目框架开始写业务，已经两天过去了。然后后续每次需要用到第三方组件都自己去搜选一翻，一个项目光ORM就5个，三个Redis驱动；
<h3 id="选择合适的项目管理pm工具">选择合适的项目管理(PM)工具</h3>
应当部署一套跟办公通信软件联动的PM工具，项目开发的整个生命周期都能及时有效的把通知有效送达到对应人员；
参考：
使用企业微信做办公通信软件，可选用Tapd做PM工具，无论在项目立项、需求提出、需求变更、bug状态更新等等状态都能触发到企业微信；
使用钉钉做办公通信软件时，可选用Teambition做PM工具；
<h3 id="规范生产上线流程">规范生产上线流程</h3>
开发者不应有生产环境写文件权限，但读权限应该有且只有读权限；
上线过程必须有对应的审批流程，选择一个适合本团队的生产上线流程能避免很多不必要的问题，但也注意控制复杂度不要因流程影响效率；
参考：
开发者PM提出上线申请=>直属上级审批=>运维组长审批并指定处理的同事;（整个流程不需要私下通知PM工具与办公通信软件联动）
反面案例：
开发者都有生产环境的上线权限导致开发者对生产环境没有敬畏心，经常频繁更新；多个人部署冲突；直接拿生产环境做某些功能验证等；
<h3 id="运维开发之间">运维开发之间</h3>
很多东西不是提个工单给运维就能描述清楚了，工单是工单该当面沟通的还是要当面沟通；
像Nginx访问日志错误日志，程序等目录的可读权限应默认提供给开发，避免开发老是因为这些找运维浪费双方时间；
提倡开发人员掌握基本运维知识，可由运维根据心得分享，提示开发人员解决问题思路；
如果有工具能显著提示运维上线效率应当由运维衡量安全性后使用，比如Jenkins，docker，k8s等；
<h3 id="选用适合的产品原型管理工具">选用适合的产品原型管理工具</h3>
避免直接共享Axure导出的html原型文档，应有共享的原型管理工具（局域网和商业产品均可）；
产品原型请严格做好版本管理，不能悄无声息就把需求改了；
推荐：
局域网：直接搭个本地的的 axure.mysite.com
商业产品：
<ol>
<li>
Axure本身支持；
</li>
<li>
Figma: https://www.figma.com/
</li>
<li>
蓝湖：https://lanhuapp.com/
</li>
</ol>
<h3 id="做好知识分享代码review">做好知识分享/代码Review</h3>
<ol>
<li>
鼓励内部开发，运维等知识分享，但也要避免流于形式；
</li>
<li>
鼓励同事之间做代码Review，定时分享同事写的比较好的代码；
</li>
<li>
然后由小组长分享反面案例(不好的写法)，时刻提醒大家代码有人review，三思再写；当然要匿名的形式不然开发人员压力太大了；
</li>
</ol>
<h1 id="总结">总结</h1>
感觉自己总体说的比较乱，整个题目也比较宏大一时能想到的有限，有机会慢慢填坑；
部分要求也有一定的成本，但有的成本是不能节省的；
期待有更多不同观点，也欢迎批评指正。
<h1 id="参考">[参考]</h1>
无 
来源：https://www.cnblogs.com/xiaxiaolu/p/16114880.html

頁: [1]

琼殿技术论坛's Archiver

中小团队的技术负责人如何做好技术团队建设