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

Компания 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. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.

 

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

 

В данной статье Игорь коснется человеческих проблем, возникающих при управлении относительно небольшим проектом, где применять всю мощь науки просто некогда или незачем (нерентабельно).

Как известно, знание немногих принципов часто заменяет знание многих фактов. Вот выработанные Игорем самые общие принципы управления проектами:

А. Кадры решают всё.

Б. Ключ к успеху проекта — передача ответственности участникам проекта.

В. Ключевой момент переключения ответственности — принятие решения.

За подробностями — к оригиналу:
http://www.ashmanov.com/pap/ashrul2/

P.S. Автор рисунка — Артем Попов.

Правила Ашманова — must read, однозначно — до встречи на Кибе
rutube.ru/tracks/37785.html

Текстовый вариант правил:
www.ashmanov.com/pap/ashrul.phtml

Полгода назад решил найти нового виндового клиента к Subversion. TortoiseSVN тормозил сильно, да и глючил время от времени.
Требования к новому клиенту были следующие: бесплатный (или относительно недорогой) продукт, живой и постоянно обновляемый, хороший и удобный UI, встроенные плагины, реализация не на Java.
Искал недолго. Спасибо Википедии (http://ru.wikipedia.org/wiki/Svn) за хороший список svn-клиентов. Выбор пал на два продукта: RapidSVN и SmartSVN. Первый написан на C++, второй на Java (решил просто посмотреть, хотя по требованиям не подходил).

RapidSVN оказался сырым и глючным (вылетал постоянно какой-то алерт). Прожил он максимум полчаса.

SmartSVN сразу привлек нормальным человеческим интерфейсом.

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

Плюсы более-менее очевидны:

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

Проверочный список на качество управления релизами.

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

На Хабре общается немалое количество менеджеров интернет-проектов и не меньше разработчиков: дизайнеров, программистов. Из своего опыта знаю, что часто бывают моменты непонимания одних другими. Чтобы как-то помочь и тем и другим достичь взаимопонимания, предлагаю резюме статьи Роба Уаллинга (Rob Walling):