该如何管理和面对一个为技术论的总经理

0 0

该如何管理和面对一个为技术论的总经理10

   各位，我最近进入一家刚开业的软件公司，公司主要采用ROR建立的一个基本平台进行企业级开发，团队大概有4个人，我，2个大学生A，B（刚接触软件开发），一个有2年开发经验的程序员Q（主要做桌面应用，没有接触过web开发），前阶段3个人一直在进行ruby和html的培训，8月底有项目开始进行前期接触，我也开始进行一些团队的工作，比如建立文档，规范，团队建设方面的工作。大家刚开始都比较抵触，不过我通过几次会议也算有点小成效。并进行了web开发基本基础方面的讲解，使团队里的人基本了解了一些web开发的基本方式方法。但是对软件开发的方法和软件管理方面都没有做过多的灌输。基本都是放任自流。今天我召开了一个头脑风暴会议，主要是希望能给大家讲解一下敏捷开发和软件开发中需要注意的一些问题。
    但是在开会过程中，因为Q和A一直在在会议上说这些方法并没有什么需要了解的，但我的级别和Q是一级的，所以我就讲总经理C请到现场，希望能借他给我支持，让大家去学习和了解这些方法。
     但是让我没有想到的是，会议刚进行一会，总经理C就对我召开这样的会议提出意见，他表示，在软件开发中，最重要的就是技术，除了技术以外，其他的都是没有什么用的，只能在后期做一下就可以。这里需要插一下介绍总经理C，他不是做软件出身，原来在一家商贸公司做技术总监，但是对软件开发技术并不了解，但是本身代码能力还是很强，并十分熟悉我们的产品平台。
     之后全部的成员都开始表示了赞同总经理C的意见，大家开始热烈的讨论起来技术问题，我打断了他们，然后开始提出一些软件管理的意见，没想到总经理C开始了他的讲演，他说，在我眼里，我最希望的就是每一个人都能将我们全部的技术都学会，并能在短时间内完成这样工作，我们的目标就是，在今年底，这里坐的每一个人都需要独立完成一个项目，还举出他的列子，我原来再一次客户工作中，只用了5个小时就完成了一个dome和方案，客户表示非常满意。我提出每一个人的情况不同，不能简单的就要求每一个人都能独立完成一个项目。因为项目中出现的问题太多，会代码的人不一定会沟通（Q是代码能力不错，但沟通不行的人。），会需求和分析的人不一定能完成一段代码编写。我们不能简单粗暴，但是总经理C表示，这样的人不是公司所需要的，这代表他不能完成公司的任务，只能请他离职。总归一句话，如果是比较小（2-3个月左右）的项目，就需要一个人单独完成。这就是考核大家的标准。因为他并没有带过团队，也没有真正做过项目，我一时之间不知道该怎么去说服他了。之后团队的每一个人都开始表示自己能完成这项任务，一个项目从需求、分析、编码、测试、实施，一体化搞定。总经理还建立了自己的团队目标：
每个人都独立实施完成一个项目。
     目标建立后，我就问怎么样进行计划建立，怎么样实施考核，总经理表示，现阶段这个都是靠个人，以后有项目了就好了，现阶段每一个人自己建立工作计划，自己考核自己。
      我不想讨论总经理C这样的方式对还是错，但是项目还是要进行下去，公司还是要进行运作，所以想问一下大家，该怎么样在这样的领导和团队中做工作？怎么样让他们能认识到软件开发不单单是一个编码的过程？

项目管理敏捷编程

2014年9月10日 19:58

yctemp
22
0 0 3

5个答案按时间排序按投票排序

0 0

采纳的答案

C的话有其合理之处：
1、刚创立的公司，快刀斩乱麻或者说简单粗暴有时候也是生存的需要，有一点“革命不能那样雅致，那样从容不迫文质彬彬”的意思。
2、刚开始做不了大项目，简单的小项目不需要太多沟通，一个人就能掌握项目的方方面面，以个人为单位做项目是比较合适的，管理上较为简单。
3、对于小项目，可能你从方法学的角度一看惨不忍睹，但客户只要求有问题能找到人及时解决就行了，很多时候他不要求你有完善的开发流程。

C当然也有其不合理之处：
1、忽略了楼主的积极性主动性，不仅未加以激励，还进行了打击。
2、过份简单粗暴，按楼主描述来看有点不上档次，过于片面。
3、忽略了人与人之间的技能差异，试图以自己的水平为标准来要求员工。

对楼主的建议：
1、除非你与其他同事有非常大的技术水平上的差距，否则建立起权威的过程会很长。楼主可能认为自己在web开发方面相对于其他同事是权威，但很显然其他同事并不认可。
2、没有建立起权威的情况下，要进行软件工程方面的偏务虚的工作会很困难。
3、应该先和C取得观念上的一致再请他过来，否则还不如不请。楼主主观假定C一定会支持自己的想法，直接请C过来，结果把会议搞砸了。
4、在目前的情况下楼主已经很难协调团队成员了，同事和C的思想观念很难改变，楼主应该换家公司。

2014年9月11日 15:32

wyuch
68
0 0 4

4条评论

0 0

新公司最重要的是生存，这个时候最需要的是全能型的骨干员工，讲究迅速交付，客户满意就是最大的满意。至于团队建设、产品内在品质之类的东西相对来讲都不是太重要。

我身边就有一个类似的团队，整个团队完全是围绕着三个骨干员工来开展的，软件项目管理完全为项目让步，为骨干员工开路。所谓的梯队建设很残酷，用一个月的时候来考察新员工，跟得上就继续用，跟不上就迅速淘汰。

不过这类公司在渡过生存初期以后就会有很大的麻烦了，甚至会超过刚开始的时候。项目做得越多负担就越重。尤其是到了一定时期，所谓的骨干员工开始流失的时候，有些项目会直接无法跟进。

对楼主的建议是：
1、认清现实，在规范化管理和公司生存之间找到一个平衡点。一开始的时候软件管理为项目让步，做后勤而不是做管家。但是让步绝对不是妥协，必要的文档、资料和节点控制一定要有，哪怕是楼主自己辛苦一点，默默的在旁边补也要有。
2、做项目，做技术，树立自己的技术影响。整个团队都是一堆做技术的，你如果不能在技术上有所建树，是根本不可能发出自己的声音的，人微言轻嘛。

2014年9月17日 23:15

mmwy
63
0 0 1

添加评论

0 0

先然别人服你把不然都是扯淡！

2014年9月12日 10:29

q15106202446
30
0 0 0

添加评论

0 0

哈哈你们的C就是一个坑公司也是二B公司，这总公司部能呆早走早解脱哈哈，除非给的公司高在那忽悠钱，要想真正做技术，还是早点撤吧。

2014年9月11日 14:34

FirstBlood
101
1 1 33

3条评论

0 0

研发团队以技术为第一宗旨一点错都没有，但是在追求技术的同时，也得把相应的技能一起掌握，我想C经理的观点是把team中的每个成员都力争培养成全栈工程师，独当一面。
当然，站在团队的角度上，技术底子是基础，日常的一些管理也是必要的，因为有2个新人和一个技术宅，可能往往忽略这点，所以可以把项目分成几个阶段，第一阶段可以让他们按照自己的路子来做事，到第一个阶段快完成的时候，组织大家开会，分析第一阶段的成果和问题，闷头做肯定是会有问题的，有问题就提出来慢慢改进，这样慢慢推进必要的每天早上的站立会议，每个迭代的回顾，总结需要改进的地方，以及开发中必要的codereview....

2014年9月10日 22:18