Object-C还是Swift？
现状
采用Object-C的偏多，成熟的技术，人员充沛，已经有成熟的产品。
想法
Swift是趋势，迟早要切换，迟不如早
困难
- 换语言是技术的事，很难得到产品的支持
- 业务不能停，人手不够，根本来不及
- 现有版本已经是Object-C的，多年发展已经很庞大，能换吗？
对策
- 技术和产品不是甲方乙方的服务关系，而是共生共荣的合作关系
- 除了产品的功能需求外，还有技术本身的重构、优化、甚至重写需求
- Swift的人才可以自己培养，开源社区很多，资料也很全
- 业务在原版本上继续发展
- 内部版本，专注于语言切换，架构改造，不用太在乎业务
- 双版本发展，等时机成熟了，自然就可以切换了
- 分两个子团队，分别应对两个版本，人员可以根据兴趣，自由流动
- 一些好的想法，如果不适合在正式版本上搞，可以在内部版本上先试
- 正式版上APPStore，内部版本用企业版账号开发
招聘：态度还是能力？
现状
招聘时看能力，进来之后更重视态度
想法
招聘时更应该看重态度，价值观，是否能融入团队。进来之后，应该更看重能力和价值贡献。只招聘价值观一致的人，一起玩得开心最重要，不符合团队氛围的人，逐步清退。
建议
让团队成员参与面试，选大家都感觉好，合得来的小伙伴
绩效：是奖还是惩；评价个人还是评价团队
现状
绩效评价的时候是最不爽的时候，不论是主管还是团队成员；不论是表现好的还是表现一般的。有好就有差，垫底的基本上要准备找工作了。一方面招人困难，花费很高；一方面又在往外踢人。
考核的重点是个人，哪些人表现好，哪些人表现一般，强调个人能力。
想法
人的贡献有大有小，人也有优秀和普通。贡献小的，普通的，往往都是团队不可或缺的。个人的业绩再突出，也替代不了团队的作用。考核的重点是团队的贡献，而不是个人能力的区分。考核气氛应该是快乐的，不应该压抑。
建议
- 考核团队，不考核个人；
- 取消排名，尊重普通的，平凡的员工贡献
- 评选优秀并奖励，名额有限（中奖的光荣，不得将没关系，像年会抽奖一样，大家都喜欢）
H5、APP后台人员属于哪个团队？
现状
- H5人员属于PC的前端开发团队
- APP后台开发，一般用Java，属于后台开发团队
想法
- H5页面目前的比例比较大，H5与Native交互已经是个比较重要的问题领域，H5人员放APP开发团队比较合适
- APP后台其实是介于客户端与真正后台之间的一个“网关层”，需要了解业务，熟悉后台各模块，但不需要实现具体的后台模块，所以也应该放APP开发团队
电脑配Windows还是MAC？
现状
- iOS开发配mac，这个要感谢苹果，生态系统控制得比较好
- Android，H5，APP后台都用Windows电脑开发，降成本
想法
- iOS、Android，H5，APP后台等整个APP团队都用MAC
- 用15寸 MacBook Pro，高配的，让开发者有自豪感
- 今后往全端，甚至全栈的方向发展，团队内部人员相互流动，相互补位
- 人比设备贵，所以采购高端设备让开发者满意是理性的选择，靠省，干不成事
部门结构还是扁平结构？
现状
- 每个部门都有1到2个iOS开发
- 或者大部门扁平结构，1个iOS架构师管10多个iOS开发
想法
- 资源池+小团队模式+“特战小组”
- 资源池是大团队，仍然由1个iOS架构师负责
- 小团队管理，每个团队不超过5人
- 业务导向，开发时加入业务组（“特战小组”），进行团队合作开发，资源池提供支持
- 隔一定时间，需要回资源团队，进行技术交流，团队建设
- 代码质量要纳入资源池统一管控，类似于人员外派出差
- 面向业务组建“特战小组”，完成具体的“战斗任务”
- “特战小组”成员不能超过10人；任务太大，就拆分，成立新的“特战小组”来应对。
- 时间点一到，就验收“战斗成果”，只验收符合条件的“成果”，没完成的任务，放下一个阶段，或者转给其他“特战小组”。
- 按“战斗成果”评价各“特战小组”，团队贡献优先于个人。
- “战斗英雄”先由个“特战小组”自己评选，然后上报，然后在一个大团队内，统一评选。采用民主选举的方式，给“风采展示”时间，选出大家心目中“众望所归”的“战斗英雄”。
- 对于优秀“特战小组”，先进“战斗英雄”的表彰方式，事先说明，全员动员。既要有“荣誉”，有“自我实现”的成就感，也要有足够吸引力的物质奖励。我们呼唤“雷锋”，同时也不能让“雷锋”吃亏。
- 中级以上管理者不能参加“战斗英雄”评选，对他们来说，“团队的表现”才是衡量工作的标准。“只有兵王，没有领导的个人英雄主义”。
瀑布模式还是敏捷开发？
现状
- 小团队敏捷开发，周期2周
- 大公司瀑布模式，周期3~6个月
想法
- 以APP后台为界，分两段，分开运行
- APP开发靠近业务，先行开发
- 后台服务没跟上，先在APP后台mock数据，内部试用
- APP团队采用敏捷开发
- 开发周期为4周，两周开发，1周测试，1周上线
- APP团队按数据层，逻辑层、界面层分组，每组不超过5人
- 界面层与产品团队混编，按照业务功能分组，每组不超过10人
- 以团队为单位，不考察个人
- 推荐三分之二时间讨论，三分之一时间编码的工作模式
- 推荐结对编程的模式；淡化个人因素的影响
代码Review，学习，分享能落地吗？
现状
- 都知道代码Review能提高代码质量，但是落地的很少
- 都知道要学习，但是能落地，能分享的人很少
想法
- 代码Review，学习，分享提到和工作同等重要的地位
- 代码Review，学习分享，完成业务工作都量化为无差别的团队贡献
- 集中进行代码Review，控制代码上传权限，全员（至少5人）Review
- 学习强调分享，强调创新demo，提倡开源，强调输出成果
- 时间上可以考虑利用周一、二、四晚上6~8点这段时间；平时努力，争取周末休息
沟通是浪费时间吗？
现状
- 周例会；成员汇报进度，PM或者Leader分配任务
- 平时沟通很少，问到的时候，常见回答：“这个没人跟我说，我不知道啊”
- 认为沟通是浪费时间，开会无聊，但是结果是一直相互等待，进度缓慢
想法
- 每日站立会议；沟通不是太多了，而是太少了；沟通不是浪费时间，而是提高工作会议。
- 取消周例会，一个人讲，其他人坐着打瞌睡的“形式会议”才是真正的浪费时间
- 每天固定时间开站立会议，比如早上10点，不能参加的要向全体成员请假，协调不好的用“红包”解决意见冲突
- 开每日站立会议时，每个人都必须站着，不能坐
- 开每日站立会议的人员不能超过10人，人多了就要分组
- 每个人都要说，无话可说者，“红包”解决；说话顺序可以通过各种方式，比如随机、摇号、指定等各种趣味的方式
- 每个人只说三件事：昨天做了什么？今天准备做什么？是否需要协助？不要涉及细节，每人发言不能超过3分钟。想多说的，话多超时的，“红包”解决；
- 总结会议：1个月1次，完成一次版本迭代之后，总结经验教训，修改团队规则，评选优秀成员，交流实际中的“踩坑、填坑”经验等。完善共同的制度，彰显“自我实现”的成就感。
- 以具体业务为目标分“特战小组”，成员坐在一块，成立“作战室”。“先吵架，再编码”，有疑问，“特战队员”之间直接解决。
- 文档和编码同时进行，两者同等重要。两件事可以由不同的“特战队员”同步进行。有分歧？当场“吵架”解决。（交互改原型，UI改切图，开发改代码，测试改用例，架构改设计，产品改用户故事）（这些事在“特战行动”开始前的准备阶段有先后，但是在“行动过程中”就没有先后之说了，随时“吵架”，随时改。中间过程都是“波浪”，会被忽略，最终只看“战斗成果”）（代码和需求不符，整个“特战小组”失败，产品个人再会“忽悠”也没用，一起承担“战败后果”）。不同的“特战队员”只是做的事情不一样，最终只有一个目标，让任务落地，让“文艺青年”也能直观感受到“特战小组”的“战斗成果”。
- “聊得开心”，“吵得热烈”，才能“玩得开心”，“特战小组”才有可能给出令人惊喜的“战斗成果”
- 沟通是第一战斗力，是提高效率的有效途径。沟通是太少了，不是太多了。
需要加班吗？
现状
- 996加班，持续时间越来越长
- 版本发布之前，997都有可能
- 平时有时候没事做，心里不踏实
- 朝九晚五
- 上下班要打卡
想法
- 不打卡
- 上班时间8~10点，10点开每日站立会议
- 中午12点吃饭，前后灵活15分钟。中午要午睡，下午1点半到2点开始工作。
- 下午4点左右吃下午茶，半小时左右
- 下午6~7点，有事可下班，一般可以作为晚餐时间
- 下午7~8点，代码review或者团队学习分享。这个很关键，这是每天进步一点点，持续坚持下去，团队将变得优秀。
- 晚上8~10点，有进取心的同学可以在公司多学一点。公司才是工作学习的好地方
- 晚上10点，建议回家，保存好体力，保证第二天更好的工作状态
- 周三、周五可以早一点下班，5~6点样子，调节一下，过个好周末。
