干了二十多年的技术了, 作为一名80年出生的80后, 特别羞愧的在这里写这篇文章, 我是一名很常见的技术总监, 目前正在做saas电商平台麦穗云, 跟随前新浪高管做过医疗平台, 曾经在热酷做过月流水近千万的 交游戏>的项目经理和后端主程, 跟当年facebook一模一样而且还比校内 更早上线的SNS 交 站新公 的技术总监, 曾经跟随过蒋总在CSDN奋斗过.
这几年对领域驱动开发(DDD)特别痴迷, 结合我之前在看板方面的丰富实战经验和对>, >, >等相关书籍的熟练掌握和运用, 自认可以写这篇文章讲讲我自己的技术方法.
经常听到一些做朋友的朋友说产品的需求多么奇葩, 进度安排多么不合理, 在大概5年以前, 我是非常认可这些朋友的说法的, 现在我跟朋友讨论这些事情的时候, 我回复这些朋友的第一句话是: “其实你的方法不对.”
为什么不对呢为本来你让产品以技术的视野规划产品的表现细节就是很不靠谱的事情, 当然很多产品的工作能力实际也是不足, 但是技术和产品既然是一种合作关系,那怎么样才能让工作更快更好的完成呢bsp;我来说下我的方法.
大致先说下我带领的研发团队的整体流程吧,大家可以看下面的脑图, (⊙o⊙)…, 我没找到可以上传文件的地方
一 用户故事阶段:从需求确认会到用户故事地图
我首先是跟产品就墨刀原型进行一番大致的讨论, 我的问法是你这个功能的目的是什么呢来用它呢会受这个操作影响呢大致给我描述下使用流程吗k, 这些问题产品同学肯定是能够回答的出来的, 然后我会做个记录, 做记录我尝试过如下的方案, 分别说下优缺点
1. 纸质笔记本
优点: 记录会议重点比较省事.
缺点: 会后就不看了…
2. IPad
优点: 用电子笔做会议记录, 录音记录. 装逼
缺点: 会后就不看了…
3. 故事卡片, 这是我用的最久的工作方法, 也是最熟练的方法, 开始是sprint模式, 上线节奏比较慢, 2周一个sprint周期, 后来逐步演化成了看板法, 就是啥着急先做啥, 可以上线了就上线…
优点: 以user story用户故事的方式把产品的需求从使用者, 使用方式, 要达到的目的进行了记录, 对技术同学理解需求有挺强的帮助. 后续开发任务分配, 如前端工作, 后端工作是在另一块白板上黏贴.
缺点: 对开发人员来说故事卡片只是某个页面, 某个功能要开发, 对于用户故事背后的关联性毫无头绪. 而且如果我不提前进行架构, 往往技术同学就无从下手或者最终推翻反复.
4. 用户故事地图
在跟产品开发需求确认会后, 或者我期望产品在画墨刀Axure前跟我先沟通用户故事地图, 根据产品人员的配合情况, 这两种场景都适合使用用户故事地图, 大家有读过>这本书的或者在知乎等平台上看过用户故事地图概念的, 会认为用户故事地图应该这样梳理, 这种方式优点是比较直观, 方便和物理看板进行关联, 而且不论产品是否已经画了墨刀Axure原型, 都有助于产品和技术评判业务缺失点和确认具体需求.
然鹅当时有个美国团队我还要支持, 于是就搞了个xmind的脑图, 方便远程共享. 例子如下
后来就演化成更容易阅读的版本.如下
这是与产品达成最终交付物的最有效的一个工具和方法了, 最早我也是有点犹豫这个方法能否在公司推广开, 因为产品有一套自己的工作习惯, 往往跟技术开需求确认会的时候就是墨刀Axure页面齐全的时候, 这个时候也特别适合使用用户故事地图的方法进行梳理, 可以和产品人员一起发现业务流程上的缺失和问题.
今天先写到这哈, 明天我要去北京一趟, 所以没法做到许诺的日更, 后天继续写头脑风暴阶段. 我也挺想一次性写完的, 问题是这样写差不多我能写本书, 啊!! 还是利用摸鱼的时间想到哪写到哪吧
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览214998 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！