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

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

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

情况似乎跟敝司类似，一直没找到可行的办法，只有一些打算： 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就是我们团队搞出来的”，就很难做出那种激情的创业团队的效果。好像更适合机械化的制度管理方式。。。

5楼 @lucio 这样的话，可能是他们觉得你太好人了吧，开人吧

1、工作细分。至少有个周计划吧，然后周三小会看进度。

2、奖罚分明。有哪些行为是不容忍的，要明确公示。光你自己去希望这希望那没用的。要明确化。

3、带头写文档，重奖写文档。也许，最大问题在于，你自己都觉得现阶段没必要写文档。文档，有助于新人接手，有利于公司积累。

来晚了，看来很多牛人都回复了。再补充几点：

1. 需求文档之类的一定要有。根据你项目情况，需要有合适的管理需求的工具和方法。不一定说要写长长的FRD，也可以写出需求列表，再或者跟那些喜欢玩流程的银行甲方们玩需求report。总之，不要形成skype文字语音报需求的习惯。就算这样交流，过后要写邮件，整理文档把需求落实。
2. 这个项目有很多模块吧？能否把13个人分成小组，因为你对系统熟悉，所以是按前台后台横向分还是整个功能模块的纵向分你会很清楚。谈到什么需求变更，你来判断是哪个模块的，叫上模块对应的小组（一般1-2个人），一起分析需求，然后那个人实现。定义一个基本的流程，从开始你们和客户skype搞完后你整理出需求email开始，到那个人发完release, check in email算结束。所以，那个人的责任就建立了，他对那个更新task负责，你确保需求明确，人到位，就OK。
3. 我总觉得，如果你有13个人，全部的财务透明是否合适？财务上可以只有你，或者你的合伙人另外2个知道就行。其他的人像发工资一样的来做。对于有潜力的重点培养成骨干，加一点儿工资让他“站”出来。
4. 每天2个BUG下班的节奏？？你们项目不是没有文档吗？代码也没有优化吗？把这些任务分配给这些人，并且塑造一个这样的感觉：他们的任务是你给的，不是客户给的。（Again，依然建议不要对13个人公开财务，他们是works for you, but not works for customer.) 这样，让那些每天2个BUG的人慢慢把之前没做的补起来。

再有问题，可以添加我的微信公众号 boluotoutalk ，聊管理聊职场。

9楼 @forzaJuve 谢谢你的回复；你说的这两点目前已经都在开始着手了，

 1.相关的functional specification和technical specification都分别指派相关的accountant和programmer开始写了
 2.计划招一个懂会计的产品运维的角色负责以后沟通，不过目测很难招到，英语好，懂会计，最好还有点sales和IT背景的，估计也很难看上我们这

可能我还是有些理想化，喜欢那种小而精的team, 从内心比较抵触目前这种大团队，Boss Drive Development，打个比方就是1个女人生孩子需要10个月，他们则希望10个人女人一个月生个孩子一样，这样导致的后果就是前面几位说的开人了

14楼 @lucio 我们公司也是一个短短三年半从16个人变成200多人的创业团队....

也遇到过跟你类似的情况...中间也走过很多弯路.....

但是现在的情况就是 里说的理想化的情况......针对不同业务分了好多team 每个team都有相应的 产品,研发,测试人员

但是也是视情况而定的....在没拿到足够的投资,产品线是不可能扩展得那么宽,那么细的...

所以前期,不可避免的出现一个team 做好多事情.....

你的方向肯定没问题,但是文档什么的是最基础的...

最后,你们目前最缺的就是产品经理,运维是运维,运营是运营,

产品经理在团队扩大的过程中 必不可少.

甚至可以说,产品经理 是产品的灵魂.....

12楼 @清醒疯子 谢谢你的回复；奖惩分明这点确实目前做得不够好，对于Accountant,工作能量化还比较好制定规则; 但是对于IT，前面说了我们透明了报价，比如一个初级工程师的报价是$12/h,你对应的成本是￥7000(工资，社保，公积金，办公设备，年终等),如果你表现好，客户涨到$14,你对应的成本就会相应的增加比如￥8000.....,希望这样每个人就不会太去care自己的工资，惩罚措施还没有制定

我觉得 @boluotou 说得也不错,另外推荐你一个项目管理的好工具 : 禅道 .

我们团队现在就是用这个去做项目管理,辅以邮件为沟通...

管理团队最需要做好的就是 : (1)分工 (2) 沟通

另附禅道官网:http://www.zentao.net/

很规范的文档倒是不一定需要，不过我是建议用一个在线wiki工具重新把系统架构、接口、业务逻辑这些东西梳理一遍而且记录下来（最主要是图，方便阅读）。

也是时候梳理团队职能和结构了吧，即使是Agile，团队大了也不是那种10人以内的Agile模式的可以照搬的。