项目制作随感 核心事情 1.责任到人 2.可量化工作量 知已，知彼 知已：知自己团队的战斗力是多少 知彼：要做的项目难度是多大 做之前，要做的事 （分责，量化） 1.两会 需求会 开完会后，回去思考4小时 再开前后台对接会 两会之后，再估时间 2.量化工作量的三大类 1.脑力劳动 S A B C 只是工作难度 C 无脑铺板子，交互也只是跳转 B 有一些交互，后台的数据简单处理，与后台数据发生简单交互等 A 有一些复杂的算法，但是网上能找到一些例子，比如电影选座位，处理一些后台的复杂数据 S 复杂算法，且网上找不到什么参考例子，如用原生JS编写个分层气泡图，拓扑图的企业祖谱，用到红黑树，四叉树遍历等，写个智能AI，AlphaGo 关心的点：做的这个功能的人，之前有没有做过类似的，有就可以认为时间和风险可控，没有就认为不可控，需要重点观注一下 2.体力劳动 直接灌数据，虽然是体力活，但要是数据多，细节多，肯定也要花不少时间，还要比格外细心 3.对接后台劳动 前后台人员的沟通成本，两人联调时，前台传参是否正确，后台数据过来是否正确，发现问题时的修改时间 3.估时间的尺子 1.C级：1小时，B级：4小时，A级：8小时，S级：看个人能力了，有可能就无穷个小时了 2.6条变化显示的数据，1小时 3. 一个接口，3小时 4.要批判的思想 我在网上看过，按人/天，来算项目时间的方法，这个算法最大的问题是忽视了每人具体人的工作能力差异 如：毛科做一个项目，他需要30个工作日做完，也就是30人天，但不能简单的认为，6个人一起做，就可以在5个工作日完成，要看这5个人的个人能力是不是和毛科一样强，还有人多后的沟通成本也要计算在内，所以肯定5天完不成 5.难点 1.不真正做时，没感觉，也不知道哪里会出现问题，俗称“馅” 2.技术经验不足，是新手，或是粗心大意，在写代码过程中一些不是问题的问题，也成了问题，一不留神自己写的代码就是坑，掉进坑里，没几个小时，爬不出来 3.在最开始，前后台，也交流不出来什么，都是摸着石头过河 三性、三期 三性 稳定性，流畅性，可配置性 三期 定型期 1.打包处理 2.配置的常量 3.从后台得数据，到把数据渲染到前台的套路流程，一般是用建父类的方法 （不是告诉大家，什么能做什么不能做，而是告诉大家只可以做什么） 4.大家共用的常用方法，如：日期格式转换，存取COOKIE等 5.后台接口返回值的结构，约定好一些事情，如：有个状态值，如果后台运行有错时，前台如何显示，在前台基类中统一处理 6.路由，模块的英文名字 7.所有的常量，如数据，文案，都应该在一个常量文件之中,避免在逻辑代码中，有文案直接出现 重在：定套路 扩张期 根据已经形成的套路，一个页面一个页面的去做 直到都做完，准备提测 重在：按套路狂写代码，遇到问题解决问题 冲刺期 1.bug 2.产品对需求的改变 3.濱习上线过程，模拟上线环境，遇到问题解决问题 重在：沟通每个人得到结论，修改代码 自己做项目时的感受 理想很丰满，现实很骨感 知易行难，落地困难 团队优势：每个人的主观能动性都很强 团队加强：整体流程，预做之事的事前沟通，同事之间的配合,尤其是跨部门做事之前的沟通 做项目时，最大的痛：警惕在项目中，做无用功 小痛：天天平地摔，还有晕头晕脑掉坑里，要好几个小时才能爬出来 提高工作效率就是句虚话，能落地的是把你手里的技术活，变为纯粹的体力活(干的活，都变为死套路时)，就方便量化工作量，并且可以对项目进行掌控了 团队一起开发，最好是一对一，或是一对一对一，都是一条一条的线，最忌，多对多的形式，又乱又容易出错，还要不停切换思维，导致效率很低 领导层的宏观注意力应该放在哪里，一是提升每个员工的战斗力，二是提升整个团队的凝聚力和战斗力，不断优化配比与流程 带团队 认识上 就是要让团队中每个人明白，自己在团队中所扮演的角色和肩负的责任。 这就好像，让两组团队，随意选取扑克牌中的一张牌，然后把所选的牌摆在桌子上。于是，出现了下面的结果： 第一组：方块A、黑桃2、黑桃5、红桃6、梅花Q…… 第二组：红桃A、红桃K、红桃Q、红桃J、红桃10…… 这两组的结果是完全不同的，第一组是一副杂牌，第二组却是一手红桃同花顺。为什么会这样呢?这是因为，第一组没有统一的目标，所以大家都按照各自不同的想法来选牌。是一种个人行为。个人行为加个人行为叫“乌合之众”。第二组有一个统一的目标，才形成清一色的同花顺，这就叫“组织行为。” 如果想要你的团队拿到一手同花顺，就一定要思路清晰，定出整体目标，并且明确共同利益所在。同时在这个目标下，让每个人知道自己所承担的责任和要达到的要求，并且给予一定的发挥空间，让个人能力共同达成组织目标。 工作上 上面所说的，是让成员知道自己在团队中的作用和要做什么，这里要说的是成员做事要做到什么样子，对具体做事的要求。要求只有一个，就是把交给自己做的事情做到位。看似简单，其实要达到做到位的标准，必须要有高度的责任心，还要有对事情非常认真负责的态度。 例如，我叫一个同事把机箱上面的一个螺丝拧紧，过会儿他告诉我已经做好了，我便拿着螺丝刀，到机箱前，把他说拧紧的螺丝又给拧紧了两扣，然后回过头来望着他，他也有些不好意思，说是以为拧紧了。像这种事情，可以延伸到工作中的方方面面，几乎别人告诉你，他已经把一件事情做好了，这个“好了”倒底是不是真的好了，你要是不自己去检查，而相信他的话，到后来很可能会出现问题。一个很明显的例子，就是游戏测试说测试好了，游戏没有问题，但是发布到线上却发现了很严重的BUG，给公司造成了损失。如果你不相信测试说的话，又派一批测试去测，那公司的成本会被加大。检查别人已经完成的工作，要付出的代价也是很大的，有些团队为了防止这种事情发生，在工作流程中，专门在每一步完成之后，加上了“验货”的环节。虽然这个流程有效防止了没有做到位而出错的可能性，但也把开发时间给拉长了。 在我心目中，一个能把别人交给他的事情百分之百做到位的人，就可以称的上是一个靠谱的人。要让做到位的想法，深入每一个团队成员的心中，并付诸实际行动。 精神上 就是一个团队的气势，也可以理解为大家的工作积极性是不是很高。我管这种积极做事的态度，叫做“斗心”。要让一个团队有斗心，第一步是为团队定下一个让团队完成起来，比较有难度的目标。之所以要定个难以达成的目标，是因为目标太容易达到，团队成员必然会放松，甚至不屑于去做，只有目标对他来说是个挑战时，才能激起斗心。第二步，是把大目标分解成诸多的小目标，每当完成小目标后，就及时鼓励团队，不断为团队补充斗心，如果不经常鼓励，大家的斗心会随着时间慢慢减退。斗心的来源除了鼓励，还有公司内外其他优秀团队的竞争，和团队人员自发的荣誉感。 团队中每个人也是需要及时去夸赞的，夸奖一个人，要夸他所做的具体事例，而不是浮夸其表面，不然别人也会认为你的夸赞很假。有些人认为，管理是应该胡萝卜加大棒的管理方式，一味的夸奖是不是不好呀？其实不然，夸奖别人，可以使他的劳动积极性大幅增加，而当你批评某人工作不佳时，对于大多数人只能使他的劳动积极性下降，更有甚者直接离开团队。所以还是要以赞美为主，如果真的看出此人的问题，也可以采用“三明治”的方式去说出，即先夸后提建议再夸，这样也使别人好接受。每个人都有缺点，而我们用人是用人的长处，不可以求全责备，要懂得“水至清则无鱼，人至察则无徒”的道理。我们要怀有一颗包容他人之心。 物质上 ... 少点儿鸡汤，多些实在的技术分享 百看不如一练，百练不如一上线
感觉用XMIND去做东西，条理性比DOC要清楚的多
但XMIND我在用时，觉得有两点不足：
1.没有 子项目“...” 这个设置
2.具体的文字框中的文字，不能单独变色强调出重点，只能框里文字都设置颜色
