透明是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。
透明程度是一个团队全面改善的前提条件。 在微小型公司，也许不存在透明性的问题。但在大型公司，透明性可能真是一个问题。大型公司有各种各样的KPI，报表，怎么会存在透明性的问题呢？ 我们说，你考核什么，就会得到什么。本质上，KPI有他的作用，同时也有他的负作用。我们暂且把它定义为透明的真实性。
回到研发场景，我们看看透明性的另一面。相信质量一直是产品侧诟病研发的一个核心点。而且这种指责一般都是居于主观的判断以及一两次重大事件。作为研发方，可能会行成一些改善计划，如加强测试用例评审及测试执行情况的通报。然而，你会发现这个过程是怎么做的呢，测试执行过程中发的测试报告邮件，是一个群发的，仅有几百条测试用例执行情况的列表。透明了吗？ 透明了。 有效吗? 基本无效。 因为压根就没人有空去观注你的细节。我把这种透明称之为伪透明。
做不到透明的原因是多种多样的，有团队成员忽略了表达形式造成的，也有出于自我保护的本能不想透明，也有觉得这个透明出来给对方没啥用，没必要透明出来的。
针对团队成员忽略了表达形式造成的，加以引导，也许习惯不是一两天就能养成的，作为顾问及支持转型的领导们，这个一般不会成为太大的问题。 形成一些标准，规范。得到领导的认可，推行一般不会受到太大阻碍。
针对自我保护不想透明的场景，我们要了解这个是一线人员不想透明，还是领导有所顾虑。如果是一线人员不想透明，需要了解潜在的原因，如技术任务潜藏着研发，可能是居于产品与研发的信任关系，发现潜在原因，协助解决。如果是领导有所顾虑，这个可能需要多思考原因了，公司中的潜文化不是容易突破的，高层领导中背后的事情也不容易知道。无论如何，作为顾问，收集可以收集到的数据，把数据呈报给直接关联方，征寻领导意见哪些数据呈现出来有所帮助。 这一类的透明性问题可能是转型的头号杀手。
当然，我们也说了觉得透明给对方没啥用，没必要透明出来，本质上，听说这种反馈的情况一般也属于第二类。
所以，要解决转型的难题，本质上是在推动透明化的一个过程。当大家愿意把透明化做好时，很多矛盾和抱怨也就迎刃而解了。我们在实践过程中发现，有很大一部分的冲突造成的原因是不透明造成的，加剧了互相的不信任和自我保护。 多观注透明性问题，从不同维度透明出来，推动敏捷转型，破除透明星的真实性和伪透明问题，并逐步建议相互的信任，才能达到真正的成功。你的组织透明吗？ 是什么阻碍了透明的发生？以上是一点见解。
网友评论