@flyouting
2015-06-02T17:31:07.000000Z
字数 3504
阅读 6310
未分类
1.参与技术沙龙及开发者沙龙，总结分享已有工作模式或技术方式的优势，学习其他团队的成功案例，拿来主义+微创新融合成到自己的技术方案里
2.关注新技术，新框架的变化，继续写博客，对于好的类库框架，延续使用-分析-改进的方式，整理相关wiki
3.增加与公司内部经验丰富的资深工程师的沟通交流，从他们那里获取一线经验，建立良好的沟通关系，多抛出问题，讨论问题，解决问题。
1.如果公司有类似常青藤之类的培训课程，希望能参加
2.正在研究scrum模型，在整理总结自己的理解后，尝试在团队内推行敏捷开发方式
1.团队内部，加强对不规范工作流程，不规范代码风格的管理控制，从自身开始，逐步减少团队内存在的有些懒散，缺少激情的工作方式，工作时间该认真的时候保持一个认真的心态对待工作，对超出这个范围的人或事，不再纵容，该黑脸时就黑脸
（个人认为就是个人威信的一个事，性格好不代表好说话，保持自己一个底线，超出底线绝不纵容，所要坚持的就是在那时那地，必须黑的下脸，维护团队工作方式的规矩，必须保证团队内部人员在自己可接受的一个范畴内工作，每个人的工作方式都可以自由把控）
2.团队内部，对于初级工程师，增强技术类影响，主动抛出一个技术类问题，与其一同分析解决，对于高级工程师，增强编程思想，方法论上的影响，及时跟进技术发展方向上的沟通。
（初级工程师，更多是想先学会如何把东西做出来，高级工程师，做出东西来不是问题，追求在与如何用一种最优的方式去解决问题，所以对初级工程师的影响，就是传授经验，如何以一种最快的方式去搞定业务需求，技术需求，对高级工程师，就是探讨经验，如何以一种最优的方式去解决问题，这个至少我有6年的项目经验，优化过的解决方案能提出一些来进行探讨，至于编程思想，方法论，这个都是从项目中提取出来的，如果注重思考和积累，每个人都应该有谈资）
3.团队外部，跟其他团队的沟通，脱离RD的身份特征，针对所有team共同做的事，共同的目的去思考问题，多提出自己的意见，多站在其他的角度看事情，多向其他团队反馈意见并接收其他团队反馈回来的意见。
（作为团队leader，对于团队间的协作，代表的是整个团队，需要稳住自己的形象，自己给别人的印象是强势，那团队的形象就是强势，自己给别人的印象是谨慎，那团队的形象就是谨慎，自己靠谱，别人就会认为我这个团队是靠谱的，所以团队间协作，讨论，都要保持一个底气，我身后有一个团队在支撑着我，对于需求，我们不仅仅是能做，而且我的团队是能做出彩的，一定要有这样的底气）
1.搭档式工作，对于工作一年以上的有足够经验或者熟练度的工程师采用此工作方式，一名高工+一名普通工程师组成搭档，两人一组负责独立的模块，要求两人对负责模块均熟悉，其一请假和离职，另一个可以暂时顶上。每组高工对研发工作负责，并参与每日晨会。
（高工本身就有职责带人，但是不一定要带新人，高工带中级工程师最合适，因为不用很费劲的解释一些基础概念，高工带中工，可能沟通上更有效率，中工带新人比较合适，因为是刚刚从新人成长起来一两年，相应经验都完全可以适用在新人身上，这种经验传授更直接有效。这种搭配，leader只需要管理几个高工就好，任务分配也分配到高工，然后高工带中工完成工作。这样避免我告知一个工程师某需求的解决方案，说了两遍他都不清楚的情况，因为作为leader，说的都是解决问题的思想，而不是具体的代码实现，高工跟工程师的交流，就会从具体实现上出发，去沟通实现细节）
2.针对高工，额外提出技术需求池，每个迭代周期，从技术需求池中挑选一到两个技术革新点（新技术实现或代码重构等）接入到项目中，保持项目的技术在不断的革新，并在此过程接触学习新的技术实现，在每个技术需求完成后，经办人需要整理wiki，分享至团队所有人。
（对高工，需要提起他们的激情，高工更多追求的是技术，leader需要有技术前瞻性，在技术需求池里提一些革新性的技术方案的试行，或者一些老方案的重构等等具有一定挑战性的需求进来，激发高工的研发热情，给他一个方向或者研究点去focus，这样高工才会不觉得在团队是虚度）
3.每周一次周会，会议内容包含本周工作内容，工作完成度，团队协作依赖关系的进展，本周遇到的问题，需要我去与其他团队沟通协助解决的问题。
（周会必须要开，所有人必须向leader汇报当前的工作进度，leader必须具体的询问需求完成情况，对滞后的人员需要提醒，并且对滞后的人员和需求进行评估，看当前工程师是否能在下一周追上进度，如果自己评估不能，需要安排人员补充跟进，或者自己跟进，降低项目delay的风险。团队内需要培养习惯，在周会的时候告知leader需要帮助沟通的地方，比如依赖其他团队的某个api的上线，需要跟进等等，leader需要统计下来，尽快解决，这是体现执行力的时候，解决不了一定会delay，delay就是执行力差的表现）
4.每日一次晨会，一般在10分钟内，各高工参与，主要内容，当前工作进度百分比，有无卡点，当天工作大致内容，是否需要leader解决一些配合问题等。
5.每周一次CodeReview，每次一到两人主讲，主要内容为自己在开发过程中某些具体业务需求的实现代码，此代码也许逻辑比较绕，也许实现方式比较先进，总之属于值得大家去注意，值得大家思考一下实现是否合理或者实现优点在哪里。每人分享代码量控制在百行内，时间控制在15分钟内。
1.每天最好一起吃饭
2.最好有共同的兴趣爱好，且常交流
3.每周最好一次AA聚餐
4.每月最好一次TB，内容最好别是吃饭，棋牌，桌游，台球，或者出去爬山之类的最好，去奥森野餐也比去馆子里吃效果好
1.工期评估，60%的工作时间用来接业务需求，另外40%的时间用来进行代码重构，技术革新，即实现技术需求池里的技术需求，用不断改进的实现方式或者技术方案，超出其他团队预期的完成业务需求。
（RD需要对性能和质量负责，不对需求的多少负责，所以我们需要时间来以我们的角度把需求做好，我们要从我们自己的角度规划一下时间，接10个需求，不如接6个且超出预期的完成）
2.每个版本内部总结一次团队配合的反馈，针对此迭代周期内出现的协作问题，从自身，对方两个角度提出意见及改进方式，由leader约各配合团队组织一次非正式吐槽会。抛出团队对此周期协作的意见且接收其他团队的意见。
（RD不光对性能和质量负责，如果团队人员都能对产品有看法，有想法，那团队爆发出的影响力是巨大的，leader需要收集团队内部对产品需求的想法，并反馈给PM团队，或者对协作流程的意见，反馈给合作的团队，我们需要通过leader向别的团队表示，我们是一个有想法，有态度的团队）
3.不接野需求！坚决杜绝某PM随意怕脑瓜想出的一个插单需求，并且不经过leader知晓，直接与具体RD沟通，商量实现事宜。需要在团队内明确作为有态度的研发团队，野需求是坚决不能加的，我们是遵守某些开发规范的严谨的研发团队，对于合理的插单需求，在抄送各组老大后，可以加入排期，但是随意的野需求，坚决挡回去。对于野需求，所有具体的RD都一句话：请先找我们leader沟通
1.需要跟团队人员保持沟通，以月为单位，定期有个沟通，了解下状态，问题，从leader角度看能帮助解决什么。解决不了需要马上找自己的leader沟通。每个季度需要有一次one to one的大的回顾，上一个季度定的目标完成没，自己有什么收获，有什么未完成，下一个季度组员的发展方向等等。
2.表扬与批评，需要通过各种方式表扬和鼓励团队成员，对成员完成工作优秀的给予相应的肯定，在团队内公开表扬。
3.公平的绩效考核
4.相互尊重，团队人员水平有高有低，需要培养每个工程师都有一个方向是精通的，引以为豪的，每个人都有有所依凭的技术力量，这样每个人都会有自信心，这样团队内都会相互尊重。
5.标杆，需要自身是一个标杆，或者团队内推出一个工作认真有热情的人做标杆，引导团队人员像其学习，模仿，竞争，超越。
6.讨论的氛围很重要，周会，CodeReview会议的目的就在此，每个人都可以抛出问题来讨论，每个人都需要有怀疑精神，讨论中，新的更优的方案才会成型
7.有一定的决策权也很重要，做有态度的RD，对某些设计，某些需求，某些流程，提出并坚持自己的意见，努力争取，leader就是负责收集，评估这些意见，并加以实施推行，让好的想法得以实，让团队每个人都能有自己的影响力，有自己的归属感。