konakona
一个没有团队的产品人的那点事儿
一个没有团队的产品人的那点事儿

我在开展产品研发工作仅一个月的时间发现了许多头疼的问题,整个技术团队没有形成产品概念,更没有因为立项而产生任何正能量,反倒因为之前的工作缺乏计划性、奖罚制度未落实等原因负能量满了。

同时也因团队缺乏leader级核心人物而没有凝聚力。松散的团队使得没有人敢对难题说出肯定的话语(也就自然连最开始的“想要去解决问题”的心思都没有了),无法自下而上,每个人都在尽可能的逃避责任或将压力转架于下级员工,同时管理层不去鼓励下级员工,也不曾思前想后理清工作内容,安排详尽的工作计划,导致员工对近期一周的工作目的不明所以,甚至会产生从头到尾都不知道自己做这些有任何意义。管理层的激情彭白和对项目的掌控感会让员工感觉越来越扭曲。

(我们不是受过军事训练和洗脑的佣兵,我们无法克制自己的情绪不随便跑出来)

一个好的珠宝工艺者懂得将每个珠宝串在一根线上。

 

由此可见组织架构存在严重问题。经受不起任何考验,做起事来只会漏洞百出,若想做出一个好的产品更是难上加难。在做一个新项目时需要像赶驴子一样追在每一个人的后面不停的拍打。

 

由于不具备调配资源的权利所以产品工作实施非常困难而且缓慢,再加上不具备话语权,根本没有办法在这样的团队中灵活运作。

 

对于开展产品工作来说,公司整体架构过于松散或我还未能领教到其有效执行力,产品工作中有关市场、财务、人力资源、技术团队都没有调配权和参与权,仅仅是负责文案工作等于在写独角小说。导致产品经理的工作被彻底架空,有没有都无所谓。但这样质量的团队又偏偏无法代替产品经理所能干的事。

 

由于不具备思维灵敏度开发人员和精明能干的设计人员,策划文案的工作变得堆积如山。PRD文档改了又改,甚至高达100多页。我开始怀疑PRD到底适不适合这个团队,我是否应该先打造团队,改变每个人对工作的态度,形成统一的价值观和目标后再去写PRD呢?PRD并不是最重要的,最重要的是有一个好的团队。

 

在之前写PRD的时候,想要做到精简遗骸,但根本不能满足这支贪婪的团队,于是我加上了UC,改了N次版,我发现除了页数增长和自己写东西的能提升长以外,并没有解决什么实质的问题。

PRD是一份将产品需求传递给相关干系人进行功能开发的文档,不应过分涉及程序流程(只要有一个功能里有,那就意味着其他功能里也要有,不然的话别人觉得莫名其妙),偏离正道的PRD已经被我改得面目全非。

 

掉了不少头发后我确立了PRD以后的书写规范:1.文档概要 2.流程说明 3.设计说明 4.功能概要 5.其他跟链接

 

并继续修订。

赞赏
https://secure.gravatar.com/avatar/3b712b34a0e1b689cfb524c9c6bcdc47?s=256&r=g

团哥

文章作者

继续玩我的CODE,让别人说去。 低调,就是这么自信。

发表评论

textsms
account_circle
email

konakona

一个没有团队的产品人的那点事儿
我在开展产品研发工作仅一个月的时间发现了许多头疼的问题,整个技术团队没有形成产品概念,更没有因为立项而产生任何正能量,反倒因为之前的工作缺乏计划性、奖罚制度未落实等原因负能量…
扫描二维码继续阅读
2013-07-03