Статью выкладываю по разрешению автора. Оригинал здесь.

Я знаю два варианта организации времени начала работы в IT фирме и довелось мне поработать с обоими вариантами.

1. Приход на работу к конкретному времени. Сродни советскому: в 8.00 все должны быть на работе иначе штраф или даже увольнение. Уходят все в 17.00
2. Свободный приход к любому времени. Тут может быть куча вариаций, когда надо работать 8 часов в день или 40 часов в неделю или вообще никто время не смотрит, лишь бы работа делалась.

Я проработал 7 лет в компании, где надо было приходить каждый день в 9.30 и уходить не раньше 18.30, а теперь уже полгода в компании, где каждый приходит и уходит когда хочет.
И теперь я готов сравнить варианты.

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

Полагаю, ситуация довольно типична.

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

Самые посещаемые местные сайты компаний (и их можно пересчитать по пальцам) имеют не более 200 посетителей в день (волгоградцы, поправьте).
Речь не идет о порталах (Волга34, Волгоград в сети, v1.ru) и форумах (например, форум волгограда).

В среднем это число для приличного «корпоративного сайта» колеблется между 20 и 90.
Понятно, что это мизер.

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

Кому интересен договор на сайт, смотрим тут: Договор навороченный, Договор простой (удален автором).

Этот топик про более редкую ситуацию, когда перед собственно проектом нужно сделать ТЗ, а это большая и серьезная работа. На нее нужен договор и цена.

Японское слово Муда (muda) — означает потери, неоправданные расходы и любую деятельность, которая потребляет ресурсы, но не создает ценности для клиента.



Давно размышляю на тему неэффективных коммуникаций, как внутри компании, так и между разными компаниями, как это мешает развитию рынка и созданию новых продуктов.

Управлять наёмными рабочими и распределенными проектами — это просто и весело. Стоп, что за чушь? На помощь приходит хороший контроль версий — именно то, что вам нужно, чтобы правильно вести ваши проекты.

Далее — перевод статьи Collaborate and Connect with Subversion. Это мой первый перевод, поэтому был бы очень рад вашим замечаниям.

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

Вот уже 15 лет экономист Кэй-Ют Чен (Kay-Yut Chen) проводит экономические эксперименты для компании HP. С помощью своих опытов он пытается прогнозировать спрос на технику HP, тестирует маркетинговые программы ещё до их запуска и определяет наиболее выгодную ценовую политику для тех или иных товаров. Хотя опыты д-ра Чена сэкономили работодателю миллионы долларов, но до последнего времени он оставался чуть ли не единственным учёным, который работал в этой уникальной области.

Всё изменилось после 2002 года, когда Нобелевскую премию получил другой специалист по экспериментальной экономике Вернон Смит «за лабораторные эксперименты как средство в эмпирическом экономическом анализе, в особенности в анализе альтернативных рыночных механизмов». Это был настоящий прорыв. После этого события многие крупные компании, в том числе из IT-индустрии, открыли собственные отделы по моделированию экономических процессов. Например, команды экономистов и компьютерщиков в Google и Yahoo оптимизируют аукционы по ключевым словам. В компании eBay экспериментальные экономисты помогли разработать новую систему обратной связи для сервиса аукционов, что позволило на 25% увеличить оборот сайта.

«Когда вещи становятся более сложными, становятся трудно управлять бизнесом только с помощью лозунгов, — говорит стенфордский профессор Озалп Озер (Özalp Özer), который недавно по заказу Hitachi запустил эксперимент по определению оптимального промежутка времени между выпуском новых моделей HDD с точки зрения компромисса между НИОКР, производством и маркетингом.

Хабралюди! Меня уже какой день мучает вопрос: а что не хватает современным web-based системам управления проектами? Я уверен, что многие из вас работают в командах, при этом разнообразных. У некоторых есть офис, а некоторые разбросаны на сотни километров друг от друга. Так вот: чем вы все пользуетесь? Что устраивает, а чего не хватает? А главное — о чем мечтаете? =)
Заранее спасибо за все ответы.

Итак. Вы обсуждаете проект. Добились встречи с важной персоной. Встреча проходит в формате Вы + Босс + N помощников босса. И вот на самом интересном месте у босса звонит телефон. Он отвечает. Что делать?

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

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

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

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

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

Я склонен утверждать, что эта теория применима к коллективам численностью от 10 до 200 человек. Хотя последние наблюдения за государством, армией и большими компаниями начинают убеждать меня в том, что все используют ее, но не признаются в этом :)

Изначально это была секретная теория :) Т.е. сотрудники компании не должны были знать ее, чтобы не противодействовать выполнению планов. Но сегодня я убежден, что понимание отношений внутри коллектива необходимо всем сотрудникам, так как без этого вообще иногда не удается решить застарелые проблемы или понять причину поступков руководителей и сотрудников. Ну и просто это открывает еще большие возможности по достижению выдающихся результатов в компании.

Иными словами я рекомендую данную статью для прочтения как директорам компаний или руководителям отделов, так и сотрудникам компаний. Вдруг пригодится :)

Позавчера в Москве прошла конференция PMDays 2008. Я решил выложить текст презентации своего выступления здесь, надеюсь, что он поможет вам в вашей текущей работе, также готов ответить на любые вопросы. Спустя какое-то время на RuTube появятся видеозаписи выступлений.

• Презентация
  Пример концепции
  
  

  План рассказа

  
  
  
  • Что такое Концепция
  • Как она устроена
    
  
  
  

Вопрос предоплаты, ее величины и необходимости был поднят при обсуждении предыдущих тем.
Были высказаны разные позиции, в том число совершенно полярные, вроде «Я против работы по предоплате»
Где истина? Как всегда — между.

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

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

Рассмотрим типичную ситуацию.

Каждый четвёртый веб-проект не вписывается в отведённый ему бюджет, а почти в каждом третьем случае разработчики не могут закончить работу к дедлайну. Такую мрачную статистику выявило новое исследование, проведённое компанией New Bamboo, которая занимается разработкой ПО на Ruby on Rails. В опросе участвовали около ста IT-менеджеров и директоров компаний.

Главной причиной подобной безалаберности называют слишком большое количество сторон, участвующих в проекте и желающих повлиять на него. И это при том, что около половины веб-проектов создаётся силами собственного IT-подразделения компании и только 28% отдаётся на аутсорсинг.

Неприглядная картина веб-разработки дополняется и другими цифрами. Оказывается, даже после всех согласований, возможного дополнительного финансирования и продления сроков 21% проект всё равно не соответствует требованиям заказчика. Печальные цифры сохраняются не только для крупных, но и для совсем мелких проектов. Ситуация усугубляется, если заказчик требует усложнить преокт и добавить в него модные современные технологии: социальные сети, приложения электронной коммерции, фичи Веб 2.0.

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

 

В теории решений может быть, разумеется, сколько угодно. Вот пример, компания INDIVID так описывает свой проект в портфолио:

«Дизайн сайта разрабатывался и согласовывался в течение года (в частности, оказались отвергнуты 28 начальных вариантов стилевых макетов).» Источник.

Является ли этот факт поводом для гордости, вопрос спорный. Скорее, это говорит об ошибках в управлении требованиями.

Профессор Эрик Шпикерманн (Erik Spiekermann) из Германии, основатель Metadesign, в интервью опубликованном в журнале «Мир Дизайна», говорил, что в дизайне у задачи может быть не больше двух решений.

Речь идет о практике, разумеется. И главное на практике — четкость поставленной задачи, основанная на общем видении заказчика и исполнителя.

Хотел бы рассказать о некоторых эпизодах проектного менеджмента, особенно подходов к управлению отношений с клиентом на примере веб-конторы. По словам Terentii, моего ex-коллеги, клиенты «вели с конторой, мягко говоря, по-хамски — достойные наследники традиций Солтычихи». Дело в том, что… клиент всегда прав. Итак…

Когда проект сайта Х-Банка был готов и нужно было погашать договор, менеджер проекта не смог получить платеж «с наскоку» и стал вести подобные записи:
— 20 января 11:02. звонил в банк. отв.менеджер не подошел. обещал перезвонить через час.
— 20 января 15:02. перезвонил. его не было. позвонил его руководителю. секретарь не соединила.
— 25 января 11:02. звонил в банк. отв.менеджер подошел к телефону. наорал, почему я не позвонил раньше. назначили встречу.
— 27 января 15:00. на встрече вынесли мозг, сказали все переделывать. на ТЗ в договоре не смотрели. написал им изменения, какие мы можем сделать с сохранением стоимости.
— 28 января 11:00. позвонил чтобы узнать что с е-мейл. не соединили…
И так далее.

Метод критической цепи: эффективное управление проектами с использованием буферов времени и ресурсов

Работа стремится занять все время, отпущенное на нее.
Закон Паркинсона.
Если какая-нибудь неприятность может произойти, — она случается.
Закон Мерфи.

Немного статистики

Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех.
По данным многочисленных исследований Standish Group¹ для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.
И хотя в последнее время, с развитием инструментов и техник управления проектами, эти цифры стали уменьшаться, общая картина говорит о том, что мы как менеджеры проектов плохо делаем свою работу.
Данная статья рассматриваем использование относительно новый метод управления проектами, метод критических цепей (МКЦ), сравнивая его с традиционным подходом к управлению проектами.