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

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

    Хочу попросить не отсылать к известным методологиям PMI, PRINCE2 и т.д. Так как в них указаны диапазоны бюджетов, в которых применимость их будет давать эффект больший чем затраты на саму методологию — это от 50 000 $ USA. Интересуют решения для проектов бюджетами от 5 000 до 30 000 $ USA.

    1. Неправильная оценка проекта. Почти все заказчики хотят fix-cost. И это правильно с их точки зрения, только имея понимание об этом, они принимают решение запускать или не запускать проект.
    Как лечится: выделение консалтинга в отдельный проект. По результатам имеем концепт проекта, ТЗ, ИСР, бюджет, календарь.

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

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

    4. Учет изменений на проекте и документация особенностей. Реализация идет с согласованными отклонениями от постановки, и это нормально, но когда проект уже запущен и летит, никто не занимается документацией этих отклонений и «фич». В итоге, если приходит новый человек на проект или его в дальнейшем надо сопровождать, то чтобы ввести его в курс дела, ничего нет кроме как первоначального устаревшего ТЗ и спецификаций. Проект изменился, он уже другой. Денег на исправление нет никогда. Такой проект становится кошмаром для support.
    Как лечится: фиксировать все изменения в концепте проекта, хотя это ресурсозатратно.

    5. Недостаточная обеспеченность проекта ресурсами. Сюда можно включить все разнообразие:
    a. Людей не выделяют в нужном количестве и нужной квалификации
    b. Людей забирают в середине проекта на тушение пожаров
    c. Людей забирают в середине проекта на support их прошлых проектов
    d. Неадекватная замена исполнителей
    e. Текучка на проекте – уходят те, кто «в теме», а набирают тех, кого найдут
    Лекарства пока нет. Видимо такова специфика отрасли – «овертаймить» и проваливать сроки.

    6. Замыкание многих процессов на самых компетентных и перегрузка их работой. Нет делегирования. Всегда на проекте те кто знает и делает и те кто делает только если скажут. Ответственные и компетентные люди не всегда используют делегирование или этому не способствует обстановка в команде.
    Лекарства пока нет. Видимо такова специфика отрасли IT. Хорошие инженеры и программисты по своей природе интраверты. Все говорят о Agile team building как лекарстве, но пока не получилось. Так как этот процесс утянет и так ограниченные ресурсы и деньги, понадобится компетентный и недешевый HR. Если у кого есть идеи, посоветуйте.

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

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

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

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

    Комментарии 47

      +7
      10-й пункт: на самом деле есть лекарство, если чувак говнокодит сейчас и не слушает советов опытных чуваков, он и дальше будет колбасить говнокод и толку с него никакого не будет. Решение только одно — отбор ответственных за свои действия разработчиков в команду, старательных и стремительных. Если этих качеств у разработчика нет, он никогда не будет писать библиотеки и думать о будущем проекта
        +2
        Подход хороший если ресурсов достаточно, но если 5-й пункт срабатывает — борьба за ресурсы в условиях ограниченного бюджета, то работать приходится с теми людьми что доступны.
        Тут надо придумать какой-то личностный мотиватор, чтобы воздействовал на профессиональную гордость.
        Как-то так…
        +2
        >>Текучка на проекте – уходят те, кто «в теме», а набирают тех, кто найдут
        Лучится очень просто:
        подписывается контракт с работником на каждый новый проект по которому он не может разорвать контракт предупредив не за 2 недели а за 2 месяца.
        ЗА это неудобство работник получает доп. денег.
        А а также всегда должны быть минимум 2 человека, которые разбираются в 1 фиче. Один мастер, а второй хотя бы падаван.
          +4
          Вы уверены, что такой контракт, вернее такой пункт в нём, будет юридически значим?
            0
            По договору оказания услуг можно вписать туда неустойку — и вуаля.
            Не единым трудовым договором жив рынок работы.
              +1
              Человек, привыкший к белой зарплате, соцстраху и т. п., может и не согласиться. Или согласиться, а потом в суд подать с иском о признании отношений трудовыми. Или сообщить «куда следует». В общем ещё дороже может выйти, чем текучка.
                +1
                Вы хотите сказать, что есть на Руси люди, которые любят судиться с работодателями? И что у них потом все хорошо складывается в жизни?
                В теории всё гладко, на практике же…

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

                Мне кажется, Российский национальный колорит во всем этом слишком силен.
                  +6
                  Восстанавливаться у «плохого» работодателя не нужно. А вот съесть ему мозги сразу после увольнения вполне даже можно и нужно. Ибо нефиг.

                  Я уже на несколько хороших работ из-за таких дурацких договоров не пошел. Проще не идти, чем судиться. Товарищи силились придумать договор о неконкуренции после увольнения, договор о неконкуренции во время работы (в свободное время я кодю опенсорц по той же теме, по какой работаю), адовые договоры о неразглашении, итп. Всех, всех лесом!
                    0
                    С меня недавно взяли NDA, довольно дурацкую:) при этом не то что не сняв сканы моих документов, но даже туда не заглянув (!) Кстати, читается ли такая NDA действительной, если она скреплена только моей подписью (без документов с надписью «копия верна, число-дата-подпись»)?
                      +1
                      Если информация в документе позволяет вас однозначно идентифицировать, то считается. Хотя, конечно, что там записано.
                        +1
                        ФИО, серия и номер паспорта. Но мало ли откуда они их взяли? Это так, если что…
                          +1
                          Подпись ваша? ФИО, серия и номер паспорта ваши? Вывод — именно вы этот документ подписывали. Вот написали бы левые — в случае конфликта пришлось бы сложнее работодателю. Но если бы доказал свою правоту, то вас вполне могли бы и за мошенничество привлечь. Проверять документы в таких ситуациях не обязанность работодателя, а право.
                            +1
                            Тоже правда. Тогда проще не нарушать NDA :)
                              0
                              Или если есть острое желание нарушить — сходить к юристу и проконсультироваться :) Может документ в целом или отдельные его пункты не имеет силы.
                          0
                          Если честно, я пожалел, что не написал левые данные :) просто не знал, что они не будут смотреть документы=)
                      +1
                      Восстанавливаются по суду не затем, чтобы работать дальше, а чтоб написать по собственному, получить положенное по закону (включая компенсацию за вынужденный прогул) и компенсацию за моральный вред. Плюс трудинспекция может проблем устроить.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        +1
                        >> Вы уверены, что такой контракт, вернее такой пункт в нём, будет юридически значим?
                        Это не граничит с тем, что прописано в законе (в законе говорится, что не менее 2х недель отработать. Отработать != предупредить заранее. Это юридическая тонкость.)
                        К тому же я писал про контракт, у контракта могут быть другие условия, отличные от бессрочного трудового договора по ТК. В договоре должно быть ясно указано, что за это неудобство человек получает больше денег. Тогда это не нарушает его права.

                        блин, парни, так не о том же спор. Вы тему затронули того, что человеку плохо работается и он хочет судиться с работодателем. Это совсем иная плоскость.
                        Если ему плохо работается, то он может после испытательного срока свалить. Испыт. срок — до 3х месяцев может быть. Но если ему работается хорошо, но вдруг предложили больше, то чувак извини. Мы же тебе помогли в трудные времена — взяли на хорошую ЗП, ты получал бонус за то, что обещался предупредить нас за 2 месяца. Получал? Вот и предупреди.
                        Конечно, если этот пункт — часть соцпакета в 30 т.р. то вряд ли он покажется интересным.

                        PS 90% трудовых споров выигрываются в пользу работника. Кстати, потому что работодатели сами себе ямы роют часто, уклоняясь от уставных отношений.
                          +1
                          Пункты трудового договора, ухудшающие положение работника вроде как являются ничтожными. Максимум это бонус себе сможете забрать назад, если я не предупрежу. Но, наверное, в порядке гражданского спора, а не трудового. То есть сначала выплатите, всё что мне причитается, а потом будете отсуживать бонус.

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

                          Вот я и спросил, уверены ли вы, что не попадёте в эти 90%.
                            0
                            я ещё раз делаю акциент, на том, что контракт и трудовой договор — разные понятия. ТД — это контракт со всеми бонусами от ТК, которые гарантирует гос-во (CMS если хотите).
                            Контракт как таковой — это срочные договорные отношения (система разработанная с нуля).
                            В ней описываются все аспекты трудовой деятельности, иногда дублируя ТК.
                            Да, он не должен быть хуже, чем типичные трудовой договор.
                            Но в контракте можно прописать, что одним из условий является возможность частого смена места работы, ненормированный график (да, в пределах установленных ТК), наличие или отсутствие авто. И подписавшись под этим работник соглашается.
                            Также одним из условием разрыва является обязанность сторон предупредить о разрыве не меньше, чем за n месяцев. Блин, ну какое здесь ухудшение условий ТРУДА?
                            За это работник получает доп плюшки.
                        +1
                        Не боитесь признания такого договора трудовым и получения «вуаля» уже в свою сторону и в куда большем размере?
                    +2
                    Коллеги, а «проектный менеджер» — это то же самое что project manager, или что-то другое?
                      +3
                      Да, здесь это синонимы
                        +1
                        А теперь обратите внимание, насколько все различается в зависимости от типа «проекта». У вас — работа на внешнего заказчика по автоматизации бизнеса. Для кого-то еще — веб проект на средства инвестора. Для другой команды — разроботка игры на собственные деньги. Или тиражируемого коробочного продукта. При этом в каждом случае пересекаться будт меньше половины пунктов вашего списка :).
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +1
                            У нас так исторически сложилось в компании, думаю что из-за дословного перевода от project manager
                            В принципе может возникнуть сопоставление с ролью «руководитель пакетов проектов, куратор проектов». Надо будет подкорректировать текст.
                            • НЛО прилетело и опубликовало эту надпись здесь
                          +2
                          Тоже самое, что и Менеджер проекта, и совсем по-русски Руководитель проекта.
                          +1
                          В итоге все упирается в деньги.
                            +7
                            По 10 пункту мы так решаем.
                            1. Сделали ставки на несколько опенсорс платформ: фреймворк и пару специфичных цмс.
                            2. На базе это фреймворка разработали собственную библиотеку, которая ускоряет разработку.
                            3. Фреймворк и библиотека заставляют использовать определенные стандарты кодирования.
                            Причем это не только оформление синтаксиса кода, а и стандарты проектирования системы.
                            4. Если есть время каждый новый программист выполняет тестовый проект, в котором использует наработки.
                            Потом происходит разбор кода.
                            5. Сделали обучающее видео :)

                            В процессе — система еженедельных семинаров на интересные темы. 2 часа в неделю найти можно.
                              +2
                              Еще появилось пару модификаций внутренней библиотеки. В планах построить её разработку (даже скорее просто поплнение) по типу разработки опенсорс проекта.
                              Опять же с нуля никто ничего не будет разарбатывать, каждый сам за себя. Чтобы получить систееу, нужно сначала создать её, а потом заставить других в неё поверить.
                              +3
                              4. Учет изменений на проекте и документация особенностей.

                              По этому вопросу я считаю следующее:

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

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

                                Проблема действительно серьезная.
                                Решение на мой взгляд такое:

                                Нужно работать с людьми, которые хотят это делать хорошо.

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

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

                                Хорошо работать невозможно заставить, можно только мотивировать.

                                  +2
                                  >1. Нужно мотивировать профессионалов. Нужно создавать атмосферу, в которой приятно развиваться как профессионал и делать свою работу. Нужно искать в работе новое. Открывать горизонты. Сейчас скажут — мы не выбираем проекты, у нас все проекты говно и т.п. Могу сказать одно — любую работу можно сделать плохо, посредственно, хорошо и великолепно. Стремится нужно к последнему.

                                  а это очень правильно сказано.
                                  +1
                                  По моему мнению универсального решения всех пунктов (или по каждому отдельного) нету, собственного и тем отличаються разные студии или компании что одни как все делаю четке, а у других как так не все гладко :).
                                  У Лебедева кстати по этому есть особое мнение: Догоро. Долго. Охуенно. (и он прав, така уже наша доля… ИТ — издержки профессии, как любят говорить. )
                                    0
                                    Насчёт последнего пункта (охуенно) можно поспорить. Но вот пиар у студии налажен запредельно офигенно и эффективно. Они очень и очень здорово умеют себя продавать, чего очень сильно не хватает другим фирмам.
                                      +1
                                      Согласен, если проект хорошо продан, больше половины описанных рисков не возникнет в принципе. Но на деле в организации 20% проектов продаются хорошо, а на прибыль от них тянутся остальные 80%.
                                      Да и по статистике в 70% провальные проектов, основная причина — это недофинансирование.
                                        +1
                                        …а основная причина недофинансирования — неверная оценка стоимости со стороны исполнителя.
                                    +2
                                    > Денег на исправление нет никогда. Такой проект становится кошмаром для support.

                                    заказчик может как раз выдавать такие проекты «командам 911», которые его будут реанимировать, реверсинжинирить и потом документировать/технологизировать. Есть конторы, которые только на том и живут — реанимировать до состояния «уже дышит, но еще не двигается», а на выздоровление проект отправляется индийскому-русскому-китайскому-итп аутсорсам. Выздоровления часто не наблюдается, и в конце цикла проект опять попадает в реанимацию. Для «команд скорой помощи» это как раз неисчерпаемый источник доходов.
                                      +1
                                      > Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.

                                      еще практика: все осуществляют контроль за свои деньги-время. Иногда заказчик вообще не заказывает в проект PMа, а только непосредственных исполнителей, и PMит на своей стороне, но при этом продолжает спрашивать аналитику по команде. Получается, разработчик тратит от 30 минут до 2 часов в день на бумажную работу и анализ (как для себя как для участника проекта, как для удаленного сотрудника заказчика, как для участника проекта своей компании, как для офисного работника своей компании), которые он не может записать в оплаченные часы. Рабочий день из любого количества часов превращается в 10-часовой.
                                        +1
                                        в смысле, это плохо.
                                          0
                                          Необходимо сразу закладывать это время в смету.
                                          Если заказчик хочет отчетности — на нее нужно время.
                                          Если это время забирается у разработчиков — это косяк управления, с этим надо бороться.
                                          Если оно сознательно забирается у разработчиков — это эксплуатация, от таких надо просто валить. Исключение только в том случае, если разработчик в доле.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            +1
                                            10 пункт решается внедрением методик управления знаниями, это целая парадигма ведения бизнеса. На западе это направление уже входит в силу, в России я знаю только одних ребят, которые действительно шарят в этой области: knowledgemanagement.ru/
                                              +1
                                              План управления рисками проекта — будет хорошим документом, тем более, что база рисков у вас набралась уже. И для заказчиков этот документ будет полезным.
                                                0
                                                По поводу 10.
                                                Нужно иметь хотя бы несколько выполненных проектов близких предметных областей, чтобы можно было переиспользовать прошлый опыт. Причем переиспользовать код, как правило, удается только для всяких утилитных вещей. Можно делать по аналогии — это все равно намного дешевле, чем писать «с нуля». И забудьте про серебрянные пули — их не бывает.
                                                Чтобы переиспользование опыта старых проектов, он должен быть задокументирован. Документации подлежат:
                                                • все нетривиальные алгоритмы;
                                                • все компоненты и расширения используемых framework'ов;
                                                • высокоуровневая модель компонентов системы;
                                                • сложные системы взаимодействия для выполнения какой-то узкой задачи (например, progress bar'ы для веба) — и диаграммы, и текстовое описание (и то, и другое необходимо);
                                                • при выполнении для нескольких заказчиков — четко фиксировать участки, специфичные для заказчика;
                                                • все детали, специально проясненные у заказчика (резюме переписок и устных бесед);
                                                • все локальные решения и предположения, принятые в обход заказчика (с указанием причин выбора);

                                                Мотивацией документирования может служить опыт успешных разработок, которые без документации никогда бы не выжили. Например, те же используемые framework'и. Нужно четко увязать в головах зависимость между управляемостью проекта и документацией. Каждый должен понимать, что если сегодня он это не задокументирует, то завтра он наткнется на чужой код, который кто-то не задокументировал, и положит кучу времени на анализ.
                                                В обязательном порядке необходимо осуществлять проверку качества документации на предмет содержания в ней всех деталей из указанного выше списка. Если чего-то не хватает — необходимо явно указывать на это и добавлять (все мы люди, все ошибаемся). Должно быть понимание, что качественная документация является показателем профессионализма, что бы там не говорили. IMHO, профессионал всегда способен четко изложить детали. Оформлением может заниматься кто-то еще, но полноту информации должен обеспечить разработчик.
                                                  0
                                                  >>Текучка на проекте – уходят те, кто «в теме», а набирают тех, кто найдут

                                                  Чтобы постоянно иметь несколько разработчиков «в теме», полезно проводить регулярный code review. Времени занимает немного — 15-30 минут в неделю, зато всёгда есть 1-2 человека, хорошо разбирающихся в чужом коде.

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

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