前言
最近一年的时间里，我一直在一个创业团队做后端开发的工作，有时候也需要跟一下项目管理之类的统筹安排，通过处理不同的事情以及和不同角色的伙伴沟通，慢慢地我也产生了一些思考。
受自身经验与所处环境限制，这些观点不一定对，如果有人看的话，希望你们可以辩证地去思考。
正文
由于阅历会逐渐增加，本文内容我也将会持续更新。
态度认真很重要
懒散的态度对团队有很大的消极影响，就算是完成了任务也没有完成责任。
不一定都得非常厉害
- 聚集一群都厉害的人这件事本身就非常困难
- 水平有层次更有利于团队凝聚
- 不一定都得非常厉害，但是不能拖后腿
先有将后有兵
先搞定核心业务的核心人物再考虑扩招，而不是跟学10年前的老话：“就差一个程序员了”。
0 到 1 的重要程度，大于 1 到 100
- 0 到 1 是一个质变，1 完成了，大家才会觉得靠谱
- 1 到 100 是一个量变，大家不迷茫了以后才更有方向感、凝聚力
完备性会比性能更重要
一个 C 端接口的投入大量的人力去优化，响应时间从 200ms 减成 100ms，乍一听优化了很多很厉害，其实呢，不如去好好设计业务需求。
最小颗粒度及时上线很重要
从 0 到 1 的时间一定不要太长，团队里的所有人，都需要一个正反馈。
确认比信任更重要
即使某位成员非常靠谱，备受信任，也要得到明确的结果。
不要过度优化
以前的我认为：“写得慢也不要写得烂”，现在的我更觉得：“把控不住进度都是扯淡”。
多给团队一些反馈，哪怕是不好的
有任何不合理的地方，一定要及时提出。好的行为就奖励，不好的行为就惩罚，千万不要“秋后算账”。
负责人得先舒服了
没错，就是得到“舒服”的程度，领导的面部表情有时候能决定到团队一天的效率。
一定满足不了所有用户需求，挑关键需求做，而不是全部都做
- 0 到 1 是为那些特征用户服务的，这些人能用就行了
- 在 1 到 100 的阶段再去追求覆盖率， 0 到 1 的阶段先解决问题
每周都花时间去总结
- 自己做了哪些决定（或者否定了哪些决定）
- 大家有没有成长
- 最关键的点：项目进度到底可不可控
及时拍板，不要怕担责任
项目中一定会有错误决策，不要害怕承担责任，大家如果都在犹豫就会很容易败北。
在没有得到用户验证的情况下，不要凭空脑补需求
凭空的需求只会拖慢从 0 到 1 的进度，而且这些需求也不一定都很正确，甚至随着时间的推进，这些需求也会“凭空消失”。
业务大于技术
虽然我是技术岗位，但是我还是坚持认为 技术一定要服务于业务，技术要用来解决需求。
无论抗癌药物研究的多么先进，拉肚子的时候也不会去吃它。
从 0 到 1 更需要的是服从，从 1 到 100 必须要发散
- 说服从可能有点过于阶级化，但是在 0 到 1 的阶段中，产生决策之后就是需要大家一起去执行
- 1 到 100 的时候更需要大家去提升自己，做到 100 而不是只到 50
……
结语
受自身经验与所处环境限制，这些观点不一定对，如果有人看的话，希望你们可以辩证地去思考。