Управление разработкой *

Проект GNU опубликовал релиз открытого текстового редактора GNU Emacs 29.2.

Вплоть до выпуска GNU Emacs 24.5 проект развивался под личным руководством Ричарда Столлмана, который передал пост лидера проекта Джону Вигли (John Wiegley) осенью 2015 года.

Исходный код проекта написан на языках C и Lisp и распространяется под лицензией GPLv3.

В новом выпуске на платформе GNU/Linux по умолчанию Emacs выставлен по умолчанию в качестве обработчика схемы URI org-protocol. Режим org позволяет быстро сохранять закладки, заметки и ссылки, используя команду emacsclient, например для сохранения ссылки URL с заголовком можно выполнить emacsclient "org-protocol://store-link?url=URL&title=TITLE". Кроме того, в новой версии редактора предложена новая опция tramp-show-ad-hoc-proxies, при помощи которой можно включить отображение внешних имён файлов вместо ярлыков на них.

Источник: OpenNET.

Создатель ReiserFS Ханс Райзер (Hans Reiser) в письмах из тюрьмы принёс сообществу Open Source свои глубокие извинения за социальные ошибки и прокомментировал прекращение поддержки файловой системы.

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

Разработчик Фредрик Р. Бреннан написал письмо Райзеру, когда тот находился в тюрьме в Калифорнии, и недавно получил ответы на первое письмо и на несколько последующих. Письма от Райзера было разрешено расшифровать и публично распространить. Судя по оригинальным изображениям письма и всей сопутствующей информации, оно действительно кажется подлинным письмом от автора ReiserFS. Райзер в своих письмах подробно описал свои социальные ошибки, историю ReiserFS, осуждение ReiserFS некоторыми представителями сообщества и надежды, которые он возлагал на Reiser4.

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

Роспатент в 2023 году зарегистрировал 31,9 тыс. программ для ЭВМ и 5,2 тыс. баз данных (БД), следует из подсчетов компании «Онлайн Патент» на основе официальных данных ведомства. Это на 23,3% и 38,8% больше, чем в 2022 году, соответственно. В 2022 году показатели тоже росли относительно 2021 года, но не так активно: с 22,1 тыс. до 25,9 тыс. оформленных прав на ПО и с 3,3 тыс. до 3,7 тыс. прав на БД.

Больше всего свидетельств о регистрации в 2023 году получило управление информационных технологий и связи, подведомственное комитету по информации и связи Санкт-Петербурга. В течение года оно зарегистрировало 503 программы и 270 БД. В случае с ПО, по данным «СПАРК-Интерфакс», речь идёт о компонентах систем «Безопасного города», других городских систем мониторинга и документооборота.

Следующими в списке организаций, наиболее активно регистрировавших права на ПО, идут ТК «Центр» (крупнейший распространитель лотерейных билетов, бренд «Столото») с 440 свидетельствами и ОАО РЖД с 273 свидетельствами.

Базы данных, помимо властей Санкт-Петербурга, активнее всего регистрировали вузы: РАНХиГС, ВШЭ, Сеченовский институт и другие.

Количество патентов, выданных в течение 2023 года, осталось фактически на уровне 2022 года — 30,1 тыс. против 30,4 тыс. до 30,1 тыс. на изобретения и полезные модели. Число патентов на промышленные образцы снизилось на 5,5%, до 5,2 тыс.

18 января 2024 года Линус Торвальдс вернулся в сеть спустя пять суток без электричества у себя дома в Портленде, штат Орегон.

13 января 2024 года Линус Торвальдс объявил, что ему пришлось отложить текущие задачи по разработке ядра Linux 6.8 из-за сильного зимнего шторма, обрушившегося на США, включая Портленд, штат Орегон. У Торвальдса пропало электричество и доступ в Интернет.

В последнем сообщении Линуса Торвальдса, говорилось, что его пятый день «отпуска» продолжается, но коммунальная компания надеется восстановить подачу электроэнергии к сегодняшнему вечеру, хотя вчера она давала аналогичное обещание, но это не сработало.

В итоге сегодня после пяти суток перерыва Торвальдс всё же смог продолжить работу над ядром Linux 6.8 и начал проявлять большую активность в Linux Git.

13 января 2024 года Линус Торвальдс объявил, что ему пришлось отложить текущие задачи по разработке ядра Linux 6.8 из-за сильного зимнего шторма, обрушившегося на США, включая Портленд, штат Орегон. У Торвальдса нет электричества и Интернета.

Из-за зимнего шторма мы потеряли электричество и Интернет. Конечно, это Орегон, поэтому «шторм» здесь — это то, что некоторые, вероятно, посчитали бы «несколько ветреным», а «зима» здесь означает, что температура приближается к -10°C. И прежде чем кто-нибудь скажет: «Просто сходите в Starbucks и работайте оттуда», самое страшное — не считая, возможно, поваленных деревьев и линий электропередач — это другие водители. Я останусь на месте.

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

Запуск нового проекта: когда Time and Materials дороже Fixed Price, и на что лучше потратить эту разницу

Недавно мы сравнили модели Fixed Price и Time and Materials на примере типичного среднего проекта: прошлись по всем этапам и проследили, как меняется бюджет от пресейла до релиза.

В нашем примере проект по T&M вышел примерно на 5 миллионов дороже, чем Fixed Price проект. При этом проект по T&M получился более продуманным. Но мы считаем, что это не стоит таких сверхвложений.

По нашему мнению, лучше потратить разницу в 5 миллионов на постепенный запуск продукта — Soft Launch. Это когда мы тестируем первую версию проекта на ограниченной аудитории. Потом исправляем ошибки и только тогда выпускаем продукт для большей аудитории.

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

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

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

Полную версию этой статьи найдете тут. А об управлении проектами читайте в нашем телеграм-канале.

https://console.dev/

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

Разработчики Gentoo Linux, изначально ориентированного на формирование окружения с использованием сборки программ из исходного кода, объявили о введении в строй репозитория готовых бинарных пакетов. Пакетный менеджер Portage уже много лет поддерживает установку бинарных пакетов, но до сих пор бинарные пакеты предоставлялись лишь выборочно - предполагалось, что дистрибутив в основном распространяет метаданные для сборки, но пользователь может собрать бинарные пакеты на одной из своих систем и использовать на других компьютерах.

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

Для архитектур отличных от amd64 и arm64 сборки Gentoo Linux ограничены базовыми системными компонентами и еженедельными обновлениями. Для систем amd64 и arm64 бинарные пакеты охватывают и пользовательские приложения, включая пакеты с LibreOffice, Docker, Xfce, KDE и GNOME. Всего на зеркалах размещено более 20 ГБ бинарных пакетов, обновляемых ежедневно для стабильной ветки Gentoo.

Источник: OpenNET.

Чек-лист для самоконфликта. Как мы учим менеджеров прогнозировать

В заказной разработке мы оттачиваем навык прогнозирования ежедневно. Но как добиться эффективного планирования от проектных менеджеров? Ведь в том числе от их решений зависит рентабельность всей компании.

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

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

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

Главная задача — задать правильные вопросы, чтобы менеджер засомневался во всех возможных вариантах ответа, но нащупал границы и выплыл с точным прогнозом.

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

В полной версии статьи еще больше примеров — читайте ее здесь.

P. S. Мы много пишем об управлении проектами в нашем тг-канале. Так что приходите, если интересно)

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

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

А потом Вася Пупкин, Яваскрипт джун, тащит всё это добро к себе в репозиторий, потому что так делают ведущие компании. Бред! Он делает магазин для автозапчастей!

Тот же ужас творится и в найме. Задача Netflix не нанять человека. У них на каждую вакансию в день приходит по 84 резюме. Их задача - избавиться от кандидатов. Так же как и MS и FB избавляются от кандидатов, а кандидаты безбожно врут, для того, чтобы откусить "запретный плод" "хорошей зарплаты" и "отличной корпоративной культуры", а потом сваливают оттуда через годик-другой.

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

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

В ядро Linux 6.8 запланировано добавление первого сетевого драйвера на языке Rust. В ветку net-next, в которой развиваются изменения для ядра Linux 6.8, включены изменения, добавляющие в состав ядра начальную Rust‑обвязку над уровнем абстракции phylib и использующий данную обвязку драйвер ax88 796b_rust, обеспечивающий поддержку PHY‑интерфейса Ethernet‑контроллера Asix AX88 772A (100MBit). Драйвер включает 135 строк кода и позиционируется как простой рабочий пример для создания сетевых драйверов на языке Rust, готовый для использования с реальным оборудованием.

По своим возможностям драйвер на Rust полностью эквивалентен предыдущему драйверу ax88796b, написанному на языке C, и может быть использован с сетевыми картами X-Surf 100, оснащёнными чипом AX88796B.

Оба сетевых драйвера, на C и на Rust, будут сосуществовать в ядре Linux, и могут включаться в зависимости от предпочтения пользователей системы. Для включения драйвера на Rust в Kconfig предусмотрена настройка AX88796B_RUST_PHY, вместе с которой при помощи параметра RUST_PHYLIB_ABSTRACTIONS также нужно включить Rust-обвязку над phylib.

Кроме того, на языке Rust разработан Ethernet‑драйвер Realtek Generic FE‑GE, который пока не предложен для включения в состав ядра. Ранее также был представлен прототип драйвера rust-e1000 для Ethernet-адаптеров Intel, переписанный на Rust.

Источники: OpenNET, Phoronix.

Google опубликовала релиз web-браузера Chrome 120.

Основные изменения в Chrome 120:

• стартовал эксперимент по отключению поддержки сторонних Cookie, выставляемых при обращении к сайтам, отличным от домена текущей страницы;

• начался процесс прекращения поддержки видеокодека Theora;

• оформление каталога Chrome Web Store переработано для упрощения поиска и управления дополнениями;

• расширена функциональность интерфейса «Проверка безопасности» (Safety check);

• реализована адаптивная панель инструментов, меняющаяся в зависимости от изменения размера окна;

• взаимодействие с принтерами перенесено в отдельный сервисный процесс;

• в TLS включена реализация механизма инкапсуляции ключей (KEM, Key Encapsulation Mechanism), использующего гибридный алгоритм X25519Kyber768, устойчивый к подбору на квантовых компьютерах;

• в версии для Android прекращена поддержка платформы Android 7.0 Nougat;

• внесены улучшения в инструменты для web-разработчиков. В отладчике по умолчанию включено игнорирование скриптов размещённых в каталогах "/node_modules/" и "/bower_components/" с модулями Node.js. В режиме удалённой отладки реализован переключатель для выбора между мышью и сенсорным экраном. Улучшена отладка анимации. В панель Elements добавлен переключатель "media" для отладки элементов <audio> и <video>.

Источник: OpenNET.

Простая идея для канбан-доски, которая делает работу прозрачней

Пересказываем большую статью в маленьком посте.

Недавно мы заметили, что некоторые задачи на наших канбан-досках застревают на приемке у заказчиков. Например, задачу с нуля мы делаем 10 дней, а потом в колонке Client Acceptance она может лежать еще 20–30. Ситуация повторялась на разных проектах и явно была общей.

Мы быстро поняли, в чем дело. На стадии Client Acceptance команда получала замечания от заказчики. И пока они вносились, задача оставалась в этом же столбце. По правилам Канбан, двигать ее назад нельзя. Хотя, по сути, всё это время она проходила тот же путь, что и до этого — через To do, In progress и Validation.

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

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

Благодаря этому решению мы:

• упростили и оптимизировали работу;

• начали лучше контролировать работу отделов;

• сделали работу прозрачной для заказчика.

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

Интересная статья на английском языке:
"First decide how to decide: “one weird trick” for easier decisions"
https://jacobian.org/2023/dec/5/how-to-decide/

Статья про формальный процесс принятия решений, основанная на опыте работы в Heroku на проекте Dogwood (Heroku Enterprise).

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

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

Источник новости: полезняшки от Разбора Полетов

Выгорание - это всего лишь отсутствие цели в работе.

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

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

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

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

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

В этот момент вместо Труса, Балбеса и Бывалого у вас появится инициативная команда.

1. Платите им

2. Корректируйте их

3. Покажите им как они влияют на ваш бизнес в котором они учавствуют

PI-планирование, или Почему нам стало легче дышать

Один из наших заказчиков — известный бренд, который развивают Ecom-направление. Мы работаем с ними уже пять лет, но начиналось всё так себе. Первое время мы не могли найти общий язык, спорили из-за мелочей. Всё как в басне «Лебедь, рак и щука».

Но затем нашли лекарство — PI-планирование. Рассказываем, как его проводим мы.

PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров. Она помогает держать фокус на общей цели и синхронизировать действия нескольких команд сразу.

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

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

В итоге мы стали понимать KPI стейкхолдеров и глобальные задачи бизнеса. Вот главные плюсы PI:

1. Мы обеспечиваем команде равномерную нагрузку.

2. Мы делим ответственность за проект с заказчиком.

3. Мы лучше распределяем ресурсы.

PI-планирование точно стоит внедрить тем,

✔️ кто строит команду на аутсорсе;

✔️ у кого над продуктом работает несколько команд.

Напишите в комментариях, нужна ли отдельная статья о PI-планировании. А больше про управление разработкой — в нашем телеграм-канале.

Что мы делаем, когда задача приходит на разработку без планирования

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

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

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

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

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

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

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

Теперь вы расскажите, как вы проводите срочные задачи. Больше про управление проектами — в нашем телеграм-канале.

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.43.

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

По сравнению с прошлым выпуском в версию Git 2.43 внесено и принято 464 изменения, подготовленные при участии 80 разработчиков, из которых 17 программистов впервые приняли участие в разработке, включая:

• в команду "git repack" добавлены опции "--filter" и "--filter-to", позволяющие выполнить переупаковку репозитория c учётом заданного фильтра объектов и при необходимости перенести в отдельное место объекты, не удовлетворяющие заданному фильтру;

• добавлена возможность работы с несколькими pack-файлами с информацией о недостижимых объектах ("cruft packs"), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги);

• добавлено распознавание попыток выполнения двойной отмены коммита через "git revert" и учёт этого факта при формировании сообщения об отмене;

• Разрешено совместное использование опций "--rfc" и "--subject-prefix".

Источник: OpenNET.

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_8

?Вопрос_8: Какие алгориммы поиска аномалий в данных существуют и чем они отличаются ?

✔️Ответ:

• DBSCAN (Density-Based Spatial Clustering of Applications with Noise) - алгоритм кластеризации данных, который основывается на плотностной информации о расположении объектов. Он определяет кластеры как плотные области в пространстве признаков, разделенные областями разреженности;

• LOF (Local Outlier Factor): LOF также использует информацию о плотности для обнаружения аномалий. Он вычисляет локальный коэффициент выброса для каждого объекта, основываясь на плотности окрестности данного объекта по сравнению с плотностью окрестности его соседей. Значения LOF выше единицы указывают на аномальные объекты;

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

• One-Class SVM (Support Vector Machines): One-Class SVM - алгоритм, который строит модель только для "нормальных" данных. Он пытается найти гиперплоскость, которая наилучшим образом разделяет нормальные данные от выбросов в пространстве признаков. Объекты, находящиеся далеко от этой гиперплоскости, считаются аномалиями.

  https://t.me/DenoiseLAB

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

Если компания на рынке хотя бы 10–15 лет, в ней точно есть сотрудники-старожилы. Когда-то они решали нерешаемые задачи и были незаменимы. Но технологии и процессы шагнули вперед, а они нет. Ниже советы, как вернуть их в строй.

1. Разговаривать.

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

2. Учить новому.

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

3. Строить план развития.

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

4. Мотивировать.

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

5. Следить и поддерживать.

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

6. Принимать решения.

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

Если хотите узнать больше о работе тимлида — подписывайтесь на телеграм-канал.