Вторая линия, виртуальная

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

Из общения с различными менеджерами SOC, да и процессе собеседований с потенциальными коллегами на операционные линии, сложилась уверенность, что в большинстве SOC есть первая линия аналитиков, действующая практически полностью по алгоритму (~плейбуку) и более-менее проявить инициативу можно только на "второй" линии. При этом мне никто не объяснил, почему, если работа первой линии столь детально алгоритмизирована, ее нельзя полностью автоматизировать, да хоть даже с использованием машобуча. Да, есть определенные различия в квалификации аналитиков, в опыте, но это все равно не повод полностью обламывать крылья, превращая аналитиков SOC в биологические автоматы. Чтобы люди умели принимать решения,  им надо давать возможность принимать решения!

Постоянно раздумывая о проблематике, намеченной выше, мы в конечном счете пришли к выводу, что у нас не будет нескольких операционных линий с жестким назначением аналитиков. Я уже рассказывал (и раньше в этом посте есть ссылка на запись доклада), что "первой линией" в нашем случае является Автоаналитик, являющийся частью конвейера обработки телеметрии, а на команду SOC уже попадает меньше фолсы. Вместо нескольких у нас есть одна операционная линия, среди которой по расписанию выделяется группа, выполняющая функции второй линии. Поскольку состав группы по расписанию меняется каждую неделю, внутри мы ее называем "Виртуальная вторая линия" (Virtual Second Line, VSL). 

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

• Операционка. Эта группа занимается расследованием алертов, как и дежурные, но на нее дежурные могут выполнить эскалацию. При получении такой эскалации данная группа VSL (конкретный аналитик, на кого передали кейс) переключается на работу по эскалации и доводит ее до конца. По завершении работы на эскалации, снова "превращается" в операционного аналитика, расследующего поступающие алерты. Такой режим работы используется при высокой нагрузке команды SOC в целом (большой объем работы, много алертов и/или инцидентов). В более спокойное время, под операционку не выделяется группа из состава VSL, а на эскалации переключаются из других направлений (например, аналитик занимался ретро-хантингом, но, получив эскалацию. переключился на нее, а по окончании - продолжил проверять свои гипотезы)
• Перепроверка. Известно, что мы перепроверяем за Автоаналитиком, но мы перепроверяем и за аналитиками. Приоритезация перепроверки (за кем следует посмотреть побольше) управляется метриками SOC (в частности, на основе конверсии). Типы ошибок аналитиков я привел в докладе на слайде 32, ошибки регулярно обсуждаются, и тенденция к их уменьшению доказывает полезность этого мероприятия.
• Периодический ретро-хантинг. Не все гипотезы реализованы в виде алертов, ввиду своей склонности к ложным срабатываниям. Но это не отменяет необходимость их проверки вручную. Для ретро-хантинга есть несколько критериев. которые позволяют его применять с большей результативностью.
• Фильтрация, адаптация детектирующей логики. Давно писали о разных типах ложных срабатываний, с т.з. этой статьи "контекстные" ложные срабатывания в ответственности операционной группы и на их расследование требуются ресурсы.

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

Сколько нужно операционной безопасности?

 Во второй день SOC Forum выступал с докладом в секции аналитических отчетов. Выкладываю презентацию. Остановлюсь тезисно на основных вещах, которые хотелось донести.

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

2. Есть определенные различия в языке между CISO и Бизнесом, что в результате сводит общение об ИБ к пугалкам, типа: "Вот страшная-страшная угроза, но внедрив решение Х, уровень риска будет снижен до допустимых значений, нужны средства на этот Х". Подход не блещет новизной, и имеет проблемы эффективности и результативности.

3. На основании аналитики DFIR можно объективно оценить ландшафт угроз, а на базе метрик SOC - возможности соей операционной безопасности. Основной контент презентации - это те или иные цифры из аналитической отчетности, и вопросы, которые имеет смысл себе задать для оценки собственной готовности. Фактически, стоимость необходимой безопасности - это разница между возможностями атакующих (на базе фактических инцидентов, а не какого-то теоретического допущения) и способностями SOC (на базе метрик SOC, которые всегда надо считать, в случае любой операционки, иначе невозможно объективно судить о качестве сервиса)

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

4. Для тех, кто уже имеет SOC, а, следовательно, процесс управления инцидентами, статистика результатов расследования собственных инцидентов - отличный материал для понимания ландшафта угроз, а метрики SOC покажут готовы ли Синие управлять релевантными рисками ИБ.

5. Подход на базе метрик SOC, типа MTTD, MTTR представляется более точным и, самое главное, понятным менеджменту, чем, например, более академические модели оценки зрелости SOC, так как в большей степени подвержены субъективизму со стороны оценщика.

Сколько надо SOC? from Sergey Soldatov

SOC на удаленке

Удаленка - отличный способ оценки зрелости ваших процессов!

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

Все постоянно говорят, что SOC - это люди, процессы, технологии, я обычно добавляю, что люди и процессы - первичны, причем я бы их не рассматривал отдельно, банально: если ваша команда насчитывает более 3-х человек, то для их совместной эффективной работы уже нужны процессы, а если у вас круглосуточная дежурная смена - размер вашей команды, минимум, 5 человек.

Припомним уровни зрелости, - с уровня 2 мы имеем требование повторимости, а с уровня 3 уже говорим о стандартизуемости. Повторимость, тем более, стандартность означает, что процесс документирован и доведен до исполнителей, а они его уже далее самостоятельно исполняют и получают предсказуемый результат. Если исполнители плохо исполняют свою роль в процессе, это значит, что либо процесс плохо описан - это фиксируется качеством документации и Базы знаний, либо исполнители не наработали достаточную практику - это исправляется онбордингом и менторством. Для обеспечения качества Базы знаний необходим процесс Управления знаниями (Knowledge management), крайне важный для SOC - это и данные о собираемой телеметрии, типовых сценариях отработки инцидентов (по-хорошему это должна делать правильная IRP), данные об инфраструктуре заказчиков (при этом база прошлых инцидентов\обращений - также отличный источник, но, ввиду того, что по требованиям по защите PII эти данные нельзя хранить долго, какие-то моменты придется вытаскивать в Базу знаний обезличенными), литература для ознакомления и многое другое. Заметка не про Управление знаниями и не про Базу знаний, поэтому напоследок лишь замечу, что для нее очень важна грамотная маркировка (теги, лейблы, summary, оглавление, и т.п., что упрощает навигацию и поиск).

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

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

Уровень 4 модели зрелости требует измеримости. Метрики - неотъемлемая часть любого SOC, - это самый очевидный способ ответить на простые вопросы: насколько эффективно работают аналитики, как часто они ошибаются, какова трудоемкость в зависимости от объемов (уровня SLA, характера и количества систем в мониторинге), какова пропускная способность команды и как необходимо масштабироваться с приходом новых объемов, как изменяется пропускная способность со временем ввиду автоматизации, какова эффективность и результативность детектирующей логики, какова трудоемкость обработки инцидентов в зависимости от уровня критичности и типа атаки, и многое-многое другое. Метрики позволяют постоянно контролировать уровень сервиса и объективно показывать проблемные места.

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

Все перечисленные выше процессы, характеризующие работу зрелого SOC никак не зависят от работы в офисе или удаленно. Понятие еще более размывается в случае распределенных команд, как, например, наша. Для меня, работающего из России, безразличен режим работы моих коллег из Америки: работают ли они из офиса, или из дома, - в любом случае они для меня удаленные сотрудники, наблюдать их "вживую" я не могу, но метрики и статистика их работы позволяют объективно видеть их результаты. Важно оценивать работу именно по результату, удаленка не отнимает эту возможность, и поэтому не влияет на эффективность работы или управления. Скорее даже верно обратное: если наблюдаются сложности с оценкой по результату, то проблема не в режиме работы, а в процессах, и негативное влияние удаленки здесь может быть хорошим индикатором.

Тем не менее, коммуникация - основная проблема удаленной работы. Более 70% процентов информации передается невербальными методами. Здесь, безусловно, есть потеря в передаче некоторой ментальной информации, типа, озабоченности, взволнованности, душевного состояния, а с учетом тяжелой работы аналитиков SOC и потенциальным выгоранием - это крайне важно. Но и здесь можно придумать контроль - увеличение отдельных совещаний 1-на-1 с менеджером, при включенной камере (вообще, включение камеры при синхронных коммуникациях - правило хорошего тона), где можно обсудить не только производственные вопросы, а вообще, все, что угодно, именно в рамках синхронной коммуникации. Подавляющее большинство других коммуникаций можно делать асинхронно. Асинхронная коммуникация - важный фактор эффективной удаленной работы, - это когда мы пишем сообщение и не ожидаем ответ сию же секунду, общение не производится интерактивно. Когда команда распределена географически, асинхронная коммуникация - единственно возможный способ, так как наше рабочее время попадает на период отдыха наших американских и дальневосточных коллег.  Очевидным плюсом асинхронной коммуникации является ее документированность, и, следовательно, возможность ее хранения, последующего анализа и переиспользования, например, для целей обучения. В зрелом SOC документированность коммуникаций внутренних, тем более, внешних - принципиальное требование, так как это - единственный способ сохранения контекста при пересменках аналитиков, а также, для внутренних расследований в случае эскалаций (кто что кому когда написал\посоветовал, какие действия кем были предприняты и т.п.). Именно поэтому для зрелого SOC привычна и естественна асинхронная коммуникация, и это не создает отрицательного эффекта на работу SOC.

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

Ротация кадров и Поддержка перспективных проектов

Одним из критериев глупости является выполнение одних и тех же действий 

с одновременным ожиданием разных результатов

Соотношение прибыли и убытков (P&L) - важнейшая операционная метрика проекта. На ее основе можно приоритезировать проекты и соответственно планировать ресурсы: прибыльные (или перспективные, но о стратегии поговорим в другой раз) надо развивать, убыточные можно подмораживать или полностью закрывать, а высвободившиеся ресурсы перебрасывать на выявленные прибыльные (и\или перспективные) проекты. Люди - важнейший ресурс, они эмоциональны (и это - преимущество, ибо эмоциональный человек способен работать с большей отдачей), поэтому здесь надо быть крайне осторожным, об этом и поговорим.

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

Хорошие эффективные команды - это те, которые работают за идею, полностью отдаваясь делу, как и шедевры не создаются исключительно за деньги. Но P&L проекта показывает необходимость его закрытия, и ресурсы надо перебрасывать на другие направления... В любом случае команду надо расформировывать, объясню почему. Допустим команда закрытого проекта - истинные поросята scrum, действительно болеющие за свой проект, - в этом случае чем более они были преданы своему закрытому проекту, тем сильнее они демотивированы происходящим. Если такую команду сохранить в полном составе, в прошлой оргструктуре и с прошлым менеджментом, то результате общения между собой эта демотивированность будет только культивироваться: "... здесь, у них, все не так, вот у нас было как надо....". В результате, как минимум, от команды точно не будет прежней отдачи (причем ее не будет тем вероятнее, чем сильнее команда была предана прежнему проекту, так как люди эмоциональны, а ведь мы стремимся развивать преданность проекту, и только переживающие за свое дело работники нам нужны, поэтому и последствия будут весьма значительными!), а как максимум, - они полностью загубят проект своим безразличием и ностальгией по прежнему закрытому проекту. Демотивация по причине закрытия проекта не позволит получить результат предполагаемого на основе прежнего опыта качества, поэтому, упомянутая ранее, гипотеза о предсказуемости качества здесь не верна.
Другой крайний случай - проектная команда абсолютные бездельники (может даже, их проект поэтому и закрылся), но в этом случае передача им перспективного направления выглядит очевидной глупостью, а от подобных индивидуумов надо аккуратно избавляться, ибо даже на сборочном конвейере отношение сборщика отражается на изделии, тем более в случае продуктов сложного интеллектуального труда.  Поскольку оба полюса ситуации имеют одинаковый исход, те же последствия имеет и любой промежуточный вариант (ну, например, когда, члены команды не полные бездельники, и\или только "почти" безразличны в отношении нового проекта, или любая другая комбинация).

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

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

Сведем сухой остаток в нехитрую табличку.

-->

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

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

Карьера карьериста

Каждый растет до уровня своей некомпетентности

(Принцип Питера)

Вынужден признаться я не очень хорошо отношусь к карьеристам. Наверно, это неверно, но у меня есть на этот счет предположения и предрассудки, которые попробую изложить в этой заметке.
Прежде чем о чем-то рассуждать, надо синхронизоваться по терминологии. Карьерист в моем понимании - это тот, кто делает все для того, чтобы его позиция изменялась быстро, в результате наблюдался карьерный рост.
Что такое "быстро"? Мой опыт показывает, что придя на новое место (если это, например, не сборочный конвейер, где задачи понятны просто из наблюдения за соседями, а показатели эффективности четко определены), нужно в среднем полгода, чтобы разобраться что к чему. Т.е. только в среднем через полгода новичок научится работать на уровне не нарушения ожиданий от него. Если наша работа имеет творческую составляющую (а любая должна иметь, иначе могла бы выполняться машинами), то возможности по оптимизации/инноваторству также появятся не раньше чем через полгода (пока не будем обсуждать тот сценарий, когда, напротив, требуется свежий взгляд на процессы, лишенный предубеждений, чтобы предложить улучшения). Пойдем дальше: через полгода становится понятно что надо поменять\улучшить. Но на реализацию этих улучшений также нужно время, причем, чем "революционнее" изменения, тем больше требуется времени на их реализацию. Если мы говорим о карьерном продвижении в рамках компании, то логично предположить, что реализуемые инновационные идеи также должны быть заметны в масштабах компании. В зависимости от размеров компании и масштабов изменений, реализация последних может занять от полугода до бесконечности. Теперь мы получили представление о минимальном сроке нахождения в одной позиции, в течение которого можно реализовать что-то, способствующее продвижению как в рамках компании, так и за ее пределами, - это один год. На практике, я бы полагался на срок - два года, минимум, а, беря во внимание, размер компании, предметную область изменений и их масштабность, - этот срок "зарабатывания звезд\орденов\медалей" значительно больше.
При стремительном карьерном росте продолжительной работы в одной позиции не наблюдается, поэтому добиться даже состояния эффективной работы в текущей позиции не всегда удается (выше мы разобрали, что нужно минимум полгода, чтобы просто научиться работать и минимум год, чтобы сделать что-то значимое). Поэтому мы получаем, что из плохих сотрудников службы поддержки пользователей вырастают плохие сисадмины, которые потом становятся плохими архитекторами или начальниками отделов, которые, в свою очередь, становятся плохими директорами департаментов. При этом эффективность сотрудника при столь стремительном карьерном росте весьма невелика: он просто не успевает стать эффективным - нет у него этих год-два, за которые можно научиться работать, понять как изменить[ся] к лучшему и реализовать изменения. Беря во внимание принцип Питера, который в упрощенном виде я вынес с эпиграф, мы получаем, что достигнув карьерных высот, ограничивающихся исключительно возможностями и способностями карьериста, его эффективность также остается нулевой, так как на вершине карьеры не хватает самого главного - компетентности.
Я всегда ценил профессионализм, а он, на мой взгляд, - фактически, опыт, который приобретается за долгие годы работы на одном месте. В любой творческой позиции всегда есть что оптимизировать и нормальные руководители всегда поощряют инициативу, поэтому, для того, чтобы делать что-то выдающееся, совсем не обязательно постоянно сремиться менять круг обязанностей. Постоянное прыгание с позиции на позицию размывает ответственность (этой проблеме стоило бы посветить, как минимум, отдельный абзац, но и так уже много написал, не буду утомлять занудством), в итоге мы получаем кучу проблем, в которых, вроде как, никто и не виноват.
В завершении, хочу отметить, что, конечно же, я не против карьерного роста, в его гармоничном проявлении: реализовал один проект, перешел к другому и т.п., при этом не один из реализованных проектов не загнулся (опять же, по опыту, успешные проекты превращаются в операционную историю, поэтому по завершении проекта ситуация, когда данная сфера деятельности уже не требует внимания, часто не наблюдается; решение - более комплексный подход: реализовать успешно не только проект, но и построить его операционную модель, при которой проект мог бы успешно продолжать жить без нашего с вами внимания, а мы могли бы переключиться на новые задачи ). С каждым проектом - новые знания, навыки, опыт, профессионализм, что позволяет браться за новые проекты, более сложные, чем предыдущие, требующие большей компетентности... Но все начатое нужно доводить до успешного конца, а на это нужно время, чего нет в рамках стремительной карьеры карьериста.

API для гибкой интеграции в коммерческих продуктах

В мягкое и податливое можно так глубоко влезть, что уже никогда не вылезешь

(Ассоциация)

На секции Сбербанка SOC-Форума 2017 единодушным пожеланием пользователей производителям систем ИБ было наличие открытых API с целью максимально гибкой адаптации решения под свои нужды. А нужно ли это? Если вы - не технологическая компания, то, скорее, нет.

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

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

Требования к продуктовому стратегу

О комфорте транспорта лучше спросить пассажиров, а не конструкторов, тем более, не технологов

Изучая спрос на рынке труда обнаружил, что требование №1 к позиции, отвечающей за продуктовую стратегию - огромный опыт разработки (звучать может примерно так "N+ years of experience in software engineering"), Причем, это - повсеместная практика (есть ощущение, что компании Job description списывают друг у друга), и именно поэтому хочется на этом остановиться в заметке.

Основной задачей продуктовой стратегии является придумывание продуктов, которые будут востребованы на рынке. Чтобы этим заниматься нужно очень хорошо понимать целевого потребителя, а самой простой способ этого достичь - быть самому опытным потребителем. А раз так, то, например, для стратега корпоративных продуктов безопасности требованием №1 должен быть опыт работы в корпоративной безопасности, а не "software engineering", так как человек, который всегда занимался разработкой софта и никогда им не пользовался не способен определить потребности пользователя. Да и вообще, разработка ПО или даже разработка алгоритмов\моделей\схем\архитектуры ПО едва ли могут относиться к стратегии, где больше оперируют концепциями и не углубляются в детали проектирования и реализации.

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

Об Ответственности и Возможностях

....тот, кто знает врага и знает себя, не окажется в опасности и в ста сражениях. 

Тот, кто не знает врага, но знает себя, будет то побеждать, то проигрывать. 

Тот, кто не знает ни врага, ни себя, неизбежно будет разбит в каждом сражении.

Сунь-цзы. "Искусство войны"

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

Вроде как бы все очевидно, да? Однако почему в области кибербезопасности мы думаем иначе? Сколько ни был бы профессиональным безопасник или целое подразделение копрбезопасности, почему есть полная уверенность, что он способен противостоять киберармии (APT-кампаниям), и что в его ответственности лежит не допустить компрометации? А разве он имеет возможности, для обеспечения этой ответственности? Он имеет возможность провести глубокую разведку противника (== исследовать группировки, организующие APT-кампании)? Он имеет возможность реверсить применяемые противником инструменты/оружие, чтобы выковыривать оттуда информацию о других инструментах и инфраструктуре и придумывать что с этим можно поделать? Он смотрит на вопрос широко (== видит больше своей сети)? Едва ли он имеет многолетний опыт (== критерий профессионализма) таких исследований (давно ли мы заговорили об целевых атака?), позволяющий ему прогнозировать действия противников и производить безошибочную атрибутику. 

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

Профессионализм vs. Новые идеи

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

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

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

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

В этом последнем моем посте в уходящем году, я хотел бы нам всем пожелать:

• всегда видеть положительные моменты в любой ситуации;
• становиться как можно более широкими и глубокими профессионалами и, вместе с тем, не обрастать инертностью мышления;
• новых идей;
• отсутствия страха, а напротив, повышения интереса и увлеченности, при виде трудностей;
• удачи и Божьей благодати.

Американское руководство по саботажу

Любая палка имеет, как минимум, два конца

Владимир Солдатов

Обычно истина - совокупность противоположных предположений (= Правда где-то посередине)

Из личного опыта

Если вы сложно решаете простое, то сложное вы не решите вовсе

Из личного опыта

Я много троллил глупости и абсурдности, но все еще сомневался в системности бессмыслия, в том, что, в конечном счете, идиотизм имеет цель, хотя и депутат Федоров открытым текстом говорил о бюрократии как об инструменте снижения эффективности, следовательно, - развале, и вот моим сомнениям положил конец документ (дам несколько ссылок: раз, два, три ) - далее по тексту буду называть его "методичка"....

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

Теперь я понял, что вся работа по сбору и анализу "техник" была напрасна - в методичке все они изложены в лучшем виде, систематизированы, даны рекомендации по их применению. То, с чем я наиболее часто сталкивался, и что попало в качестве "техник" в мои записки, изложено в разделе (11) General Interference with Organizations and Productions, поэтому, казалось бы, достаточно ознакомиться до способности уметь узнавать "техники" - это и позволит определять "засланца" на основании методички.

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

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

Функциональная оценка высокотехнологичных продуктов

In theory, theory and practice are the same. In practice, they are not.

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

Наверно самым ужасным последствием функционального тендера является получение предложений, которые объективно невозможно сравнить. Объяснение очевидно: у меня есть практика использования ряда продуктов (если я радел за стандартизацию, то, очевидно, - одного-двух), о них я имею мнение, подтвержденное практическим опытом. Однако, в результате функционального тендера я получаю предложения из всех продуктов, представленных на рынке. Почувствуйте разницу между перечнем продуктов, которые я отшортлистил у себя для использования в компании, очевидно, из соображений стандартизации, и перечнем вообще всех продуктов, представленных на рынке в данном классе. Оставим за кадром устойчивое желание производителя убеждать меня в том, что его продукция соответствует запрашиваемому мною классу продуктов, допустим я покупаю не что-то волшебное, типа DLP или SIEM, где функционал может варьироваться настолько, что вместо первого мне могут продать антиспам или Remote Desktop, а вместо второго - сервер syslog, а выбираю что-то более понятное - СХД, или систему резервного копирования, или, просто, сервер, монтируемый в стойку. И даже в этом случае, выбор на основании заверений производителей, подкрепленный только маркетинговыми буклетами, - чреват супер-негативными последствиями для моего ИТ-комплекса. Ни для кого не секрет, что в приличном ряде случаев, заявленные в спецификациях показатели либо вовсе не выполняются никогда, либо достигаются только в тепличных лабораторных условиях, далеких от боевых, поэтому полагаться на них слепо, с моей точки зрения, - преступная халатность!

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

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

Если взять во внимание все о чем я сейчас и ранее написал, то первоначальная идея получения экономии, породившая функциональные тендеры, по крайней мере в области ИТ и\или ИБ, мне кажется ошибочной. А вам?

Цена неопределенности

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

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

Такое поведение руководства обнажает отсутствие стратегии, и ведет к вполне ощутимым потерям: исполнители вынуждены прорабатывать заведомо несостоятельные варианты, и стоимость проработки этих, стратегически убогих, вариантов и есть цена (стратегической) неопределенности, если хотите, - цена непрофессионализма руководителя. Эти потери Компании на проработку решений, которые впоследствии не были приняты можно подсчитать для каждого руководителя, анализируя его деятельность и, например, учесть при расчете выходного пособия. Мы почему-то все кидаемся на анализ КПЭ (KPI), что по сути своей является полной банальщиной – насколько твой план совпал с твоим фактом. При этом мы почему-то не оглядываемся назад, а напрасно, - ведь смотря на прошлое из настоящего можно вполне объективно судить о ранее принятых решениях; также просто судить и о не принятых решениях, а затраты на их проработку известны. Можно даже ввести метрику для руководителя, отражающую сколько ресурсов (можно выразить и в деньгах) Компании он потратил впустую. По-моему – это обалденный показатель, характеризующий любого принимающего решения, позволяющий оценить его эффективность, профессионализм, лидерство.

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

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

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

Вовлеченность и ответственность

В очередной раз выслушивал от Заказчиков негодование по поводу пробуксовки проекта и о том, что я недостаточно самоотверженно его толкаю через различные бюрократические процедуры. 
К сожалению, в крупной компании существует масса контролеров и кураторов каждому из которых надо объяснить различные аспекты проекта, причем желательно используя его язык, иначе он не поймет и не согласует, и проект накроется медным тазом. Кто-то воскликнет, что при поддержке "нормального (== с хорошим грейдом) менеджмента" ничего никаким тазом не накроется, однако, на практике технически  не получится каждого клерка пушить "нормальным менеджментом": не получится эскалировать на вице-президента проблемы с каждым закупщиком, контролером-закупщиком, финансистом и пр. контролерами-кураторами у которых есть какие-то инструкции и их задача заключается исключительно в требовании от всех соблюдения этих инструкций и трава тут не расти! Я даже опущу как сложно порой нетехническому экономисту объяснить какие-то технические подробности, которые ему непременно следует узнать, прежде чем что-то согласовать и пропустить в дальнейшие круги общения с другими клерками, курирующих-контролирующих другие формальности. Невольно приходит в голову аморальная мысль, что все эти формальности придуманы только с одной целью, чтобы у кураторов-контролеров было что контролировать.... Но не в этом дело, и бороться с этим надо не указывая клеркам что они неправильно работают, занимаются ерундой и т.п. - это вообще нерабочий вариант, а вовлечением в проект.

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

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

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

 

Мотивация Демотивация

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

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

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

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