Саммари

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

amazon, litres

Книга Как управлять интеллектуалами Я, нерды и гики Майкла Лоппа представляет собой сборник выдуманных и остроумных историй из профессиональной деятельности менеджеров по разработке софта. Майкл Лопп проработал более 20 лет в различных инновационных компаниях Кремниевой долины Palantir, Apple, Borland, Slack и др. Всё это время параллельно со своей работой он вел блог под псевдонимом Рэндс. В итоге истории из блога перекочевали в его книгу.

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

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

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

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

Ниже предлагаю мою подборку важных идей из этой книги.

Кстати, в начале этого года я также прочитал

Не менее интересную книгу на похожую тему Сначала нарушьте все правила: Что лучшие в мире менеджеры делают по-другому. Её написали Маркус Бакингемм и Курт Коффман. Мой обзор можно прочитать на Хабре<. Если будет интересно, книгу Бакингема и Коффмана можно купить здесь.

Ваша команда жизнеспособна?

Пройдите простой тест Рэндса, в котором вы можете набрать максимум 11 очков. Если вы набрали менее 8 очков, то у вас есть пара серьезных проблем. Если вы получили от 8 до 10 очков, то у вас опасно низкий уровень коммуникации, стратегии или личностного роста. Чего именно? Это зависит от конкретных очков, которые вы не смогли заработать, пишет Лопп.

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

1. Проводятся ли у вас совещания тет-а-тет? +1 да, 0 нет
   
   Цель тет-а-тета провести что-то вроде беседы о сути деятельности команды.
   
   Тет-а-тет это еженедельное инвестирование в сотрудников, которые составляют вашу команду. Если ваши тет-а-теты нерегулярны или вы не считаете их особо ценными, то вы укрепляете миф о том, что руководители недоступны.
2. Проводятся ли у вас общекомандные совещания? +1 да, 0 нет
   
   Общекомандные совещания должны обладать такими же двумя основными признаками, что и тет-а-теты, а именно систематичностью и фокусом на сути деятельности команды, а не на текущем положении дел.
   
   На таких совещаниях вы должны решать проблемы и бороться со сплетнями и ложной информацией, которая может возникать в условиях информационного голода.
3. Есть ли у вас отчеты по статусу проекта? +1 да, 0 нет
   
   Автор считает, что письменные отчеты о статусе проектов это зло. Дело в том, что команда в своей работе так или иначе использует уже какие-то инструменты и реальный статус уже отражен в них. Отслеживание работы это не задача команды, а задача менеджера. Вместо статусов автор предлагает руководителю на совместных встречах обсуждать статус проекта, а потом записывать его, если это нужно. Это будет более эффективно, т.к. если вопросы возникнут, их тут же можно будет обсудить.
   
   Отчеты о статусах проектов обычно появляются, когда руководитель чувствует, что он отдаляется от некоей части организации и верит, что сможет избавиться от этого ощущения, заставив своих сотрудников тщательно документировать свою рабочую деятельность. Но это не поможет! Девяносто процентов людей, которые обязаны направлять отчеты о статусе проектов по электронной почте, думают об одном и том же: ''Мой руководитель не ценит мое время''.
4. Можете ли вы сказать своему боссу нет? +1 да, 0 нет
   
   Когда ваш босс открывает рот и говорит какую-нибудь откровенную глупость, то ваше святое контрактное обязательство перед акционерами компании, в которой вы работаете, поднять руку и возразить: ''Вы говорите глупости! И вот почему''
   
   Если вы этого сделать не можете, то в вашей компании что-то идет не так.
5. Можете ли вы объяснить стратегию вашей компании незнакомцу? +1 да, 0 нет
6. Можете ли вы рассказать о текущем состоянии дел в вашей компании? +1 да, 0 нет
   
   Вы постоянно должны работать над составлением общей картины, отображающей состояние вашей компании. Хотя бы на уровне она скорее растет или умирает.
7. Ваши руководители регулярно выступают перед всеми сотрудниками и рассказывают о том, что они думают? Верите ли вы им? +1 да, 0 нет
   
   Когда команда растет, требуются более серьезные инвестиции в организацию корпоративной коммуникации, особенно если речь идет о сотрудниках низшего звена. Директора, лидеры и руководители это люди, которые обычно активно вовлечены во все основные события в компании, потому что в этом, собственно, и состоит их работа. Но помимо этого, их работа состоит в том, чтобы эффективно организовать обмен информацией.
8. Вы знаете, что хотите делать дальше? +1 да, 0 нет. Бонусное очко: А ваш босс знает? +1 да, 0 нет.
   
   В здоровой организации информация должна курсировать эффективно и беспрепятственно, но это еще не всё. Важно и то, как люди ее получают, транслируют и обрабатывают.
   
   Вы можете получать важную информацию для вашей карьеры и должны уметь ею воспользоваться. Если у вас есть карьерный план, то это сделать будет гораздо проще.
   
   Бонусное очко это если ваш босс знает о вашем карьерном плане. Он имеет больший доступ к корпоративной информации и может сильно помочь.
9. У вас есть время на стратегическую деятельность? +1 да, 0 нет.
   
   Вы не просто должны представлять свои карьерные цели, но и реально двигаться в их сторону. Для этого у вас должно быть выделено время для стратегической деятельности.
10. Вы активно боретесь с сарафанным радио? +1 да, 0 нет.
    
    В отсутствии информации люди начинают придумывать конспирологические теории. С этим нужно бороться, качественно распространяя информацию на тет-а-тетах и на других совещаниях. Еще способ это относиться к сплетням септически. Просто скажите сплетнику: Ты действительно веришь в этот бред?

Почему инженеры не любят процессы?

Источник

Все инженеры ненавидят процессы. Но почему? На самом деле инженеры это структурированные люди, которые обожают порядок. На самом деле инженеры ненавидят не процессы, а если никто не может объяснить, почему процессы именно такие.

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

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

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

Не нужно просто слепо выполнять процесс. Всегда нужно попытаться понять контекст или предусловия, при которых этот процесс применим. К сожалению, это бывает сложно, но это надо пытаться делать.

Должен ли руководитель разрабатывать софт?

Автор задается вопросом должен ли руководитель продолжать писать код. Когда-то автор думал, что нет, так как он считал, что если руководитель продолжает писать код, то это не позволяет ему доверять и делегировать своим разработчикам. Впоследствии он радикально изменил свое мнение. Теперь он считает, что руководителю писать код нужно обязательно.

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

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

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

Зачем нужно учиться на своем опыте?

Источник

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

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

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

По Лоппу: Стресс это убийца креативности. Когда вы находитесь в состоянии стресса, у вас включается режим реагирования и выживания. В стрессе вы мыслите так: ''Как мне выжить?'', а вовсе не так: ''Что может стать элегантным решением этой проблемы?'' Элегантное решение проблемы требует наступательных действий и чем ниже уровень стресса, тем эффективнее ваше наступление.

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

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

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

Об оценке производительности

Как делать ежегодную оценку производительности? Самое плохое если вы раз в год пытаетесь вспомнить, что же такого делал сотрудник и наспех делаете ему оценку. В этом случае ваша оценка будет определяться всего лишь последними несколькими неделями/месяцами работы сотрудника, и она будет, мягко говоря, необъективна. Лучше всего, если вы будете каждый месяц записывать ваши впечатления о прошедшем периоде.

Автор предлагает использовать модель оценки сотрудников Skill vs. Will. На шкале Skill откладывается уровень навыков, на шкале Will уровень намерений.

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

Когда вы распишете кого-нибудь с помощью графика Skill vs Will, вы начнете понимать, в чем именно состоит ваша работа на полную ставку в постоянном и неуклонном продвижении своих сотрудников в верхний правый квадрат. Высокий уровень навыков (я хорош в том, что я делаю) и высокий уровень намерений (мне нравится то, что я делаю).

Автор предлагает разделять обратную связь по положению на графике Skill vs. Will от обсуждения повышения з/п или бонусов, особенно, если обратная связь негативная, в этом случае сотрудник не сможет воспринять ее в одновременном обсуждении с денежными вопросами.

Источник

Описание пограничных ситуаций на графике:

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

О важности коммуникаций

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

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

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

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

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

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

Ваша команда сама расскажет вам о своих потребностях!. Лопп рекомендует в ситуациях, когда он не чувствует отклика или понимания, просто замолкать команда сама расскажет, что ей нужно.

Зачем нужны тет-а-теты? Как их проводить?

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

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

Основные правила тет-а-тетов:

• тет-а-теты должны быть регулярными и в определенные дни (автор считает, что тет-а-теты необходимо проводить еженедельно);
• никогда не отменяйте тет-а-теты! Каждый раз, когда вы забиваете на тет-а-тет с человеком, которым руководите, он думает: Значит, я не так важен;
• отведите на тет-а-тет не менее 30 минут.

Автор определил следующие типы тет-а-тетов: сводка текущих событий (все в порядке), жалоба (что-то случилось), катастрофа.

Как правило тип тет-а-тета становится понятен сразу после ответа на вопрос открывашку Как дела?.

Рекомендации для сводки текущих событий:

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

Рекомендации для жалобы

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

Рекомендации для катастрофы

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

Как сделать более эффективным совещания?

Автор ненавидит совещания. Для того, чтобы сделать эффективными совещания для себя, автор предлагает технику Распознавание повестки дня.

Говоря простым языком, распознавание повестки дня это способность выявлять следующее.

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

Предлагаемая последовательность действий, если вы попали на совещание.

1. Идентифицируйте тип совещания. Автор выделяет информационные и конфликтно-разрешительные совещания.
2. Классифицируйте участников. Первичная классификация игроки и пешки. Самое простое различие между ними состоит в том, что только игроки хотят, чтобы совещание имело какой-то итог.
3. Идентифицируйте игроков. Если вы не можете идентифицировать ни одного игрока бегите с такого совещания.
4. Идентифицируйте про и контра. Про это игроки, которые в данный момент находятся в выигрыше. Они получают то, чего хотят, и не настроены вести переговоры. Контра это явно те, кто кричит и возмущается. Вероятнее всего, это именно те люди, громкие крики которых привели к организации этого совещания.
5. Выявите проблему. Скорее всего проблему надо искать у контр.
6. Дайте контрам то, чего они хотят. Контрам нужно решение проблемы или план такой, чтобы они почувствовали прогресс.
7. Снова выявите проблему. Если проблем слишком много уходите. Тот, кто беспокоится больше других, должен дистиллировать всё сказанное в связные формулировки, чтобы про и контра спорили об одном и том же.

Об организационной структуре

Автор считает, что в нашем тысячелетии самый эффективный способ создания здоровой команды это максимальная горизонтальность. Он выделяет всего три типа лидерства:

1. Лидеры, например, руководитель команды, тимлид;
2. Лидеры Лидеров, например, старший менеджер, отвечающий за несколько команд;
3. Директора.

Лидеры максимально сфокусированы на своих командах. Лидер тактик.

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

По мнению Лоппа, Лидеры Лидеров в действительности управляют компанией.

Лидер Лидеров совмещает как тактические, так и стратегические активности.

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

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

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

Нужно другое решение этой проблемы карьерного роста.

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

У автора нет окончательного решения, но он предлагает внедрить в компаниях ДНК-совещания (ДНК от англ. DNA, Design & Architecture). На это совещание приглашаются только самые крутые инженерные головы, и на этом совещании решаются важные технические и архитектурные проблемы. Участие в таком совещании должно быть очень почетно. Чистые менеджеры не приглашаются на такие совещания, так как ДНК-совещание подразумевает идеально культивированное техническое лидерство.

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

О типажах сотрудников

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

Стабильные инженеры это инженеры, которые:

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

Взрывоопасные инженеры это инженеры, которые:

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

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

Автор также выделяет следующие типажи сотрудников инкременталисты и комплеционисты.

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

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

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

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

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

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

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

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

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

Бывают двустволки органические механики и механические органики.

Заключение

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

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

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

Как понять, что ваш продукт не будет успешен, не затрачивая при этом значительные материальные ресурсы и не теряя годы на его разработку? Вы наверняка слышали о бережливом стартапе как удачном способе реализовать слабую (читай не очень обоснованную), но перспективную идею. Концепция бережливого стартапа, lean startup это когда вы запускаете собственную модель бизнеса без огромных трат на старте

В этом посте расскажем, как мы в компании Автомакон применяем успешные практики из Lean Startup (несмотря на то, что многие наши проекты вполне сформировались и устоялись), с какими проблемами сталкиваемся и как с ними справляемся.

У ВкусВилл есть книжный клуб для сотрудников, в рамках которого часто обсуждаются те или иные книги. И нас часто приглашают поучаствовать в нем. На одном из таких собраний обсуждалась книга Эрика Риса Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.



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

Работа по классике

С самого начала проекта Тилси началось выстраивание платформы с космическими требованиями:

• Высоконагруженная система;
• Всё пишем на Golang;
• Создание теоретических бизнес-процессов.

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

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

Работа по линам

Вот что сделали:

• Отказались от всего, что сделали ранее. На коленке сделали в CMS самые примитивные, но работающие процессы. За месяц сделали MVP и запустили для проверки гипотез и начали получать первых пользователей: магазины, поставщики, конечные покупатели.
• Затем пытались тестировать разные гипотезы. Протестировали много чего, но гипотезу ценности не подтвердили. Пытались сделать вираж, но все же в определенный момент приняли решение закрыть проект в текущем виде.
• Итого нам удалось потратить не так много денег и времени (порядка 1 млн. и 2 месяца), а главное вовремя понять, что проект не взлетит, и сфокусироваться на другом.

Кроме этого мы использовали подход Lean Startup в Зеленой линии, совместном проекте ВкусВилла и Перекрестка по запуску новой линейки натуральных молочных продуктов с ультракоротким сроком годности. Он так и назывался, Маркет. Зеленая Линия В рамках проекта мы протестировали много гипотез. Подтвержденные гипотезы ценности позволили сэкономить кучу денег и времени, а неподтвержденные не тратить ресурсы на тупиковые направления.

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

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

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

На чём стоит Lean Startup

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

Поэтому Дешево, быстро, хорошо оказывается штукой, которую можно написать в тексте, но нельзя увидеть в работе. Если у вас большая компания, у которой более чем достаточно ресурсов, причем как материальных, так и временных, то для вас отлично подойдет триада Тёмы Лебедева, которую мы бы процитировали, но нас за нее забанят.
А если у вас стартап в принципе, или же стартапная разработка продуктов внутри большой компании, то бюджет и время надо считать.

Не дешево, а экономно

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

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

Суть подхода

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

Это важно, ведь это касается интереса людей к продукту, его нужности, как следствие спроса. Вы можете сделать великолепный по своим ТТХ смартфон. Открыть кофейню с лучшим кофе в мире.

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

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

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

Соответствует ли продукт нуждам потребителей?

На самом деле он нужен, или команда убеждает себя в этом и делает неправильные выводы? Тут нужно подходить к делу максимально объективно, абстрагируясь от своего отношения к продукту.

Как потребители решали подобную проблему раньше?

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

Какие издержки потребители сегодня несут из-за этой проблемы?

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

Нужно ли адаптировать или изменить ваш продукт?

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

Если точно всё ОК, то переходим к пятому вопросу.

Готовы ли вы масштабировать его?

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

Осилит ли компания масштабирование? Хватит ли времени и денег, рук разработчиков, потянет ли инфраструктура возросшую нагрузку?

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

Непрерывность развития

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

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

Поэтому тут необходимы непрерывность инноваций и постоянное совершенствование. Собственно, все как в жизни.

Гибкость

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

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

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

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

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

А руль дает вам возможность подстроиться под то, что уже точно случилось

Погодите, это же постоянный MVP

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

Это и есть бережливость.

Что еще важно

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

Работайте с обратной связью. Это постоянный статус вашего проекта.

Эксперименты. Не бойтесь проводить их снова и снова. Посмотрите, сколько больших компаний вокруг используют A\B-тестирование. Вспомните, сколько разных версий интерфейса Facebook прямо сейчас показывается различным сегментам пользователей. Это все эксперименты, это все проверки тех или иных гипотез.

Это постоянные инновации, которые обеспечивают постоянный прогресс.

Итого

Настоятельно рекомендуем обратить внимание на концепцию Lean Startup. Из IT вы или нет, большие у вас бюджеты или собственные сбережения на продукт, методология пригодится.

Вот наши выводы от использования подхода на практике:

• Лины работают. И работают хорошо.
• Но лины не панацея, подход не поможет поднять любой проект. Скорее, наоборот концепция поможет быстрее закрыть тупиковый проект, а не жить в иллюзии, что он клёвый. Что тоже очень полезно.
• Ограниченное трактование линов может завести в другую крайность все процессы будут строиться на MVP. Зачем рефакторить, ведь все и так работает. Но есть большой риск, что в определенный момент это все может рухнуть. Поэтому использовать лины надо грамотно. Запустили MVP, подтвердили гипотезу ценности, дальше проанализировали надо ли делать нормальный продукт.

Кстати, мы сейчас активно расширяем команду, которая активно применяет Lean-подход. Вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт

Будем рады ответить на ваши вопросы.

Несмотря на то, что описание данных с помощью графов практикуется еще с позапрошлого столетия, использование их в решении повседневных задач по анализу данных лишь набирает обороты. Хотя основное внимание уделяется, как водится, графовым эмбеддингам и сверточным сетям, маленькие шаги предпринимаются и в алгоритмах по поиску аномалий или антифроде. Основная обзорная статья, на которую ссылается большинство специалистов в своих в докладах и публикациях, Graph based anomaly detection and description: a survey от авторов Leman Akoglu, Hanghang Tong, Danai Koutra (Akoglu, 2015). Мы в CleverDATA решили рассказать Хабру об этом практически единственном материале по теме и предлагаем вашему вниманию его саммари.

Первый граф Российского царства Борис Петрович Шереметев. Аномалий не обнаружено.

Во вступлении авторы отвечают на вопрос: В чем же преимущества поиска аномалий с использованием теории графов?:

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

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

Таким образом, перспективность использования теории графов для поиска аномалий обоснована. Перейдем к описанию самих методов.

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

Поиск аномалий в графах без свойств, приписанных вершинам и/или ребрам

Для простых графов выделяют три направления структурных подходов: поиск аномалий на основе признаков узлов, диад узлов, триад, эгонетов (egonet), на основе сообществ и на основе метрик близости (proximity): pagerank, personalized pagerank, simrank. При этом предлагается для решения задачи поиска аномалий на графе использовать обычные алгоритмы (например, Isolation Forest, или если есть разметка, то стандартные классификаторы), но на основе графовых признаков.

Пример Эгонета

Отдельно описывается подход с признаками эгонетов подграфов, включающих целевой узел, и его ближайших соседей. Авторы, ссылаясь на статью 2010 года (Akoglu, 2010) (в статье будет очень много таких ссылок, гиперссылки на некоторые я дал в тексте, но более подробные ссылки, например, с указанием страниц, вы найдёте в списке литературы в конце этой статьи), предлагают искать характерные для графа паттерны эгонетов с выраженной зависимостью между характеристиками, а эгонеты, не соответствующие этим паттернам, считать аномальными, и, таким образом, считать аномальными их центральные узлы. Поскольку всевозможных показателей на основе эгонетов может быть много, авторы в этой же статье обосновывают свой выбор подгруппы таких показателей, наилучшим образом отражающие свойства графа (например, число треугольников, общий вес ребер). Расстояние между паттернами и между эгонетом и паттерном предлагается измерять, как отклонение характеристики этого эгонета от характерной зависимости, соответствующей паттерну.

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

Также авторы описывают и другие подходы:

• кластеризация узлов на основании сходства их ближайшего окружения; предлагается реорганизация матрицы смежности для получения более плотных и менее плотных блоков (Chakrabarti 2004; Rissanen, 1999);
• матричная факторизация; предлагается аналог Non-negative matrix factorization (NMF) (Tong and Lin 2011).

Поиск аномалий в графах с узлами и/или ребрами, обладающими свойствами

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

Также рассматривается проблема наличия у узлов множества характеристик различных модальностей. Предлагается всем условно нормальным значениям ставить в соответствие единственное значение категориальной переменной, а для выбросов ставить в соответствие значение единственного показателя аномальности, например, на основании метрических методов обнаружения аномалий: kNN, LOF.

Также перечисляются и другие возможности: SAX (Symbolic Aggregate approXimation) (Lin et al., 2003), MDL-binning (Minimum description length) (Kontkanen and Myllymki, 2007) и дискретизация по минимуму энтропии (Fayyad and Irani, 1993). Авторы этой статьи (Eberlie and Holder, 2007) иначе подходят к определению аномалии в графовых данных, считая аномальными те подграфы, которые похожи по отношению к условно нормальному графу в определенных пределах. Такой подход авторы обосновывают тем, что самые успешные мошенники будут стараться максимально подражать реальности. Они также предлагают учитывать стоимость модификации показателя и формулируют показатели аномальности с учетом этой стоимости (чем меньше стоимость, тем более аномальным является показатель).

Поиск аномалий для графов с атрибутированными узлами рассматривается и в основанный на поиске сообществ парадигме. Предлагается подразделять графы на сообщества. Далее, в рамках каждого сообщества, искать аномалии по атрибутам. Например, курильщик в команде по бейcболу. Курильщик не является аномалией для общества в целом, но в своем сообществе является. Другой подход (Mller, 2013) основывается на выборе пользователем (аналитиком) набора узлов, для которых далее определяется подпространство показателей, схожих для них. А аномалиями в таком подходе являются узлы, которые структурно принадлежат к кластеру этих узлов, но в выбранном подпространстве показателей находятся далеко от них.

Отдельно рассматриваются методы semi-supervised, в предположении, что какая-то часть узлов размечена как нормальные и аномальные, а остальные узлы можно классифицировать, используя соответствующие методики, а в самом простом случае им можно присваивать метки соседних с ними узлов. Перечисляются основные подходы: iterative classification algorithm, gibbs sampling (подробнее про эти подходы пишут здесь), loopy belief propagation, weighted-vote relational network classifier.

Поиск аномалий в динамическом графе

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

1. выделяется некоторое сжатие или интегральная характеристика каждого статического графа;
2. вычисляется расстояние последовательно идущих графов;
3. аномальными принимаются те графы, для которых расстояние выше порога.

В качестве мер расстояния предлагаются:

• maximum common subgraph (MCS) distance;
• error correcting graph matching distance, то есть расстояние, измеряющее, сколько шагов нужно сделать, чтобы из одного графа сделать другой;
• graph edit distance (GED), то же, что и предыдущее, но возможны лишь топологические изменения;
• расстояния между матрицами смежности (например, Хэмминга);
• различные расстояния на основе весов ребер;
• расстояния между спектральным представлением графов (распределениями собственных векторов);
• описывается также и более экзотическая мера: эвклидово расстояние между перроновскими собственными векторами графа.

В статье от Bunke et al. (2006) авторы предлагают считать расстояние не только между последовательно идущими графами, но вообще между всеми графами в последовательности, и потом применять многомерное шкалирование, переводя графы в двумерное пространство. Далее выбросы ищутся в этом двумерном пространстве.

Описан также следующий способ работы с динамическими графами (Box and Jenkins, 1990): графу ставится в соответствие некое число (расчетный показатель) и далее применяются стандартные методы поиска аномалий во временных рядах. Например, расхождения с моделью ARIMA.

В статье Akoglu and Faloutsos (2010) авторы осуществляют следующую последовательность операций:

1. выделяют для каждого узла графа для каждого момента времени F-признаков;
2. для каждого признака с временным окном W считают корреляционные матрицы между узлами;
3. выделяют собственные векторы и далее рассматривают лишь первый собственный вектор;
4. параллельно выделяют типичное поведение собственных векторов корреляционной матрицы (для этого делается еще одно SVD-разложение над матрицей изменения всех собственных векторов корреляционной матрицы во времени);
5. сравнивают (через косинусное произведение) с реальным поведением этого вектора, получая таким образом показатель аномальности рассматриваемого временного окна.

Матричное разложение используется также и в статье Rossi (2013):

1. аналогично предыдущему подходу выделяется по F-признаков на узел на каждый временной промежуток;
2. для каждого временного промежутка производится NMF-разложение, при котором каждому узлу ставится в соответствие роль;
3. далее мониторится изменение ролей каждого узла.

Матричное разложение для интерпретации результатов

Отдельно хочется отметить приведенные авторами методы аппроксимации матриц альтернативные по отношению к давно известным SVD, PCA, NMF: CUR (Drineas et al., 2006), CMD (Sun et al. 2007b) и Colibri (Tong et al. 2008). Основным преимуществом этих методов является интерпретируемость, поскольку в отличии от SVD, переводящего точки в другое пространство, эти методы оставляют пространство нетронутым, лишь сэмплируя точки из него. Наиболее простым из них является CUR, у которого авторы отмечают два недостатка: в нем точки выбираются из матрицы с повторением. В CMD удается убрать этот недостаток, однако как и в CUR, этому методу присуща линейная избыточность, которую удается избежать авторам алгоритма Colibri. Хотя методы были изобретены именно для решения задач поиска аномалий в графах методами матричной аппроксимации, их использование может быть перспективным и для других задач.

В задачах, обсуждаемых в этом обзоре, эти подходы применяются по следующему принципу: производится аппроксимация и оценивается, насколько различные столбцы/строки отличаются у аппроксимированной матрицы от изначальной. Также авторы отмечают метод NrMF (Tong and Lin 2011), модификация NMF, в котором ограничение на неотрицательность накладывается на матрицу остатков R, поскольку именно в ней сосредоточена основная информация по отличию апроксимации от изначальной матрицы, а отрицательные значения в таком случае было бы сложно интерпретировать. Тем не менее, до конца не ясно, почему нельзя аналогичным образом использовать SVD для декомпозиции, последующей реконструкции и последующим расчетом отличия от изначальной матрицы.

Определение узлов, связывающих аномальные

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

1. Определение связного подграфа (connection subgraph) (Faloutsos et al., 2004). Проблему предлагается решать в терминах электротехники, присваивая одному узлу положительный потенциал, а другим узлам нулевой, и смотреть, как будет течь ток между ними, если присвоить ребрам некое сопротивление.
2. Center-Piece Subgraphs (CePS) (Tong and Faloutsos, 2006). В отличие от предыдущего метода предпринимается попытка выделить лишь k-узлов из всех аномальных, поскольку совершенно не обязательно все узлы заданы. При этом k необходимо задавать.
3. Dot2Dot (Akoglu et al., 2013b; Chau et al., 2012). В этом подходе авторы решают задачу группировки выбранных узлов и уже далее выделяют узлы, их связывающие.

Примеры поиска аномалий в различных сферах

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

Телекоммуникации. Целью являются люди, пользующиеся услугами бесплатно. Cortes et al. (2002) искали подграфы, тесно связанные с ключевым узлом по параметрам числа и продолжительности звонков. Наблюдения, которые авторы обнаружили: фродовые аккаунты оказались связаны, то есть нарушители или сами звонили друг другу, или звонили на одни и те же телефоны. Второе наблюдение нарушителей можно обнаружить по схожести их подграфов, определенных предложенным образом.

Онлайн-аукцион. Нарушители создают себе фейковые аккаунты и накручивают им рейтинги. Их не получается отследить по обычным агрегатным показателям, но возможно увидеть по графу. Аккаунты нарушителей более связаны с фейковыми аккаунтами, чем с хорошими аккаунтами. Фейки связаны примерно в равной степени с аккаунтами нарушителей и с хорошими. Последние в основном связаны с подобными себе аккаунтами. Pandit et al. (2007) решают эту задачу через приведение к реляционным марковским сетям (relational markov networks) и далее классифицируют узлы через Loopy Belief Propagation (метки класса итеративно распространяются по графу).

Транзакции. McGlohon et al. (2009) решают эту задачу через реляционную (relational) классификацию в предположении, что нарушители будут близко расположены друг к другу. То есть аналогично подходу из предыдущего примера.

Брокеры, которые жульничают с ценными бумагами. Здесь Neville et al. (2005) анализируют мультимодальный граф, выделяя подграфы, включающие человека под подозрением, его коллег, фирмы, с которыми он связан и т. п. Они рассчитывают агрегированные атрибуты и приписывают их центральному узлу. Далее используют реляционные вероятностные деревья (relational probability trees (Neville et al. 2003)) для реляционной классификации.

Поиск фейковых постов на форумах, дающих заведомо ложную информацию. Авторы описывают несколько подходов, с использованием признакового описания, анализа текста и графовых методов. Графовые методы, использованные Wang et al. (2011a), применялись для ситуации, когда в задаче присутствуют обзоры какого-то товара. В предложенном ими алгоритме предлагалось присваивать рецензентам показатели степени доверия им, их обзорам достоверности и товарам показатели надежности. Все эти показатели взаимосвязаны. Так, насколько можно доверять рецензенту, зависит от того, насколько у него достоверные обзоры. Надежность товаров зависит от степени доверия рецензентам, которые его описывают, а достоверность обзоров зависит от надежности товара, по которым они пишутся, и от доверия их авторам. Предлагаемый алгоритм сначала их случайно инициализирует, а затем итеративно улучшает оценку.

Трейдинг. Мошенники сначала совершают большое число транзакций друг с другом по какому-то типу акций, увеличивая их привлекательность, а затем, когда акции повышаются в цене, распродают их другим трейдерам. Оба этих последовательных инцидента можно отследить по графовым данным. В первом случае будет выделяться подграф, где нет никаких внешних транзакций (именуется черная дыра), а через временной промежуток этот же подграф преобразуется к подграфу, в котором сильно преобладают транзакции из подграфа в другую часть графа (именуется вулкан). Авторы ссылаются на работу Li et al. (2010).

Веб-ресурсы. Одним из первых подходов для борьбы с плохими веб-сайтами предлагалось распространение показателей надежности и ненадежности ресурсов. Если есть ссылка с одной страницы на другую, то для последней это увеличивает ее статус надежной. Если страница указывает на другую страницу, для которой известно, что она спам, то это снижает надежность изначальной страницы. Упоминается алгоритм TrustRank (Gyngyi et al., 2004) модификация PageRank для борьбы с веб-спамом. Для него требуется, чтобы изначально эксперты разметили часть сайтов, как надежные. Эти показатели далее распространяются по графу, постепенно затухая. Anti-TrustRank (Krishnan and Raj, 2006) следует этому же принципу, но с распространением показателей ненадежности от размеченных заведомо ненадежных сайтов. У обоих методов есть недостаток, что надежность делится по числу дочерних узлов. Benczr et al. (2005) предлагают совершенно иной подход: анализировать PageRank узла и соседних с ним. Распределение PageRank таких подграфов должно подчиняться некому степенному закону. Для тех же узлов, для которых распределение PageRank их соседей выбивается из этого закона, присваивается штраф. В работе (Castillo et al., 2007) предлагается сначала обучать классификатор на известных надежных и ненадежных страницах, а затем размывать результат скоринга остальных веб-сайтов по графу.

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

Атаки в компьютерных сетях. Sun et al. (2008) успешно применяют для решения этой задачи матричное разложение (CMD). Ding et al. (2012) используют подход основанный на поиске сообществ, выделяя в качестве подозрительных узлы-мосты между сообществами.

Заключение

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

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

Если вас интересует тема, то, чтобы получить больше информации, обязательно нужно идти в слак ODS (OpenDataScience), в каналы #network_analysis и #class_cs224w, смотреть курс Стэнфорда cs224w.

Еще недавно был прочитан курс по Knowledge Graphs. Ну и, конечно, нужно прочитать саму статью Graph based anomaly detection and description: a survey от авторов Leman Akoglu, Hanghang Tong, Danai Koutra (Akoglu, 2015), о которой идет речь в этом посте. Я перевел ее не всю, а только те фрагменты, которые счел важными, и понял в какой-то степени. Большинство авторов ссылаются именно на эту статью, потому что больше обзоров такого уровня и широты по теме нет. По крайней мере, я не нашел таких.


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