Денис Бесков ([info]beskov) wrote,
@ 2008-01-11 20:14:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
3 организационных подхода к созиданию нового
Из наблюдений за индустрией консалтинга и создания продуктов и систем мне видится, что есть 3 основных подходов к тому, чтобы решить какую-то сложную (или не очень) задачу в этой области.

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

2. Синергетический
Создание продукта происходит посредством определённым образом организованной коллективной деятельности команды профессионалов в разных областях, касающихся данного продукта. Каждый из них не обязан быть абсолютным экспертом, скорее должен превосходить уровень специалиста и уметь работать в команде. Команда формируется не только на основе профессиональных компетенций, но и командных ролей. Одна из ключевых составляющих такой работы - опытный куратор команды, который её формирует и организует её работу. Главная особенность синергетического подхода - частые мозговые штурмы, перемежающиеся этапами сбора и отработки различных идей. На мой взгляд, команда может давать результаты, близкие к идеальным и достаточно быстро. Другое дело, что ресурсная стоимость создания и поддержания такой команды достаточно высока, такой подход могут позволить себе немногие в индустрии. Антипаттерн - Design by Commitee.

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

NB: Такой перечень подходов немного напоминает типовые оргструктуры по Минцбергу и стадии развития организации по Адизесу.

Кстати, выстроилась некоторая очевидная, наверное, секвенция: Эксперт > Профессионал > Специалист.

Я в основном в своей жизни участвовал в процессных и псевдо-экспертных подходах (когда человек пытается всё сделать сам, экспертом не являясь).



(26 comments) - (Post a new comment)


[info]mama_ari
2008-01-11 05:56 pm UTC (link)
oj. menia prosto pugajet rifmovannost' moej zhizni. noch'u v pervyj raz uvidela familiju Adizes, serfila raznoje pro business-obrazovanije i natknulas'. utrom tut zhe upomianul ego meatrich, a teper' pod vecher - ty. chto eto za znak, blin.
http://meatreach.livejournal.com/227662.html - tut, sm. commenty.

(Reply to this) (Thread)


[info]beskov
2008-01-11 06:02 pm UTC (link)
спокойно, я же из вашей же переписки его взял

(Reply to this) (Parent)(Thread)


[info]mama_ari
2008-01-11 06:18 pm UTC (link)
uff!!! :)

(Reply to this) (Parent)


[info]xekc
2008-01-11 07:43 pm UTC (link)
4. Итерационный

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

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

как то так, а?

Что бы не менять последовательность, нужно понимать что эксперт субьективен, а цифры обьективны. То есть это не способ 4, а способ 0 и последовательность Аналитик > Эксперт > Профессионал > Специалист. Эксперт умный и он угадывает, аналитик знает.

Про то что настоящий номер 0 это система которая вносит изменения сама по данным аналитики я писать не буду, не буду, не буду... :)

(Reply to this) (Thread)


[info]beskov
2008-01-11 07:56 pm UTC (link)
Все 3 предложенных мной подхода допускают итерации, причём в 1-м они происходят неявно, во 2-м - явно, в 3-м - по необходимости. Кстати, есть такое предубеждение, что ГОСТ на ИС/ПО не позволяет работать итерационно. Workflow <> Waterfall.

"Широкий набор ключевых параметров" - это оксюморон.

Постановка задачи - за пределами собственно созидания.

Про бесконечное количество не понял в принципе.

Аналитик - это просто роль и профессия, а не уровень экспертизы. Аналитик владеет аналитическими методами. Знает - это уже мудрец :)

В "создание нового" я включаю, например, написание картины.

(Reply to this) (Parent)(Thread)


[info]xekc
2008-01-11 09:51 pm UTC (link)
писал писал и написал называется коммент.. он не влазит тут, да и может у меня будет кому интересно почитать.

(Reply to this) (Parent)


[info]beskov
2008-01-11 08:02 pm UTC (link)
Последовательность "Эксперт... Специалист" это не демонстрация порядка выполнения работ, а отношений объёма их компетенции.

> - это знак "больше")

(Reply to this) (Parent)(Thread)


[info]xekc
2008-01-11 09:52 pm UTC (link)
я понимаю что это знак больше :))))

(Reply to this) (Parent)


[info]xekc
2008-01-11 09:53 pm UTC (link)
ну хорошо, может быть не "Аналитик" а "Модель" я не знаю чего туда поставить на самом деле. но знак больше - да.

(Reply to this) (Parent)


[info]tolldo
2008-01-11 09:14 pm UTC (link)
Может и не в тему. Но предположим есть такие массовые явления, например:
  1. биологическая эволюция

  2. политика (результаты которой ощущаются потом многими поколениями)

  3. идеология (мысль овладевшая массами)

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

(Reply to this) (Thread)


[info]dancing_harmony
2008-05-20 05:05 pm UTC (link)
Это насилие над понятием "организация")

(Reply to this) (Parent)

Для разделения подхоов необходимо противоречие
[info]cornerles
2008-01-11 10:55 pm UTC (link)
На мой взгляд, три перечисленных "подхода" являются просто различными измерениями и не противоречат а дополняют друг друга.

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

Вырожденные ситуации и дадут описанные "подходы" :-)

(Reply to this) (Thread)

Re: Для разделения подхоов необходимо противоречие
[info]bas4all
2008-01-13 08:46 pm UTC (link)
Полностью с тобой согласен. Например, в первом подходе есть эксперт, кот делает бОльшую часть работы, и в 3ем есть эксперт (или как назвал Денис - процессный инженер), кот делает меньшую часть работы - ставит процесс и дает пинок.

(Reply to this) (Parent)


[info]beskov
2008-01-13 10:17 pm UTC (link)
в каждом проекте есть люди, но не в каждом есть команда

там противоречия нет, но есть различительные признаки по количеству участников и типу коммуникации (1-1, 1-N).

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

(Reply to this) (Parent)(Thread)


[info]cornerles
2008-01-14 02:56 pm UTC (link)
мне всегда казалось, что понятие "вырожденный" означает "не встречающийся на практике".

В математике под "вырожденным" понимается ситуация когда по той или иной причине один из факторов не учитывается, Т.е. вырождается фактор а не случай как таковой.
Например какой то коэффициент равен нулю. И тогда говорят о том что уравнение вырожденное.

(Reply to this) (Parent)

хорошая проекция.
[info]neo_der_tall
2008-01-11 11:24 pm UTC (link)
действительно очень разрез для анализа выбран. Но я бы заострил внимание еще на одном аспекте - эффективности как функции размера проекта во всех трех случаях. Т.е. все так, но вот единственный способ построить реально большую систему - это 3. (не забываем о несчастных случаях, падении мотивировки, замыленности взгляда и мышления, ... и проих мелочах в которых кроется дьявол)

(Reply to this) (Thread)

Re: хорошая проекция.
[info]beskov
2008-01-11 11:43 pm UTC (link)
эффективность - не функция размера

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

если нам нужен по-настоящему инновационный продукт, то 3 способ, например, подойдёт менее всего

а для того, чтобы сделать по-настоящему большую систему (продумать все детали и не забыть про концептуальную целостность) нужна комбинация 1 и 2, 1 и 3 или 2 и 3.

(Reply to this) (Parent)(Thread)

как это не функция? конечно функция. но не только
[info]neo_der_tall
2008-01-11 11:48 pm UTC (link)
Можно конечно кинуться в уточнение что такое эффективность, но опять придем к спору о терминах. Скажу просто что с ростом проекта растут и затраты на организацию, координацию и т.п., что я не включаю в "продуктогенерящую" деятельность. Потому - зависимость есть и еще какая.

хм.. как Вы себе представляет комбинацию, например 1 и 3 вживую?

(Reply to this) (Parent)(Thread)


[info]beskov
2008-01-13 10:12 pm UTC (link)
скорее нужно уточнить термин "размер проекта". я говорил только про "сложность", а не размер, а это не одно и то же

3 помогает в случае больших проектов (для масштабирования), но со сложностью умеют справляться только 1 и 2

например, ситуация, когда архитектор (ГАП) проектирует уникальное здание под заказчика, а его подсистемы проектируются стандартными отраслевыми инженерами-проектировщиками

(Reply to this) (Parent)

Re: хорошая проекция.
[info]alisherhasanov
2008-01-12 12:14 am UTC (link)
очень соглашусь мой дорогой гуру... да кстати и любимый гуру тоже.

ваша зайка

(Reply to this) (Parent)

Очень похоже на классификацию Майстера
(Anonymous)
2008-01-12 05:04 pm UTC (link)
Предложенная классификация очень напоминает то, что предложил Дэвид Майстер для организаций, занимающихся профессинальными услугами:
http://www.ozon.ru/context/detail/id/1456592/
У него три типа проектов "мозги" (требуется экспертный уровень), "седина" (требуется опыт) и "процедуры" (требуется следование технологиям.

(Reply to this) (Thread)


[info]beskov
2008-01-13 10:19 pm UTC (link)
я подозревал, что тема не нова)

(Reply to this) (Parent)

Re: Очень похоже на классификацию Майстера
[info]tutunov
2008-01-24 04:11 pm UTC (link)
Действительно похоже (хотя мне кажется, что только внешне).

Жаль, что Майстер не рассматривает вопросы командной работы (кроме как в смысле баланса квалифицированных и неквалифицироанных работников на проекте). Его анализ нацелен больше на создание бизнес-модели. Т.е. как зарабатывать на консалтинге, как при этом подобрать пропорции специалистов, как эти пропорции связаны с типами выполняемых проектов (потребностями клиентов).
Отсюда и классификация проектов:
- Новые, сложные и высокорискованные проекты требуют экспертов(мозги), у которых нет опыта решения именно таких проблем, но есть высокие компетенции;
- Более традиционные и достаточно сложные проблемы, требуют опытных именно в этой проблематике спецов (седина);
- Если надо решать стандартные проблемы и недорого, то нужны такие консультанты, у которых отработана технология решения (процедуры), а кто работает не важно.

Эта шкала достаточно четко располагает проекты по степени убывания инновационности, рекомендует и квалификацию исполнителей.

Соответсвенно, я думаю, что слова в 2-х классификациях использованы похожие, а суть разная.

(Reply to this) (Parent)

Поздравления и вопрос
[info]maashaa
2009-05-15 02:30 pm UTC (link)
Денис, во-первых, мои поздравления с замечательным назначением! Большому кораблю... Меня месяца три назад приглашали пообщаться на эту тему, но я, зная, что существуют люди Вашей квалификации, решила не тратить время. :-)

Вот какой вопрос хочется задать Вам, как глубокому и знающему энциклопедисту. Есть с Вашей точки зрения наиболее признанное и стандартизованное описание bug workflow или support ticket workflow? Интересно формальное описание приоритетов проблем, переквалификации в другой тип и изменения ответственного - при таком распространении и сродстве автоматизированных систем должен же был найтись кто-то описавший общее в их многообразии?

(Reply to this) (Thread)


[info]beskov
2009-05-15 02:50 pm UTC (link)
Спасибо за поздравления.

Стандартизованных описаний bug workflow не существует, разве что преднастройки в соответствующих инструментах.

Рекомендую посмотреть книги и статьи на эту тему: http://software-testing.ru/books/testing-books

Я глубоко тестирование и обеспечение качества не копал.

(Reply to this) (Parent)(Thread)


[info]maashaa
2009-05-15 04:50 pm UTC (link)
Вот что нашлось, даже с картинками. Пусть на роль стандарта и не претендует, зато просто и с картинками. :-)

http://www.redhat.com/apps/support/
http://www.redhat.com/support/process/production/#howrh
http://www.redhat.com/support/policy/GSS_severity.html

(Reply to this) (Parent)


(26 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…