Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2010-09-20 03:15    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

От белого листа к красной ленточке

Проблемы
Откуда берутся проблемы
Краткое повторение базовых принципов
   Сквозная линия напряжения
   Правило шнурка
   Кривая накопления дефектов и принцип обратной связи
   Цикл управления результатом
      Работа, как управление
      Объект управления
      Состояние объекта управления
      Получение требований и оценка текущего состояния
      Наблюдение и воздействие
Пошаговые инструкции
   Как начать работу
      Напишите введение
         Назначение
         Область применения
         Источники информации
         Что является контекстом
         обзор артефакта
         требования к качеству артефакта
         методы и этапность работы
      Напишите два введения
      И что мы получили?
Как закончить работу
   Внутренний контроль
   Правила поставки
      Должно быть
      Необходимо уйти от
Что делать между началом и завершением
   Управление информацией
   Рабочая разметка артефакта
   Метамодель
   Двухпроходный метод
   Управление неопределенностью
   Неизвестная задача
Заключение

В этой статье написано, как пройти путь от "белого листа" до поставки результата, оформленного и "перевязанного красной ленточкой" - как начать и закончить работу по созданию аналитического артефакта. Статья, кроме аналитиков и менеджеров, может быть полезна тем, чья работа включает создание документов. Для создания других результатов изложенные принципы подходят или полностью или в большей своей части.

Две самых типичных проблемы начинающих и продолжающих аналитиков и менеджеров:
- боязнь белого листа;
- страх перед завершением работы, что ведет к отсутствию четкой фиксации результата.

Что с этим делать, какие еще бывают проблемы и как их обойти читайте ниже.

Тем, кто читал статью Создание эффективной инженерной документации может показаться, что написанное здесь уже где-то было.

Это отчасти так. То, что я рассказываю здесь кратко перечисляет принципы планирования и создания документа или пакета документов. При этом здесь есть и не рассмотренные в моих статьях раньше принципы, которые касаются правил планирования и управления работой, требованиями и неопределенностью, а так же правил поставки.

Фокус этой статьи на том, как получить сам результат.

Есть и другие аспекты, например, как поставить и выдержать сроки как правильно принять обязательства по работе, что измерять для управления работой, что делать с рисками. Надеюсь все это я тоже в ближайшее время напишу.

Проблемы  ^

По сути, как и написано выше, главных проблем две.

Вот перед нами белый лист и в голове несколько ключевых слов о том, что нужно сделать - мы должны начать писать, но что писать - мы пока не знаем или не уверены. И в таком состоянии мы можем провести несколько часов и даже дней. Если время есть - это не страшно. Но если время поджимает - необходим более продуктивный способ создания результата.

Если мы не выполнили некоторые установочные действия на старте (о них дальше в этой статье), с самого начала работа начинает катиться кувырком.

И через некотороое время у нас есть документ или диаграмма или другой артефакт, который почти готов. И в этом "почти" - вся проблема. Это никогда не закончится. Мы будем потихонечку вносить в него исправления, пока не испортим окончательно или не закончится время и от нас потребуют результат. Отправляя документ мы не будем уверены, то ли мы сделали или не то, или не совсем то.

Эта неуверенность для начинающих специалистов - одна из самых частых причин срыва сроков или полного отсутствия результатов.

В итоге мы имеем проблемы, которых можно было бы избежать. И сейчас мы обсудим - откуда берутся такие проблемы и что надо было делать.

Откуда берутся проблемы  ^

Любые проблемы создаются нарушением тех или иных базовых принципов. Ключевым принципом любой работы является учет "правила шнурка" и правила "сквозной линии напряжения". Второй ключевой принцип работы - наличие обратной связи по качеству результата и возможность в нескольких циклах работы-контроля довести качество до требуемого. Оба принципа нарушаются одновременно с более фундаментальными принципами (из которых они вытекают). В нашем случае (не)действуют принципы построения системы управления.

Синдром белого листа вызывается отсутствием или нечеткостью требований к результату и отсутствием четкости в исходных данных.

Страх перед поставкой вызван отсутствием требований к результату и отсутствием обратной связи.

Проблемы начала и завершения в середине усугубляются накладками и запредельными издержками в схеме управления результатом.

Краткое повторение базовых принципов  ^

Те, кто хочет быстрее приступить к изучению контрольного списка, могут эту главу пролистать. Остальным я попытаюсь объяснить, откуда берется приводимые немного ниже списки рецептов.

Сквозная линия напряжения  ^

Правило сквозной линии напряжения уже обсуждалось, например, тут.

Правило шнурка  ^

Правило шнурка (или принцип клиенториентированности) я сейчас здесь сформулирую: чем длиннее цепочка работ (что соответствует сложным задачам), тем более предпочтителен вытягивающий метод - работа от требований и ожиданий потребителя (а не от своих представлений, как правильно/как должно быть).

Метафора шнурка очень хорошо иллюстрирует это правило. Попробуйте взять шнурок за конец и протолкнуть его противоположный конец в петлю в ботинке. Максимум, что вы получите - это скомканный шнурок. Так же и длинная цепочка работ нуждается в вытягивании, качественно толкать ее невозможно.

Толкать удобно только что-то короткое (ясное/маленькое) или твердое (жестко стандартизированное), так же и с работами - маленькие монолитные, часто повторяемые, а значит, ясные всем работы можно и толкать (работать без выявления ожиданий и требований, так как они давно уже выявлены, согласованы и зафиксированы в общем контексте).

Стандартизированные работы тоже можно толкать. При этом остается риск протолкнуть не туда, куда хотелось - возьмите вместо шнурка длинную тяжелую спицу за кончик, теперь шанс продеть ее в петлю повысился, но это все еще не так удобно, как тянуть - свободный конец так и норовит ткнуться не туда маленькие дрожания пальцев рождают большие колебания на свободном конце спицы.

Кривая накопления дефектов и принцип обратной связи  ^

Накопление дефектов вдоль цепи работ - это и есть наш случай со спицей.

Принцип прост: в отсутствие обратной связи на длинной цепочке или сети работ качество в среднем падает экспоненциально и быстрее.

Кто верит мне на слово, может пропустить врезку, остальным я сейчас попробую обосновать этот принцип.

Допустим у нас цепочка работ. И качество выхода определено, как произведение качества входа на качество работы. Это можно предполагать, если трактовать качество входов и выходов, как вероятность обнаружить не дефектный элемент, ткнув пальцем в произвольное место поставки, а качество работ, как вероятность не нанести дефект элементу результата при условии, что элементы входов, из которых он получен не дефектны. Подразумевается, что результат состоит из элементов, каждый из которых в любой момент либо годен либо дефектен.

Чтобы обосновать все это более четко, нужно включать аппарат теории вероятности, закладывать модель работы, результата и делать аккуратный вывод. Но сейчас нас интересует практика, по этому вывод я пропускаю.



Нам интересно вот что: если принять качество (то есть вероятность ненанесения дефектов) всех работ за константу, то качество поставки на выходе из цепочки падает, как (качество работы) в степени (число звеньев в цепочке), то есть - экспоненциально.

Но это еще не все: в проекте работы выстроены не в цепочку, а в сеть. Может показаться, что это хорошо, так как сеть из N узлов всегда имеет кратчайший путь, который короче числа узлов. Но с другой стороны дефекты из одного узла могут ухудшать следующие результаты несколько раз.

Вот пример сети из 8 узлов: Заказчик, Аналитик, Архитектор, Конструктор, Программисты, Тестировщики, Технический писатель, Сборка результата и поставка:



Связь входов и выходов узла такая же - произведение качества всех входов на качество работы. Итог расчетов более, чем печален - на выходе мы получаем единицы процентов даже при качестве работы - 90%. Чтобы удержать качество результата в пределах 90% необходимо обеспечивать в каждом узле качество работ в 99,7%. Чтобы выйти хотя-бы с 50% качества результата, работы необходимо удерживать работы на уровне качества в 97,8%.



В жизни все немного сложнее и представленная модель лишь отражает факт накопления дефектов, но не всегда может дать адекватную реальности количественную картину. Однако наш опыт показывает, что накопление дефектов - это факт, с которым невозможно не считаться. И вот здесь можно увидеть тому подтверждение с совершенно неожиданной стороны.

Принцип накопления дефектов является причиной провала водопадного жизненного цикла во многих проектах.

И практически для нас это означает, что хорошая вещь получается с третьего раза, то есть сложные работы должны выполняться за несколько итераций выдачи результата.

Проблемой многих начинающих специалистов является то, что вместо выдачи соглаованного в нескольких циклах результата в установленный срок (или позже) они выдают первую редакцию, в неустановленном качестве. После этого необходимость доделок влечет за собой сдвиги сроков и перерсход времени на работу относительно запланированного.

При правильной организации работы первая итерация заказчивается поставкой первой редакции артефакта, возможно, с прохождением внутреннего контроля качества.

Однако лучшим контролем качества является беспроблемное использование артефакта и производных от него артефактов в дальнейших работах. По этому следующие итерации доработки артефакта вызываются обратной связью со следующих участков работы - как смежных, так и находящихся дальше по сети работ.

Обсужденные выше 3 итерации на выпуск аналитического артефакта (условно) подтверждаются моей статистикой - в среднем это минимально достаточное число редакций документа перед утверждением.

Условия таковы: группа согласующих не велика (единицы человек), нет сильных конфликтов интересов вокруг принимаемых решений, согласующие честно отрабатывают свою роль, нет системных проблем и с входными данными на эту стадию анализа (почти) все в порядке.

Тогда мы имеем такие фазы:
- сбор исходных данных, анализ, выпуск первой редакции и списка открытых вопросов и предположений;
- обсуждение в группе, снятие вопросов, подтверждение предположений, выпуск второй редакции;
- снятие оставшихся мелких вопросов, финальная вычитка, поставка редакции.

При работе с бОльшим количеством людей или с официальными/юридическими документами или со сложными документами большого объема и большим числом решений число итераций будет бльше.

Если решения ясны всем и быстро приняты группой, их остается только задокументировать (это первая редакция, вычитка и вторая редакция) - то есть менее 2х циклов получается только, если повезет написать принятые решения без замечаний с первого раза.

Вопросы о том, как бороться с согласующими, если они не уделяют внимания, где вообще их взять что делать с конфликтами и т.п. находятся за рамками этой статьи. Но написанные ниже рецепты частично решают и эти проблемы.

В итоге нам надо запомнить одно: обратную связь нужно обеспечить, а работа должна быть итерационной.

Цикл управления результатом  ^

Работа, как управление  ^

Если учесть, что выполнение работы по созданию артефакта можно представить, как управление определенной информацией: фактами, решениями, то становится ясно, где подсмотреть полный контрольный список источников проблем с работой. Вот схема системы управления, одинаковая для любого управления любым объектом, как говорит нам теория управления:

Что мы видим:
1. Система управления получает целевое значение для состояния управляемого объекта;
2. Система управления измеряет (наблюдает) текущее (или входное - начальное) состояние объекта;
3. Система управления вычисляет разницу между целевым состоянием и текущим;
4. Система управления преобразовывает разницу в воздействие на объект;
5. цикл повторяется.

Если в этой схеме есть неполадки, мы ничем не управляем.

Многим это кажется слишком простым, чтобы быть умным (а значит уважаемым) и слишком теоретическим для того, чтобы всерьез делать практические выводы. Но все же давайте посмотрим внимательно, как эта схема ложится на нашу работу.

Объект управления  ^

Если посмотреть внимательно, то мы увидим, что под управлением в аналитических работах находится информация: факты и решения (технические, методические, организационные, управленческие и т.п.). Сначала есть мало информации в управляемом состоянии и большая неопределенность, после нашей работы есть много информации в управляемом состоянии и малая неопределенность с известными границами.

Что такое управляемое состояние - это состояние, в котором мы можем наблюдать и воздействовать.

Состояние объекта управления  ^

Так как мы управляем информацией, то атрибуты, присущие ей и задают состояние. Наиболее интересные для нас:
- носитель: человек, документ, база данных;
- источник появления: человек, измерение, система, деятельность;
- степень наличия: не знаем, что не знаем; знаем, что не знаем - задан вопрос; знаем ответ;
- качество: детализация/точность, достоверность, адекватность реальности, актуальность;
- стоимость и время доступа;
- стоимость и время изменения;
- дублирование хранения: не храним, храним в одном месте, храним во многих местах, храним во многих местах с установленным первоисточником;
- состояние канала получения: обрыв, установлен канал, канал плавает - каждый раз получаем по разному;
- степень децентрализации появления: порождаем 1 раз (одно и то же), порождаем много раз/в разных местах.





Что важно отметить.

Во-первых, нельзя путать между собой хранение, извлечение, передачу и порождением информации - это разные процессы, каждый из которых имеет свои характеристики и законы.

Во-вторых, отсутствие информации имеет два состояния: есть вопрос (заданы границы неопределенности) и нет вопроса - неопределенность в этой области вне контроля.

И в третьих, человек - это особый случай, так как он может и хранить и порождать и передавать информацию. При этом бывает трудно различить эти режимы. А глядя снаружи на человека (а иногда и в беседе) практически невозможно установить границы, идентификацию, качество и степень наличия у него той или иной информации.

Получение требований и оценка текущего состояния  ^

Получение требований (или задание целевого значения) переводит информацию из степени наличия "не знаем, что не знаем" в "вопрос" - это первый шаг к результату.

Обзор текущего сосояния (что есть сейчас) с пересчетом источников хранения/порождения информации, каналов коммуникации и их состояния - это второй шаг к управлению результатом.

Следующие шаги будут связаны со сближением текущего состояния с требуемым.

Наблюдение и воздействие  ^

Информация управляема при следующих условиях:
- границы и качество информации под управлением моут быть установлены;
- поиск и доступ имеет приемлемую стоимость, то есть:
-- обеспечена однозначная идентификация источников, мест хранения, каналов получения;
-- способы получения дешевы (канал установлен и работает хорошо);
-- обеспечено отсутствие дублирования при хранении или выделен первоисточник;
-- при порождении информации обеспечена централизация появления (то есть одно решение принимаем по возможности один раз);
- изменение нужной нам информации дешево:
-- носитель идентифицирован, легко доступен для изменения информации;

Важно понимать, что залогом успеха всех аналитических работ является повышение управляемости информации: перевод ее в удобоваримый вид из степени наличия "не знаем, что не знаем"/"вопрос" или из плохо управляемого состояния с дублированием хранения (или из голов людей), децентрализацией порождения, низким качеством, оборванными или плавающими каналами коммуникации.

На основе сравнения жеаемого с действительным мы можем планировать циклы воздействия:
- извлечение информации и сохранение без дублирования;
- порождение (централизованное принятие решений);
- повышение качества;
- понижение стоимости доступа;
- понижение/ограничение неопределенности.

Пошаговые инструкции  ^

Ниже я рассказываю, как можно пройти путь от белого листа до поставки документа - на какие вопросы надо для себя ответить и что сделать.

В качестве примеров используется вариант, когда мы делаем документ, храним на файловом сервере, поставляем сообщением по электронной почте.

Все те же принципы годятся при работе с моделью, хранении в специализированном элемкронном архиве и поставке через подвеску результата в систему учета задач со сменой статуса задач. В некоторых случаях я буду особо отмечать варианты применения технических средств.

Важно так же понимать, что при нарушении некоторых шагов конец света может не наступить. Но если не отвечать себе на достаточное количество вопросов, которые обсуждаются ниже, то можно получить большие проблемы в работе. То есть все шаги требуют творческого осмысления: с одной стороны, делать так, как написано может быть непривычно/неудобно/долго/дорого, с другой - отказываясь от некоторых занудных (и с виду ненужных) подготовительных действий мы можем заложить себе проблемы в будущем. Фокус здесь в том, что дефекты в организации работы копятся незаметно. Пока не накопится критическая масса, работа будет продвигаться. И наша задача, допуская отступления от "чистоты методологии", все же довести работу до конца раньше, чем она развалится.

Как начать работу  ^

Напишите введение  ^

Даже если не просят.

Напишите введение. Даже, если создаваемый артефакт не должен иметь такого раздела, даже, если это диаграмма или пачка разнородных документов, и даже, если вы пока не знаете, сколько будет артефактов и каких - все равно откройте notepad.exe и напишите введение.

При поставке результата, если артефакт не подразумевает наличие введения, его можно легко удалить или не присоединять файл с введением к комплекту поставки.

Что имеется ввиду, то есть что писать во введении?

Структура введения:
- назначение
- область применения
- источники информации
- что является контекстом
- привести обзор артефакта
- указать требования к качеству артефакта (это в половине случаев придется удалять, но пригодится нам при поставке)
- методы и этапность работы (это обычно всегда потом надо будет удалить, но сейчас пригодится)

Назначение  ^

В предыдущей статье по документированию (вот здесь) вопрос введения обсуждался более подробно. И дальше здесь я напишу только краткую выжимку и то, чего там не было.

Итак, отвечаемые артефактом вопросы необходимо сформулировать настолько конкретно, насколько это возможно. Сформулировать точные критерии конкретности вопросов достаточно сложно. Но здесь и далее действует ключевой принцип: если есть проблемы и мы не знаем, в чем, то надо вернуться на предыдущие шаги и улучшить их. Блоки введения должны иметь такое качество, чтобы легко было отвечать на вопросы, формирующие следующие блоки.

Второй критерий качественно сформулированного назначения артефакта - это мнение потребителей:
- потребители сказали, что: "да, это наши вопросы!";
- порочитав введение, людям удается понять, содержит ли документ нужную им информацию.

Область применения  ^

Чтобы определить, область применения, мы должны знать:
- когда конкретно (даты или ориентировочные даты) в какой конкретно работе будет использоваться артефакт;
- кто (указать поголовно) будет использовать наш артефакт;
- как наш артефакт будет использоваться (и должны уметь это показать на практике).

При этом мы должны понимать, что область применения артефакта может иметь две части:
- после создания - предоставлять информацию: принятые решения и факты;
- в ходе создания - организовать процесс принятия решений. Некоторые артефакты не должны доходить до чистовика - их назначение организовать процесс обработки информации и умереть.

Источники информации  ^

Источники информации должны быть пересчитаны поголовно (люди) и с точностью до ссылок (документы и другие носители). Причем, для каждого конкретного источника необходимо указать: какая информация из/от него нам нужна в работе.

Очень часто я вижу, как люди морщатся при словах "реестр исходных данных/источников информации". Это лень/долго и т.п.

Так вот: те же слова - если это долго, то у вас нет исходных данных.

Исходные данные, которые находятся в управляемом состоянии должны подниматься за секунды. А если вы не в состоянии их даже перечислить, то предыдущее требование не выполнимо. Каждый раз, работая над документом, вы будете обращаться к исходным данным. Если это будет занимать минуты - работа остановится.

Но на самом деле вам придется загрузить в голову всю необходимую исходную информацию - большую часть вы забудете, но остальное надежно заблокирует возможность думать и помнить что-то еще кроме исходных данных.

Каждй раз, вспоминая, вы будете задумываться, затем вы будете не уверены, затем в половине случаев полезете искать источник, начнете нервничать - это надежно выведет вас из потока, чтобы вернуть мысль опять уйдет время - это будет пока агония, которая, после растраты существенных нервных усилий перерастет в проектный паралич.

С другой стороны, при конструктивном рецензировании, люди смогут проверить ваши выводы, обратившись к источникам. В худшем случае, наличие внушительного списка исходных данных (причем не из серии "подшивка журнала Cosmopolitan за 2009 год", а ссылки на протоколы совещаний, письма проектной переписки, предыдущие проектные документы, нормативные акты и т.п.) у многих желающих с вами спорить на пустом месте сам собой умерится пыл.

Что является контекстом  ^

Важным фактом, который необходимо учитывать при написании любых доументов является то, что абсолютной истины не существует. Все, что мы пишем толкуется читателями исходя из того контекста, который у них есть.

По этому нам абсолютно необходимо представлять себе читателей и контекст: как они поймут написанное. Для инженерных документов это особенно важно, так как, в отличие от научных трудов, учебников и энциклопедий
- они должны быть дешевыми;
- они направлены на узкую аудиторию (проектная группа и ближайшее окружение);
- при этом они должны быть предельно четкими в передаче фактов и решений.

Что можно сделать при фиксации контекста:
- указать проект или временные границы, деятельность и людей, для которых предназначен документ;
- указать связанные документы, где есть еще подробности;
- сослаться на глоссарий, устав, концепцию, план и другие опорные документы проекта;
- приложить раздел "термины, сокращения и определения";

Встречая затруднения при ревью, вызванные несовмещенным контекстом у нас будет возможность не спорить, а зафиксировать видение, справедливое только в данном проекте - это путь к уходу от методико-терминологических holy wars.

обзор артефакта  ^

Теперь, чтобы было предельно ясно, что куда писать, надо перечислить разделы артефакта и написать, какие решения и факты мы будем туда класть.

Почему это важно?

По тому, что это первый шаг к оценке объема результата.

Когда у вас есть множество сырых исходных данных, вы можете копи-пастом складывать их по разделам. Так же можно будет раскидывать тезисы, которые позже обрастут аргкментацией. Разрозненные факты, которые позже дополнятся так же удастся быстро рассортировать.

В конце концов - это вторая сторона в матрице трассировке источники-раздел, если вы будете применять такую трассировку на начальном этапе анализа.

Читатель, и в первую очередь, рецензент сможет ориентироваться в вашем документе. Особенно, если разные разделы будут резензировать и подписывать разные люди.

Я не рассматриваю шаги по созданию схемы и шаблона документа или соглашения о моделировании для модели среди установочных действий (но ниже мы еще встретимся с ними). Первое описано в предыдущей статье Создание эффективной инженерной документации , а второе надеюсь еще написать. Но отмечаю, что их тоже можно бы выполнить, особенно, если есть затруднения с дальнейшим продвижением.

Перечень разделов документа - это минимум, от чего можно оценить разработку артефакта с точностью до часа. В сложных случаях придется идти дальше и делать схему и шаблон и/или соглашение о моделировании, чтобы понять порядок объема артефакта с точностью до числа ячеек таблиц, абзацев и элементов на диаграмме.

Чтобы снять риски согласования при рецензентах и согласующих вне проектной группы (то есть, не разделяющих до конца цели проекта), начинать согласование надо с шаблона документа и соглашения о моделировании (то есть еще во время планирования работ) - это хорошее время для установления контакта и снятия информационного шока при выдаче на согласование (например) шестисотстраничного документа, или такой же пачки диаграмм с непонятной семантикой.

требования к качеству артефакта  ^

Этот блок в чистовике можно удалить, но до момента поставки он жизненно важен. Мы должны точно ответить на вопрос, как разграничиваются состояния артефакта в целом и данной редакции в частности: когда артефакт готов к поставке, а когда еще нет.

Это проще сказать, чем сделать, но вот некоторые наводки:
- артефакт достаточен для (выполнения работ);
- артефакт отвечает на вопросы (перечень) и (ФИО, ФИО, ...) подтвердили это;
- перечень требований произвольного содержания "артефакт должен";

Задерживаться здесь не стоит, если нечего писать - едем дальше. Но при возникновении проблем в дальнейшей работе возвращаемся сюда и доформулируем требования.

При этом как минимум к моменту поставки перечень ключевых требований должен быть, иначе мы не определим момент, когда можно поставлять. Это значит, что как только решили поставлять, можно вернуться и записать, каким критериям сейчас отвечает наш артефакт.

методы и этапность работы  ^

Раздел бывает полезен, когда не до конца ясны шаги. При этом если кто-то из коллег занимается контролем качества, им можно ненавязчиво предложить прорецензировать и этапы работы - может, они и предложат что-то полезное.

С другой стороны иметь перед глазами план тоже полезно. Если требуются оценки с точностью до часов, без плана не обойтись.

Напишите два введения  ^

Бывает так, что артефакт работает и в процессе создания и после.

В этом случае часто мы имеем несколько поставок очередной редакции с опрделенными целями: согласовать введение и шаблон, донести до группы имеющуюся информацию и открытые вопросы, представить варианты и предположения, собрать и представить все мнения, собрать все замечания, наконец, зафиксировать решения и затем хранить их.

Фокус тут в том, что у каждой редакции свое назначение и уровень качества. В этом случае есть два варианта:
1. указывать назначение и область применения финальной редакции и текущей редакции: "Документ предназначен для .... Данная редакция предназначена для ...".
2. Указать назначение всех планируемых редакций, включая финальную - это можно сделать в таблице с колонками "номер редакции", "назначение", "обасть применения", "уровень качества" (можете добавить сюда все колонки, которые вам нужны, минимальный базовый список - перечень разделов введения).

Предупреждая вопрос "из зала" о том, что это же много писать - это долго, сразу отмечу: если вы не можете быстро и качественно написать введение - внутри документа будет еще хуже. Почему - я намекаю в следующем разделе.

Указание двойного/множественного назначения документа дает рецензентам и читателям возможность сконцентрироваться на том, на чем необходимо сейчас сконцентрироваться. Это позволяет избежать негатива при согласовании и застречания в вопросах оформления тогда, когда еще не проработаны концептуальные содержательные вопросы.

Второй риск, от которого страхует двойное введение - это отправка черновика под видом чистовика. В лючшем случае коллеги могут перепутать. В худшем случае встречается выдача чужих черновиков зв свои чистовики или выдача чужих черновиков за их же чистовики. И важно тут не то, что у вас украли документ или пытались попортить репутацию, а то, что коллега, удаляющий из документа второе введение (иначе это нельзя выдать за чистовик), берет на себя полную ответственность за качество и решения в документе в их текущем виде. Вы поставляли не то, что он отправлял под видом чистовика и включали disclaimer - это всегда можно доказать.

И что мы получили?  ^

Кто-то из читателей мог подумать, что описанные шаги и их результат подозрительно напоминают проектное задание или техническое задание, смотря как кто называет.

Так и есть. Основная идея метода в том, чтобы иметь проектное задание на аналитические работы прямо в разрабатываемом артефакте.

Вот здесь есть замечательный материал про техническое задание. Его можно использовать чтобы получить новые идеи для разработки введения документа, то есть, для планирования работы.

Это имеет свои причины и дает ряд преимуществ.

1. аналитические работы всегда начинаются с высокой неопределенностью, то есть, задание в начале может сильно изменяться. И мы можем или иметь расплывчатые формулировки в задании или кропотливо переписывать задание раз за разом. Первое не подходит, а второе проще, если задание находится как можно ближе к самому артефакту. В случае с документом - это выходит без проблем.

2. Если ваши коллеги и менеджеры, не привыкли обременять себя проектными заданиями, можно, никого не смущая, спокойно извлекать все выгоды из планирвания работ. И даже ненавязчиво принуждать коллег рецензировать ваши планы вместе с вашими результатами.

3. Конкретная фиксация планов и результатов дает возможность не препираться при очном согласовании: всем одинаково ясно, чего ожидать от данной редакции, а чего не ожидать. А кто не умеет читать - научится, после первого недоразумения и тычка носом во введение к обсуждаемому артефакту.

4. Как уже было сказано, основные два плюса такого подхода:
- вы знаете, что делать с белым листом;
- вы знаете, когда остановить работу.

Как закончить работу  ^

Внутренний контроль  ^

Если вы написали хорошее введение и включили в него требования к результату (они же - критерии поставки), то всегда ясны две вещи:
- чего не хватает для поставки?
- готов ли документ к поставке, и если не готов, то на сколько?

Если документ готов или пришло время, то вы делаете одно из трех: поставляете документ, поставляете документ с указанием отклонений (дефектов), просите еще время, указывая какие дефекты остались в документе и сколько времени надо на доделку.

Проектная документация редко доходит до чистовика вся. Если работа итерационная, то на какой-то редакции фиксируется документ с указанием известных дефектов, а чуть позже документ или до/перерабатывается или вообще устаревает.

Так как документы можно полировать бесконечно и это, обычно, слишком дорого, то критерии остановки должны задавать потребители.

Если вы не знаете, готов ли документ, то есть два варианта: вернуться дописать введение или выдать редакцию на рецензирование потребителям, чтобы они определили, что следует доделать.

Правила поставки  ^

Итак, вы приняли реешние поставлять артефакт.

Во-первых, что такое "поставлять"?

Мы должны выдать осязаемый результат, идентифицированный, находящийся под управлением, то есть имеющий установленный объем, качество и область применения.

Учет поставок - одна из ключевых работ при управлении проектом, так как все результаты проекта обязаны находиться в управляемом состоянии.

План коммуникаций, план управления или другие нормативные документы проекта должны задавать правила поставок.

При этом если правил нет, то вот минимум, без которого эффективной работы быть не может.

Должно быть  ^

1. Поставка идентифицирована, то есть на нее можно однозначно сослаться (сейчас и в будущем).
2. Элементы поставки идентифицированы.
3. Поэлементно установлено качество и объем:
- или это обсуждалось и записывалось раньше;
- или требования приложены к поставке.
4. Поэлементно указаны отклонения от требуемых качества и объема;
5. Поэлементно указано, кто и что может/должен с этим делать;
6. Обеспечено оповещение получателей;
7. Подтвержден "технический" прием на той стороне (например, звонок вдогонку письму);
8. Очень желательно, чтобы любой элемент любой совершенной поставки можно было предъявить за секунды - это заставляет нас думать о проектном архиве и правилах управления документами/артефактами. В худшем случае - это должно занимать минуты.

Необходимо уйти от  ^

1. Ссылка на файловую помойку без указания точного имени файла;
2. Ссылка на каталог архива или файлового сервера, где лежат файлы не только от этой поставки или они могут там появиться;
3. Ссылка на файл или несколько в каталоге, где не включен версионный контроль;
4. Ссылка на каталог с версионным контролем, но без указания версии (выдаваемой архивом) артефакта.
5. Ссылка, по которой не у всех потребителей есть доступ.
6. Отсутствие явного оповещения;
7. Отсутствие оповещения вместе с выкладыванием в неоговоренное место, в котором артефакты не находятся в управляемом состоянии.

Выше часто звучат слова "управляемое состояние". Что это такое, мы разберем дальше.

Что делать между началом и завершением  ^

Управление информацией  ^

Итак, что такое информация "под управлением"? Разберем.

Во-первых идентифицирована и предъявляема (наблюдаема):
- установлен носитель;
- присвоен идентификатор (имя, код, имя-версия и т.п.);
- обеспечено предявление, то есть известна инструкция, выполнение которой верно преобразует (идентификатор) в (предъявленный артефакт) за секунды или, в крайнем случае, минуты;
- известен требуемый объем и качество, поддаются измерению фактические объем и качество;
- ясны назначение, область применения;
- ясен статус актуальности, как минимум: черновик (смотреть в присутствии автора с его комментариями), поставлено/принято (когда, кому - можно опираться), аннулирован/устарел (не смотреть).

Во-вторых изменяема: есть инструкция, которая за приемлемое время позволяет разместить артефакт под управление или изменить его статус и другие параметры.

Задание и измерение объема и качества аналитических артефактов - это отдельная большая тема. Пока здесь скажем только пару слов.
- Объем задается списком элементов, для которых измерен объем. Самая простая единица объема - единицы. То есть мы можем сказать, что "в этой модели 250 классов" или "в документе 100 страниц" - это будет указание объема. Как интерпретировать единицы объема зависит от... И об этом в следующий раз.
Качество - это соответствие требованиям и ожиданиям потребителей. Для измерения качества нужен список требований и ожиданий (возможно, с весами или группировками) - это дает возможность подсчитать качество в процентах, по группам, определить уровень (если надо). Самое простое измерение качества - это экспертная оценка на зачет: годится/не годится.

И еще такие вопросы: что хранить, как технически организовать?

Хранить необходимо:
- ВСЕ исходные данные и иметь реестр исходных данных;
- ВСЕ поставки;
- черновики - по желанию (можно договориться о ежедневной сдаче текущих наработок в архив).

Технически это может быть:
- файловый сервер и индексный файл, например, excel с гиперссылками
-- минусы:
--- менее защищенное решение - требует дисциплины или усилий по организационному администрированию;
--- версионный конроль, статус и другая атрибутика эмулируется через названия файлов;
--- ручная нотификация.
-- плюсы:
--- самое простое и дешевое;
--- незащищенность лечится ежедневным резервным копированием;
--- затраты на администрирование (помещение в архив через ответственного) могут обернуться одновременной централизованной отметкой прогресса по плану работ.
- электронный архив:
-- минусы:
--- дорого в приобретении и настройке;
--- нуждается в техническом администрировании;
-- плюсы:
--- автоматический версионный контроль и история всех операций;
--- статус и атрибутика на карточке документа (что дает атрибутный поиск);
--- нотификация потребителей (но важно правильно ее настроить).
- хранение в выделенном под архив прокта почтоом ящике, при этом все поставки идут письмом с копией в этот ящик:
-- минусы:
--- требует дисциплины - не слать мусор, правильно ставить префиксы в темах;
--- требует заведения ящика;
--- обычно такой ящик закрыт для публичного доступа (и поиска);
--- при использовании "ответить всем" на письмо с поставкой в ящик начинает сыпаться мусор;
-- плюсы:
--- позволяет выполнять поставку письмом с минимальными усилиями;
--- нотификация обеспечена;
--- дисциплину можно подлечить настройкой фильтров в ящике с "автоответом" на плохо оформленные письма.

При поставке с задействованием электронной почты есть такая тонкость: в архив лучше помещать не файлы результата, а письмо, с приложенными к нему файлами. Большинство почтовых клиентов позволяют выгрузить файл письма, включающий вложения. Это дает фиксацию отправителя, даты отправки письма, полный список получателей, сопроводительный текст в теле письма.

Важно понимать, что вне зависимости от выбора технического решения, важно обеспечить управляемость информации. Не думая об управлямости, можно легко получить файловую помойку в электронном архиве на базе специального ПО. Думая об управляемости можно легко получить идеальный порядок на файловом сервере.

Самая частая проблема с управлением информацией проекта не в выборе и неудобстве технического решения, а в частом нежелании команды иметь предельно четкую управлямость. Я писал о возможных причинах здесь и здесь. Но повторю, что важно избежать двух ловушек:
- синдрома большой кнопки, когда люди предлагают слить время на игру в систему управления документами, когда времени на это уже нет.
- организации помойки при любой технической реализации, когда кажется, что техническая система решит за нас все вопросы, и организация верной идентификации, своевременного проставления статусов и других атрибутов упускается.

Решение в случае, когда группа склонна "прятать" или "разбрасывать по углам" свои результаты, такое: назначить ответственного администратора за архив и установить правило: все поставки письмом администратору, а дальше он сам распределят (заодно вносит прогресс в план). Если опереться не на кого, по началу (пока группа не втянется) - эту работу должен делать менеджер проекта.

Рабочая разметка артефакта  ^

Чтобы понять, в чем суть рабочей разметки, давайте посмотрим на модель аналитической работы.



Красные стрелки показывают последовательность появления разных артефактов:
1. Метамодель и/или выбранная аналитическая технология задает вопросы;
2. Вопросы вызывают планирование их снятия;
3. Вопросы могут закрываться предположениями или предложениями;
4. Предложения и предположения планируются к проверке/согласованию;
5. Не снятые вопросы - это риски к инициации;
6. План шагов вызывает подъем и осмысление исходных данных: сбор информации, принятие решений, проверка предположений, согласование предложений;
7. Исходные данные после обработки становятся решениями и фактами;

Для управления всеми перечисленными микроартефактами: вопросы, предположения, предложения, факты и решения, исходные данные, метамодель, риски нужно заводить множество опорных списков. Это дорого и трудоемко. Но самое главное, частое переключение между учетными структурами вызывает выход из потока. По этому суть предлагаемого метода - хранение всех микроартефактов в документе.

Как это выглядит: в текст документа мы помещаем все, что не знаем, что нас беспокоит, планы, что надо сделать, что является предположением.



Метамодель задается шаблоном документа, который надо заполнить.

Для удобства управления разметкой можно использовать теги наподобие "TBD" и "OQ" (To Be Done & Opened Question). Это дает возможность перемещаться по тегам с помощью поиска, а так же быстро определять количество вкраплений.

Вот самый грубый, но действенный способ это сделать в MS Word:



Надо только не забыть откатить эту операцию.

Преимущества размеченного документа очевидны:
- его качество ясно: черновик невозможно перепутать с чистовиком;
- это подход к измерению качества и оставшегося объема к заполнению;
- это дает рецензентам возможность сфокусироваться более четко и не терять лишнее время;
- это дает всей группе понимание текущего состояния работы.

Вот пример, как примерно узнать состояние в MS Word (как это сделать численно, мы только-что обсуждали):



Но самое главное, мы можем не останавливаться: все, что мы не знаем или нас беспокоит, все предположения и планы мы можем писать, не выходя из потока и не отвлекаясь - одним проходом по документу сверху-вниз - это наиболее эффективно.

Метамодель  ^

Простейшая метамодель - это обзор документа. Отвечаемые вопросы берутся от потребителей или из контрольных списков применяемой методологии: ГОСТ, RUP и т.п.

Если копнуть глубже, то можно сделать шаблон документа, который даст нам большую детализацию по вопросам.

Когда делать шаблон?

Когда это необходимо и окупается, то есть детали вопросов неочевидны, а затраты на документ превысят затраты на шаблон.

Если речь идет о модели, то метамодель - это не только записка "как читать диаграммы", но и информация о применяемых точках зрения, отвечаемых вопросах, организации пакетов (или других структурных единиц), критерии полноты и качества моделирования то есть, полновесное соглашение о моделировании.

Двухпроходный метод  ^

После прохода по документу мы получаем размеченный документ, в котором готовые части, вопросы, планы, предположения и т.п. перемешаны между собой.

Что дальше?

Два варианта.

1. Вернуться обратно и сделать еще один проход, начиная от введения. Это работает, так как по мере прохода по документу вопросы и планы были вытеснены в подсознание, там переработались и уже могут быть готовы вернуться новыми идеями: где посмотреть, какие еще вопросы, какие неточности в постановке, какие можно сделать предложения и предположения. В какой-то момент это перестанет быть эффективным, так как из имеющихся исходных данных мы выжали все, что могли. И тогда второй вариант.

2. Проходом по документу соскоблить все пометки в списки:
- открытые вопросы
- предложения
- предположения
- задачи
- вопросы к постановке задачи

Можно так же немного расслабиться, посчитать инкремент по количеству тегов и занести его на графики, показывающие динамику продвижения. Не знаю, кому как, но мне психологически проще видеть, что хоть что-то в работе движется: нет решений, но прирастают вопросы и задачи, то есть, нам есть куда двигаться. Так же приятно наблюдать перелом, когда, наконец, решения идут на рост, а вопросы уже не прибавляются. Это, конечно, не обязательно, но при параличе команды перед сложной задачей и связанной с этим общей депрессией важно показать позитив и открыть возможность продвижения.

Что тут важно?

Если мы не можем добавть в наш результат факты и решения, мы должны перейти к действиям иного рода:
- отсортировать вопросы по адресатам и методам снятия и спланировать раскрытие;
- календарно спланировать задачи по поиску и получению информации, проверке предположений, согласованию предложений;
- вынести артефакт на ревью для последующего мозгового штурма или групповой сессии работы;
- приступить к выполнению спланированных работ.

Сами списки могут быть как внешними, так и временно размещены в разделах документа. Как минимум, раздел "Открытые вопросы" есть смысл всегда создавать и поддерживать в документе (и все соскобленные элементы разметки хранить там). Это дает возможность при поставке явно указать текущее качество артефакта без лишних хлопот.

Почему лучше проходить документ сверху-донизу, а не при каждом вопросе планировать раскрытие? Надеюсь - это ясно:
- мы можем не выходить из потока и двигаться быстрее;
- мы можем, вместо 100 задач на 100 вопросов после сортировки получить 10 задач, снимающих по 10 вопросов.

Управление неопределенностью  ^

Важно понимать, что открытые вопросы - это мера неопределенности в работе.

И тут есть одна тонкость: неопределенность может быть неограниченной "не знаем, что не знаем" и ограниченной "есть вопрос без ответа".

Чтобы проект данного типа был успешен, мы должны обеспечить принятие решений определенного типа, то есть снятие неопределенности.

В этом нам помогают различные методологии, содержащие контрольные списки вопросов, то есть плоскости и грани, грубо ограничивающие неопределенность с самого начала.

В области ИТ уже достататочно наработок и можно сказать, что большинство проектов могут стартовать со всеми заданными ключевыми вопросами.

Что же мешает ИТ проктам быть успешными?

Вот мой рейтинг причин (по моим наблюдениям).
1. Неумение пользоваться выбранной методологией или отказ от любых контрольных списков вопросов на входе.
2. Страх перед неопределенностью - как ни странно, вместо того, чтобы радоваться найденному вопросу без ответа (ведь мы теперь знаем, над чем работать), люди часто отворачиваются от него, в надежде что это вопрос не к ним. Позже, когда связанный с вопросом риск выстреливает, это представляется, как "внезапные обстоятельства", хотя в реальности - это полная некомпетентность в области управления рисками.
3. Разные мнения о текущих приоритетах. Тут необходимо управлять рисками, то есть просчитывать последствия каждого не снятого вопроса и разрабатывать стратегию реагирования. При этом надо не путать эту с предыдущей причиной, когда несогласие команды о приоритетах маскирует страх перед неопределенностью. Только что об этом написал коллега: тут.

Правило такое: кроме тупого проделывания ясной работы необходимо принимать решения, то есть, снимать открытые вопросы.

Чтобы управлять этим необходимо делить вопросы на ключевые и производные и отслеживать динамику раскрытия:
- ключевые вопросы не спланированы;
- ключевой вопрос детализирован на производные и есть план работ;
- степень реализации (отношение решенных производных вопросов к общему количеству).

Пока на графиках не начинают отчетливо проступать S-кривые, мы не можем себе позволять успокоиться.

Если коротко резюмировать, то принцип такой: ищите вопросы, затем ищите ответы, управляйте количеством того и другого - это даст возможность никогда не попадать в проектный паралич.

Неизвестная задача  ^

Бывает так, что мы не имеем списка вопросов на входе: новая для нас область или реально новая задача (типа, мы ученые-исследователи).

Предварительный список открытых вопросов на этот случай я записывал в одной из предыдущих статей тут.

Есть и более впечатляющие списки из "большого системного анализа" или из других методов научных исследований. Но это тема другой статьи.

При этом тезис "ищите вопросы" сохраняется для любых случаев.

Заключение  ^

Итак, в этой статье я объяснил свое видение принципов аналитической работы (в основном, основанной на документах) и предоставил минимальные контрольные списки, связывающие состояния белого листа и совершенной поставки.

Ключевые тезисы таковы:
1. Все в одном документе (постановка задачи, факты/решения, планы, вопросы, предположения и т.п.) - это позволяет не выходить из потока и двигаться эффективней;
2. Начало работы - постановка задачи: или проектное задание или введение - это даст знание, когда закончить работу;
3. Обеспечить управляемое состояние исходных данных и результатов поставки;
5. "Проход" по документу в состоянии потока с принятием решений, записью вопросов, предположений и т.д. - использовать работчу разметку;
6. Второй тип прохода - скобление в списки: открытые вопросы, задачи;
7. Управление границами неопределенности: наблюдать (по мере продвижения проекта), как решаются ключевые вопросы, не допускать откладывания решения сложных системных вопросов в пользу простой или ясной работы.
8. Управление рисками, связанными с нерешенными вопросами.
9. Соблюдать правила поставки и правила хранения.
10. Ищите вопросы, затем ищите ответы. Никогда не ботесь вопросов, но бойтесь их отсутствия.

Существует еще много приемов работы, но лучшее враг хорошего. Минимальный список для работы, на мой взгляд, обеспечен.

И теперь, когда ясны базовые принципы, мы можем искать ответ на вопросы, специфические для работы с моделями и моделлерами, численного определения объема и качества аналитических артефактов, календарного и ресурсного планирования работ, правил принятия обязательств по работам, работы с людьми (извлечение информации, согласование и презентация решений) и вопросах мониторинга и управления аналитическими работами.

И об этом в следующих статьях.

Я благодарю читателей за внимание к моей статье. Кому есть, что обсудить или спросить по представленной теме - прошу писать мне ( здесь актуальные контакты ), я всегда открыт для конструктивного диалога :)