Тимлидер: плюсы и минусы профессии

Знания и навыки

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

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

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

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

Повторюсь еще раз – тимлид это и программист, и психолог, и менеджер в одном лице.

Психологическая роль

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

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

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

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

Какая же деятельность для тимлида родная?

  1. члены команды были согласны выполнять поручения,
  2. достаточно компетентны для этого,
  3. обладали достаточными ресурсами (в первую очередь — временем),
  4. могли ужиться вместе.

Лидерство

с намерением

  1. Проявлять искреннюю личную заинтересованность в успехе проекта. В современной команде разработчиков все видят все, что делают остальные, как делают, насколько стараются. Разработчики с большей охотой пойдут за тем, кто сам вовсю старается ради успеха проекта, даже если этот кто-то и формальной власти то не имеет, из желания помочь. Такой лидер легко удерживает инициативу, пока не выдохнется или не потеряет интерес к проекту.
  2. За счет знания технологий и устройства проекта лучше всех в команде. К таким лидерам тянутся заинтересованные в профессиональном росте разработчики, они часто именно за этим и приходят в проект. Логично, что при достижении разработчиками уровня лидера, если других факторов нет, лидер теряет инициативу, что на практике выражается постоянной критикой решений, порой приводит к игнорированию распоряжений или скрытым саботажам.
  3. Способен добиться уважения окружающих за счет личных качеств. Когда человек объективен, справедлив, последователен, сотрудники могут полагаться на такого человека и его решения. Однако для того, чтобы команда разглядела эти качества в потенциальном лидере требуется время, за которое лидерство захватит кто-нибудь другой. Этот фактор наиболее устойчив к различного рода переменам в команде.
  4. Умение эксплуатировать настроения отдельных членов команды, заставляя действовать по своему плану (кино Filth сразу вспомнилось www.imdb.com/title/tt1450321). Видел таких лидеров, даже немного поработал в профессиональной юности сдуру, но вовремя сбежал. Очевидно, что опытными специалистами, знающими себе цену, долго не поманипулируешь.
  5. Применение административных мер, предоставляемых формальной властью, для того, чтобы заставить сотрудников выполнить обязательства. Если этот фактор лидерства единственный, то это явный пример системы отношений «я — начальник, ты — дурак». Работает также на довольно ограниченном множестве сотрудников.

Компетентность команды

  1. Типовая ошибка — найм недостаточно компетентных сотрудников в силу неумения выявить профессиональные качества кандидата. Простые примеры — это неумение или боязнь задать правильные вопросы на собеседовании, смещение акцента на эзотерические особенности технологий, а не на их практическую сторону. Последствия ожидаемы — кандидат не справляется со взятыми командой обязательствами, следовательно и тимлид тоже.
  2. Другая крайность — найм только экспертов. Чтобы не ошибиться в найме после набития шишек, или из желания собрать команду мечты, тимлид тщательно отбирает только не уступающих в знаниях ему самому кандидатов. Так как такая манера больше свойственна лидерам-экспертам, то ценз получается довольно высоким. Кандидаты ищутся долго, затраты на подбор растут, задачи проекта не решаются, а у тимлида есть отличная отговорка — нет специалистов. Но даже когда команда собрана оказывается, что звезды с рутинными задачами готовы мириться, но хотелось бы задач с вызовом (challenge) и каждому, а вот пойти мусор подмести в проекте никому не хочется. Да и обстановка какая-то напряженная становится, как известно у 4-х архитекторов 8 мнений, большинство из них правильные, хоть и противоречат друг-другу.
  3. Еще типичный пример — игнорирование потребности в привлечении в команду сотрудников других специальностей, например фронтендщика, эксперта в определенной БД, проектировщика интерфейса и т.д. Часто такое происходит просто из-за непонимания того, что такой специалист в команде нужен. В итоге команда суровых бэкендщиков разрабатывает кое как работающий фронтенд в своем проекте, команда разработчиков месяцами бьется с оптимизацией PostgreSQL, ну и мой любимый случай — психбольница в руках пациентов.
  4. Пример сложнее — неравномерность найма, взял пачку джуниоров, чтобы два раза не вставать, а они как начали код писать так, что ревьювить команда не успевает, да еще подходят вопросы всякие задают непрерывно, ломают что-то постоянно.
  5. Или наоборот, работаем, концентрируемся на задачах, найм на потом откладываем, как внезапно уходит кто-то из ключевых сотрудников, другой в отпуске/болеет/забрали в другой проект, а на смену никого из подрастающего поколения нет. Скажете, что мол, ситуация неожиданная? Так вот к такой ситуации тимлид всегда должен быть готов, заранее продумывая как он поступит в случае потери того или иного члена команды. А еще лучше если он отношения построит так, чтобы заранее узнать о таком исходе.

Стиль спускается каскадно от топ-руководителей

Есть один важный нюанс. Скорее всего, вы не идете на работу в маленький стартап, где вашим руководителем будет сам основатель. Это значит, что у вашего руководителя будет ещё как минимум один руководитель на уровень выше. Если ваш непосредственный руководитель — милейший человек, который всегда «за своих орлов», а его руководитель — авторитарный деспот с усами, то так или иначе вы будете ощущать авторитарную нотку управления на себе. Если кто-то из директоров вздумает установить в офисе камеры и будет лично следить за тем, кто уходит на 15 минут раньше положенного, то никто вам не поможет. Каким бы подходящим ни был ваш тимлид, он будет не в силах спасти вас от бушующего СТО. Именно поэтому при собеседовании нужно задавать вопросы по фреймворку STAR или PARLA, узнавать отзывы бывших сотрудников

Важно не то, что говорят руководители, а то, как они поступают

Дополнительные материалы

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

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

  • Матрица доверие-прозрачность https://t.me/general_it_talks/78

  • Ситуационное лидерство https://t.me/general_it_talks/59

  • Чайка-менеджмент, микроменеджмент https://t.me/general_it_talks/28

  • Обучение, приоритеты и иллюзию компетентности в этом деле https://t.me/general_it_talks/60 https://t.me/general_it_talks/41 https://t.me/general_it_talks/116

  • Овертаймы и подбор темпа работы https://t.me/general_it_talks/42 https://t.me/general_it_talks/61

  • Теория разбитых окон https://t.me/general_it_talks/48

Идеальные вопросы для интервью — какие они?

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

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

История из жизни
«Как мы проворонили хорошего кандидата»

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

Плюсы и минусы профессии

Теперь немного о достоинствах и недостатках профессии:

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

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

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

6 стилей менеджмента

Существует множество классификаций менеджерских стилей. Больше других мне нравится классификация Дениэла Гоулмана, опубликованная в HBR в 2000 году. В ней выделяется 6 стилей: 

  • авторитарный,

  • авторитетный,

  • демократический,

  • образцовый,

  • товарищеский,

  • обучающий.

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

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

Растить замену ещё полезнее

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

На мой взгляд, полезная мысль. Если размеры команды и желания людей позволяют, то лучше растить сразу 2 или 3, тогда лучше начнёшь замечать свои собственные проблемы, на которые раньше не обращал внимания

Для удалённой работы это очень важно, потому что получить фидбек для самого себя намного сложнее, чем при работе всем вместе, ведь мой начальник тоже сидит за 1000км от меня и тоже сталкивается с похожими проблемами, когда хочет поговорить со мной

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

Чаты как способ выстраивать связи

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

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

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

Приведите в порядок встречи один на один

Пример формата записи результатов и договорённостей по итогам встречи

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

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

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

Тимлид – не профессия, а должность. Лидером команды, как правило, становится программист-разработчик. Соответственно, программист – это профессия, а тимлидер – занимаемая им должность.

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

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

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

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

Технические задачи тимлида:

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

Team leader может устроиться на работу в крупную брокерскую или финансовую компанию, бизнес-корпорацию, банк либо в IT-фирму. Интересно, что официальная должность тимлида есть не во всех айти-компаниях. И все же в любой команде должен быть главный. Занять этот пост обычно предлагают самому опытному разработчику или руководителю отдела, в небольшом стартапе – техническому директору или начальнику SEO-отдела. В крупной компании разработчики могут сформировать сразу несколько команд, каждая из которых получит своего формального тимлидера. В таком случае для руководства лидерами команд учреждается дополнительная должность – тимлид тимлидов.

Какой стиль использует руководитель и способен ли он его менять

Реакция вашего друга на вопрос о стиле его руководителя

Альтернативным способом получить такую информацию является… собеседование. Если вы хотя бы раз проходили собеседование в любую компанию, то наверняка слышали вопросы вроде: «Кем вы видите себя через 5 лет?», «Назовите ваши слабые стороны» и т.д. Очевидно, что все эти вопросы задают не с целью потянуть интервью подольше, они нужны для определения софт-скиллов. На самом деле такими вопросами можно многое узнать о мотивации кандидата, составить его психологический портрет. Такого рода вопросы — это мощный инструмент, который можно использовать и в обратную сторону. Не упускайте свою возможность задать вопросы, когда вам дают слово, попросите о дополнительной сессии с будущим начальником, коллегами. Задавайте вопросы, пока не сформируете полное представление о стиле руководства в компании. Конечно, этими техниками нужно уметь пользоваться, и если вы не знакомы с софт-скилловой стороной проведения собеседований, почитайте про интерпретацию фраз-маркеров, фреймворки STAR и PARLA. Как и в случае с любым другим инструментом, чем больше вы будете практиковаться, тем лучше у вас будет получаться.  

Профессиональный рост в IT

Рассмотрим типичную IT-компанию. Как и в других отраслях, здесь возможен рост «по горизонтали» и «по вертикали».

Горизонтальный рост — это освоение более широкого стека, близких направлений (например, мобильной разработки) или уход в смежную профессию (в управление проектами, продажи, аналитику).

Вертикальный — это переход на лидерские позиции (техлида, тимлида) или руководящие должности. О нём мы сегодня и поговорим.

Это — обычная схема профессионального роста:

  1. junior developer (специалист начального уровня);
  2. middle developer (специалист среднего уровня);
  3. senior developer (специалист высокого уровня);
  4. technical leader (технический лидер);
  5. team leader (лидер команды).

Иногда выделяют дополнительные промежуточные ступени, например junior+ (это джун, который совсем чуть-чуть не дотягивает до миддла).

Стать тимлидом можно и раньше — со ступени middle-разработчика.

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

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

Чем занимается team leader

Отметим, что тимлид – это должность, а не отдельная профессия. Что входит в обязанности этого специалиста:

  • Общение с заказчиком, организация разработки. Team lead помогает программистам решать поставленные перед ними задачи (с высоты своего опыта). Он одновременно и управляет, и сам занимается разработкой. Поэтому должен иметь иметь хороший базис в программировании и навыки менеджера. Он учитывает приоритеты и интересы конкретного заказчика, отслеживает эффективность членов команды в плане бизнес-процессов.
  • Наем, обучение и адаптация всех сотрудников. Лидер взаимодействует с менеджерами и эйчарами для закрытия потребности в кадрах, принимает участие в собеседованиях. В маленьких организациях тимлидеры иногда сами занимаются наймом. В больших компаниях эйчары производят первичный отбор, а team lead задействуется для технических собеседований. Он знакомит новичков с принятыми в работе стандартами, самим проектом, инструментарием и кодом. Помогает джуниорам понять бизнес-процессы и роль каждого в них, планирует развитие других сотрудников, мониторит их рост. Благодаря тимлиду обеспечивается соответствие всей команды и отдельных кадровых единиц потребностям бизнеса.
  • Помощь коллегам и координация команды. Лидер выполняет не только управленческие функции, он принимает участие в работе над кодом. Руководитель следит, чтобы продукт соответствовал целям, которые поставил заказчик. Осуществляется это путем контроля разработки и координации деятельности команды. Программисты обращаются за помощью к тимлиду, а во время индивидуальных бесед и общих собраний обсуждается ход грядущей работы.

Менеджерские полномочия тимлида:

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

Технические компетенции управленца:

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

Team leader должен четко осознавать, что сейчас происходит с проектом, текущий этап разработки, отклонять/одобрять различные идеи и предложения сотрудников. Он ответственен за микроклимат в коллективе, за то, чтобы все члены команды были работоспособны. Иными словами, он помощник, психолог и друг. Руководитель обеспечивает комфортные условия работы своим подчиненным.

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

Обучающий стиль

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

Мы верим в то, что сможем достигать крутых результатов, если будем развивать индивидуальные навыки своих сотрудников. Для этого каждые полгода мы проводим performance review. Оно включает в себя отзывы от коллег, self-review и 1-1 с руководителем для рефлексии. После этого мы составляем план на полгода таким образом, чтобы сотрудник знал, что ему делать для улучшения своих навыков. Каждый пункт этого плана является целью и ставится по фреймворку SMART. Например, если одной из целей является крупный рефакторинг, то мы определяем definition of done этого рефакторинга. Так он станет конкретным и измеримым. Планируем объём работ: реально ли закончить этот рефакторинг за 3-6 месяцев? И думаем о том, какую пользу он принесет компании.

Девиз обучающего стиля

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector