Менеджер проекта с ТЗ в руках — это ещё не признак управления проектом

    — Привет! Ну ты как, кто, где? — давно не виделись.
    — Да я менеджер ИТ-проекта в большой компании.
    — О, PRINCE, риски, экстремальное управление, финансы. Сложно!
    — Да не. Так, ТЗ от клиента технарям и обратно таскаю за деньги. Фигня.


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


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

    Неслучайное начало


    В феврале 2007 года в Нижнем Новгороде проходила конференция по управлению проектами. Тогда это была супер крутая и инновационная тема. Несколько сотен представителей крупного бизнеса, предпринимателей, депутатов, научных работников и студентов обсуждали существующие на тот момент практики управления проектами и механизмы бизнес-процессов. Признаться честно, выглядело всё это совершенно безбожно: иностранные компании и отечественные промышленные гиганты рассказывали о том, как они управляют проектами в своих компаниях и призывали перенять их опыт. Перед ними сидели растерянные представители малого бизнеса и понимали, что там одни системы автоматизации стоят миллионы долларов, не говоря уже об обучении, менторах, внедрении. Казалось, это будущее, которое за горами. В том далёком начале 2007 года наша RegionSoft CRM только начинала свой путь, а участниками конференции были двое будущих наших сотрудников, тогда ещё студенты, ничего не слышавшие о нашей компании. И никто не знал, что в августе 2018 года выйдет релиз нашей CRM-системы RegionSoft CRM 7.0, а мы напишем на Хабр (которому на тот момент не было и года) статью о том, что управление проектами доступно всем.

    Не верите? Зря. На самом деле, в бизнесе всё есть процесс и всё есть проект. Стоит только немного заморочиться.

    Осторожно! Статья написана профессиональными разработчиками и может содержать определённую долю сарказма и нелюбви к РМ.

    На самом деле нет, мы их любим


    Почему мы поднимаем эту тему?


    В любой компании рано или поздно стартует проект. Это может быть вывод нового продукта или услуги, создание новогодней рекламной кампании, внедрение программного обеспечения, запуск новой линии производства и т.д. Тогда настаёт момент выбрать менеджера проекта (координатора) среди сотрудников либо нанять специалиста и сделать всё в лучшем виде. Но выглядит весь этот процесс далеко не безоблачно.

    • Бизнес не знает, что такое проект. По сути, это ничего сложного: цели, задачи, бюджет, риски, распределение ресурсов, отчётность. Но какие-то компоненты постоянно игнорируются: то бюджет выходит за рамки (а это ошибка планирования), то задачи пересекаются, накладываются и делают работу одних сотрудников невыносимой, а других — халявой. Из-за этого под угрозой находится весь проект, что бьёт прежде всего по интересам заказчика (внутреннего или внешнего — без разницы).
    • В управлении проектами постоянно забывают о рисках. А они есть всегда, от обыденных и легко прогнозируемых (нехватка ресурсов, косяки поставщиков, болезнь сотрудника) до совершенно внезапных, которые всегда нужно учитывать (сезонность, экономическая ситуация в мире, работа с валютой, законодательный риск). Безусловно, возникновение риска ставит под удар весь проект. Поэтому оценка риска должна быть проактивной, а не реактивной — то есть происходить до того, как песец решил вас посетить. Если проект длинный, переоценка рисков должна осуществляться каждые 2-3 месяца жизни проекта.
    • Бизнес увлекается методологией и забывает о сути работы, теряя время на формальности. Особенно этим грешат крупные компании и, как ни странно, стартапы. Причём причины у них разные: стартапы стремятся соответствовать моде и обязательно фиксировать факт управления по PRINCE или PMBOK, а в крупных компаниях (особенно не работающих по ISO) всегда есть коты, которые, как известно, когда нечего делать, яйца лижут сотрудники, которым необходимо продемонстрировать свою важность и приверженность стандартам. Нередко в погоне за правильной организацией документации, митингов, этапов и т.д. теряется быстрое и качественное выполнение работы.
    • Менеджеры проектов (именуемые project manager) — весьма неопределённая категория работников. Более-менее неплохо дела обстоят в ИТ, где большинство (но, увы, не все) проджектов растут изнутри, из среды разработчиков. Но горе ИТ-компании, если менеджером технического проекта становится гуманитарий или выпускник «Менеджмента». Нет, это не плохие ребята, и вероятно, они прочитали много толстых книжек (включая многочисленные источники «мотивации»), но ИТ слишком специфическая отрасль для того, чтобы проектами управляли люди без технического бэкграунда (уверены, что с нами будут спорить — и хорошо, если есть истории успеха). Что касается других сфер, то в них менеджерами проектов берут людей без должного опыта, но, например, с релевантным образованием или резюме, в котором можно наврать с три короба. В общем, отбор должен быть более критичным, а ещё лучше — из внутренних резервов.
    • В работе с проектами учитываются задачи и ресурсы только одной стороны. У любого проекта есть холдер (исполнитель) и заказчик, который ждёт результата исполнения проекта. Чаще всего весь проект нацелен на интересы заказчика, которые нужно исполнить любой ценой, реже — исходит исключительно из ресурсов исполнителя (внутренние проекты). При правильном управлении проектами должны быть учтены интересы всех участников, действия должны быть согласованными.
    • Страх перед руководством загоняет проект в кризисную ситуацию. Часто сотрудники боятся сообщить о реальном положении дел, информировать о срыве сроков или перерасходе бюджета. В конечном итоге проект может быть выполнен с низким качеством или же погрузиться в полностью безнадёжное состояние. В свою очередь у руководителя в такой ситуации может не быть инструмента контроля и мониторинга проекта.
    • Работа менеджера проекта не измерима или плохо измерима, а он сам всеми силами пытается выйти из-под KPI (например, утверждая, что проект — это эксклюзивная работа, которую нельзя измерять) и уйти в сторону премий по итогам (разовые). Такой подход снижает ответственность менеджера за проект и «размазывает» её по другим участникам.
    • У проектов часто не устанавливаются границы — расплывчатое понимание масштаба проекта может легко превратить его в долгострой.
    • Внутренние проблемы проекта и проблемы коммуникации. Изначально менеджер проекта — это лидер и одновременно проводник-коммуникатор, задача которого среди прочих координировать и направлять команду. Но случается так, что менеджер считает себя единолично правым, ставит себя выше команды и игнорирует предложения и даже целые пласты работы, занимаясь микроменеджментом и стремясь закрыть собой все задачи. Команда в прямом смысле слова постепенно учится молчать. Конечно, проектная работа, даже во главе с самым гениальным менеджером, не тот случай, где один в поле воин.

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

    • Увы, как и в любой деятельности, в проектной работе почти всегда есть место принципу Парето: 20% команды по факту выполняют 80% работы. Конечно, можно смириться с этим положением вещей, но лучше стимулировать работу и получить более эффективную команду.

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

    Компоненты проекта и профессиональный софт


    Существует довольно распространённая формула, которая годится для любого проекта вне зависимости от методологии и величины компании:

    project = time + cost + scope




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

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

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

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

    Границы проекта — это не только оценка его масштаба, но и строгое следование требованиям заказчика и, конечно, техническому заданию и паспорту проекта. Техническое задание — это фактически броня исполнителя, потому что можно всегда сослаться на описанные объёмы работ и ограничения. Чтобы ТЗ было успешным, необходимо тщательно собрать требования, разбить их по этапам проекта и согласовать техзадание. Будет идеально, если вы оговорите и зафиксируете не только то, что будет сделано, но и то, что сделано не будет.

    Ещё один важный вопрос: какое программное обеспечение подходит для управления проектами?


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

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

    Ещё один тип программ — это CRM, BPM и другой софт с встроенными механизмами управления проектами. Поэтому мы встроили модуль управления проектами в редакцию RegionSoft CRM Enterprise. В ходе разработки у нас были дополнительные ограничения (точнее, наоборот, требования к расширению) — модуль управления проектами находится внутри нашей RegionSoft CRM, а значит, должны быть дополнительные связи. Помешают ли они задачам управления проектами? Нет, конечно — связь с клиентами и другими сущностями пойдёт только на благо пользователю:

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



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



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

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



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



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

    Так как управлять проектами?


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


    joyreactor.cc

    • Соблюдайте главную триаду ограничений сферы управления проектами: сроки, стоимость, границы. Таким образом бизнес (и команда!) будет управляться более качественно и прозрачно. Даже чисто психологически марш-бросок в виде проекта воспринимается позитивнее, чем вечная рутина: когда ты знаешь сроки и видишь свет в конце тоннеля, ну то есть окончание задачи, работается не в пример легче.
    • Не бойтесь стартовать одновременно несколько проектов — грамотное распределение задач и ресурсов даст вам выигрыш во времени и в конечном итоге компания сможет работать быстрее и с высоким качеством.
    • Лошадь сдохла — слезь. Если проект разваливается, границы и сроки давно пробиты, не тяните его на себе и не пытайтесь скакать дальше, проанализируйте причины и проблемы и перезапустите задачи. Бывает, что все проблемы кроются в таких вещах как, например, слишком громоздкий проект — достаточно его разбить на несколько небольших и параллельных подпроектов и дело полетит.
    • Собирайте отчёты, проводите ретроспективы и анализируйте проблемы, достижения и откровенные факапы. Таким образом, вы сможете избежать проблем в будущем. Если решение оказалось успешным, не оставляйте его одним лишь поводом для командного поедания пиццы с пивом, разберитесь в причинах успеха и смело внедряйте находки в жизнь.
    • Не промахнитесь с менеджером проекта (чаще всего с этого все беды и начинаются). Менеджер проекта это не человек с какими-то требованиями к образованию (типа «Менеджмент», красный диплом) и не хороший презентатор, а человек, который разбирается в теме проекта и должен организовать систему, в которой всё отлажено, проще говоря, каждый процесс даёт выход, который служит входом для следующего процесса. В этом, конечно, кроется и коммуникация, и делегирование, и умение работать в команде.
    • Управляйте изменениями — если в проекте появляется что-то новое, обязательно обработайте событие, не отстраняйтесь и не отказывайтесь от изменений. Опять же, всё в рамках триады: стоимость, сроки, границы.
    • Проект должен быть реальным — по задачам, которые он решает, и для исполнения. Если у вас есть 200 тыс. рублей и нет дополнительных источников финансирования, глупо затевать строительство десятиэтажного дома — не хватит даже на котлован. Обязательно оцените соответствие имеющихся ресурсов задачам проекта.
    • Определите, насколько экономически эффективен и/или целесообразен проект. Вот где кладбище погибших стартапов — именно в неумении просчитать эффективность. Можно запустить производство электромобиля из дерева или приложение для подсчёта убитых комаров, но это будет проект ради проекта, об экономике нет и речи. Оцените реального заказчика или будущий объём рынка перед тем, как стартовать проект. Кстати, нонкоммерсов это тоже касается — к примеру, благотворительность и меценатство тоже могут оказаться бесполезными, но отожрать массу ресурсов.
    • Планируйте загрузку с определённым горизонтом — так вы сможете понять, кто чем занимается и какие ресурсы уже задействованы и будут задействованы в дальнейшем. Например, для этих задач можно использовать групповые планировщики, встроенные в систему управления проектами или CRM (ну или диаграмму Гантта).
    • Управляйте документацией — все документы проекта должны быть собраны воедино и содержать исчерпывающую информацию о каждом этапе, платеже, требованиях и т.д.
    • Не тоните в методологии (например, вы считаете, что право на существование имеет только водопадная модель или только Agile), а лучше выбирайте лучшее, комбинируйте и делайте так, чтобы методология была вашим инструментом, а не вы её рабом и заложником.
    • Не забудьте закрыть проект. Совет кажется смешным, но только для того, кто с проектами не работал. Не допускайте частично незавершённых проектов, долгостроев и остановок в одном шаге от финала. Впрочем, закрыть проект — это реально сложно.

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

    Вы же не хотите получить зарплату имитацией денег?


    image У нас проходит новогодняя акция на всё программное обеспечение, разработанное нашей командой, так что если кому нужна мощная десктопная и функциональная RegionSoft CRM со скидкой до 15%, ловите момент, есть дополнительные плюшки.
    • +22
    • 12,5k
    • 6

    RegionSoft Developer Studio

    154,00

    CRM-система, программное обеспечение для бизнеса

    Поделиться публикацией

    Похожие публикации

    Комментарии 6
      +1
      Очередная статья о том что проектное управление это круто.
      Сразу возникает вопрос — в каких условиях НЕ эффективно использовать проектное управление?
        0
        Кстати, реально круто. Приходилось видеть проекты разного масштаба, и если были хотя бы ТЗ и управление ДДС, уже выходило удачно. Проектная работа не годится для краткосрочных задач, для рутинных операций, для очень долгосрочной работы с размытыми перспективами (какая-то крупная сложная разработка) — в силу того, что всё равно в проект не влезет. Ну это моё видение. У автора оно может и отличаться. Хотя лично я многое бы сводил к проекту, но без фанатизма.
          0
          Например, в условиях низкой маржинальности (так как проектное управления — это не дешево), в операционной и функциональной деятельности. Но проектное управление позволяет справиться с более высокой степенью неопределенности и интенсивностью изменений, чем это обычно бывает при стандартной операционной деятельности.
          –1

          Вы, конечно, простите, но описанные проблемы, и, особенно, фраза
          ". Но горе ИТ-компании, если менеджером технического проекта становится гуманитарий или выпускник «Менеджмента»."


          Выглядят именно как недопонимание Роли Project Manager и отсутсвия необходимого бищнес бэкграунда для данной профессии.


          Понимание контекста и сферы бизнеса, безусловно, важны, но профильное образование в проектном управлении, рисками и процессами гораздо важнее для этой роли.
          Отрицание этого равносильно утверждению того что SCRUM и Agile это исплючительно про ПО, забывая что оба этих направления вышли в основном из TPS (Toyota Production System), а сам SCRUM изначально разрабатывался для проектов не связанных с ПО — это то что сам Jeff говорит на своих выступлениях, тренингах и в своих книгах.


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

            0
            Когда я учился, мне рассказывали байку про руководителя в СССР, которому поручили провести новый год. Он подготовился, речь подготовил, товарищам дал рекомендации. И прошло все так: Каждый вставал, зачитывал что-то. В духе совещания. И вроде и люди есть и речи произносят и ёлка стоит. Только это праздник, а не митинг трудящихся. Ни танцев, ни музыки, ни веселья. Поэтому если нету соответствующего бекграунда, то ты можешь сделать все в лучшем виде, но не соответствующе данной отрасли.
            –2
            OMG, зачем я это прочитал?
            Вы спорите с голосами в своей голове.

            Сначала вы описываете или махровые заблуждения о проектном управлении или типичные ситуации поломанного проектного управления. Но дальше я не увидел объяснения как ваша CRM (предлагаемая в качестве информационной систему правления проектами) позволяет избегать вышеописанных проблем? Т.е. ваша CRM магически должна приложить подорожник к брешам в корпоративной методологии проектного управления (если она вообще есть). Методология первична, инструмент — вторичен. Инструментом может быть и листок бумаги и Excel и физическая канбан-доска. Чем вы лучше этих вариантов? А чем вы лучше Trello или Open Project или кучи другого похожего бесплатного софта?
            Среди типичных проблем вы упоминаете игнорирование рисков. Как ваша система помогает решить эту проблему? Не увидел на скриншотах и в описании функционала ни чего про риски.

            «Не бойтесь стартовать одновременно несколько проектов» — как ваша система помогает не бояться мультипроектной работы? Как менеджер или его руководитель с помощью вашей программы может контролировать ход 5-10 проектов или вех по ним?

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

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