Вопрос по назначению задач не даёт спать. В ряде веток Agile задачи назначаются руководителем (см. FDD методологию). Но в основном принято задачи разбирать самими разработчиками. Остаётся вопрос — когда?

Вариант 1 (Tasks ownership). В начале итерации все расхватывают задачи, а потом уже помогают друг другу. Общий пул задач. Каждый, кто освободился, берет себе задачу с наивысшим приоритетом.
+ Ориентация на общее решение (приоритетность задач)
+ Выполняется максимально возможное количество самых приоритеных задач
+ Возрастает мотивация (я выбираю сам согласно приоритету, я являюсь вкладом в командный успех)
+ Командная ответственность
+ При появлении высокоприоритетных задач во время итеррации их легко отправить в разработку
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру), а потом поделиться размышлениями с коллегой, взявшим задачу
+ Общее владение кодом
+ Общий стиль программирования
+ Кросс-функционалность
+ Повышение коммуникации

Вариант 2 (Individual Commitments). Общий стэк задач на всю итерацию, и каждый отхватывает самую приоритетную.
+ Ориентация на личные предпочтения
+ Возрастает мотивация (я выбрал задачи сам)
+ Индивидуальная ответственность
+ Специализация разработчиков
+ Можно "вынашивать" решение: есть время подготовится к решению задачи в свободное от работы время (поразмышлять, почитать лит-ру)
— Разные стили программирования
— Незаменимость учатников
— Снижение коммуникации

Я работал в обоих вариантах. Есть свои плюсы и минусы в обоих. Предлагаю послушать эксперта в области оценки в Agile проектах :

Individual Commitments (Mike Cohn Agile Extimating and planning)

When assessing the ability to commit to completing a set of new functionality,
some teams prefer to allocate each task to a specific person and
then assess whether each individual is able to commit to that amount of
work. This approach works well and I’ve recommended it in the past
(Cohn 2004). However, I’ve found that by not allocating tasks while planning
the iteration and not doing the personal math needed to make individual
commitments, the team benefits from the creation of a “we’re
all in this together” mindset.

If you do find a need to allocate tasks to individuals while planning an
iteration, the allocations should be considered temporary and subject to
complete change once the iteration is planned and underway.


Как вы думаете какой способ лучше? Почему? Может быть ещё эффективней способ?

denis miller пишет:

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

> Может быть ещё эффективней способ?
как продолжение вышеописанного ряда — все задачи назначаются сверху. Оч
хорошо подходит для абсолютно демотивированной команды, погоняемой
кнутом ввиду полного отсутствия реакции на пряник. Плюсы и минусы
общеизвестны

--
np: [foobar2000] not started

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

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

А что, мотивация зависит только от способа распределения задач

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

Я обычно активно приглядываю за процессом распределения задач, активно собирая feedback от разработчиков и стараясь балансировать важность, интересность, заметность для заказчика, новизну.
Если за этим не следить — то точно будут недовольные, что приводит к демотивации.

Дельгядо Филипп пишет:

> А что, мотивация зависит только от способа распределения задач

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

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

если неинтересность задачи вытекает из ее простоты и рутинности —
добавьте в команду пару джуниоров
если же сложно, а потому неинтересно — нужно привлечь эксперта который
или сам сделает, или кого-нить из "коммандосов" научит

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

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

> Я обычно активно приглядываю за процессом распределения задач, активно
> собирая feedback от разработчиков и стараясь балансировать важность,
> интересность, заметность для заказчика, новизну.

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

> Если за этим не следить — то точно будут недовольные, что приводит к
> демотивации.

да, согласен на 100% — без тесного контакта с командой последняя очень
быстро потухает и сбавляет темпы.

--
np: [foobar2000] not started

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


РД>если неинтересность задачи вытекает из ее простоты и рутинности —
РД>добавьте в команду пару джуниоров
РД>если же сложно, а потому неинтересно — нужно привлечь эксперта который
РД>или сам сделает, или кого-нить из "коммандосов" научит

Ну, есть, увы, такие задачи, как разбор инцидентов. Там 80% простой рутины, с которой и junior справиться.
Но иногда есть и дико сложная рутина, с которой и сеньор неделю просидит.
И, увы, для многих подобные задачи неимоверно скучны — разбирать гигабайты логов и восстанавливать логику.

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

DM>Вопрос по назначению задач не даёт спать. В ряде веток Agile задачи назначаются руководителем (см. FDD методологию). Но в основном принято задачи разбирать самими разработчиками. Остаётся вопрос — когда?

См. FDD методологию. А также, см. waterfall Назначается руководителем, с учетом пожеланий, личных предпочтений, способностей, и опыта членов команды. Потому, как команда принимает участие в сессии планирования, учет всего перечисленного происходитсам собой. Участие и решающая роль руководителя в данном случае обязательны, потому, как он обязан развивать опыт членов командыв определенных направлениях, и, поэтому, обязан иметь контроль над тем, какие задачи выполняет каждый — для обеспечения выполнения вмененных обязанностей. Например, руководитель с согласия подчиненных и учитывая их опыти предпочтения, выделяет им зоны ответственности, называемые в просторечье code ownership.

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

Дельгядо Филипп пишет:

> Но иногда есть и дико сложная рутина, с которой и сеньор неделю просидит.

неделя на одну задачу — это уже не совсем рутина. ИМХО.

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

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

--
np: [foobar2000] not started

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

РД>Дельгядо Филипп пишет:

>> Но иногда есть и дико сложная рутина, с которой и сеньор неделю просидит.
РД>неделя на одну задачу — это уже не совсем рутина. ИМХО.
Да всякое бывает. Вылизать критический код (который работает, но нужно ускорить раза в два, например). Или поймать блуждающую багу в многопоточном приложении с кучей legacy. Первый раз это делать интересно, десятый — рутина рутиной. Хотя и очень сложная рутина.

РД>А можно поподробнее поинтересоваться, что это и зачем это? Если это
РД>узкоспециальные области вроде антивирей или кернелмодовых драйверов —
РД>есть такие же узкие специалисты, которым это интересно... или я чего-то
РД>не допер?

Не, все очень просто. Нормальные дневные логи не очень нагруженного веб-сервиса.
И нужно выяснить, жалоба пользователя в саппорт вызвана реальной багой, сложным сочетанием обстоятельств или извращенным поведением пользователя.
Рутина, но иногда очень противная. Особенно если система — legacy

Как я понял, альтернатив предложенных мною трёх вариантов нету

1. Распределение руководителем исходя из специализации
2. Задачи разбираются разработчиками в начале итерации исходя из важности, а не специализации
3. Задачи разбираются во время итерации исходя из важности, а не специализации

Предлагаю не рассматривать способ п.1 — как вдоль и поперёк изученный. Так же его производные.
Поделитесь опытом по 2 и 3 варианту?


denis_miller

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

А>Как я понял, альтернатив предложенных мною трёх вариантов нету

А>1. Распределение руководителем исходя из специализации
А>2. Задачи разбираются разработчиками в начале итерации исходя из важности, а не специализации
А>3. Задачи разбираются во время итерации исходя из важности, а не специализации

А>Предлагаю не рассматривать способ п.1 — как вдоль и поперёк изученный. Так же его производные.
А>Поделитесь опытом по 2 и 3 варианту?

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

Поэтому, ни один из вариантов 2 и 3 не годится. 2 не годится потому, что задачи разбираются без учета специализации, что может повлиять только негативно как на сроки, так и на риск. 3 — тем более не годится потому, что еще и затруднен учет логических связей между задачами — разработчики разбирают задачи не собравшись толпой, а поодиночке, то есть ситуация становится полностью хаотичной и неуправляемой. В варианте 2 они хоть имеют возможность договорится между собой, в варианте 3 это уже затруднено, и они сами не имеют никаких идей относительно того, чем будут заниматься. Лотерея. Ты думаешь, людям это нравится? Им нихрена такое не нравится.

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

Опытом по 2 и 3 варианту поделиться? Ты спрашиваешь примерно следующее — когда гребешь по собачьи, ногами как лучше дрыгать? Тебе тяжело тут будет получить ответ на такой вопрос — ИМХО большинство плавают брассом, кроллем, в худшем случае — "саженками". Это тебе к студентам надо, только они так и работают. Надо совсем никакого опыта не иметь, чтобы действовать так.

Gaperton пишет:

> не столько характеристикой самой задачи, сколько пары
> "исполнитель-задача". Поэтому за руководителем и оставляют последнее
> слово, это лучший из выдуманных человечеством способов проследить за
> тем, чтобы порядок задач был оптимальным, при этом учесть интересы
> исполнителей, и разрешать конфликты.

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

--
np: [foobar2000] not started

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

РД>добавлю только, что руководитель — это не обязательно высший
РД>руководитель ака проман или продакт менеджер. Можно делегировать
РД>распределение части задач тимлиду или архитектору.

А кто еще кроме тимлида может задачи по команде распределить, интересно?
Это же его первейшая задача и зона компетенции. Собственно, за этим он и нужен в основном
Приоритеты по бизнес-задачам — да, нужны от продуктового менеджмента, но людей распределять — нафиг, нафиг.

Дельгядо Филипп пишет:

> А кто еще кроме тимлида может задачи по команде распределить, интересно?
> Это же его первейшая задача и зона компетенции. Собственно, за этим он и
> нужен в основном

от структуры команды зависит, и от устоявшихся процессов. К примеру, ПМ
может распределять сеты задач между тимлидами, а они уже внутри своего
тима. Или ПМ сам задачи раздаст, а тимлид только контролирует выполнение
— такое тоже бывает

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

it depends...
в идеале — нафиг.

--
np: [foobar2000] not started

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

РД>Дельгядо Филипп пишет:

>> А кто еще кроме тимлида может задачи по команде распределить, интересно?
>> Это же его первейшая задача и зона компетенции. Собственно, за этим он и
>> нужен в основном

РД>от структуры команды зависит, и от устоявшихся процессов. К примеру, ПМ
РД>может распределять сеты задач между тимлидами, а они уже внутри своего
РД>тима. Или ПМ сам задачи раздаст, а тимлид только контролирует выполнение
РД>- такое тоже бывает

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

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

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

РД>it depends...
РД>в идеале — нафиг.

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

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

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

для больших команд (десятки человек) — да, вплоть до построения иерархии тимлидов.
для маленьких (кстати по моим наблюдениям Agile чаще начинают использовать именно мелкие группы) — ПМ и тимлид зачастую един в двух лицах. Еще бывают варианты ПМ-архитектор и даже ПМ-QA я видел
Понятное дело что практика некошерная, но такое имеет место быть по ряду субъективных причин.

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

G>Соответственно, тим-лид не может отвечать за выполнение плана, составленного не им.
Ну здрасте, а план проекта то ПМ составляет...

G>Если же предполагается, что тим-лид имеет право принимать корректирующие мероприятия, то в этой схеме есть тенденция к нарушению принципа одного ответственного — ПМ имеет возможность свалить вину за неудачи на тим-лида. Устроился ПМ удобно — если все хорошо — он молодец, если все плохо — тим-лид не справился.
Да, я слышал подобные истории о ПМах-"дундуках" и поисках крайнего... боюсь только что это от методологии ну аж никак не зависит.
Если команда вменяемая — сам процесс поиска крайнего отпадет за ненадобностью, если нет — горбатого могила исправит.

G>В идеале — тим-лиды должны получать четко поставленные цели, и иметь свободу действий в их достижении. Тогда и только тогда с него можно требовать и спрашивать, не опасаясь негативных последствий разного рода.
дык это о любой должности сказать можно, так что можно считать это условием by default

G>Auftragstaktik — это то, что реально работает.

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

РД>для больших команд (десятки человек) — да, вплоть до построения иерархии тимлидов.
РД>для маленьких (кстати по моим наблюдениям Agile чаще начинают использовать именно мелкие группы) — ПМ и тимлид зачастую един в двух лицах. Еще бывают варианты ПМ-архитектор и даже ПМ-QA я видел
РД>Понятное дело что практика некошерная, но такое имеет место быть по ряду субъективных причин.

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

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

G>>Соответственно, тим-лид не может отвечать за выполнение плана, составленного не им.
РД>Ну здрасте, а план проекта то ПМ составляет...

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

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

G>>Если же предполагается, что тим-лид имеет право принимать корректирующие мероприятия, то в этой схеме есть тенденция к нарушению принципа одного ответственного — ПМ имеет возможность свалить вину за неудачи на тим-лида. Устроился ПМ удобно — если все хорошо — он молодец, если все плохо — тим-лид не справился.
РД>Да, я слышал подобные истории о ПМах-"дундуках" и поисках крайнего... боюсь только что это от методологии ну аж никак не зависит.
РД>Если команда вменяемая — сам процесс поиска крайнего отпадет за ненадобностью, если нет — горбатого могила исправит.

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

G>>В идеале — тим-лиды должны получать четко поставленные цели, и иметь свободу действий в их достижении. Тогда и только тогда с него можно требовать и спрашивать, не опасаясь негативных последствий разного рода.
РД>дык это о любой должности сказать можно, так что можно считать это условием by default

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

Gaperton пишет:

> Это ничего не меняет
[skip]
нечего там ПМ-ить по большому счету
[skip]

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

> Он *обеспечивает* составление плана проекта, и вовсе не должен
> составлять его единолично. Наоборот. ПМ технически не в состоянии
> составить самостоятельно, без привлечения команды, реалистичный план.
[skip]

кого он привлекает — неважно
главное что он выдает документ на-гора, и он же за него потом отвечает.
а участие отдельно взятого тимлида здесь сугубо опциональное и субъективное.

> Хороший план — всегда результат групповой работы, и он иерархичен (на
> каждом уровне — свой), чтобы иметь возможность распределенного контроля
> и управления.
вот тут согласен на все 100%

> Плюс — есть социальный аспект, команда, участвуя в
> составлении плана автоматически дает commitment на его выполнение, и
> понимает, почему он именно такой, а не другой.

всегда завидовал людям, у которых есть свобода кадрового выбора

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

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

> И выясняется, что большинство людей в общем, оказывается, "вменяемые".

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

> Сказать можно, а вот понять и и воплотить в жизнь судя по всему тяжело.

+1
нет, +100

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

угу
или наоборот

--
np: [foobar2000] not started

G>Поэтому, ни один из вариантов 2 и 3 не годится.

Как я понимаю вывод теоретический.

Любое начинание можно провалить, но вопрос в другом, как сделать так, чтобы 2 и 3 годились? ы?

Да, кстати, я не буду теоретически выводить, что 2 и 3 годятся. Я просто сошлюсь на опыт тысячи компаний упоминаемых в отчётах различных консалтинговых контор, а количество литературы нисчесть.

G> когда гребешь по собачьи, ногами как лучше дрыгать? Тебе тяжело тут будет получить ответ на такой вопрос — ИМХО большинство плавают брассом, кроллем, в худшем случае — "саженками". Это тебе к студентам надо, только они так и работают. Надо совсем никакого опыта не иметь, чтобы действовать так.

Жаль, что твой опыт ограничивается тем временем, когда студентов учили действовать только по п.1. Сейчас временя изменились. Рекомендую у них же спросить про более эффективные стратегии управления проектами и межкомандными взаимодействиям. Ну да Бог с способами плавания. Жаль, что здесь нет людей, кто пробовал работать в стиле самоорганизующихся команд, которые работают по п.2 и п.3, а отвечают только те, кто огрничивают себя только одним вариантом и несколько агрессивнон настаивают на своей правоте. Похоже это так. Но мир не столь идеален, чтобы одна точка зрения была права
Если попробуешь, жду твоего отзыва здесь. Но всё же хотелось посмотреть, как ты будешь пробовать. Ведь знаешь как бывает — "здесь цель оправдывала средства, а средства обосрали цель" (с) Гарики.

В общем, если у вас есть опыт варианта 2 или 3 — поделитесь, очень интересно узнать.

Повторяю, прошу не обсуждать идеальность варианта 1 как изъезжанной и неэффективной стратегии.

denis_miller
http://AgileConsulting.ru

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

А>Как я понимаю вывод теоретический.
А>Любое начинание можно провалить, но вопрос в другом, как сделать так, чтобы 2 и 3 годились? ы?

Ну что ж, попробуем форму коанов. Специально для тебя сочинил. Держи.

Однажды ученик спросил сенсея/
— Сенсей, что надо, чтобы лом сгодился/
Для подметания плаца?// — Это просто/
Пустая голова, и времени избыток//

А>Да, кстати, я не буду теоретически выводить, что 2 и 3 годятся. Я просто сошлюсь на опыт тысячи компаний упоминаемых в отчётах различных консалтинговых контор, а количество литературы нисчесть.

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

А>Если попробуешь, жду твоего отзыва здесь. Но всё же хотелось посмотреть, как ты будешь пробовать. Ведь знаешь как бывает — "здесь цель оправдывала средства, а средства обосрали цель" (с) Гарики.

Боюсь, я не смогу, у меня не все необходимые ресурсы для этого есть.

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

G>>Поэтому, ни один из вариантов 2 и 3 не годится.

А>Как я понимаю вывод теоретический.

А>Любое начинание можно провалить, но вопрос в другом, как сделать так, чтобы 2 и 3 годились? ы?

Однажды в дверь лачуги, в которой жила одинокая старая женщина, постучался бродячий монах. Шел дождь, он промок, и попросился переночевать. Женщина не могла отказать монаху, однако сообщила ему, что кормить она его не будет.
— Я бедная старая женщина, и у меня нет не то что еды, а вообще ничего, кроме вот этого старого посоха и котелка.
— Что ж, хоть у нас и есть котелок, но из посоха каши не сваришь, — мудро молвил монах, — приготовлюсь ко сну, и с рассветом пойду дальше.
— Отчего ж не из посоха? — хитро спросила женщина, — мне рассказывали про тебя крестьяне из соседней деревни, что ты просветленный, и можешь творить и не такие чудеса. Для Будды это сущая безделица.
— Я уверен, что Ваш посох даст густой наваристый бульон, почтенная хозяйка, и моя вера крепка как никогда, но в нашем монастыре предпочитали варить кашу из риса. Если вы позволите, я вознесу вечернюю молитву — вежливо сказал монах,и поклонился.
— Что ж, вознеси молитву, и пусть Будда ниспошлет нам ужин. Или ты не знаешь нужной молитвы?
— Отчего ж нет, — улыбнулся монах, — попытка не пытка, как говаривал первый из Ста приближенных императора Лина. — старуха взрогнула, вспомнив грозного начальника Тайной Службы Поднебесной, имя которого до сих пор многие боялись произносить в слух, — я думаю, при удачном стечении обстоятельств сегодня Будда вполне способен совершить небольшое чудо. Прошу вас налить в котелок воды, и поставь его на огонь.

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

— Ну как? — жадно срашивала старуха, поглядывая из-за плеча монаха на посох, торчащий из дымящегося котелка.
— Терпение, мудрая хозяйка. Будда практически услышал мою молитву. Надо подсолить.

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

Старуха смотрела на монаха, сидящего с полуулыбкой перед очагом с закрытыми глазами, и ей надоело ждать.
— Ну как? — нетерпеливо выкрикнула старуха, подойдя к сидящему с закрытыми глазами монаху.
— Ну вот, — грустно сказал монах, открыв глаза, — я почти уже заканчивал молитву, но вы меня сбили, и я потерял концентрацию. Теперь даже не знаю... Боюсь, теперь ничего не получится. — монах озадаченно покачал головой.
— И что теперь делать? Каша испорчена? — испугалась старуха.
— Да что каша. Будде очень не нравится, когда прерывают почти законченную молитву. Не быть бы беде...
— Неужели нет никакого способа исправить? — заплакала старуха.
— Ну разве что...- задумчиво сказал монах
— Что?
— Я ничего не гарантирую, но можно попробовать один рискованный способ. Если все пройдет хорошо, то и Будда будет доволен, и мы голодными не останемся.
— Ну, давайте, давайте!
— Несите рис.
— Бегу.
— Много риса.
— Сейчас!
— Быстрее! Бросайте его в котелок, и не отвлекайте меня, я вознесу молитву Будде Амиде, это последнее средство. Да, и еще — выньте оттуда этот посох.