最近读了《凤凰项目》感触很多，花了三天就读完了，由于我的工作日常中也是存在很多技术支持，书中的早期案例很多好像是按照我的遭遇写的，感触颇多。
计划外工作
书中讲到，计划外工作占据了IT的绝多数时间，导致业务往往产生了较多的堆积，最终半成品较多，导致什么事情都没有做好。
我们作为SDK研发，面对公司的项目组也有同样的问题。接入SDK中，往往会抛出各种问题来，这时我们就需要抛开自己的研发任务，全力去支持项目组。这些频繁的计划外工作，往往会导致我们研发的进度延期。
针对此情况，考虑建立完善FAQ相关文档，创建标准化排错流程。当标准流程化创建完成后，是否意味着不需要研发来进行协助项目组？根据目前我们遇到的情况，这种应该可以规避大多数问题的。
约束点
在书中，布伦特为约束点。反观SDK研发谁是约束点呢？ 由于我们面对的是Unity技术，所以我认为我们的约束点，不是个人角色，而是平台，也就是Unity平台。如果这样，原生开发人员在加强Unity学习的情况下，我们就可以突破这个约束点，增加并发吞吐量。
反馈流
我的理解是产品快速迭代、反馈，而不是搞一个任务时间很长、功能很大的功能集中反馈，此时任务很容易失调。我们就发生过发布SDK后，未及时验证数据准确性，导致问题延迟很长时间才发现，这增加了产品研发时间，也加剧了计划外的工作量，导致忙于各种救火。快速迭代，1-2周一个版本，出了版本后快速验证数据，及时反馈。
信任
信任是决定合作是否能成功的重要因素，尤其是跨团队合作中。我们经常被问到的是“这些SDK哪些项目已经验证过了”，一般如果没有被其他项目组验证，是很难推进的。那作为支持部门 ，我们要理解这种想法，站在公司的角度，以及如何帮助项目组尽快上线等角度去看待这个事情，其次也是要增加我们产出的稳定性，长此以往慢慢的把信任培养起来。