"Developers and team members gather requirements discussed in face to face meetings and write some quick notes"
Start with that. If you aren't taking notes, just make one small change. Take Notes. Later, you might post them to a wiki or create a feature backlog or start using Scrum or bugzilla or something.
First, however, make small changes. Write stuff down sounds like something you're not doing, so just do that and see what improves and what you can do next. Be Agile. Work Incrementally.
You might want to be careful of the HiPPO in the room. The Highest Paid Person's Opinion is not always a good one. We've tended to focus more on providing great tools and support for developers. These things, done right, take some of the hassle out of development, so that it becomes faster and more fun. Developers are then more flexible in terms of their workload, and more amenable to late-breaking changes.
One-Click testing and deployment are a couple of good ones to start with; make sure every developer can run up their own software stack in a few seconds and try out ideas directly. Developers are then able to make revisions quickly or run down side paths they find interesting, and these paths are often the most successful. And by successful I mean measured success based on real metrics gathered right in the system and made readily available to all concerned. The owner is then able to set the metrics, which they probably care about, rather than the requirements, which they either don't care about or have no experience in defining.
Of course it depends on the owner and your particular situation, but we've found that metrics are easier to discuss than requirements, and that developers are pretty good at interpreting them too. A typical problem might be that customers seem to spend a long time filling their shopping carts but don't go on to checkout.
1) A marketing requirement might be to make the checkout button bigger and redder. 2) The CEO's requirement might be to take the customer straight to checkout, as the CEO only ever buys one item at a time anyway. 3) The UI designer's requirement might be to place a second checkout button at the top of the cart as well as the existing one at the bottom. 4) The developer's requirement might be some Web 2.0 AJAX widget that follows the mouse pointer around the screen. Who's right?
Who cares... the customer probably saw the ridiculous cost of delivery and ran away. But redefine the problem as a metric, instead of a requirement, and suddenly the developer becomes interested. The developer doesn't have to do 10 rounds with the CMO on what shade of red the button should be. He can play with his Web 2.0 thing all week, and then rush off the other 3 solutions on Monday morning. Each one gets deployed live for 48 hours and the cart-to-checkout rate gets measured and reported instantly. None of it makes any difference, but the developer got to do their job and the business shifts it's focus onto the crappy products they sell and the price they gauge on delivery.
Well, ok, so the example is contrived. There's a lot of work in there to make sure that the project is small, the team is experienced, hot deployment is simple, instant rollback is provided, and that everyone's on board. What we wanted to get to is a state where the developer's full potential is not wasted, so that's why they're involved not just from the start, but also in the success. Start out with an issue like the number of clicks during registration is too high, run it through a design committee, and we found that the number of clicks actually went up in the design specification. That was our experience anyway. But leave the developer some freedom to just reduce the number of clicks and you might actually end up with a patented solution, as we did. Not that the developer cares about patents, but it had merit - and no clicks!
FWIW：根据 Joel 对软件产品的良好分类，该项目是一个“内部”项目。 因此，我们可以按照客户的能力提供敏捷性。 :-)
Although the concept of "product owner" is a littl ambiguous to me, I think I am working in very similar circumstances: the customer is extremely buzy and always is a bottleneck in developing requirements.
On the surface, what we try to do in this situation is quite obvious and seemingly simple: we try to make sure that the customer is involved in "read-only / talk-only" mode. No writing. Minimum reading. Mostly talking.
The devil, of course, is in details. So, here are some specifics about our process (in no particular order):
We often start from recording problem statements, which are the ultimate sources of requirements. In fact, sometimes a problem statement is all that we record initially, just to make sure it does not get lost.
NB: It is important to distinguish problem statements from requirements. Although a problem statement sometimes clearly implies some requirement, in general a single problem statement may yield a whole bunch of requirements (each having its own severity and priority); moreover, sometimes a given requirement my define a solution (usually just a partial one) to multiple problems.
One of the main reasons of recording problem statements (and this is very relevant to your question!) is that semantically they are somewhat "closer to the customer's skin" and more stable than requirements derived from them. I believe those problem statements make it much easier and quicker to put the customer into proper context whenever he has time to provide feedback to the development team.
We do record all the requirements (and back-track them to problem statements), regardless of when are we going to implement them. Priorities govern the order in which requirements get implemented. Of course, they also govern the order in which customer reviews unfinished requirements.
NB:A single fat document containing all requirements is an absolute no-no! All the requirements are placed in "problem tracking database", along with bug reports. (A bug is just a special case of a problem in our book.)
We always try to do our best to minimize the number of iterations necessary to "finalize" each requirement (or a group of related requirements). Ideally, a customer should have to review a requirement only once.
Whenever the first review turns out to be insufficient (happens all the time), and the requirement in question is complex enough to require a lot of text and/or illustrations, we make sure that the customer does not have to re-read everything from scratch. All the important changes/additions/deletions since the previous reviwed version are highlighted.
While a problem or requirement remains in an unfinished state, all the open issues (mostly questions to customer) are embedded into the document and highlighted. As a result, whenever the customer has time to review requirements, he does not have to call a meeting and solicit questions from the team; instead the customer can open any unfinished document first, see what exactly is expected from him, and then decide what's the best way and time (for him) to address any of the open issues. Sometimes the customer chooses to write a email or add a comment directly to the problem document.
We try our best to establish and maintain official domain vocabulary (even if it gets scattered across the documentation). Most importantly, we practically force the customer to stick to that vocabulary.
NB: This is one of the most difficult parts of the process, and customer tries to "rebel" from time to time. However, at the end of the day everybody agrees that it is the only way to make precious meetings with the customer as efficient as possible. If you ever attended one-hour meetings where 30 minutes were being spent just to get everybody on the same page (again), I'm sure you would appreciate having a vocabulary.
NB: Whenever possible, any changes in the official vocabulary get reflected in the very next release of the software.
Sometimes, a given problem can be solved in multiple ways, and the right choice is not obvious without consulting with the customer. It means that there will be a "menu of requirements" for the customer to pick from. We document such "menus", not just the finally chosen requirement.
This may seem controversial and look like an unnecessary overhead. However, this approach saves a lot of time whenever the customer (usually few weeks or months down the road) suddenly jumps in with a question like "why the heck did we do it this way and not that way?" Also, it is not such a big deal to hide "rejected branches" using proper organization/formatting of requirements documentation. Boring but doable. :-)
NB: When preparing "menus of requirements", it is very important not to overdo them. Too many choices or too many choice nesting levels - and the next review may require much more customer's time than really necessary. Needless to say that the time spent on elaborated branches may be totally wasted. Yes, it is difficult to find some balance here (it greatly depends on the always-in-a-hurry customer's ability to think two or more steps ahead and do it quickly). But, what can I say? If you really want to do your job well, I am sure that after some time you will find the right balance. :-)
Our customer is a very "visual" guy. Therefore, whenever we discuss any significant user interface elements, screen mockups (or even lightweight prototypes) often are extremely helpful. Real time savers sometimes!
NB: We do screen mockups exclusively for the customer, only in order to facilitate discussions. They may be used by developers too, but in no way do they substitute user interface specifications! More often than not, there are some very important UI details that get specified in writing (now - primarily for developers).
We are lucky enough to have a customer with a very technical background. So we do not hesitate to use UML diagrams as discussion aid. All kinds of UML diagrams - as long as they help customer to get into proper context quicker and stay there.
I am talking about requirements-level UML diagrams, of course. Not about implementation-level ones. I believe that even not very technical people can start digging requirements-level UML diagrams sooner or later; you just have to be patient and know what to put on a diagram.
Obviously, the cost of such process greatly depends on analytical and writing skills of the team, and of course on the tools that you have at your disposal. And I must admit that in our case this process appears to be quite expensive and slow. But, taking into account the very low rate of bugs and low rate of "vapor-features"... I think, in the long run, we get very good payback.
发布评论
评论（3）
“开发人员和团队成员收集面对面会议中讨论的需求并写一些快速笔记”
从这里开始。 如果您不做笔记，只需做一点小小的改变即可。 做笔记。 稍后，您可能会将它们发布到 wiki 或创建功能待办事项列表或开始使用 Scrum 或 bugzilla 等。
然而，首先要做一些小的改变。 把事情写下来听起来像是你没有做的事情，所以就这样做，看看有什么改进以及下一步可以做什么。 保持敏捷。 渐进式工作。
"Developers and team members gather requirements discussed in face to face meetings and write some quick notes"
Start with that. If you aren't taking notes, just make one small change. Take Notes. Later, you might post them to a wiki or create a feature backlog or start using Scrum or bugzilla or something.
First, however, make small changes. Write stuff down sounds like something you're not doing, so just do that and see what improves and what you can do next. Be Agile. Work Incrementally.
您可能需要小心房间里的河马。 收入最高者的意见并不总是好的。 我们倾向于更多地关注为开发人员提供出色的工具和支持。 这些事情如果做得好，可以消除开发中的一些麻烦，从而使开发变得更快、更有趣。 这样，开发人员的工作量就更加灵活，并且更能适应最新的变化。
一键式测试和部署是两个不错的起点； 确保每个开发人员都可以在几秒钟内运行自己的软件堆栈并直接尝试想法。 然后，开发人员能够快速进行修改或沿着他们认为有趣的旁路进行，而这些路径通常是最成功的。 我所说的成功是指根据系统中收集的真实指标来衡量成功，并随时向所有相关人员提供。 然后，所有者可以设置他们可能关心的指标，而不是他们不关心或没有定义经验的需求。
当然，这取决于所有者和您的具体情况，但我们发现指标比需求更容易讨论，而且开发人员也非常擅长解释它们。 一个典型的问题可能是客户似乎花了很长时间填充购物车，但不继续结账。
1) 营销要求可能是让结账按钮更大、更红。 2) CEO 的要求可能是直接带顾客去结账，因为无论如何，CEO 一次只购买一件商品。 3) UI 设计师的要求可能是在购物车顶部放置第二个结账按钮，并在底部放置现有的结帐按钮。 4) 开发人员的需求可能是一些在屏幕上跟随鼠标指针的 Web 2.0 AJAX 小部件。 谁是对的？
谁在乎呢……顾客可能看到了荒谬的送货费用然后逃跑了。 但将问题重新定义为一个指标，而不是一个需求，开发人员就会突然产生兴趣。 开发人员不必与 CMO 就按钮的红色深浅进行 10 轮讨论。 他可以整周都在玩他的 Web 2.0 东西，然后在周一早上匆忙完成其他 3 个解决方案。 每一项都会实时部署 48 小时，并立即测量和报告购物车到结账率。 这些都没有任何区别，但开发商必须做好他们的工作，而业务则将注意力转移到他们销售的蹩脚产品以及他们在交付时衡量的价格上。
好吧，所以这个例子是人为的。 那里有很多工作来确保项目小、团队经验丰富、热部署简单、提供即时回滚，并且每个人都参与其中。 我们想要达到的是开发人员的全部潜力不被浪费的状态，因此他们不仅从一开始就参与其中，而且还参与成功。 从注册时点击次数过高这样的问题开始，通过设计委员会进行处理，我们发现设计规范中的点击次数实际上增加了。 无论如何，这就是我们的经历。 但是，给开发人员一些自由度，让他们减少点击次数，您实际上可能会得到一个专利解决方案，就像我们所做的那样。 并不是说开发商关心专利，而是它有优点——而且没有点击！
You might want to be careful of the HiPPO in the room. The Highest Paid Person's Opinion is not always a good one. We've tended to focus more on providing great tools and support for developers. These things, done right, take some of the hassle out of development, so that it becomes faster and more fun. Developers are then more flexible in terms of their workload, and more amenable to late-breaking changes.
One-Click testing and deployment are a couple of good ones to start with; make sure every developer can run up their own software stack in a few seconds and try out ideas directly. Developers are then able to make revisions quickly or run down side paths they find interesting, and these paths are often the most successful. And by successful I mean measured success based on real metrics gathered right in the system and made readily available to all concerned. The owner is then able to set the metrics, which they probably care about, rather than the requirements, which they either don't care about or have no experience in defining.
Of course it depends on the owner and your particular situation, but we've found that metrics are easier to discuss than requirements, and that developers are pretty good at interpreting them too. A typical problem might be that customers seem to spend a long time filling their shopping carts but don't go on to checkout.
1) A marketing requirement might be to make the checkout button bigger and redder. 2) The CEO's requirement might be to take the customer straight to checkout, as the CEO only ever buys one item at a time anyway. 3) The UI designer's requirement might be to place a second checkout button at the top of the cart as well as the existing one at the bottom. 4) The developer's requirement might be some Web 2.0 AJAX widget that follows the mouse pointer around the screen. Who's right?
Who cares... the customer probably saw the ridiculous cost of delivery and ran away. But redefine the problem as a metric, instead of a requirement, and suddenly the developer becomes interested. The developer doesn't have to do 10 rounds with the CMO on what shade of red the button should be. He can play with his Web 2.0 thing all week, and then rush off the other 3 solutions on Monday morning. Each one gets deployed live for 48 hours and the cart-to-checkout rate gets measured and reported instantly. None of it makes any difference, but the developer got to do their job and the business shifts it's focus onto the crappy products they sell and the price they gauge on delivery.
Well, ok, so the example is contrived. There's a lot of work in there to make sure that the project is small, the team is experienced, hot deployment is simple, instant rollback is provided, and that everyone's on board. What we wanted to get to is a state where the developer's full potential is not wasted, so that's why they're involved not just from the start, but also in the success. Start out with an issue like the number of clicks during registration is too high, run it through a design committee, and we found that the number of clicks actually went up in the design specification. That was our experience anyway. But leave the developer some freedom to just reduce the number of clicks and you might actually end up with a patented solution, as we did. Not that the developer cares about patents, but it had merit - and no clicks!
虽然“产品负责人”的概念对我来说有点模糊，但我认为我的工作环境非常相似：客户非常忙碌，并且始终是开发需求的瓶颈。
从表面上看，我们在这种情况下尝试做的事情非常明显且看似简单：我们尝试确保客户处于“只读/仅限通话”模式。 没有写作。 最低阅读量。 主要是说话。
当然，魔鬼在于细节。 因此，以下是有关我们流程的一些细节（排名不分先后）：
我们通常从记录问题陈述开始，这是需求的最终来源。 事实上，有时我们最初记录的只是一个问题陈述，只是为了确保它不会丢失。
注意：区分问题陈述和需求非常重要。 尽管问题陈述有时清楚地暗示了一些要求，但一般来说，单个问题陈述可能会产生一大堆要求（每个要求都有自己的严重性和优先级）； 此外，有时给定的需求可以定义多个问题的解决方案（通常只是部分解决方案）。
记录问题陈述的主要原因之一（这与您的问题非常相关！）是，从语义上讲，它们在某种程度上“更贴近客户的皮肤”，并且比从他们。 我相信，只要客户有时间向开发团队提供反馈，这些问题陈述就可以让客户更轻松、更快速地进入适当的背景。
我们确实记录所有需求（并将其回溯到问题陈述），无论我们何时实施它们。 优先级决定了需求的实现顺序。 当然，它们还管理客户审查未完成需求的顺序。
注意： 包含所有需求的单个胖文档是绝对不行的！所有需求都与错误报告一起放置在“问题跟踪数据库”中。 （错误只是我们书中问题的一种特殊情况。）
我们总是尽力最小化“最终确定”每个需求（或一组需求）所需的迭代次数的相关要求）。 理想情况下，客户只需查看一次需求。
每当第一次审核结果不充分（经常发生），并且相关要求足够复杂，需要大量文本和/或插图时，我们确保客户没有从头开始重新阅读所有内容。 自上次修订版本以来所有重要更改/添加/删除均已突出显示。
当问题或要求仍处于未完成状态时，所有未解决的问题（主要是向客户提出的问题）都会嵌入到文档中并突出显示。 因此，只要客户有时间审查需求，他就不必召开会议并向团队征求问题； 相反，客户可以先打开任何未完成的文档，看看对他到底有什么期望，然后决定（对他来说）解决任何未决问题的最佳方式和时间。 有时，客户选择写一封电子邮件或直接在问题文档中添加评论。
我们尽力建立和维护官方领域词汇（即使它分散在文档中）。 最重要的是，我们实际上强迫客户坚持使用这些词汇。
注意：这是流程中最困难的部分之一，客户有时会试图“反抗”。 然而，最终每个人都同意这是尽可能高效地与客户进行宝贵会议的唯一方法。 如果您曾经参加过一小时的会议，其中花了 30 分钟只是为了让每个人（再次）达成共识，我相信您会很高兴拥有词汇量。
注意：只要有可能，官方词汇表中的任何更改都会反映在软件的下一个版本中。
有时，一个给定的问题可以通过多种方式解决，并且在不咨询客户的情况下，正确的选择并不明显。 这意味着将有一个“要求菜单”供客户选择。 我们记录这样的“菜单”，而不仅仅是最终选择的要求。
这可能看起来有争议，而且看起来像是不必要的开销。 然而，每当客户（通常是几周或几个月）突然提出诸如“我们到底为什么这样做而不是那样做？”之类的问题时，这种方法可以节省大量时间。 此外，使用正确的需求文档组织/格式来隐藏“被拒绝的分支”并不是什么大问题。 无聊但可行。 :-)
注意：在准备“需求清单”时，不要做得太过分，这一点非常重要。 太多的选择或太多的选择嵌套级别 - 下一次审核可能需要客户花费比实际需要更多的时间。 不用说，花在精心设计的分支上的时间可能完全被浪费了。 是的，在这里很难找到某种平衡（这在很大程度上取决于总是匆忙的客户提前思考两步或更多步骤并快速完成的能力）。 但是，我能说什么？ 如果你真的想做好你的工作，我相信一段时间后你会找到适当的平衡。 :-)
我们的客户是一个非常“视觉化”的人。 因此，每当我们讨论任何重要的用户界面元素时，屏幕模型（甚至轻量级原型）通常都非常有帮助。 有时可以实时节省时间！
注意：我们专门为客户制作屏幕模型，只是为了促进讨论。 它们也可能被开发人员使用，但它们绝不能替代用户界面规范！ 通常，有一些非常重要的 UI 细节以书面形式指定（现在 - 主要针对开发人员）。
我们很幸运能够拥有一位具有非常技术背景的客户。 因此，我们会毫不犹豫地使用 UML 图作为讨论辅助工具。 各种 UML 图 - 只要它们能帮助客户更快地进入正确的上下文并停留在那里。
当然，我说的是需求级 UML 图。 与实施级别无关。 我相信即使不是很懂技术的人迟早也能开始挖掘需求级的 UML 图； 您只需要有耐心并知道在图表上放置什么即可。
显然，这个过程的成本很大程度上取决于团队的分析和写作技能，当然还取决于您可以使用的工具。 我必须承认，在我们的例子中，这个过程似乎相当昂贵且缓慢。 但是，考虑到错误率非常低，“蒸汽功能”率也很低……我认为，从长远来看，我们获得了非常好的回报。
FWIW：根据 Joel 对软件产品的良好分类，该项目是一个“内部”项目。 因此，我们可以按照客户的能力提供敏捷性。 :-)
Although the concept of "product owner" is a littl ambiguous to me, I think I am working in very similar circumstances: the customer is extremely buzy and always is a bottleneck in developing requirements.
On the surface, what we try to do in this situation is quite obvious and seemingly simple: we try to make sure that the customer is involved in "read-only / talk-only" mode. No writing. Minimum reading. Mostly talking.
The devil, of course, is in details. So, here are some specifics about our process (in no particular order):
We often start from recording problem statements, which are the ultimate sources of requirements. In fact, sometimes a problem statement is all that we record initially, just to make sure it does not get lost.
NB: It is important to distinguish problem statements from requirements. Although a problem statement sometimes clearly implies some requirement, in general a single problem statement may yield a whole bunch of requirements (each having its own severity and priority); moreover, sometimes a given requirement my define a solution (usually just a partial one) to multiple problems.
One of the main reasons of recording problem statements (and this is very relevant to your question!) is that semantically they are somewhat "closer to the customer's skin" and more stable than requirements derived from them. I believe those problem statements make it much easier and quicker to put the customer into proper context whenever he has time to provide feedback to the development team.
We do record all the requirements (and back-track them to problem statements), regardless of when are we going to implement them. Priorities govern the order in which requirements get implemented. Of course, they also govern the order in which customer reviews unfinished requirements.
NB: A single fat document containing all requirements is an absolute no-no! All the requirements are placed in "problem tracking database", along with bug reports. (A bug is just a special case of a problem in our book.)
We always try to do our best to minimize the number of iterations necessary to "finalize" each requirement (or a group of related requirements). Ideally, a customer should have to review a requirement only once.
Whenever the first review turns out to be insufficient (happens all the time), and the requirement in question is complex enough to require a lot of text and/or illustrations, we make sure that the customer does not have to re-read everything from scratch. All the important changes/additions/deletions since the previous reviwed version are highlighted.
While a problem or requirement remains in an unfinished state, all the open issues (mostly questions to customer) are embedded into the document and highlighted. As a result, whenever the customer has time to review requirements, he does not have to call a meeting and solicit questions from the team; instead the customer can open any unfinished document first, see what exactly is expected from him, and then decide what's the best way and time (for him) to address any of the open issues. Sometimes the customer chooses to write a email or add a comment directly to the problem document.
We try our best to establish and maintain official domain vocabulary (even if it gets scattered across the documentation). Most importantly, we practically force the customer to stick to that vocabulary.
NB: This is one of the most difficult parts of the process, and customer tries to "rebel" from time to time. However, at the end of the day everybody agrees that it is the only way to make precious meetings with the customer as efficient as possible. If you ever attended one-hour meetings where 30 minutes were being spent just to get everybody on the same page (again), I'm sure you would appreciate having a vocabulary.
NB: Whenever possible, any changes in the official vocabulary get reflected in the very next release of the software.
Sometimes, a given problem can be solved in multiple ways, and the right choice is not obvious without consulting with the customer. It means that there will be a "menu of requirements" for the customer to pick from. We document such "menus", not just the finally chosen requirement.
This may seem controversial and look like an unnecessary overhead. However, this approach saves a lot of time whenever the customer (usually few weeks or months down the road) suddenly jumps in with a question like "why the heck did we do it this way and not that way?" Also, it is not such a big deal to hide "rejected branches" using proper organization/formatting of requirements documentation. Boring but doable. :-)
NB: When preparing "menus of requirements", it is very important not to overdo them. Too many choices or too many choice nesting levels - and the next review may require much more customer's time than really necessary. Needless to say that the time spent on elaborated branches may be totally wasted. Yes, it is difficult to find some balance here (it greatly depends on the always-in-a-hurry customer's ability to think two or more steps ahead and do it quickly). But, what can I say? If you really want to do your job well, I am sure that after some time you will find the right balance. :-)
Our customer is a very "visual" guy. Therefore, whenever we discuss any significant user interface elements, screen mockups (or even lightweight prototypes) often are extremely helpful. Real time savers sometimes!
NB: We do screen mockups exclusively for the customer, only in order to facilitate discussions. They may be used by developers too, but in no way do they substitute user interface specifications! More often than not, there are some very important UI details that get specified in writing (now - primarily for developers).
We are lucky enough to have a customer with a very technical background. So we do not hesitate to use UML diagrams as discussion aid. All kinds of UML diagrams - as long as they help customer to get into proper context quicker and stay there.
I am talking about requirements-level UML diagrams, of course. Not about implementation-level ones. I believe that even not very technical people can start digging requirements-level UML diagrams sooner or later; you just have to be patient and know what to put on a diagram.
Obviously, the cost of such process greatly depends on analytical and writing skills of the team, and of course on the tools that you have at your disposal. And I must admit that in our case this process appears to be quite expensive and slow. But, taking into account the very low rate of bugs and low rate of "vapor-features"... I think, in the long run, we get very good payback.
FWIW: According to Joel's nice classification of software products, this project is an "internal" one. So we can afford to be as agile as our customer can handle. :-)