需求风险的坏味道和对策

大部分项目上,我所承担的角色是帮助客户寻找到产品战略,并着手落地开始项目实施,在这个过程中,我需要强制自己从发散思维中迅速回到收敛思维、从机会导向迅速回到风险导向,因为大部分的IT项目都可能失败,成功对于IT项目而言很可能是「不失败」。 这说起来似乎有些「缺少志向」,但是在现实中IT项目所面对的,除了软件工程本身的巨大挑战、还有技术之外的需求、设计、沟通、政治、分工、计划、等诸多变数,作为一个大型项目的负责人,一旦进入交付落地阶段,就应该进入「风险模式」。 而「控制需求」 »

设计实践与敏捷研发体系

一位来自传统企业、正在经历研发系统敏捷转型的IT组织管理者L先生问我:「当整个研发体系正在朝敏捷方向转型,现有的美工该怎么办?」 本文回答L先生的问题,首先,我们来谈敏捷研发体系转型的基本逻辑: 敏捷体系的基本逻辑 对于传统公司的研发体系而言,定义需求、设计方案、研发系统、测试系统、系统部署、和产品运营往往是独立存在的阶段。越来越多人开始实践敏捷时,选择第一步往往是通过敏捷研发实践和持续构建,将开发体系和测试体系整合(图中①)。 在经历了第一步「研发+测试」敏捷实践之后的第二步,往往是向后将「上线体系」集成在「 »

对交付负责的前期设计

当我说“对交付负责”的时候,就一定是要对交付负责。首先要明白的是,这个世界上有太多对交付不负责的设计,它们广泛存在于各种PPT或者PSD文档中,它们的自我标榜,是感官的美,且不谈逻辑的正确,连情感都是空洞的,而最致命的是,在那些高光渐变材质光晕的炫耀下,是一个不知所措的承诺。 你得承认,这世界上很多人听不懂我们的语言。业务专注商业价值、设计专注深入人心、技术专注维护运营——商业到设计,设计通过技术实现,最终反馈为商业价值的过程,不是由其中的任意一方决定,而更多是妥协。 因此,一个“ »

业务分析师成长路线

ThoughtWorks业务分析师(Business Analyst)的可爱之处在于,这样的一个职位既可以安于现状地成为随项目逐流的普通成员,也可以不知不觉成为决定项目成败地关键。更加具有技术性的是,不同种类的BA决定其在团队中的影响力。 引导者Facilitator 第一类也是最被大众广为流传的,引导者(Facilitator)。这是一个具有强迫症气质的描述,回想一下你是否有热衷于将书架上的书按照高矮顺序排列的爱好。 一个典型的引导者写得一手好的会议记录,并懂得把客户的需求直白地记录在任何电子或纸质媒体,印象中他们一定会在邮件的最后中规中矩地写下Any questions let me know和斜体Regards,尽管大多时候,客户不会专注到注意此类邮件内容。 当然你要有足够的英文和讲演的能力,要善解人意到插科打诨保证与Geek们沟通无障,当然此处沟通只在于通, »

敏捷项目快速启动(QuickStart)指南

敏捷项目由QuickStart开始,顾名思义,和传统软件开发项目不同,敏捷项目的开始需要快速。作为一个标准敏捷项目QuickStart的参与者,我将在本文中介绍QS是如何准备,进行和结束的。 轻装上阵 敏捷的理念同样贯穿在QuickStart中,所有QuickStart的方法都基于敏捷的基本精神,因此也可以把QuickStart当作一个小型的敏捷项目,只是交付物是足以启动整个敏捷项目的所有准备,包括第一个交付期的迭代计划,足够的主故事列表,以及足够的原型设计。 敏捷项目中必备的工具自然要准备,这些包括: 足够多的卡片:我们把任何有需要的东西记录在卡片上,因为它们方便移动 足够多的贴条:我们在需要头脑风暴时需要 足够多的笔:不要让你的客户因为找不到笔而放弃写下自己看法 足够多的白纸:我们的原型都画在纸上, »