中大型软件开发，免不了团队开发，团队开发就少不了分工合作。在团队开发中，当然每个人的能力都很重要，但是我认为可信赖的工作是团队开发的首要条件，也是团队开发存在的基本保证。没有可信赖的工作，就没有团队分工合作，即便有团队存在，也会变成一只内耗极高的团队，管理协调的代价超过团队的优势，团队的价值就会被堙没，便没有存在的价值了。

软件开发中可信赖的工作，是指：团队开发中，向小组或者个人分配的一个模块、一项任务应该开始前应该有可信赖的评估和分工，在开始时候被可信赖的计划，在执行中可信赖的反馈，执行过程中完成时间应该被可信赖，执行结束后要有可信赖的质量和可信赖的测试与后继补充性开发和修正工作。相反的为软件开发中的不可信赖工作或者不可信赖因素。

大多数新团队的开发工作中的组员的工作是不可信赖的，举个简单的离子，架构师或者主程序员分工好以后，交给一个小组一个模块，或者交给一个人一个模块。虽然有过反复的叮嘱，应该仔细，应该做好细节。但是每次员工递交上来的模块后，经过测试，会发现很多的问题，根本不可信赖。有时候一个模块交给团队组员去开发，用了三天时间，为了修正他们的错误，不得不把所有的代码去看一遍，最后修正工作似乎也用了三天时间，而这些问题中的绝大多数问题为不小心或者不细致导致的问题，这些问题中的绝大多数问题会反复出现在后继工作中，即便你重申过多次。当你把某项工作交给某个人的时候，你不敢相信他可以按质按时的完成，等他完成后递交，你不能确认他的工作真的完成了，或者只是为了应付差事，他自己认为完成了。以至于大家都认为完成的东西，到最后才发现原来根本没有完成，让团队无法托付工作给组员。让客户无法托付产品给公司。这样的问题非常严重，轻则耽误工期，延误时机，增加开发成本和团队管理内耗，重则可能影响到产品成败，甚至公司的前途，所以不得不把可信赖工作放到所有的管理的首位。

根据以前项目开发的经验，我做了以下整理，反应到真实的软件开发中大概如下：

首先、任务开始前，管理者应该对问题的描述、任务的规模、要求、开发完成后的质量和约束有着清晰而深刻的立即。同时对团队组员的技术水平、时间安排、工作效率和态度有着清晰的认识，知道谁可以胜任，谁不能胜任。应该如何去分配工作，大概需要用时多少，会出现什么状况有着清晰的认知。这个是可信赖工作的前提。

其次、任务分配后，组员开始开发前，应该确保和管理者进行过有效的沟通，双方对任务的理解一致而且无歧义。然后组员应该对任务作出基本的计划和规划，列出任务要点以及分工的先后次序，同时对任务作出自我评估，判断是否可以胜任，同时估计该项任务完成的时间和工作量。并且应该以正式报表的形式进行递交。团队虽小，个人认为这个报表少不了，不必太过担心在这样的报表中花费的时间和成本，切记磨刀不误砍柴工。

然后、任何开始执行以后，要有一个定时的回报，方便管理者知道的进度。回报的内容应该包括：当前已经完成的工作，剩余的工作以及计划的调整。以及开发中遇到的难点和遗漏点。回报不是为了赶进度，而是为了准确的了解信息，在回报中，管理者不可过分干预工作进度，但求做到心中有数即可。同时任何团队的组员应该明白：可信赖的工作不仅仅是在时间上可信赖，而且更应该是在质量上可信赖。质量上的要求要远远高于时间上的可信赖。

再次 、任务执行完成以后，必须有一个报表：这个报表要求明确的写明开发者是谁，测试者是谁。同时要签入源代码，因为团队水平不可能完全一致，允许有无法完成的任务点，但是报表必须写明什么没有完成，原因是什么。允许完不成的任务，但是完成的任务一定是可信赖的。即功能上没任何遗漏、质量上没任何技术缺陷或者粗心带来的遗漏性缺陷。同时时间上没明显的逾期。

最后、对签入的代码加入框架进行测试，然后对任务应该有一个基本的评估，根据开发前的报表和开发后的报表，以及软件模块的实际质量做一个评估，要求评估客观有威信。然后做出赏罚。

以上即为可信赖工作的几个要点，看上去简单可行，但实际操作中却很难执行。根据个人带领团队的经验，做出以下几点措施。
第一、让团队每一个人都能明白：一个人能力可以有大小，技术可以有差异，但是服从性和细致性的工作方面的要求没有区别，不管是技术大牛还是实习小菜，交给的任务，完不成可以提出来超出自己的能力范围，但是一旦去做，就要做好！保证每个细节都不会出现问题，经得起测试和推敲。每个测试人员都应该明白可信赖的重要性，切实把握好关。同时对于任何一次没有经过严格测试而遗留下来的Bug进行评估，如果因为非不可预见因素导致的，要进行惩罚。对于无法胜任可信赖工作的人，建议直接清理。培养可信赖的工作意识，是以第一要务。

第二、分配工作的时候留足余地，考虑到非可信赖发生后的补救工作，同时根据工作的难度和生疏程度，应该乘以一个时间系数，一般工作可以乘以1.2，自己陌生的团队和陌生的工作，应该乘以 3。同时每次根据以往的工作，对每个组员做一个系数评估。方便以后工作分配。

第三、明确工作内容、范围和质量的约束，在分工前让组员明白自己要完成的任务要求，包括功能要求和非功能要求，特别应该了解非功能部分的质量约束，比如鲁棒性要求、扩展性和健壮性的要求。同时鼓励组员提升质量标准和细节标准，确定明确的奖罚制度。
第四、不要把一项工作和任务安排周期太长，每三天到五天应该有一次小规模的验收行动，确保每个组员的短期可信赖的工作，因为非可信赖因素会慢慢出现和积累，如果安排一个较长期的工作，往往到最后容易失去控制。短期非可信赖容易控制和踢出不良因素。
第四、做好奖罚制度，一个团队中，不可信赖的工作应该是惩罚较重的惩罚点。同时每个小组要指定可信赖度监督和检测员，保证不良因素在底层解决，而非到上层以后再去解决。任何一个小的Bug在程序设计环节想到如何处理，成本最低，后而进入程序开发环节，最后进入测试环节，到签入质量检测环节，递交客户，到售后环节，每增一个环节，增加一份成本。

第五、开发未动，测试先行，我们尝试过按照接口去分配类库，最后把类库组合在一起的做法，发现：很多人在无法测试的情况下，去做开发，然后拼装在一起后去测试，无法发现一些问题，而且这样过分依赖开发人员的经验和技术，非常不同。同时问题递交到软件上去测试，容易掩盖问题。并且增加问题解决的复杂度。

第六、建立良好的信赖跟踪体系，要建立良好的质量跟踪体系，就必须明确每个环节的每个开发人员、测试人员，以及任何形式的决策和贡献者。对出现问题的原因和人员做记录和跟踪，质量体系不仅仅要跟踪 软件开发中遇到的bug，还要跟踪进度、时间、工作量、质量等等。这样可以方便后期把一些常见的问题规范化和文字化，同时还有助于分工的时候对每个员工的把握以及后期的选拔等等。