Большое спасибо за хороший совет. Мы лишь озвучили наши мысли и планы, но вы правы что то, что вы написали будет как MVP. И да, экспорт уже предусмотрен нами.
Теперь понял, спасибо.
1. Многие не планируют, а точнее планируют по итерациям или на дэйли скрам митингах задачи и таким образом вполне реализуют свои проекты. т.е. по моему скромному ИМХО — это сравнение теплого и мягкого: планировать критический путь проекта в каком-либо инструменте и причины по которым проекты могут разваливаться.
2. Вы в каком то смысле очень правы, если мы возьмем задачи из таск-трекера и просто декомпилируем их в виде MindMap, то получим скорее всего плоский список :). Наш подход как раз предлагает начинать «заводить» задачи в проект используя графическое представление, и как показывает уже практика, задачи имеют от 2-х до 5 уровней.
3. Вы утверждаете что используя Ганта, вы решаете задачу, чтобы проект не развалился. И, соответственно, мы не отрицаем, что структурируя проект в Ганте, в обычном виде в таск-трекере или в виде MindMap нужно думать и структурировать проект так, чтобы каждая «корневая ветка» могла считаться законченным функционалом.
4. И есть немаловажное отличие между Гантом и структурой проекта в MindMap. Планируя проект в Ганте, вы можете функционал одного экрана, например «Экран личного кабинета пользователя», «физически» разбить… отдельно на APi, на UI, на разработку и т.д. т.к. эти задачи действительно паралелятся и делаются разными командами. Вы действительно, можете спланировать работу так, что сделаете проект за минимальный календарный срок. Но при этом, если у вас отдельный Гант (или группа в рамках одного Ганта) для серверных разработчиков, для дизайнеров и для фронтенда, то, очень сложно понять готов ли функционал. Структура в виде MindMap, предлагает описать бизнес фичу и видеть, на сколько она готова. Т.е. одно другому не мешает, можно представлять проект в виде MindMap и видеть «законченность» фич, при этом имея даты старта и окончания задач, планировать их паралельное выполнение.
Мне кажется, чем более унифицированный свод правил, тем хуже он работает. Вроде бы сохранение интеллектуальной собственности защищать хорошо в течении 50 лет, но это действительно так отвратительно работает с давно покинувшими нас композиторами.
Резюмируя: подобный закон — это хорошо, но отдельные моменты его применения достойны гореть в аду.
Немного не так. Купить телевизор зная что когда он сломается, ждать Вам его ремонта и ждать.
А на счет бессмысленности — я с Вами безусловно согласен, спору нет, но тут как «Эффект бабочки» — каждое действие имеет последствия. Чем больше мы стремимся изменить ситуацию, тем быстрее она изменится. Я оптимист и хочу верить, что все-таки усилия людей не напрасны.
И что значит? Просто даже не пробовать что то изменить?
Звучит как: купил телевизор с пультом, сломался… наши сервис центры 2 месяца чинили… проще вернуться к старому телевизору и плоскогубцами каналы переключать.
1. Многие не планируют, а точнее планируют по итерациям или на дэйли скрам митингах задачи и таким образом вполне реализуют свои проекты. т.е. по моему скромному ИМХО — это сравнение теплого и мягкого: планировать критический путь проекта в каком-либо инструменте и причины по которым проекты могут разваливаться.
2. Вы в каком то смысле очень правы, если мы возьмем задачи из таск-трекера и просто декомпилируем их в виде MindMap, то получим скорее всего плоский список :). Наш подход как раз предлагает начинать «заводить» задачи в проект используя графическое представление, и как показывает уже практика, задачи имеют от 2-х до 5 уровней.
3. Вы утверждаете что используя Ганта, вы решаете задачу, чтобы проект не развалился. И, соответственно, мы не отрицаем, что структурируя проект в Ганте, в обычном виде в таск-трекере или в виде MindMap нужно думать и структурировать проект так, чтобы каждая «корневая ветка» могла считаться законченным функционалом.
4. И есть немаловажное отличие между Гантом и структурой проекта в MindMap. Планируя проект в Ганте, вы можете функционал одного экрана, например «Экран личного кабинета пользователя», «физически» разбить… отдельно на APi, на UI, на разработку и т.д. т.к. эти задачи действительно паралелятся и делаются разными командами. Вы действительно, можете спланировать работу так, что сделаете проект за минимальный календарный срок. Но при этом, если у вас отдельный Гант (или группа в рамках одного Ганта) для серверных разработчиков, для дизайнеров и для фронтенда, то, очень сложно понять готов ли функционал. Структура в виде MindMap, предлагает описать бизнес фичу и видеть, на сколько она готова. Т.е. одно другому не мешает, можно представлять проект в виде MindMap и видеть «законченность» фич, при этом имея даты старта и окончания задач, планировать их паралельное выполнение.
Резюмируя: подобный закон — это хорошо, но отдельные моменты его применения достойны гореть в аду.
А на счет бессмысленности — я с Вами безусловно согласен, спору нет, но тут как «Эффект бабочки» — каждое действие имеет последствия. Чем больше мы стремимся изменить ситуацию, тем быстрее она изменится. Я оптимист и хочу верить, что все-таки усилия людей не напрасны.
Звучит как: купил телевизор с пультом, сломался… наши сервис центры 2 месяца чинили… проще вернуться к старому телевизору и плоскогубцами каналы переключать.