1
Управление Проектом / Re: Нормативы на доработку ПО
« : 26 Января 2011, 16:24:31 »
Спасибо, почитаю.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: 1
2
Управление Проектом / Re: Нормативы на доработку ПО
« : 25 Января 2011, 15:33:05 »Тогда мотивируйте. Давайте людям премию за выполнение задач быстрее, чем в макс сроках. Причем сделайте градацию - сделали в 4 раза быстрее, в 3 раза и т.д.Т.к. я работаю в сфере льгот и компенсаций, то могу сказать что планируется премировать за качество сервиса, т.е в данном случае за удовлетворенность потребителей работой IT и качеством продукта.
Но пока нет измеримой системы, то оценить сложно.
Кто это все присваивает? Может пересмотреть данные правила?Проектный офис. Но нет возможности даже узнать пул ресурсов и их занятость.
По поводу декомпозиции: обычно заявки формируются на небольшие доработки (добавить чекбокс, изменить формат отчета), и разделять заявку и отдельные фичи не требуется.
Но даже в таком случае срок составит 30 рабочих дней.
3
Управление Проектом / Re: Нормативы на доработку ПО
« : 25 Января 2011, 11:08:49 »
Elf, спасибо. Буду ждать.
4
Управление Проектом / Re: Нормативы на доработку ПО
« : 24 Января 2011, 21:59:14 »
В среднем получаются именно такие сроки, хотя норматив устанавливает максимальное время работ.
Но нет мотивации делать быстрее.
А еще есть статус заявки "Критично", который присваивают не твой заявке, и волшебное "Ресурсов нет".
Извините за офтоп.
Но нет мотивации делать быстрее.
А еще есть статус заявки "Критично", который присваивают не твой заявке, и волшебное "Ресурсов нет".
Извините за офтоп.
5
Управление Проектом / Нормативы на доработку ПО
« : 24 Января 2011, 16:11:05 »
Здравствуйте.
Возможно, вам знакомо, когда IT-шники защищены от бизнес-пользователей разного рода регламентами и порядками настолько,
что это начинает создавать проблемы в работе.
У нас в компании используются временные нормативы на доработку ПО.
При этом градация проводиться по сложности работ, примерно так
При этом сроки указаны в рабочих днях (а не человекоднях)
Подскажите, как можно улучшить данную систему,
что бы уменьшить плановое время разработки (без ущерба реальности исполнения)?
Хочется уйти от шкалы «Легко-Сложно», к чему-то более измеримому.
Возможно, вам знакомо, когда IT-шники защищены от бизнес-пользователей разного рода регламентами и порядками настолько,
что это начинает создавать проблемы в работе.
У нас в компании используются временные нормативы на доработку ПО.
При этом градация проводиться по сложности работ, примерно так
Код: [Выделить]
Легко Средне Сложно
Подготовка ФТ 5 +A +A1
Подготовка ТЗ 2 +B +B2
Разработка 15 +C +C2
Функциональное тестирование 2 +D +D2
При этом сроки указаны в рабочих днях (а не человекоднях)
Подскажите, как можно улучшить данную систему,
что бы уменьшить плановое время разработки (без ущерба реальности исполнения)?
Хочется уйти от шкалы «Легко-Сложно», к чему-то более измеримому.
6
Проектирование / Re: Проектирование схемы взаимодействия подразделений
« : 07 Октября 2009, 23:46:14 »
Спасибо, kayten, еще актуально 
7
Проектирование / Re: Проектирование схемы взаимодействия подразделений
« : 05 Октября 2009, 13:47:47 »
Несколько комментариев:
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
В понятиях UML мне проще выразить через класс-ассоциацию следующим образом - см. вложение (надеюсь, не ошибся).
Время жизни любого типа соединений не может быть более, чем время жизни связанного объекта.
Вот как бы это выразить в ER диаграмме?
Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
В понятиях UML мне проще выразить через класс-ассоциацию следующим образом - см. вложение (надеюсь, не ошибся).
Время жизни любого типа соединений не может быть более, чем время жизни связанного объекта.
Вот как бы это выразить в ER диаграмме?
8
Проектирование / Re: Проектирование схемы взаимодействия подразделений
« : 01 Октября 2009, 14:41:01 »
Все равно не понятно. Схему на UML, пожалуйста..
9
Проектирование / Проектирование схемы взаимодействия подразделений
« : 01 Октября 2009, 12:08:17 »
Подскажите, как реализовать следующую схему:
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.
Таблица содержит иерархическую структуру подразделений некой организации. Необходимо реализовать отношение «подразделение» —1—взаимодействует—N— «подразделение», причем возможна ситуация, когда одно подразделение взаимодействует со всеми остальными подразделениями. Взаимодействие начинает свое действие на основании документа, и ограничено периодом, указанным в документе.
Страницы: 1