您可以编写完美的技术规范，但是如果您的开发人员在哭泣，这有什么用呢？

球形产品所有者正在一个遥远的星系中工作。他能流畅地在餐巾纸上写笔记，并默默地将其交给开发人员。很快，他收到了100％符合他期望的成品。即使此产品是具有二十一点和适应性的复杂跨平台服务。



在实践中这可能吗？



“不，兄弟，你不会骗我们的！灰发的老人说，职权范围应写得很长，而且要细致。“ TK是认真的！” -黄嘴的Juns呼应他们。一位经验丰富的业务分析师承认：“我的妻子是因为短期的技术任务而离开了我。”



让我不同意。



编写规范不一定要花费时间。而且，好的职权范围比坏的职权范围更容易写。当然，如果您知道一些技巧。我今天告诉你。然而，不是餐巾纸，我还是建议使用汇合。

怎么了？

我已经为开发人员编写了11年以上的任务。应用程序，游戏，Web服务，CRM系统，培训平台和其他产品都是基于它们而制作的。在这段时间里，我从编写200页的设计文档到几步简单的职权范围，从最初的编写工作中走了出来。当然，他填补了所有可能的颠簸。



年复一年，在不同的公司中，我观察了产品，游戏设计师和营销人员如何设定任务。这些任务的各种“功能”的后果是什么？冲刺的开始如何一周转移一次，弄清楚客户到底想要什么。惊慌失措的是，他们修复了刚注入产品中的功能。由于案例不明，应用得分下降的速度有多快。销售如何下降以及忠实的用户离开。当开发人员不得不修补有问题的任务时，他们将如何精疲力尽。



我给人的印象是，太多负责开发任务的人不知道如何做好。而且传统知识本身的质量问题不在人们的关注范围之内：他们说，他们编写了一项任务和规范，他们不会弄清楚，还是什么？而且，总是有更多有趣的事情要做：讨论新的假设，开会，喝咖啡休息时间。结果，所有人，客户，开发人员和业务都会遭受损失。

编写TK时有两个极端

您正在使用的产品越大，错误的成本就越高，技术规范的质量也就越重要（谢谢！上限！）。因此，如果您要做的事情比登录页面更严重，那么这两个选项都不适合。在大型且具有竞争力的产品中，编写TOR时应快速，明智，坚如磐石。让我们看看如何到达那里。

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. 传统知识应取悦团队领导，
   
   这意味着不需要任何特殊的仪式和解释就可以转移到开发中。例如，如果某产品已经完成了技术任务，并且在办公室里被公共汽车撞到了那里，那么这不应妨碍他以最佳方式进行技术任务。

满足所有这些要求难吗？一点也不。



相反，如果您记住它们，您将无法编写坦率的不良TK。因为所有这些要求都归结为一件事-照顾与该传统知识互动的人。

我的TK格式

这种格式是用户故事+完成的定义的相当宽松的组合。



它的出现是经过多年发展的结果：每次我看到一个系统性问题时，都会更改我的传统知识的格式，以免将来出现此问题。结果是简洁而视觉上干净的格式，甚至六月也可以轻松拾取。另外，它满足上述要求。



这就是我的传统知识中典型的故事：







无论我们开发的产品有多大和复杂，任何传统知识都将包含这些简单的故事（它们的数量只会不断增加）。





重要提示：故事不应描述太大的功能（例如，多个屏幕）或太大（例如，一个按钮）。通常，一个故事就是一种功能或产品技工。例如，一个故事可以完全描述新用户的注册。通常，要为新着陆页的布局设置一项任务，对我来说一个故事就足够了。



如果技术规范很大且很重要，那么在文章列表之前，我先简要介绍一下：我们为什么这样做以及我们希望获得什么结果。只是这样，开发人员才有一个广阔的前景。

通常，结果是这样的：

例

好的，要了解其工作原理-让我们将产品分解为这样的故事。例如，我们决定制作一个名为“ neural boot”的应用程序。在其中，神经网络将与没有一天（也没有朋友）的产品进行亲密对话。



为简单起见，我们假设我们已经有一个训练有素的神经网络，并且需要以应用程序的形式为其建立接口。



传统知识可能由以下几行组成：

1. 用户授权
2. 用户资料
3. 与神经靴的通讯屏幕
4. 屏幕“ Neuroboot目录”
5. 个人资料和设置屏幕
6. 付款弹出
7. 分析连接

仍然需要绘制每个故事（以上述格式）并将其发送给开发人员。我告诉过你这很容易。

---

棘手的生活黑客

每天都有许多技术可以帮助我开发产品。以下是与撰写职权范围有关的内容。

生活技巧＃1：反复进行详细说明

现在，我根本不写技术规范-它们本身在后台出现在工作过程中。当出现新任务时，我立即想出：要执行此操作需要哪些子任务？然后，我将每个子任务固定为故事格式（仅名称，详细信息会在后面）。



因此，我立即准备了一个广义的职权范围。它仅是在尽可能详细地描述故事的范围内，以便可以为开发分配技术。



详细信息也包含在背景中：在研究和思考细节时，我立即在相应的行内做笔记。代替设计，我插入NinjaMock的原型。



这种方法大大加快了工作速度。另外，它使您不会错过全局，也不会提前挖掘细节。

生活技巧＃2：不适用于精灵

有一部如此古老的电影，精灵以最糟糕的方式实现了愿望。



当然，理智的开发人员不会专门寻找伤害的机会。但是有时候人们不在乎他们在做什么。然后他们按“原样”完成任务，而不是真正研究为什么需要这样做。周期性地，这将导致文件变大和变小。好吧，是的，生产已经停产了……但是没有人在任务中写过需要检查的内容-这样的实现是否会破坏其他一切。



我不会谈论外包，但是这种方法在产品中是不可接受的。一个好的开发商正在建造一座寺庙，而不仅仅是砌砖。也就是说，他看到了全局并深入研究正在发生的事情。这样的人经常提供替代解决方案，并警告自己的陷阱。



因此，如果您希望以最佳方式完成传统知识，那么有时您需要改善的不是传统知识，而是团队中的开发文化。通常，这是PM的任务，但是产品也会影响情况。特别是在团队信任他的情况下（例如，由于他精心设计的技术规范）。

Lifehack＃3：将传统知识与文档分开

职权范围回答了“需要做什么？”的问题。还有文档-问题“如何完成/如何工作？” TK是在任务执行之前编写的，文档是在执行任务之前编写的。



如果需要重新布置机柜，我将本着“从这里重新布置->这里”的精神编写任务。但是我不会绘制有衣柜的房屋的建筑平面图。



有时，有人认为应该编写传统知识，以便同时将其作为文档。这是一个有害的理论。完整的文档仍然无法使用，因为事先不知道如何确切地执行职责范围。另外，开发人员需要回旋的空间，而文档没有提供这些空间。而最主要的是写这样的TK的时间要长很多倍，结果会很麻烦。



有不同的产品和不同的创业公司。完全没有文档的人也可以做。但是，如果您仍然需要文档，请聘请一名将在实施后详细描述该功能的人员。您不需要特殊技能来描述现有功能，但是您将为熟练的员工（产品开发人员和开发人员）节省时间和精力。

生活技巧＃4：学习编程

纯粹凭经验观察：知道如何编程的产品在制定任务方面更好。而且，没有必要成为高级后端操作员，掌握任何一种编程语言并理解算法思想的本质就足够了。



有一次，我仍然无法在chthonic Spectrum上进行编码，在我的学生时代，我什至不得不用Assembler编写驱动程序。也就是说，我熟悉第一手编程-这当然有助于与开发人员一起寻找通用语言。

生活技巧＃5：多想一点，多写一点

最大的问题总是出现在客户自己不完全理解的任务上。例如，他需要在管理区域中创建一个新报告，但是他不太了解如何形成该报告。就像，程序员会弄清楚的。不，那不是那样的。



编写正确解决问题的唯一方法是理解。理想情况下，如果您知道如何编程，请对问题有足够的了解，以便您可以自己解决。



但是，当您弄清楚了这一点之后，就无需转储在TK中找到的所有信息。只是对任务的深刻理解，使您可以丢弃不必要的事情并只写重要的事情。

---

PS TK是一种手段，而非目的。因此，有时最好的传统知识就是它的缺失。有一天，我将告诉您我是如何推出几款完全没有任何技术规范的产品的。



PPS如果编写时具有自己的职权范围格式或生活技巧-请在评论中分享。