今日杂谈--工作的能见度和团队组织

 昨天，读了康斯坦丁人间集的一章---提高工作的能见度，他认为这是提高工作效率的方法之一。就此问题总结和提些自己的见解。
他在文中举出了三个实例，第一是自己的程序让别人去检查，第二个是whitesmiths公司的二重唱---结伴开发，第三个是，当你把自己的问题像别人倾诉的时候常常会有恍然大悟的感觉。
其 实这些例子，除了结伴开发，在现实不一而足。我个人的亲身体会极深，当我想我的同事，老板阐述这个问题的时候，我的思路也渐渐清晰，答案也离我越来越近。 虽然这些每个开发人员都有亲身的体会，但是为什么在我们的小组中却很少出现这样类似的结构化的组织呢？比如，结伴编程，共同学习，共同讨论软件的设计模型 和结构，分享成果和互相交流知识？

我不知道是什么原因导致了我们常常处于一个封闭开发状态，程序员每人做着每个人的事情，我不知道别人的主要工作在做什么，而别人也不知道我在做些什么，几乎每个人都是在忙碌的，而老板似乎需要的也仅仅是大家工作的忙碌状态，而效率是什么，他们也不闻不问。
这样的团队只有在出现问题，或者时间不够充分的情况下，才会要求别的成员的协助，可是她却并不知道怎么协助他们，事实上，他连他们在做什么，和具体的怎么做的都不知道，谈何协助？！
我 觉得的这样的团队，实际上并不存在团队的概念，只是一个hero+很多的顾问团员。而这些顾问团员只能帮你解决某些十分具体的问题，比如我们上面提到的 1,3种情况，而且他们也没有从你们的项目中取得任何有价值的经验和知识。而且，在你们真的需要大量投入帮助的时候，他们却只能干巴巴的站在那里，不知所 措?

为什么是这样子的？怎样才能解决这个问题？解决后他会给我们带来什么？
我想虚拟一下这样子的两个团队，A团队和B团队。我们模拟一个很现代 的嵌入式开发团队的人员结构模型。A:os and driver team,有四个成员，B:application team，有6个成员。A和B团队共同承担了两个项目甲和乙。现实中的结构是什么样子的？
甲项目有A团队中的两个成员和B团队中的三个成员开发， 而乙项目由剩下的人开发。这样A的成员不知道B的成员都在干嘛？而B的成员也不知道A的进度现在如何？他们实际上类似于两个独立的团队，而且很多时候， driver team的人，和application team的人，同样被隔阂开来，因为它们属于不同的组织，不同的领导，他们也同样认为我们的东西，application team 的成员不懂或者干脆不让他们知道。就我所知，很多的团队都是这样开发，而且还认为这是分工明确的标志。各负其责。而我们希望怎么样的解决这个问题呢？
就 如同康斯坦丁的结构化团队的方法，我希望的团队是这样子的。在开发过程之前和中间的时候，软件的设计和模型是由所有的开发者和工程师共同制定，当然这不是 说公司里的所有的程序员都得参加，至少项目中的成员或者外加一个相似的项目中的成员应该参与其中。而且可以类似于两个团队共同开发两个项目的管理方式。这 样至少这个软件的整体构架，开放框架，接口如何大家都比较清晰。为后续如果增加人力提供了方便之门。
工作会议必不可少，工作会议日什么的，比如说一个阶段性之后，大家有必要对软件的构架做些调整，项目的进度的调整。在我看来，软件开发一直都是一个不断修正的过程，以会议，由记录的方式沟是必不可少的。
培训和工作报告，正如我们提到的第三点，当你向别人阐述问题的时候你的思路不断清晰，所以这个培训或者工作报告，不断有利于交流，让大家知道你在做什么，更有利于presentator对自己知识的加固。
以 上的几点意见，在短期看起来都是很浪费时间的做法，譬如关于模型的讨论，工作会议，培训报告都是让很多工程深恶痛决的东西。但是这对公司的人才储备确实大 大裨益的。只有工作会议，配型，讨论才是培养需要人才的方法。我曾经很非常酷爱经济学的知识，我看到张五常说，他们那个时候经常会有宴会，而宴会就是一种 自由讨论的方式学习，所以他们这个圈子中的成员多数都是非常著名的经济学者。所以我们也需要头脑风暴，知识共享的，为什么不呢？如果你的团队中有人对知识 是如此的保密，那么你应该尽早得让他离开吧。