Проект vs Отдел

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

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

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

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

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

    Как раз проект является той движущей силой, которая создает продукт/сервис и приносит прибыль компании. Проект — это конвейер, который использует различные ресурсы для изготовления продукта. Следовательно, распределение полномочий и ответственности должно быть направлено, в первую очередь, на поддержку проекта. Ресурсы должны полностью выделяться на проект, а не распыляться на выполнение задач в отделах. Почему? Вот аргументы.

    Задача проходит через отдел


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

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

    Частичное выделение рабочего ресурса на проект


    Для меня самая нелепая ситуация — выделение ресурса на проект на определенный процент времени. Например, руководителю проекта говорят, что “только 70% ресурса выделяется на ваш проект, а другие 30% идут на другой”. Обосновывая это тем, что “не только у вашего проекта есть задачи”. Такой подход приводит к тому, что вместо одного “недовольного” проекта мы получаем два, так как их задачи влияют на обоюдные сроки.
    Почему мой проект должен зависеть от другого? Что лучше: один проект, сделанный вовремя, или два проекта, сдвинутые по срокам? Если возникает нехватка ресурсов, не нужно пытаться успеть везде, но понемногу. Нужно полностью закрыть потребности одного проекта и искать ресурсы для другого.

    Стоимость передачи информации


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

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

    Попробуйте сами посчитать сколько времени вы тратите на передачу информации.И как будет лучше.

    Увлеченность проектом


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

    Agile


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

    Идеальный проект


    Чтобы получить идеальный проект с максимальной эффективностью и высокой производительностью, нужно создать конвейер на котором задачи беспрепятственно перетекают из “To Do” в “Done”. А для этого проект нужно снабдить всеми необходимыми ресурсами. Традиционный подход передачи задач в отделы мешает созданию конвейера, а, следовательно, эффективности и производительности.

    Идеальный отдел


    У идеального отдела должны быть три главных задачи:
    — нанимать лучших
    — обеспечивать постоянное развитие сотрудников
    — обеспечивать наилучший уровень решения задач на проекте
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 52

      –4
      Торт!
        +6
        Мы постепенно пришли к упразднению отделов, как административных единиц. Сейчас наши отделы заменены на «направления», в которых есть свои лидеры. Эти лидеры отвечают за развитие своих направлений и сотрудников в рамках этих направлений, но ни в коей мере не отвечают за их выделение на проекты.

        За выделение людей на проекты отвечает ресурс-менеджер. У нас этот человек очень сильно приближен к руководителю департамента и понимает (в сложных случаях — согласовывает) приоритеты всего департамента. Именно к ресурс-менеджеру обращаются и продавцы, и РП, и лидеры направлений для получения людей для своих нужд. Это дает существенную гибкость — в частности, часто специалисты не привязаны к направлению — в зависимости от нужд департамента они могут мигрировать между направлениями, получая новые знания.

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

              Это у vatuma возможно аутсосинг, судя по слову «продавцы».
                0
                Я так понимаю, что если есть много проектов и направлений в компании, то хоть часть этой компании направлена на аутсорсинг, т.к. своих проектов такого разнообразия не получится. Разве что если вы не Microsoft, хотя и у них в технологиях присутствует известная однобокость.

                dmitry_ov, поправьте меня, если я ошибаюсь
                  +1
                  Представьте сколько проектов в Яндексе, Рамблере, Mail.ru. Все они продуктовые. И в нашей компании Иннова, которая тоже продуктовая и где я работаю, проектов тоже куча.
                0
                Статья в первую очередь для продуктовых компаниях, которые одновременно делают несколько продуктов. Хотя и для аутсорсинга она тоже подходит. Там тоже есть отделы от куда выделяются ресурсы на проекты.
                0
                Тоже проектная, но, возможно, акценты будут другие. Я не работал в продуктовых компаниях, поэтому могу лишь предположить (поправьте меня, если это не так), что там основной проект — это длительный проект создания и развития продукта, а клиентские проекты — это, если можно так назвать, ответвления, на которые оттягиваются ресурсы из основного проекта. Если это так, то, возможно, миграция специалистов из отдела в отдел не нужна, и управление ресурсами будет строится несколько иначе. Поэтому и орг. модель, возможно, там лучше подойдет не такая, как у нас.
                  0
                  У компаний, делающих продукты для массового потребителя обычно нет проектов кастомизаций и доработок под клиентов (например, игры).

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

                  Я знаю пару компаний среднего масштаба делающих банковский софт, там действительно стоит задача балансирования ресурсов между внедрениями и развитием платформы. Но важно понимать, что баланс между внедрением и платформой — это баланс между тактикой и стратегией, поэтому нельзя сказать, что проект платформы — «основной», а другие второстепенные, т.к. если последних не будет, то завтра будет нечего есть.
                0
                Скажите, а где можно почитать по подробнее про такую организацию компании?
                0
                В компании, в которой я работал последней, отделы существуют. Но, при этом практикуется передача сотрудника отдела в проект на какое-то время. Т.е. руководитель проекта приходит к руководителю отдела и оговаривается не столько решение задач, сколько вопрос выделения ресурса проекту на определенное время. После этого сотрудник отдела становится частью команды проекта.

                Таким образом есть все достоинства как проектного подхода (увлеченность и т.п.), так и наличия отделов (например, создание определенной инфраструктуру для упрощения решения специфических задач отдела).
                  0
                  Вот это самый правильный подход, в принципе о нем я и пытался описать в статье.
                    0
                    Это не раскрывает темы баланса. В какой-то момент человека надо вернуть в отдел (pool), а если потом его надо обратно на проект, а он уже занят где-то еще? А если с момента выделения и возврата человек просто ушел в другую компанию? Опять же непонятно как все это продавать клиенту, можно конечно помесячно, типа 1-й 100%, 2-й — 100%, потом 3-й 50%, 4-й — 0%, а потом 6-й — 100%. Я далек от ресурс менеджмента на уровне выставления счетов, но все же думаю тут не все так однозначно.
                      0
                      Человек всегда остается в отделе, его оттуда никто не забирает :-)
                      Отдел — это как рабочее место, некоторая среда, в которой удобно решать некоторые задачи. Например, в отделе тестирования на компьютерах установлен специфический софт, которые устанавливается и обновляется централизовано.

                      Кроме того, на мой взгляд, не нужно идеализировать методологию. Любая методология красиво выглядит на бумаге. Но работают-то не 30%+70% ресурсов, а живые люди. Любой нормальный профессионал несет ответственность за свою работу и имеет личные обязательства перед коллегами. Соответственно, если в проекте возникает какая-то проблема, то, если она мелкая — вопрос решается в личном порядке, а если это отдельная большая задача — то уже на уровне руководства, если требуется — поднимается выше, чтобы решить уже вопрос приоритета проектов.
                    0
                    «Для меня самая нелепая ситуация — выделение ресурса на проект на определенный процент времени.»
                    А какую альтернативу вы предлагаете?
                      +4
                      «Нужно полностью закрыть потребности одного проекта и искать ресурсы для другого.»
                      Видно, что вы менеджер одного проекта.
                      Представьте, что компания продала 3 проекта 3-м разным клиентам. Во всех 3-х проектах нужна экспертиза по Oracle. Не каждый день по 8 часов, но нужна. В компании один свободный эксперт по Oracle. Что делать? Назначать его на 1 проект, чтобы он 70% времени пинал балду, а на остальные судорожно искать фрилансеров-экспертов?
                        0
                        Как клиент компании, которая распределяет свои усилия на нескольких клиентов — это меня немного раздражает.Как менеджер проекта, понимаю- что это правильно. Но все равно, хочу чтобы мне делали лучше и быстрее-)
                          +4
                          Так что вы предлагаете руководителям ресурсов?

                          Услуги DBA и экспертов конкретным технологиям часто не нужны проекту фулл-тайм.

                          Часто человек сделал один проект, перешёл в другой. И поддержка им старого проекта обойдётся в 10% его времени или 50% времени другого специалиста-новичка. Что делать?
                            0
                            Очень резонные вопросы задаёте, между прочим :) сразу видно, что вы поработали ресурс менеджером.
                              0
                              Взаимодействие с компанией партнером, на ренту специалистов. Скажем так, расширяет общий штат сотрудников и распределяем риски. Согласование усложняется, однако, это окупается снижением издержек.

                                0
                                Извините, я не понял.

                                Проект 1 стартует завтра, требует 0,3 FTE экспертизы Ораклоида.
                                Проект 2 стартует завтра, требует 0,3 FTE экспертизы Ораклоида.
                                Проект 3 стартует завтра, требует 0,3 FTE экспертизы Ораклоида.
                                В компании один ораклоид.

                                Каковы действия его руководителя?
                                0
                                А теперь посчитаем по-другому.

                                Один проект спец закончил бы за 8 часов.

                                Два проекта (одновременно). Думаете за 16? Дудки. Дай бог за 24.

                                Три проекта (тоже одновременно). Вероятнее всего, срок растянется еще в два раза.

                                Ну и что делать?
                                Правильный ответ такой: организовать такую очередь занятости специалистов, чтобы каждый из них в отдельный момент времени занимался только одним делом.
                                Я конечно понимаю, что это идеал, но нужно к нему стремиться.
                                  0
                                  ну нет там работы на 8 часов в день) вы понимаете, что такое администрирование, консультирование и контроль качества?

                                  у аналитика, например, часто бывает так, что пользователь и заказчик прямо сейчас недоступен, предыдущие результаты обработаны, возникает простой. Не всегда есть возможность организовать по принципам Agile/XP всё. Идеальные методики интересны только как шкала для оценки эффективности текущей, причём в контексте данного разговора — только для одного проекта. А компании интересен не успех одного проекта, а общая прибыль.

                                  а про эффективность работы человека без переключения контекста я в курсе, спасибо )
                                  beskov.livejournal.com/69177.html
                                  0
                                  В зависимости от потребности проекта в поддержке, например: если проект требует много внимания и частых вмешательств, то однозначно второго, т.к. его трудозатраты в 50% будут стремиться к уменьшению по мере изучения проекта и при частых вмешательствах в решение проблем довольно быстро сократятся до 10% старожила. В противном случае обратная ситуация, но тут конечно все слишком упрощено, в зависимости от ситуации на ответ могут так же влиять сложность проекта, обучаемость специалиста, степень документированности и т.п.
                                0
                                Сейчас я занимаюсь развитием одного большого продукта, но до этого я работал в Люксофт, где руководил центром разработки и поверьте, там я познал, что такое вести несколько проектов одновременно.
                                По описанной ситуации. Может не получилось этого донести, но вначале статьи я написал, что сотрудник должен выделяться на проект пока у него есть задачи. Очевидно, что если задачи разовые, требующие уникальной экспертизы, то такие люди должны помогать разным проектам.
                                  0
                                  Перекрёстное межпроектное code review, например — не разовая задача.

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

                                  Неужели в Люксе такого не было?
                                    0
                                    В Люксе все зависит от проекта или центра, где-то есть, а где-то нет. Между центрами разработки стоит «стена» и опыт никак не шарится.
                                  0
                                  в таких случаях надо ставить проблему по другому. Не человек выделяется на проект на 30% а проекту требуется определенная работа, в данном случае экспертиза. И это может быть как свой специалист, так и приглашенный или вообще внешняя фирма, которая как-то там распределяет свои ресурсы что бы выполнить задачу.

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

                                  В любом случае для проекта такие задачи — внешние, то есть аутсорс или субподряд, если по-русски. Как с ними работать — отдельная песня :)
                                  +2
                                  “только 70% ресурса выделяется на ваш проект, а другие 30% идут на другой” — это реальность жизни, от этого никуда не убежать. И от поддержки тоже. И от того, что ваших людей отвлекают по прошлым проектам, а вам приходится от этого страдать — но, когда вы побудете по обе стороны баррикад (вторая — когда вам нужно доделать проект, но ресурс, который его делал, уже занят на новом на FTE), будете придумывать каждый день нестандартные решения всем этим ситуациям.

                                  В этом, собственно, и заключается основная роль менеджера, за неё нам и платят чуть больше чем технарям — это ох как непросто, и не существует методик, как 100% эффективно управлять. Как структурно ни реформируй компанию, какие методологии (scrum, agile, deep planning) ни используй — всё равно каждый день нужно думать головой, что и как разрулить.
                                    –1
                                    >не существует методик, как 100% эффективно управлять

                                    Существуют.

                                    Так же, как существуют методики, как правильно писать код.

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

                                    Другое дело, что очень часто люди не способны учиться даже на своем опыте, а не то что по книгам.
                                      0
                                      Расскажите, дайте ссылки.
                                        0
                                        Да вот хотя бы PMBook. Это конечно скучища жуткая, но именно то, о чем я говорю.
                                          0
                                          Глеб, но там же речь про то, как добиться успеха, делая один конкретный проект. А тут тема про то, как быть с интересами вне проекта – когда проектов несколько.

                                          Сослались бы хоть на The Standard for Program Management (http://www.amazon.com/Standard-Program-Management-Project-Institute/dp/1930699549)

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

                                        То, что руководителям приходится разруливать описанные вами ситуации согласен. Но это не значит, что с этим нужно мириться и не искать эффективных решение. А я уверен, что они есть. И согласен, что тут вопрос не в Agile, а в управлении ресурсами.

                                        Как вы думаете, почему разница в производительности в Кремниевой долине и в России в разы (это вам скажет любой человек поработавший там и там)? Одна из причин, это неправильное управление ресурсами, попытка одним человеком заткнуть все дырки.
                                          0
                                          За всю Кремниевую долину говорить не надо)))) Был в Сан-Бруно в командировке и ох как меня там удивило общее распизгильдяйство))
                                        +1
                                        Зацепило одно. Отношение к людям как к ресурсам. Буквально, название их ресурсом.

                                        Я считаю это вредным не просто идеологически (никому не понравится если его называют ресурсом), а терминологически.

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

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

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

                                            Хотя определенно — люди наше все!
                                            +3
                                            Вообще не помешала бы Хабру достойная статья с кейсами про ресурс менеджмент ну и с обоснованием почему так лучше, а не вот так ибо есть случаи, когда с точностью до наоборот.
                                              +1
                                              Не только Хабру, а вообще интернету — мы в своё время с коллегами, когда строили работу в матрице, сильно удивлялись отсутствию готовых материалов на эту тему.
                                              +1
                                              Комментарии в этом топике интереснее статьи.
                                              Было бы любопытно почитать про ресурс менеджмент с реальными примерами.
                                                0
                                                Внесу и свои пять копеек. У нас есть отделы. Большинство отделов постоянно занимаются только одним проектом. Бывает что несколькими, но опять же один отдел, одни люди. Руководителей проектов нет. Есть продукт-менеджеры, которые ставят бизнес-задачи руководителю отдела, а тот уже распределяет ресурсы и ставит технические задачи. Есть долгосрочное планирование, на задачи из этого плана уходит примерно 80% времени. Есть срочные задачи, которые могут решатся с более высоким приоритетом. Вот как-то так. Эта система работает. Не сказать что идеально, но в целом работает. Компания продуктовая.
                                                  +1
                                                  Похоже, что у вас начальник отдела выполняет роль менеджера проекта, поэтому двойственности подчинения у вас нет, а следовательно и описанных проблем.
                                                    +1
                                                    Да, так и есть. Но это создает другую проблему — у руководителя отдела остается меньше времени на архитектурную работу, т.к. много уходит на административную.
                                                      0
                                                      К слову от непосредственно кодинга пришлось вообще отказаться, т.к. от этого больше проблем чем пользы проекту.
                                                        0
                                                        Руководитель проекта, по сути (большого проекта), не должен заниматься кодингом — это требует большой концентрации, программировать эффективно у него всё равно не получится.

                                                        Да и архитектуру он должен обсуждать на самом высоком уровне, ни в коем случае даже не на уровне классов.
                                                          0
                                                          Ну как большого, от 2 до 6 разработчиков одновременно. + тестеры, техпис, аналитик.

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

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

                                                            Или смириться, и жить совсем другой жизнью, в которой мало программирование. И мало интересного, положа руку на сердце.
                                                              0
                                                              На самом деле, делегирование задач — это отдельное искусство.
                                                              Сначала действительно сложно смириться. Но, со временем приходит понимание что без этого нельзя и даже наоборот, как-то легче становится :-) можно фантазировать, придумывать решения и делегировать их, не думая о рутине (делать-то не тебе придется).
                                                              Сам бы может и взялся бы реализовывать… :-)
                                                        0
                                                        Когда мне случилось быть таким начальником, я сначала вытребовал себе заместителя, чтобы он занимался административной работой. Но потом, мне и этого показалось мало, и я стребовал себе начальника, который занимался административным руководством со всех сторон, включая верхнее начальство, а я, по факту, спокойно занимался архитектурными делами и некоторыми вопросами внутреннего управления.

                                                  Only users with full accounts can post comments. Log in, please.