Скотт Сельхорст написал замечательный пост у Тайнера Блейна о документации. Не технической документации, а информации, которую вы записываете, чтобы процесс разработки заработал. Под работой я не имею в виду только деятельность внутри команды разработчиков, но и остальной цепочки создания стоимости тоже.
Скотт говорит о роли документации в Agile разработке, но его мысли подходят к любой команде, приняла она Agile или нет. Agile создаёт большую чувствительность к этому вопросу, так как слишком много документации может нанести вред скорости команды. Конечно, отсутствие документации может навредить успеху команды:
Некоторое сотрудничество преходяще - общение происходит прямо сейчас и важно только сейчас. Другое общение является постоянным - сотрудничество происходит прямо сейчас, но мы должны позже помнить, о чём мы договорились и почему.
Пост Скотта - это великолепная иллюстрация того, что я говорил вчера по поводу того, что к требованиям нужно относиться как к разговорам, а не как к словарям. Требования - часть разговора, но много одинаковой информации, определяющей, что строить и почему, повторяется позже, когда вам нужно описать, что вы построили и почему. Например, персоны часто передаются друг другу между группами. Может быть, их создают в команде разработчиков, но люди в отделе продаж, маркетинга, поддержки и прочих группах выказывают большой интерес к этой информации.
Если вам нужна точная картина того, о чём я говорю, представьте себя проводящим тренинг среди продажников относительно нового продукта. В своём стремлении открыть новый рынок ваша компания запустила новый продукт, который необходим, по какой-то причине, для ведения бизнеса на этом рынке. Теперь ваша работа объяснить продавцам, за один час или меньше, всё, что им нужно знать о (1) новом рынке, (2) что отличает новый рынок от текущего, (3) как процесс покупки на этом новом рынке может отличаться, (4) почему новый рынок вообще заинтересован в вашей компании, (5) что новому рынку нужно от вас и, наконец, (6) что делает новый продукт.
Шансы на успех? Нулевые. Ладно, давайте дадим вам два часа. Вы всё ещё провалились. Это узкое окно возможностей не достаточно большое, чтобы вместить месяцы или годы предыстории, которая вошла в требования, дизайн и другие элементы, получившие кульминацию в релизе. Очевидно, необходимо закрепление в форме сайта, где продавцы могут получить дополнительную информацию, список рассылки о новом продукте и все типичные механизмы, используемые всеми типичными компаниями, чтобы попытаться увеличить степень готовности после релиза, но никогда не добиваются этого.
Решением, конечно, будет начать обмениваться информацией до релиза. В самом деле, необходима тщательная информационная стратегия, подогнанная так, чтобы продавцы были так готовы, как это по-человечески возможно, к моменту релиза. Даже самые богатые традиции устного творчества в компании не могут заменить записывание всего как основы этой информационной стратегии. Использовать то, что вы уже написали, - чертовски проще, чем перестать делать то, что вы делаете, чтобы вы могли написать с нуля Азбуку нового рынка и нового продукта.
Таким образом, никаких больших сюрпризов в том, что отчёты и панели являются популярной частью средств, поддерживающих инновационный процесс. В своём посте у Тайнера Блейна Скотт фокусируется на исполнительном спонсоре проекта как бенефициаре этого контента, но ясно, что в любой компании много других заинтересованных сторон тоже зависит от своевременной доставки этого контента.
Конечно, вы не можете обрушить словарную версию данных о требованиях на головы этих заинтересованных сторон и ожидать от них, чтобы они поняли всё это. В идеале вы не только подготовите версию этой информации заранее, но даже до этого примените некоторые методы или инструменты, которые облегчат этот процесс переформатирования. В действительности, цепь событий не будет проходить так гладко, но вы должны, по крайней мере, начать думать о том, какую записанную информацию вам понадобится передать задолго до её передачи.
