我作为一个工程师，引以为傲的，便是不要求需求一定是完全详尽的，我会根据自己的个人经验，来帮助产品经理补全这些内容。
但另外一个层面，我也确实在思考，为什么我们会希望需求尽可能明确？
需求明确，意味着工程师在拿到需求之后，就可以开始工作了，而无需思考这个需求中的不合理的部分。
但当你和一个不靠谱的产品经理去合作的时候，就会发现，几乎约等于没有的需求，意味着在产品的研发过程中，存在大量的重写和改写的部分。因为产品经理前期思考的不充分，和后续的架构调整的计划较多，就会导致项目在后续研发的过程中，会出现不断的架构调整，推翻之前的工作，对局部进行重写，最终导致工程的不断 Delay。
当然，我也并不是说，我们应该在事事上都去追求完美的产品设计，这显然不现实，时间成本也比较高。但确实，作为一个 Trade Off，这是一个存在的现象。
换句话说，如今的行业的不断细分，是有其存在道理的。流水线化让每一个人的产出可以被量化、我们接受标准的 Input 和给出标准的 Output，让每一个人的工作都可以更加轻松。
从腾讯出来以后，我一直还在用的，和腾讯内部一样的工具，便是 —— TAPD。
说句实话，TAPD 的编辑器是真的很难用，但我很难找到类似的产品，只能继续使用 TAPD。
Trello 我一直还在使用，但我只会在一些个人的项目上使用，更多的时候，我是用 Trello 替代 ToDo 类应用。但涉及到更加复杂的需求/Bug管理，我会选择使用 TAPD 这样的应用来完成。
相比于 Trello，TAPD 提供了看板和看板以外的功能，比如文档、Wiki、需求管理、迭代管理、Bug 管理等功能，对于一个软件开发项目来说，所需要的几乎都提供了。
看板的功能只是TAPD中的一小部分，更重要的是 TAPD 提供了需求管理和标准的富文本编辑器，这使得一个需求可以更加详细的被描述，在开发过程中，开发者可以更好的和产品经理去对齐需求。
类似的，还有迭代和Bug管理，这些并非不能通过 Trello 实现，但Trello 的核心还是一个 KANBAN，对于更加重量级的内容管理，是力不从心的。
出于上述考虑，我最终选择了 TAPD，而不是 Trello。
国内类似于 TAPD 的产品还包括，腾讯旗下的 Coding，Coding 除了提供了基础的代码托管功能以外，还提供了项目管理工具，可以让开发者更好的管理自己的软件项目。
希望这个图对正在建立自己的课程研发体系的你有帮助。
独立开发者中有一大批人是通过做工具来获取收入的。做工具也算是独立开发者圈子中经久不衰的话题了。
但到了具体的工具开发之时，其中又有不少可以拿来讨论的内容。
而这里，我最想讨论的是工具的理念。
对于工具类的软件开发而言，最容易出现的就是「别人做了一个什么东西，我觉得不够新/便宜/不爽，我自己也要开发一个」。对于开发者来说，遇见问题， 并自己解决问题是非常常见的。 但是，工程师常常的问题也在于此，因为复制一个产品的成本越来越低，所以最先选择的是复制，而不是思考这个产品的长期发展道路。这会让产品陷入简单的 Copy and Paste 的模式下，长期来看，并不利于产品发展。
在我看来，如果工程师想要做好一款工具，那么一定要为自己的工具准备一个最基本的方法论。这个方法论一定是基于你自己对于问题的看法做出的拆解，而不能是依赖于其他第三方软件的。
这个方法论将指导你的产品朝着最终的目标，要解决的问题，奋力前行。你后续所遇见的问题，都会成为你前行的助力，为拓宽前进的道路。
而一个没有方法论的产品，则会被途中遇见的各种问题引导偏离最初的目的地。我们目前的市场中有太多的工具了，每一款工具都有其优秀之处，倘若没有自己核心的理念，那只会被众多的 Feature 搞得「乱花渐欲迷人眼」，最终失去了自己对于工具的定位，抄成了一个四不像。
如果你想要以一个小团队打造一款好用、生命力持久的工具，那么先想清楚你的目标和理念，再动手开发，是一个好的路子。需求有很多，但并不是每一个都适合你。工具有很多，也不是每一个都适合你，预期去抄别人的理念，做别人要做的工具，不如发现自己的需求，做自己的工具。
我这几天在 Twitter 上发了一条推，引起了一些热烈反响。不少推油也从不同的角度给出了看法。
后续我也补充了一些信息
不过，我觉得我可能需要完整的描述一下我对于独立开发者的定义，以确定大家的讨论会在同一个维度上。
技术人的常见路线其实很明确，总体可以分两个大类：技术专家和产品研发。
技术专家的特征是对于技术研究更深刻，会更加专注于某一项技术的研究，有通才型的技术专家，但较少。更多的是在某一个领域方面深入的技术专家。
技术专家的话，一般而言，最好的路线是进入企业，以技术专家的身份，被企业供养着。特别是进入大的企业，较大的企业拥有足够的技术场景可以供技术专家进行深度研究。同时，大型企业也拥有足够的预算来供养这些技术专家。
产品研发类，不会太过于纠结于技术的本身。而是会将更多的精力投放在技术产品的价值。
这类人大多最终会走上独立开发者/创业者的道路，企业内部虽然也会有内部创新的道路，但可能很多时候会受限于企业的资源和布局，因此，在出现企业利益与产品利益冲突的时候，容易触发这类人离职。
产品研发类的人的特点是，技术也会研究，但不会像技术专家一样沉迷于某一个技术，更加关注是技术之间组合产生的价值，站立在产品、研发、和人文的交叉点，讨论组合产生的价值。
从他们的表现逆推，则可知，两种发展路线可能会需要的一些特性：
关于独立开发者而言，需要具备的特点有很多，这里仅能根据自己的经验总结一些，也欢迎各位在下方评论。共同讨论。
因为我有“好为人师”的坏毛病，所以我经常制作一些视频，去指导别人，要如何做一个东西，在这种场景下，我会考虑制作一些视频。
这篇文章是介绍我的视频制作的课程，介绍一下我是如何制作视频的，并将这个流程分享出来，让大家了解，并给出一些建议。
因为目前在做运营，所以经常要做一些活动。
在做活动的时候，会涉及到不同的角色，就工作人员而言，会分为 Owner 和 Staff 两种。
Owner 是活动的主要负责人，无论是最终的活动效果、活动转化率等等，都是由 Owner 背负。
而 Staff 则更多是项目中的合作者，他们可能是单项特别强，或者是掌握了相应的资源，或者是因为没有什么事情，被拉来帮忙的。
不过，无论 Staff 因为什么原因加入到 项目，可以肯定的是，Owner 相比于 Staff 能够了解更多的信息，在这种情况下，Owner 可以给 Staff 提出建议，当然，Owner 也可以不给 Staff 建议。
在之前的活动中，我曾经吃过亏，因为Owner 没有给 Staff 建议，结果 Staff 在对接资源时，对接了大量的非目标群体的渠道，致使钱花了，效果达不到。
此外，这里强调，是建议而不是要求。对于外包，可以给出要求，但对于项目的合作者，还是要给出建议，给 Staff 一些拓展的可能和空间，从而让活动有更多的可能。
标准作业程序（英语：Standard Operating Procedures，常缩写并简称为SOP）是指在有限时间与资源内，为了执行复杂的事务而设计的内部程序。从管理学的角度来看，标准作业程序能够缩短新进人员面对不熟练且复杂的学习时间，只要按照步骤指示就能避免失误与疏忽。
https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F
标准作业程序的成立理由，通常有下列几点：
标准作业程序可以节省时间，进而达到高效率。
标准作业程序可以节省资源的浪费，从而达到环保效应。
标准作业程序可以获致稳定性，稳定可以使组织继续存在，也是主要动力。
https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F
标准作业程序也可能产生若干问题，反而阻碍目标的实现：
标准作业程序常会抗拒变迁，无法因应特殊环境需要而适时调整。
标准作业程序的执行可能会延误时机，无法满足多数人的需求。
标准作业程序往往造成“新政策”与“旧实务”之间的矛盾，较难推动改革。
https://zh.wikipedia.org/wiki/%E6%A8%99%E6%BA%96%E4%BD%9C%E6%A5%AD%E7%A8%8B%E5%BA%8F
运营工作难做就难做在没有 SOP
如果你也和我一样，使用[兔小巢][1]来作为你的产品用户社区，那么你一定会遇到一个问题：反馈不及时，由于兔小巢本身没有和用户的强关联，只有当用户主动填写了个人信息，或关注了兔小巢的服务通知，你才能对用户进行消息的触达。因此，你的回复的时效就十分重要了，快速的回复可以让你的用户在还没有失去和你的联系时获得反馈，完成一次有效的用户交流。因此，实时的信息反馈就十分重要了。
但是，兔小巢本身并不具备实时推送问答的能力，因此，我们需要借助一些第三方工具来完成自己的目的，在这篇文章中，我将向你介绍，如何使用腾讯云云函数将兔小巢的消息转发到企业微信当中。当然，如果你使用的聊天工具不是企业微信，而是诸如飞书、Slack、Bearychat，你也可以参考这里的说明，完成自己的相应的需求的实现。
这里使用兔小巢的提供的 WebHook ，来接管所有的用户请求，并辅以腾讯云的 API 网关和云函数的能力，将实时推送的消息转发至企业微信。
这里我实现了企业微信，但对于你来说，还可以用来实现其他同类似渠道的能力。
由于这篇文章是兔小巢的高级用法，因此，对于如何创建一个兔小巢产品，就不再赘述，此外，以下步骤均在电脑端操作，因此，请使用电脑来执行下述流程。
首先，你需要打开兔小巢的管理后台，打开产品设置 ，在其中找到 产品 ID，复制这里的产品 ID，后续我们会用到。
由于我们本次要实现的是兔小巢消息推送到企业微信，因此，我们需要创建一个企业微信机器人。
在你需要推送消息的群上，右击，选择其中的添加群机器人，
并在弹出的窗口中选择从新创建一个机器人
在新弹出的窗口中输入机器人的基本信息，并点击添加
添加完成后你会获得一个 WebHook 地址，复制这个地址，后续会用到
访问腾讯云云函数控制台，点击界面中的新建，新建一个云函数。
这里函数的地域可以根据你的需要选择，几乎没有影响，我选择的是广州地域。
随后，在新建函数的时候，输入函数名称、运行环境（运行环境选择 Node.js 8.9），以及创建方式，选择空白函数。
填写完成后，点击下一步，在新的页面，设置函数的描述，这里需要注意，执行方法不要做任何修改，使用默认的，除非你知道你在干什么。
然后，复制这段代码，粘贴在下方的代码框中，操作步骤参考动图
'use strict';
const request = require("request")
const productId = ""
const botUrl = ""
function requestPromise(r,t){return new Promise(function(e,n){request({uri:r,method:"POST",body:JSON.stringify(t)},function(r,t,i){if(r)return n(r);try{e(i)}catch(r){n(r)}})})}
exports.main_handler = async (event, context, callback) => {
const txcData = JSON.parse(event.body);
if (txcData.type == "post.created") {
await requestPromise(botUrl, {
"msgtype": "markdown",
"markdown": {
"content": `**新增用户反馈**\n\n${txcData.payload.post.content}\n\n[点击查看详情](https://support.qq.com/products/${productId}/post/${txcData.payload.post.id})`
}
})
}
return "ok"
};然后，将第三行的 productId 中加入你的兔小巢产品 ID，将第四行的 botUrl 中加入你的微信机器人地址。
比如，我的修改完是这样的
'use strict';
const request = require("request")
const productId = "149567"
const botUrl = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=d8c1e6b1-ccbf-467e-8dcc-31c1961baf41"这里需要注意，不要删除放好的引号，把 ID 和 WebHook URL 放在引号内部就好，以免你的输入法输入了中文引号导致出错。
修改完成后，保存文件（按下 Ctrl + S 或 Command + S），点击下方的 完成，进入到函数的详情页。
接下来，我们为函数生成一个请求地址，用作后续兔小巢的消息提醒。
在函数的详情页，点击左侧的触发管理，选择创建触发器，创建一个 API 网关触发器
触发器的具体配置可以参考下方的图片。
创建成功后，你会获得一个访问路径，这个路径就是你的函数请求地址了。复制这个地址，下一步我们就会用到。
回到兔小巢的后台，找到左侧菜单栏中的 开发 – 新反馈实时通知
将刚刚你生成的函数的访问地址，粘贴在这里，点击保存并发布
保存成功后，就可以去你的兔小巢中发反馈，测试一下效果啦
当我在兔小巢社区发了一个新的反馈后，我的企业微信群内就出现了一个新的消息提醒，提醒我有了新的反馈，同时，还带上了一个链接。点击这个链接，就可以跳转到我的兔小巢对应的反馈页面，方便快速回复。
通过简单的配置，我们就可以很轻松的实现兔小巢反馈的实时推送，十分的方便。对于广大使用兔小巢的运营同学来说，现在你可以不用每隔几分钟就去刷新一下社区了，耐心的等待机器人的推送就好了～工作效率大大的得到的了提升。
用户运营是一个可大可小的事情。可以宏观运营，只针对用户进行大数据的切分、标签、触达；也可以小范围的对用户进行更加细化的产品运营，更好的促进用户和产品的交流，为产品发展添砖加瓦
内容在产品运营中是一个重要，而又不太被重视的部分。
重要是，这玩意就像基建，很难看 ROI，但对于产品的长期发展来说，是有不少好处的。不太被重视是，产品运营的工作本身很难去做内容产出，因为产品运营在团队中更多是 Connector 的属性，需要连接不少人。
挺难的。不过，也更加让我自己明白其中的价值。
