爱.港湾

 

昨天负责后台的同事很高兴的告诉我小站的访问量涨了很多，正当我们聊着一些不着边际的话时，他突然问我：“你对小站以后的发展怎么看？”心里一惊，想了想，然后小心翼翼的回答：“这不是你们和产品运营的同学应该考虑的么？”，他无奈的告诉我：“都不知道他们每天都在干嘛。”

听他这么说，我已经看到小站项目组或许正在面临比较严重的内部问题了，因为不是身处其中，所以能更加客观的看待。

现在，还会经常跟晟晟高谈起小站，晟晟高说：过了这么几个月，感觉Qing博客越做越好了，定位越来越清楚，我看到的就是一个个博客，而且里面的内容还不错。可是小站好像定位还不明确，似乎仍然是那些“非正常人类研究中心”很恶俗的东西。即使不在项目组了，我仍然会经常去逛逛小站，有了新的很好的功能，我也会作为当事人一样特别的高兴，可事实是，过了快半年的时间，小站似乎变化很少，我快离职的那个月里有正在做的比较大的功能至今都没上，我有时候也会向晟晟高抱怨：“怎么小站都没什么进展啊，进去看，都没怎么找到好玩的内容”。说了那么多，总结一句话“小站没动静，让用户感觉不到惊喜”。产品从来不需要一开始就完美，后面持续的给用户制造一些小惊喜，就能让人知道他们在努力，可是一个产品本来不够好却又长时间内没有多大动静，怎么让我们去爱？

这就是我今天要说的问题：暂且不考虑产品团队提出的功能好不好，项目组如何相互配合最快最好的实现功能，做出成果。

身在项目组，我也感受到了，一个星期能做的事情很少，从产品人员到开发人员都是这样。每周五开例会的时候，都会给下周的任务进行排期，列下来发现一周时间做的东西真的好少（人员有限，工作时间有限），一个月也是，几个月也是，这样想来，似乎我又能理解为什么小站几个月都没有多少变化。可是也会有其他产品像打了鸡血一样，几个星期给人一个大惊喜，给我印象比较深的是微信。我就想：为什么我们的项目组不能像他们一样都打了鸡血一样，为了更好的小站大家都拼尽全力呢？

为了找出问题，我列出如下现象：每周五会有例会，小站的所有成员会参加，由产品人员组织，对下周的工作进行安排，产品人员会列出待做事项，然后这样问：“XX功能谁做？要多久？”这样下周的任务都分配好了，散会。不知道你看出来没有，这里是有问题的。应该说周五的例会是各小组之间唯一一次正式的交流，可是上述过程却浓缩为：产品与运营同学想出了需求，给开发测试人员分配任务，这中间没有交流讨论，开发人员对为什么这么做这些东西以及近期内还要做什么东西几乎完全不知。

小站内部合作的问题不仅仅发生在产品和开发之间，也发生在产品和运营之间。记得有次运营的同学很生气的找我们理论：为什么开发出了新的功能我们运营的人都不知道？还是用户告诉我的！其实，我那时候的一项工作是：由于周四新功能上线了，周五开例会安排下周任务，所以开完例会后，我会将这两个星期的完成的工作和下周预期的工作都会以邮件的形式发送给小站所有人。这样算是间接告诉了他们，可是现实和预期是有差距的，他们并不在意这封邮件，所以并不知道。

要知道，一个团队里各个岗位都很重要，从产品设计到开发到测试再到运营再到产品，都是环环相扣的，哪一环出了断裂就会有问题，更何况环环断裂那将会是一盘散沙，又怎么会高效率的做出成果来呢？最后出现的问题正如最上面说出的那段话：开发人员不知道产品人员和运营人员在做什么，怎么规划的，所以开发起来没动力没希望；产品人员觉得开发速度慢，没法出成果！这样恶性循环下去，自然产品进展慢，渐渐被其他产品所替代。

为了说明怎么解决这个合作的问题，我先说两段我的经历。

记得我离职前做了一个相对复杂功能，配合我完成的是一个前端同学和一个后台同学以及共享一个测试同学，当时我们大家做的还算很开心。因为我当时出方案的时候考虑实现技术的较少，大多从业务逻辑出发，所以开发的同学实现过程中会出现问题，他来找我理论，庆幸自己学软件出身的，他讲如何实现的时候我还是能听懂的，这时，解决方案会有折中，不能完全按照我想的那样做了。这没关系，只要能在最短时间内实现出能帮助到用户的功能就可以了。那时候，这位开发的同学很主动，经常会给我提出优化流程的建议，因为这样做既可以缩短开发时间，减轻复杂度，而且又不会影响用户的使用，只要讨论后，发现他对于我的方案有好的修改，我都会很爽快的接受。所以这次合作相当愉快，甚至时间紧迫时他主动加班完成，当然我也会陪着。

作为一个软件学院（又被同学自嘲为“文档学院”）出身的学生，写的文档算是详细规范的，但是不管我负责多小的功能，我都会在文档里详细写清楚为什么要做这个功能，做了有什么好处，并且会把功能具体怎么实现，实现完了度量哪些数据去检查成果（这项是产品组的领导提出的，我觉得相当好）。这样开发的同学会知道，这工作是有意义的，有收效的，他们自然乐意做了，效率自然高了。

这就是我的两段经历，现在回想起来算是做的不错的地方，由于大学的大家庭就是程序猿，所以对于做开发的人感觉特别亲切，沟通自然也多。现在客观的回忆起这段经历，我也深深感受到了其中的好处，开发人员不再是实现代码的工具了，而是我们正在为相同的目标而奋斗着，这样更容易出成果。

这也是我今天想说的：虽然各个团队各司其职，但是沟通真的很重要，产品团队既然作为领军人物，那就要将小站的发展理念传递给小站所有成员，不管是近期的还是远期的，这样大家才能站在统一战线上。周五的例会，可以不仅仅是分配任务，更重要的是要向所有小站的人传递这样的信息：我们要做这些功能，因为这样做可以如何帮助用户，可以如何吸引到更多用户，可以如何留住老用户。不要以为这样做的话，这个会议会持续很长时间，耽误他们工作时间，其实时间长只能说明会议组织者表达能力不够强大，太罗嗦。如果能这样做，开发的人不仅仅是实现产品同学想法的工具了，他们也参与了进来，他们知道做这些东西是有用的，或许他们也能从技术的角度提出更好的方案来，他们知道前面的路是光明的。只有目标明确了，大家才能像打了鸡血一样的工作，而不仅仅为了完成任务和敷衍。

团队发展壮大后，沟通成本自然大了，但是只要报着“说服他们做出这些功能”的心态，而不是“安排他们做出这些功能”，那效果会好很多吧！

 

 

 

 

 

Tags: 人人小站 团队合作