Обсуждение

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

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

Здесь такой клубок терминов и переводов. capabilities - это не только полномочия, но и компетенции, competencies, умения, scill. А компетенции, не только умения, но и полномочия - "компетентные огрганы", "ваших компетенций не достаточно" Таким образом, "могу" и "имею право" идут как синонимы. Хотя в русском так и есть. В паттернах пользователей бы не запутать.

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

Да, ИМХО capabilities это, скорее, то, что присуще, и тем самым не может быть привнесено или отозвано извне, а полномочия, ability, permission - то, что придается именно снаружи и не является внутренним свойством. Хотя и определенные пересечения смыслов есть, когда начальник говорит "я могу", он имеет в виду, что необязательно это может лично он, он, быть может, в жизни молотка не видал, а что у него есть Левша, который эту блоху по приказу этого начальника вмиг подкует. Здесь бюрократическая языковая практика едва ли не намеренно запутывает суть, для упрощения и инкапсуляции несущественных на данном уровне деталей.

Давайте разведем две работы: 1. Выбор терминов, концептов, понятий, в которых мы будем описывать организацию. 2. Меры, которыми мы будем в жизни добиваться, чтобы as is перешло в to be согласно нашим паттернам (реорганизация согласно паттернам). Я не пойму ваших формулировок: они про первую или про вторую работу? С одной стороны, "оценивать влияние начальника" явно из работы-2, с другой стороны, общий вид такой, что вы задаете модельные ситуации для работы-1. Плюс у вас "задача", а у меня термин Таска (в котором может прятаться огромная иерархия задач, все из которых назначены разным Исполнителями разными Начальниками). Можно ли как-то конкретизировать -- на какие вопросы вы отвечаете своими репликами, или какие вопросы задаете? И если вы используете отличающуюся от предложенной терминологию, то почему -- может, нужно термины поправить? Я просто не пойму, как учесть ваши комментарии.

1. Ага, Начальник=ОргЗвену я как раз думаю: тут действительно полный бардак, который отражается во многих софтовых системах (есть системы, в которых начальник даже не входит в свое ОргЗвено, а выставляется на отдельный уровень иерархии!). Тут нужно еще думать, как про это говорить. 2. Разделение "я имею право поручить" -- "я имею обязанность взять, но пошел ты нафиг -- вас таких много, а я один, и ресурса на твою работу у меня нет" я как раз и имею ввиду, когда говорю "полномочия" -- "Обязанности". Дальше я хотел бы обсуждать, бывают ли полномочия, пришедшие не по административно-формальной линии, а от какого-нибудь местного серого кардинала, которого уважают, но который работает уборщицей. И наоборот: что происходит, когда БольшойНачальник выдает команду, которую заведомо никто исполнять не будет (и выяснится это, когда все накроется медным тазом от неисполнения этой команды). 3. Я имею ввиду capabilities как софтверный механизм, а не игру в словарики. Раньше при рассказе о capabilities произносили слово token. Эти token отнюдь не присущи, а именно что передаются, копируются, "имеются". Насколько я понимаю, сейчас слово token не используется, а прямо говорится о capabilities. Реализуется, например, через куки: либо у тебя нужная кука есть, либо ее нет -- и нельзя говорить, что "кука мне присуща". Ибо ее или мне дали, или нет. Я ровно в этом месте говорю, что механизм "полномочий" сразу архитектурно нужно делать правильно. Согласно софтверным паттернам. Нет "присущих полномочий". Есть даденные, переданные, откопированные. Tokens.

Это что-то вроде use cases. То есть, относится больше ко второй работе. Но для них можно ввести какие-то обозначения, и это будет уже из первой. Насчёт "Таска - задача". Я под задачей понимаю в данном случае тоже одну или группу задач на одного и более исполнителей. То есть, почти ваш вариант. Правда, изначально думал в небольшом масштабе порядка нескольких человек. Но, думаю, и на большего размера структуры можно распространить. Возможно, стоит заменить "Таска" чем-то вроде "БольшаяТаска" или "КомплекснаяТаска" - чтобы отличать задачу большого масштаба от задачи для одного конечного исполнителя.

"я имею обязанность взять, но пошел ты нафиг -- вас таких много, а я один, и ресурса на твою работу у меня нет" я как раз и имею ввиду, когда говорю "полномочия" Ещё к терминологии. Мне кажется, имеет смысл как-то отдельно назвать эту "ёмкость" исполнителя по задачам. И к методам. Можно ли вычислить и контролировать эту задачную ёмкость исполнителя, и как это может выглядеть?

В прошлый раз я, кстати, писал о совместимости заданий, выданных одному исполнителю. С количеством и объёмом задач совместимость можно в один ряд ставить.

Терминологию мы ввели в http://ailev.livejournal.com/488460.html Там, вроде, зафиксированы решения по разным категориям Таск.

емкость исполнителя по задачам -- это потом, когда мы будем говорить про планирование. Конечно, будет какая-то оценка производительности. Сейчас на эту тему -- мораторий. Обсуждаем только назначение Тасков Исполнителям. Кто порождает Таски, и как они попадают конкретным Людям-Исполнителям.

Совместимость заданий -- это про планирование. Это пока не входит. Нам бы пока разобраться с самим паттерном назначения Таска Исполнителю. Условия назначения, соответствие жизни планам, соответствие назначения планам, факт исполнения -- пока не интересуют, намеренно. Не обсуждаем. Нельзя обсуждать все сразу. Вопрос очень сложный, на эту тему тома написаны, есть сотни вариантов. Нам нужно определиться. Поэтому новые сущности в рассмотрение пока не вводим.

Там по объёму Таски не делятся - то есть, нет различия в названии элементарной Таски и составной.

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

Да, конечно. Таска представляет собой некоторое количество из ПлановГромадья или Труда. Но при настройке системы Таски именуются по тем категориям, куда они попадут -- могут быть Баги, Проекты, Процессы, Поручения, Операции, ЭлементарныеДействия и т.д. А в общем случае этого всего нет.

Две операции: 1. дробление Таски на части. 2. Назначение Исполнителей. Тут отдельный вопрос, Исполнитель -- это Оргзвено, или отдельный человек (кстати, в юридической практике директором подразделения можно назначить юридическое лицо -- т.е. целую компанию ;) Тут в соседних тредах обсуждают язык, которым говорят о поручении задач: поручение Начальнику оргзвена часто означает просто поручение его Оргзвеную. Это запутывает. А нам нужно распутывать. Весь вопрос, как. Отчет о выполнении (плана) -- это будем решать после того, как сообразим про сам план. То есть сильно потом. Пока разбираемся с различными полномочиями по назначению Начальства, по назначению Начальством задач Исполнителям. Вы бы поглядели, как эти вопросы решаются в разных issue trackers (их на рынке тьмы). И предложили, как улучшить применяющиеся там модели. А то какая-то странная у нас дискуссия...

по 1 и 2 - согласен. По 3 не совсем. Token ИМХО никуда не делся. Честно говоря, не слышал в контексте безопасности слова capability. Насколько могу судить, права доступа стали более гранулированные, и capability означает неделимую единицу, а token - их пучок. Присущесть и даденность, здесь такая же. Либо тот, кому token дали, способен - тогда он даденные полномочия юзает в меру своих capabilities, либо нет - тогда даденные полномочия ему до лампочки. Кука, как ты верно пишешь - это все про даденность.

Про capabilities я в постинге ссылку привел. Погляди тамошний текст (хотя уже 8 лет прошло ;) Там, кстати, и элементарные операции с правами приведены -- которые нужно обеспечивать. Нам все это пригодится ;) Только права совершенно необязательно привязывать к безопасности. А обсуждение capabilities (как механизма, софтверного паттерна) сегодня ведется на 90% по линии security -- уж больно удобно это обеспечивать именно таким образом! А мы можем пообсуждать и иные права - так, милиционер предъявляет удостоверение, и начинает винтить кого-нибудь прямо на улице. И не нужно при этом иметь централизованный список милиционеров, чтобы тыкать в него каждый раз. Вот и начальники могут предъявлять жетон исполнителям. Петя получил у БольшогоНачальника жетон, и пошел к Васе поручать ему работу... Это все делается стандартными софтверными паттернами capabilities и обсуждаться может примерно в этих же терминах. Жетоны, пропуска, мандаты (кстати, "мандат" -- это как раз словарная формулировка ;) Capability означает софтверный паттерн (такой же, как Singleton или MVC или Decorator, а то и более высокоуровневый, т.е. архитектурный -- типа "клиент-сервер" или "клиент-мидлварь-сервер"). Почитай по приведенной ссылке.

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