Foreword
试用了一下PingCode，发现还是很多地方很反人类，举例说明，再谈谈我自己对项目和产品管理的理解
PingCode
https://pingcode.com/
先要注意一下，PingCode大致分了两个大板块，一个是产品管理，一个是项目管理。
产品偏重一些用户需求，服务对象是用户和市场，而项目则是服务产品的，但也不全是服务产品，项目规划或者管理的范围可能更大一些，会涉及到超过产品的部分，比如技术本身的发展、预研的部分、一些内部的问题。而且项目本身可能包含的不仅仅是一款产品，可能是多个产品，甚至是整个产品平台。
大公司中会把产品和项目分成两个部门，产品管产品的，项目管项目的，类似PingCode就是这样的模式，大部分做此类的管理的软件都是将二者分开的模式，这没问题，但是对比起来不那么大的公司他们也要上类似的管理模式就有点奇怪了。可能产品和项目管理都在一个人手上或者说分的不是那么清，既管项目又管产品，此时需要的就是一个混合模式，显然PingCode是不支持的。一般能用到分开管理的，基本都是很大的公司了，为此付费不是什么大问题，而对于还达不到这级别的公司来说，就有点难选了。
产品管理的核心是需求管理，过了需求之后，都需要转换成项目管理中的一个环节，但是产品又有自己的计划，而项目管理必然也有自己的计划，一个东西搞出来两套，一边一套，对于不太区分的公司来说这就有点小难受。
产品管理
产品管理，主要是需求、计划、工单、基线、评审，这几个关键环节，其他几个标题栏不重要
PingCode的设计是先产生工单、然后形成需求，接着需求加入了某一个阶段计划，而这个阶段计划其实可能就是下一个基线标准。但是呢PingCode并不是完全按照这样的流程来走的，他很奇怪。
先说初始阶段，建立工单时无法关联需求，要工单建立完了才能关联需求，这没问题，工单的建立者应该是客户或者使用者，他不知道具体需求单，而关联这一步得产品来处理，他去关联到某个需求上。
- PingCode不支持第三方进入建立工单，必须是产品经理自己做，这对于第三方来说其实是缺少一个正向反馈的环节的，他不知道他提的需求到底咋样了
但是反过来，比如你先建立需求，此时就无法关联工单，就必须建立完了以后再修改去关联，这就有点奇怪。
PingCode把客户独立出来，想法上是可以的，后期统计可以知道来源于内部或者客户需求都是哪些，需求质量如何
再说到计划和基线，在我的理解里，计划完成以后基本就变成了下一次计划的基线了，但是PingCode偏不，他计划和基线完全独立，各玩各的，没有任何关联，也就是你做了计划还要做一次基线，就类似工单和需求，你都得做。这就显得很多余，也怪不得没人用。
可能有些公司里产品计划和项目计划不是一个计划，产品可能计划里会留一部分余度？防止项目计划跟不上？所以搞出来两套计划
项目管理
PingCode的项目管理可以选择多种模板
PingCode这里规划=需求，二者一模一样，不知道为什么要多一个分页，工作项又是和规划完全一样的东西，这已经是三个一样了。
不同点在于规划可以看到工作项级别，需求看不到，规划是树状结构，工作项是平铺结构
正常迭代应该是把工作项分配给某一个迭代内，新建迭代的时候完全不提示这个，转入迭代又藏在角落里，真的不知道这是咋想的
后续的测试也比较奇怪，测试可以建立测试计划，但是当测试计划完成以后，如果要进行多次测试计划的支持，那就不行了，必须要新建一个。而实际上可能版本发布很频繁，测试计划会经常有，缺少同一个计划的持续更新的设计
项目管理还有一个问题，由于项目是互相划开的，如果一个人或者多个人同时做多个项目，就没有一个全局视角查看，这样的话，如果一个人同时进了三四个迭代，那工作量就很难预估了，PingCode中没有这种把所有项目化整为零统一到一起去看的视角
Scrum
PingCode的项目管理，依然是套用Scrum，比较反感这种套用敏捷概念，但是 各种用词还是用敏捷那套机翻的名词，看着就别扭
https://blog.pingcode.com/whats-is-story-point/
故事？工作量评估，用一个奇怪的词来偷换你原本的概念
讲到最后还是大家协商工作量，中间一大段过程全部是废话，纯纯为了故事而故事
Scrum 术语表
史诗，基于产品的长期战略方向而被提出，颗粒度级别最大，通常为可独立使用的一个产品模块。
特性，作为某个史诗的子需求（比史诗更具象）和若干个用户故事的集合，承上启下，需要多轮迭代才能完成交付。
用户故事，从用户的角度来描述用户渴望被满足的需求，颗粒度级别最小，且能在一个迭代中开发完成。
故事点，是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。
迭代，团队处理事务的一段短期迭代周期，在创建用户故事前需要创建迭代，才可以选择到对应迭代。
速率，迭代速率图是用于跟踪当前项目下所有迭代已完成的工时量。这有助于您确定团队的开发速度并预估在未来迭代中能完成的工作量。
燃尽图，用于跟踪记录所有问题的剩余工作工作时间，预估完成冲刺任务的可能性。
回顾会议，回顾会议是 Scrum 检视与调整的一个重要的环节，在这个会议上，Scrum Master 鼓励团队在迭代过程和时间范围内，对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。
Scrum 术语中文翻译真的就字母翻译，只能说弱智的不行。
史诗->长期战略、长期规划、长期计划都可以，看到史诗这个词就有点恶心
特性，特性倒是没啥问题，但是其实这里应该是一个相对中期的目标，比如：中期规划、中期计划
用户故事，就是短期规划
故事点，直接用工期就行了
迭代，Scrum的核心迭代周期，可能是两周，也有可能一个月这样的
回顾会议，简称复盘
测试管理
PingCode测试管理就更差一些了，很多管理不到的，重复跑的测试用例或者类似的东西基本都没有考虑
权限管理
PingCode的权限管理也非常粗放，一给就是整个项目或者产品给出去了，具体内部的细节权限，似乎不能限制
内部的职位设置和权限又不挂钩，不知道这个职位设置的意义何在，总体看起来比较像半成品
重新设计项目管理
我对于项目管理的理解，如果是把产品和项目经理都独立拆开，各自负责各自的，那么协调在一起做一个计划肯定是比较统一的，对于提出工单的客户有良好的反馈回路。
如果产品和项目是同一个人，那么职能直接合并就行了，整条链路走下去也更顺畅，从降本增效角度来看，越简单越统一越好，而完全独立
对于任务计划等项目最好可以这样
实际产生一个工单或者一个需求，可能并不是一个任务或者工作项就能直接完成的。
想要完成这个其实可能得上升到计划的级别，如果是计划的级别，那就有可能有多个子计划，然后多个分步，这些分步的工作项才能进入迭代，而不是直接从计划就拆解到任务级别，又或者是全部扁平，全是任务级别。
全部扁平化带来的问题就是任务缺少了分类，做稍微长期的规划时找关联任务非常困难。
每个计划应该是一个类似事务的东西，他有完整的工作内容，不仅仅局限于那点代码，还包括可能的沟通、协调、变更等等操作，这样从整体上来看就能对事务的始末进行一个完整追踪，远胜于单纯的只对那点需求或者功能的追踪
Summary
不是很好用，还得再找找