ПРО МАТРИЦУ КОМПЕТЕНЦИЙ

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

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

Матрица компетенций - это своего рода специальная "линейка", которой можно измерить квалификацию сотрудника и присвоить ему какую-то категорию: грейд, разряд, звание и т п.

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

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

Как ее превратить в артефакт? Вот это, пожалуй, самый сложный вопрос. Давайте разбираться.

Матрица компетенций должна включать 3 основных блока:
1. Описание навыков и их уровней
2. Требования к категориям (необходимые уровни по навыкам)
3. Путь перехода между категориями (сам маршрут, и требования по прокачиванию скиллов)

Здесь вроде все понятно. Собираем скиллы, расписываем по ним уровни (у нас это были звездочки). Потом создаем сетку грейдов, указываем, сколько звездочек по каждому навыку должно быть, и почти готово. Останется сетку связать графами переходов и определить дельту.

А теперь самое интересное.

Вопрос#1 - А как определить полный список всех скиллов?

Тут придется фантазировать. Условно все скиллы можно поделить на 2 большие группы:
- Что нужно уметь делать
- Как нужно это делать
Почти как хард-скиллы и софт-скиллы, очень похоже.

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

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

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

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

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

Вопрос#2 - Сколько должно быть категорий?

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

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

Вопрос#3 - Все сотрудники должны соответствовать требованиям матрицы?

Если матрица построена хорошо и учитывает интересы бизнеса, то да, все.

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

Это были основные вопросы. Если у вас есть другие - смело пишите. Разберем здесь или чуть позже в рамках Вопросника.

ВОПРОСНИКУ БЫТЬ

Я собрал ваши голоса и вопросы, все честно подсчитал, результаты позитивны, а значит Вопросник запускаю 🙂

Всем спасибо за отклики и обратную связь!

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

Хотите добавить свой вопрос - пишите в комменты, в директ, или в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

Разборы буду публиковать здесь, ничего не потеряется!

Минутка юмора)

ВОПРОСНИК#1

А вот и первый выпуск Вопросника! Сегодня текстом.

Вопрос:
Может ли команда разработки (или несколько таких команд между собой) существовать и взаимодействовать без формального тимлида? Типа без вертикальной иерархии. Насколько эффективна такая модель по сравнению с той, где в команде есть тимлид?

Ответ:
Если верить спиральной динамике и концепции бирюзовых организаций, то да, такое возможно. Насколько это работает в реальной жизни – большой вопрос.

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

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

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

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

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

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

И в итоге команда работает почти также неэффективно с тимлидом, как работала бы и без него. Ну или почти также. Хоть какую-то пользу он же приносит 🙂

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

Надеюсь, получилось ответить на вопрос.

P.S. Задавайте новые вопросы любым удобным способом: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

А у меня опять хорошая новость!

SmartUp запустил свой блог на CNEWS https://smartup.cnews.ru/

Там уже не столько про технику, сколько про бизнес. Но тоже жирок!

Коллеги, я к вам с вопросом!

Хочу поразвиваться в копирайтинге. Какие полезные книжки посоветуете по теме?

Или может каких-то авторов/блогеров, которые вас вдохновляют?

Сейчас читаю "Как не съесть собаку". Ничего так. Но хочется больше.

ВОПРОСНИК#2

Второй выпуск Вопросника! Этот тоже лучше текстом.

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

Ответ:
Здесь, как и в распространенном вопросе “Как руководителю выйти из операционки”, ответ кроется в избитом слове “Делегирование”. Правильное делегирование – залог успеха.

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

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

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

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

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

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

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

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

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

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

Надеюсь, получилось ответить на вопрос.

P.S. Задавайте новые вопросы любым удобным способом: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

Картинка по теме)

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

https://habr.com/ru/post/716070/

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

ВОПРОСНИК#3

И моя любимая картинка как нельзя кстати 🙂

Вопрос:
Интересует тема пуша работничков (понятно что надо искать мотивацию и через нее пытаться), но мб еще какие-то мысли есть и нюансы?

Ответ:
Все верно, здесь все строится вокруг мотивации. Сотрудники – это партнеры. И у вас с ними есть определенные договоренности, кто что делает, и что за это получает.

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

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

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

А дальше есть стандартный алгоритм, который может быть скорректирован в зависимости от тоталитарности вашего стиля менеджмента:

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

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

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

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

Отрицательная мотивация всегда работает хуже, чем положительная. А внешняя – хуже чем внутренняя. Поэтому дешевле и проще понять человека, определить, что его мотивирует, а что демотивирует, и потом стараться давать ему то, что он хочет, и не делать того, что ему в тягость. Ну а если это не работает, то подтягивать мотиваторов, желательно (но не обязательно, здесь как хотите сами) в том порядке, как я написал.

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

Надеюсь, получилось ответить на вопрос.

P.S. Задавайте новые вопросы любым удобным способом: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

ПОЧЕМУ МАНИПУЛЯЦИИ РАБОТАЮТ

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

Так почему же это все работает, несмотря на то, что везде про это пишут и все про это знают?

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

Конечно, каждый скажет: "Это вообще не про меня! Я мыслю только рационально!". Мыслишь, но это тоже про тебя, мой друг 🙂

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

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

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

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

Будьте бдительны и удачи в переговорах!

ИСТОРИЯ О ТОМ, КАК МЫ SCRUM ВНЕДРЯЛИ

В далеком теперь уже 21 году случилась у нас в компании Lineate реорганизация. И стал я тогда руководителем всего продакшна. А вместе с задачей по построению новой оргструктуры была нам с командой поставлена задача внедрить везде Scrum.

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

Scrum - стильно, модно, молодежно. Сложновато, но интересно. И плюсов от такого изменения не счесть. Выглядит перспективно!

Но во всей этой ложке меда была нормальная такая бочка дегтя: у нас было больше 30 проектов, и все абсолютно разные. Были проекты поддержки на пару часов в неделю одного инженера. Были ватерфольные фиксбиды с командой в 15 человек. Были средненькие T&M-ы на 5-7 человек. Очевидно, взять и сходу раскатать одинаковую схему Scrum-а на все проекты не получится. Пришлось креативить.

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

Так вот, история. Мы пошли к нашему руководству и стали выяснять, почему и зачем Scrum. Оказалось, что нужен не так чтобы прям Scrum, но нужен удобный механизм для контроля и управления скоростью работы команды и каждого человека в ней, который будет очевиден и понятен всем в индустрии. А Scrum это умел из коробки. И любой человек в IT уже знает про Scrum. Словом, идеальный кандидат.

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

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

Спустя полгода мы развернули наш Scrum уже на 90% проектов и смогли сильно выровнять эти проекты, сделав заказчиков счастливыми. Наш продакшн стал управляемым и эффективным, а руководство получило метрики контроля за ситуацией, как в разрезе всей компании, так и в разрезе каждого проекта и даже сотрудника.

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

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

ПРО МЕНТОРИНГ И КОУЧИНГ

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

Кстати, доклад для митапа DevRel Meetup SPb #3, будет 17 марта в баре на Ваське. Приходите, будет 4 разных и интересных темы на повестке. Ссылочка на мероприятие вот https://www.meetup.com/devrel-spb/events/291069709/

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

Тема дискуссионная. Мое личное мнение - нет. И основная ценность ментора как раз в том, что у него ЕСТЬ собственные знания и опыт, которыми он МОЖЕТ и ДОЛЖЕН делиться. Коучинг же про поиск ответа ВНУТРИ себя. Коуч НЕ ДОЛЖЕН давать советов, только направлять.

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

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

А бывают запросы на "рыбу", без "удочки". Конкретная проблема с конкретным решением. И решается она, зачастую за 1-2 часа сессии. Но это уже не совсем менторинг, скорее консалтинг/эдвайзинг. Тут и коучинг будет излишним, все и так понятно.

Согласны? Подискутируем? Делитесь своими мнениями, обсудим.

ВОПРОСНИК#4

Вопрос про процессы в IT, конкретно – про роль архитектора.

Вопрос:
Какова роль архитектора в небольшой команде (10-15)? Насколько этот архитектор будет эффективен в середине или в конце проекта (если берем стандартный цикл разработки, где конец проекта это выпуск в прод и отдача его на поддержку)?
Насколько эффективно будет выполнять роль архитектора одному из back/front или вообще аналитику?

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

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

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

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

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

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

Надеюсь, получилось ответить на вопрос.

P.S. Задавайте новые вопросы: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

ПРО ЦЕЛИ

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

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

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

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

Из чего состоит SOSTAC:
S – Situation analysis → Анализ текущей ситуации, где мы находимся
O – Objectives → Цели, к которым мы должны прийти
S – Strategy → Стратегия, как мы собираемся достичь цели
T – Tactics → Тактика/инструменты, которые мы будем использовать
A – Actions → Конкретные действия, задачи и сроки
С – Control → Контроль, как и по каким показателям мы поймем, что достигли цели или отклонились от курса

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

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

Цели - вытекают из колеса баланса. Тут может быть 2 подхода: закрывать самые большие пробелы или фокусироваться на самых важных составляющих. Кому какой ближе. А сами цели мне нравится формулировать через OKR-ы. Получается воодушевляющая и мотивирующая формулировка цели, как девиз, с которой хочется просыпаться по утрам, например "в здорово теле - здоровый дух". И для нее несколько измеримых и засмартованных ключевых результатов, которые и раскрывают, а что это все значит для вас: вылеченные старые болезни, комфортный вес, спорт и т п.

Стратегия - верхнеуровневый план, как достигать цели. По каждой цели! Главное в стратегии - некоторая киллерфича, почему именно эта стратегия приведет именно вас к именно этой цели.

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

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

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

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

Попробуйте! И расскажите о результатах 🙂

Написал небольшую статью про правильную постановку задач и контроль с учетом особенностей сотрудника https://habr.com/ru/post/718114/

ПРО СТРАТЕГИЮ ГОЛУБОГО ОКЕАНА

Сегодня немного о высоком - о стратегии.

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

Яркий пример - компания Apple. Придумали iPod - дали толчок развитию медиаиндустрии. Придумали iPhone - стартанули индустрию смартфонов. Придумали AirPods - теперь на полках только такие наушники кругом. В общем, законодатели.

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

И как это все понимать? Кто прав?

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

А если вы хотите не просто успеха, а сверхуспеха, то нужно изобретать что-то новое. Но представьте только, сколько ресурсов потратил тот же Apple на создание любого своего продукта? Такие ресурсы есть у среднестатистического бизнеса? Чаще всего, нет.

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

Коллеги, хочу напомнить про Вопросник!
Задавайте вопросы, я подробно их разберу и опубликую ответ.
Вопрос по любой тематике. Но ценны будут ответы про менеджмент в IT 🙂 Про остальное с радостью порассуждаю.
Можете писать в личку @ilya_prakht, можете сюда в комментарии, можете в анонимную форму https://forms.gle/yguM6swyLCvFbJ858

ИСТОРИЯ О ТОМ, КАК МЫ SCRUM ВНЕДРЯЛИ #2

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

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

На этой встрече мы от лица продакшена рапортовали о состоянии проекта, награждая его каким-то цветным значком, и немного расшифровывали, что это все значит. Значков было 4, названия их говорящие, так что не запутаешься: critical, warning, good, uncertain. Критикалы - плохо, ворны - не очень, но ситуация под контролем, гуд - значит мы в порядке, а ансертн (как же странно это пишется по-русски) значит, что информации нам недостаточно.

Были определенные правила выставления этих статусов: по наличию кризисов, по просроченным дедлайнам и т д. И вот, с появлением Scrum в нашей продакшенской жизни, появились и интересные цифры, которые нашли отражение в статусах проектов. Помните, я как раз рассказывал, зачем нам нужен был Scrum, и что из него мы внедрили? Вот это все и работало здесь: commitment, velocity, backlog size.

Львиная доля наших проектов показывали одну и ту же картинку из недели в неделю: велосити постоянно было ниже коммитмента. С одной стороны, это ок для Scrum-а, некий коридор нужно закладывать. Это правда. Но расхождения были серьезные, больше 50%, и это происходило постоянно.

Да, Scrum помог и подсветил нам проблемные точки. Хотя бы этим он уже окупил все наши страдания по его внедрению)

Пока мы разбирались, в чем же дело (а причин там много, и на каждом проекте, по сути, они были свои), наш топ-менеджмент не хотел ждать. И мы получили новую инструкцию по определению проектных статусов: если велосити ниже 80% коммитмента - это warning, если ниже 50% - critical.

Ох как же неудобно нам стало жить с этим. Вместо типичных 1-2 критикалов в неделю, мы стали показывать до 10 критов! И ведь за каждый надо было отчитываться, показать план, а что мы делаем, чтобы проект вернуть к жизни, и т д. Пришлось поработать нашим деливери-менеджерам...

Мы ворчали, жаловались, что Portfolio Review превратился в какой-то шум, теперь непонятно, что на самом деле с проектом, и как вообще можно на это ориентироваться и все в этом духе. Даже пытались внедрить штуку аля "реальный статус проекта", но не получилось (спойлер - и хорошо).

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

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