Почему стоит усовершенствовать сущность проектов
Добавлено: 24.07.2012 09:38
Приветствую!
Хочу затронуть вышеупомянутую тему. Сначало я подумал о том чтобы описать это обыденным списком причин, но пришел к тому что причина лишь одна: Вы разрабатываете универсальный сервис.
Думаю, такой список не привлек бы к себе много внимания, а так как я заинтересован в развитии Вашего сервиса, поскольку планирую и в дальнейшем его использовать, то мне хочется чтобы в нем были реализованы функции которые бы удовлетворяли мои потребности. Так что я решил более подробно порассуждать на эту тему и пришел к мысли описать пример ситуации в которой могла бы использоваться возможность создания иерархий проектов.
Предположим что существует некоторая компания, занимающаяся разработкой программных продуктов и их сопровождением. Разработчики в комманде работают по методологии Agile.
Используя ПланФикс администратор мог бы создать следующую структуру:
.. Проекты
.. .. Приложения финансового учета "Ласточка"
.. .. .. Постановка задач
.. .. .. Разработка
.. .. .. Сопровождение
.. .. .. .. Обучение персонала
.. .. .. .. Техподдержка
.. .. .. .. Раскрутка
.. .. Веб-сайт "Оратор"
.. .. .. Постановка задач
.. .. .. Разработка
.. .. .. .. Scrum 1
.. .. .. .. Scrum 2
.. .. .. .. ...
.. .. .. .. Scrum 11
.. .. .. .. Scrum 12
.. .. .. Сопровождение
.. .. .. .. Раскрутка
.. .. .. .. Техподдержка
.. Развитие компании
.. .. Реклама
.. .. .. Онлайн
.. .. .. Оффлайн
.. .. .. .. Телевидение
.. .. .. .. Баннеры
.. .. .. .. Визитки
.. .. Персонал
.. .. .. Набор персонала
.. .. .. Отдых
.. .. .. Обучение
Таким образом, элементы первой вложености являлись бы группами проектов, элементы второй вложености - проектами, а все остальные принадлежали бы к сущности задач внутри которых ставились бы реальные задачи.
Лично я подразумеваю под проектом группу задач обьедененных одной темой, задачу же - как максимально конкретно поставленное задание. Элемент "Scrum N" еще можно было бы создать как задачу - у него есть сроки, конкретные требования и прочее, но "Разработка", "Сопровождение", "Обучение" и т.д. Разве это можно назвать задачами? Реклама компании - это легко можно назвать проектом, но что если за оффлайн и онлайн рекламу отвечают разные люди и продвижения в этих двух направлениях идет совершенно разными, не пересекающимися путями? Приложение может работать в то время когда оно еще разрабатывается (ОБТ или ЗБТ (открытый или закрытый бета-тест)), Ваш сервис тому подтверждение. Но не ужели удобно выдавать задачи по ответам любопытным пользователям и разработке нового функционала в одной папке?
Также, сразу же, хотелось бы предложить несколько других расширений для сущности проектов: 1. Шаблоны для проектов. На примере той-же компании: Каждое приложение будет содержать в себе структуру содержащую такие элементы как "Постановка задач" (или работа с заказчиком), "Сопровождение" и "Разработка" и было бы удобно начинать проект уже с готового шаблона. 2. Общий доступ к проектам. Можно было бы обьединить проект "Телевидение" с компанией телеканала, или один из подпроектов проекта "Отдых" с компанией предоставляющей услуги по организации развлекательных мероприятия.Благодарю за внимание!
--= Переписка со службой поддержки =--
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Здравствуйте, Станислав!
1. Если уйти от названия "Задача", есть ли какие-то вещи, которых Вам не хватает в текущей системе иерархии ПФ (группа проектов-Проект-Задача - Подзадачи)?
Перефразирую для пущей ясности: насколько я понял, Вы бы хотели видеть в ПланФиксе иерархию проектов неограниченной вложенности. У нас есть иерархия задач неограниченной вложенности. Чем это принципиально отличается для Вас кроме названия?
2. Шаблоны для проектов будут, пока в этой ветке развития мы остановились на шаблонах деревьев задач, которые решают большую часть кейсов. Нам нужен был еще один релиз, чтобы сделать шаблоны проектов, но мы решили пока отложить это дело и использовать этот релиз для развития по другой ветке.
3. Если я Вас правильно понял, то это и сейчас есть в ПланФиксе - прямо сейчас мы с Вами общаемся каждый в своем аккаунте и работаем по сути над общим делом. Просто проекты могут называться в наших аккаунтах по-разному: для нас это "Поддержка пользователей", а для Вас не знаю как :) Но проекты и должна в разных аккаунтах называться по-разному, т.к. как правило каждая из компаний-участников видит его под своим ракурсом.
--------------------------------------------------------
Я > Дмитрий Гончаренко
--------------------------------------------------------
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Давайте на примере: представим что компания А решила заказать себе сайт. Она создает проект "Разработка сайта", в котором изначально есть задачи-обсуждения, в которых сотрудники и руководство компании определяют каким же должен быть сайт, какие разделы в нем будут, готовят тексты и другие материалы для разделов, определяют подрядчика. Вся эта информация внутренняя и касается только компании А.
В какой-то момент она определила, что подрядчиком будет компания Б. Создается одна или несколько задач, в которых исполнителем становятся сотрудники компании Б. Они видят эти задачи в своем аккаунте и относят их к проекту, который у них называется уже по-другому, например "Разработка сайта компании А" - ведь просто "разработок сайта" у компании Б великое множество.
В процессе работы становится понятно, что компании А необходимо сделать промо-ролик для сайта. Для этой цели нанимается компания С и ее ответственному лицу ставится задача все в том же проекте "Разработка сайта". Но компания С не занимается разработкой сайтов, она занимается только промо-роликами. Поэтому когда ее сотрудник получает эту задачу в своем аккаунте, он относит ее в проект "Промо-ролик для компании А".
В итоге, все 3 компании работают над общим проектом, но видят разные его стороны и он по-разному для них называется. Управление на уровне задач позволяет это делать прозрачным для всех участников образом. При этом никто не видит лишних данных - компания Б не видит как проводился конкурсный отбор подрядчика и сколько на самом деле была готова заплатить за сайт компания А. Компания А не видит что на самом деле думают по поводу предложенного ей сценария сотрудники компании С и что они наняли для его изготовления фрилансера из Урюпинска. Ну и так далее.
--------------------------------------------------------
Я > Дмитрий Гончаренко
--------------------------------------------------------
Продолжая тему вложености проектов:
Продолжая тему вложености проектов:
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Хочу затронуть вышеупомянутую тему. Сначало я подумал о том чтобы описать это обыденным списком причин, но пришел к тому что причина лишь одна: Вы разрабатываете универсальный сервис.
Думаю, такой список не привлек бы к себе много внимания, а так как я заинтересован в развитии Вашего сервиса, поскольку планирую и в дальнейшем его использовать, то мне хочется чтобы в нем были реализованы функции которые бы удовлетворяли мои потребности. Так что я решил более подробно порассуждать на эту тему и пришел к мысли описать пример ситуации в которой могла бы использоваться возможность создания иерархий проектов.
Предположим что существует некоторая компания, занимающаяся разработкой программных продуктов и их сопровождением. Разработчики в комманде работают по методологии Agile.
Используя ПланФикс администратор мог бы создать следующую структуру:
.. Проекты
.. .. Приложения финансового учета "Ласточка"
.. .. .. Постановка задач
.. .. .. Разработка
.. .. .. Сопровождение
.. .. .. .. Обучение персонала
.. .. .. .. Техподдержка
.. .. .. .. Раскрутка
.. .. Веб-сайт "Оратор"
.. .. .. Постановка задач
.. .. .. Разработка
.. .. .. .. Scrum 1
.. .. .. .. Scrum 2
.. .. .. .. ...
.. .. .. .. Scrum 11
.. .. .. .. Scrum 12
.. .. .. Сопровождение
.. .. .. .. Раскрутка
.. .. .. .. Техподдержка
.. Развитие компании
.. .. Реклама
.. .. .. Онлайн
.. .. .. Оффлайн
.. .. .. .. Телевидение
.. .. .. .. Баннеры
.. .. .. .. Визитки
.. .. Персонал
.. .. .. Набор персонала
.. .. .. Отдых
.. .. .. Обучение
Таким образом, элементы первой вложености являлись бы группами проектов, элементы второй вложености - проектами, а все остальные принадлежали бы к сущности задач внутри которых ставились бы реальные задачи.
Лично я подразумеваю под проектом группу задач обьедененных одной темой, задачу же - как максимально конкретно поставленное задание. Элемент "Scrum N" еще можно было бы создать как задачу - у него есть сроки, конкретные требования и прочее, но "Разработка", "Сопровождение", "Обучение" и т.д. Разве это можно назвать задачами? Реклама компании - это легко можно назвать проектом, но что если за оффлайн и онлайн рекламу отвечают разные люди и продвижения в этих двух направлениях идет совершенно разными, не пересекающимися путями? Приложение может работать в то время когда оно еще разрабатывается (ОБТ или ЗБТ (открытый или закрытый бета-тест)), Ваш сервис тому подтверждение. Но не ужели удобно выдавать задачи по ответам любопытным пользователям и разработке нового функционала в одной папке?
Также, сразу же, хотелось бы предложить несколько других расширений для сущности проектов: 1. Шаблоны для проектов. На примере той-же компании: Каждое приложение будет содержать в себе структуру содержащую такие элементы как "Постановка задач" (или работа с заказчиком), "Сопровождение" и "Разработка" и было бы удобно начинать проект уже с готового шаблона. 2. Общий доступ к проектам. Можно было бы обьединить проект "Телевидение" с компанией телеканала, или один из подпроектов проекта "Отдых" с компанией предоставляющей услуги по организации развлекательных мероприятия.Благодарю за внимание!
--= Переписка со службой поддержки =--
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Здравствуйте, Станислав!
1. Если уйти от названия "Задача", есть ли какие-то вещи, которых Вам не хватает в текущей системе иерархии ПФ (группа проектов-Проект-Задача - Подзадачи)?
Перефразирую для пущей ясности: насколько я понял, Вы бы хотели видеть в ПланФиксе иерархию проектов неограниченной вложенности. У нас есть иерархия задач неограниченной вложенности. Чем это принципиально отличается для Вас кроме названия?
2. Шаблоны для проектов будут, пока в этой ветке развития мы остановились на шаблонах деревьев задач, которые решают большую часть кейсов. Нам нужен был еще один релиз, чтобы сделать шаблоны проектов, но мы решили пока отложить это дело и использовать этот релиз для развития по другой ветке.
3. Если я Вас правильно понял, то это и сейчас есть в ПланФиксе - прямо сейчас мы с Вами общаемся каждый в своем аккаунте и работаем по сути над общим делом. Просто проекты могут называться в наших аккаунтах по-разному: для нас это "Поддержка пользователей", а для Вас не знаю как :) Но проекты и должна в разных аккаунтах называться по-разному, т.к. как правило каждая из компаний-участников видит его под своим ракурсом.
--------------------------------------------------------
Я > Дмитрий Гончаренко
--------------------------------------------------------
Да, это не столь принципиальный вопрос. Скорее выражение своего субьективного мнения отностиельно выше упомянутой структуры. В моем понимании задача - это нечто назначеное кому-то что подлежит выполнению. А такие вещи как развитие компании и сопровождение програмного продукта, которые буду висеть в списке задач годами, попросту несколько напрягают. Собственно по этому я и написал это как предложение, а не баг или замечание.1. Если уйти от названия "Задача", есть ли какие-то вещи, которых Вам не хватает в текущей системе иерархии ПФ (группа проектов-Проект-Задача - Подзадачи)?
Перефразирую для пущей ясности: насколько я понял, Вы бы хотели видеть в ПланФиксе иерархию проектов неограниченной вложенности. У нас есть иерархия задач неограниченной вложенности. Чем это принципиально отличается для Вас кроме названия?
Прошу прощения, не досмотрел конфигурации проекта. Думал что совместно можно работать только над задачами, но сейчас увидел что во вкладке "Аудиторы проекта" можно добавить Вашу компанию.3. Если я Вас правильно понял, то это и сейчас есть в ПланФиксе - прямо сейчас мы с Вами общаемся каждый в своем аккаунте и работаем по сути над общим делом. Просто проекты могут называться в наших аккаунтах по-разному: для нас это "Поддержка пользователей", а для Вас не знаю как :) Но проекты и должна в разных аккаунтах называться по-разному, т.к. как правило каждая из компаний-участников видит его под своим ракурсом.
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Понятно. Дело в том, что идеология ПланФикса крутится вокруг понятия "задача". Для нас задача это не совсем то, что принято понимать под этим словом, а скорее некая универсальная сущность.Да, это не столь принципиальный вопрос. Скорее выражение своего субьективного мнения отностиельно выше упомянутой структуры. В моем понимании задача - это нечто назначеное кому-то что подлежит выполнению. А такие вещи как развитие компании и сопровождение програмного продукта, которые буду висеть в списке задач годами, попросту несколько напрягают. Собственно по этому я и написал это как предложение, а не баг или замечание.
Честно говоря, вообще не представляю что получится, если Вы это сделаете :) Скорее всего, ничего особого не произойдет. Вообще, мы придерживаемся той точки зрения, что доступ лучше регулировать не на уровне проекта, а на уровне задачи. Это более гибко, в том числе и если мы говорим о совместной работе в разных аккаунтах.Думал что совместно можно работать только над задачами, но сейчас увидел что во вкладке "Аудиторы проекта" можно добавить Вашу компанию.
Давайте на примере: представим что компания А решила заказать себе сайт. Она создает проект "Разработка сайта", в котором изначально есть задачи-обсуждения, в которых сотрудники и руководство компании определяют каким же должен быть сайт, какие разделы в нем будут, готовят тексты и другие материалы для разделов, определяют подрядчика. Вся эта информация внутренняя и касается только компании А.
В какой-то момент она определила, что подрядчиком будет компания Б. Создается одна или несколько задач, в которых исполнителем становятся сотрудники компании Б. Они видят эти задачи в своем аккаунте и относят их к проекту, который у них называется уже по-другому, например "Разработка сайта компании А" - ведь просто "разработок сайта" у компании Б великое множество.
В процессе работы становится понятно, что компании А необходимо сделать промо-ролик для сайта. Для этой цели нанимается компания С и ее ответственному лицу ставится задача все в том же проекте "Разработка сайта". Но компания С не занимается разработкой сайтов, она занимается только промо-роликами. Поэтому когда ее сотрудник получает эту задачу в своем аккаунте, он относит ее в проект "Промо-ролик для компании А".
В итоге, все 3 компании работают над общим проектом, но видят разные его стороны и он по-разному для них называется. Управление на уровне задач позволяет это делать прозрачным для всех участников образом. При этом никто не видит лишних данных - компания Б не видит как проводился конкурсный отбор подрядчика и сколько на самом деле была готова заплатить за сайт компания А. Компания А не видит что на самом деле думают по поводу предложенного ей сценария сотрудники компании С и что они наняли для его изготовления фрилансера из Урюпинска. Ну и так далее.
--------------------------------------------------------
Я > Дмитрий Гончаренко
--------------------------------------------------------
Думал что совместно можно работать только над задачами, но сейчас увидел что во вкладке "Аудиторы проекта" можно добавить Вашу компанию.
Не упускайте из виду :)Прошу прощения, не досмотрел конфигурации проекта.
Продолжая тему вложености проектов:
Вы ведь могли сделать поддержку пользователей задачей, но посчитали верным назвать это проектом, наверняка из эстетических соображений. А ведь в описаной мною структуре проекта есть такие пункты как "Сопровождение" что по свойствам схоже с "Поддержкой пользователей" и "Разработка", что является аналогом "Разработка сайта".Просто проекты могут называться в наших аккаунтах по-разному: для нас это "Поддержка пользователей"
Можно было бы реализовать это в качестве проектов и группой проектов назначитьОна создает проект "Разработка сайта"
Не упускайте из виду :)Приложения финансового учета "Ласточка"
Продолжая тему вложености проектов:
Вы ведь могли сделать поддержку пользователей задачей, но посчитали верным назвать это проектом, наверняка из эстетических соображений. А ведь в описаной мною структуре проекта есть такие пункты как "Сопровождение" что по свойствам схоже с "Поддержкой пользователей" и "Разработка", что является аналогом "Разработка сайта".Просто проекты могут называться в наших аккаунтах по-разному: для нас это "Поддержка пользователей"
Можно было бы реализовать это в качестве проектов и группой проектов назначитьОна создает проект "Разработка сайта"
Но компания ведь не обязательно занимается лишь разработкой приложений? Есть и другие проекты которыми она занимается и видеть их на одном уровне с разработкой не эстетично. :)Приложения финансового учета "Ласточка"
--------------------------------------------------------
Дмитрий Гончаренко > Я
--------------------------------------------------------
Мог бы, и именно так и сделал бы, если бы такая необходимость появилась. Пока же мне во всех ситуациях хватало имеющейся в ПланФиксе иерархии. Но я понимаю, что мой опыт не является всеобъемлющим и универсальным, поэтому мне интересно мнение других людей. Не хотите вынести этот вопрос на форум?Вы ведь могли сделать поддержку пользователей задачей, но посчитали верным назвать это проектом, наверняка из эстетических соображений. А ведь в описаной мною структуре проекта есть такие пункты как "Сопровождение" что по свойствам схоже с "Поддержкой пользователей" и "Разработка", что является аналогом "Разработка сайта".