Продолжу про рекомендации.

#РазговорилисьСегодня о том, говорить или нет о недостатках бывшего коллеги.

Есть мнение, что говорить о недостатках не стоит — лучше всегда встать на сторону кандидата. Он-де менее защищен, чем работодатель. И лучше уж отказаться давать рекомендации.

Давайте представим, что вам не рассказали о недостатках кандидата, взяли вы его. А у него они есть. Неважно какие, но почему-то существенные для вас. И о кандидате сразу мнение испорчено, и о том, кто рекомендации дает: «Эвоно что, в людях не разбирается, свинюху мне подложил, ух я ему припомню!».

А рассказали о них... Ну ок, недостатки есть у всех, дальше ваше осознанное решение. Либо с вашей точки зрения недостатки несущественны, либо вас предупредили о рисках, и вы на них идете, либо риски высоки и кандидату лучше отказать.

Но это же вставать на сторону работодателя!

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

Мое мнение — говорите объективно. Насколько это возможно.

При автоматизации/цифровизации госкомпаний и промышленных предприятий часто сталкиваемся с нехваткой у сотрудников заказчиков цифровых знаний и навыков.

Сегодня про компетенции в практиках и процессах.
В следующий раз — про людей.

Понимание возможностей новых технологий и связанных рисков:
- Хотим применить вот здесь компьютерное зрение
- Но у вас условия освещения позволят давать рекомендации только с вероятностью 55-65%. Нужен будет человек для принятия решения.
- Ой, всё.

Владение методами проектного управления
- Проект на несколько месяцев. Будем отвлекать людей от производства. Давайте вместе спланируем.
- Ой, всё.

Владение азами гибких методологий
- Сделайте нам по Agile.
- Что вы под этим понимаете?
- Ну чтобы не было ТЗ.
- Ок, но давайте тогда оплату по T&M.
- Ой, всё.

Владение инструментарием работы с аналитикой
- Почему вы решили, что проблема именно здесь?
- Марь Иванна так считает, у нее 30 лет опыта
- Но ведь мы снимали метрики, результаты противоречат Марь Иванне.
- Ой, всё.

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

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

Объясняем, конечно. Проводим обучение. А что делать?
Как у ваших сотрудников с этими компетенциями?

Продолжаем про нехватку компетенций у сотрудников госкомпаний и промышленных предприятий. Сегодня про людей.

Эмоциональный интеллект, понимание потребностей другого человека
- Хотим автоматизировать вот этот процесс вот так.
- Но это усложнит работу сотрудников, а реальной пользы не принесет. Что они считают по этому поводу?
- Недовольных уволим.
- Но у них же узкая экспертиза, на рынке нет
- Ой, всё.

Взятие на себя ответственности
- Давайте сделаем вот так. Это займет два месяца, на стоимость не повлияет. Но будете экономить Х млн. в месяц.
- Нам нужно посоветоваться.
...
- Посоветовались? Что решили?
- Петра Ивановича не было, Иван Петрович воздержался, а Марьиванна в отпуске. Нам еще месяц-другой нужен.
- А может сами примете решение?
- Ой, всё.

Способность к непрерывному обучению
- Знаете, наш директор ничего не понимает в ИТ.
- Давайте поможем. Расскажем, покажем альтернативы, объясним, как повлияет на финансовые результаты. Займет полчаса-час, не больше.
- Час? Так долго он не может, очень занят!

Готовность к изменениям
- Давайте внедрим здесь ЭЦП. Это избавит вас от необходимости сканировать. Выгода — Х млн.минут в год.
- Не, это ж приказ по организации написать надо. Будет много недовольных. Тем более, у начальников для этих действий есть секретари. Не сам же он сканировать будет.
- Но Х млн. минут секретарей - это ж тоже много.
- Ой, всё.

По моему опыту, неготовность меняться — основная проблема при изменении привычных процессов. Но если для линейных сотрудников и миддл-менеджмента это обычная история, то работа топов вроде бы в том и состоит, чтобы менять компанию к лучшему. Типичное же run business vs change business. Но нет. Типичное мнение: «Топы потом и кровью пришли в текущую точку карьеры, изменения и перестройка могут стоить карьеры». Так и живем. Кого-то переубеждаем, кто-то доходит сам. А кто-то рано или поздно выйдет искать новую работу.

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

#РазговорилисьСегодня о влиянии менеджеров продукта на прибыль компании.

Началось всё с двух тезисов:
1. Менеджер продукта не должен отвечать ни за выручку, ни за прибыль.
2. Любой сотрудник компании должен приносить прибыль

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

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

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

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

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

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

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

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

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

На днях задали вопрос о тестовых заданиях для квалифицированных кандидатов. Давать их или нет.

Однозначного ответа нет. Всё сильно зависит от отрасли, позиции и даже от конкретной компании. Порассуждаю.

Зачем дают тестовое задание? Как минимум, есть два варианта. Первый — проверить компетенции кандидата. Второй — ограничить входной поток специалистов. Вариант «получить на халяву результат тестового и использовать» отметаем, как нечистоплотный. Фу такими быть.

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

С позицией/профессией соискателя ситуация похожа, но есть нюансы. С одной стороны, если классных специалистов не хватает, то лучше брать того, кто подходит хотя бы процентов на 85-90, чем отсекать такого тестовым заданием. Доучится, в крайнем случае. С другой стороны есть профессии, где без тестового брать не принято. Не просить копирайтера что-то написать или переделать текст? Не просить дизайнера что-то нарисовать? Странно, да. А вот 3 из 4 программистов, по нашим опросам, против тестового.

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

Так что, если решаете, давать или нет, задайте себе два вопроса:
1. Мы выбираем или нас выбирают?
2. Принято для этой профессии давать тестовое или нет?
Если оба раза на первую часть вопроса ответили положительно — валяйте, несите тестовое.

Новая рубрика #ЧтоЕсли
~~~~
Задали вопрос: «Как быть, если кандидаты отваливаются из-за большого числа собеседований — одновременный смотр в несколько команд».
~~~~
Ситуация типичная для IT-компаний: кандидата смотрят 3-4 человека, каждый задает вопросы. Еще хуже, когда собеседуют по одному, но 3-4 собеседования. Собеседование — стресс. Один-на-один с командой — еще больший. Не все могут справиться. Для компании отвлечение специалистов — расходы. Тем большие, чем больше отказов.

Решение простое — снизить длительность собеседования и число собеседующих.

Делаем 5 простых шагов.
1. Готовим профиль компетенций вакансии (или вакансий).
Оцениваем, какие навыки критичны, какие нет. Проверяйте на собеседовании критичные. Не тратьте время.

2. Делаем предварительный скрининг компетенций кандидата и сравниваем с вакансией.
Естественно, только ключевых. Чтобы кандидат не тратил время. Сделать скрининг можно пока кандидат едет на собеседование — потыкает в телефоне. Можно раньше — вдруг вообще не соответствует профилю вакансии.

3. Выбираем собеседуемых по каждой нужной компетенции.
Кто вообще способен оценить навыки кандидата? Кто знает не хуже? Троечники не отсобеседуют отличника.

4. Выбираем минимально необходимое количество собеседующих
Скорее всего, по каждой компетенции у нас 3-4 оценщика. Сравниваем их компетенции с кандидатом, выбираем минимальное количество. Эти 1-2 человека и должны отсобеседовать. Их знаний достаточно.

5. Делаем запись собеседования
Если кандидат согласен, делаем запись собеседования, показываем остальным командам.

Вот пример поиска HR-менеджера с помощью Кловери.
1. Выявили компетенции Ивана через скрининг.
2. Нашли оценщиков - Светлану и Евгению.
3. Поняли, что Светлана справится одна.
4. А еще поняли, что по ведению архива документации собеседовать некому.

Если у вас есть вопросы в рубрику #ЧтоЕсли, пишите мне: @webbyte.

Иногда встречаюсь с таким запросом:

«Хотим программу обучения для управленцев, идеально — курсы онлайн. Какие ресурсы использовать? Чему учите ваших ТОПов?»

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

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

Например, есть цель «повысить производительность труда».

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

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

Выбрали направления обучения? Выберите и форму. Онлайн (особенно в записи) не очень способствует объединению ТОПов. Гораздо лучше работает совместная практическая работа. Поработать руками, плечом к плечу. Изучаете Kanban? Попробуйте командой ТОПов наладить конвеерное производство бумажных самолетиков. Изучаете Lean? Соберите десятка два скворечников. Несколько часов работы, а понимание в разы лучше.

Итак, прежде чем слепо копировать чужой опыт:
1. Определите цели обучения
2. Определите способы достижения целей
3. Под способы подберите контент.
4. Выберите форму, максимально подходящую под цели. И максимально практичную.

Задали вопрос о проблемах обучения детей.
Не претендуя на экспертизу в педагогике, отвечу исходя из знаний психологии.

В раннем возрасте дети учатся наблюдая.
За авторитетами: родителями или родственниками, учителями, кумирами. Обучаясь при взаимодействии со своей социальной группой — классом. Всё, что дети могут на этом этапе делать — подражать. Если в школе не сложилась культура обучения (не нравится учитель, потому что кричит; другие дети не хотят учиться и подбивают ребенка), то может помочь домашняя культура обучения.

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

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

1. Когда-то им заложили установку «ты тупой, ничего в жизни не добьешься».
Ему эту установку заложили авторитетные люди: родители, учителя. А если авторитет сказал, то как идти против? Откуда для этого опыт и знания?

2. Не смогли найти точки, где ребенку интересно
Например, ребенок может и рад интересоваться историей, но никто с ним об этом не беседовал. Ребенок может и не знать, что вообще есть такое понятие — записывать события прошлого. Задача родителя пока ребенок маленький — искать точки интереса.

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

Обучение ребенка — комплексная история. Но смысл сводится к одному: родители и авторитеты должны
- закладывать культуру обучения в ребенка;
- подбирать области, где ему интересно;
- подбирать инструменты, которые он лучше воспринимает.

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

Кстати, обучение начинающих специалистов очень похоже.

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

Пример из недавней практики. Уездный город N. Администрация города. Задачка — обсудить возможный пилот с городом по внедрению технологий Smart City. Известно, что на встрече будет руководитель ЖКХ и руководитель социального направления. Перед встречей изучаю справку по проблемам водоснабжения, разбираюсь в основных процессах (пусть в другом регионе, но сходство есть). Изучаю биографию руководителей. Заслуги и проблемы на текущем месте работы. Изучаю новости о проблемах города. Встречаюсь. Успех.

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

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

1. Появляется информация для начала беседы
1-2 вводных минуты, пока собеседники собираются с мыслями, есть шанс расположить их к себе, показав принадлежность к той же социальной группе. Общие знакомые, общие интересы, общие элементы биографии, то-сё.
2. Появляется примерное понимание проблем участников
Можно сразу обсудить что-то конкретное: насущность проблемы, ее остроту, что уже сделано. И затем предложить что-то свое для решения. И меньше времени тратить на обсуждение. В городе N хватило 20 минут.
3. Появляется сопричастность
Собеседники видят заинтересованность, если кто-то потратил время, чтобы вникнуть в их проблемы. Эт плюс в карму. И способ встать на сторону клиента.

Конечно, всего изучить нельзя. Но обладая хоть какой-то конкретной информацией, импровизировать сильно проще. Импровизируйте правильно!

#РазговорилисьСегодня об управлении по целям. Как вести, как отслеживать достижимость, какие критерии.

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

1. Заводим отдельный раздел в Конфлюенсе или любой другой вики.
2. В этом разделе есть
- цели на текущий период
- архивные обязательства. Они помогают посмотреть в прошлое: насколько менялись цели, насколько они были амбициозны, насколько они достигались.
3. Страницы в разделе иерархичны: от целей компании к целям департаментов, а затем — команд. Все страницы доступны для просмотра всем.

4. Каждая отдельная страница содержит 1-3 цели.
Цели могут быть из одного из трех направлений:
- Развитие продукта
- Развитие процессов (инфраструктуры, управления проектами итп)
- Развитие команды
Обычно, в квартале у команды может быть не более 1 цели по одному из направлений. Но желательно не больше двух всего.

5. Цели описываются 3-4 измеримыми метриками.
Можно каждую метрику делать задачкой в таск-трекере. Тогда в вики метрики просто выводятся в виде пунктов чеклиста с названиями задачек.

6. В конце квартала ставятся галочки напротив выполненной метрики
Этим фиксируем, какие задачи были закрыты на конец квартала.

Пример:
Цель: Доехать из Петербурга в Москву.
Метрики:
✅ Купить билеты не дороже Х рублей
✅ Добраться до вокзала
✅ Проехать не менее 800 км.
❌ Выйти на Ленинградском вокзале в Москве.

Упс.

#РазговорилисьСегодня об адаптации. Началось с вопроса об идеях для адаптации.

Подходить к таким вопросам стоит от целей и задач компании.

Улучшения в процессах делаются не просто так, а для чего-то. Конечно, если наша задача — развивать компанию, а не имитировать бурную деятельность. Раз так, то сначала надо понять, чем вообще занимается компания: чтобы приблизительно понять, какие процессы ключевые, и где в них возможны проблемы.

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

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

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

Итак, задумываясь об адаптации, ответьте себе на вопрос: Зачем?

Попросили прокомментировать ситуацию.

Руководитель группы (назовем его Гриша) написал следующее сообщение своим сотрудникам:

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

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

Теперь детально.

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

Фраза «остальное, ну такое» — на грани оскорбления, что в публичной беседе вообще недопустимо. Если есть претензии к конкретным людям, это обсуждается с глазу на глаз. А не публично.

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

Вывод.
Этим сообщением руководитель, скорее всего, еще больше демотивировал персонал. И даже тех трех, «которые специалисты» тоже. Так как видят неадекватного руководителя.

Адекватный мог написать так:

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

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

Не будьте как Гриша. Общайтесь с сотрудниками корректно, с профессионализмом.

Задали вопрос: «За что премировать SRE-команды (site reliability engineering)?» Какие есть ли особенности премирования с учетом функционала таких сотрудников.

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

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

За что можно давать премии?

Сразу скажу, я не сторонник давать премии за работу, которую и так должен хорошо выполнять сотрудник. Его же для этого и брали, да? Но если уж отвечать на вопрос, то я бы исходил из задач бизнеса. И влияние на них команд SRE.

Работа инженера — обеспечение непрерывности бизнеса и его развития:
1. Обеспечение непрерывного функционирования ключевой инфраструктуры, от работы которой зависит производство, продажи итп.
2. Помощь в снижении Time-to-market в части взаимодействия с производством.

Непрерывное функционирование инфраструктуры связано с реактивным решением проблем и с проактивым:
- реагирование на текущие инциденты (какой-то из узлов, компонентов вышел из строя и влияет на процессы);
- развитие инфраструктуры для предотвращения инцидентов в будущем;

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

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

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

Итак, три составляющих, влияющих на премии SRE-команд:
- Развитие продукта компании в части скорости поставки;
- Развитие процессов компании в части надежности работы инфраструктуры, оптимизации ресурсов;
- Развитие персонала компании в части развития компетенций.

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

Последнее время мало пишу.
Конец 2020 и начало этого года очень жаркие. Хотя за окном иногда -30.

Жара — из-за моих проектов.
Самый старший из них — Кловери, сервис по оценке и развитию digital-специалистов на основе моделей профессиональных компетенций.

В 2017 году я задумал Кловери, как место пересечения всех участников развития взрослых специалистов: самих специалистов, компаний-работодателей, экспертов и экспертных сервисов, контент-провайдеров. Это должно было стать практической win-win реализацией моей концепции work-long learning — развитие людей во время работы.

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

К счастью или к несчастью, в начале 2018 мне пришлось отпустить Кловери в плавание без капитана. Я нанял исполнительного директора, команду, оплачивал ее работу, показывал направление, но не лез в операционку. А сам помогал государству. Без капитана Кловери далеко не уплыл. Без меня не было нужного уровня продаж компаниям, а продажа услуг специалистам не взлетела. Хоть мы и провели примерно 4000 оценок. И в середине 2019го я свернул основное финансирование, взял паузу подумать о будущем сервиса. А заодно подтянуть свои навыки в менеджменте организаций.

Пауза затянулась. Но в конце 2020 я понял, зачем нужно продолжать развивать Кловери, и как это делать. И с этим пониманием пошел на EdTech B2B Challenge. Мы вошли в список победителей — 8 команд, которых по итогам конкурса выбрали к участию в акселераторе ED2.

Что ждет Кловери дальше?
Как минимум, перезагрузка и большая ориентация на B2B.
Это не значит, что Кловери больше не помогает специалистам.
Нет, будем помогать и дальше, но чуть иначе, чем раньше. В концепцию work-long learning я хочу добавить opensource learning. Объединить лучшие практики открытого ПО и открытого образования. Пока не знаю, что получится: нет ни компаса, ни карты, впереди Terra Incognita. Но это точно будет интересно. Присоединяйтесь.

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

Если вам интересна концепция "Образование как OpenSource", присоединяйтесь к Open Cloveri.

А если просто хотите продолжить читать этот канал, ждите следующей заметки. Она уже пишется.

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

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

Настолько интересно стало, что даже небольшой опрос (6 вопросов) сделал.

Уважаемые коллеги, поделитесь - а как в вашей компании с такими конфликтами? Опрос анонимный, результаты - в пятницу:
https://cloveri.com/poll/topconflict/

Результаты исследования уже доступны.

В исследовании приняли участие 28 компаний. Конфликты идут или были за последние 6 месяцев примерно в 82% компаний из опрошенных (23 из 28). А в 11 случаях еще длятся.

Ребята, давайте жить дружно :)

Присутствовал в качестве заказчика на демо одной из команд нашей группы.

Команда занимается прогнозированием аварий.
Ребята полчаса говорили на своем языке дата-саентологов: рассказывали, чем занимались на итерации, какие результаты. «F-мера», «Isolation forest», «dbscan», то-сё. В конце прозвучало: «Вопросы?»

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

Демо — важная встреча. На ней можно повлиять на направление развития продукта. Обратная связь; инсайды от рынка; услышанное на демо — всё это определяет дальнейшее движение по максимизации ценности для клиента.

Чтобы демо проходило плодотворно, стоит помнить следующее:

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

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

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

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

А как вы проводите демо?

Как изменится постковидный мир?
Что произойдет после резкого уменьшения налогов для ИТ-компаний? А после перехода на гибридный формат работы?

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

Но кажется, больше статут обращать внимание на внутреннюю культуру компании и на бренд работодателя.

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

Повторю пост 4 летней давности, который написал еще до появления этого канала.

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

Что такое приоритет технически? Для кого-то — какие-нибудь циферки в Jira/Redmine/СтопицотомТрекереЗадач. И варианты на тему рангов — Rank, BackLog Rank, Project Rank и так далее. Из альтернатив — порядок на Как-там-бан доске. Рациональщина, короче.

Однажды я решил добавить эмоций и красок в жизнь простого менеджера. И придумал приоритеты... раскрашивать. Какую цветовую систему выбрать? Конечно же известную нам с детства: Каждый-Охотник-Желает-Знать-Где-Сидит-Фазан.

Итак, встречайте — радужные приоритеты. Нет, это не пропаганда.

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

Для примера я выбрал задачу «Путешествие из Москвы в Британию», которую я давал при обучении декомпозиции. По этой карте я сам постоянно готовлюсь к поездке (оригинал заметки написан в доковидные времена).

PS. Я уверен, что это кто-то изобрел и до меня. Уж больно на поверхности лежит идея — раскрашивать приоритеты и MindMap в радужные цвета. Если подскажете автора-первопроходца, буду признателен.