您当前的位置:
请教下在创业期的小公司如何制定项目奖惩制度
小弟大学毕业六年，这两年来和同学创业搞了个小IT公司，主要是做乙方干活。发展到现在2年多，公司连同我和合伙人一共15人，另外固定的兼职还有2人，都是干活的，至今没有行政人事财务这些后勤的职位。主要是我们起步低，想省钱，所以后勤的工作都自己咬牙做了，财务则是我合伙人的老婆帮忙做。
但是公司运作到现在，管理的问题开始浮上来，问题越来越多。一个是开发的效率很慢，一个是员工的态度不行，根本不像是一个创业的有朝气的公司，好多人都是能混则混，我们一出去见客户，他们就聊天打游戏，等我回来往往发现布置的任务进展很慢，有一些资格老的人还喜欢讨价还价，给分配的项目说什么不想做，想做其他的项目之类，今年过了春节后IT的行情很好，工资普遍大涨，我这样的小公司招人蛮困难，不是说招就可以招来的，所以也不可能雷厉风行的裁换员工，目前就想到要增强一些管理制度。
我现在打算搞项目负责制，就是每个项目定一个team leader，然后把任务拆细写成文档，然后分配好人员后让team leader来跟踪进度，项目如果按时完成，从该项目的利润里抽钱作为项目奖金。目前大的原则确立了，但是因为我管理经验少，细节方面很多还觉得不大好入手，想请教下。
第一是我们因为是创业期，项目不是都赚钱的，有的项目是可以有利润，有的项目是为了将来的，做的好会有后续，所以第一单不赚钱，我的设想是类似那些不赚钱的，涉及公司战略，就给一个积分，这个积分到了年底是年终奖的一个依据，还有将来职位的升迁也会考虑进去，但是不知道这样做可行么，具体的细则要订到怎么一个程度，我感觉蛮头疼的。
第二是成本的核算，就是怎样算项目成员在一个项目里花的时间，这个似乎不太容易计算，理论上应该是我们根据经验和合同期来给一个项目定格标准，然后低于这个时间完成就是更好，超出就是不行，但是实际执行肯定很麻烦，因为公司小，每个人除了项目外会有因为突发情况而要做的一些杂事，这些情况可能需呀平衡。
最后一个项目奖金的比例不知道一般是多少，我以前自己工作的时候公司有这方面的规定，但是从来没有兑现过（这也是我以前单位留不住人的原因），所以我自己不清楚通常的行情，应该是对少，我现在大部分项目都不大，几万块的那种，少数是几十万，不同数量级的项目应该也不是用一个比例的，这里怎么来分，有jrs有这方面的经验可以告知就太感谢了。
说了许多，都是我和合伙人自己拍脑袋想出来滴，我们都是技术出身的，为了创业，我最后两年转职去做了销售，但是我们都没有内勤方面管理的经验，不知道怎么更好的通过一些手段去激励人，怎么来平衡公司的气氛但是又不失去应该有的威信，现在人多了问题就多了，希望可以主动的去解决，否则真正大问题爆发估计就要惨了。
------解决方案--------------------
用钱是解决不了问题的。好的公司不需要自认为编程水平比较高、但是又过于纠结于低级算法的人。然而只有这些人才可以用虚幻的“将来的奖金”糊弄一下。而对于可以组织项目开发的人，你用虚幻的积分来糊弄反而适得其反。其实不用去考虑钱的问题，假设我们把未来1个月的50个任务（这只是一个好产品的一个迭代开发周期中的任务）写到一块大大的白板上，如何讨论这些任务大小的当、接口得当、论证得当、所有开发人员都取得了一致（基本水平接近）的认识呢？这就是开发管理。而一个产品的真正的路线图、灵活地在每一个迭代中控制任务设计、如何进行高水平的测试驱动开发（从而让软件质量和开发速度都比那些作坊式的开发块3倍以上，并且无需专门花时间去做人工测试）的开发是什么呢？这就是产品管理。
管理者如果是项目和开发的外行，那么就要借助好的内行管理人员，来共同实现蓝图。你只应该跟这样的内行分享奖金。而如果不小心把这些东西告诉给那些不懂整个项目开发的中间各种风险的一般开发人员，他们仍然无法克服自身的弱点，但是反而会把这些缺点造成的问题归咎于你的奖金不够多、发放不及时，你不但没有提高开发效率而且可能更快地丧失人心。
------解决方案--------------------
或许可以在许多软件作坊中见到这样的所谓管理者，它满脑子就是某些个算法如何编写、某些个sql语句如何写之类的，面对大一点的项目他的想法就是把一大堆这种东西堆积在脑海中然后用来评价别人的方案，他总是希望列出一大堆问题然后给出一个全世界最顶尖、堆砌的时髦技术术语最多、最与众不同的“架构”。实际上这个时候很难做好创业式的开发，这样的管理者最适合的是到一个貌似很大而实际上还是作坊式的企业中。原因就在于，这不是行动的模式，他轻易地否定那些感觉敏锐、在行动的路上不犯错误的人，而是过于学院派。真正好的行动是貌似最朴实，然后结果却出人意料地快速达到用户心甘情愿买单的地步。
创业者就好像一个兔子，一边快跑一边还要找草吃，他不可能像行动缓慢的骆驼那样。所以关键不是看这个人是否喜欢列出一大堆需求描述然后开始幻想一个最与众不同的“架构”，而是要看他是否能够用“触觉”就能正确地作出产品。为了项目管理者挣钱，一个项目就应该达到这样一种境界：所有开发人员都有勇气编码；任何人任何时候去更改产品代码都无法伤害到产品的质量，反而会使得开发速度更极限、更敏捷；只要重构必定使得系统变得特别高效或者大大节省将来的开发时间（而不是仅仅提高一点点）。我遇到一些管理者，他们列出一大堆问题，然后希望得到一个堆砌的时髦属于最多的架构，除了这条路就没有什么更好的管理措施了（他并不注重过程、只注重对他而言不切实际的“结果”），这就跟只是拿钱说事一样，都是不切实际的。
------解决方案--------------------
你讲到了要找各个team leader负责，所以我给你个深入一点的建议，这种人的做事方式才是最大的风险系数，而不要以为假单地从那些中低级程序员中找一个最喜欢死记硬背知识的人挑选一个就行了。
你也讲到了奖金公开和提前的问题，但是我给你个深入一点的建议，中低级的人员是经常变动的（所以他们心里永远不会只盯着虚幻的未来奖金，而是赚一点就走）。并且最主要地是，用户的期望会在第一眼看到产品原型时就开始飘逸，所以项目开发的过程必定充满了变数（既是挑战也是机遇），所以预先精算奖金是不切实际的。如果你想明白了跟那些确定可以更你一起把变数编程机遇的人分配奖金，要比胡乱空想跟一般的程序员分配奖金，这个想法更靠谱一些。
------解决方案--------------------
我同意 SP1234的 观点
钱不是万能的，所谓的积分制度就更不可取了
从你描述来看，BOSS一方一旦不在公司，员工一方就打游戏聊QQ
这样形成了对立的两方：一方是监视方 一方是被监视方
这可不是管理方想看到的场景
建议你找专门的一人来当 黑脸， 你来当白脸
适当的权人之策是必不可少的