多学多写，这个急不来，只能慢慢积累。

个人项目有问题就改，甚至重写，走弯路可以学到很多东西。我有时走歪了，一顿折腾后回头重写，通常可以比当初改进很多。

每个人的条件千差万别，都 40 岁了还不会根据自己的实际情况来安排时间吗……

项目组长能力不足。

组长要了解团队成员的能力，才能设定比较合理的工期。

在开发过程中也要不断重新评估，有问题及时提出来，发现原定工期来不及了，该延长就提出要延长，能删需求就删需求，问题出来哪里越早提出来才能越早解决。

改 bug 时间比开发长，这个不是问题的核心，核心是造成这一切的原因有没有去找啊，开发过程中为什么没有发现问题啊，或者有人曾提出来问题，组长 /领导为什么不重视啊？

密码规则有些缺点：更换密码难，调整长度难。

就不要剩余次数 和 剩余金额了吧，主要是方便不了多少。甚至可以说更麻烦了，因为要维护这两个数字与另外两个表的一致性。

因产品犯错导致返工的情况，通过邮件也好、会议记录也好，让产品承认错误。有了这些记录，以后可以怼他，甚至把事情搞大，换人。

@diesans

《用资本战胜资本（一）》是定方向。

《用资本战胜资本（二）》是解问题。

然后，在找红人与搭台子之前，我认为还需要在 “解问题” 这一步给出更具体的细节，也是时候制定一些更具体的东西了。

我最关心的还是具体、细节。你现在描绘了一个 “实现后” 的理想状态，但由于缺乏实现的过程，看起来就像一个空中楼阁，很美丽，但没有根基，看着让人不安，怕不稳，容易倒塌。

举个例子：比如你说 “开发一套应用了区块链技术的办公软件”，这里面我看有很多问题。

1. 如果初期找到少量红人，而这些红人的能量（能力、资源、资金）不大，这个开发软件的钱就凑不齐。

2. 如果初期有大能量的红人投资，那他能获得什么收益？由于每次销售产品时都会把一部分股份分出去，那么，对于初期投资者来说，他的股份会不会越来越少？（这个计算方法也很重要）

3. 区块链技术就一定能确保 “不可伪造”“全程留痕” 吗? 据我所知，区块链也有可能受到攻击，如果你不把可能受到的攻击方式以及相应的防护措施写出来，初期有可能吸引一些不懂行的人，但这里有隐患，随时会被人质问，比如商业上的竞争对手抓住这一点搞舆论，就会产生信任危机。

另个，关于 “高管集权问题”，社企的最高决策单位，是“消费者委员会”，而同样重要的监督部门是 “钓鱼监督团队”。

那么，问题来了，“消费者委员会” 和 “钓鱼监督团队” 的成员怎样选定？这个你没有说。要注意，对于办实事，真心想参与到你设想的这个事业中的人来说，你只给出了部门名称，却没有给出产生办法，会让人觉得很虚，没有诚意，做事不塌实，以及会导致无法执行。

你必须先给出具体的执行方法，方法不完善可以后续慢慢改，但这个部分不能留白呀。


上面我只是举了一些例子，在“解问题”这一步，你要么需要吸引同道中人一起去完善，要么自己去完善，不管如何，依我看还是需要给出更多更具体的细节。

小米 11，买到了就是赚到了。

来了来了，又开始有人跃跃欲试要进场了，如果这种现象多起来就该撤了。

你这种情况，就该学 bootstrap，一个主要原因是它帮你适配了大屏幕和手机屏幕，省了你再学那些细节。

另外一个原因是它在布局方面的官方教程写的很好，虽然跳不出 flex 和 grid 概念，但它教程易学易懂啊。

重不重要，总得对比吧，如果时间有限，语言天赋又一般，花大量时间去死磕口音，值得吗？

看了答案还忘记？这个理解了不容易忘记的啊...

多数情况下尽可能避免使用 null 应该比较好。但这事情没有定论。

@intellectual 双十一、PDD 百亿补贴，以及美团、滴滴之流，都是靠特价引导用户习惯，一个个都活得很滋润啊