Текущее время: Пт, мар 29 2024, 17:27

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 132 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 9  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Пт, сен 28 2007, 16:54 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4842
Откуда: Москва
Пол: Мужской
egen написал(а):
У нас просто - программисты - самый дефицитный ресурс.
Запланированы они на месяцы в перед, и если планировать с большим буфером, то они сделают работу и будут балду пинать. а если не запланировтаь буфер и они не выполнят, то по сути доделка работы встанет в очередь на месколько месяцев, то бишь - не сделать проект.
и как разрулить - не знаю. :(


Может просто ввести правило, что исправление старх косяков в програмах имеет более высокий приоритет по сравнению с новой разработкой? У нас есть такое правило и вроде работает..

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 01 2007, 09:18 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Вт, ноя 16 2004, 10:05
Сообщения: 1059
Откуда: Санкт-Петербург
Пол: Мужской
LKU написал:
Может просто ввести правило, что исправление старх косяков в програмах имеет более высокий приоритет по сравнению с новой разработкой? У нас есть такое правило и вроде работает..

Очень опасно такие правила устанавливать. Ведь может получиться, что из-за исправления ошибок по старому проекту можно завалить новый. :roll:


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 01 2007, 09:56 
Специалист
Специалист

Зарегистрирован:
Вт, апр 18 2006, 15:04
Сообщения: 161
Откуда: Мск
Я пока решил, что должен быть проект с некритичными сроками - типа повышения квалификации.
Им можно жертвовать, или затыкать дыры. :)

_________________
Режу правду, Na vjen keq për tim albasky


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 01 2007, 10:48 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4842
Откуда: Москва
Пол: Мужской
АлексО написал:
LKU написал:
Может просто ввести правило, что исправление старх косяков в програмах имеет более высокий приоритет по сравнению с новой разработкой? У нас есть такое правило и вроде работает..

Очень опасно такие правила устанавливать. Ведь может получиться, что из-за исправления ошибок по старому проекту можно завалить новый. :roll:


Я писал про ситуацию, когла абапер сидит на одном проекте.
Если есть пул абаперов, которые сидят в офисе и сегодня абапят для одного проекта, а завтра для другого - тут конечно надо как-то по другому подходить..

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 01 2007, 12:39 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Вт, авг 09 2005, 21:20
Сообщения: 538
YaYa написал(а):
По моему мнению основной источник всех проблем проектов это:
1) нарушение (или отсутствие) комуникаций среди участников проекта.
2) необоснованные предположения о (сроках, объемах, ресурсах и т.д.).
Оба источника лежат в основе общечеловеческих наклонностей: "Приятнее всего свой голос" и "Ожидание метафизической халявы..."
+1
Особенно усложняет эти проблемы чрезмерная надежда на различные средства планирования и управления проектами. Типа нарисовал ганта, распечатал и повесил на стену - все, дело в шляпе...
а с народом поговорить???
98% проектной информации носит неформальный и скрытый характер. Если ее не использовать, то из оставшихся 2% как раз и вырастают вышеназванные проблемы.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, окт 03 2007, 18:21 
Начинающий
Начинающий
Аватара пользователя

Зарегистрирован:
Вт, фев 27 2007, 17:00
Сообщения: 14
Откуда: Москва
+1 Проекты делаются людьми, поэтому многое упирается в работу с людьми (Топами, командой и т.п.).
Всё остальное, сказанное на этой ветке - обсуждение классического треугольника "Деньги-Время-Объём+качество".
Решение: формализация процессов и неформальные отношения с людьми (при этом беречь печень!!!!) :lol:


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Сб, окт 06 2007, 15:47 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пт, авг 11 2006, 16:38
Сообщения: 57
egen написал(а):

... а если не запланировтаь буфер и они не выполнят, то по сути доделка работы встанет в очередь на месколько месяцев....
. :(



Какая-то странная ситуация...
по здравому смыслу надо планровать задачи и сроки к которым они должны быть выполнены. А ситуация когда весь проект заваливается от того что программисты что-то не сделали и у них другие "важные" задачи - нонсенс (или нет всей информации...).

_________________
Основная наша задача - победить идиотизм в себе. Все остальное не имеет никакой важности. (с) ДХ


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, окт 08 2007, 09:18 
Специалист
Специалист

Зарегистрирован:
Вт, апр 18 2006, 15:04
Сообщения: 161
Откуда: Мск
Ну может быть - это я такой кривой планировщик. :)
Но проги то заняты на других не менее важных проектах, так что жертвовать одним проектом ради другого никто не будет.
Я тут уже придумал одну идею:
Надо создать буфер задач и запустить их в работу одному челу. Если он вывалится из графика - не сделает только часть, а если уложится - то ваще все в шоколаде. :)
И ресурс один на подхвате, который будет дотачивать отчеты после прогов. Вот типа так ...

YaYa написал(а):
egen написал(а):

... а если не запланировтаь буфер и они не выполнят, то по сути доделка работы встанет в очередь на месколько месяцев....
. :(



Какая-то странная ситуация...
по здравому смыслу надо планровать задачи и сроки к которым они должны быть выполнены. А ситуация когда весь проект заваливается от того что программисты что-то не сделали и у них другие "важные" задачи - нонсенс (или нет всей информации...).

_________________
Режу правду, Na vjen keq për tim albasky


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, окт 09 2007, 14:19 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Пт, авг 11 2006, 16:38
Сообщения: 57
egen написал(а):
Ну может быть - это я такой кривой планировщик. :)
Но проги то заняты на других не менее важных проектах, так что жертвовать одним проектом ради другого никто не будет.
Я тут уже придумал одну идею:
Надо создать буфер задач и запустить их в работу одному челу. Если он вывалится из графика - не сделает только часть, а если уложится - то ваще все в шоколаде. :)
И ресурс один на подхвате, который будет дотачивать отчеты после прогов. Вот типа так ...


Тоже вариант...
Тут получается надо посмотреть что можно использовать из методологии написания ПО. Каким путем они идут.

_________________
Основная наша задача - победить идиотизм в себе. Все остальное не имеет никакой важности. (с) ДХ


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, окт 10 2007, 19:29 
Гость
Проблемы, думаю, только две: руки и голова, либо голова и руки. на каждом проекте проблемы свои, но из двух.... :lol:


Принять этот ответ
Вернуться к началу
  
 
 Заголовок сообщения: Матричная система
СообщениеДобавлено: Вт, июл 01 2008, 11:44 
Специалист
Специалист

Зарегистрирован:
Вт, апр 18 2006, 15:04
Сообщения: 161
Откуда: Мск
Прошло полгода, а воз и ныне там ...
Как то мы в компании не может утрясти нормальную систему по планированию ресурсов. Даже то, что начальник говорит, что наши программисты планируются с 50% загрузкой на месяц - не дает положительного результата.
Сейчас тенденция в компании создать не матричную структуру, а проектную. То есть есть четкая тенденция у РП иметь своего собственного аналитика в проекте, своего программиста и тд, и никому их не отдовать, ибо самим скоро понадобятся. Опять же идея о "тонкой" специализации людей тоже оказалась похороненой. Сегодня человек делает задачу А, завтра совсем из другой области, и наработанный опыт по задачи А почти неиспользуется.

Может кто то поделится, у кого устойчиво работает матричная структура?


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


_________________
Режу правду, Na vjen keq për tim albasky


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Матричная система
СообщениеДобавлено: Вт, июл 01 2008, 13:21 
Ассистент
Ассистент
Аватара пользователя

Зарегистрирован:
Пн, июн 09 2008, 00:34
Сообщения: 42
Откуда: Moscow
egen написал(а):
Прошло полгода, а воз и ныне там ...
Как то мы в компании не может утрясти нормальную систему по планированию ресурсов. Даже то, что начальник говорит, что наши программисты планируются с 50% загрузкой на месяц - не дает положительного результата.
Сейчас тенденция в компании создать не матричную структуру, а проектную. То есть есть четкая тенденция у РП иметь своего собственного аналитика в проекте, своего программиста и тд, и никому их не отдовать, ибо самим скоро понадобятся. Опять же идея о "тонкой" специализации людей тоже оказалась похороненой. Сегодня человек делает задачу А, завтра совсем из другой области, и наработанный опыт по задачи А почти неиспользуется.

Может кто то поделится, у кого устойчиво работает матричная структура?


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

И то и другое должен пасти ПМ и вовремя реагировать.
по 1-му пункту - естественно, если у меня отбирают ресурс, то есть повод разобраться с руководством какое место занимает мой проект по отношению к остальным. И если он где то в п.пе, то согласовать новые сроки и расслабиться.

Руководство, правда, не всегда соглашается и требует трудовых подвигов :). А мы стараемся аппелировать к логике и к согласованным планам ("Ха-ха" - скажут почти все, - "неужели работает?":). Ответ: "иногда").

_________________
Ржунимагу


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Матричная система
СообщениеДобавлено: Вт, июл 01 2008, 13:30 
Ассистент
Ассистент
Аватара пользователя

Зарегистрирован:
Пн, июн 09 2008, 00:34
Сообщения: 42
Откуда: Moscow
egen написал(а):
Прошло полгода, а воз и ныне там ...
Как то мы в компании не может утрясти нормальную систему по планированию ресурсов. Даже то, что начальник говорит, что наши программисты планируются с 50% загрузкой на месяц - не дает положительного результата.
Сейчас тенденция в компании создать не матричную структуру, а проектную. То есть есть четкая тенденция у РП иметь своего собственного аналитика в проекте, своего программиста и тд, и никому их не отдовать, ибо самим скоро понадобятся. Опять же идея о "тонкой" специализации людей тоже оказалась похороненой. Сегодня человек делает задачу А, завтра совсем из другой области, и наработанный опыт по задачи А почти неиспользуется.

Может кто то поделится, у кого устойчиво работает матричная структура?


Кстати, планирование, на мой взгляд, позволяет сократить объем ненужных работ (метаний/исследований и т.п.) в проекте.
Т.о. затраты на управление проектом должны компенсироваться превосходящими по стоимости ресурсами, освобожденными от ненужных работ.


P.S. Вот вспомнил - в одной компании отказывались запускать новые проекты, если загрузка ресурсов на проектах была болл 100%. Оценивали ее на глазок (вернее по факту на основе отчетов).
Результаты были интересные:
- продавцы жутко ненавидели департамент производства и постоянно капали руководству, что производство отказывается принимать в работу потенциальные предложения
- компания выполняла свои обязательства перед клиентами

типа был лозунг - лучше меньше, да лучше. Делали, кстати, они очень дорого, но клиенты были довольны за качество/сроки.

_________________
Ржунимагу


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, авг 21 2008, 12:40 
Ассистент
Ассистент

Зарегистрирован:
Пт, мар 14 2008, 14:09
Сообщения: 27
Тема столь многогранна, что описать всё, конечно же сложно... Я бы поделил обсуждение на две темы: "проблемы стороны Заказчика" и "проблемы стороны Исполнителя". Предложу для начала немного..

А. Проблемы стороны Заказчика

- С начала проекта сотрудники Заказчика недопонимая работу и насыщение модулей создают два типа ситуации: либо подписывают концепт не вдаваясь в подробности, либо не подписывают его отказываясь понять материалы, достаточные для этого этапа. То и другое - большая проблема.

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


Б. Проблемы стороны Исполнителя

- Излишняя бюрократия (в больших фирмах) обусловленная предельно точным следованиям aSAP. SMEшные проекты просто умирают при таком подходе. Доказано (не Zanussi).

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

- Таже проблема с руководством, что и у Заказчика. Если руководитель департамента очень многое "заворачивает" на себя, то и время реакции ПМа увеличивается в разы.. что не есть good.

p.s. Это только проблемы.. обсудим решения? Кто как выходит из подобных ситуаций?

_________________
Best regards,
Micklas


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: выбор интегратора
СообщениеДобавлено: Чт, окт 23 2008, 11:56 
Начинающий
Начинающий

Зарегистрирован:
Пн, июн 09 2008, 17:11
Сообщения: 5
Доброго дня!
на данный момент передо мной встала проблема выбора нового интегратора взамен старого, ибо старый не устроил ни меня ни руководство компании ни пользователей. Хотелось бы авторитетного мнения, построенного на собственном опыте, плюсы и минусы той или иной компании. Скажу только что проект уже работает и необходимы доделки и доработки нацеленные на развитие и усовершенствование причем с минимизацией Z разработок.

_________________
Цветы, самые прелестные создания
из всех, что Бог создал, но в которые
забыл поместить душу.

Генри Уорд Бекфорд


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 132 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB