Продолжение про последствия влияния новых экономических и социальных факторов.
Начало.

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

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

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

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

Впрочем, эффект будет отложен на несколько месяцев, поскольку частично софта еще нет. И пока только начинаются поиски инвесторов.

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

Последствия, как и в первом случае:
- рост зарплат сеньоров, лидов
- акцент на иные плюшки, например, переманивание сеньоров на должности лидов, CTO/CPO/CMO

Что делать, расскажу в последующих постах.

Продолжение следует...

Какие вы знаете примеры раздражающих косяков в UI/UX крупных сервисов?

Ниже мой топ.

1 место
Пошаговая форма аутентификации.

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

Примеры: вход на почту VK, Яндекса, Google; GitHub еще год назад; сервисы Атлассиана; Альфабанк; МГТС, VK Cloud Solutions и многие другие.

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

Работники UX, кто научил вас этой хрени? Плюньте ему в лицо, это неудобно. И не очень безопасно, кстати.

2 место
Бесконечная прокрутка контента.

Крутишь страницу вниз, а тебе подсовывают всё новые и новые элементы - рекламные объявления, статьи итп.

Примеры: главная почты Мэйла, главная Авито итп.

Чем бесит: иногда нужно добраться до ссылок в подвале страницы. Но хрен там.

Работники Е-кома и медиа, уймитесь. Если кто-то крутит вниз уже десяток экранов, вряд ли ему нужен шлак в виде объявлений. Остановите прокрутку и сделайте кнопку "Загрузить еще" для тех, кто всё-таки пришел за шлаком.

3 место
Использование запятой в числе для разделения разрядов

Это когда и разряды тысяч (234,456), и дробная часть числа отделяются запятой.

Примеры: почти любой прайс-лист.

Чем бесит: хрен поймешь, где какая стоимость.

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

Бесит.

Усложнять просто. А вот упрощать — очень тяжело.

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

И хорошо, если времени и ресурсов хватает. А заказчик или клиент готовы ждать.

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

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

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

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

Держите в голове сложное, но делайте проще. Это ценится.

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

Задача достаточно типовая для крупных организаций. Для мелких в оптимизации смысла нет: даже если за счет автоматизации сократится 10% персонала, то обычно речь о половинке человека. А вот для крупных общих центров обслуживания (ОЦО) эффект вполне может достигать десятков миллионов рублей в год.

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

Но 10 шагов — в следующих постах.
А пока про нулевой шаг, про команду внедрения изменений.

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

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

Итак, HR, IT, бизнес, консалтинг. Четыре всадника апокалипсиса. В следующих постах посмотрим, как его избежать.

#СтарыеПубликации

80% работы менеджера — это маркетинг и продажи.

Нет, я не про маркетологов и менеджеров по продажам. Я про IT-менеджеров. День за днём, неделя за неделей им приходится продавать. Продавать на собеседованиях свою компанию подходящим кандидатам. Торговаться с ними за каждые пять-десять тыщ зарплаты, предлагая что-то нематериальное взамен.

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

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

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

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

PS. Про HRов вообще молчу. Вот уж кто боги маркетинга.

Продолжаю про производительность бэк-офиса. Начало.

Итак, команда проекта сформирована, пройдемся по первым шагам процесса.

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

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

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

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

Шаг 1.
Выделяются бизнес-процессы по поддержке подразделений компании (например, «предоставление справки», «закупка оборудования», «поиск сотрудника» и др.) или жизненные ситуации сотрудников подразделений: комплекс связанных бизнес-процессов. Например, жизненная ситуация «выход из декрета» может состоять из бизнес-процессов кадрового документооборота, обучения персонала, адаптации. Жизненная ситуация «поездка за рубеж» распадется на процессы «предоставление справки», «оформление отпуска». И так далее.

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

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

О следующих шагах — в следующих сериях.

Продолжение про производительность.
Предыдущие серии: начало, часть первая.

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

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

Не рекомендую пытаться на масштабах 100+ человек охватить сразу всё: это сложно для компании, можно легко затормозить работу. Лучше выбрать подопытных кроликов. Принципы выбора тоже разные. Если этот пост наберет 10 лайков, напишу и про алгоритмы выбора.

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

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

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

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

Продолжение следует...

Продолжение про производительность.
Предыдущие серии: начало, часть первая, часть вторая.

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

Шаг 4.
Для учёта затрат на бизнес-процесс выбирается и внедряется любая система по управлению задачами/процессами. Это может быть уже привычная для компании система (Битрикс, Jira, Trello, Райда — «задачникам» «несть числа»). С вариантами поможет член вашей команды изменений, отвечающий за технику (или консультант, если раньше опыта не было). В выбранной системе настраиваются пилотные б/п, ж/с (см.Шаг 2) в самом простом виде (см. Шаг 3).

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

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

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

Ближе к концу обучения назначается день Х.

Шаг 6.
В день Х работа выбранной роли переводится на «задачник».

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

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

Продолжение следует...

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

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

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

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

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

1. Какие важные части продукта знает только N?
2. Какими уникальными практиками, важными для бизнеса владеет N? За какие процессы отвечает? Возможно, он единственный эксперт по управлению проектами? Может быть, он единственный, кто обеспечивает публикацию программного обеспечения в промышленной среде? Только он знает, как формировать данные для ежемесячной отчётности бухгалтерии?
3. С кем взаимодействует только этот сотрудник? Какие из этих коммуникаций важны?

Смогли ответить на эти вопросы до того, как на стол легло заявление? И все ответы - это «уникальных важных знаний у сотрудника нет»? Поздравляю, вы относитесь к 1% проактивных руководителей. Остальные с такой задачей не справляются, являясь адептами реактивного менеджмента.

Ладно, на вопросы рано или поздно ответили, а дальше? Дальше нужно расставить приоритеты: что или кого дублировать в первую очередь. Здесь я рекомендую воспользоваться двумя простыми принципами:
1. Если признаков ухода пока нет, то первыми дублируем знания важных вещей, дублирование которых занимает больше всего времени (или денег). В момент ухода стоимость дублирования вырастет в разы, если сотрудник осознаёт свою уникальность
2. Если признаки ухода налицо, старайтесь задублировать как можно больше, пока сотрудник ещё здесь. А это явно не длительные по времени и стоимости, да?

Как дублировать?
О трех известных мне способах — в следующих постах рубрики #СтарыеПубликации

Продолжение про дублирование сотрудников из рубрики #СтарыеПубликации

Как дублировать сотрудников?

Я знаю три способа.
1. Автоматизация процесса/развитие продукта.
2. Составление письменных пошаговых инструкций.
3. Обучение других
Обычно, менеджерам, которые не занимаются проактивным дублированием компетенций, остаётся только второй вариант. Времени-то в обрез.

Советы руководителю:
1. Проще всего ответить на вопросы про важные знания, если заниматься анализом регулярно. С самого начала работы сотрудника. Можно использовать специализированные инструменты. Например, в Кловери есть специальный отчет для поиска уникальных навыков.
2. Если есть возможность и один из сотрудников является лидером мнений, дублируйте знания между тремя сотрудниками. Иногда ведь лидер может увести кого-то за собой. Даже если не сразу, то через несколько месяцев работы на новом месте.

Советы сотруднику:
1. Думайте о будущем. Уходить, хлопнув дверью, не лучший вариант. Работодатель, который уже сделал вам оффер - не последний в вашей жизни. Референсы влияют.
2. Если вас не успели задублировать, предложите вариант с заключением договора на оказание консультационных услуг. Некоторые ваши руководители не знают, что так можно. Поэтому не предлагают. Нормальная стоимость часа в договоре — в несколько раз больше, чем вам платили. Да-да, минимум вдвое.
3. Если вас просят остаться больше, чем на две стандартные недели — соглашайтесь. И да, помните, что теперь вы временно стоите минимум вдвое дороже.

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

Окончание про производительность.
Предыдущие серии: начало, часть первая, часть вторая, часть третья.

Итак, вы перевели часть сотрудников на работу через систему управления задачами. Что дальше?

Шаг 7.
При старте работы над задачей сотрудник, которому она назначена, переводит ее в статус «в процессе», в конце — в статус «выполнено» или «отказано». И заносит время, которое он потратил на решение задачи. Это, конечно, требует некоторой дисциплины. Но тем самым вы начинаете собирать время, которое тратят сотрудники на процесс или его этап.

Не стоит на этом шаге упарываться и требовать занесения с точностью до минуты. На данном этапе это ненужно. Можно вообще обойтись интервалами «меньше часа», «1-2 часа», «2-4 часа», «4-8 часов», «более 8 часов». Даже с такой точностью через несколько недель вы получите хорошую статистику. Пока важна не точность до минуты, а общая картина.

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

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

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

Шаг 10.
По итогам пилота вам нужно будет решить, что изменить, чтобы двигаться дальше: переводить на эту схему другие роли, улучшать качество измерения и даже остановится (иногда опускаются руки, это жестокая реальность). Из этих трех вариантов рекомендую первый. Чем больше ролей вы переведете на новую схему, тем прозрачнее работа организации. А производительность и оптимизация отдельных ролей — это уже следующие шаги.

Не стоит останавливаться на одной роли и улучшать только ее. Если она занимает всего 10% вашей компании, и вы улучшите процессы роли на 10%, то в масштабах всей организации это будет всего +1% производительности. Поэтому главный принцип, которого я рекомендую придерживаться — сначала пилот, потом количество (больше ролей, процессов), потом качество (точнее измерения, детальнее процессы). И через какое-то время вы легко сможете посчитать реальные затраты организации на выполнение определенной работы.

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

Я пришла к Максиму с запросом вида «последние 3 года мне не везло с начальством -- не помогали мне с развитием, оно было 100% только на мне, а теперь я потерялась, не хватает советов старшего товарища. Хочу вырасти в классного лида.»

Как итог, Максим поместил в проект с ОЧЕНЬ БОЛЬШИМИ ПРОБЛЕМАМИ. Жёсткий, почти проваленный дедлайн, тяжёлые отношения с заказчиком, полуразваленная команда, отсутствующие процессы, два месяца сломанных релизов и — как вишенка на торте — редкие технологии в стеке (Go, Tarantool, Clickhouse).

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

В общем, если вы ищете экспоненциального роста в сжатые сроки под надзором очень опытного ментора — вам сюда! Будет тяжко, но круто :). Я не пожалела!

——-
Это реальный свежий отзыв моей ученицы. Будущего CTO.

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

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

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

Четкой образовательной программы нет — всё реально индивидуально под запрос ученика. Но будет и теория, и наставничество, и практика. 10:20:70 — для меня это обыденность, а не влажные фантазии. На старте «сниму» уровень компетенций, вместе поймем, куда нужно прийти. И за 4-6 месяцев повышу уровень: с ведущего до тимлида, с тимлида — до директора итп. Если понадобится — дам реальную команду, реальный проект (но, конечно, с правом на ошибку за мой счет, вплоть до фатальной). Гарантия одна — прежним вы уже не будете.

Почему я?
Потому что хрен вы найдете где-то еще разработчика/продакта/CTO/CPO, который прошел по каждой ступеньке с junior-программиста до председателя совета директоров группы компаний. Успел поработать в крупных ИТ-компаниях, запустил или помог десяткам стартапов, сделал несколько федеральных проектов, тесно работает с членами Правительства РФ, депутатами, главами корпораций, трансформируя целые отрасли. А еще сделал несколько образовательных курсов, обучив сотни digital-специалистов; получил финансовое и психологическое образование. И при этом готов вас тащить к своему уровню.

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

Ах да. «Дорого. Не гербалайф».
Осталось всего пять одно место. Отсчет пошел. Пишите в личку.

А если пока не готовы — лайк, шер.

Когда-то давно, работая директором по разработке в Ру-центре, я придумал методику управления, который стал активно использовать и продвигать — «Три-п» (Предмет, Персоны, Практики). Потом, оказалось, что нечто подобное где-то на западе придумали чуть раньше, но не суть. У чудаков мысли сходятся. Здесь о «Три-пе» писал впервые года четыре-назад.

Применяя эту методику в работе и в жизни, пришел к мысли, что не хватает еще одного «П». Причины, по которой надо что-то сделать (или цели, ответа на вопрос «Зачем? Почему?»). Так, методика стала называться 4П. Или «чпок» 😁. У нас появилось даже обозначение действия — «чпокни этот документ/продукт/презу». Проверь на соответствие всем четырем «П».

Цель — это прекрасно. Десятки сообщений в этом канале — про цели и целеполагание.

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

К примеру, для проекта «Пушкинская карта» моя личная формулировка такая:
«Молодежь регулярно посещает культурные события» [кто, как, что: персоны, процесс, предмет]

Для своей жизни формулировка такая:
«Я помогаю появиться множеству успешных ИТ-компаний» [кто, как, что: персона, процесс, предмет]

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

А как звучит формулировка вашей личной цели?

#СтарыеПубликации

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

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

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

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

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

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

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

В будущем я хочу объединить опыт ребят конкурса #ЛидерыРоссии с огромной мотивацией наших студентов. Кажется, что из такой смеси получится просто бомба. И будет появляться еще больше ИТ-компаний.

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

Некоторое время назад активно муссировались случаи с утечками персональных данных (ПнД). Наши доблестные депутаты даже штрафы планировали вводить и всё такое.

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

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

- повышение грамотности работы с персональными данными, в том числе среди ИТ-специалистов.
- неиспользование персональных данных, полученных из «протёкших» сервисов, без согласия субъектов ПнД.

Поясню детальнее, в чем некорректность подхода.

1. Сама формулировка «персональные данные» в 152-ФЗ достаточно размыта.

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

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

Утечка данных бывает не только по вине организации, обрабатывающей ПнД.

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

Продолжаю #ПроИБ.
Начало. И еще пара нюансов, почему штрафы за утечки не панацея.

3. Конечный источник ПнД достаточно сложно выявить.

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

Публикация этих ПнД с заведомо ложным указанием источника может быть использована для давления на бизнес, в том числе, для конкурентной борьбы. Кто помешает выложить телефоны 2-3 депутатов Госдумы и написать, что это утечка с сервисов Яндекса? С сервисов VK? Из Министерства цифрового развития? Oh, wait..

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

4. Утечка ПнД может происходить по вине бывших сотрудников

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

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

5. Утечка ПнД вообще может быть не связана с конкретной организацией и быть массовой.

Существует гигантское количество сервисов, имитирующих сервисы банков, соц.сетей, почты и др.. Т.н., «фишинговые сайты». Существуют автоматизированные методы социальной инженерии по выманиванию данных у субъектов ПнД. Моей теще на днях очень убедительно позвонили «сотрудники Моссоцрегистра». Почти выдала номер карты. Благо слишком громко разговаривала, мы успели выхватить карту из рук. И повестить трубку.

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

Следующая часть статьи — финальная.
Еще пара причин. И ответ на вопрос «Что делать?».

Снова #ПроИБ.
Начало. Продолжение.
И окончание.

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

Итак, еще аргументы, почему ужесточение — «ну такое себе».

6. В стране недостаток компетенций у ИТ-специалистов по информационной безопасности

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

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

7. Высокая стоимость построения информационной инфраструктуры, устойчивой к утечкам ПнД.

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

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

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

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

2. Вложиться на государственном уровне в развитие ИБ-грамотности населения, начиная со школы.

3. Вложиться на государственном уровне в развитие ИБ-грамотности разработчиков (например, субсидировать курсы повышения квалификации). Именно вложиться, а не имитировать. На сайте МинЦифры «Цифровые профессии» по ИБ всего 2% курсов. Зато по программированию — половина.

Есть и другие меры, в т.ч. организационно-технические. Но толку-то... Шадаев меня не читает.

Посмотрим, что приготовит МинЦифра.

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

С чего начать делать презентацию? С тезисов? С оформления слайдов? А с чего начать сервис рассылки писем? С API приема команд на отправку? С модуля отправки? С шаблонов писем?

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

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

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

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

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

Научить методике выбора наименьшего инкремента?