Форум продуктивных

Привет.

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

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

Т.е. можно сказать, что одновременно документация нужна и документация не нужна.

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

P.S. Тема немного оффтопик, поэтому предлагаю обойтись без споров, а попрактиковаться в теории ограничений
P.P.S. Есть одно известное решение, в XP https://ru.wikipedia.org/wiki/%D0%AD%D0 ... 0%B8%D0%B5 решили эту дилемму. Но сама методология не получила широкого распространения.

Alex Moskvichev писал(а): Т.е. можно сказать, что одновременно документация нужна и документация не нужна.

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

Кстати, да... Можно попробовать порисовать Диаграмму Разрешения Конфликтов, вот тут есть шаблон: Правильно я понимаю, что так и надо формулировать методы обеспечения: "Создавать документацию по проекту" и "Не создавать документацию по проекту?". Или попробуем что-то более конкретное?

Alex Moskvichev писал(а):P.P.S. Есть одно известное решение, в XP https://ru.wikipedia.org/wiki/%D0%AD%D0 ... 0%B8%D0%B5 решили эту дилемму. Но сама методология не получила широкого распространения.

А что они решили в ХР? Заказчик всегда рядом + TDD?

cartmendum писал(а):
Правильно я понимаю, что так и надо формулировать методы обеспечения: "Создавать документацию по проекту" и "Не создавать документацию по проекту?". Или попробуем что-то более конкретное?

Ничего лучше в голову не приходит. Если никто еще вариант не предложит, то можно так оставить.

cartmendum писал(а): А что они решили в ХР? Заказчик всегда рядом + TDD?

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

Для пользователей - User stories и приемочные тесты.

Ну и wiki вроде как один из авторов XP придумал, если я ничего не путаю. Но это на крайний случай, если очень-очень надо )

Первое приближение.
Смущает, что много тавталогии получилось. Это плохо для схемы?

А в чем тут тавтология? По-моему прекрасный пример.

Давай попробуем пройтись по предпосылкам:

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

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


В общем - отлично для начала!

На поддержание документации уйдут ресурсы, которых и так всегда не хватает

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

cartmendum писал(а):А в чем тут тавтология? По-моему прекрасный пример.

Чье время уйдет на лишние согласования и переделки?

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

• Получатель результата - Заказчик
  Ответственный за общий результат - ПМ
  Занятый на работах критической цепи - исполнитель
  Остальные - вспомогательный персонал

Время может уйти у всех. Зависит от степени промаха.

А Чье время уйдет на поддержание документации? Мы же знаем, что не все время одинаково полезно - есть ограничение, и есть не ограничение

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

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

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

[*]Документацию все равно никто не читает - возможно, обобщение здесь излишне, но ведь и правда, многим проще спросить, чем читать.[/list]

Можно переформулировать - документация может быть неиспользована, или устареть к моменту использования. Устаревание не обязательно зависит от работ по проекту. Например, интеграция систем, документация - howto по интеграции, вторая система поменялась

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

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

Alex Moskvichev писал(а):А высокая скорость разработки - не всегда помогает Вот в моих проектах на разработку уходит меньше половины времени, больше на согласования и внедрение

Хм... А мы о какой документации? Той, которая помогает разработчикам или помогает согласовывать?

Alex Moskvichev писал(а):При создании документации есть вероятность, что она не будет никогда использована или устареет до момента использования.

Устаревание не обязательно зависит от работ по проекту. Например, интеграция систем, документация - howto по интеграции, вторая система поменялась

Это фундаментальные проблемы планирования, чего угодно, а не только документации. Ветвления во времени. Дело в том, что документация тоже должна быть запланирована с учетом своей специфики: Сейчас у тебя если в проекте случается сюрьприз, то необходимость документировать умножает последствия сюрьприза на 1.3 скажем. А надо чтобы на 0.7.

чтобы не сойти с ума.

cartmendum писал(а):

Alex Moskvichev писал(а):А высокая скорость разработки - не всегда помогает Вот в моих проектах на разработку уходит меньше половины времени, больше на согласования и внедрение

Хм... А мы о какой документации? Той, которая помогает разработчикам или помогает согласовывать?

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

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