(法)平衡出最优的team生产力组合

 (法)平衡出最优的team生产力组合

 --IT项目品质系统控制技巧

   谨以此文分享于曾经被不良项目管理风格扎针难耐，苦逼得“曾经拥有健康”程序猿兄弟们。
   最近辞职在家，无意之酝酿,多有开发感触，故想做道法术器四文《(道)良性成瘾开发习惯养成策略》《(法)平衡出最优的team生产力组合》《(术)产品、交互设计理念断想》《(器)构建自由通行的IOS开发者地图》，此为其一,法。
   这篇文章的题目“平衡出最优的team生产力组合”，说白了其实就是“项目管理”。如果要掌握一门“软性能力”的技能，像“项目管理”。由于其不具有良好的实践机会去操作then反馈学习。
   所以我建议的策略是战隼warfalcon的原话：“学习或研究一门新的知识时，最好的办法就是去学习这一领域名家的方法或系统，然后根据自己的情况进行调整，形成自己的系统，再不断实践并改进。”
   这句话涵盖了几个点，根据我的领会方式，我把它分成：
         step1==>主题阅读，针对项目管理类书籍；
         step2==>系统思考，概括项目管理名家的一些思想；
         step3==>粗略构建自己的系统=书籍抽要+实践领会；
         step4==>试验性碰撞出自己风格的系统；
  首先，针对step1。“主题阅读”是个精辟的词汇，它明确了几点，@阅读种类、@阅读目标、@时间控制。那就让我们在一段时间内GTD掉step1吧。下图是我个人进行的主题阅读方式，其中的阅读循环中我比较推崇有两个关键点，@带着疑问去索引到目标页数，@理解不清的东西别舍不得放弃。


   然后针对step2。“系统思考”同样也是个精辟的词汇，它也明确了几点，@思考的逻辑是一体的，@发掘出内在逻辑的联系和关系。惭愧，个人的积累程度还达不到系统思考地输出。下图是只是我的第一印象思考，也可抛砖引玉一起思考。


   继而针对step3。“粗略构建自己的系统”，简单的就是，粗略系统=书籍抽要+实践领会；经历前两个step，还有加上你的一些经验，你大致印象认为项目管理需要那几个要素。


  最后针对step4。“碰撞出自己的雏形系统”。而这套风格系统的目标就是本篇的题目--->“平衡出最优的team生产力组合”。实质上，项目管理这门科目建立的目标也是为了，平衡出最优的team生产力组合。
    而下面就是我个人马虎经历了以上几个step加上得到恩师simon和战隼文章多次启发后，弯弯曲曲碰撞出来的我的雏形项目管理风格框架。


    下面，我就简要点破每一项中个人颇有领悟之处：
一、leader对架构设计思想深刻把握；
     ==>首重MVC模式；
     ==>了然“OOP的6个设计原则，23个经典设计模式”；
  “跟对人，做对事”，这点是我一直以来很坚守的一个原则。对于项目中也同样是，如果项目leader很糟糕，而且你也尽力在你能够影响的范围内积极做出建议了，但是leader依然很糟糕。那么个人建议不管薪酬有多高，你的发展瓶颈是相当明显而且很难去突破的。那么再去找可以跟随的人吧。同时你也可以注重一下这方面的提升，他日也让人家来跟你又何乐不为。
  “MVC”是一个被说烂了N回的词。而或许留意其意义并且加以实践到项目中的人就不多。就像多数IOS开发者都有看过斯坦福IOS课程2011版，其中有一张介绍MVC的PPT,里面有一张“MVC示意图”，而留意到这张示意图并且弄清楚这张示意图表明内容的人或许不多。


  解析上面MVC这张图，可以抓住一个思路“两个圆圈的相互联系的管道（pipe）各是什么？各表示什么？”
  抓住C<-->V之间的pipe：V指向C有三条黄线，分别是action，delegate，datasource，可以理解为从“视图层V”输入一些事件，需要在“控制器C”进行响应；而C指向V有一条绿线outlet,可以理解为“控制器C”响应后通过outlet变量输出处理结果到“视图层V”上；
  抓住C<-->M之间的pipe：C到M有一条绿线，在这里绿线表示objc-c里面的[消息 传递]，可能是方法调用，或者属性调用；而M没有直接到C的pipe，这是为什么呢？再仔细观察原来M有一根天线，备注文字是“Notifacation&KVO”,只是说明M中的数据变动通过通知的机制以KVO（基于键值的观察者模式）来进行捕获。

    对于“OOP的6个设计原则，23个经典设计模式”，下面列图出来。至于吃透它的方法，大家估计各有千秋，理解记忆的几个核心个人认为还是几个关键词句，“艾宾浩斯记忆曲线”、“勤于基础动作练习”、“善于利用效率工具”（善假于物也）；





二、teamer对项目代码框架、设计模式了然把握：
     ==>对每个模块，需声明用到的设计模式或构建思路；
     ==>对每一模块，需同时生成有UML图；
  在良好leader的前提下，组员会得到明确清晰地任务分派，以及建议或者讨论后的模块设计方法。那么对于个体组员来而言他需要做三个步骤工作:
  草稿出模块的UML且声明构建思路==>编码操作出模块==>循环滚轮直到测试出稳定可用；



三、规则先行，约定大于技术：
     ==>项目进度表、进度日志;
     ==>界面规则风格明确文档;
     ==>代码风格文档;
     ==>代码编写结构会议；
  在项目管理里面，讲究的是team生产力，而不是个人英雄式生产力，所以有一等式：“约定规范”>“技术操作”。那我们就认可了“team规则”的重要性，那么团队的leader就必须生成制定出这相关的规范。
  这些文档估计每家公司都会有的，只不过需要反思是否具有易用性和高效性。这里着重“代码编写结构会议”，因为这个必须有。这个会议的过程“可以抹清很多噪音和雾气”。我所比喻的噪音和雾气其实是，team成员经常会有的一种迷糊感，他不明白为什么这么做，从而他有很多意见或建议。而这些噪音和雾气如果太重就很不利于项目的健康推进了。

四、项目开发日志：
     ==>事务、时间日志线（可用于为“IT工作2.0”建立保障机制）；
   个人反思了N回。才发掘出这个开发日志方式，这也是我的项目管理认识里面最核心的一种思想和工具。这个“事务、时间日志线”，良好操作的前提必须是team成员都有已经良好时间管理意识。然后每天以下面的日志线风格进行事务管理、时间管理。


  这个若是能够融入团队的文化基因。那么就太强大了，因为日志线追踪着项目中每一个微型的任务事务，同时确立了一条推进项目的高效轨道。我未来的假想是，若我成立一家公司，我将用这一机制来进行试验“IT工作2.0”是否可行。

五、短时长、高频率“微会议”；
    ==>严谨15min时间控制，善控制“讨论主题”、“讨论时间”、“讨论记录”；
    ==>leader需“善于击破”木桶长板组员的随意，也需“善于引导”木桶短板组员实现自我的突破；
  这也是一种高效率的机制建立。leader需要控制好节奏，目标是：
       1、把脉各处工作推进情况；
       2、同时疏通耦合环节；
  这样，确保独立模块能够按进度稳妥推进，也确保多模块耦合环节不新冒出问题，对未来造成不可控制影响。

六、MBA式对待team中“人”的问题；
     ==>对事可“有则升堂，无则退朝”，对人需“有事没事还得和他有事”；
     ==>沟通技巧和话术的方式；
  人性化，氛围宽松，几乎是每一家公司都挂在嘴边的。但并不是每家都理解到、做到。总结出这个点，其实也是得到前公司恩师simon的多次启示下，在此甚感谢simon。项目团队，虽然是四面八方凑在一块一起合伙挣口饭吃。不过大家都是人，与人做事就得把握个良好的交流印象，这就是对人需“有事没事还得和他有事”；
    而沟通技巧，下面我举几个例子，大伙可以举一反三：
  “我们一起考虑如何解决这个问题，明早上花五分钟交流一下，你看行吗？”；
  “你做的XX怎么样了？有什么地方需要我帮忙吗？……如果一切顺利可以在后天早上完成交给我吧。”；
  就是这种形式的沟通方式。如果需要更深层的把握估计就是MBA们该干的了。在此我也想到了一本书，也是在战隼warflcon那里发掘到的，叫《说话就是生产力》。这本书相当棒，我晚上发现的，第二天早上立马买了回来 。
七、项目高效展开的几个保证；
     ==>资料获取,公司书籍库（纸质or电子版）；
     ==>资料获取,公司模块库（封装好的.a文件）；
     ==>资料获取,公司通畅网络；
     ==>leader效率工具，项目协作平台的使用；
     ==>teamer效率工具，evernote做“事务时间日志”，
 mindnode做“逻辑分析辅助”，
“UML tool”做uml图；
  这点很关键。也是必须要基本保证的东西。说白了程序员也是个输入输出工具，你得给他输入资料他才能够输出代码解决方案。我最近就直接拒绝了一家给了我高薪诱惑，但是这点却没有保证好的公司，他们那里的程序员得到的“输入”相当有限，以致输出了一些让人匪夷所思的代码解决方案。以至于我极度怀疑这公司的实力，担心会不会月底拖欠我工资。

  以上七点就是我为了达到“平衡出最优的team生产力组合”，所进行思考出的“engels项目管理风格系统雏形”。在“大家”前就献丑了，只求分享此文于曾经被不良项目管理风格扎针难耐，苦逼得“曾经拥有健康”程序猿兄弟们。

转载于:https://www.cnblogs.com/limbo0312/archive/2012/05/05/2484806.html