在一些业务场景中需要选择相应的人员，将人员展现出来供用户选择的控件即为选人控件。最近在负责某企业IM产品移动端的选人控件改版，下面针对改版中遇到的人数上限问题和选自己的问题进行反思与总结。
一、人数上限问题
某产品移动端涉及到选择多人的业务场景有：多人会话、任务执行者、日程参与人、审批抄送人、电话会议，现有容量分别是100人、20人、100人、100人、0（新功能）。那么如何确定需不需要扩容呢？我主要从以下三个方面进行考虑：
1、 现有容量的使用率
如果现有容量足够用户使用，那么扩容将可能是一个伪命题。
例如，对于某产品的任务执行者场景，从运营系统中查询该产品最近七天所有任务的发送情况，统计任务执行者数量，结果如表1所示。
表1 某产品最近七天所有任务的执行者数量统计
根据统计结果可知，90%以上的任务的执行者在5人以内（含5人）；只有约1%的任务的执行者在16人以上（含16人）。因此，目前的任务执行者容量能满足用户的使用需求。
但是，客服部门确实收到了部分用户关于任务执行者数量不够的反馈，这其中的原因主要是用户在不该使用任务的场景使用了任务。例如，通知全体员工一个事情也使用了“任务”（本应该使用“电子公告”）。
因此，最终的解决方案是：一方面，安排客服人员给提出扩容需求的用户详细解释“任务”、“电子公告”等关联功能的使用场景；另一方面，后期针对不同功能使用场景重叠的问题，反思每个功能的定位。
2、 服务器压力
有些业务场景支持的人数越多越好，例如多人会话。但是，也不能盲目扩容。因为人数上限增加之后，服务器的压力也会随之增加。在多线程、高并发情况下，服务器是否能扛得住，这是在确定人数上限时必须考虑的问题。
对于这个问题，产品部门通过分析和调研确定一个理想的人数上限之后，技术部门需要做一些压力测试确保产品的可靠性和稳定性。
3、 商业目的
对于一些用户有需求、服务器能承受的业务场景，出于后续商业目的的考虑，也不一定会一次性将容量扩到最大。
例如，某产品的电话会议对接的是第三方，第三方支持的最大容量是50，但在该功能上线时人数上限却定为10。这是因为，考虑到未来可能考虑将电话会议作为一个盈利点，那么将剩余容量作为增值服务是一个不错的选择。
二、能否选自己的问题
“自己”指的是用户本人，在能否选自己的问题上如果处理不好，会带来一系列问题。
1、 业务上是否支持选择自己
不同的业务场景下是否支持选择自己是最先需要考虑的问题。
大多数场景中应允许选择自己（如多人会话、转发、任务执行者、日程参与人、审批人、审批抄送人、电话会议），其中一些场景中还必须选择自己（如多人会话、电话会议）；而另外一些场景下选择自己将没有意义（如审批转交），甚至会产生异常（如公费电话），因此不应允许选择自己。
2、 是否列出自己
大多数业务场景中，自己是一个可选的参与人，因此应当列出自己并供用户选择。但是在一些特殊的业务场景中（不允许选择自己、必须选择自己、默认选中自己），是否选择自己的处理会比较复杂。
在组织架构中，如果不列出自己，那么自己所在分支的实际列出人员的数量将与该分支总人数的显示不符，会给用户带来困惑（例如：显示分支有8个人，怎么点进来只看到7个呢？）。因此，在组织架构中应当列出自己，但是要针对不同的业务场景做一些特殊处理：群聊和电话会议场景下，自己必须作为参与人，因此应默认选中自己且不能取消选中；统计发现，日程参与人中，大多数的用户均选择了自己，因此应默认选中自己且可以取消选中；公费电话场景下，自己给自己打电话是不被允许的，因此应禁止用户选中自己，若用户试图选中自己则应阻止并给予必要的提示。
在个人联系人和最近联系人中，是否列出自己都没有问题，但是有两点需要注意：第一，在一些不允许选择自己的场合下（如公费电话），列出自己却在用户选择自己时阻止并弹出Toast，这样的体验不够友好，因此这些场景中的个人联系人和最近联系人中不建议列出自己；第二，其他场合下，个人联系人和最近联系人中是否列出自己都是ok的，建议以最小改动为原则，除非必要（如出现bug）则不改动，把研发资源腾出来去做更有价值的事情。
3、 不支持选自己的业务场景中选了自己后的提示
如果用户在一些不支持选自己的业务场景中选了自己，则应该给予用户提示。而选人控件中的这些场景中的提示信息的作用只是告知用户“不能选择自己”这个事儿，也不需要用户对此作出响应，因此采用Toast形式就够了，没必要采用Dialog这类对用户干扰过大的提示形式。