С чего начать внедрение проектного управления

Елена Филипова, руководитель корпоративного Проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Managment Institute, квалификация Project Managment Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

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

Чем характеризуется проект внедрения КСУП

Внедрение проектного управления – особый вид организационных проектов с ИТ-составляющей. Результаты такого проекта можно разбить на 4 группы:

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

А типовой план и контрольные точки можно представить так:

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

  • сопротивление сотрудников вводимым изменениям;
  • несоблюдение (или неверное толкование) правил, отказ от использования документов;
  • сбои в работе новой системы подотчетности;
  • недостаток мотивации для работы по-новому;
  • весь спектр проблем внедрения программного продукта.

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

Обзор проектной деятельности

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

Похоже, что речь о научных изысканиях, а ведь известно, как они осложнены, могут затягиваться и долго не приносить никакого результата. Проект же ориентируется на совсем другое – получение конкретного ответа за ограниченный период времени. Давайте конкретизируем. Результатом такой работы может быть просто перечень наиболее ярких и болезненных проблем при выполнении проектов: провалы, потери, ошибки, нелепицы и боли. А завершаться такая проблематизация должна согласованием, то есть общим признанием и решением необходимости их устранения.

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

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

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

  1. группы небольших регулярных проектов;
  2. крупных проектов стратегического характера.

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

Обзор коротких регулярных проектов

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

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

Основные этапы такого процесса:

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

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

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

Обзор крупных проектов стратегического характера

Вторая группа проектов – это совсем другая история. Если вам удастся выявить и внедрить инструменты, которые наладят работу с экстра-важными проектами компании, то вас поддержат самые ценные заказчики КСУП – Первое лицо и топ-менеджмент. Именно поэтому обследование этой сферы так интересно.

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

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

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

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

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

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

Приложения Tekla работают с огромными объемами сложной информации. Эта информация содержит многомерные данные о геометрии и местоположении. Однако она обрабатывается не как чертеж, карта или трехмерное визуальное представление; вместо этого информация сохраняется в модели данных.

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

Содержание

Как используется модельная информация

Чтобы продемонстрировать преимущества основанного на моделях подхода, рассмотрим, например, эволюцию моделей данных. Так, в последнее десятилетие остро встала необходимость поддержки в 3D-моделях для строительного проектирования временного измерения. Благодаря гибкой природе моделей данных добавление четвертого измерения не составило особых сложностей. Другая тенденция — растущая важность стоимостной информации в качестве «пятого измерения».

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

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

Программная архитектура Tekla

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

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

Технологическая платформа Tekla, получившая названия Tekla Technology, предоставляет необходимые средства для реализации основанного на моделях подхода. Модель данных должна быть интеллектуальной и постоянно сохранять свою целостность, а вносимые в нее изменения должны визуализироваться немедленно. Например, когда изменяется профиль балки в модели строительных конструкций, изменения должны распространяться на множество соединений и других деталей в модели.

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

Правило 13. После завершения проекта нужно запустить следующий «бессрочный» проект — проект по поддержке.

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

Артем Попов. © «Ашманов и Партнеры»

II. Неправильный проект и его лечение

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

Правило 14. Риск неудачи проекта есть всегда.

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

Негативные тенденции накапливаются и в определенный момент превращаются в болезнь. Как распознать их заранее?

Признаки неправильного проекта

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

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

Как распознать заранее будущие проблемы проекта? Есть несколько типичных признаков.

Виртуальная реальность проекта

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

Относительно благополучный проект также может быть не целиком виртуальным, а частично, в некоторых своих кусочках. Чаще всего превращение благополучного проекта в проваленный — это и есть процесс постепенной «виртуализации» проекта.

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

Мифы и отсутствие информации

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

Где руководитель? Например, может считаться, что у проекта есть руководитель, а на самом деле фактически его нет.

— Да есть как бы руководитель проекта, Петров. А, он не руководитель? А кто? Ну хорошо — как бы ответственный за проект, только он сейчас в командировке… Но его можно будет спросить, когда он приедет.

Когда он приезжает, выясняется, что за проект на самом деле отвечает кто-то другой, а Петров не в курсе. Точнее, перед поездкой вместо Петрова назначили другого, но тот пока всё еще занят в другом проекте.

Отсутствие ответов на самые простые вопросы. Никто не может ответить на вопросы, которые должны были бы быть прояснены в самом начале.

Например, считается, что по завершении проекта будет получена очень крутая штука, но никто не знает о том, что ровно это почти у всех есть:

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

А где раньше был Сенькин и его аналитики? Да и сам босс тоже?

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

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

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

  • План без фамилий исполнителей, с устаревшими и не обновленными датами, с пропусками таких ключевых этапов, как тестирование и выпуск, обрывающийся на бета-версии.
  • Десятистраничное «Техническое задание» годичной давности, содержащее перемешку русских и английских кусков, незаметно переходящее в описание функций на языке С++, запинающееся к концу и обрывающееся на полуслове.
  • «Атомарные» недельные отчеты из полутора десятков пунктов в стиле «крутили гайку номер 8 ключом на 13 два рабочих дня», которые абсолютно ничего не говорят ни о месте и назначении гайки, ни о цели кручения, ни о состоянии проекта в целом.
  • Устаревший на два-три месяца план-график работ над столом руководителя.

Бесконечные совещания и «мозговые штурмы»

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

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

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

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

На совещании разбор полетов довольно быстро переходит в кашу, разбивается на несколько независимых дискуссий, слышатся угрозы и упреки начальства, поток технических разъяснений, исторических экскурсов «как всё было». Естественно, рефреном со всех концов стола звучит «ресурсов же не хватало, мы же говорили!». Начальник надувается (ведь это претензия к нему, он же якобы не дал ресурсов).

В середине заседания возникает вдруг конструктивное течение — возникает вопрос «ну хорошо, что делаем дальше?», высказываются конструктивные предложения. Потом опять всё само собой тонет в пучине обсуждения вопроса «кто виноват и как же так вышло?».

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

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

В результате собрания у босса все-таки появляется большая ясность, однако конструктивных решений не возникает.

Постоянный перенос сроков

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

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

Дурная петля загруженности

В разработке ПО очень часто воспроизводится известный случай с пилой:

— Почему вы пилите тупой пилой, так ведь очень долго и трудно?
— Да некогда точить, пилить надо!

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

Обычно эта дурная петля возникает в условиях «небольшого срыва» сроков. Действительно, некогда и незачем писать оценки и планы, когда продукт выйдет вот-вот… Некогда оценить сроки и размер срыва.

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

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

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

Более того, хоть это и выглядит дико в глазах вышестоящего руководителя, но обычно после получения подобной оценки состояния проекта, выданной наконец под давлением, менеджер проекта начинает утверждать, что полная неготовность проекта, огромный объем недоделок и необходимость потратить еще месяцы — совершенно очевидны, закономерны и давно известны. На вопрос «а что ж ты раньше-то молчал!» он обычно отвечает — «да я же говорил, а вы мне руки выкручивали». Босс-то помнит, что на самом деле менеджер проекта ничего не говорил, но доказать это уже невозможно.

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

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

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

Порочная логика разработки

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

— Смотрите, как логично всё получается — сначала простая версия, потом тяжелая, потом смежные продукты, потом новое ядро, потом продукты для всех сегментов, потом глобальные версии, потом локальные продукты для Венеры и Марса, потом…

Очень часто такая логика используется и для переноса срока выпуска проекта:

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

И часто этот ход используется для переноса срока уже проваленного проекта.

Жизнь в виртуальной реальности

Наиболее запущенная стадия неправильного развития проекта — полный переход его существования в виртуальную реальность. Вот основные признаки ее.

Отсутствие обратной связи

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

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

Резонанс распущенности

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

Некоторые менеджеры быстро выучивают способы получать реальные блага за виртуальные ценности. Нужны вам отчеты — будут вам отчеты. Всё легче, чем за программистами гоняться. Маховик виртуальности начинает раскручиваться в уме менеджера.

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

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

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

Много жизней иметь вредно

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

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

Торговля словами

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

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

Награждение непричастных

Применение компанией премий и бонусов «по площадям» также усиливает сдвиг в сторону виртуальности.

Если квартальную премию платят всегда, то никто не ценит ее и она никого не стимулирует. Получается, что настоящими деньгами платят за виртуальные заслуги

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

Возникновение «карманов» безделья

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

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

Очень распространенный пример — отдел веб-дизайна в торговой фирме. Сайт вроде есть, есть программисты и даже маркетинговый начальник. Сайтом все, в общем, недовольны: он давно устарел, медленно загружается, никак не помогает бизнесу, от вебмастера не допросишься обновить простейший прайс-лист. Но компания не видит большого смысла в Интернете вообще, и руки навести порядок на сайте никак не дойдут.

А часто вообще никто не может сказать, хорошо ли работают в таком кармане, потому что посмотреть на результаты «глазами» вообще нельзя, а планов давно уже нет — то есть нет критериев для оценки работы. Например, как оценить качество техподдержки, особенно если нет охоты связываться?

Метастазы виртуальности

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

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

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

Соблазны наведения порядка

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

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

Правило 16. Когда в проекте что-то идет не так, начальство предпринимает титанические бесполезные усилия по наведению порядка.

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

Контроль посещаемости

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

— Менеджер проекта сам программист (вариант — сам не программист), вот и распустил их. Ясно, что нужно их просто тщательнее контролировать. Я сам этим займусь.

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

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

Волна контроля посещаемости иссякает примерно через одну-две недели, максимум месяц.

Контроль количества работы

Далее светлая мысль начальства достигает самой сути: нужно контролировать даже не рабочее время, а количество работы! Возникает смелый план заставить программистов вечером каждого дня (вариант — по пятницам) записывать, что сделано, и тут же «одной кнопкой» отправлять запись в некую общую систему.

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

Пятничные отчеты начинают писаться (руководитель проекта упросил всех поддаться), но их перестают читать наверху через пару недель, а писать внизу — через месяц-полтора.

Правила внутреннего распорядка

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

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

Планы и отчетность

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

Премии и штрафы

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

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

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

Опять ползут слухи об увольнениях. Кое-кого даже увольняют или понижают в зарплате. И опять волна наведения порядка спадает через некоторое время — почему-то период релаксации всех нововведений составляет 1-2 месяца.

Комсомольские накрутки и политинформации

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

Всё это в деталях описано в великолепных комиксах Скотта Адамса про бедного разработчика Дилберта и его глупого босса (), так что опустим подробности.

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

Закручивание гаек не работает

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

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

Правило 17. Бессмысленно муштровать исполнителей, нужно муштровать менеджеров.

Это правило легко доказать следующим рассуждением:

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

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

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

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

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

Таким образом, «лечить» исполнителей либо через голову среднего менеджера, либо при его поддержке (что еще более отвратительно) в большинстве случаев теоретически неправильно и практически вредно.

Правило 18. Наведение порядка в проекте всегда должно начинаться с головы.

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

Как вылечить неудачный проект

Дать рецепт для дистанционного лечения невозможно, поскольку каждый больной уникален (по слухам, слово «галиматья» происходит от фамилии французского врача XIX века, лечившего по переписке). Можно дать только общие советы на основе прошлого опыта.

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

Вот какие основные этапы с необходимостью возникают при лечении проекта:

Разбор полетов и инвентаризация

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

Признание наличия проблем

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

Признание ошибок и вины

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

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

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

Создание новой команды

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

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

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

Лечение больных самолюбий

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

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

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

Кто старое помянет…

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

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

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

Правило 19. После разбора полетов нужно списать все долги и запустить проект заново.

Перезапуск проекта

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

Вместо заключения: о чем не сказано в статье

О материальном стимулировании

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

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

О специальных средствах управления проектами

Если в офшорном программировании и системной интеграции использование систем управления проектами (от MS Project до Rational Unified Process) может быть просто необходимым условием получения заказа, то в малых и коротких проектах они, на мой взгляд, необязательны, хотя и могут быть полезны. Подробное обоснование этой точки зрения — тема для отдельной статьи.

Читателю может оказаться полезной уже упоминавшаяся статья Джоэла Спольски , подробно рассказывающая про эффективное использование Microsoft Excel для планирования разработки ПО и неудобство использования для тех же целей пакета для управления проектами Microsoft Project.

О стандартах качества

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

Однако в коротких проектах накладные расходы на поддержание системы качества могут съедать до 15-20% бюджетных средств и времени. Для короткого проекта это недопустимо.

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

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

Неспроста наиболее крупные и успешные разработчики ПО используют собственные, приспособленные к внутренним задачам системы качества.

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

III. Приложение

Словарь ненормативной лексики руководителя

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

8 мин.

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

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

Сервисы для управления проектами: обзор возможностей

Мегаплан

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

Сервисы для управления проектами Мегаплан

Сервисы для управления проектами Мегаплан

Знакомясь с Мегапланом, вы оцените простоту его интерфейса. Зайдя на сайт, зарегистрируетесь в позиции «Попробовать бесплатно», заполните поля с реквизитами, а затем с помощью курсора ознакомитесь с азами пользования сервисом. Управление проектами станет не такой сложной задачей.

Пошаговое меню «Задачи», нужное вам для того, чтобы добавить первую (или очередную) задачу, стоящую перед компанией, вынесено в верхний блок панели. Аналогичным образом организовано меню «Сделки».

Возможности Мегаплан:

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

Мегаплан работает с приложениями Android, iOS, Windows, Mac, его дисковое пространство неограниченно. По стоимости Мегаплан относится к бюджетным сервисам.

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

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

Сервисы для управления проектами AmoCRM

Сервисы для управления проектами AmoCRM

Сервисы для управления проектами AmoCRM

Возможности AmoCRM:

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

Возможности сервиса для управления проектами GEN CRM особенно ценят сотрудники отделов продаж, львиную долю работы которых составляет обработка входящих звонков и online-заявок.

К достоинствам GenCRM относится интеграция с большим количеством каналов, сайтом, корпоративной почтой, чатом; обширная телефония без помех; индивидуальная адаптация сервиса под потребности компании.

Сервисы для управления проектами GenCRM

Сервисы для управления проектами GenCRM

Визуальное преимущество GenCRM — вся система умещается на одной странице. Очень удобно видеть все параметры отчетности сразу.

Возможности GenCRM:

  • ежемесячно сервис обновляется на основе параметров обратной связи
  • управление проектами в системе, где есть полезные опции для сотрудников: телефон, электронная почта, чат
  • пользовательский доступ по протоколу HTTPS
  • опция резервного копирования сразу в несколько мест
  • высокие параметры конфиденциальности

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

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

Сервисы для управления проектами WireCrm

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

Возможности WireCrm:

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

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

Сервис управления проектами Wrike выглядит очень функционально: вы видите календарь с основными запланированными событиями и список поставленных перед сотрудниками задач, что упрощает управление проектами разного объема. Вы сможете быстро просмотреть динамику развития, что сделано по каждому таску. Весьма удобна возможность создать автономные папки для отдельных проектов (бесплатно хранилище рассчитано на 2 Гб).

Сервисы для управления проектами Wrike

Сервисы для управления проектами Wrike

Возможности Wrike:

  • наличие функционала для повторяющихся задач с возможностью ведения диалога и командной работы с файлами
  • опция подключения к родственным сервисам для командной работы с интеграцией почты
  • опция приоритета отмеченных задач (многоуровневая иерархия проектов)
  • доступность для приложений iOS и Android
  • наличие новостной ленты (в реальном времени)
  • функционал табличного форматирования
  • интеграция с Google Drive, Dropbox, Box, iCal
  • разветвленный алгоритм работы с задачами (визуальная демонстрация, формирование подзадач посредством массовых опций и обзора c кастомными виджетами, выставление фильтров для задач)
  • наличие плагинов для Outlook и Apple Mail для партнерской работы по задачам
  • интеграция с MS Project, Excel, Salesforce, RSS

Что говорят пользователи: хорошо зарекомендовала себя благодаря возможности создания пользовательских групп с разными уровнями доступа, наличию единого корпоративного входа через Active Directory, высоким параметрам безопасности.

«Простой бизнес»

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

Сервисы для управления проектами Простой бизнес

Сервисы для управления проектами Простой бизнес

Среди достоинств «Простого бизнеса» можно выделить следующее: разработчики предоставляют неограниченное время его бесплатного использования с минимальным набором функций.

Возможности сервиса «Простой бизнес»:

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

Что говорят пользователи: радует наличие версий для Windows, Web, Mac OS, iOS и Android, оперативно работает техническая поддержка. Управление проектами и контроль за реализацией можно осуществлять, по сути, с любого устройства.

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

Сервисы для управления проектами Pipedrive

Возможности Pipedrive:

  • сервис формирует подробные данные о каналах продаж (с поэтапным просмотрам по группам товаров, с опцией просмотра временной шкалы и формированием отчета)
  • необходимый функционал для поэтапного мониторинга и фильтрации
  • удобство обратной связи с клиентами (CRM)
  • простота управления лидами с возможностью добавления полей и форм, адаптированных под потребности компании
  • для ускорения доступа к системе можно использовать мобильные приложения
  • неограниченное резервное копирование с созданием регулярных копий
  • мощности API позволяют переносить сделки в другие системы (Evernote, Yammer)

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

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

Еще один недостаток Trello — отсутствие автоматической постановки задач, их придется копировать вручную.

Сервисы для управления проектами Trello

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

Возможности Trello:

  • удобство управления проектами достигается следующим образом: ваши проекты выглядят как панели задач, в которые включены списки подзадач, разбитых на карточки
  • функционал карточек включает в себя назначение сотрудников в проекте, создание контрольного списка и дедлайна с возможностью прикрепления файла
  • мобильность карточек: их можно перетаскивать из списка в список, собирать в группы
  • сервисом управления проектами можно пользоваться с iPhone, Android, Windows Phone 8

Trello — это веб-сервис для совместной работы, способный помочь в организации и управлении проектами.

Что говорят пользователи: даже пробной бесплатной версии достаточно для организации работы в длительной перспективе; случайное удаление карточек не является необратимым; из интерфейса можно работать с облачными сервисами Dropbox и Google Диск; особенно удобна система для просмотра нескольких одновременно реализуемых проектов.

Active Collab

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

Платформа Active Collab англоязычная, что многие отнесут скорее к недостаткам, чем к преимуществам.

Сервисы для управления проектами Active Collab

Сервисы для управления проектами Active Collab

Возможности ActiveCollab:

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

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

Exo Platform

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

Возможности Exo Platform:

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

Что говорят пользователи: одно из достоинств Exo Platform — наличие обширной разнопрофильной базы знаний — столь же удобно, как и пользование корпоративной социальной сетью.

Освоению Worksection помогает предоставленный разработчиками большой объем обучающей информации (вкупе с роликами на YouTube).

Сервис Worksection позволяет хранить все базы по проектам на сайте компании.

Сервисы для управления проектами Worksection

Возможности Worksection:

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

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

Битрикс24

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

Сервисы для управления проектами Битрикс24

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

Возможности Битрикс24:

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

Что говорят пользователи: недостатком Битрикс24 является отсутствие готовых шаблонов для типовых документов.

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

Несмотря на ограниченное количество инструментов для условного форматирования, сервис удобен наличием форума для корпоративного общения.

Сервисы для управления проектами Onlyoffice

Возможности OnlyOffice:

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

Что говорят пользователи: особенно ценна и удобна поддержка офисным редактором сервиса документов в PDF, DOCX, RTF, XLSX, PPTX и т. д.), а также возможность пользоваться приложением с iOS-устройств.

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

В равной степени эффективен сервис для управления проектами Yammer и для организации обратной связи с партнерами.

Сервисы для управления проектами Yammer

Возможности Yammer:

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

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

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

Особое достоинство Intrum — наличие API для интеграций с функционалами других сервисов.

Возможности Intrum:

  • наличие структурированной клиентской базы с архивацией
  • функционал для создания каталога товаров и услуг
  • ведение учета потока заявок (онлайн, IP-телефония, SMS
  • контроль за документооборотом с использованием шаблонов
  • возможность создания собственного мобильного приложения под потребности компании
  • интеграция с корпоративными сайтом и почтой
  • опция переадресации звонков с их записью

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

Снегирь

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

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

Сервисы для управления проектами Снегирь

Возможности сервиса Снегирь:

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

Что говорят пользователи: Снегирь особенно эффективен в работе проектных компаний, региональных и центральных представительств брендов, структур рекламы, маркетинга и контроля.

Как правильно ставить задачи?

Однажды Билл Гейтс сказал, что ключ к успеху любой компании лежит через ошибки и постоянное совершенствование продукта. Трудно не поверить человеку, который создал многомиллиардную компанию. Каждый, кто хочет расти и развиваться, будь то менеджер проекта, маркетолог или Scrum Master, должен быть гибким и иметь свою собственную форму оценки эффективности.

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

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

Формулировка задачи

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

Четкое представление результатов

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

Что будет считаться выполнением задачи

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

Дополнительная информация

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

Дедлайны

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

Ответственные, исполнители и соисполнители

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

Добавить комментарий