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, 04.11.2008 рубрики: ЖЖ-сообщество ru_pm, Синдицированные из ЖЖ-сообществ

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

Тема для сегодняшней дискуссии - управление задачами.

Вступление и необходимые определения.

Давно известно, что задача должна быть назначена одному ответственному, иначе своевременного выполнения может и не случится. Группа ответственных товарищей будет бодро указывать друг на друга, обьясняя задержку чьей угодно, но не своей виной, это называют футболом, пинг-понгом, или еще как. Для простых задач, вроде копания канав все просто - один участок на одного землекопа. Или бригады землекопов и ответственного бригадира. Веселье начинается по мере усложнения работы. Требуются консультации экспертов, согласование с потребителями результата работ, утверждение результатов поставки и своевременное освещение хода работ, а также их завершения. Один из методов распределение ответственности - матричный (RACI matrix). Google находит более полутора миллиона упоминаний данной аббревиатуры.

Здесь и далее будем использовать следующие определения:
Responsible - ответственный за выполнение задачи. Ответственность нельзя разделять.
Accountable - все, кто может (и должен) повлиять на выполнение задачи. Всякого рода эксперты, владельцы процессов и пр.
Communicated- лица, утверждающие (или подтверждающие) результат поставки.
Informed - все, кого каким-либо образом касается факт завершения работ. Односторонняя коммуникация.

О управлении задачами.

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

А Вам приходилось сталкиваться с тем, что задача находится в состоянии “почти готово” уже долгое время, а все сроки давно уж вышли? “90%” готовности, переход которых в “сделано” стоил Вам ……………. (впишите самостоятельно).

Упростить себе жизнь можно установив для команды проекта качественные показатели, которые будут регламентировать степень готовности задачи. Итак, к делу. Мой личный опыт показывает, что для контроля выполнения задач достаточно следующей шкалы: 0-25-50-75-100%. Определим качественные условия:

0%  - работа определена;
25% - задача в работе, ответственность определена;
50% - все необходимые решения приняты;
75% - все работы выполнены, результаты поданы на утверждение;
100%- результат утвержден.

Дополнив предложенную шкалу матрицей ответственности, получим следующее:

0%  - ответственный принял задачу;
25% - определены все участники, вовлеченные участники (А) мобилизированы;
50% - все ключевые решения приняты;
75% - работы выполнены, результат подан на утверждение (С);
100%- работы приняты, развернутое интервью улыбающегося менеджера опубликовано в ключевых таблоидах ;]

Графически вышесказанное можно выразить следующим образом:

Итак, сегодня мы:
1. Определили важность установления персональной ответственности по отношению к задачам.
2. Рассмотрели метод, позволяющий качественно оценивать ход выполнения задач.

Комментарии - приветствуются.

Кросс-пост в ru_pm, ru_management и moscow_pm_club

Comments Off

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

doTask!
Проект ведет один, графиков никаких нету, отчетов тоже* (можно использовать внешние серверные скрипты). И зачем она такая нужна?

*22.10.2008 - Обновление до 2.1 имеет отчеты о работе

Умеет
- Главное: все участники процесса взаимодействуют, так что не только для ПМ, причем все очень просто и всем понятно
- Задачи в виде простого списка
- Работа над задачами - общение между исполнителем и контролером, на манер ICQ, по каждой задаче в отдельности (для каждой задачи…
Читать дальше...

Comments Off