Форум сервиса Планфикс

не обращать внимания на большинство предложения, т.к. простота ресурса тогда усложниться и потеряет свою привлекательность

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

Официальный ответ:
Спасибо за это предложение, оно всем нам очень по душе :)

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

Да, от этого подхода никуда не деться. Кроме этого, мы делаем инструменты для самостоятельной "допилки" ПланФикса под нужды конкретной компании. Пока из этих инструментов реализованы Аналитика и Отчеты (оба - в первой версии, но уже достаточно функциональные).
В будущем появится возможность вводить новые реквизиты на уровень проекта и задачи. Как это будет выглядеть, уже сейчас можно представить, посмотрев на карточку сотрудника - там есть возможность добавлять новые поля (карточка сотрудника - Редактировать - Дополнительные данные).

Решением этого вопроса, на мой взгляд, является "вынос" некоторого функционала в отдельные модули. А для пользователя реализация "кнопки" "Настройки", где можно будет удалять, добавлять, скрывать, деактивировать, ограничивать доступ и т.д. (добавьте сами свои пожелания) тот или иной модуль (функционал).

Такой подход часто используется, но, как показывает практика, он далеко не идеален.
Мы для себя выбрали другой путь, который позволит сделать ПланФикс с одной стороны достаточно гибким, а с другой - сохранить простоту.
Первые шаги на этом пути сделаны - это наш функционал Аналитика и Отчеты. Остальное - в планах на этот год.

Странно. Видимо модульность не была запланирована изначально. Т.к. "неидеальность" может заключаться только в сложности реализации. А с точки зрения пользователя системы, на мой взгляд, как раз наоборот идеально показывать пару кнопок и пару списков, а остальной ворох "наворотов" пусть сам включает по мере возникновения необходимости или изучения системы.
К слову о простоте - лично мне не понятно, зачем было выносить отчеты в отдельный пункт, если отчеты - это частный случай аналитики. Похоже необходимость аналитики появилась позже. :)

Неидеальность в случае с модульным подходом обычно проявляется не в сложности реализации, а в сложности интеграции модулей между собой на уровне данных и интерфейсов.
Если Вы уже посмотрели какое-то количество систем с модульным подходом, то наверняка заметили, что схожие вещи в разных модулях системы зачастую делаются по-разному, а иногда данные, введенные в одном модуле, нельзя использовать в другом.
Вроде бы, в таких случаях все можно списать на криворукость архитекторов системы, однако я думаю, что дело в другом. Как сторонник теории развития систем, я вижу в этом ошибку выбора уровня интеграции - модуль это слишком "крупная" система, именно поэтому при интеграции модулей автоматически возникает столько проблем.
В ПланФиксе мы пробуем проводить интеграцию на более "низком" уровне - на уровне объектов типа задача, действие и т.п. В перспективе это позволит выстраивать достаточно сложные структуры управления реальными бизнес-процессами, без усложнения самой системы.
Такой подход имеет свои нюансы, как в разработке, так и в использовании. Но нам он кажется правильным.
Чтобы не говорить голой теорией, приведу простой пример - часто в системах управления проектами встречаются модули "Задачи", "Дела", "Встречи". В одной и той же системе в модуле "Задачи", например, можно сделать повторяющуюся задачу, а в модуле "Встречи" - нельзя. Почему? Потому что это два разных модуля, и при разработке встреч архитектор посчитал, что это не нужно. При этом несложно заметить, что на 80% функционал всех перечисленных модулей пересекается.
В ПланФиксе, если Вы обратили внимание, вместо этих трех модулей есть только одна сущность - "Задачи". В зависимости от контекста, задачи можно использовать и как задачи, и как дела, и как встречи. Минус такого подхода – у нас это всегда называется "задачи". Плюс - можно использовать весь разработанный функционал, в зависимости от ситуации. Например, я запланировал себе "дело", а потом решил, что лучше перепоручу его кому-то (а значит, оно плавно становится "задачей"). Я знаю системы, в которых это попросту невозможно - а в ПланФиксе я просто добавляю нового исполнителя, и моя личная задача вдруг становится уже проблемой кого-то другого :)
Аналогичным образом происходит и со Встречами – у нас это тоже задачи; просто поставьте задачу в Ежедневнике на определенное время, добавьте к ней соисполнителей и получите встречу.
Пример может быть не совсем красивый, зато с использованием того фукнционала, который уже реализован. В скором будущем у задач появится новая, более ширкоая область использования, они станут еще гибче – при этом новые модули в системе не появятся.
--
Что касается Отчетов и Аналитики, то задуманы они были одновременно, именно как две части одного целого: с помощью аналитики можно вносить информацию в систему, а с помощью отчетов - собирать и анализировать в удобном настраиваемом виде.

По поводу аналитики, это всего лишь мое мнение - т.е. мне кажется удобней было бы видеть в разделе "Аналитика" в списке слева "Отчеты".
--
Под сложностью реализации как раз и имел ввиду сложности интеграции модулей между собой на уровне данных и интерфейсов.
--
По поводу модулей. Уточню. На самом деле под модулем имел ввиду просто набор функций или группу функций или группу функционала, если хотите. Идея заключалась в том, чтобы эту группу, скажем, в настройках системы, можно было бы за раз отключать. Т.о. пользователю не выводился бы "лишний" функционал. Ни в коем разе не хотел кого-то упрекать в криворукости - вроде бы мы здесь обсуждаем полезные дополнения к ПланФиксу :) Вы выбрали свой путь и как у вас там внутри всё будет организовано - решать вам. В системе увидел связи между сущностями и их объектами, а группу функционала, производящего над этими связями какие-то операции, мне пришло в голову назвать модулем :)
По поводу дел-задач-встречь, по-моему не важно как обозвать связь сущность-объект, главное чтобы можно было с ними что-то делать (и многое!). А вообще, было бы здорово предоставить пользователю решать самому как эта связь будет называться. Правда тогда ПланФикс будет чем-то большим, чем инструментом управления бизнесом. :)

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