团队中的产品经理最近提了几个问题，趁此机会做一下分享。
有朋友反馈之前文章太长。所以从这篇开始，我缩短文章的内容，拆分为多篇陆续发出。
这是产品问答的第三篇，也是《百尺竿头更进一步》的上篇，主要讲“更进一步参与基础工作”。
问：
我觉得我最大的问题是，脱离了基础工作，我有点不知所措，我还可以在哪方面去做更多~
答：
提升到管理岗位，说明你工作已被认可，工作获得不小的进步。
中国有句古话叫“百尺竿头，更进一步”，意思是“获得一定成就之后不要自满，继续前进以追求更大进步”。
你提出这个问题，说明你在继续学习上有充足心理准备，这是一件非常好的事情。每个人的学习路径都不同，想要指导甚至帮助别人规划学习，我还没有那么大的自信。
我只能从个人角度提出一些建议，仅供参考。
不做甩手掌柜
从执行岗提升到管理岗之后，最要不得的，是完全脱离基础工作。
首先，要承担产品信息承上启下的作用。
要保证自己对于产品战略、产品路线图的全面理解，不但要知道是什么，还要知道为什么是这样，而不是那样。要“知其然，知其所以然”。
接着就是在团队中，对理解的信息进行宣教，让团队在基础认识上保持一致。这可以节省很多时间，让团队省去很多不必要的多次沟通和争论。同时也可以让团队在执行相关任务时，明白方向是什么，哪部分是核心。
其次，要承担基础工作中，最核心最决定成败的部分。
就如上一篇《提岗管理后的团队管理及项目管理-产品问答第三篇》中所提到的。你应该是最了解团队工作前提的人，即已经确定的产品战略、产品路线图。那么你需要承担对应各端的关键模块、关键页面的设计，保证产品基础的工作和上层信息一致。如果只进行了信息传递，而不参与进去，最后结果物可能会有很大偏差。必然会返工、重复，导致时间成本的浪费。
最后，在承担核心部分的基础工作时，同步推进交付物标准。
清晰可执行的交付物标准，是保证产品交付物高质量的前提。
如何保证制定的标准清晰且执行？如何保证团队准确理解和执行标准？
制定标准不能假大空，不能建立在虚无幻想之上。否则标准就可能变成桎梏，不但不能提高效率和质量，还会拖后腿。
制定交付物标准有几个原则：
1、自身积累经验
在工作中逐渐积累的，产出高质量交付物的经验，最适合转化为标准。
我进行产品设计时，使用“产品线+产品端+版本号+文件描述+6位日期+大写字母序号”的命名方式。同时在进行较大量的修订时，都会复制文件进行命名。
例如：我第一次编写某版本原型是命名为“登月计划-系统后台-V2.2.3-界面原型190201A”，我在3天后进行较大量内容的修订，复制并命名为“登月计划-系统后台-V2.2.3-界面原型190204B”。
这样我每个版本的记录都会保存在，这样的好处有很多的。我可以回顾整个迭代过程，可以随时找回某个重要版本的内容。
2、研发团队建议
产品设计时经常将“用户需求”这个词。产品交付物也有“用户”，就是负责开发的RD们。在制定标准时，要参考这些“用户”的需求。
在某个项目的标准制定过程中，开发团队提出希望中后台的需求文档，能以交互原型的基础来来实现。这样在开发时，不需要来回切换交互原型和需求文档，还要寻找之间的一致性。在搜集到这个需求后，团队为满足需求进行了尝试和修订。最终着到合适的呈现方法，满足了开发团队的需求，提高了开发的效率。
3、可读易用性
产品要关注“用户体验”，产品交付物也一样。写给人看的东西，一定要保证可读性。用于开发参照，一定要保证易用。
在制定标准时，为了满足可读易用性，我有如下经验：
a、规范专业术语。规范文档本身的用语，便于阅读者更高效理解；
b、能用数学就不用文字。数学是最精确的语言，在准备传递信息方面，远好于任何其他语言文字；
c、描述时说人话。好的描述文字，要保证没有专业基础的人也基本看懂；
d、不写复杂，不写长句。复杂表述和长句子，对于阅读者很不友好；
e、格式和标点符号要规范。规范的格式和标点，能提高文档的理解效果；
f、所有图片保证清晰。不清晰的图片，还不如没有；
g、目录、引用和跳转。目录、引用及跳转等，能让文档更方便被使用。
4、保持迭代
标准是需要迭代的，根据实际情况的变化和使用中的反馈，逐步调优。
尤其在标准发布之前，最好团队内部多尝试，也尽量邀请开发代表参与体验。避免发布后的标准，沦为没有市场的产品。
明天，我会讲接着讲下一个建议，构建团队沟通规则。
