17 февраля 2013 в 12:12

Менеджмент ИТ-проекта

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

На хабре есть много тем по специфичным аспектам менеджмента проектов. Но именно основы менеджмента до сих пор не были освещены.

Попробуем закрыть этот пробел.

Кратко обозначены, выделены и пояснены основные, наиболее важные моменты.

UPD. Пост про менеджмент, а не про менеджеров.

  • Чем управлять
  • Основной процесс менеджмента
  • Нет делегирования? И это хорошо
  • Малая боевая диверсионная группа
  • Системный анализ
  • Divide et Empera
  • Логгирование
  • Оценка множественных и неявных факторов
  • Время, как основной фактор
  • Два в одном


Чем управлять


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



Основной процесс менеджмента


Менеджер работает с процессами. Процессы являются составной частью проектов.

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



Нет делегирования? И это хорошо


Один из самых популярных и в тоже время противоречивых методов традиционного менеджмента — делегирование. Есть куча академической информации о том, как, кому и когда поручать задания.

В условиях стартапа, как правило, делегирование в общем понимании недоступно. Слишком мало денег, слишком мало людей.

Непосредственных участников у новорожденного проекта, как правило, мало. Нанимать экспертов со стороны — дорого, да и к тому же чревато утечкой информации и дополнительными временными затратами.

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

Малая боевая диверсионная группа


На самом деле работа в условиях ограниченных ресурсов является более эффективной.

1. Избыточные ресурсы расхолаживают
2. В малой группе короче и эффективнее коммуникации
3. Малую группу легче настроить на цель
4. В малой группе эффективнее контролируются процессы
5. В малой группе проще охранять коммерческую тайну

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

Не надо стесняться малого размера вашей команды. Вообще, никаких комплексов! Только энтузиазм, только объективизм.

Системный анализ


Благодаря методу системного анализа малые рабочие группы решают сложнейшие задачи. Причем делают это быстро и дешево.

Я не призываю вас создавать тонны трудночитаемой документации. Но использование даже некоторых основных методик даст вашему проекту жизнь. Вот эти методики:
— разделение задач на подзадачи;
— выделение субпроектов;
— запись (логгирование) всего.

Цели системного анализа таковы:
— получение прозрачного и очевидного представления всех деталей проекта;
— выявление потенциально узких мест;
— выявление скрытых факторов, прежде всего затрат;
согласование тактического и стратегического видения между всеми участниками проекта.

Divide et Empera


«Разделяй и влавствуй», завещали нам древние правители. И по сей день эта методика управления проектами оказывается одной из самых эффективных.

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

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

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

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



Логгирование


Записывать имеет смысл все и всегда. В текстовом редакторе, в еверноте или в специализированном ПО — не важно. Главное — записывать, и регулярно осведомляться о том, что с записями осведомлены все ключевые участники проекта.

Все подряд записывал не только Сталин, но и все продвинувшиеся ученые, предприниматели и подвижники.
Дана Скалли подробно записывала на диктофон процесс вскрытия инопланетян, и заметки по расследованиям. Если вам в какой-то момент станет скучно писать — вспомните ее.



Оценка множественных и неявных факторов


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

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

Одним из таких приемов является применение оценок-весов.

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

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

Время, как основной фактор


Называя что-то «дорогим», программист подразумевает затраты ресурсов машины или сети. Аналогично, менеджер ИТ-проекта имеет в виду время. Буквально — время является основным измерением, для которого можно применять оценки вида «дорого» или «приемлемо».

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

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

Подробно этот вопрос раскрыл в посте про управление рисками.

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

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

Два в одном


Подготовительные мероприятия и проект в рабочем режиме — это два разных проекта!

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

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

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

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

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

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

Неопытные всегда акцентируют внимание на действиях, связанных с открытием проекта, но имеют пространное представление о дальнейшем развитии проекта и нормальном режиме его работы.
Например, вот некоторые из различий в предметной сфере, показывающие разницу между проектами-этапами:
Подготовительные работы Основной процесс
Покупка ПО или программирование Поддержка технического обеспечения
Дизайн Бизнес-модель, план доходов и план расходов
Исследования, первое планирование маркетинга и рекламы Маркетинг и выполнение плана рекламы
Определение состава специалистов ФОТ


Оба процесса имеют итеративные признаки и общие объективные черты, но в то же время имеют массу различий.

Эксперта, мнение которого возможно будет учитывать инвестор, будет интересовать следующее.
  • Раздельные оценки затрат для двух этапов
  • Раздельные временные оценки (время до получения прототипа, альфы, беты, открытие, время до рентабельности)
  • Оценка бизнес-модели и ее детальных параметров
  • Оценка затрат на маркетинг и рекламу до открытия проекта и в процессе

Календарный план-график обычно составляется по кварталам.
В процессе бизнес-планирования имеет смысл попытаться спрогнозировать развитие проекта хотя бы на 1-2 года вперед. Но это уже другая тема.

Может быть что-то упустил? Дайте знать — напишу в следующих темах.

Спасибо за внимание и удачи вам!
Артем @customtema
карма
–4,8
рейтинг 0,0
Пользователь
Самое читаемое Управление

Комментарии (14)

  • +5
    Одни менеджеры проектов кругом, а работать некому.)
    • +4
      Иногда мне кажется, что они(менеджеры) играют в карты, кто проиграл, тот и работает
    • 0
      Хех. Напоминает мне слова Чапаева из недавнего сериала. Там было приблизительно так же: «Некогда учиться, воевать надоть».
  • +2
    Здесь нет одного — списка рисков и списка «что делать», если что-то пошло не так
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Product manager, насколько я понял ваш вопрос.
      • +1
        Скорее бизнес/системный аналитик.
    • 0
      заказчик? клиент?
  • +2
    Отличный материал, спасибо. Откликов мало, так как интересен не всем, но зато «не всем» весьма полезен.

    Объясните цель и ценность логирования. «Записывать имеет смысл все и всегда.» звучит как мантра.
    Вот, предположим, пишем и пишем пару лет, накопилось материалов на тысячи листов и сотни тегов.

    В каком процессе участвуют эти логи кроме логирования как такового?
    • 0
      Имел в виду рабочие записи проекта.

      Обычно это десятки, редко сотни листов.

      Их отсутствие ведет к проблемам. Удивительно, но есть очень много Project Managers, которые ведут дела, держа всю информацию в голове. При этом лажают не по-детски, но тетрадочкой все равно не пользуются. Наверное, из религиозных соображений, или культурных особенностей…
      • 0
        но есть очень много Project Managers

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

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

          Я рассматриваю действительно другую ситуацию — когда записей нет совсем (вся информация в голове), что очевидно тупо, и когда они принципиально есть.

          Вернитесь к статье — там есть выводы из обоих вариантов.
  • –2
    Ну пусть тут полежит
    image

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

Интересные публикации