产品经理写文档很麻烦，规则容易漏，除了加强自身技能锻炼外，我灵机一动...

[renxiangbin]

产品经理写文档很麻烦。
看到开发人员的代码提示真炫酷。
我也想要一个输入 TextField 就提示我默认是啥，密码框还是普通文本框，如果选密码框，然后选密码安全等级规则...
规则都提前写好，反正可以复用的都还挺多。
我初步试了 sublime 的 snippet。

如果开发知道我是这么写的文档的
会不会疯掉
我好怕怕...

我去设计个 TextField 的 snippet，好玩再跟大家分享。如果你对此~~抱有希望~~有好的想法，欢迎来 Telegram 畅想。https://t.me/joinchat/EukrYA1RDmDQ4qhYNosiwg

自以为是的放到 GitHub 上，当前就一个 radio，还在探索和补充。欢迎吐槽。https://github.com/renxiangbin/prdSnippet

[noe132]

然后开源产品经理文档 snippet，成为 npm 第一下载量产品经理中文 snippet，github star 数第一，之后产品经理必备技能多了一项，熟练掌握和使用各种文档 snippet XD

[zhouxuchen]

文档写得完善开发高兴还来不及呢……实际情况是大部分 PM 是个时序图都画不出来的垃圾

[xiqingongzi]

好主意，不妨完善完善你的需求，做个 sideproject 出来

[shoumu]

你一定是在说不熟练的或者不优秀的产品经理。
你看某些厉害的开发人员，没装任何插件的 vim 不一样用得溜得飞起吗

：）开个玩笑，忽略我

[gaobh]

🐂，能搞出来产品经理专用 IDE，至少能缩短一半需求准备时间

[ichanne]

这个可以有

[renxiangbin]

@zhouxuchen @shoumu 这种产品经理咱们不带他玩，就跟建议刚学习开发的人员不要用 IDE 一样一样的。

[luoway]

要不再来个产品文档模版网，专门分享各类需求模版

[nameryan]

这个 idea 值得有！！！大赞。而且还可以延伸到其他各行各业，不止产品经理写文档，那些重复劳动类型的文档也都可以用，最好能有一种通用的 ide。
btw，v2 上产品经理力量太弱，大多都是技术男，产品们要团结。

[nameryan]

@renxiangbin 开源吧，一起来打造属于产品经理的 snippet

[ycz0926]

靠，这得上 emacs，org 最适合做这种文档的活了

[renxiangbin]

@nameryan 你的支持，我的荣幸。今天就撸起袖子，搞起！

[lengjingxu]

感觉可以自己动手做

[renxiangbin]

@luoway 有个解释控件的知乎专栏： https://zhuanlan.zhihu.com/c_87416856，真想催龙爪槐守望者更，我们要不要去给他点动（压）力？

[luoway]

@renxiangbin 这个啊
类似代码补全
那语法高亮、语法检查估计也少不了

[renxiangbin]

@luoway 是的啊，初步定写成 Markdown 的格式，高亮这些就看 Markdown 支持了。

[luoway]

话说产品写文档能用 sublime 而不是 word ？表格、示意图什么的怎么办

[cairnechen]

@luoway

用 word 写文档很难受，我写文档都用 Typora，有流程图插件就够了

[renxiangbin]

@luoway 所以工作流也是考虑的问题。先定个小目标，看能不能先解决大量重复性劳动、遗漏的问题。插图，表格等，关于索引的问题，还得给花点时间思考。作为开发人员，你们希望看怎样的文档，产品经理们也愿洗耳恭听呀，都为了同一个项目不是嘛。

[renxiangbin]

@cairnechen 我过去用 Plain tasks 写，开发完成的打钩，连测试用例都不自觉的包含了一部分😆😆😆

[TimePPT]

Axure 模板了解一下

[renxiangbin]

@TimePPT 了解了之后就有了这个想法😆

[renxiangbin]

@TimePPT 欢迎吐槽😆

[TimePPT]

@renxiangbin
其实吐槽的点是，产品设计和需求文档没有银弹，包括登录密码交互提示，各类产品要求以及各家产品的现状都不一样。简单说就是业务决定需求，你直接生成的灵活性不能保证，还得手工改，到底能省多少人工我很怀疑。

而如果是普通布局和简单交互，Axure 的模板基本够用。

[TimePPT]

从根本上说，规则容易漏，最大的问题是开始需求理解以及逻辑流程分支闭环没想清楚，建议用脑图或者流程图去理顺。
流程图和脑图框架出来后跟开发去碰逻辑，按照业务现状和需要进行修补，等多方确认基本无误后再去写文档，至少能保证大方向上没问题，至于开发过程中遇到的小问题，勤和 RD 沟通，随时进行文档调整就行了。

再说回你的构想，如果业务固定，你做这套自用没问题，但广泛实用性并没有想象的那么高，理由就是我上面提到的，业务决定需求，你没法确定各家业务的情况，就不会存在银弹去解决产品需求问题。
而如果你把设想的这种东西做的过于灵活，需要在初期去设定很多规则值方便日后用，那也失去了你最初构想的意义，和每个人自己维护一套适合自己业务需要的 Axure 模板没啥差。

[renxiangbin]

@TimePPT 感谢吐槽。我还真没想过要把交互也包含进来。
一是想解决遗漏问题：比如我输入 TextField,输入“.”弹出 password、radio、checkbox，如果我选择 password，下面让我填写必要的参数，比如最大最小位数，是否可见，密码强度等级等等。至少我可以看着写，防止项目遗漏。
二是想解决重复性劳动的问题。比如我参与的一个项目，大部分都是表单。这里规则写一遍，很开心。又来一个项目，又是一堆表单。这个时候，就可以复用了。如果你把它作为一个收集整理自己规则的工具，可能也不错（我瞎说的）。
至于省不省力，我也怀疑，所以想听听大家意见。
最后就是看着开发写代码有提示很炫酷。。。。我的咋就不能有呢？

[shiweifu]

这确实是个刚需
snippet 这种方式不够彻底，最好有个集成的环境来解决这个问题

[renxiangbin]

@TimePPT 感谢回复。维护一套 Axure 模板不错，不过我一般都是打开个 txt，老老实实写一遍（个人工作习惯问题）。前期的沟通都很重要，包括项目进行过程中。不过我真不是非常看好开发人员当场发现多少我遗漏的问题。对了，关于你提到的大方向上的问题，我是限定在很基础的问题上面，比如“密码多少位”这种。说白了，我就是希望电脑在我写文档的时候能帮我做点什么，不用太智能。
关于灵活性，太灵活或者太不灵活都有问题，你说的没错。

[manihome]

Ulysses 写文档应该不是我一个

[TimePPT]

@renxiangbin
呐，像你说到的，密码一个 TextField 涉及到的约束条件就包括长度范围（最小、最大）、字符类型（数字？英文大小写？混合？是否可以有特殊字符，如果有可使用的特殊字符有哪些？）、可见性、密码强度检查（包括长度、必须的字符混合类型和比例、是否允许与设定的用户名、填写的邮箱等其他资料有重复字符），你这有些业务根本不涉及这么复杂，有些业务就确实需要这么复杂。你怎么统一？

编程时候一般是用一个基类，然后在子类定义时候去扩充属性，你这如果也这样处理不得麻烦死……
这还只是一个密码输入框。

[renxiangbin]

@TimePPT 嗯，没错。可以开发一套产品文档的语言了😄。接着密码输入框说哈。我初步想的是，密码规则有 1，2，3 级，我们产品现在要哪一级别，我就输入哪一级别。至于说，1，2，3 级别的规则是什么，这就由你来定了，要不就叫做 snippet 呢。

[TimePPT]

@renxiangbin 唉……

其实写文档只是产品经理的一部分工作，想提高效率就多积累，写熟悉了就好了。我工作九年多，最长的产品文档写过 70 多页。光登录注册改版就做过三家的，每家的坑都不一样。最坑那家在老版设计里把注册邮箱当用户名写死了，导致老用户没法完全解绑邮箱，这都是坑……

[renxiangbin]

@shiweifu 理想是美好的，哈哈哈，基于 Markdown，欢迎光临 telegram 愉快的畅想....

[renxiangbin]

@TimePPT 前辈您好，失敬失敬！我还是个菜鸟，真是有点大言不惭。欢迎光临 telegram 指导哈。

[TimePPT]

@renxiangbin 前辈不敢当，就是多趟了几年雷 233

[vectorzhao]

有钱途啊小伙子，开发出来当真是产品经理的利器。

[piku]

作为运维从头看到尾，你们在说什么一头雾水。不过之前写过打勾填数字就生成一周工作报告的工具

[ideacco]

作为产品狗，表示墙裂支持。

[ideacco]

不过作为产品我还是有个建议，这种类型的产品，其实主要考虑特定使用场景，比如我习惯在 Axuer 上画图，然后直接文字注译，或者说在思维导图里面直接写了，这时候这个文字处理方法就不合适了，比较合适的方法是让这个产品独立出来……

[renxiangbin]

@ideacco 握爪

[hangzhoupm]

有钱途啊小伙子，开发出来当真是产品经理的利器。

[zjl03505]

2 年多过去了，lz 还有在使用这样的方式吗？