挨踢项目求生法则（1）——团队建设篇

 

摘要：

 

知道什么是挨踢项目吧？ 什么！ 不知道？ 那IT项目知道了吧？ 为了避免让客户踢、不让老板踢、项目组成员之间不互相踢，俺为你们分享一些减小被踢机会的心得体会。 就算不能让项目成功，也至少不会死得那么惨吧！

 

我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。

 

 

什么叫挨踢项目？

 

IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。 挨踢项目的几大特色： 1.需求不肯定。 2.技术不肯定。 3.工期限死。 4.预算限死 两大不肯定和两大限死，你想不“挨踢”都难！

 

 

由“踢皮球”事件想到的

 

事件回放：

 

某项目部署给客户后，重现了一些之前已经解决的问题，而这些问题测试时并无出现。 经检查，发现测试的版本不是部署的版本，不知道为何老版本部署给客户了。

 

领导要追究责任，因而你们各有说法：

• 开发人员说：我是按要求打标签的，没有问题。

• 测试人员说：我是在提交区中取版原本测试的，我没有出错。

• 实施人员说：我是按照开发给个人版本去部署的，我没有过失。

• 最后终于有人说：是以前已经离职的某某弄错版本号致使的。

 

该事件暴露了不少问题，但我想说的是团队建设的问题，没有任何一我的首先从本身身上找缘由，第一反应就是推卸责任！

 

唐僧四师徒西天取经，若是每一个人都是这样，不是本身内斗死，就是被妖怪吃掉！ 优秀的团队能“自动”解决不少问题，如何才能打造良好的团队文化呢？

 

 

良好团队文化的源泉是什么？

 

良好团队文化的根本其实就是老板的管理思想了，不一样的管理思想，老板会设计不一样的部门规划和考核办法。

 

有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分红两类人，设成两个部门。 一个部门叫设计部门，负责需求和设计； 一个部门叫实施部门，负责编码、测试、实施。 设计部门经过一个任务管理系统向实施部门下单，实施部门根据这些工单来工做。

 

该老板还设计了自觉得很牛的考核办法，若是实施部门不能按时按质完成工单，则会影响考核； 若是设计部门的工单被实施部门退回，则会影响设计部门的考核。

 

因而两个部门之间的扯皮时间每天发生，之前完成一个工做很简单的，如今要扯来扯去。 设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工做，或者是认为这些文档说得不够具体，要退单。 当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！

 

还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，一样只不过是杯具的另外一种形式而已。

 

软件研发活动是人类复杂的高级智力活动，是须要team work的活动。 若是明白这个道理，若是懂软件开发，就不会设计出这些傻瓜的管理措施，将软件研发团队的每一个人变成机械人、卸责人。 研发团队中的每个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家！

 

 

做为Team Leader应该怎样作？

 

Boss的想法咱们没法控制，虽然没法从根本上改变公司的部门设计和考核制度，但做为Team Leader来讲，在能力范围内仍是能够作不少事情的。

 

Team Leader应尊重每一位Team Member，平等地对待他们，充分发挥他们的潜力，给予足够的支持和成长空间等。 对你们好，你们是知道的，未来会给你带来更大的回报。

 

下面一些法则供你参考。

 

 

法则1：一荣俱荣，一损俱损

 

项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在本身专业领域内发挥主导做用，并能够为项目的成功提出非本身领域内的建议。 最终的项目成果是各位专业人士共同努力的结果，全部人对最终成功承担同等的责任。

 

若是系统部署后，系统出现了一个严重缺陷，请问谁应该负责？  

1. 项目经理？测试？开发？……

2. 都不是，而是项目组全体都要负责！

3. 软件中某个功能作得很炫很好用，请问谁应该受到表扬？

 

项目奖励发下来了，请问谁能够分到这份奖励？

 

以上问题相信你应该有答案了！

 

项目组全体是共同承担连带责任的，要死一块儿输死，要活一块儿活。 若是项目组中有人受罚，有人会获得好处，这个Team是很难团结和有战斗力的。

 

 

法则2：让 Team Member 当家做主

 

项目组中不免有部分红员是新手，经验和水平不足，某些工做可能一时不能胜任。 而咱们每每迫于项目进度压力，某些任务就会直接安排给他作，不让他提出本身的想法和看法。

 

而咱们这些接受了中国式教育的人，很多人喜欢以“接受任务”的方式来工做，而不是主动迎接挑战。 因而有时候你可能遇到一些成员会跟你说“今天工做已经完成！ ”“我按照任务要求来作的，我没有错！ ”之类的活活会气死你的说话。

 

不要剥夺项目成员当家作主的机会，应相信每位成员在他的专业领域内都是专家，在他的专业范围内，他能够说了算！ 只要知足项目的大框架，只要出发点是为了项目成功，那么这段代码应该怎样写、这个功能点应该如何测试等之类的决定，彻底能够交给Team Member来作主！

 

项目成员可能一时没有魄力独立作决定，可能担忧犯错误，不要紧，要多多鼓励他！ 犯错不可怕，由于还有“法则3： 鼓励犯错！ ”

 

 

法则3：鼓励犯错！

 

少作少错，不作不错。 若是犯错误会受到惩罚的话，那么前面八个字就会应验！

 

犯错几种状况：  

1. 常常挑战高难度工做，犯错是不免的。

2. 作一些以前没有经验的工做，犯错也是不免的。

3. 犯一些低级错误。

4. 犯一些以前曾经犯过的彻底能够避免的错误。

 

对于状况一、2，绝对是须要鼓励的！ 对于状况三、4，要帮助他避免这类的错误。

 

软件研发工做大部分是高难度和复杂的，加上进度压力大，犯错是不可避免的，如何在总结中前进。 一个在工做中历来不犯错的人，他不是神，他应该是那种“少作少错，不作不错”的人，或者是专挑低难度工做的人，你喜欢这样的人？

 

 

法则4：言传身教

 

曾经见到这样的一些领导，当下属有问题求助时，他会板起脸孔，摆出领导的样子，而后说： 你本身不会解决问题吗？ 你应该本身列出解决方案后才来找我！

 

我赞同领导不该该帮下属解决全部问题，有些问题应该由下属本身搞定，但下属是不可能搞定全部问题的，有些问题超出能力范围和职责范围，做为领导就应该出手。

 

做为Team Leader，应着重帮助Member养成良好的工做习惯和工做方法。 中国式教育培养出来的学生，可能会喜欢直接获得答案，而不求工做方法。 这个中国式教育的错，就只能由咱们来补了。

 

 

法则5：挡住骚扰团队的外来干扰

 

Team Leader应当住来组团队外部的干扰，让团队能够专心工做。 挡住麻烦是Leader的职责之一，而不要由于嫌麻烦，而让你的Member去处理这些麻烦。

 

 

法则6：全力维护团队利益

 

某部门的员工的薪金近年来不多获得提高，缘由是该部门经理对外是好好先生，每一年都不会主动积极为部门争取加薪的预算，老是被别的部门抢去预算。 某项目出了问题，老板找来项目经理，说要找人负责任，不然很差向客户交代。

 

如下三个选择你会选哪一个？

1. 该问题确实主要是由于某Member致使的，全部他来负责是应该的。

2. 这是团队的责任，要全体负责。

3. 尽管是主要由于某人出错致使的，但做为PM的我应该负主要责任。

 

做为一个Team Leader，不管任何状况下都不该该“出卖”本身的Member，应该本身一力承担！ 回头你能够关起门来，批评这位犯错的Member。

 

 

法则7：咱们是一我的

 

法则7是最重要的，其实只要能作到“咱们是一我的”，其余法则天然就作到了。 你不会和本身的左手做对的，右脚不会和左手打架，你的身体哪一部分受伤，你都会以为疼，一我的的手脚动做是很容易协调的。

 

若是咱们团队能凝聚在一块儿，达到“咱们是一我的”的效果，那么咱们将望风披靡！ ◈◈◈精选好文◈◈◈

 

• 为何阿谀奉承之辈能在公司横行这么久？

• 老板对你说公司要裁人，你该怎么办？

• 技术总监到底要不要写代码？

• 漫画 |《程序员十二时辰》内容过于真实 ...

• 为何我有那么多时间写公众号？