有一种团队，叫做个人;有一种做项目的感觉，叫鸡肋。
处于一个创业型公司，常常会碰到以下两种情况。
一. 公司人员配备参差不齐，很多岗位都是缺胳膊少腿。每次一开项目，总有种自己即将战死沙场的感觉。
二.老板隔三差五乐呵呵地跟你说，我们又接了一个小项目，客户的要求是快、准、稳。当你一看客户的需求，满满的一篇，只想仰天长啸问候他的十八代祖宗。
我们公司，就经常出现这种情况。
在项目人员配备上，加上老板，我，主程序，支援型前端工程师，能干事儿的，也就四个人。
老板，每天日理万机，总是每次拿到项目，大家一起开个会，就又马不停蹄的去寻找下一个项目了。
就这样我负责搜集用户需求意见，开发进度汇报，提出产品需求，编写文档，还有产品的美术设计。（从美术出身转行至产品岗）
主程序主要负责生产代码，然后调试，测试，构建，部署，同时也会参与很多与客户沟通的工作，从而得到大量的用户反馈。
支援型前端，是在完成自己的工作情况下，协助该项目的进行。有时候，多帮你一点，那感觉，简直就是赚到了。
这样的团队配置，在遇上这种鸡肋项目应该怎么办呢？
最近看了一本韩伟的《世界500强互联网产品经理管理笔记》，想把读书感悟结合我们的具体情况，跟大家分享一下经验。
一.一句话需求
在做模拟项目的时候，我的导师就时常强调说，要用一句话来总结你的产品。对用户来说，就是用最短的时间描述你能满足我何种需求。实际工作中，有很多客户，想要通过一次成本，整合自己之前项目的所有资源，这个时候，我们都会建议找到一个最有价值的需求，然后进行开发。能在产品需求的设定上，准确的满足用户的需求，其实也是一种“精品”。
二 尽快形成上线条件，抢占先机
由于超小型项目一般开发周期较短，所以给我们试错的机会很少。因此我们就要尽量在服务器的环境下进行开发，调试，避免因为环境问题而花大量时间去找原因。
在技术方面，有的时候为了节约成本，我们之前会去下载许多别人的代码进行改写拼凑，可是往往有时候拼凑的模块不是一个体系的，对产品的运维工作造成了很多麻烦。我们在之前的项目中，就遇到过因为复杂的语言环境，频繁出现配置错误的状况。在那之后，我们一致的意见是，尽量使用一种技术去完成整个项目。
抢占先机的重要性，在这里想举一个例子。最近有部剧叫《三生三世十里桃花》异常火爆，有的客户找到我们，想要做一个测试类的h5。对于我们来说，这个项目完全看不到价值，无非就是通过热点达到引流的目的。不过据我所知，该剧即将迎来大结局，喜新厌旧本就是人的本性，按照客户挑三拣四的性子，估摸着项目刚上线，这股热潮就过去了。这种一次性项目，加之没有一个好的产品或者服务给到你引流来的用户，结果必定是之前的所有投入都打了水飘。
三. 做自己产品的用户
每次做完一个项目，测试总是最枯燥的过程。就拿我们来说吧，产品就像自己的娃，无论他有多么多的缺点，自己也是默默接受，但是最受不了不允许别人说长道短。
因此在出厂前，作为他的亲爹亲妈，只能装作不认识，以第一次见面的心态去重新认识，实际上是能够发现比较多的实现和设计缺憾的。
无论他的出厂零件是否足够好，在测试这个环节，我们都以最严格的标准去把关，对他进行最后的完善。
四.正视别人的意见
每个人都有自己的需求，对待同一件产品，所持意见也各不相同。
有时候，在地铁上，看到同类产品，就忍不住多问一句，这个产品的体验怎么样，你觉得哪里比较好？然后自己也下载下来玩，和这个社区下的用户产生互动和沟通 ，挖掘更多新的产品需求。
也会每天去留意自己产品，用户给的反馈，通过这些信息，不断去优化自己的产品，在用户的“教育”下成长起来。
项目结束以后，我们之间会有一个短暂的沟通，相互说一下自己的经验和教训，但也并非是像大团队那样，整个一个团队作案自首现场。想必这也算人员精干的一点点好处。
总结一下，人员少的情况下，做小项目，需要精简用户需求，保持干净的环境和采用单一技术，速战速决，和用户要达成良好的互动关系。
好了，今天就写到这里了。老板，啥时候请我们吃饭？
书籍推荐：
《世界500强互联网产品经理管理笔记》介绍的项目管理知识，是以互联网项目开发为重点实践对象的。和一般项目管理书籍以介绍项目管理的过程为主不同，《世界500强互联网产品经理管理笔记》的重点在于介绍团队中的各个角色，阐述他们在不同类型的项目管理中应该承担的责任，以及实践中的经验教训。
-THE END-
梦鱼，创业界里的小学生，坚持每天进步一点点的人。微信公众号：深夜书桌前（ID:Plz-be-yourself ）,坚持分享原创文章，卖鸡汤，也挖坑，希望找到能够一起进步的人。
