А вот и видео со вчерашнего онлайн-митапа https://youtu.be/FHeoDeHAUJs

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

В конце самый "жир" - небольшой чеклист, что должно быть в вашем процессе PDP, чтобы его можно было считать хорошим и системным.

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

ПРО ПЛЮСЫ МЕНТОРИНГА (НЕ САМЫЕ ОЧЕВИДНЫЕ)

Еще разок немного порассуждаем на тему менторинга.

Во многих материалах всегда выделяют несколько очевидных плюсов менторинга:
- Доступ к чужому опыту и знаниям
- Свежие идеи и инсайты
- Возможность взглянуть на проблему/ситуацию со стороны

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

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

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

- Объективная оценка
Это отчасти пересекается с "Возможностью взглянуть со стороны", но я немного о другом. Ментор не будет вас жалеть. Если вы совершили ошибку, он так и скажет: "это ваша ошибка". Согласитесь, часто сложно признаться самому себе, что ты где-то налажал. А тут выпадает такая уникальная возможность. Помогает задуматься и, опять же, взглянуть на ситуацию под новым углом.

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

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

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

А я с хорошей новостью!

Мы в SmartUp запустили блог на Хабре! Будем там писать про наши проектные кейсы, иногда какие-то менеджерские истории, но меньше.

Технический жирок для ценителей 🙂

https://habr.com/ru/company/smartup_tech/blog/713730/

Друзья!

Я хочу адаптировать темы, про которые здесь пишу, под ваши интересы. Для этого запускаю новую активность с кодовым названием "Вопросник".

Суть очень проста: собираю от вас вопросы и темы, которые хочется рассмотреть поподробнее, а потом формирую ответы, в формате коротких видео или текста. По наиболее востребованным тематикам сделаю подробные разборы.

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

Пишите свои вопросы любым удобным способом: в комменты, в личку, как угодно. Для самых стеснительных сделал анонимную гуглоформу https://forms.gle/yguM6swyLCvFbJ858. Пользуйтесь!

Чуть позже расскажу, где и когда ждать первых разборов 🙂

Что скажете? Стоит такое запилить?

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

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

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

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

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

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

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

Матрица компетенций должна включать 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