Вселенная опять открывает возможности. Менеджерам уже открылись. Теперь настало время для программистов с аналитиками.

Сегодня я буду Морфеусом.
Слушайте меня, будущие Нео и Тринити.

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

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

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

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

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

Следуй за белым кроликом, Нео.
Впиши себя в историю. Пиши мне.

В ФБ: https://www.facebook.com/WebByte/posts/1900136203384450

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

Дескать, ведомство "А" обидело. Всё бы ничего, но реально дело не в ведомстве "А", а в ведомстве "Б", которое некорректные данные передало в первое ведомство. Или не передало вообще. Или передало когда-то корректно, а потом некорректности добавило. Или еще что-то сделало не то. Но по факту, у ведомства "А" данные грязные, из-за чего услугу гражданам указывает не всегда качественно.

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

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

Кому интересно, почему нельзя — почитайте про CAP-теорему (она же теорема Брюера).

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

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

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

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

Только смелые духом :)

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

—-
В ФБ: https://www.facebook.com/WebByte/posts/1904673609597376

21 век будет веком, когда индивидуальность в потреблении выйдет на первый план.

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

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

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

И так далее.

При этом индивидуальность не означает однообразия. Наоборот. Полная свобода. Миллиарды комбинаций.

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

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

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

Говорили мы на эту тему со сторонниками кровавого энтерпрайза. С ТЗ на сотни листов, с глубокой многомесячной проработкой десятками аналитиков итп. Объяснял им, как наш продукт-то можно начать щупать уже через 2-3 недели.

Но в ответ получил две таких вот фразы
1. Этот ваш Скрум подходит для веб-систем, а для серьезных проектов не подходит.
2. Методология молодая, наш проектный подход проверенный и рисков меньше.

Что я могу на это ответить:
1. Итерации и инкрементальная разработка != гибкие методологии. Agile вообще про другое.
2. IID настолько стар, что про него писал ещё Брукс в своей "Серебряной пули нет". И он был далеко не первым. Шухарт вообще в 1967 умер. Да-да, цикл Plan-Do-Check-Act был задолго до написания Agile-манифеста.
3. Что только не делали с помощью IID. Даже самолёты. Ограничений на технологии не накладывает.
4. Величина рисков не зависит от методологии. Хотя использование незнакомых инструментов риски может породить. Зато убрать другие.
5. Scrum не произносится как "Скрум". Конечно, если вы не из Ланкашира, UK.

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

Жила-была компания #СоусПарк.
Ну вы помните эту компанию: https://t.me/cloveri/5

Однажды к HR-специалисту Вере пришел новый тим-лид Тарас и принес требования к двум вакансиям — подобрать программистов. Но вместо «Принято, пойду искать», услышал странный вопрос: «Зачем?».

– Что «зачем»? — спросил Тарас.
– Зачем тебе эта вакансия?
– Как зачем? От нас программист ушел. Вот я и принес требования к новому.
– А почему требования именно такие? — продолжила вопросы Вера.
– Я скопировал с другой нашей вакансии — ответил Тарас.

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

Да, но нет.
Следующий вопрос Веры был такой:

Что на _самом деле_ потеряла команда с уходом программиста?

Какие компетенции пропали из компании? Знание конкретных инструментов разработки? Практика работы по гибким методологиям? Опыт проектирования высоконагруженных систем? А какие из этих компетенций ключевые?

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

Вера умная. Будьте как Вера.

В следующей серии — про вторую вакансию Тараса.

В ФБ: https://www.facebook.com/WebByte/posts/1918163988248338

И снова про осознанность при подборе. Возвращаемся в #СоусПарк

Итак, если ищете кого-то на замену, хорошие вопросы — Какие компетенции на самом деле потеряла команда с уходом специалиста?. Что мы хотим восполнить?

Но что спрашивать, если команда растет?

...Оторвавшись от монитора HR-специалист Вера взглянула на тим-лида Тараса.

– Тарас, вторая вакансия — это тоже замена кого-то из ушедших сотрудников?
– О, нет! Мы растем! Нам нужны еще программисты! – ответил Тарас.
– Зачем?
– Ну... Э... Потому что нужно быстрее выпускать релизы. Быстрее доставлять пользователям продукт.
– Тарас, вспомни Брукса. — попросила Вера. — В своей книге «Мифический человеко-месяц» он писал, что добавление людей в проект не всегда приводит к ускорению. Почему ты считаешь, что в нашем случае нужны именно программисты?

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

Что _на самом деле_ нужно команде?

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

1. Дрейф требований

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

2. Неумение выпускать продукт небольшими порциями.

Вместо итерационной разработки мы месяцами готовим новый релиз и пытаемся приблизить сдачу добавлением людей. «Ресурсов», как говорят особо отмороженные PMы. В данном случае нужен навык инкрементального развития продукта, понимание практик создания MVP. Он точно у программиста?

3. Проблемы с процессами.

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

4. Сложная, запутанная архитектура продукта.

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

Не факт, что при росте команде нужен именно тот специалист, за которым пришел заказчик. Возможно, узкое место в поставке продукта — в какой-то иной компетнции.

Правильные вопросы — компас, который поможет HR-специалисту двигаться в нужном направлении, не терять время.

В чем ограничения команды? Кто ей нужен _на самом деле_?

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

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

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

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

Рисовать акварелью? Да пожалуйста. Собирать кубик Рубика? Нате. Писать на питоне? Вот вам. Проектировать био-скелеты? Да не вопрос.

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

12 лет назад я продал свой первый стартап.
А сегодня запустился третий.

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

В основе всего этого — модели компетенций. И оцифровка всех и вся. Мы оцениваем уровень IT-специалиста, сохраняем цифровой профиль (Skill Passport, цифровое портфолио навыков) и подбираем рекомендации на основе уровня.

Сейчас самое начало — про нас еще не писал Александр Горный, а инвесторы не выстраиваются в очередь. Мы еще многие вещи делаем вручную и проверка гипотез — наше всё. У нас есть первые продажи в B2B и понятны первые ограничения, не позволяющие продавать много прямо сейчас.

Сегодня мы открыли B2C историю стартом двух IT-профессий. Каждую неделю будем запускать новую (и рассказывать о ней зарегистрированным пользователям).

Мы рады экспертам, рады пользователям и просто посетителям нашего проекта #Кловери — https://cloveri.com/ . Рады любой обратной связи по всем каналам — здесь в ФБ, через сайт, через почту ask@cloveri.org и так далее.

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

Присоединяйтесь!

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

Коллеги задали вопрос: "Почему не даете рекомендации по развитию наименее проявившихся навыков?"

Отвечаю.

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

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

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

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

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

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

Отсюда и негативное отношение сотрудников. И к процессу, и к результату. И попытки накрутить метрики или результаты оценки - тоже отсюда.

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

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

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

Выступал на конференции тим-лидов.
Рассказывал про модели компетенций - что это такое, как создавать и использовать.
https://www.youtube.com/watch?v=HmpEsSZdHy0
Видео на 40 минут - 20 минут теория, 20 минут разбор практических кейсов.

#РазговорилисьСегодня про создание системы мотивации IT-департамента.

Вопрос интересный. И для IT-директоров, и для HR.

За что платить разработчикам, тестировщикам, админам? За текущий уровень владения компетенциями или за динамику их развития? За разработку ПО или за бизнес-показатели компании?

Как платить? Фикс? Фикс + премия? Фикс + бенефиты? Фикс + опционы? Как создавать систему "пряников"? Каждому свой пряник? Выбор из группы пряников?

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

1. Система грейдов / классов / уровней — сетка разной степени гибкости
2. Индивидуальное/командное премирование за результат — цели, критерии, вот это вот всё.
3. Привязка оклада к количеству развитых, полезных для компании, компетенций — быстрее развиваешься, больше получаешь.

А как устроена система мотивации у вас в компании?

Я боялся выступать и преподавать.

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

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

На первом публичном выступлении пересох рот, меня трясло. На втором ситуация не поменялась.

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

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

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

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

- необязательно отвечать на любой вопрос. Совсем нестыдно признаться, что ответа не знаешь.

А синдром самозванца никуда не денется.
Будь ты хоть финалистом всероссийского конкурса.

Не бойтесь передавать знания.
Это почти небольно.
Но потом сложно остановиться.

#РазговорилисьСегодня про согласование.

Знаю два вида согласования задач или документов.
- Устно (звонок, личная встреча, видеоконференция).
- В переписке (почта, мессенджер).

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

Почему акценты понимать трудно?

Потому что неясны эмоции написавшего.
А они влияют на смысл. Смайлики, количество восклицательных знаков или ЗАГЛАВНЫЕ буквы решают проблему лишь частично.

Потому что смысловое ударение может падать на произвольное слово. Простое предложение: "Мама мыла Раму". И сразу три оттенка смысла из-за ударения: "Именно мама мыла Раму. А не папа". "Мама именно мыла Раму. А не одевала". "Мама мыла именно Раму, а не Кришну". Неправильно поставили ударение? Вас неправильно поняли.

Скорость ТОЧНО выше?

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

Зачем повторять?

Затем, чтобы убедиться, что собеседник нас понял. Или, что мы его. Я часто возвращаю собеседнику его слова: "Правильно ли я понял, что вы имеете ввиду...". И частенько спрашиваю своих сотрудников: "Как ты понял мое поручение?". Реально помогает не переделывать.

В следующий раз - почему лучше писать, чем говорить.

20% продукта решают 80% проблем пользователей.

Часто, разрабатывая продукты или решая проблемы, мы об этом забываем. Срываем сроки, превышаем бюджеты. Переусложняем и кормим демона перфекционизма. Обратная связь от пользователей всё не поступает, команда не видит результатов и демотивируется. И сроки ещё больше срываются.

Что же делать?

Найти те самые 20% требований, реализация которых решит большинство потребностей.

Эти 20% можно назвать по-разному. "Критерии успешности реализации технического задания", "MVP" - неважно. Главное - найти.

Как искать?

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

Иногда я использую такой.
1. Выписываю цель создания продукта.
2. Выписываю список требований
3. Начинаю отбрасывать одно за другим
4. И задаю вопрос "Будет ли продукт без этого требования все ещё ценен для пользователя"?
5. Если ответ "да", отбрасываю и беру следующее.
И так - до тех пор, пока не найду минимальный набор.

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

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

Только во тьме — свет;
Только в молчании — слово.

Две строчки из песни Бориса Гребенщикова, которые иллюстрируют закон единства и борьбы противоположностей.

Каждый день в своей работе я сталкиваюсь с этим законом.

- Планировать или делать продукт без ориентиров?
- Искать сотрудников самому или ждать HR?
- Ждать обратной связи от клиентов или верить интуиции?
- Фиксированная оплата в месяц или за результат?
- Бэкенд или фронтенд?
- Процесс или результат?

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

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

- Задача фронтендера занимает слишком много времени? А если сделать ее на сервере?
- Процесс плохо идет? А какой результат мы ожидаем?
- Не мотивирует фикс? А если добавить премию за достижение целей?
- HR плохо ищет? А что если самому написать знакомым?
- Чересчур долго планируем? А если планироваться тщательно только на неделю?

Ищите противоположность. Тянитесь к ней.

Есть те, кто генерирует идеи.
Есть те, кто их доводит до практической реализации.

Часто это разные люди. Нормальная ситуация.
Одни про «Что сделать», а вторые — «Как сделать?»
Одни про будущее, другие про настоящее.
Одни предпринимают, другие производят.

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

Обе стороны можно тренировать.

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

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

Путь к мечте начинается с маленьких шагов.
Шагайте.

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

Но сдали. Отпустило.
А за пару дней до Нового года накрыло снова.
Простуда. И еще почти неделя из жизни выпала.

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

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

Причина — хорошая работа иммунитета.
Да-да, я не оговорился.

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

Что за гад подавляет иммунитет?

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

В стрессе организм мобилизуется — настраивается на борьбу или бегство. Вот только мы уже не наши древние предки. Тигра встретить на улицах мегаполиса — невелика вероятность. Поэтому в стрессе мы не бежим. А сидим. И тем самым обрушиваем на организм всю мощь гормонального сдвига.

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

Завтра выходные. Берегите себя, не болейте.

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

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

Цели - куда мы идём.
Что мы хотим получить в итоге.

Задачи - как мы идём.
Какие шаги нужно сделать, чтобы достичь цели.

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

Не путайте.

#РазговорилисьСегодня о бардаке.

Есть такое понятие у предпринимателей: "масштабирование убытков". Означает, что при притоке новых клиентов рост расходов идёт быстрее, чем рост доходов. Экономика не сходится - стоимость продажи выше, чем доход с нее. Например, привлекаете покупателя за 1000 рублей, а дохода - 900. 1000 клиентов принесут 100 000 убытка. Рекомендуют сначала поправить ситуацию, а потом уже вливать денег в масштабы.

В управлении людьми есть очень похожая ситуация.

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

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

И вот руководитель команды приходит к Главному и говорит: "Все проблемы - из-за нехватки людей".
Нужны ещё разработчики - начнем в срок делать.
Нужны ещё рекрутеры - начнем лучше подбирать.
Нужны ещё повара - начнем больше готовить.

Не начнут. Не сойдется "экономика".
Расходы на процесс будут больше, чем доходы от него.

Масштабирование бардака получится.

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

И тогда уж масштабировать команду, а не бардак в ней.

#РазговорилисьСегодня про обучение. Дескать, взрослые люди на то и взрослые, чтобы учиться вне зависимости от «хочу». Партия сказала: «Надо!». Народ ответил: «Есть!»

А вот нет. Хренушки.
Если мотивации нет — учить бесполезно.

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

После этого мы включили в анкеты опросы по мотивации.
И оказалось, что лишь 60-70% предлагаемых навыков интересно развивать. Даже взрослым, вполне профессиональным людям.

Почему так?

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

И это нормально.

Я сам очень не люблю разбирать и готовить юридические документы. Спасибо, Ольга Данилова отлично помогает. Зато мне вполне интересно изучать психологию общения.

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

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