Следующий вопрос.

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

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

Здравствуйте, Spidola, Вы писали:

S>Следующий вопрос.

S>В дисциплине управления рисками есть темы, связанные с персоналом. Есть некоторые методики по устранению данных рисков. Но вот интересен один маленький аспект — если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

S>Интересно, насколько такой риск управляем и какие способы управления данным риском наименее затратны в рамках всего проекта (это я уточняю для того, чтобы учитывались затраты по проекту вцелом и не предлагалось взять ещё пять запасных)?

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

Накладные расходы конечно есть — но с другой стороны это и приток идей обеспечивает.

Здравствуйте, Anatolix, Вы писали:

A>Здравствуйте, Spidola, Вы писали:

S>>Следующий вопрос.

S>>В дисциплине управления рисками есть темы, связанные с персоналом. Есть некоторые методики по устранению данных рисков. Но вот интересен один маленький аспект — если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

S>>Интересно, насколько такой риск управляем и какие способы управления данным риском наименее затратны в рамках всего проекта (это я уточняю для того, чтобы учитывались затраты по проекту вцелом и не предлагалось взять ещё пять запасных)?

A>Просто нужно сделать чтобы не было сотрудников обладающих сакральными знаниями. А именно чтобы над любой задачей работало как минимум 2 человека. А лучше 3. У XP в этом смысле все хорошо не смотря на прочие возражения к этой методике, почитай про ихнюю метрику того сколько разработчиков может сбить автобус.

XP это конечно интересно, но я данную методологию не люблю как раз из-за парного программирования. Есть нелюбовь объективная и субъективная. Объективная заключается в том, что затраты на программистов существенно возрастают (по большому счёту в два раза), а при сильной специализации программиста это непозволительные расходы. Субъективная заключается в том, что я не согласен с необходимостью парного кодирования. Правда, это тема для другого топика.

По поводу "минимум 2 человека" думаю, что вы предлагаете, чтобы два человека занималось одной задачей из предметной области? Или всё-таки имеется ввиду как в XP — горячая замена?

A>Накладные расходы конечно есть — но с другой стороны это и приток идей обеспечивает.

Вот здесь не понял. Что значит приток идей? Как реализовать requirements?

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

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

Вот и думается, где найти баланс.

Как всегда надо искать золотую середину, исходя из логики вещей.

А вообще, как говорил Б.Н. Ельцин — " ... незаменимых у нас нет ...".

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

Здравствуйте, Spidola, Вы писали:

S>По поводу "минимум 2 человека" думаю, что вы предлагаете, чтобы два человека занималось одной задачей из предметной области? Или всё-таки имеется ввиду как в XP — горячая замена?

Я вот сейчас решаю на практике задачу о заменимости, т.к. перехожу в другую компанию и разруливаю, кто чем будет заниматься из того, что я делал.
Практика показывает что в тех задачах где был еще хотя бы один человек все просто — ему передается и проблем не возникает. Т.е. например писали с человеком вместе олдин из серверов — моего кода 70% его 30%. Писали разные вещи. Но главное что он понимает общий дизайн, а с кодом разобраться дело не хитрое. При этом разница не в 2 раза. Накладные расходы были только н понимание это 10% наверное.

А в тех вещах которые я один проектировал и писал еще долго буду народ консультировать похоже.

A>>Накладные расходы конечно есть — но с другой стороны это и приток идей обеспечивает.

Когда в двоем пишешь то возникает больше взглядов на одни и те же вещи. В том числе и requirements и архитектуру.

S> И то, и то достаточно затратно. В первом случае минусом является то, что растут внерисковые расходы, т.е. расходы на обеспечение быстрого выхода из сработавшего рискового случая). Во втором внерисковые затраты тоже немаленькие, но поменьше, однако при наступлении "страхового случая" возврат к нормальной работе будет медленнее.

Затраты по принципу: 10% затрат обесчпечивают 90% эффекта.

Здравствуйте, Spidola, Вы писали:

S>В дисциплине управления рисками есть темы, связанные с персоналом. Есть некоторые методики по устранению данных рисков. Но вот интересен один маленький аспект — если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

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

Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.

Никогда не надо ставить только одного человека на проект, т.к. это явный признак сбоя в работе при выпадении человека из работы на некоторое время, а в случае форс-мажора (невозможность человеком продолжения работы по тем или иным причинам) — или закрытие проекта, или авральное изучение проекта другими членами группы.

Все выше написанное применимо для non-agile методологий типа MSF, RUP.

A>Затраты по принципу: 10% затрат обесчпечивают 90% эффекта.

А почему такое соотношение ? У Брукса, например, описаны 80-20, 20-80.

Здравствуйте, stasukas, Вы писали:

S>Здравствуйте, Spidola, Вы писали:

S>>В дисциплине управления рисками есть темы, связанные с персоналом. Есть некоторые методики по устранению данных рисков. Но вот интересен один маленький аспект — если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

S>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?

S>Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.
Кстати, как у вас делается CodeReview? Весь код оценивается или только отдельные участки? И, если отдельные, то используются ли какие-либо тулзы для выявления данных участков по метрикам?

S>Никогда не надо ставить только одного человека на проект, т.к. это явный признак сбоя в работе при выпадении человека из работы на некоторое время, а в случае форс-мажора (невозможность человеком продолжения работы по тем или иным причинам) — или закрытие проекта, или авральное изучение проекта другими членами группы.
Ну это да, разумеется.

S>Все выше написанное применимо для non-agile методологий типа MSF, RUP.
К сожалению. На динамичном процессе с этим несколько сложнее, насколько я понимаю.

Здравствуйте, xf_ho, Вы писали:

_>Как всегда надо искать золотую середину, исходя из логики вещей.

_>А вообще, как говорил Б.Н. Ельцин — " ... незаменимых у нас нет ...".

_>Может быть это кощунственно для личности, но если Вы ставите сотрудника в "позу" незаменимого, то по любому это обойдётся гораздо дороже ... (размышления можно продолжить),

Незаменимым конечно нет — есть вопрос стоимости замены. А точнее совокупной стоимости с учётом возможной замены. Вот этот параметр и хочется оптимизировать.

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, stasukas, Вы писали:

S>>Здравствуйте, Spidola, Вы писали:

S>>>В дисциплине управления рисками есть темы, связанные с персоналом. Есть некоторые методики по устранению данных рисков. Но вот интересен один маленький аспект — если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

S>>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
S>По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?
В данном случае это совместная работа, совместные обсуждения. Главное, чтоб каждый исполнитель роли был в курсе того, что делает другой, а заодно и как. При этом я вижу только увеличение производительности, а заодно и качества работы, т.к. "одна голова хорошо, а две лучше".

S>>Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.
S>Кстати, как у вас делается CodeReview? Весь код оценивается или только отдельные участки? И, если отдельные, то используются ли какие-либо тулзы для выявления данных участков по метрикам?
Обычно Code Review делается для измененного модуля более или менее обзорно, изменные части кода анализируется пристально. Желательно обеспечить попеременное написание кода в одном модуле разными кодерами. То же относится к Unit-тестам. У нас в большинстве случаев множество ошибок отлавливается Unit-тестами, а так же системой Continuous Integration, которая производит сборку и тестирование полных версий с системы контроля версионности.

S>>Никогда не надо ставить только одного человека на проект, т.к. это явный признак сбоя в работе при выпадении человека из работы на некоторое время, а в случае форс-мажора (невозможность человеком продолжения работы по тем или иным причинам) — или закрытие проекта, или авральное изучение проекта другими членами группы.
S>Ну это да, разумеется.

S>>Все выше написанное применимо для non-agile методологий типа MSF, RUP.
S>К сожалению. На динамичном процессе с этим несколько сложнее, насколько я понимаю.
В ХР, например, совсем другой подход к разработке. Там и так идет тесное взаимодействие каждого члена команды с другими, а так же с людьми со стороны заказчика. На сколько я знаю, там так же нет четкого разделения ролей типа аналитик, архитектор, PM, кодер, тестировщик.

Здравствуйте, Аноним, Вы писали:

A>>Затраты по принципу: 10% затрат обесчпечивают 90% эффекта.

А>А почему такое соотношение ? У Брукса, например, описаны 80-20, 20-80.



Я думаю если бы даже кто то это соотношение точно считал, то получилось бы не круглое число.

Здравствуйте, stasukas, Вы писали:

S>>>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
S>>По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?
S>В данном случае это совместная работа, совместные обсуждения. Главное, чтоб каждый исполнитель роли был в курсе того, что делает другой, а заодно и как. При этом я вижу только увеличение производительности, а заодно и качества работы, т.к. "одна голова хорошо, а две лучше".
Если за ту же цену, то да, а если за двойную цену — то это как сказать...

S>>>Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.
S>>Кстати, как у вас делается CodeReview? Весь код оценивается или только отдельные участки? И, если отдельные, то используются ли какие-либо тулзы для выявления данных участков по метрикам?
S>Обычно Code Review делается для измененного модуля более или менее обзорно, изменные части кода анализируется пристально. Желательно обеспечить попеременное написание кода в одном модуле разными кодерами. То же относится к Unit-тестам. У нас в большинстве случаев множество ошибок отлавливается Unit-тестами, а так же системой Continuous Integration, которая производит сборку и тестирование полных версий с системы контроля версионности.
Сенкс. Поглядим.

S>>>Все выше написанное применимо для non-agile методологий типа MSF, RUP.
S>>К сожалению. На динамичном процессе с этим несколько сложнее, насколько я понимаю.
S>В ХР, например, совсем другой подход к разработке. Там и так идет тесное взаимодействие каждого члена команды с другими, а так же с людьми со стороны заказчика. На сколько я знаю, там так же нет четкого разделения ролей типа аналитик, архитектор, PM, кодер, тестировщик.
Хм, почему нет? Парное программирование это не запрещает, насколько я понимаю...

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, stasukas, Вы писали:

S>>>>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
S>>>По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?
S>>В данном случае это совместная работа, совместные обсуждения. Главное, чтоб каждый исполнитель роли был в курсе того, что делает другой, а заодно и как. При этом я вижу только увеличение производительности, а заодно и качества работы, т.к. "одна голова хорошо, а две лучше".
S>Если за ту же цену, то да, а если за двойную цену — то это как сказать...
В данном случае получается, что мы можем имея некоторый коллектив распределять работу по нему. Поэтому и речи нет о "двойной цене".

S>>>>Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.
S>>>Кстати, как у вас делается CodeReview? Весь код оценивается или только отдельные участки? И, если отдельные, то используются ли какие-либо тулзы для выявления данных участков по метрикам?
S>>Обычно Code Review делается для измененного модуля более или менее обзорно, изменные части кода анализируется пристально. Желательно обеспечить попеременное написание кода в одном модуле разными кодерами. То же относится к Unit-тестам. У нас в большинстве случаев множество ошибок отлавливается Unit-тестами, а так же системой Continuous Integration, которая производит сборку и тестирование полных версий с системы контроля версионности.
S>Сенкс. Поглядим.

S>>>>Все выше написанное применимо для non-agile методологий типа MSF, RUP.
S>>>К сожалению. На динамичном процессе с этим несколько сложнее, насколько я понимаю.
S>>В ХР, например, совсем другой подход к разработке. Там и так идет тесное взаимодействие каждого члена команды с другими, а так же с людьми со стороны заказчика. На сколько я знаю, там так же нет четкого разделения ролей типа аналитик, архитектор, PM, кодер, тестировщик.
S>Хм, почему нет? Парное программирование это не запрещает, насколько я понимаю...
Да, можно пользоваться парным программированием, но у Вас не будет 2 аналитиков, 2 архитекторов, 2 кодеров (т.е. четких ролей), у Вас будут универсальные солдаты. Да и логика работы там постороена на тесном взаимодействии всех с всеми. А оприсание я делал именно для "тяжелых" методологий, поэтому такой PS.

Здравствуйте, stasukas, Вы писали:

S>Здравствуйте, Spidola, Вы писали:

S>>Здравствуйте, stasukas, Вы писали:

S>>>>>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
S>>>>По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?
S>>>В данном случае это совместная работа, совместные обсуждения. Главное, чтоб каждый исполнитель роли был в курсе того, что делает другой, а заодно и как. При этом я вижу только увеличение производительности, а заодно и качества работы, т.к. "одна голова хорошо, а две лучше".
S>>Если за ту же цену, то да, а если за двойную цену — то это как сказать...
S>В данном случае получается, что мы можем имея некоторый коллектив распределять работу по нему. Поэтому и речи нет о "двойной цене".
Почему нет? Насколько я понимаю, когда 2 человека занимаются одной и той же задачей (рассматриваем не проектирование — там сложнее — а кодирование), даже если они занимаются кодированием не параллельно, а последовательно, то всё равно требуется время на "вхождение" в задачу. Это время можно минимизировать очень глубокой проработкой низкоуровневого дизайна, однако всё равно затраты на вхождение должны быть. Или я не прав? Пусть не двойная цена, но всё равно процент потерь существует. Возможно, этот процент может компенсироваться более быстрым принятием решений по некоторым сложным вопросам, но в этом случае это уже не парное консультирование, а модель с "хирургом", когда есть эксперт (гуру), решающий сложные вопросы...

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, stasukas, Вы писали:

S>>Здравствуйте, Spidola, Вы писали:

S>>>Здравствуйте, stasukas, Вы писали:

S>>>>>>Если роли в группе достаточно четко распределены, то необходимо вводить дублирование функций каждой роли на 2-х или более человек и их постоянное взаимодействие друг с другом для поддержания актуальности для каждого члена команды.
S>>>>>По вашему опыту — насколько падает интегральная производительность команды при появлении затрат на дублирование?
S>>>>В данном случае это совместная работа, совместные обсуждения. Главное, чтоб каждый исполнитель роли был в курсе того, что делает другой, а заодно и как. При этом я вижу только увеличение производительности, а заодно и качества работы, т.к. "одна голова хорошо, а две лучше".
S>>>Если за ту же цену, то да, а если за двойную цену — то это как сказать...
S>>В данном случае получается, что мы можем имея некоторый коллектив распределять работу по нему. Поэтому и речи нет о "двойной цене".
S>Почему нет? Насколько я понимаю, когда 2 человека занимаются одной и той же задачей (рассматриваем не проектирование — там сложнее — а кодирование), даже если они занимаются кодированием не параллельно, а последовательно, то всё равно требуется время на "вхождение" в задачу. Это время можно минимизировать очень глубокой проработкой низкоуровневого дизайна, однако всё равно затраты на вхождение должны быть. Или я не прав? Пусть не двойная цена, но всё равно процент потерь существует. Возможно, этот процент может компенсироваться более быстрым принятием решений по некоторым сложным вопросам, но в этом случае это уже не парное консультирование, а модель с "хирургом", когда есть эксперт (гуру), решающий сложные вопросы...

Если не хочется раздавать одну задачу на 2-х кодеров, то отвечу своей же цитатой несколькими постами раньше:

Кодерам достаточно делать очень регулярно Code Review других членов команды (заодно повышается качество продукта) и периодически делать обзоры по дополнениям и изменениям архитектуры.

S>если команда небольшая (5-6) человек, то каким образом управляют риском "недоступности" (т.е. когда один из ключевых членов команды внезапно становится недоступным на длительное время, фактически выпадая из команды на срок, существенно влияющий на общий срок выполнения проекта)?

Если проект надо сдавать завтра или он узкоспециализизованноэкзотичный (драйвер гироскопа для системы стабилизации разгонного блока ), то вы, как шеф проекта, попали

Если типичный entrprise проект и срочно нужен человек, то решается очень просто — ищется гуру, который стоит, на самом деле, всего раза в 2 дороже кодера. Дать объявление на 10..20..30% выше рыночной стоимости. Въехать в такой проект для гуру не представляет большой сложности

Типичный стаффинг для проектов 5-6 человек, большая контора-интегратор (я видел пару десятков таких проектов, думаю, можно экстаполировать на 99 %): эксперт — в лучшем случае один , один-два адвансед, остальные кодеры. Критичный ресурс на таких проектах всего один, остальных заменить не проблема.