согласна, требования безусловно рано или поздно устаревают, для этого хорошая команда аналитики ведет реальный полный цикл требований ОТ Вася-VP тогда-то захотел ускорить процесс закупок из-за "проблема"+ вот что реально хочет вася и это будет стоить нам столько и даст такой примерный результат ДО, а вот так мы сделали и это дало вот такой реальный результат (желательно в бизнес показателях). но да, тут мы не говорим о минимальной документации, тут мы говорим о хорошей рабочей и нужной документации на крупных проектах с зрелым лидом аналитики)
вы удивитесь какой процент компаний и команд их реально сейчас использует) В моей команде и среди экс коллег -это 90% очень скиловых ребят в очень разных командых.
говорить важно в первую очередь о сути, как в этой статье - что важно вести адекватную документацию! Луше сделать и в экселе, чем не сделать совсем, НО мы же про удобство и качество для всей команды? К слову, какой софт разрешает иметь и внедрит компания, где ты хочешь что-то фиксировать тоже немало важный нюанс - иногда хоть урекомендуйся...где-то хоть плач, но альтернативу тебе внедрить не дадут и тут уже подкладываешь себе и команде соломку как можешь - увы...
Вопрос в какой команде и каком проекте/проектах вы работаете) Например, международная команда или нет...распределенная команда или нет, один у вас проект или нет, гос проект или нет, инхауз разработка или нет и так до бесконечности!
Выбор инструмента - это вопрос не первой значимости, факт и при этом зависит от целого ряда нюансов и должен быть рациональным для конкретной организации, команды, проекта. И да -лучше даже иметь записку в блокноте аналитика, чем не иметь вообще ничего, если уж мы утрируем
На крупных проектах с большой командой вне зависимости от инструментов моя команда всегда имеет два места, где мы храним документы. Один полудеревянный, но в случае отказа всего - мы сможем ее достать (хоть и с болью в сердце), а второй адекватный для работы и подвязки связанных процессов.
Почему именно моя команда зачастую (не всегда) использует конфу - у нас полностью выстроен процесс от старта проекта, проработки требований до разработки, тестирования, валидации и вывода в прод. Мы пользуемся Jira и Git, а в связке с конфой это дает большую долю прозрачности.
senior и lead себе такие вещи позволить не сможет, тк твоя работа разобраться в том, что от тебя хотят. Если мы говорим про разработчиков, то как минимум ткнуть аналитика с вопросами или PM-а а вот если аналитику спустили непонятную задачу - то у тебя нет альтернатив, кроме как искать истину...иногда даже просто в глазах заказчика))
процессы нужно настраивать) управлять документацией смотря в каком виде - в чем большой плюс конфы для меня и моих команд, например: -есть адекватная версионность и единое место формирования базы знаний к которой мы можем все нормально из разных точек подключаться и спокойно ходить и сравнивать версии/формировать потоки
-есть супер удобная возможность стыковать документацию с продуктами, которые мы используем, а это таже Jira.
Были и такие в моей жизни, очень понимаю боль! Сейчас я погружена в не менее извращенный мир производства в фарме и там есть свои нюансы с валидацией систем по особым правилам, включая оформление документации - как итог почти все команды имеют два комплекта документов с одной сутью, НО одни полезные для команды, а другие избыточные для аудитов )
-какая стадия проекта: если функционал уже формально принят заказчиком это одно дело, если пожар возник на демо и выясняется, что заказчик не то хотел - другая история. А уж если ты пришел и тебе нужно разобраться в проекте, где всем норм, что документации нет...и таких вариаций много. Шагаем в пучину исходя из ситуации.
-осознаем причины той стадии на которой находится данный хаос
Потом смотрим на нашу цель: - а для чего мы начинаем писать документацию? одно дело написать документацию только чтобы разобраться, другое дело сделать документацию и выстроить на базе нее процессы в команде
Слона всегда нужно есть по частям и тем более не бездумно
2. Про протоколы тоже согласна, более того их я уже давно отдала ИИ, а вот вникнуть в суть и добиться реального решения...при чем чтобы у решения был реальный ответственный, а другие отделы были с ним согласны...) вечная боль!
3.Что касается инструмента - это безусловно не первый и, даже не второй, момент по значимости, НО важно понимать, что: - с ним должно быть удобно работать всем участникам проекта
-нужна версионность
-в больших проектах важно чтобы документация хранилась в идеале не в одном месте, тк увы риски отключения любого ПО нынче высоки
Information
Rating
1,152-nd
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
согласна, требования безусловно рано или поздно устаревают, для этого хорошая команда аналитики ведет реальный полный цикл требований
ОТ Вася-VP тогда-то захотел ускорить процесс закупок из-за "проблема"+ вот что реально хочет вася и это будет стоить нам столько и даст такой примерный результат
ДО, а вот так мы сделали и это дало вот такой реальный результат (желательно в бизнес показателях).
но да, тут мы не говорим о минимальной документации, тут мы говорим о хорошей рабочей и нужной документации на крупных проектах с зрелым лидом аналитики)
вы удивитесь какой процент компаний и команд их реально сейчас использует) В моей команде и среди экс коллег -это 90% очень скиловых ребят в очень разных командых.
говорить важно в первую очередь о сути, как в этой статье - что важно вести адекватную документацию! Луше сделать и в экселе, чем не сделать совсем, НО мы же про удобство и качество для всей команды? К слову, какой софт разрешает иметь и внедрит компания, где ты хочешь что-то фиксировать тоже немало важный нюанс - иногда хоть урекомендуйся...где-то хоть плач, но альтернативу тебе внедрить не дадут и тут уже подкладываешь себе и команде соломку как можешь - увы...
Вопрос в какой команде и каком проекте/проектах вы работаете)
Например, международная команда или нет...распределенная команда или нет, один у вас проект или нет, гос проект или нет, инхауз разработка или нет и так до бесконечности!
Выбор инструмента - это вопрос не первой значимости, факт и при этом зависит от целого ряда нюансов и должен быть рациональным для конкретной организации, команды, проекта. И да -лучше даже иметь записку в блокноте аналитика, чем не иметь вообще ничего, если уж мы утрируем
На крупных проектах с большой командой вне зависимости от инструментов моя команда всегда имеет два места, где мы храним документы. Один полудеревянный, но в случае отказа всего - мы сможем ее достать (хоть и с болью в сердце), а второй адекватный для работы и подвязки связанных процессов.
Почему именно моя команда зачастую (не всегда) использует конфу - у нас полностью выстроен процесс от старта проекта, проработки требований до разработки, тестирования, валидации и вывода в прод. Мы пользуемся Jira и Git, а в связке с конфой это дает большую долю прозрачности.
senior и lead себе такие вещи позволить не сможет, тк твоя работа разобраться в том, что от тебя хотят. Если мы говорим про разработчиков, то как минимум ткнуть аналитика с вопросами или PM-а
а вот если аналитику спустили непонятную задачу - то у тебя нет альтернатив, кроме как искать истину...иногда даже просто в глазах заказчика))
процессы нужно настраивать)
управлять документацией смотря в каком виде - в чем большой плюс конфы для меня и моих команд, например:
-есть адекватная версионность и единое место формирования базы знаний к которой мы можем все нормально из разных точек подключаться и спокойно ходить и сравнивать версии/формировать потоки
-есть супер удобная возможность стыковать документацию с продуктами, которые мы используем, а это таже Jira.
Сочувствую!
Были и такие в моей жизни, очень понимаю боль!
Сейчас я погружена в не менее извращенный мир производства в фарме и там есть свои нюансы с валидацией систем по особым правилам, включая оформление документации - как итог почти все команды имеют два комплекта документов с одной сутью, НО одни полезные для команды, а другие избыточные для аудитов )
Согласна, тут надо учитывать ряд нюансов:
-какая стадия проекта:
если функционал уже формально принят заказчиком это одно дело, если пожар возник на демо и выясняется, что заказчик не то хотел - другая история. А уж если ты пришел и тебе нужно разобраться в проекте, где всем норм, что документации нет...и таких вариаций много. Шагаем в пучину исходя из ситуации.
-осознаем причины той стадии на которой находится данный хаос
Потом смотрим на нашу цель:
- а для чего мы начинаем писать документацию? одно дело написать документацию только чтобы разобраться, другое дело сделать документацию и выстроить на базе нее процессы в команде
Слона всегда нужно есть по частям и тем более не бездумно
2. Про протоколы тоже согласна, более того их я уже давно отдала ИИ, а вот вникнуть в суть и добиться реального решения...при чем чтобы у решения был реальный ответственный, а другие отделы были с ним согласны...) вечная боль!
3.Что касается инструмента - это безусловно не первый и, даже не второй, момент по значимости, НО важно понимать, что:
- с ним должно быть удобно работать всем участникам проекта
-нужна версионность
-в больших проектах важно чтобы документация хранилась в идеале не в одном месте, тк увы риски отключения любого ПО нынче высоки