Должен ли руководитель проекта знать систему, которую внедряет?

[komar]

Цитата:

Сообщение от mazzy

в общем, мнения разделились почти поровну.

А твое мнение?

[ТРЕНЕР]

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

И еще. Мне непонятен подход: "необязательно, но желательно". Либо нужно, либо не нужно. Вы, как работодатель, готовы платить за эти доп.знания РП или кого-либо другого? или только за выполнение конкретной работы на конкретно месте ? вот то-то же..

[mazzy]

Цитата:

Сообщение от komar

Цитата:

Сообщение от mazzy

в общем, мнения разделились почти поровну.

А твое мнение?

http://forum.mazzy.ru/index.php?showtopic=...findpost&p=4247

Да, неправильно выразился.
Все ответили, что "да, должен".
Но насколько должен знать? мнения распределились поровну между степенями знания.

Так точнее, вроде.

[ans_imported]

Цитата:

Сообщение от komar

Если РП совсем не знает систему, то как он проверит:
- что работа действительно требует таких временных затрат
- что такая работа действительно может/не может быть выполнена
- что работа действительно выполнена/не выполнена
- что работа не может быть выполнена лучшим образом

Можно, конечно, под каждый пункт держать отдельного человека.  Большой толпа получится, однако.

Доброго времени суток всем!
А теперь вопрос из подтишка

А как клиент (заказчик) при заказе внедрения
у консалтинга определит:
- что работа действительно требует таких временных затрат
- что такая работа действительно может/не может быть выполнена
- что работа действительно выполнена/не выполнена
- что работа не может быть выполнена лучшим образом???

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

Это только вопрос, прошу никого не обижаться ))

[mazzy]

прямой ответ:
что такое обман?
если это несоответветсвие обещанного и сделанного...
то есть клиента не волнуют РЕАЛЬНЫЕ временные затраты.
клиента волнуют обещанное консультантом.

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

так что тут ans ты немножко не о том.

Руководитель проекта сам должен генерить то, что он будет обещать руководителю/владельцу. Но должен ли он при этом знать систему?

Консультант же систему знать ОБЯЗАН по определению

[ans_imported]

Доброго времени суток!

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

Цитата:

то есть клиента не волнуют РЕАЛЬНЫЕ временные затраты.
клиента волнуют обещанное консультантом.

Это кто сказал? Клиент или внедренец?
Клиент просто НЕ МОЖЕТ САМ это проверить.
Если клиент сомневается и готов еще тратить деньги,
он найдет стороннего аудитора проекта для оценки РЕАЛЬНЫХ
временных затрат.

Цитата:

что такое обман?
если это несоответствие обещанного и сделанного...

Немножко отвлечение от темы, но тоже интересно.
Обязательно опишу в своей статье, которую все никак не закончу
Так вот, про несоответствие. Смотря что и как хотели, и что и как обещали.
Если клиент говорит внедренцу - хочу чтобы у меня после внедрения все
было хорошо. Это абсолютно не значит, что в конце отношений не возникнет
слово "обман". Внедренец полностью вылижет систему, даст абсолютно
все необходимые для учета в данном бизнесе инструменты. Научит
персонал и т.д. А тут, как варианты, конкуренты этой фирме на горло
наступят, рынок в данной отрасли обвалится, персонал поувольняется
или в системе работать не захочет.
То есть ПОСЛЕ внедрения, все НЕ ХОРОШО. Однако ПОСЛЕ, не означает
ВСЛЕДСТВИИ.
А вот чтобы такого не было, нужно чтобы клиент сам сначала разобрался
что он хочет, а потом начинал внедрение, а не чтобы ему предлагали на выбор
"вам бы подошло вот это". Это уже тема про управленченский консалтинг
и почему он не развит в России.

Цитата:

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

Тут же возникает вопрос. Значит если клиент и консультант торгуются
на предмет обещаний, а не РЕАЛИЙ (сроков, денег и т.д.) и это
есть правда признаваемая всеми и публично, то почему же
точно так же не могут торговаться Руководитель проекта (РП) и его
подчиненные? Почему тогда большинство на вопрос на этом форуме о том
должен ли РП знать систему отвечают, что так или иначе должен?
Почему бы РП абсолютно не знающему систему не "сторговаться на предмет
обещаний" со своими консультантами? Не потому ли что все отвечающие
здесь ислючительно внедренцы? (ну я собственно тоже).
То есть мы естественно не хотим чтобы нам втирали очки,
но кто же откажется от втирания очков другому, тем более когда светит
выгода? И неважно, внутренний ли это консультант или сторонний консалтинг.

Цитата:

Руководитель проекта сам должен генерить то, что он будет обещать
руководителю/владельцу. Но должен ли он при этом знать систему?

Обещать что? Сроки, затраты по поставленной клиентом задаче?
Или обещать как-раз то, что получится после внедрения, то есть
самостоятельно ставить себе задачу и убеждать клиента, что это для него
будет хорошо?
Стоп, стоп,стоп... Такой подход заранее предполагает, что клиент сам
не знает что хочет получить от внедрения системы.
В противном случае было бы так.
Клиент САМ говорит РП - хочу после внедрения получать такие отчеты (список)
с такой-то информацией (перечень).
Или более радикально - хочу сокращения численности персонала
по обработке данных на Х-человек или увеличения скорости получения отчетности (не раз в квартал, а раз в неделю) и тд. Готов заплатить Y-денег.
То есть реальное задание, а не "хочу как у соседа, чтобы было хорошо".
(хотя в жизни получается как раз что клиент не знает чего хочет).
РП как бизнес-аналитик разруливает у себя в голове (ну и на бумаге)
как это должно быть по бизнес-процессам и документообороту, а ПОТОМ
отдает своему подчиненному по функциональному дизайну. И тот, натягивая
это на функционал системы, говорит что соответствие только на 70%.
После чего РП передает остальные 30% отделу программинга и спрашивает
за сколько они нарисуют эти 30% нехватающего функционала.
Если это не так, то скажите пожалуйста, как тогда происходят тендеры по
выбору ERP? Или в этом случае РП знает функционал сразу всех
возможных ERP систем? (Только не надо говорить про откаты и застолья,
это и так понятно и противно)

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

Цитата:

Консультант же систему знать ОБЯЗАН по определению

Это вопросов не вызывает. Естественно, технолог производства
должен знать технологию

[MegaCrusher_imported]

Давно не был здесь

Цитата:

еще. Мне непонятен подход: "необязательно, но желательно". Либо нужно, либо не нужно. Вы, как работодатель, готовы платить за эти доп.знания РП или кого-либо другого? или только за выполнение конкретной работы на конкретно месте

Хочу ответить. Подход самый простой. Знания системы буду перерастать в качество у РП только в некоторых случаях поэтому и говорю "желательно". ИМХО опять же это я делаю скидку на "Рассейскую" действительность. Рассмотрим случаи :
1) РП - со стороны клиента является человеком оркестром т.е. и жнец и швец и на дуде игрец. Вот в этом случае знания ему нужны в полном объеме, чем больше тем лучше. И никуда от этого не уйти. Случай не такой уж редкий и встречается сплошь и рядом.
2) РП- является внутренним консультантом на проекте со стороны клиента и осуществляет контроль за ходом проекта и за "своими" программерами, админами и прочими сотоварищами. А также за привлеченными консалтерами. Знания нужны, но всегда есть чел который больше знает в своей области. Скажем есть челы по СУБД админ, программер фин. менеджер и т.д.. Знания нужны лишь на уровне продвинутого пользователя, но здесь нужно больше всего знаний и умений по организации и деловому администрированию. Остальные решения РП может легко выработать совместно с привлеченным спецом.
3) РП- явлется директором неважно каким. Главное! директором с реальными полномочиями. Это может быть фин. дир, ИТ директор, ген. дир и т.д. Вот тут уже почти не нужны знания системы на уровне продвинутого пользователя. Нужен уровень обыкновенного пользователя. Если раз за неделю в систему зайдет то это и будет здорово. Тут важно иметь штат спецов то бишь команду со сторону клиента, которая бы рулила всеми вопросами. Директор должен лишь грамотно управлять людьми контролировать и "зажимать" по срокам. Тут уже почти не нужны знания системы. "Почти" это потому что он все равно должен быть потребителем системы а значит минимально знать функционал.
4) РП - является менеджером внедряющим со стороны консалтеров. Ситуация на мой взгляд однозначная пункту 1.

Вот собственно и случаи которые я описал. Возможно, есть и другие ситуации которые я не учел, но мне показалось что это самые расспространеные. Я хотел бы отметить что если описывать РП именно с западного понимания а не с нашего, то как не кажется это человек именно РУКОВОДИТЕЛЬ а не ИСПОЛНИТЕЛЬ. т.е. ему самому не нужно настраивать систему и программить ее и писать описания и т.д. . РП это человек которые координирует, контролирует и направляет действия подчиненных. А знания системы РП если и повышают успешность внедрения (при описанном мной понимании) то отнюдь не в линейном отношении и даже не экспоненциально. Скорее обратно направленая экспонента. Ведь нужно учесть что грамотный РУКОВОДИТЕЛЬ никогда не будет делать все сам, ему необходимо опять же грамотно делигировать полномочия сотрудникам.
Я думаю, что все голосовали по разному именно из-за того, что не было понимания того, что же в сущности представлет собой наш мифический РП. Я думаю что и в голосовании нужно было несколько изменить формулировку. т.е. пояснить что же мы понимаем под РП. А то у нас в стране слово менеджер воспринимается всеми по разному
Вот собственно и все что я хотел сказать.

[mazzy]

точно! поэтому и ответы распределились по группам поровну.
просто каждый отвечал про своего РП...

[Likefire]

Знаете как в армии? В армии всё очень просто: непосредственный начальник должен знать и умёть всё, что умеют и знают его подчинённые в рамках исполняемых обязанностей. Только в этом случае начальник (руководитель) может быть ответственен за постановку и решение задач, при этом только в этом случае, в его руках действительно будут сосредоточены реальные возможности по управлению своей командой для достижения только положительного результата. А не так, как у нас, блин: мой непосредственный начальник абсолютно не представляет ни средств, ни методов, которыми я решаю поставленые задачи (которые сам себе и ставлю), а требует с меня отчётов о проделанной работе (в которых я вешаю откровенную "лапшу", а он её проглатывает с удовольствием).

[mONYA]

Цитата:

Сообщение от Likefire

Знаете как в армии? В армии всё очень просто: непосредственный начальник должен знать и умёть всё, что умеют и знают его подчинённые в рамках исполняемых обязанностей. Только в этом случае начальник (руководитель) может быть ответственен за постановку и решение задач, при этом только в этом случае, в его руках действительно будут сосредоточены реальные возможности по управлению своей командой для достижения только положительного результата. А не так, как у нас, блин: мой непосредственный начальник абсолютно не представляет ни средств, ни методов, которыми я решаю поставленые задачи (которые сам себе и ставлю), а требует с меня отчётов о проделанной работе (в которых я вешаю откровенную "лапшу", а он её проглатывает с удовольствием).

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

[Голова 2уха]

А почему собственно внедряемую систему?
Если например менеджер знает одну систему, а внедряет другую? Например, знает Аксапту и российский учет (бухгалтерский, складской, серый управленческий, не суть), внедряет Навижн или знает Сап внедряет Оракл. так что мой ответ - должен ли менеджер знать внедряемую систему - нет, должен ли он вообще что-то знать - наверное должен, но что именно - зависит от того, какие задачи перед ним ставятся. Может быть и чисто административный менеджер проекта, и менеджер-архитектор, знающий систему.
хотя с трудом могу представить, зачем нужен чисто административный менеджер-управленец в команде из 3 человек, например.

[mazzy]

Цитата:

Сообщение от Голова 2уха

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

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

[Тимур_imported]

Цитата:

Сообщение от Голова 2уха

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

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



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

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

[Голова 2уха]

Цитата:

Сообщение от Тимур

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

--------
Хм. По собственному опыту скажу: должен знать, именно ту систему, которую внедряет.
Иначе могут быть неожиданности. Как приятные ("А наша система решает задачу стандартным функционалом"), так и неприятные ("к сожалению, в этой транзакции могут работать одновременно не более одного пользователя").

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


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

[komar]

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

[komar]

Цитата:

Сообщение от Голова 2уха

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

Он ее может зверски перепрограммировать, не зная стандартного функционала. Или несколько затянет срок внедрения, изучая систему. Конечно, внедрят. Вопрос, когда и в каком виде.

[Голова 2уха]

Цитата:

Сообщение от komar

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

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

[Тимур_imported]

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

[Тимур_imported]

Цитата:

Сообщение от komar

Цитата:

Сообщение от Голова 2уха

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

Он ее может зверски перепрограммировать, не зная стандартного функционала. Или несколько затянет срок внедрения, изучая систему. Конечно, внедрят. Вопрос, когда и в каком виде.

Согласен.
На своем опыте прочуствовал.

[spaiks]

Цитата:

Сообщение от Тимур

Согласен.
На своем опыте прочуствовал.

Vot interesno, a eto u vseh po nachalu tak poluchaetsa? V smisle, zverskoje peredelovanije, kotoroe privodit v nekuda ...
Dva krainih mnenija, po-moemu:
1) akademicheskij = Proj Man'u po barabanu, kakoj sferi proekt, nuzhno toljko manipulirovatj treugoljnikom vremja-resursi-kachestvo;
2) uzko-profesionaljnij = postroitj ofigennij dom moget toljko tot, kto prohodit vse inkarnacii ot "podi tuda, prinisi eto - poshol ti <censored>" do arhitektora.
Pravda, IMHO, po seredine, i vsegda drugaja