Конференция DSE Fest — технично и понятно про data science для разработчиков. Смотри детали на сайте
×Закрыть

Строим сильную команду: от 0 до 100

[Дмитрий Зиновьев — Software Engineering Manager в EPAM, 11 лет в IT]

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

История моей команды

Четыре года назад мы начинали работу командой в 20 ребят. Был только потенциал и безудержное желание растить экспертизу, чтобы иметь возможность работать с проектами любой сложности и технологических стеков. Цель была работать на перспективу, не утопая в текущей реальности. Шаг за шагом, квартал за кварталом мы построили эти процессы. Спустя два года повторили эту стратегию с двумя новыми дисциплинами в нашей команде. Сейчас у меня в команде более 170 замечательных и компетентных специалистов. 80% команды продолжает развивать и инвестировать в практику на регулярной основе.

Какие трудности возникают

Каждая уважающая себя software engineering компания хочет делать вклад в продукт, который она реализует. И каждый уважающий себя software engineer тоже хочет видеть результаты своего труда. Следовательно, вектор стратегии развития компании должен лежать в плоскости роста экспертизы.

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

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

В таких условиях самая главная инвестиция любого управляющего — команда. И задача не состоит в том, чтобы набрать сильных и самостоятельных людей с рынка. Цель — непрерывная инвестиция в лидеров (Continuous Leadership Growth). Это непростой подход, так как окупаемость инвестиций местами измеряется годами.

Зачем нужна непрерывная инвестиция в лидеров?

Рассмотрим стандартный процесс старта нового проекта, не вдаваясь в детали. Мы получили Request for Proposal (RFP). Путём длительного анализа и общения с клиентом мы подготовили прагматичный вариант с нашим решением, заложенными рисками, планом и прочими артефактами. Опустим pre-sale фазу и предположим, что путём сложных переговоров мы выигрываем тендер на условиях команды из 20 человек и сроком на год. Для систематического достижения результата нам нужна команда ключевых специалистов в размере 4-6 человек (для меня «ключевой специалист» — это специалист с атрофированными слёзными железами и высокой компетентностью в предметной области).

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

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

Непрерывная инвестиция в лидеров

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

Особенность CIS-рынка

На пространстве СНГ IT-специалисты растут в основном эмпирическим путём, не имея профильных учреждений для подготовки production ready software engineers. Плюсы — люди весьма мотивированы, так как пришли в IT в большей степени на своём энтузиазме. Минусы — у людей часто нет чётко структурированного вектора профессионального роста. В среднем при таком подходе люди выходят на уровень ключевых специалистов спустя 5-8 лет. Некоторым недостаточно и 10 лет.

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

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

Профиль специалиста

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

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

Берём стандартное распределение на junior, middle и senior. Каждый профессиональный уровень состоит не только из набора технических навыков. Цель каждой должности — это роль и связанные с этой ролью уровни ответственности, которые специалист может на себя взять и успешно выполнить поставленную задачу. То есть по данной шкале специалист уровня senior, помимо хорошего технического опыта, должен быть самостоятельным, иметь навыки выстраивания отношений с командой и клиентом, работать с конфликтами, эффективно интегрировать новые тренды, брать на себя ответственность за результат, тем более, если тот был построен на базе его предложения, и так далее. Заметим, что требования к персональным навыкам (soft skills) столь же высоки, как и к техническим.

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

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

Прозрачность роста для специалиста и компании

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

Что если специалист выполнит поставленные перед ним задачи? Компания, скорее всего, должна будет пойти на два шага: пересмотреть финансовую сторону вопроса и перевести человека на новую роль. Допустим, в финансовом вопросе обе стороны пришли к компромиссу. Что касается новой роли, это не должна быть лишь громкая должность: «Все, теперь ты Team Lead, продолжай педалить». С новой должностью должны раскрываться новые зоны ответственности и задач. К сожалению, в некоторых компаниях люди могут формально пройти путь Software Engineer, Team Lead, Business Analyst, Product Owner, но при этом неформально оставаться Software Engineer, не получая новых знаний в смежных областях.

Компания предоставила план роста, но как она готова его поддерживать? «Вот план, вот проекты — будущее в твоих руках!», — далеко не всегда рабочая схема для эффективного роста специалистов.

Существует три заблуждения касательно эффективного роста посредством смены проектов.

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

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

Но как только специалист начинает свой день с чёткого понимания последовательности действий (например, митинг с клиентом в определённое время, список задач на итерацию, какие задачи на кого стоит распределить, порядок операционных активностей и с чего начать выполнение собственных задач), в этот момент мозг начинает всячески оправдывать заслуженный отдых после сложного старта. Что приводит к фоновой прокрастинации: чуть дольше пил чай, заговорился с коллегой, читал непрофильную литературу и так далее. Сам отдых — это прекрасно, но он никак не коррелирует с профессиональным ростом.

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

Третье заблуждение. Между проектами редко меняется сложность. Смена предметной области привносит новые тонкости, но для Software Engineer абстрактно задачи имеют общие черты: сущности, коллекции, межсетевые взаимодействия, формы, валидация, API и так далее. По сути, для молодого специалиста все проекты можно обличить в один домен, например Healthcare или CMS. Если роль специалиста остается прежней, то со временем он лишь набивает руку для более эффективного выполнения однотипных задач.

Учитывая эти подводные камни, фактического роста у специалиста, который 5 лет подряд сидел в рутине, может и не быть. Для выхода на новые горизонты каждый из предыдущих проектов должен привнести новый навык. Например:

  • Первый проект: я научился работать в команде.

  • Второй проект: я научился делать сложные части системы самостоятельно с качественным результатом на выходе.
  • Третий проект: я научился делать проект с нуля.
  • Четвертый проект: я научился работать в сложных условиях.
  • Пятый проект: я получил опыт миграции сложной системы.
В таком случае я как Software Engineer, скорее всего, могу претендовать на более высокую должность и заработную плату, так как компания с большей вероятностью может рассчитывать на меня в достижении цели. Подобные достижения минимизируют риски в будущем.

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


  • участие в технических интервью, чтобы научиться подбирать себе надежную команду;
  • управление внутренними активностями и проектами, чтобы получить опыт управления командами и достижения результата;
  • привлечение к pre-sale новых проектов, чтобы научиться строить релевантные планы, предложения и так далее.

Подготовка молодых кадров

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

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

Сложность данной инвестиции в больших сроках её окупаемости. Требуется 3-4 года, чтобы молодые кадры вышли на уровень ключевых специалистов. К тому же подобные процессы должны быть системными, а это требует долгосрочного планирования и следования ему, адаптируясь под обстоятельства. Поэтому подобные инициативы требуют сильных лидеров на местах. Последняя фраза будет встречаться в статье крайне часто :)

Тренинги и наставничество

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

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

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

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

R&D, инвестиции в новые тренды

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

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

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

Рассмотрим оба шага в отдельности.

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

  • кто создатель этого решения?
  • есть ли у этого решения поддержка сообщества или платная поддержка 24/7 (что особенно критично для большого бизнеса)?
  • удовлетворяет ли данное решение всем требованиям бизнес-процессов?
  • есть ли прозрачные планы по стабилизации и модернизации этого решения с запланированными датами релиза?

  • какие сильные и слабые стороны, риски и перспективы (SWOT-анализ)?
  • как данное решение будет интегрироваться в уже существующую среду компаний?

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

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

Сообщество и глобальный опыт

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

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

  • менеджмент-команда, координирующая все процессы внутри практики;
  • прозрачные процессы и возможности, каждый должен иметь возможность присоединиться и поддерживать систему;
  • новости в компании и индустрии;
  • работа со входящими запросами со стороны бизнеса (консультация, аудит, помощь с pre-sale и т. д.);
  • разработка общего вектора развития дисциплины;
  • доступность информации;
  • offline-мероприятия.

Оценка

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

В моей практике формат формального check list и принятие решения на основании мнения руководителя работали малоэффективно и лишь порождали больше вопросов.

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

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

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

Подводя итоги

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

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

LinkedIn

45 комментариев

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

Полностью согласен с таким мерилом сеньора, но с ним в последние пару-тройку лет не согласны 90% соискателей :-) Что в разы усложняет закрытие вакансий и формирование команды.

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

Что в разы усложняет закрытие вакансий и формирование команды.

Ну так зарплату таким выше давай. Ставь в вакансии сразу высокую зарплату.

Действительно инфляция зарплат имеет место быть. Тем не менее никто не ограничивает компанию в высказывании собственной стратегии, ценностей и предлагать свой job offer. На моей практике, кандидаты далеко не всегда ориентируются на финансовую компенсацию. Конечно если она не разниться в разы :)

Да к твоей статье у меня особо претензий нет. Кроме заголовка — «С нуля до ста» должно быть.
Просто осточертело это нытье про «сеньоры не те», «народ не тот».

Я понимаю, поэтому согласен с твоим комментарием выше. «Люди не те что были раньше» наверное самая забитая фраза во все времена :) и да эти обстоятельства лучше использовать нежели осуждать, так как осуждение не принесет больше прибыли. Как опция: повышения стоимости сервисной организации, смена профиля в сторону более комплексных решений или наоборот узкой направленности, фильтрация нужных клиентов, пересмотр внутренних регламентов и принципов организации, вовлечения ключевых людей в долю/партнерство и т.д. Вариантов много, только они все заставляют менять в первую очередь собственную модель мышления, а это всегда сложно. Местами даже не приемлемо :) Каждый из нас проходит этот этап самоанализа много раз.

Я бы не списывал Angular раньше времени.

Соглашусь. С приходом крупных игроков в лице Google, Facebook и других, JavaScript мир только начал обретать взрослые формы. Это закономерно сформировало мировое сообщество. Что в свою очередь подтолкнуло бизнес идти по стопам проверенных и поддерживаемых решений. Как результат Angular (и прочие решения) стали частью многих систем на уровне коробочного решения. Все это ведет к тому, что пласт индустрии, где будет востребована менее трендовая технология все равно будет существовать и вероятно длительно время обеспечивать специалистов трудовыми местами.

Спасибо Саша за комментарий :)

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

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

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

Что касается ставки на первый Angular, я верю она не напрасна, если процесс повышения квалификации был построен на базовых принципах разработки, а framework был лишь одной из стратегий реализаций этих знаний. В таком случае специалисты с сильным core JavaScript (и возможно предыдущему опыту на Python, PHP, .NET, etc.) не испытывают сложности при переходе из одного решения на другое. Новый framework должен расширять границы мышления а не строить бетонный забор с единой религией на борту.

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

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

Снова наблюдаю эту канву). Вам не кажется, что такой подход содержит взаимоисключающие параграфы? Как это выглядит: в вакансии Вы пишете «ангулярщик», собеседование Вы проводите как ангулярщика, требуете (самое важное) опыт ангулярщика, а потом Вы же хотите, чтобы человек переходил на реакт? Очевидно, что такой вариант подходит далеко не всем с оглядкой на последующее трудоустройство — исключительно в случае, если это совпадает с личным планом развития... т.е., вероятность попасть на такой вариант околонулевая.

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

Так не об этом же речь :-) Удивляться тут нечему. Конечно берем ангулярщика. Суть комментария касалась в целом вопроса инвестиций в команду (обучения и т.д.) и я озвучил один из рисков, которые постоянно возникают. Компания видит тренд, что Ангулар проигрывает рынок Реакту. Плюс бурный рост РеактНейтива на фоне кривости аналогичного НейтивСкрипта от Ангулара и т.д. И компания хочет менять упор в технологиях, в результате которого ощутимая (бОльшая) часть команды уже не подходит приоритетам компании и ее приходится менять. Это констатация факта, а не жалобы :-)

Подчеркнул для себя интересные мысли.

Спасибо, Дмитрий!

Очень интересная статья, Дим! Спасибо! :)

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

Спасибо, Александра!

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

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

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

Чтобы «растить и поддерживать своих же людей» нужно иметь постоянный приток новых проектов, чтобы этих людей содержать. А аутсорс проекты (консалтинг) имеют жизненный цикл. Один проект закончили, другой вовремя не нашли и все эти специалисты уходят искать себе другую работу!

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

Спасибо Игорь за комментарий!

Контекст моей статьи лежит как раз в плоскости сервисных организаций. Да, действительно есть задача по налаживанию потока проектов. В эту область вовлекаются большинство высококвалифицированных специалистов из команды (как extra miles), чтобы наладить рапорт с клиентом, в то время как мы будем собирать необходимую команду для успешной реализации этого проекта.

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

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

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

Спасибо.
Мне вот интересно, сказывается ли на эффективности работы, место, где специалист решает задачи (офис/удаленка) и если это офисный формат, то всякий контроль посещаемости. Знаю некоторые «руководители» любого ранга, очень любят ощущение некой власти и глумиться над подчиненными что они опаздывают или приходят/уходят не вовремя.
Иными словами, так ли важна организационная дисциплина для специалистов высшего ранга (Джунов в расчет не берем, их нужно гонять всегда) или она лишь негативно влияет на общий результат?

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

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

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

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

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

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

— не многие специалисты способны самостоятельно мотивировать себя к эффективному труду работая из дому

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

Спасибо Виктор за комментарий!

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

Согласен, что хорошо поставленный процесс нивелирует ряд сложных ситуаций и помогает кооперации распределенных команд. И чем сложнее производственный процесс, тем больше промежуточных процессов потребуется интегрировать. В условиях того, что качество интеграции процессов лежит на плечах людей, то это привносит дополнительные расходы по времени (вовлечение, контроль, направление, поддержка, решение конфликтов и т.д.) Что касается личного контакта, социальная ценность его по прежнему велика, так как мы все люди и даже небольшая эмпатия дает большей эффект в переговоров, нежели формальный путь их достижения (не берем в расчет формальное заключение по итогу переговоров, она нужна всегда, ИМХО).

Что для тебя значит «много».

Целиком согласен, это мое видение, как результат интерсубъективной реальности. Опираясь на цифры, я работал в разных сферах: freelance, продуктовых и сервисных компаниях. За это время по грубой оценки мне удалось плотно поработать в разных контекстах с 600 специалистами. Высококвалифицированных из них было порядка 60-80. Среди этой небольшой группы было менее 10 людей, которые были:
— само-мотивированными
— имели собственные долгосрочные планы
— могли работать автономно
— не требовали лишнего внимания к себе
— отлично интегрировались в коллективы
— соблюдали регламенты проектов, где того требовалось
Исходя из этого я, опираясь на свой опыт, могу сказать что таких специалистов мало.

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

Немного спасает аутичность большинства програмеров.

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

У меня где-то выходило 40% «мотивированных», 60% нет. Но я больше старался работать в продуктовых небольших компаниях. Так что моя выборка специфична.

Можно попросить, любопытства ради, описать размеры небольших продуктовых компаний? Полагаю в разрезе 10 человек подобное разделение имеет право быть (ИМХО).

До 100-250 человек. Но обычно над проектом работает группа 5-30 человек.
Просто пока продуктовая не вышла за размер пары сотен, там половина где-то замотивирована — планктона еще немного. Задачи в продуктовых обычно интересные и ими занимаются те, кому оное сильно нравиться — иначе не достигнешь нужного уровня опыта и знаний и результата.

Спасибо за детали, совпадает с моими наблюдениями.

Вот тут ИМХО оптимистично:

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

А что, если: (3) человек говорит, что он выполнил поставленные задачи, а компания готова его поддерживать, не удостоверившись ?

В моей практике формат формального check list и принятие решения на основании мнения руководителя работали малоэффективно

Аналогично. А вот то, о чем пишеЦЦа далее в разделе «Оценка», относицца скорее к Perfect World и вряд ли может быть формализовано. Лично я опять прихожу к тому, что данный процесс не может быть обЪективным ... прозрачным — наверно да :) . И вопрос только в том, как там на уровень выше обстоят дела с камнем № 3 :(

Спасибо за комментарий, Евгений!

Касательно момента, когда «человек говорит, что он выполнил поставленные задачи, а компания готова его поддерживать, не удостоверившись», это ситуация описывающая некомпетентность менеджера в первую очередь. Менеджер мог быть неопытен и не установить четкие рамки принятия результатов, или менеджер поставил задачу с позиции занять человека, не думая о перспективе. В любом случае таких ситуаций может быть очень много. Варианты результатов:
— доведенный проект до конца: в рамках оговоренных приемочных критериев и качества, клиент доволен и хочет продолжать сотрудничать
— сотрудник взял инициативу, например создать и провести тренинг: решил организационные вопросы, вовлек людей, провел тренинг, результаты тренинга получили позитивный отклик у остальных сотрудников и полученные знания дают положительный эффект в проектной деятельности (последнее требует больше времени для накопления обратной связи)
— заведенный проект в компанию: сотрудник поехал onsite, решил вопросы и сомнения клиента, осветил прагматичный план утвержденный всеми заинтересованными лицами с обоих сторон и клиент подписал контракт

Теперь по второй части комментария. Понятия «Perfect World» не существует, так как идеалы это лишь персональное представления каждого индивида с собственными рамками. Уход в крайности всегда плохо. Порядок в каком-то приближении нужен. Качество оценки можно улучшить путем привлечения большего количества экспертов (в идеале не связанных между собой на эмоциональном уровне), так как люди всегда субъективны. Но в определенный момент достижения 100% качества требует колоссальных ресурсов и как правило никогда не оправданно.

спасибо за ответ.

это ситуация описывающая некомпетентность менеджера в первую очередь

Да, конечно.

Понятия «Perfect World» не существует

Ессно.

люди всегда субъективны

Да :)

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

Да. Мы ассимптотически сходимся к мысли, что если этажом выше человек стоит (сидит, лежит) что называется на своем месте и не требует большого числа замов, завов, экспертов и пр. и пр., то на текущем уровне как минимум жить людЯм проще и понятнее :) Да, возможно один шеф не сможет оценить-развить-промоутить подчиненного настолько всесторонне, как целая комната экспертов, но (1) такая необходимость достаточно редка (2) про колоссальные ресурсы уже сказано (3) главное: если менеджер на этом уровне не противоречит своему шефу, если он адекватен, то его оценки не ухудшают работоспособности всей системы. У Вас ниже в комментариях есть похожая мысль: «если менеджер является хорошим лидером и следует ценности инвестирования в людей (веря в свою идею), у него появляются последователи».

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

Спасибо за комментарий, Евгений :)

Интересная и толковая статья, есть чему поучиться и над чем подумать, спасибо !

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

+1. Также со стороны сотрудника: если текущая компания не оценила рост так, как ожидалось, то в случае перехода в новую компанию это в любом случае поможет.

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

Спасибо, интересная и хорошо структурированная статья. Интересно, а как изменится тактика развития после выхода за 200 человек?

Спасибо, Денис!

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

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

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

С этим я согласен. Вы, наверно, не планируете остановиться на числе Данбара(100-230 человек). Чтобы дальше система не сбрасывала эффективности, нужно, скорее всего, что-то менять, в том числе, в себе, конечно, но и в процессах, структуре, культуре и пр.?

Я в принципе не планирую останавливаться :) Именно процесс достижения новых результатов есть самая интересная часть. Что касается перемен, они нужны будут независимо от того, хотим мы двигаться дальше или нет. Мир сильно меняться (и менялся ранее, только медленнее), индустрии меняются вместе с ним. Нам всегда хочется иметь незыблемые принципы, но это это зыбкая иллюзия :)

Да, конечно, согласен.

It is not necessary to change. Survival is not mandatory.

Однако, все таки, было бы очень интересно узнать о новых способах пересечения числа Данбара без уменьшения эффективности тоже. :) Как Вы думаете, поддержание отдела/предприятия в пределах этого числа достаточно для сохранения эффективности, или как должен измениться «лидер,» структура, культура, процессы, чтобы обеспечивать эффективность предыдущего этапа развития?

Спасибо за прикрасную фразу :)

Теория Данбара имеет место быть. Она приносит сложности в случае если на расширение до 500 или 1000 человек, менеджер планирует держать все под собственным, тотальным контролем. Это микроменеджмент, не готовность принятия перемен или не желание делиться зонами ответственности. Появляется тревожное чувство «никто не сможет делать это так эффективно как я». На самом деле с аналогичным эмоциональным барьером сталкивается и многие Lead Engineers на размере куда меньше 150 человек.

Если же менеджер направлен на рост компании и собственной команды, у него появляются лидеры-последователи. Он готов делегировать им самостоятельно принимать решения и строить стратегические планы относительно своих подразделений. Безусловна эти планы должны иметь корреляцию с вектором компании, не ограничивая тактики их достижения (если они не противозаконные и не противоречат правилам компании). Контроль осуществляется за счет KPI, которые являются больше «лакмусовой бумажкой», обращающие внимание на проблемные места и необходимость погружения в контекст на необходимом уровне. И конечно обратная связь. Если мы видим негодование сотрудников, людей на рынке, высокий уровень потери кадров и так далее.

Дима, спасибо за статью!

Дмитрий Зиновьев — ракета!

Подписаться на комментарии