要想马儿跑,就得给马儿吃草

你这种外包项目,钱肯定是你拿大头,那自然要多干活,其他人又不傻;当然,现在你的情况是手下太懒了,因此你要做的是明确手下的职责,不行就开人呗

感觉是连楼主自己都无法保持工作的激情里,更何况手下的员工。

情况似乎跟敝司类似,一直没找到可行的办法,只有一些打算: 1,量化工作,横向比较,当然更重要的是和奖金好挂钩 2,制定短期和长期目标,大家有点奔头 3,加强团队建设,让大家关系好点 4,建立顺畅的工作沟通渠道 5,开人

只是这样打算,实施起来发现很难,人都痞掉了,有时候都想全部重来......

2楼 @dowei 多谢你的回复!其实你提的这些点,团队激励和中长期规划都有在做,目前氛围也还算好,就是本人觉得很是疲惫和焦虑,眼睁睁的看着一些很小的问题都是因为沟通和流程上耽误太多的时间而未能及时发布解决,非常不适应这种臃肿的流程化的东西,也许对于长远来说有利; 团队倒是还没到都痞掉的境地,只是预感这样下去会很快到那一天.

发钱,发粮,发娘们!

1楼 @ithinco 要想马儿跑,就得给马儿吃草. 这个自然在理,目前还没开过人,也没人离开,因为把客户的报价和他们能拿到手的都给他们透明化了,激励是一方面,但总感觉不是能持久化的,也可能和项目本身的特性有关.

3楼 @lucio 出现这种情况,很大原因是因为,以前的代码的维护性和扩展性太差,导致维护的很疲惫啊。

积攒和重构代码,不断迭代,从而获得自己的一套开发和扩展维护都有高效率的积木式模块,乃至可以所见即所得配置和维护,短期看很麻烦,长期看势在必行。

否则这种情况会不断发生,随着项目增多一直延续下去。

我所在的公司里,代码都有十几年历史了,结构特差,各种肮脏代码潜藏...我重构了部分,所重构的部分用起来就非常舒服。

4楼 @freecunix 因为是外包,钱和粮给他们透明化了再怎么也只有那么多; 至于娘,现在团队里面女的多于男的,因为客户那边缺处理业务数据的会计,因此也帮忙成立了一个10来人的Accountant团队(全部都是90后毕业一年左右的MM),但是屌丝程序员码字还行,一见面交流就都怂了,哈哈

6楼 @尼克徐 谢谢你的回复!在这里我很想说一个词BDD,这里特指Boss Drive Business, 背景我说了,最开始客户这公司压根就没IT,需求都是一部分一部分的给,很难形成一个整体,在东西上线之前,Boss有时候都不一定清楚最后弄出来的东西是不是自己想要的,所以代码质量确实很多地方比较乱; 长远来看,重构和文档整理都是很有必要的(前提是最基础的功能要先做完,在项目早期只有1-2个人,上线压力大的时候谈各种文档和重构就是一坨shi一样的空话),也是最近头疼的重点,要说服Boss,要准备大量的纯英文Report.>_<

看到你说的两个情况...

1,文档缺乏, 这个很致命的 带来的直接后果就是

 (1):新员工入职适应期长, 而且什么都得来问你,然后你就会被累趴了...
 (2):陆续来的新老员工写的代码交替,导致 连你也可能搞不清很多地方的逻辑....恶性循环

解决方案: (1) 一定要建立文档 如业务流程文档,代码结构文档

 (2) 建立wiki ,鼓励要求研发人员把重要或者复杂的逻辑写开发文档 ,并存储到wiki当中

2,研发交流能力差,没法与客户打交道

 我想说的是,本来就不应该要求研发直接与客户去打交道.
 你应该成立一个产品部,专门负责与客户沟通需求,并转化为研发可识别的需求(axure 原型以及需求文档)

这样子 业务逻辑由产品部去维护整理,研发人员专心写代码

各司其职,不就梳理开了吗?

7楼 @lucio 最好是项目具有挑战性,存在风险并有可能获得很大的回报(经济上或名誉上)。一般都是这种类型的项目,加上一些牛X的激情四射的技术狂人,才会达到团队整体积极度很高的效果。如果项目本身没什么挑战,很成熟的运营过N年了,做完了成员也不能出去吹嘘:"xxx就是我们团队搞出来的",就很难做出那种激情的创业团队的效果。好像更适合机械化的制度管理方式。。。