<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр: коллективные</title>
	<link>http://habrahabr.ru/rss/blogs/pm/</link>
	<description><![CDATA[]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Tue, 09 Feb 2010 17:35:42 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	
			
		<item>		
			<title><![CDATA[Управление проектами / Вебинар: «Людям о менеджерах». Среда, 10 февраля, 17.30 по Москве]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/83518/</guid>
			<link>http://habrahabr.ru/blogs/pm/83518/</link>			
			<description><![CDATA[Мы решили провести эксперимент и проводить наши открытые семинары еще и через вебинары.<br/>
<br/>
<b>О чем примерно говорить будем?</b><br/>
 — Разогреемся мы примером мальтитаскинга.<br/>
 — Далее мы поговорим о 2 очень разных путях создания «Value to people».<br/>
 — Поговорим о том, что есть менеджеры, почему идти туда нужно осознанно и подготовленным. О том, как это обычно бывает. О том, почему вменяемый менеджер это большая редкость.<br/>
 — Поговорим о том, какие менеджеры бывают, почему вам вообще это нужно знать, как использовать это знание.<br/>
 — Коротенько расскажу современную теорию менеджмента, что такое командная работа. Покажу за счет чего правильная команда «делает» одиночек.<br/>
 — Немного поговорим о разных типах проектов и почему это важно знать сотрудникам.<br/>
 — Поговорим о разных типах компаниях, о циклах развитии компании. И снова, с точки зрения сотрудника и менеджмента. Почему это всё важно и как использовать.<br/>
 — А закончим несколькими удивительными примерами правильного управления, которые на дорогущем 2-ух дневном тренинге Certified SCRUM Master-ом рассказывал очень грамотный дядька <a href="http://www.scrumalliance.org/profiles/5066-robin-dymond">Robin Dymond</a>. Надеюсь, меня за это не засудят :)<br/>
 — Если останется время, я покажу на примерах что такое очень популярные нынче Lean и Kanban. Если времени не останется и вам понравится, я сделаю 2-ую часть. Возможно, вы захотите оставить мне «заявки», о чем бы вы хотели послушать в последующих частях.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/83518/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 08 Feb 2010 16:33:29 GMT</pubDate>
			<author>DenisVaihanski</author>
			<category>management</category><category>project managment</category><category>pm</category><category>agile</category>
		</item>
		
		
		
		
		
		
		
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[Управление проектами / [Ссылка] Redmine 0.9.1 released!]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/82657/</guid>
			<link>http://habrahabr.ru/blogs/pm/82657/</link>
			<description><![CDATA[Одна из лучших систем управления проектами обновилась до 0.9.1! Список изменений по сравнению с 0.8 просто не может не радовать!]]></description>
			
			<pubDate>Sun, 31 Jan 2010 13:06:36 GMT</pubDate>
			<author>DerSpinner</author>
			<category>redmine</category><category>git</category><category>svn</category><category>управление проектами</category>
		</item>
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Круговорот артефактов в Agile]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/82388/</guid>
			<link>http://habrahabr.ru/blogs/pm/82388/</link>			
			<description><![CDATA[Доброго времени суток.<br/>
<br/>
В этой статье я хочу <a href="http://adrobnych.habrahabr.ru/blog/81077/">продолжить</a> рассказ о «прагматическом» Agile процессе разработки ПО. На суд Читателя предлагается иная перспектива обзора этого процесса — с точки зрения создания и эволюции артефактов (Artifact Flow) в ходе развития проекта. А также мы рассмотрим практический подход для работы с артефактом «Коллекция Требований» с использованием Google Wave и Google Docs.<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/82388/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Thu, 28 Jan 2010 16:21:42 GMT</pubDate>
			<author>adrobnych</author>
			<category>управление проектами</category><category>коллективная работа</category><category>Agile</category><category>артефакт</category><category>жизненный цикл</category><category>google wave</category><category>google docs</category><category>требования к системе</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Управление портфелем проектов и макросы для Google Spreadsheets]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/81391/</guid>
			<link>http://habrahabr.ru/blogs/pm/81391/</link>			
			<description><![CDATA[Привет<br/>
<br/>
Иногда бывает так что обычная задача приводит к необычным находкам. Так все началось с тривиальной задачи — нужно было развернуть за несколько часов систему управления портфелем проектов. Ресурсы на эту задачу не выделялись вследствие некоторого цейтнота по текущим проектам. <br/>
<br/>
Особенности бекграунда задачи — система должна быть очень динамичной и наглядной. Специфику и уклад жизни нашей небольшой команды я коротко описал в <a href="http://adrobnych.habrahabr.ru/blog/81077/">недавнем посте</a>. Бизнес кейс задачи таков: у нас в работе много проектов. Пишутся предложения, рисуются оценочные Гантты, обсуждаются вопросы, ведется поддержка Процесса Разработки… В день через обсуждение в команде может проходить до 15 проектов. У проектов могут меняться статус, фаза, владелец. Информации <i>много</i>, она <i>быстро меняется</i>, и она <i>важна</i>. Наступил момент вводить инструмент для управления портфелем проектов. <div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/81391/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Fri, 22 Jan 2010 07:24:32 GMT</pubDate>
			<author>adrobnych</author>
			<category>управление портфелем проектов</category><category>google docs</category><category>google spreadsheets</category><category>гаджеты</category>
		</item>
		
		
		
		
		
		
		
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[Управление проектами / [Ссылка] Введение в CMMI (слайдкаст)]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/81543/</guid>
			<link>http://habrahabr.ru/blogs/pm/81543/</link>
			<description><![CDATA[Нашел несколькими постами ниже пост про CMMI. Думаю, стоит поделится ссылкой на свой рассказ про эту модель. Он должен прояснить некоторые &quot;склизкие&quot; моменты, оставшиеся нераскрытыми.]]></description>
			
			<pubDate>Thu, 21 Jan 2010 21:39:10 GMT</pubDate>
			<author>Cartmendum</author>
			<category>cmmi</category><category>cartmendum</category>
		</item>
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / 10 советов заказчикам коммерческого ПО]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/81109/</guid>
			<link>http://habrahabr.ru/blogs/pm/81109/</link>			
			<description><![CDATA[Давайте представим, что у вас есть беспроигрышная гениальная идея для программного продукта, в котором остро нуждается рынок, при этом и заказчик программного обеспечения (вы) и компания – аутсорсер, нанятая на проект — отличные ребята. Заказчик отличается адекватностью и порядочностью, а аутсорсер исполнительностью, ответственностью и профессионализмом. Почему же даже при таких условиях некоторые проекты с треском проваливаются? Рецепт краха состоит из многих ингредиентов, и в лучшем случае мы задумываемся о них только когда сталкиваемся с проблемой, а в худшем — истинная причина остаётся незамеченной и вина за провал валится, допустим, на кризис<sup>(тм)</sup>.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/81109/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 18 Jan 2010 12:57:53 GMT</pubDate>
			<author>mihteh</author>
			<category>аутсорс</category><category>управление проектами</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Использование гугл-докс как системы простейшего документооборота для небольших компаний]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/81054/</guid>
			<link>http://habrahabr.ru/blogs/pm/81054/</link>			
			<description><![CDATA[Не секрет, что многие студии используют большое количество внештатных специалистов.<br/>
Это могут быть дизайнеры, программисты, тестеры, верстальщики, да кто угодно, кто необходим компании. И в принципе эта ситуация полностью повторяет общую ситуацию в мире, когда коммерция переходит в рамки сетевых компаний, с распределением функций.<br/>
И компании, и отдельные фрилансеры могут находиться в других городах, часто даже странах. Коммуникации осуществляются посредством средств связи, благо технологии позволяют.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/81054/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 17 Jan 2010 21:40:06 GMT</pubDate>
			<author>timeout</author>
			<category>управление проектами</category><category>управление веб-проектами</category><category>разработка сайтов</category><category>google docs</category><category>бизнес</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Способ организации проектных директорий и файлов]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/80519/</guid>
			<link>http://habrahabr.ru/blogs/pm/80519/</link>			
			<description><![CDATA[Достаточно часто поднимается вопрос о том, кто и как называет организовывает файлы (речь идет не о системах хранения версий, а именно о способе организации файлов и директорий). Или не называет, а хранит как придется. Буквально вчера коллега в Useful Сlub задал аналогичный вопрос. Я, пожалуй, зафиксирую свой ответ и здесь, вдруг кому-то еще наш способ поможет сэкономить время.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/80519/#habracut">Честно-честно финальное техническое задание 56785.doc</a> </div>]]></description>
			
			<pubDate>Tue, 12 Jan 2010 01:10:04 GMT</pubDate>
			<author>creadone</author>
			<category>организация файлов</category><category>проекты</category><category>командная работа</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Модель CMMI]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/79130/</guid>
			<link>http://habrahabr.ru/blogs/pm/79130/</link>			
			<description><![CDATA[<i>Всем здравствуйте! Наконец-то я на Хабре. Постараюсь незамедлительно начать приносить пользу если не всему сообществу, то хотя бы некоторой его части:)</i><br/>
<br/>
Я был немало удивлён, обнаружив, что на Хабре практически нет информации о модели CMMI, если не считать пары упоминаний <a href="http://habrahabr.ru/blogs/fluerograff/14879/">здесь</a> и <a href="http://habrahabr.ru/blogs/pm/53854/">здесь</a>.<br/>
На западе уже давно крупные заказы по разработке ПО доверяются только компаниям, прошедшим сертификацию на соответствие какому-либо международному стандарту, зачастую им становится модель CMMI. Хотя сами авторы этой модели неоднократно повторяют, что это не стандарт, а всего лишь сборник рекомендаций по улучшению процессов внутри организации.<br/>
<br/>
<h4>Что такое CMMI?</h4><br/>
Википедия даёт следующее определение:<br/>
<blockquote><b>Capability Maturity Model Integration (CMMI)</b> – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.</blockquote><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/79130/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Wed, 23 Dec 2009 19:02:12 GMT</pubDate>
			<author>arty87</author>
			<category>cmmi</category><category>capability maturity model</category><category>сертификация</category><category>разработка по</category><category>процессный подход</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Учёт рисков при оценке трудоёмкости ПО и планировании проекта]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/77958/</guid>
			<link>http://habrahabr.ru/blogs/pm/77958/</link>			
			<description><![CDATA[<h2>Поговорим о рисках</h2><br/>
<img alt="dice" src="http://i081.radikal.ru/0912/62/1df7a1219814.png"/><br/>
Что такое риски? Что является риском, а что нет? Как учитывать риски при оценке трудоёмкости ПО и планировании проекта? Об этом я предлагаю поговорить в этом топике. В то же время, чтобы не раздувать топик и <a href="http://habrahabr.ru/blogs/pm/73571/">не повторяться</a>, здесь не будут обсуждаться вопросы <i>идентификации</i> и <i>митигации рисков</i> — действий по выявлению, уменьшению вероятности возникновения рисков и минимизации их последствий.<br/>
После публикации <a href="http://habrahabr.ru/blogs/pm/75903/">статьи о смертных грехах в оценке трудоёмкости программного обеспечения</a> мне <a href="http://habrahabr.ru/blogs/pm/75903/#comment_2220339">указали</a>, что ни автор, ни я ничего не сказали о рисках. Хочу исправить это досадное недоразумение и поведать вам немного о рисках и моём опыте работы с ними.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/77958/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sat, 12 Dec 2009 08:42:20 GMT</pubDate>
			<author>Jay_Di_Human</author>
			<category>риски</category><category>учёт рисков</category><category>risks</category><category>risk management</category><category>project management</category><category>управление проектами</category><category>планирование проектов</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / О работе с заказчиками, разработке и внедрении софта]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/77639/</guid>
			<link>http://habrahabr.ru/blogs/pm/77639/</link>			
			<description><![CDATA[Почитал я, как люди бьются с пользователями своего софта и решил поделиться с миром опытом. Сразу скажу, что опыт у меня не маленький — в своё время мои программы пользовались большим спросом и на их поддержке я не одну собаку съел. В результате клиенты пИсали кипятком, а пользователи саботировали любой другой софт, спускаемый сверху, кроме моего. В качестве истории успеха приведу не слишком большой проект автоматизации АЗС.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/77639/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Tue, 08 Dec 2009 13:25:22 GMT</pubDate>
			<author>Sap_ru</author>
			<category>пользовательские интерфейсы</category><category>работа с заказчиком</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Как бороться с человеческим фактором при внедрении ПО?]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/77581/</guid>
			<link>http://habrahabr.ru/blogs/pm/77581/</link>			
			<description><![CDATA[Устал биться головой об стену! Сотрудники организаций, в которых мы внедряем ПО, не используют его возможности полностью, или вообще не используют.И это, в принципе, случается не только у нас, но и у других разработчиков/внедренцев в организациях всех размеров. Да что говорить, внутри своей компании внедрение различного по для багтрекинга/контроля версий/управления проектами/сниппет-хранилища проходит со скрипом. И это среди программистов!<br/>
 Приведу три примера: <br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/77581/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 07 Dec 2009 20:06:33 GMT</pubDate>
			<author>popotam2</author>
			<category>человеческий фактор</category><category>внедрение</category><category>документооборот</category><category>проблемы</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Три вопроса на собеседовании руководителя проектов]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/76477/</guid>
			<link>http://habrahabr.ru/blogs/pm/76477/</link>			
			<description><![CDATA[Предлагаю каждому написать в комментариях три вопроса, которые, по его мнению, обязательно нужно задать ПМу на собеседовании. Варианты оставляем в комментариях первого уровня, форма вопросов любая. В результате получим материал для опросника, который поможет выявить хорошего руководителя проектов из общей массы кандидатов.<br/>
<br/>
Моя версия под катом.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/76477/#habracut">Читать дальше</a> </div>]]></description>
			
			<pubDate>Thu, 26 Nov 2009 13:09:18 GMT</pubDate>
			<author>vadimdne</author>
			<category>управление проектами</category><category>собеседование</category><category>руководитель проектов</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Управление проектом на одной странице (таблица из одноименной книги К. А. Кэмбэлла)]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/76101/</guid>
			<link>http://habrahabr.ru/blogs/pm/76101/</link>			
			<description><![CDATA[Только дочитал означенную в названии топика книгу. Она предлагает очень интересную и удобную схему для ведения проекта. Фактически, это – несколько усложненная <a href="http://ru.wikipedia.org/wiki/Диаграмма_Ганта">диаграмма Ганта</a>.<br/>
<img src="http://pic.ipicture.ru/uploads/091123/bShzTs8577.jpg" alt="image"/><br/>
Однако я предположил, что таблица уже созданная в Excel будет многим хабравчанам удобна. Сама по себе книга имеет ценностью на 80-90 % в этой схеме. Но, думаю, без первоисточников вполне можно справиться с изучением данной диаграммы, тем более, что на официальном сайте издательства она представлена как:<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/76101/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Tue, 24 Nov 2009 08:20:37 GMT</pubDate>
			<author>Alexey_S</author>
			<category>управление проектами</category><category>книги</category><category>microsoft excel</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/75903/</guid>
			<link>http://habrahabr.ru/blogs/pm/75903/</link>			
			<description><![CDATA[<h2>Введение</h2><br/>
В этом топике я хочу представить вам, дорогие читатели, пересказ <a href="http://construx.com/Page.aspx?hid=2929">вебинара</a> от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз <a href="http://www.construx.com/Page.aspx?hid=535">Стив МакКоннелл</a> решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги <a href="http://www.microsoft.com/learning/en/us/book.aspx?ID=2425&amp;locale=en-us">«Software Estimation. Demystifying The Black Art»</a> — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить. <br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/75903/#habracut">Итак, поехали...</a> </div>]]></description>
			
			<pubDate>Mon, 23 Nov 2009 12:59:34 GMT</pubDate>
			<author>Jay_Di_Human</author>
			<category>software estimation</category><category>estimation</category><category>Steve McConnell</category><category>sins</category><category>black art</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Выбор системы управления задачами, часть 2]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/75004/</guid>
			<link>http://habrahabr.ru/blogs/pm/75004/</link>			
			<description><![CDATA[<b>Обзор и сравнение предложенных хабралюдьми систем</b><br/>
<br/>
Краткое содержание <a href="http://atman.habrahabr.ru/blog/74842/">первой части</a>: автор рыщет в поисках системы, которая поможет вдохнуть новую жизнь в отношения между работниками и задачами. Формулирует требования, жалуется на недостатки опробованных систем. Те, кто в теме, советуют автору, чего бы помучить еще.<br/>
<br/>
Вторая часть длинная (да еще и со скриншотами), если тема не интересна — лучше и не начинить читать :)<br/>
<br/>
Мы опробовали в нашей команде некоторые предложенные системы управления задачами, и я отчитываюсь о результатах. Может кому-то будет интересно и полезно, а может кто-то посоветует систему лучше всех остальных (только прошу написать хотя бы несколько слов, о том почему и чем предлагаемая система интересна). <br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/75004/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 23 Nov 2009 10:00:35 GMT</pubDate>
			<author>atman</author>
			<category>управление проектами</category><category>таск менеджмент</category><category>project management</category><category>task management</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Отчеты менеджеров проектов]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/73792/</guid>
			<link>http://habrahabr.ru/blogs/pm/73792/</link>			
			<description><![CDATA[Прошу сразу прощения, если получится не совсем в тему, но решил поделиться тем, как я собирал отчеты по работе над проектами у своей команды менеджеров.<br/>
Когда в компании несколько проектов, по 3-4 на каждом менеджере, достаточно сложно держать в голове все данные по ним.<br/>
Поэтому я ввел правило: два отчета в неделю. По 10-15 минут на каждого менеджера. <br/>
Отчеты устные. Данные фиксируются в бланк отчета.<br/>
Почему устные, а не просто бумажный отчет?<br/>
Просто чтобы иметь возможность задавать вопросы. То есть составить мнение самому о делах на проекте.<br/>
<br/>
Протокол отчета имеет следующий вид.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/73792/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Thu, 29 Oct 2009 20:47:54 GMT</pubDate>
			<author>timeout</author>
			<category>управление проектами</category><category>разработка сайтов</category><category>менеджмент интернет-проектов</category><category>менеджмент интернет проектов</category><category>менеджмент</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Управление рисками]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/73571/</guid>
			<link>http://habrahabr.ru/blogs/pm/73571/</link>			
			<description><![CDATA[В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа. <br/>
<br/>
Но проектов без рисков, наверное, не существует в природе и с ними так или иначе приходится работать. О том, как это делать, можно прочесть в <a href="http://en.wikipedia.org/wiki/A_Guide_to_the_Project_Management_Body_of_Knowledge">PMBOK</a>, на <a href="http://en.wikipedia.org/wiki/Risk_management">википедии</a> и на тематических ресурсах. В этой статье больше практики, чем теории. Ее цель — показать на примерах недорогой и эффективный подход к управлению рисками проекта.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/73571/#habracut">Читать дальше</a> </div>]]></description>
			
			<pubDate>Wed, 28 Oct 2009 15:39:10 GMT</pubDate>
			<author>vadimdne</author>
			<category>управление проектами</category><category>управление рисками</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Управление проектами / Конфигурационный менеджмент (часть 2, обзор инструментов)]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/73347/</guid>
			<link>http://habrahabr.ru/blogs/pm/73347/</link>			
			<description><![CDATA[Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции <a href="http://phpconf.ru">PHPCONF 2009</a> 8 октября (<a href="http://www.phpconf.ru/programm/web-architect-workshop-day/">Web Architect Workshop Day</a>) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением <a href="http://habrahabr.ru/blogs/pm/53687/">предыдущей</a>), посвященной конфигурационному менеджменту, для публичного обозрения доступны <a href="http://www.slideshare.net/altern/ss-2219788">слайды</a> презентации.<br/>
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/pm/73347/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 25 Oct 2009 22:38:33 GMT</pubDate>
			<author>altern</author>
			<category>scm</category><category>CM</category><category>configuration management</category><category>version control</category><category>build management</category><category>unit testing</category><category>continuous integration</category><category>agile</category><category>static analysis</category><category>phpdoc</category><category>phpconf</category>
		</item>
		
		
		
		
		
		
		
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[Управление проектами / [Ссылка] Планирование коммуникаций или есть такое слово – “НАДО”]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/pm/73314/</guid>
			<link>http://habrahabr.ru/blogs/pm/73314/</link>
			<description><![CDATA[Приходилось ли вам в процессе управления проектом слышать от участников &quot;Мне никто не сообщал!&quot; или &quot;Разве ты не знаешь?&quot; или &quot;Надо же было немедленно сообщить об этом руководству!&quot;? Все эти вопросы — симптомы скверного планирования коммуникаций. Об этом и пойдет речь далее]]></description>
			
			<pubDate>Sun, 25 Oct 2009 12:29:00 GMT</pubDate>
			<author>vzzvzz</author>
			<category>управление коммуникациями</category>
		</item>
		
		
	
	
	
	
	
</channel>
</rss>
