Как поддерживать требования к проекту всегда в актуальном состоянии? Инструменты?

Вопрос больше для тех кто собаку съел в управлении проектами. Суть: есть требования к проекту, сначала в виде обзорного ТЗ, потом в виде задачек в трекере, они постепенно реализуются в разрабатываемой системе (ПО), появляются новые, что-то меняется, что-то заказчик передумывает (часть задач теряют актуальность), и т.д.

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

Ребята, кто какие системы применяет для управления требованиями к ПО, что вы там храните? - задачи, или UserStories? Куда ткнуться почитать как это вообще по-уму реализовать ?

Я не ПМ, знаю что нужно пинать ПМа, но реально пока не понимаю, он что, должен это тупо вручную отслеживать, и документацию в вики или в гугл-доке?

Всем заранее спасибо.
  • Вопрос задан
  • 199 просмотров
Пригласить эксперта
Ответы на вопрос 1
apavlyut
@apavlyut
www.apavlyut.ru
> Как поддерживать требования к проекту всегда в актуальном состоянии?

Добрый день. Блиц ответ - регулярно обновлять информацию )

> Инструменты?

Сразу к делу - я создатель такого инструмента. Подробности на трибуне vc.ru ->

> Вопрос больше для тех кто собаку съел в управлении проектами.

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

> Суть: есть требования к проекту, сначала в виде обзорного ТЗ, потом в виде задачек в трекере, они постепенно реализуются в разрабатываемой системе (ПО), появляются новые, что-то меняется, что-то заказчик передумывает (часть задач теряют актуальность), и т.д.

Требования всегда будут проявляется потому что внимание ограничено - мы живем и работаем в ситуации аналогичной игр типа "стратегия" - когда карта туманная мы ничего не видим, когда мы "дойдем" и "воочию" увидим что там - мы видим "новые вещи". Были ли они новыми? нет - они новые только в нашем внимании. Вы мыслите верно.

> И потом бац - а цельной-то картины и нету, приходит например новый разработчик на проект или даже новый менеджер, начинает потом у народа спрашивать, а как вообще надо чтобы работало ? Тестировщик приходит - "меня прислали потестировать, а скажи как оно вообще должно работать ?".

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

Также эффект в игре-стратегии такой же, я называю его "эффект фонарика" - куда "светите" там и все вам видно, а вот в другом углу куда не светите (нет фокуса) уже не видно.

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

> Ребята, кто какие системы применяет для управления требованиями к ПО, что вы там храните? - задачи, или UserStories? Куда ткнуться почитать как это вообще по-уму реализовать ?

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

Короткий ответ в группе уже дал на разницу Jira / Тимсити / Трелы и прочее:

// цитата

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

Практики Мьельнира не совсем понятные с ходу - но следуя им вы просто работаете как бы и работали в других системах, но весь контекст будет просто накапливаться и вам никогда не надо будет кому-то "передавть" знания и терять контекст при смене сотрудников.

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

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

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

// конец цитаты

> Я не ПМ, знаю что нужно пинать ПМа, но реально пока не понимаю, он что, должен это тупо вручную отслеживать, и документацию в вики или в гугл-доке?

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

> Всем заранее спасибо.

Надеюсь не забанят - вроде бы прямой ответ на вопрос.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
29 нояб. 2024, в 10:38
5000 руб./за проект
29 нояб. 2024, в 10:27
100000 руб./за проект
29 нояб. 2024, в 09:43
100000 руб./за проект