###(法)平衡出最优的team生产力组合 IT项目品质系统控制技巧


以此文分享于曾经被不良项目管理风格扎针难耐,苦逼得“曾经拥有健康”程序猿兄弟们。 最近辞职在家,无意之酝酿,多有开发感触,故想做道法术器四文《(道)良性成瘾开发习惯养成策略》《(法)平衡出最优的team生产力组合》《(术)产品、交互设计理念断想》《(器)构建自由通行的IOS开发者地图》,此为其一,法。 这篇文章的题目“平衡出最优的team生产力组合”,说白了其实就是“项目管理”。如果要掌握一门“软性能力”的技能,像“项目管理”。由于其不具有良好的实践机会去操作then反馈学习。 所以我建议的策略是战隼warfalcon的原话:“学习或研究一门新的知识时,最好的办法就是去学习这一领域名家的方法或系统,然后根据自己的情况进行调整,形成自己的系统,再不断实践并改进。” 这句话涵盖了几个点,根据我的领会方式,我把它分成:

  1. step1==>主题阅读,针对项目管理类书籍;
  2. step2==>系统思考,概括项目管理名家的一些思想;
  3. step3==>粗略构建自己的系统:书籍抽要+实践领会;
  4. step4==>试验性&碰撞出自己风格的系统;

首先,针对step1。“主题阅读”是个精辟的词汇,它明确了几点,@阅读种类、@阅读目标、@时间控制。那就让我们在一段时间内GTD掉step1吧。下图是我个人进行的主题阅读方式,其中的阅读循环中我比较推崇有两个关键点,@带着疑问去索引到目标页数,@理解不清的东西别舍不得放弃。

1

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

2

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

3

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

4

下面,我就简要点破每一项中个人颇有领悟之处: ####1、leader对架构设计思想深刻把握;

  • ==>首重MVC模式;
  • ==>了然“OOP的6个设计原则,23个经典设计模式”;

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

5

解析上面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个经典设计模式”,下面列图出来。至于吃透它的方法,大家估计各有千秋,理解记忆的几个核心个人认为还是几个关键词句,“艾宾浩斯记忆曲线”、“勤于基础动作练习”、“善于利用效率工具”(善假于物也);

6

7

####2、teamer对项目代码框架、设计模式了然把握:

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

8

####3、规则先行,约定大于技术:

  • ==>项目进度表、进度日志;
  • ==>界面规则风格明确文档;
  • ==>代码风格文档;
  • ==>代码编写结构会议;

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

####4、项目开发日志:

  • ==>事务、时间日志线(可用于为“IT工作2.0”建立保障机制);

个人反思了N回。才发掘出这个开发日志方式,这也是我的项目管理认识里面最核心的一种思想和工具。这个“事务、时间日志线”,良好操作的前提必须是team成员都有已经良好时间管理意识。然后每天以下面的日志线风格进行事务管理、时间管理。

9

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

####5、短时长、高频率“微会议”;

  • ==>严谨15min时间控制,善控制“讨论主题”、“讨论时间”、“讨论记录”;
  • ==>leader需“善于击破”木桶长板组员的随意,也需“善于引导”木桶短板组员实现自我的突破;

这也是一种高效率的机制建立。leader需要控制好节奏,目标是: 1、把脉各处工作推进情况; 2、同时疏通耦合环节; 这样,确保独立模块能够按进度稳妥推进,也确保多模块耦合环节不新冒出问题,对未来造成不可控制影响。

####6、MBA式对待team中“人”的问题;

  • ==>对事可“有则升堂,无则退朝”,对人需“有事没事还得和他有事”;
  • ==>沟通技巧和话术的方式;

人性化,氛围宽松,几乎是每一家公司都挂在嘴边的。但并不是每家都理解到、做到。总结出这个点,其实也是得到前公司恩师simon的多次启示下,在此甚感谢simon。项目团队,虽然是四面八方凑在一块一起合伙挣口饭吃。不过大家都是人,与人做事就得把握个良好的交流印象,这就是对人需“有事没事还得和他有事”; 而沟通技巧,下面我举几个例子,大伙可以举一反三: “我们一起考虑如何解决这个问题,明早上花五分钟交流一下,你看行吗?”; “你做的XX怎么样了?有什么地方需要我帮忙吗?⋯⋯如果一切顺利可以在后天早上完成交给我吧。”; 就是这种形式的沟通方式。如果需要更深层的把握估计就是MBA们该干的了。在此我也想到了一本书,也是在战隼warflcon那里发掘到的,叫《说话就是生产力》。这本书相当棒,我晚上发现的,第二天早上立马买了回来 。

####7、项目高效展开的几个保证;

  • ==>资料获取,公司书籍库(纸质or电子版);
  • ==>资料获取,公司模块库(封装好的.a文件);
  • ==>资料获取,公司通畅网络;
  • ==>leader效率工具,项目协作平台的使用;
  • ==>teamer效率工具,evernote做“事务时间日志”, mindnode做“逻辑分析辅助”, “UML tool”做uml图;

这点很关键。也是必须要基本保证的东西。说白了程序员也是个输入输出工具,你得给他输入资料他才能够输出代码解决方案。我最近就直接拒绝了一家给了我高薪诱惑,但是这点却没有保证好的公司,他们那里的程序员得到的“输入”相当有限,以致输出了一些让人匪夷所思的代码解决方案。以至于我极度怀疑这公司的实力,担心会不会月底拖欠我工资。

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

一图一体系update...

一图一架构,一图一知识体系。 Continue reading

website【2045区块链导航】
Published on March 19, 2018
DevOps在CI/CD上的工具链
Published on December 01, 2017