Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Торт!
Мы постепенно пришли к упразднению отделов, как административных единиц. Сейчас наши отделы заменены на «направления», в которых есть свои лидеры. Эти лидеры отвечают за развитие своих направлений и сотрудников в рамках этих направлений, но ни в коей мере не отвечают за их выделение на проекты.
За выделение людей на проекты отвечает ресурс-менеджер. У нас этот человек очень сильно приближен к руководителю департамента и понимает (в сложных случаях — согласовывает) приоритеты всего департамента. Именно к ресурс-менеджеру обращаются и продавцы, и РП, и лидеры направлений для получения людей для своих нужд. Это дает существенную гибкость — в частности, часто специалисты не привязаны к направлению — в зависимости от нужд департамента они могут мигрировать между направлениями, получая новые знания.
Но у нас основная деятельность — проектная. В чисто софтверных компаниях, создающих свой продукт, я думаю, более эффективной может быть другая модель.
За выделение людей на проекты отвечает ресурс-менеджер. У нас этот человек очень сильно приближен к руководителю департамента и понимает (в сложных случаях — согласовывает) приоритеты всего департамента. Именно к ресурс-менеджеру обращаются и продавцы, и РП, и лидеры направлений для получения людей для своих нужд. Это дает существенную гибкость — в частности, часто специалисты не привязаны к направлению — в зависимости от нужд департамента они могут мигрировать между направлениями, получая новые знания.
Но у нас основная деятельность — проектная. В чисто софтверных компаниях, создающих свой продукт, я думаю, более эффективной может быть другая модель.
А какая деятельность по-вашему в продуктовых компаниях, если не проектная?
Там совсем другая специфика, статья же про аутсорсинг.
Посмотрите профиль топикстартера и найдите в статье хоть один намёк на аусторсинг.
Это у vatuma возможно аутсосинг, судя по слову «продавцы».
Это у vatuma возможно аутсосинг, судя по слову «продавцы».
Я так понимаю, что если есть много проектов и направлений в компании, то хоть часть этой компании направлена на аутсорсинг, т.к. своих проектов такого разнообразия не получится. Разве что если вы не Microsoft, хотя и у них в технологиях присутствует известная однобокость.
dmitry_ov, поправьте меня, если я ошибаюсь
dmitry_ov, поправьте меня, если я ошибаюсь
Статья в первую очередь для продуктовых компаниях, которые одновременно делают несколько продуктов. Хотя и для аутсорсинга она тоже подходит. Там тоже есть отделы от куда выделяются ресурсы на проекты.
Тоже проектная, но, возможно, акценты будут другие. Я не работал в продуктовых компаниях, поэтому могу лишь предположить (поправьте меня, если это не так), что там основной проект — это длительный проект создания и развития продукта, а клиентские проекты — это, если можно так назвать, ответвления, на которые оттягиваются ресурсы из основного проекта. Если это так, то, возможно, миграция специалистов из отдела в отдел не нужна, и управление ресурсами будет строится несколько иначе. Поэтому и орг. модель, возможно, там лучше подойдет не такая, как у нас.
У компаний, делающих продукты для массового потребителя обычно нет проектов кастомизаций и доработок под клиентов (например, игры).
У больших компаний, создающих корпоративный продукт, работа по кастомизации и доработкам обычно ложится на компании-партнёры, например, модель 1С.
Я знаю пару компаний среднего масштаба делающих банковский софт, там действительно стоит задача балансирования ресурсов между внедрениями и развитием платформы. Но важно понимать, что баланс между внедрением и платформой — это баланс между тактикой и стратегией, поэтому нельзя сказать, что проект платформы — «основной», а другие второстепенные, т.к. если последних не будет, то завтра будет нечего есть.
У больших компаний, создающих корпоративный продукт, работа по кастомизации и доработкам обычно ложится на компании-партнёры, например, модель 1С.
Я знаю пару компаний среднего масштаба делающих банковский софт, там действительно стоит задача балансирования ресурсов между внедрениями и развитием платформы. Но важно понимать, что баланс между внедрением и платформой — это баланс между тактикой и стратегией, поэтому нельзя сказать, что проект платформы — «основной», а другие второстепенные, т.к. если последних не будет, то завтра будет нечего есть.
Скажите, а где можно почитать по подробнее про такую организацию компании?
В компании, в которой я работал последней, отделы существуют. Но, при этом практикуется передача сотрудника отдела в проект на какое-то время. Т.е. руководитель проекта приходит к руководителю отдела и оговаривается не столько решение задач, сколько вопрос выделения ресурса проекту на определенное время. После этого сотрудник отдела становится частью команды проекта.
Таким образом есть все достоинства как проектного подхода (увлеченность и т.п.), так и наличия отделов (например, создание определенной инфраструктуру для упрощения решения специфических задач отдела).
Таким образом есть все достоинства как проектного подхода (увлеченность и т.п.), так и наличия отделов (например, создание определенной инфраструктуру для упрощения решения специфических задач отдела).
Вот это самый правильный подход, в принципе о нем я и пытался описать в статье.
Это не раскрывает темы баланса. В какой-то момент человека надо вернуть в отдел (pool), а если потом его надо обратно на проект, а он уже занят где-то еще? А если с момента выделения и возврата человек просто ушел в другую компанию? Опять же непонятно как все это продавать клиенту, можно конечно помесячно, типа 1-й 100%, 2-й — 100%, потом 3-й 50%, 4-й — 0%, а потом 6-й — 100%. Я далек от ресурс менеджмента на уровне выставления счетов, но все же думаю тут не все так однозначно.
Человек всегда остается в отделе, его оттуда никто не забирает :-)
Отдел — это как рабочее место, некоторая среда, в которой удобно решать некоторые задачи. Например, в отделе тестирования на компьютерах установлен специфический софт, которые устанавливается и обновляется централизовано.
Кроме того, на мой взгляд, не нужно идеализировать методологию. Любая методология красиво выглядит на бумаге. Но работают-то не 30%+70% ресурсов, а живые люди. Любой нормальный профессионал несет ответственность за свою работу и имеет личные обязательства перед коллегами. Соответственно, если в проекте возникает какая-то проблема, то, если она мелкая — вопрос решается в личном порядке, а если это отдельная большая задача — то уже на уровне руководства, если требуется — поднимается выше, чтобы решить уже вопрос приоритета проектов.
Отдел — это как рабочее место, некоторая среда, в которой удобно решать некоторые задачи. Например, в отделе тестирования на компьютерах установлен специфический софт, которые устанавливается и обновляется централизовано.
Кроме того, на мой взгляд, не нужно идеализировать методологию. Любая методология красиво выглядит на бумаге. Но работают-то не 30%+70% ресурсов, а живые люди. Любой нормальный профессионал несет ответственность за свою работу и имеет личные обязательства перед коллегами. Соответственно, если в проекте возникает какая-то проблема, то, если она мелкая — вопрос решается в личном порядке, а если это отдельная большая задача — то уже на уровне руководства, если требуется — поднимается выше, чтобы решить уже вопрос приоритета проектов.
«Для меня самая нелепая ситуация — выделение ресурса на проект на определенный процент времени.»
А какую альтернативу вы предлагаете?
А какую альтернативу вы предлагаете?
«Нужно полностью закрыть потребности одного проекта и искать ресурсы для другого.»
Видно, что вы менеджер одного проекта.
Представьте, что компания продала 3 проекта 3-м разным клиентам. Во всех 3-х проектах нужна экспертиза по Oracle. Не каждый день по 8 часов, но нужна. В компании один свободный эксперт по Oracle. Что делать? Назначать его на 1 проект, чтобы он 70% времени пинал балду, а на остальные судорожно искать фрилансеров-экспертов?
Видно, что вы менеджер одного проекта.
Представьте, что компания продала 3 проекта 3-м разным клиентам. Во всех 3-х проектах нужна экспертиза по Oracle. Не каждый день по 8 часов, но нужна. В компании один свободный эксперт по Oracle. Что делать? Назначать его на 1 проект, чтобы он 70% времени пинал балду, а на остальные судорожно искать фрилансеров-экспертов?
Как клиент компании, которая распределяет свои усилия на нескольких клиентов — это меня немного раздражает.Как менеджер проекта, понимаю- что это правильно. Но все равно, хочу чтобы мне делали лучше и быстрее-)
Так что вы предлагаете руководителям ресурсов?
Услуги DBA и экспертов конкретным технологиям часто не нужны проекту фулл-тайм.
Часто человек сделал один проект, перешёл в другой. И поддержка им старого проекта обойдётся в 10% его времени или 50% времени другого специалиста-новичка. Что делать?
Услуги DBA и экспертов конкретным технологиям часто не нужны проекту фулл-тайм.
Часто человек сделал один проект, перешёл в другой. И поддержка им старого проекта обойдётся в 10% его времени или 50% времени другого специалиста-новичка. Что делать?
Очень резонные вопросы задаёте, между прочим :) сразу видно, что вы поработали ресурс менеджером.
Взаимодействие с компанией партнером, на ренту специалистов. Скажем так, расширяет общий штат сотрудников и распределяем риски. Согласование усложняется, однако, это окупается снижением издержек.
А теперь посчитаем по-другому.
Один проект спец закончил бы за 8 часов.
Два проекта (одновременно). Думаете за 16? Дудки. Дай бог за 24.
Три проекта (тоже одновременно). Вероятнее всего, срок растянется еще в два раза.
Ну и что делать?
Правильный ответ такой: организовать такую очередь занятости специалистов, чтобы каждый из них в отдельный момент времени занимался только одним делом.
Я конечно понимаю, что это идеал, но нужно к нему стремиться.
Один проект спец закончил бы за 8 часов.
Два проекта (одновременно). Думаете за 16? Дудки. Дай бог за 24.
Три проекта (тоже одновременно). Вероятнее всего, срок растянется еще в два раза.
Ну и что делать?
Правильный ответ такой: организовать такую очередь занятости специалистов, чтобы каждый из них в отдельный момент времени занимался только одним делом.
Я конечно понимаю, что это идеал, но нужно к нему стремиться.
ну нет там работы на 8 часов в день) вы понимаете, что такое администрирование, консультирование и контроль качества?
у аналитика, например, часто бывает так, что пользователь и заказчик прямо сейчас недоступен, предыдущие результаты обработаны, возникает простой. Не всегда есть возможность организовать по принципам Agile/XP всё. Идеальные методики интересны только как шкала для оценки эффективности текущей, причём в контексте данного разговора — только для одного проекта. А компании интересен не успех одного проекта, а общая прибыль.
а про эффективность работы человека без переключения контекста я в курсе, спасибо )
beskov.livejournal.com/69177.html
у аналитика, например, часто бывает так, что пользователь и заказчик прямо сейчас недоступен, предыдущие результаты обработаны, возникает простой. Не всегда есть возможность организовать по принципам Agile/XP всё. Идеальные методики интересны только как шкала для оценки эффективности текущей, причём в контексте данного разговора — только для одного проекта. А компании интересен не успех одного проекта, а общая прибыль.
а про эффективность работы человека без переключения контекста я в курсе, спасибо )
beskov.livejournal.com/69177.html
В зависимости от потребности проекта в поддержке, например: если проект требует много внимания и частых вмешательств, то однозначно второго, т.к. его трудозатраты в 50% будут стремиться к уменьшению по мере изучения проекта и при частых вмешательствах в решение проблем довольно быстро сократятся до 10% старожила. В противном случае обратная ситуация, но тут конечно все слишком упрощено, в зависимости от ситуации на ответ могут так же влиять сложность проекта, обучаемость специалиста, степень документированности и т.п.
Сейчас я занимаюсь развитием одного большого продукта, но до этого я работал в Люксофт, где руководил центром разработки и поверьте, там я познал, что такое вести несколько проектов одновременно.
По описанной ситуации. Может не получилось этого донести, но вначале статьи я написал, что сотрудник должен выделяться на проект пока у него есть задачи. Очевидно, что если задачи разовые, требующие уникальной экспертизы, то такие люди должны помогать разным проектам.
По описанной ситуации. Может не получилось этого донести, но вначале статьи я написал, что сотрудник должен выделяться на проект пока у него есть задачи. Очевидно, что если задачи разовые, требующие уникальной экспертизы, то такие люди должны помогать разным проектам.
в таких случаях надо ставить проблему по другому. Не человек выделяется на проект на 30% а проекту требуется определенная работа, в данном случае экспертиза. И это может быть как свой специалист, так и приглашенный или вообще внешняя фирма, которая как-то там распределяет свои ресурсы что бы выполнить задачу.
Для своего специалиста в этом случае нужно просто ставить задачи в очередь. И как их планировать — надо решать вместе со специалистом — то как он видит свой time management. Некоторые умеют решать эффективно задачи параллельно, выполняя этапы и переключаясь между ними, некоторые так не умеют и должны полностью погрузиться в задачу пока не выполнят.
В любом случае для проекта такие задачи — внешние, то есть аутсорс или субподряд, если по-русски. Как с ними работать — отдельная песня :)
Для своего специалиста в этом случае нужно просто ставить задачи в очередь. И как их планировать — надо решать вместе со специалистом — то как он видит свой time management. Некоторые умеют решать эффективно задачи параллельно, выполняя этапы и переключаясь между ними, некоторые так не умеют и должны полностью погрузиться в задачу пока не выполнят.
В любом случае для проекта такие задачи — внешние, то есть аутсорс или субподряд, если по-русски. Как с ними работать — отдельная песня :)
“только 70% ресурса выделяется на ваш проект, а другие 30% идут на другой” — это реальность жизни, от этого никуда не убежать. И от поддержки тоже. И от того, что ваших людей отвлекают по прошлым проектам, а вам приходится от этого страдать — но, когда вы побудете по обе стороны баррикад (вторая — когда вам нужно доделать проект, но ресурс, который его делал, уже занят на новом на FTE), будете придумывать каждый день нестандартные решения всем этим ситуациям.
В этом, собственно, и заключается основная роль менеджера, за неё нам и платят чуть больше чем технарям — это ох как непросто, и не существует методик, как 100% эффективно управлять. Как структурно ни реформируй компанию, какие методологии (scrum, agile, deep planning) ни используй — всё равно каждый день нужно думать головой, что и как разрулить.
В этом, собственно, и заключается основная роль менеджера, за неё нам и платят чуть больше чем технарям — это ох как непросто, и не существует методик, как 100% эффективно управлять. Как структурно ни реформируй компанию, какие методологии (scrum, agile, deep planning) ни используй — всё равно каждый день нужно думать головой, что и как разрулить.
>не существует методик, как 100% эффективно управлять
Существуют.
Так же, как существуют методики, как правильно писать код.
Разумеется, без приложения мозга ни в том ни в другом процессе ничего не выйдет.
Другое дело, что очень часто люди не способны учиться даже на своем опыте, а не то что по книгам.
Существуют.
Так же, как существуют методики, как правильно писать код.
Разумеется, без приложения мозга ни в том ни в другом процессе ничего не выйдет.
Другое дело, что очень часто люди не способны учиться даже на своем опыте, а не то что по книгам.
Расскажите, дайте ссылки.
Да вот хотя бы PMBook. Это конечно скучища жуткая, но именно то, о чем я говорю.
Глеб, но там же речь про то, как добиться успеха, делая один конкретный проект. А тут тема про то, как быть с интересами вне проекта – когда проектов несколько.
Сослались бы хоть на The Standard for Program Management (http://www.amazon.com/Standard-Program-Management-Project-Institute/dp/1930699549)
Не говоря уж о том, что PMBoK – это не PMBook.
Сослались бы хоть на The Standard for Program Management (http://www.amazon.com/Standard-Program-Management-Project-Institute/dp/1930699549)
Не говоря уж о том, что PMBoK – это не PMBook.
К сожалению, нет таких методик когда много конкурирующих проектов. Вы пока просто не сталкивались с определённым множеством ситуаций.
Как раз мой опыт позволил мне побывать по обе стороны баррикад. Несколько лет я руководил отделом разработки, а последние годы занимаюсь развитием продукта. И как раз зная и понимая нужды обеих сторон, пытаюсь найти решение.
То, что руководителям приходится разруливать описанные вами ситуации согласен. Но это не значит, что с этим нужно мириться и не искать эффективных решение. А я уверен, что они есть. И согласен, что тут вопрос не в Agile, а в управлении ресурсами.
Как вы думаете, почему разница в производительности в Кремниевой долине и в России в разы (это вам скажет любой человек поработавший там и там)? Одна из причин, это неправильное управление ресурсами, попытка одним человеком заткнуть все дырки.
То, что руководителям приходится разруливать описанные вами ситуации согласен. Но это не значит, что с этим нужно мириться и не искать эффективных решение. А я уверен, что они есть. И согласен, что тут вопрос не в Agile, а в управлении ресурсами.
Как вы думаете, почему разница в производительности в Кремниевой долине и в России в разы (это вам скажет любой человек поработавший там и там)? Одна из причин, это неправильное управление ресурсами, попытка одним человеком заткнуть все дырки.
Зацепило одно. Отношение к людям как к ресурсам. Буквально, название их ресурсом.
Я считаю это вредным не просто идеологически (никому не понравится если его называют ресурсом), а терминологически.
Ресурс — это до-информационный термин. К классическим ресурсам очень ограничено применимы негативные эффекты масштабирования. Поставишь 100 станков — выполнишь работу в 100 раз быстрее чем один станок.
Надо ли говорить, что с любыми разработчиками это вообще не так.
Поэтому рассматривать людей как ресурс неправильно. Это такой квази-ресурс, который бухгалтера считают по старинке, тем не менее ведет он себя совсем по-другому. Соответственно и привычные проектные подходы, в т.ч. классическое выделение ресурсов, загрузка расписанная по процентам — в основном не имеющий отношения к жизни тупняк.
Я считаю это вредным не просто идеологически (никому не понравится если его называют ресурсом), а терминологически.
Ресурс — это до-информационный термин. К классическим ресурсам очень ограничено применимы негативные эффекты масштабирования. Поставишь 100 станков — выполнишь работу в 100 раз быстрее чем один станок.
Надо ли говорить, что с любыми разработчиками это вообще не так.
Поэтому рассматривать людей как ресурс неправильно. Это такой квази-ресурс, который бухгалтера считают по старинке, тем не менее ведет он себя совсем по-другому. Соответственно и привычные проектные подходы, в т.ч. классическое выделение ресурсов, загрузка расписанная по процентам — в основном не имеющий отношения к жизни тупняк.
Поэтому ресурсом нужно называть то, чем действительно управляет ресурсный менеджер — а именно, человековременем определённой квалификации.
Когда в департаменте работают сотни людей, статистический подход вполне работает.
Когда в департаменте работают сотни людей, статистический подход вполне работает.
Кстати, мне тоже не нравится это слово. Пытался подобрать разные слова: люди, сотрудники, участники, члены команды. И общего слова для все ситуаций не нашел.
Хотя определенно — люди наше все!
Хотя определенно — люди наше все!
Вообще не помешала бы Хабру достойная статья с кейсами про ресурс менеджмент ну и с обоснованием почему так лучше, а не вот так ибо есть случаи, когда с точностью до наоборот.
Комментарии в этом топике интереснее статьи.
Было бы любопытно почитать про ресурс менеджмент с реальными примерами.
Было бы любопытно почитать про ресурс менеджмент с реальными примерами.
Внесу и свои пять копеек. У нас есть отделы. Большинство отделов постоянно занимаются только одним проектом. Бывает что несколькими, но опять же один отдел, одни люди. Руководителей проектов нет. Есть продукт-менеджеры, которые ставят бизнес-задачи руководителю отдела, а тот уже распределяет ресурсы и ставит технические задачи. Есть долгосрочное планирование, на задачи из этого плана уходит примерно 80% времени. Есть срочные задачи, которые могут решатся с более высоким приоритетом. Вот как-то так. Эта система работает. Не сказать что идеально, но в целом работает. Компания продуктовая.
Похоже, что у вас начальник отдела выполняет роль менеджера проекта, поэтому двойственности подчинения у вас нет, а следовательно и описанных проблем.
Да, так и есть. Но это создает другую проблему — у руководителя отдела остается меньше времени на архитектурную работу, т.к. много уходит на административную.
К слову от непосредственно кодинга пришлось вообще отказаться, т.к. от этого больше проблем чем пользы проекту.
Руководитель проекта, по сути (большого проекта), не должен заниматься кодингом — это требует большой концентрации, программировать эффективно у него всё равно не получится.
Да и архитектуру он должен обсуждать на самом высоком уровне, ни в коем случае даже не на уровне классов.
Да и архитектуру он должен обсуждать на самом высоком уровне, ни в коем случае даже не на уровне классов.
Ну как большого, от 2 до 6 разработчиков одновременно. + тестеры, техпис, аналитик.
Тут две проблемы вытекает: во первых руководитель, как самый опытный разраб, хватает по привычке самый сложные задачи, делает их. Потом оказывается что в этом коде мало кто понимает кроме него из-за сложности и объемности самой задачи. А во-вторых не всегда удается доделать задачи до конца, т.к. сваливается куча непрограммерской работы, и эти задачи подвисают.
Тут две проблемы вытекает: во первых руководитель, как самый опытный разраб, хватает по привычке самый сложные задачи, делает их. Потом оказывается что в этом коде мало кто понимает кроме него из-за сложности и объемности самой задачи. А во-вторых не всегда удается доделать задачи до конца, т.к. сваливается куча непрограммерской работы, и эти задачи подвисают.
от это точно, по себе знаю — очень сложно смириться с тем, что интересные и сложные задачи приходится делегировать, а не делать самому.
Тут надо или не двигаться в ПМ-ы, если ты не готов уменьшить свою долю в программировании до 1-5%, и идти в тимлиды, где ты и будешь делать самые сложные задачи и контролировать братьев наших меньших.
Или смириться, и жить совсем другой жизнью, в которой мало программирование. И мало интересного, положа руку на сердце.
Тут надо или не двигаться в ПМ-ы, если ты не готов уменьшить свою долю в программировании до 1-5%, и идти в тимлиды, где ты и будешь делать самые сложные задачи и контролировать братьев наших меньших.
Или смириться, и жить совсем другой жизнью, в которой мало программирование. И мало интересного, положа руку на сердце.
На самом деле, делегирование задач — это отдельное искусство.
Сначала действительно сложно смириться. Но, со временем приходит понимание что без этого нельзя и даже наоборот, как-то легче становится :-) можно фантазировать, придумывать решения и делегировать их, не думая о рутине (делать-то не тебе придется).
Сам бы может и взялся бы реализовывать… :-)
Сначала действительно сложно смириться. Но, со временем приходит понимание что без этого нельзя и даже наоборот, как-то легче становится :-) можно фантазировать, придумывать решения и делегировать их, не думая о рутине (делать-то не тебе придется).
Сам бы может и взялся бы реализовывать… :-)
Когда мне случилось быть таким начальником, я сначала вытребовал себе заместителя, чтобы он занимался административной работой. Но потом, мне и этого показалось мало, и я стребовал себе начальника, который занимался административным руководством со всех сторон, включая верхнее начальство, а я, по факту, спокойно занимался архитектурными делами и некоторыми вопросами внутреннего управления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проект vs Отдел