软件工程之美41讲——为什么程序员的业余项目大多都死了？
软件工程之美41讲——为什么程序员的业余项目大多都死了？
为什么程序员的业余项目大多都死了？
- 想法大，时间少
很多程序员在业余做项目开始之前激情满满，经过一段时间没有进展，没有正向反馈，很容易就激情消逝，不想再继续了。尤其是一段时间后，可能又有新的项目想法了，于是就又开始了一个新的循环。
- 过于追求技术，缺少约束
而我一旦去做业余项目，就会陷入过于追求技术的困境。程序员的业余项目，因为缺少成本、时间和范围的限制，没有设置 Dead Line 约束，所以经常会天马行空，只为了追求技术上的兴奋点，恨不得把新酷技术都用上。但如果看看项目的定义：项目是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。（摘自百度百科）你就可以发现，项目是要有目标要有约束的。一个缺少目标和约束的项目，是难以成功的
- 缺少产品能力和运营能力
程序员们真正要去打造产品的时候，却发现要做一个产品并不是那么容易的事情，缺少产品能力就无法设计出好的产品，缺少运营能力就算产品做出来也鲜有人问津。而那些真正成功的独立开发者，无不是能兼顾产品设计能力和产品运营能力，既能设计出真正解决用户需求的产品，又能通过一定的运营让用户了解产品，为之买单付钱的人。
怎样提升业余项目成功的概率？
- 怎么样让项目不至于半途而废？想法大，时间少怎么办？怎么样让项目不至于半途而废呢？
那么最适合调整的边就是范围这条边，毕竟作为一个业余项目，你可以先实现最核心的功能。可以采用 MVP（minimum viable product，最小化的可行性产品）的模式，一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代。前不久一个朋友做了一款播客的应用，他就是采用的 MVP 的开发模式，先快速发布了一个只有核心功能的版本，甚至还很多 Bug。发布后邀请了几个朋友试用，收集了反馈，并且也把发现的 Bug 修复了，再逐步增加新功能。这样几个迭代后，他的 App 已经登上了新闻分类的排行榜。如果一开始他就想的是要做一个很大的项目，也许到现在还在开发中呢。即使程序员做的是业余项目，还有必要补充的一点就是：在决定做什么项目之前，一样要充分考虑项目的可行性研究。
2. 怎么避免陷入过于追求技术，项目难以交付的困境？
这其实也是我在专栏一开始就写的《02 | 工程思维：把每件事都当作一个项目来推进》中提到的，要把业余项目也当作一个正式的项目，做你的业余项目时，也要站在项目的整体去思考项目的进展，而不是沉迷于局部的技术实现。所以你有业余项目的话，也要像专栏文章《11 | 项目计划：代码未动，计划先行》中提到的那样，去做项目计划，去设置里程碑。还要敢于把计划和里程碑分享给你的家人和朋友们，公开的做出里程碑的承诺，让他们帮助监督你的计划执行。当你有了一个可行的计划，有了真正的 Dead Line，你的项目交付就有了基本的保障。我前些年运营过网站，一个针对我的母校西北工业大学校友们的论坛网站叫开放实验室，我需要负责这个网站的日常运营和程序开发，所以每次升级之前，我都会在论坛发帖子公布我的升级计划，设定一个上线时间，这样网站的用户会监督我的项目进度。有了进度的压力，就会逼着我必须按时完成，而不是老想着用什么新酷的技术。在你的业余项目难以交付的时候，记住一句话：Dead Line 就是第一生产力。
3. 怎么弥补你的短板
比如说你可以从解决自己的需求，解决家人朋友的需求开始，设定一个小的产品目标，然后借鉴类似的产品，模仿它们的产品设计、交互设计，就能做出来一个基本可用的产品。像 UI 设计，其实现在无论是网站的 UI 设计还是 App 的 UI 设计，都趋向于标准化，对于一个业余项目，使用一些标准模板，或者花点钱购买一套漂亮的界面模板，都是不错的选择。我个人的一点经验就是，如果你要运营一款产品，你需要想清楚以下几个问题：想清楚你的产品能给用户带来什么样的价值？帮助用户解决什么问题？商业模式是什么？也就是用户是不是会为你的产品付钱？或者你的产品通过什么方式赚钱？如何让用户知道你的产品？如何让用户知道你产品所能带来的价值？只有想清楚了你的产品的核心价值是什么，才好去针对性的运营你的产品。具体产品的运营上，可以找你的朋友作为第一批用户，然后去像Product Hunt这样的网站发帖子自荐，还可以通过微博、Twitter 这样的社交媒体宣传。除了自己去学习产品知识和运营知识之外，其实还有一种方式，就是组建一个小团队，找到志同道合的人一起，你写程序，有人做产品设计，有人负责运营推广，大家取长补短，一起把产品做好！
