Документы проекта, обязательные и ненужные

Здесь мы обсуждаем вопросы совместной работы в команде и с командами (Scrum, Kanban, TOC и прочий Lean)
Аватара пользователя
Alex Moskvichev
Сообщения: 79
Зарегистрирован: Вт авг 04, 2015 8:01 am
Откуда: Новосибирск
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение Alex Moskvichev »

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

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

Но вопрос документации имеет для меня практическое значение.
Обобщить можно и потом.

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение Максим Дорофеев »

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

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

Тут вот еще какое дело... Документация - это типа идея. Как идея - это все нужно. Но помимо идеи будет еще и конкретная реализация, а вот тут и будет тыща юансов.

Natalia
Сообщения: 313
Зарегистрирован: Пн июл 06, 2015 4:40 pm

Re: Документы проекта, обязательные и ненужные

Сообщение Natalia »

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

Аватара пользователя
Alex Moskvichev
Сообщения: 79
Зарегистрирован: Вт авг 04, 2015 8:01 am
Откуда: Новосибирск
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение Alex Moskvichev »

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

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

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

Максим, а есть альтернативный формат записи диаграммы, текстовый например? С диаграммой не очень удобно в компьютере работать, надо доску или ватман.

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение Максим Дорофеев »

Alex Moskvichev писал(а):Тогда предлагаю уменьшить ситуацию до цепочки аналитик-разработчик, или заказчик-аналитик-разработчик. А там как пойдет.
Имеются в виду требования к системе? А так еще на вскидку, какая еще документация может быть?
Alex Moskvichev писал(а):Максим, а есть альтернативный формат записи диаграммы, текстовый например? С диаграммой не очень удобно в компьютере работать, надо доску или ватман.
XML :)
Вообще все дело в программе, думаю. Это какого рода диаграммы не удобно в компьютере делать?

evmenkov
Сообщения: 14
Зарегистрирован: Пн июн 29, 2015 11:33 pm

Re: Документы проекта, обязательные и ненужные

Сообщение evmenkov »

Вообще то, кол-во и объем документации на проекте - зависит от сложности, важности, размера проекта. Вроде очевидно.

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

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

Аватара пользователя
Alexandro Podkopaev
Сообщения: 13
Зарегистрирован: Вт сен 22, 2015 6:43 pm
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение Alexandro Podkopaev »

Документы как идея - метко! :D
Обсуждать "документы" вообще, и их влияние на разработку можно бесконечно.

Чтобы немного "приземлить" идею, предлагаю выделить:
"ТЗ","конструкторскую документацию", "пользовательскую документацию", "технологическую документацию", "управленческую документацию".

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

В итоге, "в срок" не получилось, потому что пришлось переделывать архитектуру. И переписывать следом.

Отсюда вывожу: ТЗ и конструкторская документация - ни разу не вспомогательный процесс, а часть основного.
Я не увидел этого в "Цель" и "Цель2" - вероятно, потому, что для примеров все время выбирались "классические производства", где станки стоят на 1-2 порядка дороже з\п рабочего (если не брать глубокое заМКАДье, в ИТ все с точностью до наоборот), а от состояния ума рабочего перед станком характеристики результата зависят слабо (опять же, в отличие от ИТ, где джуниор, еще не отошедший от чтения "банды 4х" может простое действие копирования значения одного атрибута в другой сделать через все каноны - с фабриками, фасадами и прочей...гм). Соответственно, конструирование\проектирование в книгах как возможное ограничение не рассматривалось.

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

Про РМскую документаци - не копенгаген.

comm
Сообщения: 44
Зарегистрирован: Вт окт 06, 2015 12:32 pm
Откуда: Saint-Peterburg, RU
Контактная информация:

Re: Документы проекта, обязательные и ненужные

Сообщение comm »

Получится.

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

Мой рецепт следующий:
1. Вся документация по проекту в вики (mediawiki4intranet + plantuml + graphviz)
2. документация которая вводит в курс дела: карточка проекта - суррогат устава проекта, определяет важное: цели, ресурсы (команда, ссылки на все инфосистемы поддержки), ограничения проекта.
3. Документация защиты от автобусного фактора по формуле: СНАЧАЛА ПИШЕТСЯ дизайн дока ПОТОМ делается задача на реализацию. Если происходит наоборот, то обучаю как делать правильно. Но все рано пишут обычно будущие архитекты, те кто не хочет - "увольняю", ибо нафиг мне сотрудник который не хочет учиться?

по п 3 дока обычно содержит:
1. Постановка проблемы. Какую проблему решаем?
2. Ограничения : чем мы ограничены в выборе вариантов?
3. Варианты решения , с обоснованием почему это хорошо и почему плохо. схемы делаются в plantuml

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

Таким образом имеем:
1. Когда начинаем думать о проблеме клиента , пишем в вики требования/истории
2. Когда смотрим на историю, думаем о том как это реализовать, и сразу пишем дизайн решение.
3. Когда начинаем кодировать, думаем о том как будет работать целевой класс и пишем модульные тесты.(TDD+BDD)
4. потом пишем МИНИМУМ кода чтобы тесты сработали.
5. передаем в QA (если есть)
6. QA уже обновил свои тест планы на основе wiki
7. выпускаем клиенту


О wiki - Created by Ward Cunningham, Launched 25 March 1995
то есть к моменту выхода XP в России, ISBN 5-94723-032-1; 2002 г. , wiki идея уже взлетела
Кент на неё ссылается в книжках.


И да, я это называю XP.
С уважением, Алексей Васильев. http://bipulse.ru

Ответить