Привет ! Monday, October 2, 2006, 2:01:27 PM, you wrote: vsun> Во скольки проектах одновременно может быть задействован человек так, vsun> чтобы его психика не начинала сбоить ? Т.е. та точка, после которой vsun> переключения контекста становятся невыносимыми для психики и включается vsun> природная защитная реакция под названием ЛЕНЬ. Все очень просто :) человек одновременно не может держать во внимании более 7(9) вещей. Вот тебе и ответ :) только вот "проектов" по-моему должно быть максимум 1-2, причем похожих - иначе не то что "точка" а прямая линия будет на кардиограмме... -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Привет, Несколько комментариев (прошу рассматривать как личные а не как консалтинг, никому ничего не навязываю) Во первых для организации нормальной работы следует отталкиваться от того, что человек одновременно может делать качественно только одну задачу. Правда следует избегать распространенной ошибки, когда челеовек тупо ждет результатов выполнения какого то длинного скрипта и включает это время в рабочее :), за это время компания уже заплатила купив(или разработав) соответствующую вычислительную систему и ПО. Далее смотря что называть проектами, если речь идет о support activities(однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:) Второй вариант когда запрос нестандартный. В этом случае лучше всего предоставить исполнителю проанализировать вопрос и предоставить estimate того за сколько будет сделана данная работа. Если при этом возникнет желание сократить время выполнения то просто сказать "сделай в два раза быстрее" желаемого результата не принесет. Прийдется уточнить что собственно входит в проект. Если повезет, то возможно получится найти неоптимально выбранные пути решения, хотя скорее всего прийдется либо отказаться от части функциональности, либо добавлять ресурсы на проект, если он допускает распараллеливание. Я не рассматриваю вариант когда персонал действительно ленивый и от него лучше избавиться. Хотя для обнаружения этой проблемы периодически должны проводиться performance review. Не забывать также, что любое завершенное нестадартное действие должно быть задокументировано и соответственно перейти в разряд стадартных для компании. Особенно на это криво смотрят так называемые "гуру" и как правило всячески сопротивляются документированию своих знаний :), но IT manager который хочет построить эффективную систему обречен либо начать(продолжать) накапливать формализованные знания, либо в результате получать прямую линию кардиограммы своей или подчиненных :) А вообще если есть тяга к конкретным цифрам в американском стиле советую посмотреть материалы по курсу подготовки Project Management Professional, там эти вопросы рассматриваются очень неплохо. Sincerely, Sergei Podnos, CIO Validio Ukraine Tel: +38 057 7667667 x314 E-mail: Podnos@validio.com.ua ICQ: 18631030 Skype: podnos -----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of vladimir.sharun@ukr.net Sent: Monday, October 02, 2006 2:01 PM To: uanog@uanog.kiev.ua Subject: [uanog] Есть ли спецы по проектному менеджменту ? Во скольки проектах одновременно может быть задействован человек так, чтобы его психика не начинала сбоить ? Т.е. та точка, после которой переключения контекста становятся невыносимыми для психики и включается природная защитная реакция под названием ЛЕНЬ. Т.е. то, за что обычно любят выгонять сисадминов. Я подозреваю что есть какая-то формула, которая позволяет учитывать это дело. К тому же вычисляемая и через тесты в т.ч. Желательна ссылка на чьи-то работы в этом направлении либо на компанию (людей), которые готовы предоставить консалтинг в этом направлении. -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

PM book. Только все это есть теория, которую нужно приводить к своей практике. Не знаю как насчет человека участвуюшего в разных проектах, но менеджер может одновременно управлять от 5 до 12 подчиненными. Это один из канонов процессного менеджмента. Ну и насчет организации helpdesk: это не проектный менеджмент нужно смотреть, а в ITIL. On 10/2/06, vladimir.sharun@ukr.net wrote:

Sergei Podnos wrote: SP> Привет,

SP> Несколько комментариев (прошу рассматривать как личные а не как консалтинг, никому ничего не навязываю)

SP> Во первых для организации нормальной работы следует отталкиваться от того, что человек одновременно может делать качественно только одну задачу. Правда следует избегать распространенной ошибки, когда челеовек тупо ждет результатов выполнения какого то длинного скрипта и включает это время в рабочее :), за это время компания уже заплатила купив(или разработав) соответствующую вычислительную систему и ПО. SP> SP> Далее смотря что называть проектами, если речь идет о support activities(однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:)

SP> Второй вариант когда запрос нестандартный. В этом случае лучше всего предоставить исполнителю проанализировать вопрос и предоставить estimate того за сколько будет сделана данная работа. Если при этом возникнет желание сократить время выполнения то просто сказать "сделай в два раза быстрее" желаемого результата не принесет. Прийдется уточнить что собственно входит в проект. Если повезет, то возможно получится найти неоптимально выбранные пути решения, хотя скорее всего прийдется либо отказаться от части функциональности, либо добавлять ресурсы на проект, если он допускает распараллеливание. Я не рассматриваю вариант когда персонал действительно ленивый и от него лучше избавиться. Хотя для обнаружения этой проблемы периодически должны проводиться performance review.

SP> Не забывать также, что любое завершенное нестадартное действие должно быть задокументировано и соответственно перейти в разряд стадартных для компании. SP> Особенно на это криво смотрят так называемые "гуру" и как правило всячески сопротивляются документированию своих знаний :), но IT manager который хочет построить эффективную систему обречен либо начать(продолжать) накапливать формализованные знания, либо в результате получать прямую линию кардиограммы своей или подчиненных :)

SP> А вообще если есть тяга к конкретным цифрам в американском стиле советую посмотреть материалы по курсу подготовки Project Management Professional, там эти вопросы рассматриваются очень неплохо.

А де их посмотреть ?

То, что надо накапливать базу знаний - это понятно.

-- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Mon, Oct 02, 2006 at 02:40:18PM +0300, Sergei Podnos wrote:

Привет,

Несколько комментариев (прошу рассматривать как личные а не как консалтинг, никому ничего не навязываю)

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

Далее смотря что называть проектами, если речь идет о support activities (однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:)

Ну так вот, собственно и вопрос - а можно ли считать саппорт voip, саппорт eompls и саппорт unix-hosting'а "достаточно однотипными" задачами для того, чтобы саппортер между ними эффективно переключался ? Или эти три задачи стоит разделить на три саппорт-группы ? Или просто не бить саппортера ногами в случае неэффективного переключения между задачами и быть готовым к тому, что если его еще заставят поддерживать rfc2547-bis vpn'ы на juniper'ах и java-based crm - у него возникнет желание сначала повеситься а потом уволиться ? :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

02.10.06, Pavel Narozhnyy написал(а):

В ITIL есть отдельный том по организации helpdesk. Думаю, это Ваш случай. Рекомендую ознакомиться.

У кого есть в досягаемости? Я бы с радостью ознакомился ;) даже без перевода на туземный язык, который обещали-обещали, и тишина ;) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

vladimir.sharun@ukr.net пишет:

PN> Не знаю как насчет человека участвуюшего в разных проектах, но менеджер PN> может одновременно управлять от 5 до 12 подчиненными. Это один из канонов PN> процессного менеджмента.

Вообще-то один человек может эффективно управлять группой до 10 человек, а номинал до 5. Так говорится в теории организации. Книжка лежит дома, но этот момент читался особенно серьёзно.

Это называется норма управляемости. Помню только, что она всегда выше на нижних уровнях управления, поэтому (делаю предположение) в общем случае "канонического" числа подчиненных быть не может. Есть рекомендации по количеству подчиненных для конкретных должностей/позиций - с этим бесспорно соглашусь :) -- Andriy Berestovskyy http://www.chereda.net/ =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Alexandre Snarskii wrote:

...

Далее смотря что называть проектами, если речь идет о support activities (однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:)

AS> Ну так вот, собственно и вопрос - а можно ли считать саппорт voip, AS> саппорт eompls и саппорт unix-hosting'а "достаточно однотипными" AS> задачами для того, чтобы саппортер между ними эффективно переключался ? AS> Или эти три задачи стоит разделить на три саппорт-группы ? Ну хоть кто-то меня понял в вопросе ;-) AS> Или просто не бить саппортера ногами в случае неэффективного переключения AS> между задачами и быть готовым к тому, что если его еще заставят поддерживать AS> rfc2547-bis vpn'ы на juniper'ах и java-based crm - у него возникнет AS> желание сначала повеситься а потом уволиться ? :) Вопрос в том, насколько реально описать возможные проблемы и составить по ним процедуры. Как только реально, тут же меняется много чего. Всё упирается в базу знаний и процедуры. Пока их нет, надо чтоб человек разбирался везде и во всём. -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Valentin Nechayev wrote:

...

Вообще-то один человек может эффективно управлять группой до 10 человек, а номинал до 5. Так говорится в теории организации. Книжка лежит дома, но этот момент читался особенно серьёзно.

VN> То есть старшина армейского отделения им управляет уже сверх номинала? ;)) http://ru.wikipedia.org/wiki/Старшина Отделение -> сержанты, взвод -> лейтенант, рота -> кап/майор. Так вроде ? -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Привет ! Monday, October 2, 2006, 6:22:28 PM, you wrote:

...

Отделение -> сержанты, взвод -> лейтенант, рота -> кап/майор. Так вроде ?

VN> А по сути? Ниже командира отделения - никого уже нет. Значит, старшина VN> (сержант) уже на пределе возможности справиться? все как раз логично - капитан не моет зад :) рядовым - он моет ротному и трем взводным :) ... так что по нисходящей - по иерархии :) -- Best regards, Alexander V Soroka http://www.unet.net.ua AS106-RIPE http://www.spacegate.kiev.ua mailto:alex@euro.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Mon, Oct 02, 2006 at 16:16 +0400, Alexandre Snarskii wrote:

...

Несколько комментариев (прошу рассматривать как личные а не как консалтинг, никому ничего не навязываю)

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

Далее смотря что называть проектами, если речь идет о support activities (однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:)

Ну так вот, собственно и вопрос - а можно ли считать саппорт voip, саппорт eompls и саппорт unix-hosting'а "достаточно однотипными" задачами для того, чтобы саппортер между ними эффективно переключался ? Или эти три задачи стоит разделить на три саппорт-группы ?

А вот если из-за проблем с eompls возникнет проблема с voip и то группы могут устроить очень неплохое кольцо :) поэтому им нужна support-группа 2го уровня

Или просто не бить саппортера ногами в случае неэффективного переключения между задачами и быть готовым к тому, что если его еще заставят поддерживать rfc2547-bis vpn'ы на juniper'ах и java-based crm - у него возникнет желание сначала повеситься а потом уволиться ? :)

-- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 Bike is the freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Alexandre Snarskii wrote:

...

А вот если из-за проблем с eompls возникнет проблема с voip и то группы могут устроить очень неплохое кольцо :)

AS> Не могут. Проблемы voip довольно однозначно диагностируются либо как AS> "собственно проблемы voip" либо как проблемы нижнего (в данном случае AS> сетевого) уровня. То есть - проблема voip должна остаться на рассмотрении AS> VoIP группы, а в NOC должна уйти сетевая проблема, после разрешения AS> которой voip-проблема теоретически должна решиться сама собой AS> (если дело было только в сетевой проблеме). AS> Так как NOC не может передать сетевую проблему в VoIP - кольца не AS> возникает... voip'щикам, для того, чтобы знать, что это сетевая проблема, надо четко знать, что это она, значит пониманием сети надо владеть. Потому что они сваливанием проблем на NOC будут делать заниматься как панацеей: если это не сетевая, значит наша, т.е. доказательством от обратного ;-) PS: кстати, это я глючу, или стали в reply to all ставиться все участники ? -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message