开发队伍建设的一些思考

近半年时间,在团队的管理过程中,遇到了一些问题,相隔半年两位中级程序员相继的离职让我感到了不小的压力。针对他们的问题我进行了下面的一些反思。

问题背景

两位程序员在我看来都处于明显的上升期,一位三年多的工作经验,一位两年多的工作经验。平时工作认真负责,技术能力优秀,对团队认可度较高。他们先后负责了同一个项目,该项目存在以下问题:

架构复杂度略高

该项目存在三个端:云端、局域网控制端、用户操作端。三个端均为异构系统,局域网控制端需要直接与终端硬件进行交互,终端硬件类型较多,现场环境复杂,尤其网络环境、设备环境,不可控因素较多;同时,因客观条件限制,无法在公司内创造理想的环境模拟条件。

运维工作较多

该项目需要7x24h不间断使用,存在多个客户方,项目整体成熟度也较低,造成大量运维工作。开发人员需要全天候待命,随时面对客户,直面系统问题。并且该系统使用过程中有大量的现金交易操作,客户对问题容忍度较低,对异常敏感性较高。

需要直面用户

该系统的使用者通常综合能力较弱,语言表达能力较弱。很多由于自身不规范操作或者一些不太常见的系统理解经常在他们身上发生。因为用户都缺乏软件相关专业背景,大量反馈混杂着Bug、Feature、Require。需要具备良好的综合能力才能从容应对。

管理缺陷

经过我的反思,在我实施管理的过程中,出现了几个较为严重的错误,最终造成了团队成员的流失问题。

能力评估不足

曾经,我作为项目负责人带新人的时候,犯过一个错“我在你这个阶段的时候已经能如何如何了,为什么你还不能?”当时主要还是集中在技术领域,如今,在项目管理领域我又一次犯了这一错误。在我自己的概念里“只要我技术能力足够解决我所需要面对的问题,我是不会惧怕所要面对的压力的。”而这次的两位小朋友,根据我对他们的技术能力评估,我确定他们是有能力解决这些问题的,事实也证明了,单纯就技术而言,他们完全能够胜任。而我却完全忽略了对他们其他能力的判断。
在我工作一年左右,我的领导就将大量的项目交由我进行负责,我需要对项目需求进行了解、与客户进行沟通,产品上线后的运维,我都一人承担。我映像中,最多的时候,有10来个系统都在我的手里,我的工作模式变成了“白天当客服、晚上当开发”。在此期间,也确实感受到了工作压力的巨大,也产生了和用户之间的冲突,在团队内我也对用户有过诸多的抱怨,但是从未因此对自己的能力和工作内容产生过怀疑和退缩,更谈不上精神崩溃。
我简单地以为他们也会和我一样,因此,将项目负责人这一岗位安到了他们的身上。却对技术外的工作能力缺少了相应的评估,最终造成他们无法应对技术之外的种种问题,导致精神压力过大,直至崩溃。

缺少对问题的主动了解

在项目进展的过程中,我缺乏对过程的细致化把控,我希望交由他们自己负责。却少了项目相关细致问题的沟通。我单方面地认为如果他们在项目推进过程中,遇到了问题,会主动找我沟通,我会参与一起解决问题。但在实际操作过程中,显然并未如我所想。
在后来,与年初离职的小朋友通过电话以后,他的一番话语,让我很是吃惊。他从出校门就一直跟随我,从一个技术小白做到了能技术实力独当一面的团队中坚力量,他对我的要求和期待看得很重。他认为,我给了他信任、他需要做到最好来予以回应。而在过程中,也许是缺乏相关的技巧,也许是为了不让自己显得能力不足,对很多问题采用了大包大揽的方式解决。我突然想到了另一个小朋友,几乎每一次崩溃的导火索都来自于客户的群里at反馈问题。而他们俩都出现过和客户沟通中自身心态的炸裂。
我后来总结了他们向我最终的反馈,我几乎可以确定,他们的崩溃,更多的来自于太多的琐碎。来自这些琐碎的困扰,他们很难沟通,很难诉说。而我在过程中,却缺乏了相关问题的细致了解和认真跟踪。

缺少“软实力”建设指导

在一次协助解决问题的过程中,客户提出了非常怪异的服务要求,小朋友和客户的沟通交流过程进展十分困难,小朋友感到十分受挫和自责,向我请求帮助。我随即安排产品经理跟进,产品经理经过一个多小时的沟通,对客户的需求有了明确的认知,并且与我沟通对客户的需求进行了有效的应答。同时,我也郁闷地发现,直到他们选择离开之时,还是无法准确地表达出对客户支持工作的抗拒。
回想起来,我确实缺乏了对他们明确的“软实力”建设指导,没明确引导出他们所面临的相应问题以及相关解决方案,没明确提出遇到何种类型的问题应该如何寻求帮助,如何最好地利用团队资源,以及如何有效地与客户进行沟通。

缺少项目愿景灌输

这也许是我们最不屑的“鸡汤和大饼”,由于该项目特性比较特殊,好比你原先买了一台电脑,原装了一套操作系统,而我将你的操作系统进行了更换。从某些方面说,会给部分用户带来好处,而从公司整体规划而言,这个项目属于其他项目的前驱部分,战略价值显得更为重要。而因为前文所提到的多种客观因素,我们的系统成熟度短期内都很难和原装软件相媲美,在后期的运维过程中,问题的发生又时常打击开发人员的信心,造成对产品必要性的怀疑。
而我因为对“鸡汤和大饼”的不屑,通常只会进行一次性灌输,而后续的信心加强及产品定位却并未进行加强,造成了他们的自我怀疑。不得不承认“鸡汤和大饼”的长期存在,确实有其不可忽略的意义,团队思想的统一,也是队伍建设中不可忽略的一个环节。

我的思考

这次的教训也算是我全面走向管理岗位后的一次深刻教训。必须承认,在面对这些问题时,我过去的想法显得十分稚嫩。其中重中之重在于,并不是所有人都和你一样,看待问题的角度,解决问题的方法,处理问题的手段差异巨大。
这两位小朋友也都存在一个共同点:他们心思细腻,职场经验缺乏。从他们身上,我同样能够看到身为一个职场人、下属,所应该避免的一些问题。回想我自身的经历,多少也存在他们所存在的问题。
最近我都在想一个词“钝性”,不得不承认,在职场上,这是一项不可忽略的能力,它能为你提供一个“稳定性”的外壳。身为领导,你希望看到的下属一定是沉得住气,顶得住负面问题的人。而“钝性”能够提供给你这一外壳。
我曾请教过我学心理学的朋友:“内心强大”和“厚脸皮”有何区别?她告诉我:“内心强大是对自己的自信;厚脸皮是低自尊。”我对此做了不少的思考,就我而言,既很难做到“内心强大”更难做到“低自尊”,但如何做到“稳定性”?我想,从“钝性”开始入手是一个可以考虑的方法。而针对容易情绪失控的自己,我想说,在职场,谁都没有义务对你的情绪负责,而工作,做一个具备稳定输出能力的一份子,对大多数人,也许会是更加有效的选择。

我的微信公众号
我的公众号