Управление проектами *

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

Это лишь одна из функций, которые компания Microsoft собирается реализовать в MS Project, чтобы сделать эту систему управления проектами проще и расширить сферу её использования. Стив Балмер по этому поводу мудро заметил, что, по большому счёту, каждого офисного работника можно назвать менеджером, потому что он управляет как минимум своим собственным временем. Другими словами, MS Project должен быть доступен для пользователей любого уровня.

Главной инновацией в пользовательском интерфейсе Project станет появление стандартной для всех программ MS Office панели с кнопками в верхней части экрана. Процедура заполнения полей будет упрощена: вместо существующего метода перед пользователем будет появляться пустая колонка, которую можно заполнять любой информацией, а её тип будет автоматически распознаваться.

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

Для новой версии MS Project пока не придумано названия, потому что неизвестно, в каком году она выйдет. Возможно, это будет MS Project 2009 или 2010.

via IDG News Service

Достаточно давно я столкнулся с проблемой, что в хорошей и правильной программе TortoiseSVN (по-русски «тортойс эС-Ви-эН»), нету такой необходимой и желанной вещи, как экспорт только тех файлов, которые были затронуты определенными ревизиями. Особенно начинаешь страдать, когда приходится перезаливать на сервер весь проект, куда входят достаточно увесистые библиотеки и фреймворки. Можно, конечно, не включать библиотеки в Subversion, но это уже тема для другой беседы.
И вот, совсем недавно, один очень хороший гуру и друг совершенно ненавязчиво рассказал мне, как изящно и красиво решить эту проблему.

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

Побывав лично с обеих сторон баррикад, и рассматривая именно фриланс, а именно короткие работы, а не заказную разработку (тут очень нечеткая грань, согласен), можно выделить следующие моменты и действия, требующие от фрилансера знаний основ управления проектами:

Практика экстремального программирования включает в себя «Small Releases» — частый выпуск «коротких» релизов программ с интервалами в несколько недель.
Подразумевается, что нужно это для того, чтобы получать «обратную связь» от пользователей и вовремя вносить изменения. Сами релизы при этом, как правило, включают 1-2 «фичи» и исправление некоторых (а не всех) ошибок.

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

Во вчерашнем материале я описал общие ситуации, с которой сталкивался при работе с удаленщиками. В комментариях к нему проскочили многие из решений, к которым пришел на основе практики. Да и в целом тема оказалась жизненной — аналогичные проблемы имели и другие заказчики удаленных услуг. Какие люди вообще идут во фриланс? Я встречался с несколькими типами:

В ответ на habrahabr.ru/blog/pm/27099.html хочу привести взгляд на ситуацию со стороны фрилансера.

За годы работы с заказчиками у меня скопилась маленькая “тележка” проблем при работе во фрилансе. Пришло время немного систематизировать эти знания. Приступим.

Проблема 1. Отсутствие техзадания.

К сожалению у 99% заказчиков нет никакого техзадания вообще. Поэтому это затрудняет реализацию конечного продукта, и вообще говоря, делает практически не возможным достижения какого-либо изначально запланированного результата по той простой причине, что на словах клиент может хотеть одно, а в результате — получается либо другое, либо куча проблем.

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

Методы решения:

предлагать написание техзадания, как отдельную услугу и закладывать ее в бюджет проекта

просить клиента вернуться, когда у него будет техзадание

предлагать описать более-менее формально в текстовом виде, что же все-таки требуется (Это на порядок лучше, чем если задание сформулировано только в устной форме) .

Проблема 2. Проблемы с финансами.

Основная часть заказчиков на данный день во фрилансе — частные лица. Это является ограничивающим фактором в плане оплат — очень часто бюджет отдельно взятого заказчика меньше, чем если бы Вы это делали для фирмы. А у фирм свои проблемы с фрилансерами — наличные деньги у них почти не вращаются, а оплату по безналу фрилансер может принимать только, если он зарегистрирован, как частный предприниматель. Поэтому в плане бюджетов — есть некоторые ограничивающие факторы. К счастью — ситуация меняется в лучшую сторону — те физлица, которые раньше пришли на рынок, вложили какую-то часть своих финансов — и теперь зарабатывают на своих же проектах, что позволяет бОльше финансов привлекать для разработки новых, доработки/усовершенствования старых проектов.

Методы решения:

Регистрация себя, как частного предпринимателя. Но далеко не каждая фирма еще свяжется с частным предпринимателем — есть ньюансы с оплатой.

Поиск “раскрутившихся” частных лиц, предложение им своих услуг.

Проблема 3. Нежелание платить предоплату.

К слову будет сказано — без предоплаты вообще не стоит работать с любым клиентом. Разве что только в начале фрилансерского пути. Либо выполнить мелкий кусок работы над проектом (в течении, например, часа), чтобы показать то, что Вы умеете заказчику (как альтернатива — тестовое задание).

Заказчики не желают платить предоплату по нескольким причинам:

а) не желают потерять время и деньги
б) этот заказчик является кидалой и хочет получить готовую работу и ничего не заплатить

Методы решения:

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

если заказчик не хочет платить по причине б) (проверяется “методом тыка”) — не работать с таким заказчиком.

стать проверенным фрилансером с множеством позитивных отзывов и довольных клиентов — тогда риск для заказчика потерять время и деньги -> 0. Честный фрилансер, дорожащий репутацией никогда не кинет отдельно взятого заказчика, перечеркивая этим года работы на репутацию.

Проблема 4. Коммуникации.

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

Методы решения:

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

взять себе менеджера и общение с клиентом перенести на его плечи.

работать только при увеличенной плате за работу (для компенсации проблем в общении).

Проблема 5. Недоверие.

Клиенты никому не доверяют. Даже самим себе. Это удивительно — но факт. Хотя большая часть и успокаивается после первых этапов работы — некоторый процент не доверяет до самого конца — то, что они ищут подвоха — проскальзывает в любой их фразе, в любом письме, что существенно осложняет работу с таким клиентом.

Методы решения:

Показать клиенту, что Вы — профессионал. Делайте все на 5+ и даже больше, чем требовалось по заданию.

Попытаться с помощью общения свести негатив на нет — найти общий язык, общие темы, попытаться расположить человека к себе эмоционально.

Продолжение следует.

Оригинал находится тут

Фрилансеры — один из самых доступных и частых способов закрыть фронт работ, который в компании выполняются нерегулярно. Либо в случае, если свои люди беспросветно заняты на других проектах, а нанимать новых нет смысла или времени. Я работаю с фрилансерами по обоим причинам. Хотя за последнее время потерянные сроки и нервы убедили, что время и смысл для поиска постоянных сотрудников лучше все-таки найти. А субподрядчиков использовать только для совсем уж нетипичных работ.

Для моего друга KamniumKamnium в связи с переходом на Битрикс стал актуальным вопрос управления проектом (за этот же нелюбимый многими хабралюдьми Битрикс ему понизили карму до такой стпени, что ему теперь не написать в блог).

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

Имеется проект, в котором легко выделить подзадачи и подзадачи подзадач, то есть легко строится развесистое дерево проекта (максимальная детализация — это одна из самых важных, на мой взгляд, рекомендаций «Романа об управлении проектами»).

В наступившем 2007-08 учебном году Государственный университет управления (ГУУ) объявляет набор учащихся на новую программу профессиональной переподготовки «Менеджмент в сфере интернет-технологий». Как сообщили нам в PR-отделе Образовательной компании RMA, обучение по такой специальности осуществляется впервые в России.

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

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

1. Ваша компания начала нанимать консультантов, чтобы было кого во всем обвинять
2. Ваш сервер для нагрузочного тестирования упал с ошибкой «Все, б$%, я больше не могу!»
3. Ваша системы контроля версий — это набор папок «revision 1», " revision 2",: «revision 465» и т. д. на сетевом диске
4. Ваше ТЗ состоит из трех страниц, написанных за 2 часа перед обеденным перерывом.
5. Вы стали подыскивать новую работу, потому что не хотите поддерживать код, который сейчас пишете.
6. Первая фраза на любом совещании «Есть хорошие новости, есть плохие. С каких начнем?»
7. Прогресс вашего проекта теперь измеряется числом исправленных багов, а не числом реализованных фич.
8. Вы подружились с уборщицей

По просьбам трудящихся — перевод статьи Пола Грехема (Paul Graham) ‘Holding a Programm in One's Head’.

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

Стиль изложения может показаться сбивчивым

Если начинать со слишком высоким качеством и начинать не с того конца, это убъет проект, потому что проектом мы считаем цель, на которую выделены ресурсы. Даже если у вас крупный инвестор, вашим ресурсом станет его терпение.
—
Качество и перфекционизм — это пародия плодотворной работы на саму себя. Потому что хорошая работа начинает приносить плоды сразу же, как только начинается.

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

Сегодня у человечества есть современный автомобиль, у которого есть современное колесо. Они развивались параллельно. С точки зрения человека начала века, они являются идеальными. Если бы мы решили создать такое колесо и работали бы над ним с начала века как над отдельным проектов, у нас не было бы сегодня нашего колеса.

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

Каждый хороший проект должен пройти эволюционный процесс, который всегда един и не может быть разделен части, которые проходят последовательные этапы. Если вы хотите поделить все таким образом — придумайте для ваших этапов стыковочные API, которые будут выступать искусственными точками фиксации, «якорями» проекта, меняя конфигурацию которых вы сможете органично управлять разработкой. строго говоря, каждый API является описанием некой конфигурации и будет являться одновременно для одного проекта целью, и стартовыми данными для другого. В этом случае можно вести разработку одновременно, обладая гарантией совместимости результатов на стыке.

Почему качество губит? Таким образом, мы подошли к самому главному. Проект — это мешок ресурсов, на которых написано, в какой результат он должен превратиться. Ресурсы всегда конечны, и молитесь, чтобы этот конец был счастливым. Рано или поздно наступит точка, которую вы обозначали на своих ранних графиках латинской буквой G, а в поздних, возможно, стали использовать её русский антоним. Так вот, если заклепочный отдел сделает заклепку нового самолета идеальной, которая по характеристикам даже на 20% лучше, чем планировалось, потратив ради благого дела (кто поспорит?) ресурсы в виде 20% превышения выделенного времени и денег, эти 20%, для простоты выраженные в чистой энергии, не достанутся менее харизматичным соседям из отдела, который занимается, например, системой охлаждения.

Я не говорю, что от этого чаще падают самолеты, я лишь хочу, чтобы перестали бороться с плохим качеством только с помощью повышения качества ;)

Компания HP совместно с исследовательским подразделением HP and the Economist Intelligence Unit (EIU) провели чрезвычайно любопытное исследование: сколько IT-проектов завершаются точно в срок. Результаты показаны отдельно по странам, и это очень интересные результаты.

Конечно же, дело не столько в недисциплинированности самих программистов, сколько в недостаточном профессионализме менеджеров. Именно менеджеры всегда виноваты в срыве сроков, а не программисты. Собственно, об этом говорит и анализ причин задержки проектов (под хабракатом).

Швеция — 44%
Швейцария — 24%
Чехия — 20%
Германия — 19%
Дания — 16%
Великобритания — 11%
Израиль — 8%
Финляндия — 8%
Франция — 6%
Бельгия — 4%
Испания — 4%
Италия — 4%
Нидерланды — 4%
Россия — 4%

Компания Projity решила выпустить под открытой лицензией версию своей системы для управления проектами, которая до сегодняшнего дня была доступна в виде веб-сервиса Project-On-Demand. По мнению специалистов, новая программа OpenProj — это очень серьёзная заявка на то, чтобы потеснить позиции нынешнего лидера на этом рынке Microsoft Project.

Программа OpenProj будет интегрирована в крупнейшие дистрибутивы Linux, включая Mandriva, Mint и Sabayon. Кроме того, сейчас идут переговоры с OpenOffice.org и компанией Sun Microsystems, разработчиком StarOffice, чтобы интегрировать OpenProj и в эти офисные пакеты.

Наконец, Projity обещает вложить «значительные ресурсы» в создание общепризнанного открытого стандарта на документы для программ управления проектами. Этот формат мог бы дополнить спецификации OpenDocument Format и стать альтернативой закрытому формату .mpp/.mpx из программы Microsoft Project, хотя с ним OpenProj тоже умеет работать.

Навеяло. Готовил материал на cornflake.ru, и вдруг сделал статью собственного сочинения.

Командная работа, teamwork, работа в команде — одно из ключевых понятий в современном бизнесе. Сейчас все реализуют «проекты», и реализуют их именно с помощью «команд». Тема командной работы богата. И именно поэтому в этом материале мы не будем поверхностно освещать все ее аспекты, а остановимся на концепции построения эффективной обратной связи внутри команды.

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

• Как известно, программисты, обычно, не очень любят писать документацию… поэтому чем проще и комфортнее будет её писать, тем больше вероятность, что её таки будут писать.
  
  • Поскольку мы работаем из дома, то должна быть возможность писать документацию локально, на своей машине.
  • Чтобы это было делать комфортно, нужна возможность использовать для этого любимый текстовый редактор, никаких форм на вебсайтах а-ля вики или систем заточенных под конкретный редактор/IDE.
  • С доступом в инет у всех по-разному, и чтобы исключить ситуацию, когда документация небыла написана исключительно потому, что когда появилось настроение её писать по закону подлости отвалился инет — для написания документации не должен требоваться инет.
• Документация должна быть доступна всем, кто работает над проектом. Это включает как возможность читать её через вебсайт так и работать с ней как с обычными локальными файлами.
• Желательно, чтобы документация поддерживала какой-нить язык разметки и гиперссылки, чтобы её было удобно читать.
• Возможность редактировать документацию из браузера (а-ля вики) желательна, но не очень важна (разработчики будут работать с файлами, так что эта фича может пригодиться в основном клиенту, который врядли будет напрямую править документацию).

Введение.
Вот уже 5 лет я занимаюсь веб — разработками. За это время приходилось и на коленке делать сайты за несколько сотен долларов и участвовать в довольно крупных проектах. За последний год меня не оставляет ощущение deja vu. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.

 

Имеем корпоративный сайт. На таком сайте размещена информация о компании, услугах, которые компания предлагает, а также, возможно, каталог продукции. Как сделать так, чтобы пользователь мог легко общаться (задавать вопросы) компании?