日志

由繁入简，边走边看－网站项目过程选择

热度 1已有 4007 次阅读2012-1-30 10:03 |个人分类:过程改进| 网站, 项目, Scrum

背景：

原来公司为各种设备制造商提供OEM业务为主，只有面向全球的公司官网（多语言），以及一个面向国内的官网，内容变化不会很多，最频繁的也就是软件试用以及补丁包的上传、产品介绍更新，网站方面投入不会多。

现在一部分业务开始侧重为终端消费者提供服务，和互联网的联系和之前比，无疑要大大加强，就目前Team会接触到的，主要有四类网站业务。

1、企业官网：这是宣传企业形象、展示企业动态的地方，一方面要有更多互动性，让访问者有更多兴趣了解更多信息，另一方面和主流的网络服务要有更多联系，比如利用facebook、sina weibo等渠道。

2、产品站点：每个产品的气质、风格，以及受众未必相同

3、服务站点：服务本身也是一种产品，和平常提供用户使用的软件产品有一定区别的是，服务意味着有更多用户内容产生，比如网络存储，在线打印等等

4、运营系统：内部后台系统，通过各种技术方法为产品和服务提供数据支撑，管理客户和订单。

而这些，都是有限的一部分工程师在做，质量管理部门的诸位仁兄们，几乎都没有实践经验。倒是最近公司招募的一些人才有着之前工作积累下的一些经验。

按照一个Leader的评价，我们原来的流程角色多、审批环节多，感觉效率过于低下。

琢磨：

我们把所有和网站有关的关键角色都找来沟通，其中包括营销、前端页面设计、网站交互设计、后台系统开发、产品经理等等，诸多角色，发现有些地方语境都未形成，举个简单的例子，“网站建设”，这个词有些同学理解为“网站效果设计、前端页面开发”、有的同学理解为“网站做为一个产品，架构、开发、实现、发布的整个过程”、有的同学则把包含文案发布、营销方案上线等营销以及落实工作都认为是网站建设的一部分。

根据沟通结果，以及我对网站的理解，我做了一些大致的规划。以运营系统为例：分成建设、使用、维护三块子过程，其中又包含多个应用。

疑问：

这样绘制后，和几个SQA骨干讨论，感觉他们都可以理解我的想法了，然后安排分头编写。

因为刚好过年，一些同仁请假先走了，过程文件还来不及写出来，年前几天，趁营销团队的美女Leader有空（营销团队总是很忙），和她就这个流程来沟通（因为营销Leader目前兼网站项目的PM）。

营销团队的美女Leader流程意识倒是不错，我看到她绘制的部门内部作业流程图，非常不错，但她看了我的设想，感觉就是角色会有很多。一个人可能兼了几个角色，有些工程师可能会糊涂掉。

思考：

这的确是个问题，目前由于目前网站是短时间搭出来的，功能并不强大，很多文字的更新都要开发工程师帮忙修改页面文件，虽然不合理，但现状就是如此，而我所设想的建设、使用、维护分开，实际上是我基于以往对于电信运营商BOSS系统的开发流程的理解，虽然都是网络产品（或服务），但是无论受众、服务方式，以及产品所在的生命周期，都有非常大的差异。

通常BOSS平台的营销、策划、维护、管理分别都是较大的团队分别实施，而我们所有和网站有关的也就20人以内，这也就是营销团队的Leader会觉得这个角色太多的缘故，我之前教条的分析、简单的套用，显然会有很大的问题。

这套流程应该是对的，但打个不太合适的比方，好比照着大汉的样子做了身衣服，然后让小孩穿。那既不好看，也不方便，要么一动不动呆着，一跑就有摔跤的危险。更何况，我们还不是一个有经验的好裁缝。

选择：

既然面临的问题是人少、活多，不想要太多的流程和控制点，那首先是不能沿用公司之前统一的项目管理工具，那还是和其他试点的产品Team一样，都使用禅道算了。

既然使用了禅道，也就直接采用Scrum的方式，除了营销团队中将安排一个同仁做为网站的产品经理，剩下所有的开发测试部署以及网站管理都视作一个Team，不细分角色。

这样的好处做为专职过程改进的我们，在并不了解网站开发的所有工作的前提下，不用去假装知道所有的细节，而是做为ScrumMaster的角色，通过维护Scrum的框架，投入到Team每天工作中，让每个人都参与改进，这样的价值无疑更高。

新年新起步，定下了方向，等待一两日后所有关键角色都上班后，又一轮Scrum之旅开始。