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

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

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

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

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

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

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

А что, если вам попробовать объяснить своей поддержке, своим джуниорам суть Customer Development? Чтобы они не просто клиентов успокаивали, а еще и информацию собирали для развития? И идеи генерировали. Заодно мотивацию у джуниоров повысите. Чувство сопричастности — полезное чувство.

Пришла сегодня в голову мысль.

Вот есть майские указы президента, есть программа «Цифровая экономика». Много чего еще вокруг происходит, где говорят про необходимость модернизации, цифровизации и тому подобное.

И всё бы прекрасно, но перевод госструктур в цифру — очень дорогое удовольствие. Ну потому что там чиновники работают, а не IT-специалисты. А вокруг госстуктур вьются подрядчики, «кровавый энтерпрайз» — вот это вот всё. Этот железку продает, этот софт пишет. И у каждого своя маржа заложена. Ну а как без маржи-то? И переплачивает государство за софт. Ну а что делать? Зарплаты невысокие, программисты в очередь не встают.

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

И вот на фоне этого когнитивного диссонанса мысль следующая: дать выпускникам IT-специальностей выбор. Или в армию на год, или на альтернативную службу. Но не абы какую, а программистами, админами в госструктуры. Пару лет софт писать для Родины. Тысяч за сорок. А чтоб всякое г**но не получалось, к каждой десятке человек приставить вменяемого IT-шника. С опытом в корпорациях, стартапах. Тысяч за 250-300 в месяц. Всё экономия получится относительно текущей ситуации.

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

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

Не, ну а че не попробовать-то? Изменения — наше всё.

ФБ: https://www.facebook.com/WebByte/posts/1863513783713359

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

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

Читаешь прессу и видишь: «Этот тренер когда-то был хорош, но его прагматичный футбол никому не интересен». «У этого были титулы, но до сих пор играет в футбол прошлого десятилетия».

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

В другое ухо слышу: «Программистов нет, маркетолога днем с огнем...». Захудалого миддла в Москве меньше чем на 110-140 еще поискать придется. А уж классного нападающего вам никто меньше чем за 50-80 миллионов фунтов и продавать не станет.

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

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

Как устроен конвейер по попаданию футболиста в основную команду клуба? Скауты рыщут по всему миру, просматривая десятки и сотни детей с 4-6 лет. Оценивают по характеристикам, наиболее перспективных приводят в клубные академии. Затем годы упорных тренировок по развитию потенциала. Юношеские команды, U-17, U-19, U-21 и так далее. Всё ради того, чтобы однажды клуб получил своего Месси. Или Роналду. Или хотя бы Погбу. Механизм отлажен. Конкуренция — двигатель развития спортсмена.

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

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

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

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

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

Всё, что позволяет мозгу расслабиться, мозг любит.
Перестали собираться на утренние стендапы? Мозг: "Ура!". Перестали писать тесты? Мозг: "Ура-ура!". Перестали бегать по утрам? Ну вы поняли, да?

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

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

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

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

Вёл на днях занятие про технические основы интернета.
Зашла речь про протоколы и API.

Как объяснить людям, что это такое?
Помогли собаки.

Протокол — по сути набор соглашений, по которому происходит обмен данными. Или еще проще — команды и ответы на них.

Вот, скажем, во многих собаках есть поддержка базового протокола послушания. «Сидеть», «стоять», «лежать», «фу» — эти команды знакомы многим собакам. Может быть разная скорость отклика. Может быть разная реализация, как именно реализуется «лежать». К примеру, одна моя знакомая собака на эту команду ложится на бок. Примерно также и веб-серверы поддерживают HTTP — протокол передачи гипертекста. Очень похоже поддерживают. Но местами есть нюансы.

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

У собак API тоже есть. Вот, к примеру, мой Ферги и мой Edwin выставляют наружу расширение базового протокола. Например, в него входит команда «Обнимашки». Но есть у них и отличия. В одном псе реализована команда «На спинку». А второй эту команду не знает, но неплохо поддерживает команду «Леж».

Всего в API моих собак несколько десятков команд.

Есть команды перемещения в пространстве: «Право», «Лево», «Вперед», «Обойди». Есть команды, связанные с приемом пищи. Это вообще наиболее хорошо реализованный блок команд: «Кушать», «Жрать», «Рубец», «Помидор», «Вкусняшка», «Печенка», «Мясо» и даже «Трахея». Все эти команды (и еще 30-40 обозначений еды) прекрасно известны моим псам. А вот команда «Голос» не реализована. Вместо нее старший реагирует на «You scouse bastard!». Профессиональная деформация у него.

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

Ретроспектива — крайне полезный инструмент. Не знаю уж почему участие в таких встречах считают скучным и неинтересным.

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

Почему новую фичу запустили в срок? Потому что вовремя предупредили админов о настройке БД? Потому что тестировщики участвовали в обсуждении требований? Зафиксируем. Попробуем повторить еще раз.

Почему в нашем ресторане блюдо стало в стоп-лист в пятницу вечером? Потому что было недостаточно заготовок? Потому что закончился какой-то ингредиент? Зафиксируем.

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

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

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

Ретроспектива — та же обратная связь.
А обратная связь — наше всё.
Цените ретроспективы.

Рынок программистов похож на рынок футболистов. Хорошие стоят достаточно дорого. Начинающие с трудом могут попасть в свою первую команду.

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

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

Представьте себе HR'а, который в блокнотике имеет десятки программистов. Помнит, кто где работает, знает, на каких условиях. Раскручивает их личные бренды, организовывает выступления. И раз в полтора-два года помогает поднять зарплату. Или перейти в новую компанию. И берет свои бонусы за переход. 50. 100. 150К. Представили? Облизнулись? Не забудьте старика, когда реализуете эту идею :)

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

В каждой шутке есть доля шутки. А в каждом программисте дремлет свой Неймар, Модрич или Кейн. Интересно, в скольки HRах дремлет Мино Райола?

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

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

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

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

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

Мне нужны 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://www.tg-me.com/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/ . Рады любой обратной связи по всем каналам — здесь в ФБ, через сайт, через почту [email protected] и так далее.

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

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

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

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

Отвечаю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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