好工具，促成好开发

前言

在大学，我读的是软件工程专业，那时使用的是Visual Studio IDE编辑器，可以断点调试、代码自动补全、语法检测，用它来开发MFC和编写C#窗口应用真的非常方便、友好、强大。

后来，我在维护PhalApi开源项目时，使用docsify来编写和维护技术文档，也非常方便、实用，乃至后来至今，我都使用它来维护各类产品的使用手册、使用文档和教程。

在职业上，我曾经任职在唯品会等上市公司，接触并使用了confluence这款专业、无比强大的企业知识管理与协同软件，可以用于构建企业wiki，让我印象非常深刻。一方面，我用wiki编写并维护了很多文档、包括技术文档、设计文档、项目文档、故障复盘、创新分享、新人指引等；另一方面，wiki的宏、设计、功能、协作和界面都在我使用过程中提供了贴心、友好和有力的支撑；还有一方面，我连续任职的几家企业中，不约而同都使用了confluence这款软件。

好工具，促成好开发

过去的经验，以及多年的总结，我觉得，对于一名开发工程师，一名在职场的技术人员，好的工具，能让你的研发、工作、协同事半功倍。

作为工具，它确实不能代替你去自主工作、去自主开发，但它可以帮助你解决可能遇到的某些问题，提升你的工作效率，减少工作出错的可能性，引导你往更优秀的方向发展和前进。

“好工具，促成好开发。” -- 黄禅宗

YesDev的特点和作用

YesDev是一款专注于企业研发协同和管理的工具。它非常适合给企业的研发团队用来进行产品研发的管理和团队协作。YesDev有SaaS在线版本，也支持企业私有部署。

特别对于研发团队，对于一家企业，在软件产品研发过程中，好的软件系统，能理解和适合自己产品研发团队所使用的协作工具，无疑能在更多的方面促成好开发。例如：项目管理、需求管理、缺陷管理、文档协作、沟通交流、数据报表、持续集成等。YesDev作为一体化的研发管理平台，提供了团队日常研发的各类功能和帮助。

YesDev有以下特点：

特点1：适合更多研发模式

以自主产品研发的全生命周期协同与管理为主，同时可以满足支持外包开发项目的项目管理，以及面向ToB客户的项目服务。

特点2：连接更多工作场景

支持日常研发工作、H5移动办公、ChatOps、OpenAPI、当面沟通、每日站会、远程协作、工作汇报、客户沟通等。

特点3：满足更多管理需求

包括个人层面、团队层面、管理层面和公司层面的多层级管理和多维度的管理需求。

特点4：支持灵活的个性化配置

灵活的各类配置，让这款工具更加适合你团队的使用的流程。设定

如何做好企业研发管理？

做产品研发，从来都不是一件容易的事情。对于聚集在一起的一群人，从一个抽象的需求开始，最终交付出有价值、符合用户需求甚至超出期望的软件产品，更是一项挑战。

试想一下，那么多人、几万到十几万行的源代码、数以万计的数据库和数据库记录、还有那么多服务器环境，中间还有需求文档、UI设计稿、Bug、技术文档、测试报告，还要穿插开会、沟通、汇报、外部合作、APP上架审核等，如何做到多而不乱？如何做到稳中求胜？如何做出高产出？这些都是很值得思考的问题。

有团队，不等于有产出。也并不是人员越多，开发越快。

下面结合经验，以及YesDev这款工具，还有当前我们团队的研发情况，进行分享，给大家一点参考和借鉴。

花更多的时间，死嗑产品

在某次饭桌上（也是我唯一一次和老板吃饭的场合），公司老板CEO说道，做产品，就是要死嗑，没有捷径，也没有退路。

创业越久，我对此的理解和感悟，就越发深刻。

做开发，做产品，是要花时间的。有家花店，名字叫“花点时间”，这名字起得好，我也在上面买过多次的花，品质都不错。做软件产品的，也是急不得，需要持续投入时间、投入精力、投入你的专业。不是因为这一次有客户过来买单了，你赶一个版本或追加一些新功能，而是提前做好产品规划，持续迭代，不断精进。

MVP只是一个开始，但不是一个常态，随着使用的用户和客户越来越多，产品的升级和迭代，就要越发稳健。例如YesDev的PRD文档到目前一年多的时间，就已经有上百份了，平均每周要输出2份产品迭代的需求。

上面是我本地的截图，略显凌乱，以下是我上传到YesDev的效果。就会非常清晰，每个人可以根据他的需求，进行划分，哪些在做的，哪些还没做的，哪些做好的，一目了然。从以下截图来看，虽然有100多份需求，但当前剩余没做的需求只有3份。从某个程度上说，我们团队的研发速度和需求消化能力还是很强的。

在企业研发中，最最最为重要的就是，在需求这个源头要牢宾把控。产品需求，是一切项目管理和流转的源头，这个起点控制不好，就会混乱、失控。一方面，尽量避免一句话口头需求，尽量尽量要书面化，用邮件或YesDev或其他工具进行记录和跟踪，做到多而不乱，如果有条件，能书面化更好，转换成技术人员可以理解的需求文档或PRD。另一方面，需求的提出和流转要控制好。不管需求紧急与否，统一邮技术负责人收集和对接，避免需求方、业务方直接找到一线的技术人员进行私下沟通和处理。

小结：把控需求，死嗑产品。

尽最大努力，保障交付质量

每一次发布和交付，都意味着风险和故障的来临。一个细小的不足或某一行代码问题，都有可能导致很大的故障和损失。

企业规模越大，发布越要规避风险。发布有风险，操作须谨慎。

以我们的YesDev最近即将发布的企业YesDev v3.1版本为例，为了最大保障交付给企业客户使用的新版本能顺利运行和完美升级。除了常规的开发和测试，我们团队做了以下事情：

内部话题：如何最大限度保障企业独立版的交付质量？

1、整理测试用例，编写测试计划，进行全面的功能测试和回归测试

2、补充PHP单元测试，提高核心代码的测试覆盖率到80%及以上 

3、相互code review，前端和后端的

4、查看对比过去saas的commit记录和源代码文件对比

5、进行预安装，在纯净环境从零安装给新模拟的客户

6、全员重新回顾YesDev工作全流程

7、跟进交付升级后，客户服务器的错误日记，定期巡查和回访

8、进行梯度升级

9、整理产品功能点的差异对比，避免遗漏

其中，我们在YesDev维护了企业v3.1测试计划，共有73个用例，第二轮测试通过率是96%。

以下是部分用例：

还可以通过脑图，从整体宏观看到整体测试计划、测试模块、测试用例和Bug的关联和分布情况。

又如，我们用项目文档维护和在团队内部再次共同回顾和梳理了YesDev在SaaS产品和企业独立版之间的全流程协作图。

把交付和发布作为最终目标，以结果为导向，和团队一起共同推进。

保持友好，充分沟通，积极达成

作为工程师，要专业但不能太技术化，不能只关注写代码，还要锻炼解决问题的能力。而作为在职场上的工程师，还要学会和掌握一些软技能，例如和需求方、和业务部门的沟通与协作，要多沟通、多确认、多反馈，运用我们的专业技能来帮助其他部门更好解决他们在工作中所遇到的问题。

YesDev在设计时，就关注到了沟通和反馈的重要性和必要性。YesDev有三个核心的闭环，信息流就是其中一环。

例如：每日站会可以使用敏捷看板，在关键的项目节点和里程碑进行团队内部的面对面沟通和确认。还有在开会、面对面沟通等场景，YesDev都提供了友好的支撑。

更为重要的是，在项目、需求、问题和任务流转过程中，可以支持更加实时的消息推送，让协作更加透明，让业务方和项目干系人能及时了解到最新的项目状态。

聊天群的特点，意味着消息会很多，难免会有干扰，但可以设置消息不允许通知，并且可以为不同的工作组绑定不同的聊天群。目前支持的群有：钉钉、企业微信、飞书、喧喧等。消息通知机制如下，让消息推送更精准。

与此同时，邮件作为工作中重要的交流通道和汇报方式，YesDev也提供了极大的整合。一方面，一线的员工，他个人可以接收到非常精准的邮件通知，是和个人密切有关的通知，例如：项目指派、需求指派、Bug指派等，都是需要自己处理的事项。另一方面，作为管理者，可以接收和查看重要的汇报邮件、汇总报表，可以在关键的时机和场合掌握最核心、最重要的信息。例如有：自动汇总的员工周报、可以每周定时发出的项目、需求、测试KPI报表等。这些邮件，可以在重要的场合为你的汇报提供更多的数据支撑。

站内的消息通知+实时的群消息同步+精准个人邮件通知，YesDev为企业研发提供了一套体验更佳的沟通和反馈机制。

明确流程，遵循约定

YesDev和其他同类工具，最大的区别，可能是在于项目的定义。YesDev同样以项目为核心，但我们更加推荐在YesDev的项目是短、平、快的项目，可以在1~3周可以完成并交付的项目，符合敏捷开发的“小步快跑、快速迭代”的精神。

所以，如果你进入了YesDev，第一眼看到的就是当前项目。就和微信的最新聊天会话一样，最近有更新的项目会自动排列在前面，让团队更加关注当前项目，保持活跃、保持活力、保持生气。

组织架构会决定信息的流向，不同的研发团队有不同的协作流程，但不管是哪个流程，都要在团队内部充分同步和共享。并且要把一些注意事项、内部红线、约定等进行同步。

例如，YesDev推荐的协作流程如下。以需求池为起点，以版本发布为终点，构成单向图。每一次迭代为一个周期，如此不断持续迭代。

对于一些工作准则、内部约定和注意事项，我们会先定好，再开会宣导，最后在YesDev通过公告弹窗（即黑板）每天强化这种文化和氛围。当前我们的内部宣传内容是：

线上故障处理要求

1、#紧急 线上故障，立即处理并发布修复

2、#重要 线上故障，当天尽快处理并发布修复

3、#中 #低 线上故障，在接下来最近的发布窗口一起发布修复

12月代码注释规范

1、#必须，需求类的代码注释规范，格式：需求#XXX，XXXXXXX

2、#可选，问题类的代码注释规范，格式：bug#XXX，XXXXXXX

要协作，更要管理

在企业产品研发中，除了要求每个成员都具备各自的专业技能外，还需要每个成员都能很好的进行协作，比如前端和后端的开发联调，技术和测试之间的Bug解决，开发人员和业务部门的对接等。

但国外和国内的情况又不同，国外推崇扁平化协作，但在国内还是需要扁平化管理和进行一定程度上的团队管理。但给予团队的是指点，不应是指指点点。这要求，作为管理人员，要能在一定的高度上给予团队更高阶的梳理、指导和帮助，让团队可以跳出原来自己站在森林里面的局限，放眼更长远、更高层面的理解和把控。

这要求，我们管理者，要能看懂数字背后的意义。再进一步，我们需要有数据，才能看数字。

YesDev提供了项目管理和团队管理中的信息、报表、图表和数字。例如，有整体的宏观数据，从以下真实数据，你可以从中观察和发现什么规律和吗？

再来对比另一个团队的数据，是否可以发现一些问题以及解决方案？

再回到每周两个关键维度的汇总信息。一方面是团队的产出和交付能力，这方面可以通过需求排期来体现和观察所得。不管团队在背后做了多少事情，至少每周要的产品需求上的迭代和更新。要让老板、业务方、客户、需求方每周都有新收获。

另一方面，要关注研发人员和团队的工作饱和情况。工作时间是我们最为宝贵的资源，要充分利用、合理安排、及时调整。不宜过于饱满，但也不能过于稀疏。工作太多，天天加班也不是健康的状况；工作太少缺少规划，时间得不到有效使用，日积月累就会导致产品的迭代速度和竞争力得不到保障。

“牛人不可怕，可怕的是牛人比你更努力。”

古云此日足可惜，吾辈更应惜秒阴。”

写在YesDev 3.1版本更新之际

YesDev要做的事情很简单，就是切切实实成为企业研发更贴切的工具。

我们团队，将持续努力，死嗑产品。如果哪一天，你上班来到公司，打开电脑，用到了YesDev进行研发的协同和管理。不是因为我们在那一天或那一周做了什么，而在于我们这几年一直在做了什么。

用心做事，大有不同。 

一起加油！