Дмитрий Гончаренко писал(а): ↑22.01.2019 10:15
Более того, у нас есть задачи, в которых мы их таки используем - например, у нас в виде майндмэпа представлена структура обучения ПланФиксу новых сотрудников Службы поддержки. Но на текущий момент это никак не связано с ПланФиксом, хотя нам помогло бы, если бы по этой структуре мы могли автоматически создавать дерево задач по обучению и тестированию для нового сотрудника.
Дмитрий, спасибо и вам за развернутый ответ. Очень приятно узнать, что и вам этот функционал был бы интересен
Дмитрий Гончаренко писал(а): ↑22.01.2019 10:15
...это не классический "водопад", при котором без визуализации нам было бы не обойтись, а нечто эджайлоподобное...
Очень рад встретить коллегу)) Мы со свой командой тоже используем подобный подход, занимаясь автоматизацией наших клиентов, только мы по большей части внедряем и дорабатываем опенсорсные CRM. Тоже используем по большей части agile-подход - как в развитии и поддержке готовых, так и в разработке новых проектов. И тем интереснее мне кажется использование инструментов визуализации проектов в разработке по этой методологии.
Дело в том, что мой вопрос про визуализацию лежит за пределами проект-менеджмента. Если для "водопада" проектируется и прогнозируется не столько план работ, сколько само будущее состояние системы. И процесс разработки лишь заключается в приведении системы в надлежаще состояние. То при эджайле конечное состояние системы неизвестно. И особо острым становится вопрос в том, чтобы видеть состояние всей системы как набор взаимосвязей между отдельными частями системы.
Другими словами, меня волнует отображение текущего статического состояния динамически развивающейся системы.
Этакая карта проекта (логики проекта? функционала проекта?).
Ссылаясь на которую можно было бы общаться на одном языке новичку в проекте, который ещё не знает всех нюансов, со старожилом, который все наизусть помнит.
Программисту, который работает с функциями и ООП - с техподдержкой, которая ориентирована на пользовательский интерфейс и работу пользователей.
Технологу, который проектирует внутреннюю, техническу часть процессов, с райтером, который по ним пишет документацию для конечного пользователя.
Менеджер проекта, который отвечает за добавление нового листика на веточке, показывает другим членам команды на такой карте, с какими зависимыми частями системы имеем дело, какие моменты с этим связаны. Возможно - степень готовности этой части сиситемы и что ещё предстоит сделать. (Вот с этого момента уже можно передавать привет планировщикам и переходить от статичных узлов системы к динамически нестабильным точкам роста - текущим задачам на доработку = изменение состояния этих узлов).
А архитектор системы может "со стороны" видеть актуальную ситуацию по проекту, не привлекая команду для уточнения текущего состояния дел.
Если продолжить пример с Планфиксом: да, Планфикс ориентируется на запросы пользователей как на ресурс для развития, растет и ветвится туда, где нужен больше. При этом тщательно взвешивает и продумывает наперёд каждый новый листочек, зная, что из него может появяться новая веточка или даже целая ветвь, и стараясь предугадать, к каким дальнейшим шагам приведёт его этот листочек.
Но на уровне системной логики, внутренних механизмов, функционала - заранее всего предусмотреть невозможно. Ради новой кустистой ветви нововведений порой приходится перекорчевывать целые разделы кода, менять логику внутреннего взаимодействия отдельных узлов и элементов, а добавление новых функций приводит к созданию новых и обновлению старых связей.
Вся эта закулисная работа прозрачна и невидима внешнему пользователю, для него Планфикс растет последовательно и гармонично. Но внутри система может не просто добавлять новый модуль или функцию - но перестраивать все ядро, движок или несколько отдельных механизмов сразу.
И хорошо бы - не вдаваясь в детали на уровне кода - одним взглядом увидеть, с какими частями системы связаны изменяемые элементы, чтобы учесть это в разработке. Чтобы понять, куда подключать новый функционал, в каких местах обновлять изменения, от чего отключать устаревшее или ненужное. Откуда и в каком порядке смотреть, если что-то работает не так, как нужно.
Вот о чем-то таком хотел поговорить и узнать вашего опыта в решени такой задачи :) Поделитесь, пожалуйста, какие используете инструменты для визуализации состояния системы / проекта. Не обязательно привязанные к исходному коду - это может быть и тот же ручной майнд-мап. И если используете, то в каких именно плоскостях наблюдаете, какие стороны и взаимосвязи системы / проекта в них отражаете? (процессы? функции? базы данных? ресурсы? потоки и хранилища данных? спецификации и протоколы? что-то совсем ноу-хау или вообще иное?)
Буду признателен за ваш опыт, мысли, наблюдения :)
И чтобы вернуться к теме визуализации и майнд-карт в Планфиксе.
Я думаю, что если есть инструменты или хотя бы решения, которые позволяют видеть общую структуру разрозненных частей и взаимосвязей внутри продукта / проекта. То это были бы не просто полезные инструменты по той или иной методологии. Но интересные наработки, в которых можно подсмотреть принципы визуализации коллективной работы. Пусть даже это работа функционала внутри программного продукта, а не команды вокруг него.
Поэтому буду рад, если что-то из моих слов сможет приблизить нас с вами к дальнейшему развитию визуализации Планфикса как универсального конструктора коллективной работы. :-)