| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Вёрстка веб-сайтов > Дизайн планировщика |
| Автор: Caramel 14.9.2007, 20:09 |
| Я не знаю где такую тему следовало бы создавать, по смыслу она вроде подходит для этого раздела. Итак... В скором времени мне предстоит дизайнить некий планировщик (предполагается вебинтерфейс). Беда в том, что я никогда с такими вещами не сталкивалась и слабо представляю как оно должно выглядеть. Накидайте ссылок, товарищи! Хочется сделать не только красиво, но и удобно   (проджект менеджер и оутлук не предалагать  ) |
| Автор: DezmASter 15.9.2007, 00:46 |
| Caramel, планировщик чего? Если работы - то тут беспорный лидер - http://www.basecamphq.com/ |
| Автор: Str!pe 15.9.2007, 09:47 | ||
Caramel, надо ТЗ смотреть. Это проектировка больше для начала чем дизайн. Если есть спроектированный вариант, то все гораздо проще. |
| Автор: Caramel 15.9.2007, 16:09 |
| DezmASter, работы, времени, ага. Спасибо за ссылку! Str!pe, увы тз показать не могу. |
| Автор: dm9 21.9.2007, 21:09 |
| Новоиспечённый стартап в этой области: http://wygd.ru/. Вот ещё: http://www.rememberthemilk.com/ - личное планирование, недоработок куча, правда (было месяц назад). На практике пользоваться было неудобно. Бэйскамп (http://www.basecamphq.com/) и их та-да лист (http://tadalist.com/) тоже не впечатляют, если честно. Работать в реальности невозможно. Но каждому своё, сейчас они модные. Также нужно посмотреть бег-трекеры для разработчиков: - Eventum (http://dev.mysql.com/downloads/other/eventum/features.html) - Fogbugz (http://www.fogcreek.com/FogBugz/) - Bugzilla (http://www.bugzilla.org/) - Mantis (http://www.mantisbt.org/) - Jira (ссылку на это давать даже не хочу...) Только это руками потрогать надо... И пусть даже задачи, решаемые этим софтом, немного отличаютя, всё равно, много идей хороших. И не очень. Надо общаться с теми, кто использует. http://www.artgorbunov.ru/bb/information/gantt/ - тоже в тему будет, возможно. Можно много ещё найти, попсовая сейчас тема. 'Task management', 'manage tasks' и т. п. Только искать надо в англоязычном инете. В русском если что и есть, то либо переведённое, либо вообще нет. Ну, мало, по крайней мере. Вот ещё нашёл безобразие какое-то: http://todoist.com/ (похоже на ta-da list). И ещё сайт - там, кажется, собраны обзоры, но сейчас он висит: http://lifehacker.com/software/task-management/todoist-online-task-manager-238687.php А вообще, моя мечта. Не приступил пока к реализации, но оно всё близится Здесь важно понимать направление планировщика. Личный, проектный, если проектный, то это управление проектом или начальное его планирование. Нужно ли переназначение задач и проч. Про личное планирование (не касательно веба, просто про жизнь %)) хорошо написано в книгах у Брайана Трейси. Например, я мечтаю о такой простейшей штуке: расчерченная на 4 квадрата область (2х2). По одной оси срочность (срочно, не срочно). По другой - важность (важно, не важно). И драг-энд-дропом перетаскивать задачи. Это самый простой приём для личного планирования из его "Точки фокуса". Ну и так далее. Курили мы как-то на тему объединения представлений: линейный, иерархичный, Гантт, календарь. Интеграция баг-трекера с проджектом и Excel-ем. Можно много классного сделать. Если интересно - могу пообщаться на эту тему, но только если голосом... |
| Автор: Caramel 22.9.2007, 09:26 |
| dm9, ооооо, спасибо ))) |
| Автор: maximkr 22.9.2007, 12:27 | ||
Хм, а http://www.trackstudio.ru не смотрели случаем? Наш продукт Иерархии есть, экспорт в эксель/ms project - тоже. По поводу интеграции багтрекера с управлением проектами (и почему тут ничего нормального пока не написали) посмотрите тут мою статью: http://www.trackstudio.ru/forum/bug-tracking-project-management-issue-tracking-issue-1685.html Концепции системы лучше всего описаны в первой главе "неофициального руководства", что на странице с документацией. Еще есть http://www.trackstudio.ru/products-comparison.html, как с одной из самых продвинутых линейных систем, к Bugzilla/Mantis/Fogbugz все это относится еще в большей степени. Системы типа basecamp/wygd - это отдельное направление, не такое уж и новое. Atlassian с этого начинала (посмотрите ранние testimonials на JIRA), но потом они все равно вернулись к гонке функциональности. |
| Автор: dm9 22.9.2007, 21:08 |
| maximkr, смотрел, конечно. Правда, не очень долго. И сравнение с Жирой читал даже, помнится. Думал даже команду перевести на вашу систему. Здесь важно понимать целевую задачу. Мне интересны две области: личное планирование и управление работой малой команды (до 10 человек). Ваша система оказалась слишком тяжеловесной для малой команды. Ощущение, что проектировщики много работали с Жирой (я сам с ней не работал, просто смотрел интерфейс - он ужасен, конечно), и сделали Жиру, но лучше. Нам нужна лёгкая система, а здесь ото всюду торчали ненужные нам рычаги. Управление задачами (первое, что нам нужно) - очень навороченно. Наверняка ваша система (как и Жира) подходит тем или иным образом к разработке "большого" ПО. Но команде, умещающейся в одной-двух комнатах, проще всё же Eventum. Да и то не всегда. Экспорт в Excel - это не то. И в Проджект - тоже. Я не про это говорил. И иерархию, кажется, не ту имел в виду. Для меня важна лёгкость системы для решения простых задач. Кодга я планирую новый проект, я пользуюсь excel-ем. Помните статью Джоэла Спольски про планирование? Вот я хочу такую простую штуку. Simple things simple, complex things possible. А если ещё найти решение, как начальный план проекта интегрировать с баг-трекингом - вообще будет супер. Но вот проблема: начальный план иерархичен (дерево там, дерево задач), а баги зачастую - отдельны, не привязаны к нему. Вот и получается: есть дерево задач, а есть порядок их исполнения. И есть привязка к календарю... И переключаться между этими представлениями было бы ой как здорово. Не хватает вашей системе ещё одной штуки. Я не умею это объяснять, но называю это обычно "фаном". Если у разработчиков есть "фан" - системой приятно пользоваться. Если нет - получается классная, отточенная система, но смотреть на которую без слёз нельзя. Но это уже личное отношение к ПО, не слушайте меня. Добавлено через 2 минуты и 25 секунд Статью посомтрю, но попозже. Спасибо. Добавлено через 8 минут и 6 секунд Просмотрел статью. Собственно, моя мечта - интеграция баг-трекига с PM. Я не разбираюсь в больших разработках, но уверен, что для малых команд и проектов с первым релизом за 3-6 месяцев это реально. Не уверен, что это нужно делать под веб, но интеграция просится, и видна. |
| Автор: dm9 22.9.2007, 21:24 |
| Прошу прощения, кое-что невнимательно прочитал в статье, поэтому последнее добавление обнуляю. Но суть понятна... |
| Автор: dm9 22.9.2007, 22:40 |
| Всё же ещё напишу пару слов, зацепило. В статье есть две фразы. 1. "Это приводит к таким вопросам как: - а можно ли использовать MS Project для управление разработкой ПО - можно ли использовать TrackStudio вместо MS Project - что лучше - MS Project или TrackStudio Предметная область у этих систем очень похожа (контроль задач и сроков), но в большинстве случаев они не могут заменить друг друга". 2. "TrackStudio позволяет интегрировать issue tracking и project management". Мне эти фразы показались противоречивыми, поэтому я много раз перечитал статью, прежде чем понял (кажется, понял) идею автора. Непонятно вот что: неужели невозможно увязать оба представления (взгляд "сверху" для заказчика, или просто для общего контроля разрабокти, и баг-трекинг, самый низкий уровень) в одном ПО? Вы ориентированы на большие проекты, и там, возможно, нельзя. Не знаю. Но для малых проектов это скорее возможно, чем наоборот. Всё, что, например, мне нужно, это список задач "в очереди" (приоритеты здесь не помогут, очередь - это не приоритеты, это сверху вниз - возможно, в виде дерева), возможность вставить в очередь (или просто подвесить на приоритет) новый баг, возможность видеть и менять список ближайших задач каждого программиста (это уже линейная развёртка). Ну и к этому - отчёты. Там ещё пара мелочей, и надо понять, как это увязать в интерфейсе грамотно (думали, даже пара идей была...) В общем, чего хочется - возможность мешать и возможность не мешать задачи из начального плана с багами. Это если совсем грубо. Возможно, я один такой, кому нужен такой функционал? Интересно. Но не думаю. Трэк-студия этого делать не позволяет (если позволяет, то извините, просто там так много кнопочек, что я запутался). В общем, Simple things simple не выходит... |
| Автор: DezmASter 22.9.2007, 23:33 |
| Извиняюсь - я ошибочно дал не ту ссылку на http://www.basecamphq.com/ в предыдущем посте. Пофиксил. |
| Автор: Wowa 22.9.2007, 23:38 |
| Ребята, вам не кажется, что беседа немного не в том разделе? У нас есть спец. раздел под "Управление проектами". http://forum.vingrad.ru/forum/project-management.html |
| Автор: dm9 22.9.2007, 23:52 |
| Можно разбить тему. Но убейте меня, если я говорил не о дизайне. Правда, я не уверен, что о веб. |
| Автор: Caramel 22.9.2007, 23:55 | ||
| Wowa, винград разросся до такой степени, что я уже давно ни в чем не уверена, когда создаю новую тему. В любом случае сейчас я получаю интересные ответы на свои вопросы. Боюсь, что в разделе УП меня начнут пичкать совсем сухой техничной информацией. Мне немного другое нужно Добавлено через 30 секунд
Нет! Мне потом куски темы по всему Винграду искать?! |
| Автор: Wowa 23.9.2007, 08:01 | ||||||
Это я понял, просто не думал, что:
т.к.
Пусть тут тогда остается тема. Главное ее тегировать правильно. |
| Автор: maximkr 23.9.2007, 09:09 | ||||
На самом деле мы очень мало работали с Jira, система писалась под впечатлением от ClearQuest после нескольких лет Mantis. А сравнение на сайте именно с Jira, т.к. она сейчас стала очень популярной и про нее спрашивают. В Jira довольно простое ядро (в целом повторяющее bugzilla), на которое потом навешаны workflow, субтаски, кастом-поля, security, и т.п. - эти фичи писались когда система была уже почти готова. Сложность Jira - это сложность большого количества компонентов (очень много таблиц в БД, экранных форм, понятий и т.п.). В TrackStudio компонентов в разы меньше, а сложность образуется за счет связей между ними. Например, можно - написать скрипт, который считает время от внесения задачи в систему до ответа пользователей. - использовать этот скрипт для вычисления значения кастом-поля. - кастом поле использовать в фильтре, который вычисляет приоритетные задачи - на основе фильтра сделать правило подписки, которое будет присылать менеджеру саппортные задачи, на которые слишком долго отвечали. Лет 5 назад в Jira был вполне приятный интерфейс, который позволял "читать" багрепорты не вдаваясь в технические детали. Т.е. системные поля (состояние, ответственный, etc) - слева, под ними - операции, а справа описание задачи и комментарии пользователей как один большой документ. По сравнению с дизайном большинства других систем, это был большой шаг вперед - почитайте отзывы о Jira (большинству из них уже несколько лет) - люди выбирали Jira из-за интерфейса, а Atlassian позиционировала систему как "brilliantly simple". Но со временем количество фич росло, в старый интерфейс оно все не влезало, и сейчас там каша (которая следствие каши в самой системе). Что они теперь с этим делать будут и что тут вообще можно сделать - не знаю. Вот еще http://maximkr.livejournal.com/6286.html Basecamp и другие подобные системы - они сейчас в начале того пути, который уже почти прошла Jira. Смогут ли они отбиваться от feature requests и оставить систему простой - посмотрим. Про это Спольский писал - 80% клиентов в самом деле нужны 20% фич, но эти 20% фич для всех разные, поэтому давление пользователей есть и будет. По поводу крупных команд - весь проект TrackStudio сейчас делают 4 человека (включая меня), больше 5 человек вообще никогда не было. Используем TrackStudio в смежном проекте - там 8 человек. Хотя, конечно, наиболее типичный клиент TrackStudio - компания от 50 пользователей, просто потому что для больших команд преимущества TrackStudio наиболее заметны.
Да, я понимаю. Ну и какой может быть фан, когда текущая версия 3.5.19 - тут только героическая стойкость поможет В 4.0 интерфейс будет сильно другой, а многие "ручки" попрятаны - должно помочь в плане удобства и приятности использования. |
| Автор: Caramel 23.9.2007, 09:26 |
| Wowa, спасибо. Дело в том, что дизайнить планировщик оказался не просто созданием шкурки. У меня нет точного эскиза от заказчика, и приходится лазить по разным проектам, смотреть что и как сделано там, а потом переворачивать для своих целей. К сожалению не вникнув в логику невозможно сделать красиво и удобно. Вот и вникаю Возможно я погорячилась на счет разделения темы. Но пока очень удобно, что все это вместе. |
| Автор: maximkr 23.9.2007, 18:32 | ||||
Да, у issue tracking и project management одна предметная область, но разные "точки фокуса": основа issue tracking - это workflow (состояния, ответственные,...), а основа project management - диаграммы Гантта (иерархия задач, зависимости между работами и календарный план). Issue tracking ориентированы скорее в прошлое, а project management - в будущее. Есть много систем, претендующих на issue tracking и project management одновременно, но я не знаю ни одной, сочетающий workflow-движок уровня TrackStudio и project management-функциональностью уровня MS Project. TrackStudio - это issue tracking в чистом виде, project management функциональность тут самая минимальная и получилась почти случайно (иерархия задач, экспорт в ms project), но ведь в большинстве issue tracking систем нет и этого. Т.е. я предлагал рассматривать TrackStudio в качестве "интегрированного" решения для issue tracking + project management не потому, что у нас хорошо, а потому что у остальных еще хуже.
Нас просили сделать очередь несколько раз - все упирается в то, что для сортировки задач в очереди нужно гарантировать, что все видят одну и ту же очередь Если менеджер проекта A указал программисту порядок выполнения задач, менеджер проекта B указал тому же программисту порядок выполнения задач в своем проекте, то кто укажет программисту в каком порядке задачи в этих проектах делать - непонятно.В TrackStudio для решения этой проблемы используется понятие "ответственного" - если сейчас эту задачу делать не надо, то ответственным за нее является менеджер. Если задачу назначили на программиста - можно делать. Если назначили несколько задач - можно делать в любом порядке. Если какую-то задачу раньше нужно было делать, а сейчас - нет, то менеджер меняет ответственного с программиста на себя (и потом может назначить ее на кого-то другого). Т.е. программистам не интересна очередь работ на неделю вперед, указания что именно он может/должен делать прямо сейчас вполне достаточно. А вот менеджер уже может организовывать _свою_ очередь как ему удобнее. |
| Автор: dm9 24.9.2007, 12:05 | ||||||
Вы пытаетесь решить общую задачу. Принцип хорошего дизайна -- не грузить пользователя обобщённым (крутым, функциональным и удобным после 2 лет использования) решением, а дать ему тот минимум, который необходим в 80% случаев (да, да, помню, что у всех свои 20%, но это не повод не работать над дизайном). У нас в команде нет нескольких менеджеров на одного программиста -- все задачи проходят через тим-лида. Я при этом работал и в ситуации с несколькими менеджерами -- но в этом случае у программиста всегда есть понятие основного проекта. А всё остальное -- чистой воды баг-трекинг. То есть частные решение прослеживаются, и даже примерно понятно, как это организовать. А вы хотите сделать динозавра на все случаи жизни. Не так?
Ошибаетесь. К сожалению, и к счастью, не все люди лемминги. Я заметил, что программисты работают гораздо эффективнее, если они понимают весь процесс (вероятно, просто растёт чувство отвественности -- не знаю). Сейчас это у нас решается так: "Почитай ТЗ", и ещё общими собраниями (часто спонтанными), на которых я рассказываю общие планы на будущее. Как стратегические, так и тактические. Для тактики очередь была бы очень нужна. Кроме того, когда есть свободная очередь (не назначенные никому задачи), разумный программист может сам сориентироваться, чем ему заняться, если он освободился от текущей задачи. Разумеется, это согласовывается с ПМ-ом, но, опять же, растёт общее понимание проекта, ответственность, и, как следствие, отношение к проекту.
Приоритетами? Это же жутко неудобно. |
| Автор: maximkr 24.9.2007, 15:52 | ||||||||||
Тут проблема такая, что если пользоватею в самом деле нужен минимум - он скорее всего возьмет open source. Я где-то видел список имеющегося bug tracking софта (большая часть - open source) - там было больше 300(!) продуктов.
А у нас такое частенько бывает. Например, работник занимался одним продуктом, потом его перебросили на другой, потом какие-то доработки по первому появились. Или у менеджера по разработке один список, а у менежера по саппорту - другой.
Совсем не хотим. Если такое где-то получается, то это не специально и мы с этим боремся
Не знаю, посмотреть весь перечень задач по проекту никто не запрещает, но большого интереса к чужим задачам что-то не замечаю. Может быть это от проекта или людей зависит - сложно сказать. Вариант с "разумный программист может сам сориентируется" бывает редко - у разумных обычно работы обычно на недели вперед.
Я сам просто помню о самых приоритетных задачах, заинтересованные стороны забыть не дают. |
