Про процессы и людей глазами очевидца
708 subscribers
33 photos
2 videos
148 links
Я — Макс Бабич. 20+ лет занимаюсь ИТ и HR, 15+ лет — менеджментом. В известных IT-компаниях, интеграторах, госорганах. Преподавал в Бауманке, Нетологии и ВШЭ. Запускаю и закрываю стартапы.

Здесь пишу заметки о менеджменте, людях и их взаимодействии.
Download Telegram
Иногда очень сложно определить тему для очередного поста. Нет, не потому что темы закончились. Запас-то ещё ого-го. Сложно потому, что слишком много всего происходит кругом.

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

Большой выбор ничем не лучше отсутствия выбора. Много идей ничем не лучше их отсутствия. Много фич в продукте ничем не лучше сырого продукта.

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

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

ФБ: https://facebook.com/WebByte/posts/1659263824138357
#РазговорилисьCегодня с одним IT-предпринимателем про технических директоров. Опасается человек, что в случае конфликта с руководством технический директор со всеми его полномочиями может бизнес грохнуть.

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

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

Кстати, лайфхак еще есть — жениться на техдиректоре. Или замуж за него выйти. Главное, правильно транслировать это текущему супругу или супруге: «Извини, солнышко, ничего личного, just business».

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

Что делать в таком случае? Дублировать. Размывать компетенции, знания, навыки как можно быстрее. Давать денег, если попросит. Шантаж? Да, шантаж. Сами виноваты. Ну или те, кто был до вас. Говорят, долю еще давать можно ключевым сотрудникам, иногда спасает.

Страдать и дублировать. Людьми, инструментами, изменением процессов. Планомерно. Неделя за неделей. Может быть даже в ущерб развитию бизнеса. Это временно, ненадолго. А вот если человека автобус переедет — будет больно. Очень.

Знайте, кто у вас самое узкое место.
Думайте, как это исправить.
Торопитесь.

ФБ: https://www.facebook.com/WebByte/posts/1663398640391542
Менеджмент похож на беговые виды спорта в легкой атлетике.

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

Бывают задачи, где нужно думать о тактике. Как на средних дистанциях — 800 и 1500. Можно быстро начать, но не добежать. Можно начать спокойно, но не успеть вовремя ускориться. Думать надо.

Бывают задачи, где нужно нестись, что есть сил. Как на стометровке. Или на 400 метрах. Не раздумывая. Просто срываясь с колодок и хренача.

Редкие спортсмены бегают дистанции разных типов.
В основном, специализируются на одних — спринт, средние, длинные.

А что ж тогда от менеджера ожидают способности бегать сразу тремя способами?

ФБ: https://www.facebook.com/WebByte/posts/1666650030066403
#РазговорилисьСегодня про развитие сотрудников. И была высказана мысль: «Либо помещаем сотрудников в условия, где они сами развиваются, либо развиваем, либо понимаем,что наша компания — тупая мясорубка и только на перекантоваться». И ответ на эту фразу: «Не бирюза ни разу, но горькая правда жизни».

Я не спец в организационном развитии. Так... Кое-что читал, кое за чем наблюдал, кое с кем дискутировал. Но всё равно этот ответ показался странным. И вот почему.

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

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

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

Пожалуйста, не идеализируйте «бирюзу». Это всего лишь более целостная организационная форма. Чуть другая. А не «лучшая».

И да. Если кто-то в России говорит про свою бирюзовость, посмотрите на забор. Там тоже много, что написано. А подходишь поближе — доски.

Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1669915749739831
Обратная связь - лучшее, что придумало человечество после изобретения граблей. Потому что грабли по лбу - это физическая боль. А от обратной связи чаще даже приятно.

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

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

Меж тем иногда этот метод применять не стоит.

Иногда стоит минусами обойтись. Корону сбить. Как граблями.

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

В общем, обратная связь - очень полезный инструмент. Пользуйтесь почаще. Запрашивайте почаще.

Обсудить в ФБ: https://facebook.com/WebByte/posts/1672786796119393
Примерно раз в месяц я рассказываю, как проводить декомпозицию.

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

Один из этапов декомпозиции — проверка целостности полученного решения. На этапе проверяются два простых правила.

1. Каждому требованию из примера соответствует хотя б одна задача.
2. Нет задач без соответствующих им требований

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

Вот со вторым правилом постоянно проблемы.
Каждая группа пытается обязательно придумать что-нибудь избыточное. Вот, к примеру, есть задание "Организовать перелет из Москвы в Лондон". Так обязательно предложат купить обратный билет. Или обязательно задумаются о негабаритном багаже.

Любим мы переусложнять, ага.

Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1676173999114006
Идеальные требования наглядны.

Так я начинаю один из блоков занятия про техническое задание в рамках преподавания в «Нетология» и ВШБИ.

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

Уже никто не спорит с тем, что в хорошем ТЗ должны быть прототипы. Спрашивают разве что, какими инструментами их делать. Я рассказываю про всякие Sketch или Figma, про сервисы рисования схем и диаграмм. Вроде Draw.io или Gliffty. Даже про Tilda рассказываю как средство прототипирования. А чо, можно и на ней собрать.

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

Кстати, на маркерной доске отлично можно изобразить план запуска проекта, даже если проект очень длительный. Главное, чтобы 3-4 разноцветных маркера были под рукой. И уборщица не стерла ваш замечательный план.

А как вы делаете прототипы и пользовательские сценарии?

Ответить в ФБ: https://www.facebook.com/WebByte/posts/1679021618829244
Должна ли быть открытой информация о зарплатах в компании?

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

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

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

А должна ли бы прозрачна информация о зарплатах в отрасли и профессиях?

Вот Яндекс считает, что не должна.
И закрыл свой сервис про зарплаты: "К сожалению, данный раздел был закрыт и больше не поддерживается. Его возвращение не планируется.".

Пойду, слайд из презентации удалю. Устарела.

Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1681836321881107
Стадии развития программиста.

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

Стадия вторая.
Хо-хо. Я сделал свой первый крупный проект.
Вы говорите, что он плох? Сперва добейтесь. Вы говорите, что ваш язык или фреймворк лучше? Вы просто ничего не понимаете. Вы просите меня попробовать новое? А зачем? Ведь и так всё работает. Вы против рефакторинга? Фаулера почитайте. И вообще, сколько шаблонов проектирования вы знаете? Ах, вы вообще не программист? Ну что же, ваше мнение меня не интересует. Совсем.

Стадия третья.
Новый язык? Давайте попробуем. Новый фреймворк? Тащите сюда. Что? Вот этот код плох? Ок, как лучше? Спасибо! Какая книжка вышла? ОК, почитаю. Реакт позволяет сделать быстрее? Берем реакт, в топку ангуляр.

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

По ощущениям многие застревают между второй и третьей. Единицы доходят до четвертой.

А вы на какой? Отмечайтесь в ФБ: https://www.facebook.com/WebByte/posts/1684757458255660
Люди идут на людей.

Люди покупают товары по рекомендациям других людей. Читают отзывы, читают обзоры. Вакансия IT-специалиста — товар.

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

Поэтому скоро IT-рекрутеры сделают следующий шаг в осознании роли маркетинга в подборе: работа с лидерами мнений может ускорить и удешевить найм.

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

Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1687453624652710
Тяжело постоянно быть готовым к переменам, правда?

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

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

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

И вообще, "работает - не трогай". Это неважно, какие последствия будут для компании, если не попробовать. Своя-то рубаха ближе к телу.

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

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

Так и живём, правда?
Откладываем назавтра, на понедельник, на январь следующего года.

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

Жил-был ребенок, владелец этого мозга.
Когда ребенок был маленьким, он заболел. Ничего серьезного - просто немного кашлял. Мама малыша не бросила его в беде, была с ним, уделяла ему внимание и вылечила его. Не заметив, что у мозга появился шаблон "если кашлять, появится мама и уделит внимание".

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

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

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

Вот такая вот интересная загогулина.

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

Обсудить в ФБ: https://facebook.com/WebByte/posts/1694787110586028
#РазговорилисьСегодня о том, что большое количество знаний и навыков мешает менеджеру достигать выдающихся результатов. Дескать, больше знаешь - больше рисков видишь. И не пробуешь что-то внедрять, поскольку сразу видишь проблемы. Но на самом деле можешь просто раз за разом упускать возможности. А необремененный знаниями - якобы - не парится и просто много экспериментирует, пока не нащупает правильный путь.

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

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

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

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

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

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

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

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

На что обычно уходит время разработчика?
На четыре группы задач:
- Разработка новых фич продукта
- Операционная деятельность
- Разработка инфраструктуры продукта
- Поддержка пользователей

Некоторые компании забивают болт на некоторые группы. За что потом и расплачиваются. Но я знаю именно четыре группы. Может ещё и забиваю на другие.

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

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

Так вот по опыту для нормального развития продукта подходит такая структура квот:
- 45% - продукт
- 15% - операционка
- 20% - инфраструктура
- 20% - поддержка

Конечно, в конкретной компании в конкретной команде в конкретное время структура будет иной. Например, если многие месяцы забивали на инфраструктуру, то через какое-то время разработка станет настолько неповоротливой, что без рефакторинга архитектуры и кода time to market станет просто ужасным. В крайне запущенных случаях придется тратить на инфраструктуру до 60%. И страдать.

Представляете? Только 25% останется на развитие продукта и поддержку! Эт если ещё в компании не практикуются совещания по поводу и без.

В общем, планируйте разработку правильно. А лучше заведите отдельные команды)

Предложить свою структуру: https://facebook.com/WebByte/posts/1701046343293438
На полуфинале "Лидеров России" (по ЦФО) было голосование.
У участников спрашивали, с чем ассоциируются два слова — "лидерство" и "ответственность".
По мнению участников, "лидерство" — это "вдохновлять".
А вот "ответственность" — это "наказание".
Вот такая у нас память предков, вот так культура общества влияет на подсознание.
Хотите больше ответственности от сотрудников? Меняйте их отношение, меняйте их ассоциации.
Есть люди, которые думают. Есть люди, которые делают. Есть люди, которые объединяют других людей.

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

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

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

В ФБ: https://www.facebook.com/WebByte/posts/1706592562738816
Кто такой эксперт?

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

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

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

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

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

А кто для вас — эксперт? Как его определяете?

В ФБ: https://www.facebook.com/WebByte/posts/1709585845772821
Странная у нас жизнь, правда?

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

А за пределами работы мы часто про процесс.

Побухать пива с друзьями — ну какой в этом результат-то? Не напиться же. Это можно сделать эффективнее и дешевле дома в одно лицо.
Съездить в путешествие. Какой результат? Эмоции-то не от факта окончания поездки получаем, а от процесса.

Посмотреть фильм. Какая эффективность? Какая результативность? 1.5–2 часа потерянного времени.
Поужинать в ресторане. Можно дома. Дешевле. Сытнее. Явно ж не калориях дело.
Да просто вечерняя прогулка — где тут про достижение?

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

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

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

Вы скажете: "Так не бывает".
Ну... Да, я придумал этот способ в понедельник. С его помощью мои студенты в ВШЭ разбирали примеры ТЗ своих коллег. Говорят, очень понравилось. А эт главное в развитии - чтоб оно было не только полезным, но и приносило положительные эмоции. Закрепляется так лучше.

В ФБ:
https://www.facebook.com/WebByte/posts/1716072995124106
У рабочих, сортирующих апельсины, очень сложная работа — постоянно приходится принимать решения. Это мелкий апельсин. Это крупный. Иногда становится еще сложнее — добавляется средний размер.

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

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

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

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

Сколько, кстати, у вас правил в корпорациях, коллеги?)

PS. Беру паузу на две недели. В Сочи. В Питер.