AgileProductivity

Автор: FeedWordPress, 05.04.2010 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Коллеги , Добрый день !

  Готовлюсь к Выступлению на РИТ , - Коммуникация и человеческий фактор являются ключевыми для успешности проектов по разработке ПО. Однако каждый раз сталкиваясь с <<бизнесовой>> типизацией , будь то PAEI модель Адизеса , модель Белбина или MBTI каждый руководитель начинает задумываться, насколько эта типизация относится к команде по разработке ПО и как извлечь из нее пользу. 

Было бы очень хорошо если бы Вы поделились соображениями, положительным /негативным  опытом и проблемами с которыми приходилось сталкиваться  в связи с использованием различных моделей типизации личности.

UPD.

Пример модели нетехнологической структуры команды и лежащй под ней типизации личностей

Для большинства заказчиков команды по внутреннему устройству делятся всего на два типа:

1. Белый маг и команда кольца.

2. Темный властелин и толпа гоблинов.

В основе этого очень жизненного представления лежит модель Дугласа МакГрегора разделяющая людей на два типа

X - Среднему человеку присуща неприязнь к работе и желание, по возможности, избежать ее. и т.д.. прявляющие ум и извортливость исключительно с целью избежать работы …

Y - Затраты физических и умственных усилий в работе так же естественны, как игра или отдых. Обычный человек по сути своей не испытывает неприязни к работе: в зависимости от условий работа может быть источником удовлетворения или наказания.

К какому типу осноситесь Вы, Ваша команда , компания ?

К какому типу относят вас ?

Источник www.system-approach.ru

Comments Off

Автор: FeedWordPress, 21.02.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

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


[...]

Comments Off

Автор: FeedWordPress, 06.02.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Хочется создать базу знаний по проекту. Проект достаточно сложный, есть объемные описания циклов обработки.

Плюс периодически возникают весьма специфические работы и хочется, чтобы опыт по решению этих проблем не терялся. Сейчас в файлы пишутся памятки, но это очень неудобно. Новому человеку найти что-то практически нереально.

Хочется все это удобно организовать.
- Очень желателен веб-интерфейс
- Очень желательна возможность добавления документов, и редактирования прямо на веб
- Разграничение прав доступа на просмотр/создание/редактирование
- Желательна возможность оставлять комментарии к документам
- Возможность назначения нескольких категорий к документам

Кто-то может что-нибудь посоветовать? Заранее спасибо всем откликнувшимся!
Читать дальше...

Comments Off

Автор: FeedWordPress, 05.02.2009 рубрики: Синдицированные из ЖЖ-сообществ

Подскажите пожалуйста web-решение (возможно, интранет) для управления задачами. Специализация у нас разработка сложных web-порталов. Методология пока классический waterfall, но планируем переходить в сторону Agile/SCRUM.

Сошлись, на том, что хотелось бы видеть такой функционал:
* Поддержка множества проектов
* Учет времени (запланированного и фактического)
* Составление плана работ на период (с указанием Milestones) и отражение его в виде диаграммы Ганта
* Операции с задачами с поддержкой приоритетности (подразумевается стандартный функционал баг-трекера)
* Повторяющиеся задачи, чтобы не дублировать одинаковые задачи под разными названиями, для дальнейшего учета среднего времени на операцию
* Срез по загруженности отдельного человека, учитывая разные проекты
* Общая картина работ (текущих и будущих) по всем проектам (например, через диаграмму Ганта)
* Учет занятого времени конкретного человека на конкретный будущий период (исходя из плана работ) или общая загрузка человеко часов на будущий период.
* Поддержка wiki
* Возможность интеграцией с какой-либо из СУП (системами управления проектами)

Есть ли возможность реализовать это поверх какого-то стандартного баг-трекера (Trac, Redmine, Bugzilla) например с помощью плагинов или готовых решений?
Читать дальше...

Comments Off

Автор: FeedWordPress, 05.02.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Так или иначе у меня есть пара десятков живущих и периодически оживающих проектов.

По каждому из них довольно много разнородных материалов. В частности:
- переписка по электронной почте
- логи из мессенджеров
- текстовые документы типа технических заданий и брифов
- тяжёлые файлы дизайны из фотошопа и какого-нибудь корела
- пачки смежных материалов “на почитать для повышения эрудиции по вопросу”
- для веб-проектов ещё скрипты и статические файлы (полное дерево виртуального хоста) и дампы БД
- файлы расписания (например, для Planner или MS Project)
- просто ту-ду списки наведённые где-нибудь в эволюшене
- огромные кучи присланных файлов (вроде исходников пары сотен фотографий по 3.5Мб каждая)
- …

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

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

Я подумываю о запихивании этого всего в какую-нибудь систему контроля версий. Здесь хотелось бы разделяемости проектов - то есть, чтобы для каждого проекта можно было получить отдельную независимую группу файлов, которую можно было бы бэкапить на болванки (это важно - причём хотелось бы, чтобы проект не сильно рос по объёму от версии к версии), и с которым можно было бы в идеале работать с этой же самой болванки - что-то вроде standalone-репозитория.

Да, и чтобы это всё было кросс-платформенное. То есть, чтобы этот диск можно было как с линукса прочитать, так и с винды, допустим. Причём чтобы это была не консоль, а что-нибудь более-менее юзер-френдли, потому что такие кучи файлов всё-таки надоест вручную перетасовывать.

А. И хочу open-source или очень дешёво. Скорее open-source.
Читать дальше...

Comments Off

Автор: FeedWordPress, 05.02.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Компания Standish Group International в 2003 году исследовала свыше 13 000 проектов (март 2003 года, исследование “chaos report”). Оказалось, что 82% проектов завершено позже запланированного срока, причём с 2000 года этот показатель вырос на 30%! В тот момент, когда вы читаете эти строки, в мире погибает не один десяток проектов, а не одна сотня проектов, будучи выполненными на 95% ещё 2-3 года назад, продолжает тянуться до сих пор. Одновременно с этим, тысячи проектов успешно завершаются.
Генеральные директора компаний, их карьеры и даже выживание, сейчас как никогда зависят от эффективного управления проектами. И в выживании им помогут именно руководители проектов. В то время как многие профессии в нынешние времена вдруг оказались невостребованными, профессия PM, или руководителя проекта, наоборот, становится сверхвостребованной в деловой среде.

Однако это не означает, что руководителям проектов нужно ликовать. У них своих проблем предостаточно. Удивительно, но слова, которые используют для описания своих проблем менеджеры проектов в разных странах и разных отраслях, практически одинаковы.
Эти жалобы часто звучат так: «практически всегда подводят подрядчики», «в содержание работ часто вносятся изменения», «регулярно отвлекают от работы (заказчики, руководство, коллеги…)», «всегда возникает необходимость что-то переделать», «работа занимает больше времени, чем планировалось», «постоянно возникают непредвиденные сбои и задержки», «у нас недостаточно ресурсов». Наиболее часто встречающаяся жалоба: «Постоянно меняются приоритеты!».

По мнению многих руководителей проектов, эти проблемы им неподконтрольны. Но пока будет существовать подобное убеждение, значительных продвижений в деле внедрения проектного управления в компаниях не увидеть. Сам факт, что жалобы руководителей проектов десятилетиями остаются теми же, не находя должного разрешения, говорит о необходимости нового подхода.

Бизнес-сообщество ЗУБРЫ.РУ совместно со своими партнёрами проводит Неделю проектного управления под девизом: «Кризис – возможность для руководителей проектов!». В рамках этого мероприятия будет положено начало формированию сообщества руководителей проектов, которые не просто обсуждают рутинные вопросы, а решают насущные задачи своей деятельности, делятся опытом, развиваются и обучаются, формируют новое знание. читать дальше: что это? как это? и чем мне это будет полезно?

Если у Вас есть знакомый руководитель проектов, дайте ему ссылку на это сообщение - он будет благодарен!
Если данное сообщение не заинтересовало вас - прошу прощения.

Спасибо!
Читать дальше...

Comments Off

Автор: FeedWordPress, 26.01.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Д.д., коллеги!
Известны ли кому-нибудь excel-based offline шаблоны в которых был бы реализован процесс отслеживания требований в какой-либо сфере от концепции до приемочного тестирования. В идеале хотелось бы визуализацию состояния требования (e.g burn down chart) с возможностью углубиться в список текущих проблем/задач (отдельный sheet какой-нибудь). В кач-ве отслеживания вполне устроит 0-50-100 или подобный метод. Спрашиваю не по причине лени или незнания других систем. Нужна быстрая помощь полностью удовлетворяющая услоиям excel-based и offline. Google не помог. Заранее признателен всем ответившим “в тему”
upd
Как крайний вариант - stp для wss 3 с реализованным workflow и визуализацией (можно без).
Читать дальше...

Comments Off

Автор: FeedWordPress, 26.01.2009 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Коллеги, ни для кого не секрет, что в последний день 2008 PMI успел-таки выпустить четвертую редакцию стандарта PMBOK® Guide. Если вы уже ознакомились с новым стандартом, просим высказать ваше мнение об изменениях, которые вам показались важными и/или интересными.

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

Основные отличия нового издания
После очередной редакции стандарт претерпел значительные изменения, в частности:

• Количество процессов уменьшилось с 44 до 42. 2 процесса исчезли, 2 были добавлены и 6 процессов в области управления поставками были переформулированы в 4. А именно:
• В области знаний «Управление интеграцией проекта» был удален процесс «Разработки предварительного описания содержания проекта» (Develop Preliminary Project Scope Statement).
• В области знаний «Управление содержанием проекта» процесс «Планирования содержания» (Scope Planning) заменен процессом «Сбор требований» (Collect Requirements). В области знаний «Управление человеческими ресурсами проекта» процесс «Управление командой проекта» (Manage Project Team) перешел из группы процессов Мониторинга и контроля в группу процессов Исполнения.
• В области знаний «Управление коммуникациями проекта» произошло сразу несколько изменений: в группе процессов Инициации появился процесс «Определение заинтересованных сторон проекта» (Identify Stakeholders); Процесс «Управление стейкхолдерами» (Manage Stakeholders) в группе процессов Мониторинга и контроля исчез, вместо него в группе процессов Исполнения появился процесс «Управление ожиданиями заинтересованных сторон проекта» (Manage Stakeholders Expectations).
• Совершенно обновлена была область знаний «Управление поставками» (отметим, что по-русски она теперь называется почему-то «Управление закупками»). Шесть процессов превратились в четыре, а именно: Планирование закупок (Plan Procurement), Осуществление закупок (Conduct Procurement), Управление закупочной деятельностью (Administer Procurement), Закрытие закупок (Close Procurement).
• Значительно была переделана область знаний «Управление закупками». Несмотря на то, что исчез процесс «Запрос информации у продавцов», были добавлены различные методы по поиску поставщиков (в том числе при использовании Интернет). Из обязательного применения исключили систему «взвешиваний» тех или иных качеств потенциального поставщика (Weighting System).
• Проведено четкое различие между планом управления проектом и документами по управлению проектом. - Проведено четкое различие между содержанием Устава проекта (Project Charter) Описания содержания проекта (Project Scope Statement).
• Проведено более четкое разграничение между понятиями «активы организационного процесса» и «факторы внешней среды предприятия».
• Добавлено новое приложение, в котором описываются навыки межличностного общения, необходимые менеджеру проекта. А именно: лидерство, командообразование, умение мотивировать, коммуникативные навыки, умение оказывать влияние, умение принимать решения, внимание к политическим и культурным особенностям, умение вести переговоры. Полный перечень изменения можно посмотреть в Приложении А (Appendix A) к четвертому изданию.

Следует отметить, что одновременно с выходом четвёртой редакции PMBOK® Guide вышли также новые редакции стандартов OPM3®, The Standard for Program Management и The Standard for Portfolio Management. Стандарты являются взаимодополняющими, в PMI на этот раз постарались по-настоящему проинтегрировать их. Например, на верхнем уровне: в вводной части PMBOK® Guide достаточно внимания уделяется соотношению управления проектом и управления программами.
Более детально соотношение прописаны и в отдельных разделах: так, при проведении разграничения обязанностей различных заинтересованных сторон функции инициализации теперь принадлежат Руководителю портфеля.
Начав с формализации основных и наименее подверженных изменениям процессов (таких как планирование расписания, бюджета и т.д.) PMI сейчас всё больше уделяет вниманию описанию более тонких вещей, поэтому в стандарте много изменений, связанных с коммуникациями, взаимодействием с заинтересованными сторонами, поставщиками, навыками межличностного общения менеджера проекта. Введен процесс «Определения заинтересованных лиц в проекте», который является одним из коренных, так как реализуется на этапе инициации наряду с процессом разработки Устава проекта. Под понятие «заинтересованные лица» теперь подпадает гораздо большее количество единиц, в том числе Офис Управления Проектами, Менеджер Программ и т.п.
Все комментаторы отмечают, что одним из главных изменений стало внедрение итерации в новой редакции стандарта. Хочется отметить, что цикл Plan-Do-Check-Act был во главе угла и в предыдущих версиях, и итеративность процессов предполагалась создателями. Тем не менее для того, чтобы акцентировать внимание на этом аспекте, до этого «движущиеся в одну сторону» схемы процессов теперь зациклены.
Если говорить о характеристиках стандарта как продукта, то хочется отметить, что PMI постоянно работает над улучшением качества стандарта. Новая редакция стала намного лучше в плане всего, что касается удобства пользования – шрифт, навигация по тексту, гиперссылки (в электронном варианте). Гораздо более серьезно на этот раз отнеслись и к защите электронного текста. Из минусов можно отметить довольно значительное увеличение стоимости бумажной копии и задержку с выходом полного текста перевода на русский язык.
Официальный русский перевод и изменения в сертификациях
Постоянный адрес материала

Comments Off

Автор: FeedWordPress, 20.10.2008 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Уважаемые коллеги!

У кого был опыт внедрения КСУПр на базе Примаверы  +  СЭД на базе … (?) в одной информационном пуле компании? Поделитесь опытом, что бы не попасть в «просак» с выбором СЭД, какие возможны проблемы с интеграцией информации в будущем,  стоит ли думать о об этом.

П.С.  Необходимо оптимизировать договорную работу, порядка 2000 договоров в месяц.

Буду рад за Ваши комментарии!
Читать дальше...

Comments Off

Автор: FeedWordPress, 14.10.2008 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

Коллеги, нужна поддержка и советы:
Ну вот.. финансовый кризис. Ситуация- проект революция по внедрению КСУП приостановлен на неопределенный срок. Мне предлагают медленный вариант внедрения КСУП, который ими видится так- собираю на себя все проекты, в которых есть коммуникация между департаментами, пытаюсь защитить заказчиков, продвигать эти проекты, выявлять узкие места и писать регламентирующие документы.
Своего мнения пока даже не высказывала…. шла в эту компанию( компания большая- распределенная) именно с четким видением проекта- революции и желанием осуществить его.
Честно, в данный момент очень жалко ( уже дома, поэтому эмоции можно показать)закрыть для себя очень интересный проект, но и четкий медленный  вариант внедрения пока даже в голове не выстроен. 
Очень нужны ваши советы….
Читать дальше...

Comments Off