• Государственный университет управления начинает подготовку интернет-менеджеров

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

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

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

      • Перевод
      По просьбам трудящихся — перевод статьи Пола Грехема (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%
          Читать дальше →
        • Онлайновая альтернатива Microsoft Project выходит под свободной лицензией

            Компания 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 тоже умеет работать.

            Скриншот программы OpenProj
            Читать дальше →
          • Обратная связь в командах как инструмент повышения эффективности

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

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

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

                Читать дальше →
              • Разработка сайта. Взаимодействие с компанией-разработчиком

                  Читать дальше →
                • Распространенные проблемы при управлении проектами (Web)

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

                       

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

                      Проводите ли вы анализ проекта после его завершения (риски, ошибки, удачные решения)?
                      • 14.7%После завершения каждого проекта30
                      • 21.6%Провожу по ходу проекта44
                      • 1.9%Нет, это пустая трата времени4
                      • 19.7%Хотелось бы, но все руки не доходят40
                      • 25.6%Отмечаю в уме, но не документирую52
                      • 16.2%Зачем, НЛО анализирует проекты за нас33

                    Самое читаемое