Викилоги

Я попробую не только публиковать впечатления о конференции в реальном времени, но и сделать отчет. Может, он получится write only, как написали о моем отчете по REQ-labs, зато сразу. Тем более, что на 2 недели уезжаю в отпуск.

Итак, SoftwarePeople 2011, день первый.

Общее впечатление — конференция удалась. Она наиболее профессионально организована из всех тех, на которых я был за год. AgileDays-2011 и ADD-2010 мне показались более живые в части общения участников, но профессионализма им не хватает. Правда, они моложе и более дешевые, а профессионализм — он не бесплатен.

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

На конференции попробовали практику пленарных докладов, принятую на зарубежных конференциях. Она очень хороша, когда доклад — достоен. Как у Книберга на Agile Days. Реально достойный пленарный доклад — это очень сложно, потому что он должен быть комбинацией общего смысла, ценного для новых слушателей, но содержать интересные моменты, которые оценят специалисты, свободно владеющие основами. Здесь реально достойный доклад был у Мейдена, но сильно не все на таком уровне абстракции мыслят и восприняли идеи. А вот у Ютты — наоборот, популяризация, ликбез, и там нет новых мыслей и идей, которые бы были интересны специалистам. Более того, с моей точки зрения, у нее вообще не было конкретики, и шли очевидные вещи. Но в перерыве некоторые участники говорили мне, что услышав в докладе в очередной раз известную ранее вещь, они поставили себе пометку — попробовать, сказано было своевременно и подтолкнуло. Доклад Коскелы — посередине между ними. А с докладом Кристенсена по HTML5 получилось совсем неудачно — он воспринимался как технический и, в общем, таким был, и как таковой — был не интересен приличной части участников. А альтернативы не было.

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

После 4 пленарных докладов пошло два трека, и я был на people management, а не technologies. На первом докладе — потому что на техническом треке продолжил Кристенсена, пленарный доклад которого мне сильно не понравился. А потом — были очень креативные докладчики, их было интересно слушать. Возможно, на технической секции доклады тоже были креативные, то область технологий, которых они касались лично мне не слишком интересны, в то время как вопросы организации менеджмента и обучения, о которых говорили на секции менеджмента — интересны.

Отдельные мысли.

• Программисты, ваш собственный feedback на MS или Яндекс — вы просто их меньше ненавидите :) Кто хоть раз написал благодарность за новый функционал? Будьте готовы к тому же от пользователей…
• Как известно, сон разума рождает чудовищ. А коллективный разум бюрократии спит беспробудно. Ergo, стандарты — чудовищны.

Еще из любопытного. С моим докладом в печатной программе опять некоторые проблемы. Не такие, как на Agile Days-2011, где на его место сдублировали информацию по докладу из другого дня и другой секции — здесь всего лишь перепутали фамилию. Ну и бейджика докладчика на регистрации не было. Бейджик оперативно изготовили. Но вообще я бы сказал, что это энтропия бушует, потому как уже второй раз…

Дальше желающие могут посмотреть текущую версию отчета, где есть аннотации по всем сегодняшним докладам, а могут подождать полного отчета.

Причесал и опубликовал свои впечатления о ReqLabs-2011.

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

Опубликовал отчет AgileDays-2011.

Итак, сегодня был второй день тренинга Генриха Книберга. Тоже очень полезный. Фиксирую впечатления тезисами.

Оценка в SP.

• Почему перешли на оценку в SP (story point)? Это — опыт. При такой оценке команда быстрее приходит к согласию, чем при оценке в идеальных днях/часах. И легче калибровать разные команды, передавать им подходы к оценке. А точность — не уменьшается. Для рефлексии о причинах падения скорости SP обычно хватает, если какая-то одна-две задачи несоразмерно выросли.
• Как первоначально получают оценку в SP? На начальной оценке release PBL берут простую и понятную всем историю, которую оценивают, например, в 3 SP или 5 SP. Получается начальный масштаб, от которого дальше пляшут. Когда переходят к оценке спринта и оценивают task, на которые поделили user story, то оценка user story задает некоторый масштаб, пока команды не привыкнут. Но при этом укладываться и подгонять не обязательно, более того у многих есть практики не показывать на планировании спринта оценки user story, во всяком случае сначала — чтобы они не влияли на оценки отдельных задач. Но в случае расхождений — разбираться, вопрос в подробностях задачи или более систематично что-то поплыло.
• Новичкам для калибровки оценок полезно посмотреть оценки предыдущих спринтов до первого планирования. И, опять-таки, оценить задачу как «похожую на ту» легче, чем прикинуть часы.

О SM

• Если кто не разделяет цели — гнать из команды. Движение должно быть сонаправленным. Размер шага (скорость) — не так важны, это тренируется, если человек разделяет цели. Ответственность за фиксацию таких проблем — на SM.
• Про SM, не смотря на много «управляющих» функций по процессу, явный акцент Книберга на самовыдвижении и отсутствии формальной власти. И SM создает условия для самоорганизации, а не управляет. Основне средство — вопрос «А что вы думаете о …» (а не «Давайте решим такую проблему…»).
• Если есть персональные проблемы, например, кто-то систематически не соблюдает стандарт кодирования и на review это вылезает, то задача SM — это выявить. Хотя на ретро об этом могут не говорить. Поговорить до ретро с членами команды, а дальше по обстановки — можно индивидуально, можно на ретро. То, что это в компетенции SM — «по умолчанию».

Процесс в целом

• Практика, когда задачу заранее готовят к выполнению, например, постановка силами той же команды или согласование с заказчиком — распространенная. И хорошая техника — вместе с DoD сделать Definition of Ready — check list, что должно быть у задачи, чтобы ее можно было запускать в спринт. Пример DoR: есть bug, grade S/M/L, есть acceptante test.
• Еще раз сформулировали — кросс-функциональная команда — не значит, что каждый заменяет каждого. Но значит, что нет критичного для процесса человека, и в целом компетенции сбалансированы с потоком задач с учетом отклонений. Техника: матрица деятельность (DB/Java/Design/Test, например) — сотрудник, на пересечении — оценка: пусто/точка/звездочка. Должно быть минимум две звездочки и несколько точек, если нет, то включаем в цели их прокачку у конкретных участников в ходе спринта за счет выполнения задач (например).
• Project Manager в смысле CMMI поделен в SCRUM примерно так:
  • release plan — PO
  • build team — SM
  • архитектура — команда
  • раздача задач — task board
  • набор персонала — за рамками команды
• Надо ограничивать количество задач, находящихся в работе. На это есть мат.модель (правда тут надо смотреть, насколько плюшевая, я готов рассказать подробности). Кратко так. Если дело проходит через несколько стадий, и на каждой имеет некоторую неопределенную трудоемкость (например, от 1 до 3), то с некоторого числа дел в работе мощность выходит на плато, но чем меньше дел в работе — тем быстрее новое дело, вкинутое на вход, появится на выходе. И это — без узкого горла. Если стадий 5, то в работе оптимально 7 начатых дел. Практически это мощное ограничение, особенно с учетом дорогого переключения контекста, и надо этим пользоваться, и того, что люди не могут одновременно держать много целей.
• Working smart more important than working hard. Не рубите деревья бензопилой, а пилите, и вообще не рубите деревья молотком. Используя SCRUM смотрите, насколько подходит.

Две команды на одном продукте.

• Итерации — рекомендуется синхронно, и общий релиз. Иначе сложно с кодом.
• Задачи на итерации делить можно на общей сессии: все задачи висят на доске, команды у них и высказывают желания, а PO — отдает. Как вариант — в каждой команде свой «локальный PO», который берет задачи от общего, так тоже можно.

Разные техники.

• Если у команды период активной поддержки, то можно резервировать на это некоторую долю времени при планировании спринта, а можно — вставлять в SBL задачи типа «фиксируем 10 самых критичных багов».
• Если возник стресс и запарка — найдите силу воли сделать паузу и проанализировать причины.
• Любопытный пример. Kanban of SCRUM, на 60 человек. Большая доска, слева область для подготовки, потом область выполнения — разбита на 4 части для отдельных scrum-команд — задача уходит на их доску, а после спринта — возвращается на общую. Впечатляет. И, возможно, на проектах с несколькими командами типа ГПБ — может быть полезным.
• Где-то всплыл сайт http://userstories.com - всякие тулы и прочее для поддержки. Может, кому интересно — даю ссылку.

Повсеместная работа с карточками меня впечатлила. Техника ведения трека через карточки, которые сначала есть в PBL, потом помещаются на мини-доску Todo/Doing/Done, а потом — в сделанное в рамках спринта может быть полезна на собраниях с повесткой дня. Я, во всяком случае, буду пробовать — если не забуду. Приоритеты — тоже через них. И bring down на планировании — user story на доске, пишем task и вешаем.

Общение с другими.

• Было много участников, успешно применяющих scrum и приехавших. чтобы улучшить опыт. Сам scrum — разный, в том числе в варианте, когда scrum master близок к менеджеру. У других — упор на PO, есть те, у кого он в команде.
• Была практика, когда один SM ведет две команды, и это — его полная загрузка, а задача его — именно наладить процесс. При этом он знает разряды сотрудников и следит за адекватным вкладу разрядом, говоря о проблемах индивидуально. На ретро или эскалируя.
• Планирование 2-недельной итерации вместе с декомпозицией story на task — полдня, 4 часа.
• SCRUM позволяет делать качественные вещи, вопрос в применяемых практиках. Например, может быть жесткое требование, что по каждой user story — пишем acceptant test (пишет или утверждает PO), который развертывают в test case. И все это делает команда.
• Есть практика тех.лидов, тоже поделенных на 2 команды и занимающихся техническими архитектурными вопросами.
• Понимание терминов — разное. Не все считают, что DoD — это общее для всех задач, некоторые используют его скорее как HowToDemo или Acceptante Test. Это надо иметь ввиду, когда общаетесь.

PO в команде, как это у нас. Не отрицается, что это возможно. И ряд участников рассказывали о положительном опыте, они тоже так делают. Почему сам Генрих не делает, мне понятно — у него основной профиль — работа с проблемными проектами, бизнес-часть там разная, соответственно, он ей не занимается, а обеспечивает процесс за счет SM. Поэтому ничего определенного на мой вопрос не сказал. Что касается моих собственных мыслей об этом (с учетом тренинга и прочего), то, думаю, для нас нынешний вариант неизбежен. Потому что заказчик хочет PO у нас, в том числе согласовывающего позиции разных stakeholder’ов с его стороны. А для этого PO должен разбираться в архитектуре и уметь давать оценки, для чего, в общем-то быть в команде. И естественно им оказывается самый сильный член команды. Теоретически это не мешает появиться еще сильному SM, и команде будет только лучше, но практически в этом случае фирма просто сделает две команды — потому что дефицит руководителей проявляется наиболее отчетливо. Однако все это не мешает работе в SM для их роста, как будущих PO, управляющих процессом, или просто сосредоточенных на тех аспектах, на которые PO не хватает.

От тренинга остались 2 книги, напечатанные и на пружинке.

• SCRUM и XP из окопов с автографом, так что только на почитать.
• SCRUM и Kanban: выжимаем максимум.

И авторский checklist по SCRUMу с градацией bottom line/core/recommended/scaling/positive indicators, он есть на его сайте.

Засим — все.

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

В целом — впечатление очень позитивное и я очень рад, что туда пошел. Книберг — играющий тренер, который зарабатывает внедрением SCRUM (и Канбан где уместно) в разных проектах, где оценивают достижения по результату — то есть увеличению скорости разработки или просто спасению проваливающихся проектов. Он говорит, что обычно удается поднять скорость в 2-2.5 раза и по историям и вообще общему впечатлению я склонен ему доверять. Вообще Agile и SCRUM, возникшие как противовес традиционному менеджменту сейчас изменились и превратились в эффективный инструмент тех менеджеров, которые умеют его применять. И дальше я буду тезисно излагать те вещи, которые показались мне важными — потому, что они отражают эти изменения, или потому что я их понял более отчетливо.

Первое — роли и их разделение.

• Product Owner отвечает за продукт, а SCRUM Master — отвечает за процесс в команде. И это бьется очень четко и всеобъемлюще.
• PO — продукт целиком, его интересует общая скорость и другие характеристики. Ответственность включает ROI и экономические составляющие, включая выход и стоимость команды. Но внутрь команды он не смотри, для него команда — целиком, в том числе с точки зрения стоимости.
• SM — ответственность за процесс, внутренняя (coach) и внешняя (коммуникации с внешними людьми). Именно он представляет реальный вклад сотрудников команды, смотрит кому и где надо помочь и это организует. Не административно, а предлагая, но в целом — его scope. В том числе — может организовывать привлечение экспертов, если это повысит производительность — согласовав с PO, так как стоимость команды тоже возрастет.
• Деление PO-SM, помимо прочего, позволяет сделать явным поиск компромисса и вовлечь в процесс команду.
• Новые члены — с учетом мнения команды, интервью все или хотя бы один (это уже после HR, естественно).
• За технические решения отвечает команда. Она может инициировать включение в PBL задач, касающихся архитектуры, рефакторинга и прочего, высказывать мнение по приоритетам, которые следуют из техники реализации. Но принятие решения по приоритетам — за PO, он команду слушает, но решает сам.
• Еще есть менеджер, но он — один на много команд. Его задача — зарплата, контракт с сотрудником и подобные вещи. При этом для обратной связи о вкладе человека, его эффективности — он общается со SM. Плюс — может приходить на DSM и прочие мероприятия, беседовать и так далее — для получения нужной ему информации.
• Полной взаимозаменяемости нет, все люди — разные, с разным опытом и по-разному решают задачи. Разделение труда в команде есть или может быть. Жесткость — зависит от конкретного проекта. PO и/или SM могут стремиться к увеличению опыта членами команды за счет непрофильных задач или наоборот, пренебрегать рисками и ориентироваться на то, чтобы каждый брал профильные задачи. В зависимости от этого меняется стратегия оценки при планировании: могут брать оценку для профильного сотрудника, или среднюю, но команда должна договориться. Плюс, когда спринт не сбалансирован с опытом команды — она это учитывает при оценке.

Планирование и организация.

• Есть release plan (на 8-10 спринтов, 20-30 недель), который в крупном, в feature или user story, и он предварительно, в крупном, оценен командой.
• Поскольку есть оценка — то достижение результата в крупном, скорость реализации — контролируется.
• Но спринт — тоже, естественно, оценивается. Оценка может совпасть или нет, по разным причинам. Может быть особенность задачи, а может быть ситуация, когда команда набрала опыт и научилась точнее оценивать. Во второй ситуации PO может понять о коррекции начальных планов и что-нибудь предпринять по этому поводу.
• Исходные данные для формирования SBL итерации — не только PBL, но и цели: business, learning, risk, technical dependencies.
• Важно ограничивать число тем итерации, переключения контекста — дорого. В идеале — один основная тема и одна фоновая. От итерации к итерации темы можно менять.
• Есть мероприятие — Backlog workshop, проводится каждую неделю, PO + команда, оценивается текущее состояние, могут вноситься изменения.
• Окончательно перешли к оценке в попугаях (story point). В них меняют velocity на спринт, а при планировании из нее получают объем спринта в SP (с учетом фактических человеко-дней). Если есть фиксированные по времени мероприятия, то их надо вычесть из длительности спринта. SP оценки спринта и релиза, в общем случае — разные, коэффициент уточняется по прошедшим спринтам.

Обо всем понемногу.

• Варианты с 2-3 командами на одном продукте с общим кодом и нескольких продуктов для одной команды — вполне рабочие.
• Команды должны быть стабильны. В цифрах это означает устойчивое существование 3-6 месяцев.
• Новая команда по опыту выходит на плато скорости за 1-2 месяца.
• В презентации есть интересные ссылки на исследования психологов — как оценивает команда одну спецификацию в зависимости от разных факторов. Например, от числа листов, полученного увеличением размера шрифта (коэффициент 1.5) или предварительно высказанной оценки стороннего эксперта. Первичку, кто интересуется, думаю, можно найти — ссылка была на Simula research lab, Еstimation …, Oslo 2006.
• «Не бывает низкой скорости, бывают нереалистичные планы». Потому что скорость сама — не поднимется, над этим надо работать.
• Что мотивирует (это известно, но, тем не менее):
  • Autonomy = свобода, самоопределение (да. в рамках, но рамки — они везде есть)
  • Mastery = передовые технологии
  • Purpose = понятные, осмысленные и ценные задачи, которые делаем

Метафоры и образы.

• Водопад как последовательные выстрелы из лука: облако заказа, Req стреляет — получает требования, Designer — получает проект, разработчики — результат. Все как-то промахиваются, естественно — наводят на одно, получают другое. Ну и Заказчик реально хотел не то, что заказал.
• Водопад как стрельба из пушки по движущейся мишени. Agile (SCRUM) как самонаводящаяся на цель ракета вместо этого.

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

Достаточно регулярно, когда читаешь хорошую книжку, то прочитав где-нибудь 1/3, а то и 1/5, и осознав полезность твердо решаешь написать потом в блог и поделиться. А когда прочитал и начал писать пост - как-то не пишется. Осознав это некоторое время назад, я понял, что причина в том, что теряешь остроту восприятия, ценные мысли из книги проникают внутрь, становятся частью тебя и перестают восприниматься как новые. Ты забываешь, что было интересно именно в этой книге. Книгу Дэвида Аллена Getting Things Done (на русском) я прочитал на 2/3 и, возможно, уже утратил ту самую новизну впечатления, но, тем не менее я подумал, что лучше написать сейчас, чем дочитав.

Возвращаюсь к книге. Книга понравилась и вызвала процесс сопоставления и погружения в картину мира. И первая мысль, которая возникла - это о клиентах Аллена, которым он проводил тренинги. В них четко опознавались сенсорики-решающие (SJ) по Майерс-Бриггс, которым важно составление детальных планов и следование им. Планы - рушатся и люди испытывают дискомфорт и стресс. Таких людей - устойчивое большинство среди руководителей (50-60%), а если добавить сюда интуитов-решающих (NJ), для которых данная проблема тоже актуальна, то их будет более 3/4 (75-85%). А планы - они будут рушиться принципиально, потому что руководители имеют дело с людьми, а это - слабо предсказуемая субстанция, область Крайнестана по Талебу. Кстати, за книгу Черный лебедь Талеба - отдельное спасибо Стасу Фомину. Так вот, Аллен учит, показывает способы ведения планов, при которых не возникает стресса и дискомфорта. Потому что ты ведешь списки, а не намечаешь даты. И, что важно, способы очень легкие, простые, без накладных расходов и излишней нагрузки. Такие, что будут комфортно восприняты и второй половиной человечества, воспринимающими (P) - ведь это только среди руководителей решающих (J) - большинство, а так их половина. Таким образом, методы из книги получаются психологически пригодны для каждого, и это - замечательно.

Что касается собственно предлагаемых в книге методов, то они действительно полезны. Я не могу сказать, что они открыли мне глаза или перевернули сознание. Прежде всего потому, что по крупному у меня нет проблем с организацией дел. Отчасти из-за занимаемой позиции, а отчасти - потому что моя нынешняя система весьма похожа на GTD (тут я не хвастаюсь, типа, сам додумался, а объясняю отсутствие проблемы). Однако, в целом под влиянием книги у меня возникло достаточно много частных идей, которым я буду пытаться следовать. Потому что сейчас я пробую эффективно работать по 3-4 принципиально разным направлениям, и широта деятельности способствует потере контекстов. А еще - думаю, это полезно при организации домашних дел и проектов. Конечно, с одной стороны - просматривать список за ужином для выбора темы разговора с женой и детьми - это некоторый перебор, но, с другой - я регулярно по нескольку дней забываю нечто сказать. В последнее время, если мысль приходит на работе, то иногда даже пишу письмо :) Но в метро или когда идешь или гуляешь это недоступно, а мысли - они приходят.

Так что читайте, оно того стоит. Хотя, конечно. есть очень много книг. достойных прочтения, а времени не так много...

Участвуя в различных наших конференциях и смотря их материалы часто думаешь о том, как бы конференция выглядела в идеале. Тут три части: подготовка конференции, формирование секций и докладов, собственно проведение и, возможно более важное - последействие, фиксация результатов конференции. Почему результаты могут быть важнее? Потому что они - долгоиграющая составляющая. А еще, хотя общение - безусловно ценно, результаты при хорошей публикации - доступны широкому кругу лиц. Однако, на на большинстве конференций "спасение утопающих - дело рук самих утопающих": докладчики сами публикуют свои доклады или выкладывают презентации, благо это несложно, и тем дело кончается. Хотя необходимо отметить, что есть продвинутые конференции, например, ЛАФ-2010 или ADD-2010, на которых заботятся о фиксации результатов докладов.

Это была преамбула. Теперь предмет поста. Блуждая, точнее, целенаправленно изучая проторы инета на предмет изучения IT-отрасли на западе наткнулся на весьма интересную конференцию WICSA (Working IEEE/IFIP Conference on Software Architecture). Интересна она тем, что помимо сайтов конференции поддерживается wiki, в которую собираются материалы конференции. И не только статьи участников, каждая сессия - продумывается на предмет целей и вопросов, результаты круглых столов и обсуждений - кратко фиксируются. Пример такой фиксации можно посмотреть здесь по конференции, и здесь по отдельной сессии, и в других статьях. Заметим, что в публикациях - статьи, связный текст, а не презентации. Это определяется форматом конференции, который, в отличии от наших - весьма жесткий, докладчику дается 10 минут на презентацию своей работы. Это, кстати, характерно и для других зарубежных конференций. Зато регламент сессии предусматривает, помимо презентаций докладов, еще дискуссии в группах по этим докладам, с фиксацией результатов.

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

P.S. Кстати, сами материалы тоже интересны, читайте. Я, когда подробнее посмотрю - напишу.

В блоге Левенчука появился очень качественный обзор Стандарты представления требований.

Мне этот обзор позволил достаточно четко сформулировать мысль, откуда берет истоки подход через требования. Он берет начало в тех военных системах, для которых характерно две важных особенности. А именно, заказчиков не слишком интересуют деньги и сроки. Деньги - потому что они чужие. И вообще, если стране надо - что их считать. А сроки - потому что их устанавливает партия и правительство, и - ты же не хочешь чтобы тебя обвинили в саботаже. На западе со сроками было несколько по-другому, но суть не особо меняется. Военные не слишком готовы двигаться по требованиям к системе по этим причинам.

И в этом заключается принципиальное отличие от бизнес-заказчиков. Которые обычно готовы двигаться по требованиям к будущей системе, если это позволяет выиграть по стоимости или, что чаще важнее, по срокам ее внедрения. Более того, заказчик часто конструирует свой новый процесс, и новая система - одна из компонент этой конструкции. Соответственно, она не является жестко зафиксированной, и может меняться в достаточно широких пределах. Что интересно - эти пределы, во-первых, может оценить только заказчик, а, во-вторых, он не может это сделать заранее, потому что при этом чаще всего оценивается компромисс, например, изменения функционала против выигрыша в сроках. Классическая форма требований как набора утверждений не позволяет решать эти задачи, поэтому мы и используем вместо нее модели системы. А требования - лишь местами обосновывают принятые архитектурные решения и важны лишь в этой роли.

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

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

Во-первых, что есть сам процесс стандартизации вокруг методологий — ISO 24744 (metamodel for development methodologies). Это методологи (западные) в очередной раз резвятся. Они разочаровались в объектно-ориентированном подходе и объектно-ориентированных моделях и вместо этого придумали новую концепцию — онтологического моделирования. Объекты их разочаровали тем, что они не могут провести границу между атрибутом класса и другим классом, с которым есть отношения. А еще — атрибуты плохо отражают динамику изменений и вообще жизнь объекта. Поэтому в новой концепции нет атрибутов, равно как и самих объектов, а есть «факты».

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

Вся эта история и текущее состояние прилично освещена. Стандарт непрерывно переписывается, в новых частях — реализуются новые идеи, плохо совместимые со старыми, при этом старые части — не модернизируются, в результате, например, есть две слегка не совпадающие системы базовых типов, примеры не соответствуют описаниям и много другого знакомого и веселого. А еще — в принципе это все должно сопрягаться с ISO 24774 (life cycle management/process description) и ISO 15926 (data integration), но нормального сопряжения нет.

Что касается полезности стандарта — она сравнима с полезностью стандарта XML, или SWIFT или EdiFact. Причем тренд идет именно в эту сторону — описывается внешний формат представления, а семантику накладываешь ты сам, соответственно, всяк желающий представить свои знания в стандарте сможет для начала описать свою форму — произвольную — форму представления, а потом ей следовать. Конечно, стандартизаторы рассчитывают, что будут библиотеки стандартных форм, и никому не надо будет придумывать свою. Но я думаю, что будет как с EdiFact: Гера рассказывал, что для передачи любых документов, например, накладных там есть приличное множество форм, и если ты с каким-то поставщиком хотите обмениваться, то вы, во-первых, должны между собой договориться о конкретной форме, а дальше — каждый должен запросить своего провайдера, и это есть лишнее звено, поэтому на практике этим не пользуются… Левенчук это тоже высказывает, только по-другому, оптимистичнее. Кстати, есть другой пример — SWIFT — тоже множество форматов передачи различной финансовой информации, только когда мы делали работу с ним для Собина, выяснилось, что почему-то используется формат, где содержательных полей не хватает, поэтому многое пишется в структурированном текстовом комментарии, а вовсе не в полях.

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

На самом деле, способ однозначной фиксации — есть. Это — реализация в информационной системе. Если в информационной системе есть понятие «товарная группа» и у товара обязательна ссылка на группу, то все пользователи точно знают, какая группа у конкретного товара. При этом они могут возмущаться неправильным назначениям групп для конкретных товаров, но это уже — второй вопрос. Если они влиятельны, они могут или добиться изменения значения, и товар перейдет в другую группу, или потребовать завести еще один атрибут «товарная группа-2» и назначить его по другому, и тогда у товара будет сразу две группы. Аналогично, если система считает исполнение плана и бонусы по нему, то мы точно знаем, на сколько каждый менеджер исполнил свой план. Опять-таки можно говорить про несправедливость или дебилизм системы, факт измерения плана не изменится. Это, кстати, очень важная роль информационной системы, мне в свое время это на примерах показывал Гера и я проникся.

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

Но все это не отменяет нового тренда — онтологического моделирования, который пытается подвинуть объектно-ориентированный подход. Стоит к нему приcмотреться, вдруг он случайно похож на то, что делаем мы — тогда можно поднимать на флаг. А если нет — понимать, чем отличаемся. И, в любом случае, в основе наверняка лежат хорошие идеи. Только не очень понятно, откуда это извлечь, из стандартов точно не получится…

На просторах инета (и кто бы мог подумать - в msdn) найдена статья по сравнительному анализу различных методов выработки архитектуры - Zachman, TOGAF, FEA, Gartner. Весьма интересно. Во вводной части там отсутствуют слова, но они есть в английском оригинале. Если совсем кратко, то суть в следующем.

1. Zachman framework - на самом деле, это таксономия, то есть классификация области архитектуры предприятия на 30 клеточек (5x6), к которым надо относить артефакты, и утверждается, что в идеале все клеточки должны быть заполнены, а каждый артефакт должен быть в одной клеточке.
2. TOGAF - это стандарт на процедуру, процесс порождения архитектуры. При этом он не гарантирует качественной архитектуры в результате.
3. FEA - порождение бюрократических попыток стандартизовать структуру автоматизации для агенств и подразделений правительства США. В целом - оказалось практически мертворожденным.
4. Gartner Methodology - скорее похож на набор успешных практик, нежели на методологию или стандарт.

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

Зато - выскажу мысли, которые возникли, когда метод, процедуру делают стандартом. Ведь TOGAF, например - именно стандарт от OMG для процесса получения архитектуры. Он, правда, не гарантирует правильность и качество архитектуры. На SECR-2010 мэтр от OMG вещал про важность стандартов и начал от пожара в Балтиморе, когда выяснилось, что шланги разных пожарных машин нельзя состыковать, чтобы получить длинный шланг. Такие стандарты безусловно важны. Но когда стандартизуют процесс, то получают совсем другое - получают правила, регламентную процедуру тужения пожара. А это уже перебор. Безусловно, в тушении пожара существуют правила, которым надо следовать - какие вещества чем тушить и тому подобное. Наверняка существуют также хорошие практики, которые полезно знать. Но все это никоим образом не образует стандарта или регламентной процедуры, место стандартов тут - ограничено, в области шлангов, которые должны сопрягаться...

Кстати, есть другой аналогичный пример - футбол. Там есть свои стандарты - на футбольное поле, на мяч, есть правила игры, это тоже стандарты. Но вот дальше - есть свобода творчества и хорошие практики. И все понимают, что это - нормально. А вот в IT - не останавливаются на этом. В медицине, кстати, тоже, и это печально отзывается на пациентах.

Я тут по наводке Майка Кудряшева (для тех, кто знает) обнаружил такую весьма перспективную штуку - ArchiMate. Это произведение OMG, предназначенное для описания систем в виде диаграмм с единой нотацией. В описании выделяется три уровня - бизнес, приложение и технологии, и дихотомия структуры против поведения. Есть еще две другие оси: внешний и внутренний взгляд на систему и индивидуальное против комплексного, но это менее ясно. Для всего этого сделана единая нотация диаграмм, в некотором смысле - весь UML в одном флаконе, ну - почти весь. Есть примеры использования, которые теперь принято называть best practice. Под это еще подложен язык моделирования, как же без него :) и стандарт-спецификация, но это уже не так интересно, как и в случае с UML. А вот смешанных диаграмм мне лично - не хватало. Понятно, что я все равно рисовал, используя разные символы на одной диаграмме, но теперь это можно будет делать, используя новую прогрессивную нотацию - это стандарт 2008 года :) В общем, рекомендую взять на вооружение.

P.S. Для рисования - есть шаблоны Visio

Наконец, дописал отчет по SECR-2010

Некоторые богатые структуры, обычно связанные с государством, предпочитают автоматизироваться вместо элементарного расширения штата сотрудников, при этом стоимость автоматизации подразделения может быть такова, что за эти деньги можно было бы в полтора-два раза увеличить численность сотрудников на несколько (2-5) лет. При этом существенного расширения обязанностей подразделения — не планируется, равно как и кардинального изменения качества работы, просто работа будет идти «более качественно», «эффективнее» — ну, вы поняли. На первый взгляд, такой подход кажется странным, но на самом деле. у него есть минимум два системных основания.

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

Второе — связано с нынешней оценкой экономического положения предприятия. Сотрудники — это зарплата и другие затраты, то есть — расходы. А вот информационная система — это нематериальные активы, это — гораздо почетнее. Да, каждый год они амортизируются и это — расходы. Но зато сама система — она показывается активах и делает красивый баланс. Таким образом, с точки зрения рейтингов и кредитов информационная система гораздо лучше сотрудников. Да и для чисто бюджетных предприятий актив и автоматизация — лучше расходов на зарплату. Как минимум — идешь в русле прогрессивных технологий.

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

Рутина на работе и борьба с ней — это популярная тема. Тут родились некоторые мысли. Бороться с рутиной, на самом деле — не надо. Ее надо удерживать в заданных границах и это — должно быть естественной частью жизни и работы. В любой работе есть рутинная составляющая и даже люди творческие оценивали ее от 60 до 90 процентов. В ходе работы рутинная составляющая имеет тенденцию увеличиваться — просто потому, что по мере развития творческие задачи становятся рутинными. На эту тему — надо рефлексировать — и поддерживать долю творчества. Через расширение области деятельности, через знакомство с миром вокруг. Конференции и профессиональные тусовки — средство для этого. Можно книги читать или нехарактерные проекты делать — это кому что нравится.

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

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

Пост написан по конкретному кейсу, возникшему в работе, но в принципе - касается достаточно общей ситуации во взаимодействии между людьми. Поэтому и пишу пост.

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

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

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

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

Я, наконец, написал отчет о конференции по Управлению знаниями - размещаю KM Russia-2010 - конференция по Управлению знаниями. На самом деле, то, что я его делал с задержкой - даже полезно - я еще раз перечитал заметки и местами - что-то для себя осознал. В целом, повторюсь, это та область, в которой сейчас надо заниматься. Управление знаниями нацеленно на то, чтобы интеллект группы людей соответствовал не худшему, как в толпе, а лучшему, подтягивая остальных до этого уровня.

Некоторое время назад Лена Сомина подсунула мне книгу Поварнин Искусство спора (UPD: Либрусек заблокирован, есть еще здесь). Отмечу, что картинка на обложке по ссылке совершенно не соответствует духу книги. А книга достаточно подробно классифицирует как методы и приемы ведения спора, так и сами споры по их целям и форме. И написана в начале 20 века, когда споры считались важной частью жизни и велись разнообразно - в узком кругу и публично, устно и письменно. И само слово понималось гораздо шире, чем сейчас - понятие спора включало в себя любые обсуждения с высказыванием разных точек зрения. С тех пор обществе, конечно, шагнуло вперед и публичные споры обогатились еще одним видом - постановочные споры, которые ставят целью убедить публику в некоторой главной мысли, которая остается за кадром, или просто дать разрядку зрителям, и именно такие споры превалируют на нашем ТВ. Но это - суррогат, а что касается собственно обсуждений, то книга остается актуальной и полезной.

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

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

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

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

Из докладов второго дня мне запомнились

• Александр Зинченко - о практике реорганизации в Оборонпроме, применяющихся при этом методах. В том числе - о схематизации в разных видах. Кстати, на вопрос из зала об использованных нотациях был ответ «Не знаю такого слова».
• Дмитрий Песков - о проекте Метавер, описания компетенций. С прицелом выйти на новую систему образования.
• Виктория Солодкая - о эмоциональных аспектах восприятия.

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

А в целом - для меня как для аналитика конференция была профессионально очень полезной.

Какая-то осень очень быстрая. Позапрошлую неделю назад был SECR, а сегодня я на новой конференции по Управлению знаниями. Подробный отчет по SECR по своим заметкам сделать не успел, планировал в выходные напрячься, но получил комок земли в глаз из-под копыт лошади и работать на компе не получилось Поэтому выкладываю что есть SECR-2010 и делюсь впечатлениями первого дня новой конференции.

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

Теперь о конференции. В целом аудитория - очень пестрая. Много науки, HR, маркетинга, нефтянки - что объясняется организаторами и докладчиками - СОМАР (это маркетинг), докладчики от школы бизнеса СПбГУ, и от Лукойла, включая вице-президента. Тема управления знаниями сейчас востребована, говорят всем госкомпаниям вменили в обязанности завести соответствующий штат и заняться управлением своими знаниями :) Ну и тема - на слуху, а в России площадок для обсуждения - нет. Правда у части публики был один актуальный вопрос - как бы сделать так, чтобы менеджмент поверил в управление знаниями и велел им заниматься. Интересно, что один из гуру (Ник Милтон) дал на этот риторический вопрос вполне практический ответ. Хотя, если честно, мне именно такая постановка вопроса напоминает стенания про то, что дети сейчас не читают, и рассуждения о методиках, как бы их к чтению приучить. Я даже испугался, что конференция будет в основном про это. Но нет, были и практические хорошие доклады, интересные тем, у кого дети читают.

Организация - 2 дня, один зал, доклады объединены в 3-часовые блоки, 3 блока в день и это - кошмар. Потому что внутри блока - сидишь, даже размяться нельзя. Но это техника. Теперь про содержание - доклады.

Сегодня было много, пять штук, докладов западных гуру. Из них два - лично, остальные - по web-трансляции. В числе личных докладов - Ник Милтон из Knoco, который работал над постановкой процессов управления знаниями в BP. Кстати, участник из ТНК-BP подтвержил, что эти практики от материнской компании получены и применяются, но до конференции он считал. что они - составная часть управления проектами, и только сейчас узнал, что оказывается это управление знаниями :) Доклады гуру про управление знаниями, на мой взгляд, излагали известное. Правда, во многом потому, что я прочел книжку Учитесь летать. А ее не все читали. Кроме того, послушать гуру, даже когда они излагают известные основы - интересно, это всегда авторский взгляд и детали.

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

Завтра будет продолжение и тоже краткое резюме. А когда-нибудь попозже - большой отзыв про все доклады.

Не так давно прочитал эту книгу, ссылку на которую была в одном из постов Стаса Фомина. Что хочется сказать? С одной стороны, все правильно. Сформулированы те качества, которые нужны лидеру, ведущему свою команду в классическом понимании. Их много, акценты расставлены тоже достаточно верно. И сформулировано достаточно много идеалистических картин с аккуратными оговорками, призванными сопрячь их с реальным миром, избежав эффекта разбитых розовых очков. Так что как пособие программисту, решившему стать менеджером-лидером и готовому ради этого много и целеустремленно трудиться, книга вполне может использоваться.

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

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

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

Примерно так.