Comments 16
! Используй Confluence, Notion, Google Docs — не Excel, не Word, не PDF.
При блокировке доступа к иностранным ресурсам, не важно, с какой стороны и по какой причине, какой станет ситуация в вашем проекте? В тот день, когда не откроется ваш Confluence, Notion, Google Docs? И чем она будет отличаться от ухода Саши?
Используй Confluence, Notion
Notion и сейчас не работает уже.
Confluence не пользуюсь 5 лет, не знаю работает ли у нас сейчас.
Соглашусь, странно говорить об этих продуктах сейчас. К тому же инструменты для работы с документами есть в доступных для нас сервисах типа Kaiten, Teamer, Weeek и Shtab. Ну а в целом, поддержу автора, т.к. также предпочитаю, чтобы нюансы прописывались в проектной документации.
вы удивитесь какой процент компаний и команд их реально сейчас использует) В моей команде и среди экс коллег -это 90% очень скиловых ребят в очень разных командых.
говорить важно в первую очередь о сути, как в этой статье - что важно вести адекватную документацию! Луше сделать и в экселе, чем не сделать совсем, НО мы же про удобство и качество для всей команды? К слову, какой софт разрешает иметь и внедрит компания, где ты хочешь что-то фиксировать тоже немало важный нюанс - иногда хоть урекомендуйся...где-то хоть плач, но альтернативу тебе внедрить не дадут и тут уже подкладываешь себе и команде соломку как можешь - увы...
Вопрос в какой команде и каком проекте/проектах вы работаете)
Например, международная команда или нет...распределенная команда или нет, один у вас проект или нет, гос проект или нет, инхауз разработка или нет и так до бесконечности!Выбор инструмента - это вопрос не первой значимости, факт и при этом зависит от целого ряда нюансов и должен быть рациональным для конкретной организации, команды, проекта. И да -лучше даже иметь записку в блокноте аналитика, чем не иметь вообще ничего, если уж мы утрируем
На крупных проектах с большой командой вне зависимости от инструментов моя команда всегда имеет два места, где мы храним документы. Один полудеревянный, но в случае отказа всего - мы сможем ее достать (хоть и с болью в сердце), а второй адекватный для работы и подвязки связанных процессов.
Почему именно моя команда зачастую (не всегда) использует конфу - у нас полностью выстроен процесс от старта проекта, проработки требований до разработки, тестирования, валидации и вывода в прод. Мы пользуемся Jira и Git, а в связке с конфой это дает большую долю прозрачности.
Документации не надо бояться! Пусть боятся тебя с документацией!
"- был у нас один, вся деревня боялась..." Ералаш №52 “Просто жуть!”
Документацией нужно управлять!
Сквозная система знаний — всё в Confluence. Никаких Excel, Word, PDF.
А когда Confluence стал поддерживать процессы по управлению документами и метаданными??
процессы нужно настраивать)
управлять документацией смотря в каком виде - в чем большой плюс конфы для меня и моих команд, например:
-есть адекватная версионность и единое место формирования базы знаний к которой мы можем все нормально из разных точек подключаться и спокойно ходить и сравнивать версии/формировать потоки
-есть супер удобная возможность стыковать документацию с продуктами, которые мы используем, а это таже Jira.
В двух словах.
Нужна ли проектная документация в 26 году
В любом году обязательна.
что если ты пришел на новый проект, а там хаос и пустота?
Да ничего, если их это устраивает. Зато всегда есть отмазка: без ТЗ результат - хз. Ну и можно спокойно пинать балду, пока тебе объяснят, что же от тебя требуется в задаче, которую тебе поставили устно между делом.
senior и lead себе такие вещи позволить не сможет, тк твоя работа разобраться в том, что от тебя хотят. Если мы говорим про разработчиков, то как минимум ткнуть аналитика с вопросами или PM-а
а вот если аналитику спустили непонятную задачу - то у тебя нет альтернатив, кроме как искать истину...иногда даже просто в глазах заказчика))
Документация делается для читателя. Если его нет, она не нужна, так скажет архитектор. Для агентной разработки в 2026 нужна система управления знаниями, а не документацией, на мой взгляд
Хорошо сказано про документацию как рабочий инструмент, а не пачку файлов к приёмке. Особенно про зависимость проекта от людей, которые держат в голове причины решений, обходные пути и половину фактических правил системы. Уходит такой человек – и внезапно выясняется, что компания потеряла не сотрудника, а кусок собственной памяти.
Но, по-моему, у проектного хаоса обычно есть более глубокая причина. Документов может быть много, а порядка всё равно нет – потому что не определены владелец результата, правила процесса, полномочия и достоверные источники данных. Документация хорошо сохраняет принятые решения, но принять их вместо людей она не может. А если решений нет, можно очень аккуратно задокументировать бардак и потом годами его воспроизводить.
Поэтому и протокол встречи я воспринимаю скорее как сырьё для реестра решений. Важно не только записать, что сказал Саша или уточнила Оля, но и понять: решение вообще принято? Кем? В пределах каких полномочий? Какие последствия и риски приняты вместе с ним? А Confluence это будет, Word или Excel – уже вопрос удобства, а не управленческой зрелости.
Согласна, тут надо учитывать ряд нюансов:
-какая стадия проекта:
если функционал уже формально принят заказчиком это одно дело, если пожар возник на демо и выясняется, что заказчик не то хотел - другая история. А уж если ты пришел и тебе нужно разобраться в проекте, где всем норм, что документации нет...и таких вариаций много. Шагаем в пучину исходя из ситуации.
-осознаем причины той стадии на которой находится данный хаос
Потом смотрим на нашу цель:
- а для чего мы начинаем писать документацию? одно дело написать документацию только чтобы разобраться, другое дело сделать документацию и выстроить на базе нее процессы в команде
Слона всегда нужно есть по частям и тем более не бездумно
2. Про протоколы тоже согласна, более того их я уже давно отдала ИИ, а вот вникнуть в суть и добиться реального решения...при чем чтобы у решения был реальный ответственный, а другие отделы были с ним согласны...) вечная боль!
3.Что касается инструмента - это безусловно не первый и, даже не второй, момент по значимости, НО важно понимать, что:
- с ним должно быть удобно работать всем участникам проекта
-нужна версионность
-в больших проектах важно чтобы документация хранилась в идеале не в одном месте, тк увы риски отключения любого ПО нынче высоки
Были проекты с госзаказчиками, где документы существовали только для отчётов:
написанное в ворде, которое никто даже из заказчиков не читал
Везёт Вам!!! У нас почти все Заказчики большие извращенцы. В плане оформления документации: у всех строгие требования к шрифтам, отступам и межстрочным расстояниям.
Был проект, когда мы полгода меняли форматирование в Word. Каждую итерацию они проверяли примерно месяц, потом мы получали замечания типа "на странице 7 в 40 строке межстрочное расстояние отличается от эталона на 1pt (0.35 см)". у меня подозрение что открывали каждый документ. Ставили курсор в каждую строку и смотрели какое там межстрочное расстояние
Кульминация была феерическая: нам назначили последний срок, сделать до завтра! Объявили что к ним уже пришла проверка из Следственного комитета. Они тянут время, не пускают их до компа посмотреть документы. Я отказался работать ночью, мой начальник и ещё пару коллег участвовали в этом аврале!!!
Сочувствую!
Были и такие в моей жизни, очень понимаю боль!
Сейчас я погружена в не менее извращенный мир производства в фарме и там есть свои нюансы с валидацией систем по особым правилам, включая оформление документации - как итог почти все команды имеют два комплекта документов с одной сутью, НО одни полезные для команды, а другие избыточные для аудитов )
Пришёл из соседнего цеха - я про delivery, а не про аналитику, но подписываюсь под каждым словом. Добавлю одну вещь, которую Ваша же история про ушедшего Сашу прямо просит: самый ценный документ на проекте не требование, а решение. Не "что сделали", а "почему сделали так и почему НЕ стали иначе». Требования устаревают, а "мы не используем API X, потому что…" - это ровно то знание, что уходит вместе с человеком.
У инженеров под это есть ADR (Architecture Decision Record): пять строк - дата, контекст, решение, последствия. Идеально ложится и в вашу MVD, и в правило "фиксируем с датой и именем".
И жирный плюс за "зачем бизнесу это нужно - нет ответа, не делаем". По-моему, из этого правила растут все остальные: живёт та документация, что отвечает на вопрос, который кто-то реально задаст снова. Остальное честно гниёт в "Архив_удалить". Пусть боятся)
согласна, требования безусловно рано или поздно устаревают, для этого хорошая команда аналитики ведет реальный полный цикл требований
ОТ Вася-VP тогда-то захотел ускорить процесс закупок из-за "проблема"+ вот что реально хочет вася и это будет стоить нам столько и даст такой примерный результат
ДО, а вот так мы сделали и это дало вот такой реальный результат (желательно в бизнес показателях).
но да, тут мы не говорим о минимальной документации, тут мы говорим о хорошей рабочей и нужной документации на крупных проектах с зрелым лидом аналитики)
Нужна ли проектная документация в 26 году и что если ты пришел на новый проект, а там хаос и пустота?