Location-based payment – хорошо или плохо
В международных компаниях очень популярна практика location-based payment – зарплата сотрудников в одной роли будет значительно различаться в зависимости от страны, в которой они живут, даже когда они работают в одной команде.
На Hacker News завели классный тред, где жарко спорят про то, хорош такой подход или нет, и чем он обусловлен.
Расскажите в комментариях к посту, что вы думаете – насколько такой подход обоснован, или со временем вымрет?
В международных компаниях очень популярна практика location-based payment – зарплата сотрудников в одной роли будет значительно различаться в зависимости от страны, в которой они живут, даже когда они работают в одной команде.
На Hacker News завели классный тред, где жарко спорят про то, хорош такой подход или нет, и чем он обусловлен.
Расскажите в комментариях к посту, что вы думаете – насколько такой подход обоснован, или со временем вымрет?
Как рассказывать команде плохие новости
1️⃣Ничего не делайте, когда только узнали новость. Не надо спешить ее рассказывать, отдохните и обдумайте все со свежей головой.
2️⃣Напишите скрипт того, как вы расскажете новость команде. Начните с короткого абзаца о сути новостей. Будьте максимально честны, не надо сглаживать углы. Затем объясните смысл новостей, их место в общей картине мира и как они скажутся на команде. Завершите кратким объяснением того, чего следует ожидать дальше.
3️⃣Отдайте скрипт на ревью другим менеджерам, соберите фидбэк. По возможности, еще раз сократите лишние детали – чем короче и яснее, тем лучше.
4️⃣Следите за тоном, которым вы рассказываете новости. Команда его запомнит, и он сильно скажется на общем впечатлении.
5️⃣Проведите Q&A. Подготовьте ответы на возможные сложные вопросы заранее.
1️⃣Ничего не делайте, когда только узнали новость. Не надо спешить ее рассказывать, отдохните и обдумайте все со свежей головой.
2️⃣Напишите скрипт того, как вы расскажете новость команде. Начните с короткого абзаца о сути новостей. Будьте максимально честны, не надо сглаживать углы. Затем объясните смысл новостей, их место в общей картине мира и как они скажутся на команде. Завершите кратким объяснением того, чего следует ожидать дальше.
3️⃣Отдайте скрипт на ревью другим менеджерам, соберите фидбэк. По возможности, еще раз сократите лишние детали – чем короче и яснее, тем лучше.
4️⃣Следите за тоном, которым вы рассказываете новости. Команда его запомнит, и он сильно скажется на общем впечатлении.
5️⃣Проведите Q&A. Подготовьте ответы на возможные сложные вопросы заранее.
Stay SaaSy
How to Give Bad News
If you run teams for long enough, you're going to need to give people bad news. No matter the situation, there are some universal steps on how to give bad news.
Подборка материалов про то, как прокачать навыки работы с документацией
👩🎓Замечательные курсы технических писателей от Google
🤔Алгоритм действий по тому, как привести в порядок документацию в команде
🔗Огромная подборка ссылок по разным аспектам написания документации: от правил форматирования текста до оценки UX
🎤Выпуски Подлодки по теме: «Техническая документация» и «Управление знаниями»
👩🎓Замечательные курсы технических писателей от Google
🤔Алгоритм действий по тому, как привести в порядок документацию в команде
🔗Огромная подборка ссылок по разным аспектам написания документации: от правил форматирования текста до оценки UX
🎤Выпуски Подлодки по теме: «Техническая документация» и «Управление знаниями»
Google for Developers
Overview of technical writing courses | Technical Writing | Google for Developers
Обязательно ли разработчики должны развиваться
Большинство начинающих тимлидов, засучив рукава, начинают заниматься развитием своей команды. Вооружившись матрицами компетенций, делают оценку 360, строят индивидуальные планы развития и на еженедельных one-on-one разбирают прогресс.
Почему-то многие принимают за аксиому тот факт, что любой разработчик должен постоянно развиваться, писать пет-проекты, контрибьютить в опенсорс и зарешивать литкод. Но это – не так. Автор статьи хорошо разбирает источники давления на разработчиков, и то, почему они вредны.
Большинство начинающих тимлидов, засучив рукава, начинают заниматься развитием своей команды. Вооружившись матрицами компетенций, делают оценку 360, строят индивидуальные планы развития и на еженедельных one-on-one разбирают прогресс.
Почему-то многие принимают за аксиому тот факт, что любой разработчик должен постоянно развиваться, писать пет-проекты, контрибьютить в опенсорс и зарешивать литкод. Но это – не так. Автор статьи хорошо разбирает источники давления на разработчиков, и то, почему они вредны.
Хабр
Обязан ли разработчик развиваться?
Мир IT довольно токсичен. Нас окружает успешный успех — он захлёстывает и сбивает нас с ног каждый раз, когда мы смотрим на публичных людей в нашей отрасли. Один — ворочает «маленьким кластером на...
Про Кароля Адамецкого, автора российской теории проектного менеджмента
Интересная статья про довольно малоизвестного теоретика и практика менеджмента.
Кароль Адамецкий, работая менеджером на заводе, изучал взаимосвязь процессов в проектной деятельности и пытался управлять ими. Результатом его исследований стали гармонограммы – гибкие проектные графики, похожие на изобретенные позже диаграммы Ганта и PERT. Для работы с гармонограммой требовалось механическое устройство – гармонограмм.
Интересная статья про довольно малоизвестного теоретика и практика менеджмента.
Кароль Адамецкий, работая менеджером на заводе, изучал взаимосвязь процессов в проектной деятельности и пытался управлять ими. Результатом его исследований стали гармонограммы – гибкие проектные графики, похожие на изобретенные позже диаграммы Ганта и PERT. Для работы с гармонограммой требовалось механическое устройство – гармонограмм.
Эффект IKEA
Исследование 2011 года показало, что люди, которые сами собрали мебель из IKEA, считают ее выгодным вложением на 63% чаще, чем те, кто просто приценивается к аналогичной собранной кем-то еще мебели. Привязанность к предмету тоже значительно повышается для тех, кто своими руками его собирает.
Этот эффект объясняет два других часто встречающихся в разработке синдрома:
💦Sunk costs effect – продолжение инвестиций в проект, который уже очевидно не выгорел, только потому, что в него уже многое было вложено раньше
🤷🏻♂️Not invented here syndrom – отказ от идей и технологий, разработанных где-то или кем-то еще только потому, что это не in-house разработка
Исследование 2011 года показало, что люди, которые сами собрали мебель из IKEA, считают ее выгодным вложением на 63% чаще, чем те, кто просто приценивается к аналогичной собранной кем-то еще мебели. Привязанность к предмету тоже значительно повышается для тех, кто своими руками его собирает.
Этот эффект объясняет два других часто встречающихся в разработке синдрома:
💦Sunk costs effect – продолжение инвестиций в проект, который уже очевидно не выгорел, только потому, что в него уже многое было вложено раньше
🤷🏻♂️Not invented here syndrom – отказ от идей и технологий, разработанных где-то или кем-то еще только потому, что это не in-house разработка
Хотите быть крутым лидом, но эффективность команды падает?
Пытаетесь контролировать процессы, но не хватает времени и слаженности действий специалистов?
Не печальтесь! Учебный центр «Слёрм» подготовил кое-что интересное именно для вас, а именно бесплатный вебинар «7 типичных ошибок тимлида», в ходе которого опытные преподаватели учебного центра «Слёрм» Ксения Клен и Андрей Булов помогут разобрать самые распространенные, но не всегда очевидные ошибки и подскажут, как избавиться от них.
О чем обещают рассказать?
Что делать, если нет понимания куда двигаться самому и вести команду.
Как перестать все делать самому и начать делегировать работу.
Как выстроить в коллективе дружную атмосферу и справляться с конфликтами.
Что делать, если проблемы не решаются, а замалчиваются.
Как донести до команды ценность бизнес-метрик и важность их отслеживания.
Почему «тушение пожаров» — плохая практика.
Как быть, если команда стала неуправляемой и отказывается слышать.
Вебинар пройдет в среду 21 сентября в 19:00.
Успейте записаться — будет интересно и максимально полезно.
Регистрация: https://slurm.io/webinars/team-lead-errors
Пытаетесь контролировать процессы, но не хватает времени и слаженности действий специалистов?
Не печальтесь! Учебный центр «Слёрм» подготовил кое-что интересное именно для вас, а именно бесплатный вебинар «7 типичных ошибок тимлида», в ходе которого опытные преподаватели учебного центра «Слёрм» Ксения Клен и Андрей Булов помогут разобрать самые распространенные, но не всегда очевидные ошибки и подскажут, как избавиться от них.
О чем обещают рассказать?
Что делать, если нет понимания куда двигаться самому и вести команду.
Как перестать все делать самому и начать делегировать работу.
Как выстроить в коллективе дружную атмосферу и справляться с конфликтами.
Что делать, если проблемы не решаются, а замалчиваются.
Как донести до команды ценность бизнес-метрик и важность их отслеживания.
Почему «тушение пожаров» — плохая практика.
Как быть, если команда стала неуправляемой и отказывается слышать.
Вебинар пройдет в среду 21 сентября в 19:00.
Успейте записаться — будет интересно и максимально полезно.
Регистрация: https://slurm.io/webinars/team-lead-errors
Слёрм
Вебинар «7 ошибок тимлида»
Для действующий тимлидов и тех, кто собирается ими стать - за 90 минут вы узнаете, как избежать распространенных, но не всегда очевидных ошибок в работе тимлида.
Качество как функция системы его обеспечения
Качество продукта зависит не столько от скиллов разработчиков, сколько от системного подхода к его обеспечению. Группа супер-крутых разработчиков, работающих без оглядки на качество, скорее всего произведет продукт хуже, чем группа средненьких мидлов, работающих в системе, построенной с целью производить качественный результат.
К характеристикам такой системы обеспечения качества относится:
🐞Культура и инфраструктура, поощряющие написание тестов и дающие на это время
💻Надежные и простые в использовании dev/test окружения
☮️Отсутствие давления на команду, заставляющего релизить недостаточно протестированный код
📝Наличие документации и выделяемое на нее время
💬Регулярный разбор факапов с исправлением их корневых причин, без попыток блеймить кого-то
Качество продукта зависит не столько от скиллов разработчиков, сколько от системного подхода к его обеспечению. Группа супер-крутых разработчиков, работающих без оглядки на качество, скорее всего произведет продукт хуже, чем группа средненьких мидлов, работающих в системе, построенной с целью производить качественный результат.
К характеристикам такой системы обеспечения качества относится:
🐞Культура и инфраструктура, поощряющие написание тестов и дающие на это время
💻Надежные и простые в использовании dev/test окружения
☮️Отсутствие давления на команду, заставляющего релизить недостаточно протестированный код
📝Наличие документации и выделяемое на нее время
💬Регулярный разбор факапов с исправлением их корневых причин, без попыток блеймить кого-то
jacobian.org
Quality Is Systemic - Jacob Kaplan-Moss
Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than…
44 правила начинающего тимлида
Список важных правил и принципов, которые нужно распечатать себе на стену, когда вы только стали тимлидом.
🤔Что вы должны и не должны делать
🤩Мотивация и культура
❤️Эмоции и люди
🌩Управление конфликтами
💬Сложные разговоры
🧱Отстаиввние личных границ
Список важных правил и принципов, которые нужно распечатать себе на стену, когда вы только стали тимлидом.
🤔Что вы должны и не должны делать
🤩Мотивация и культура
❤️Эмоции и люди
🌩Управление конфликтами
💬Сложные разговоры
🧱Отстаиввние личных границ
defmacro
44 engineering management lessons
Welcome to engineering management. It’s fun, it’s exhausting, it’s rewarding — but most importantly it’s new! What worked for you before won’t work now. You’ll have to acquire a new set of skills, and shed some bad habits in the process. Here is a short guide…
Если вы выпускаете новые цифровые продукты, или обновляете существующие, вам могут быть знакомы ситуации, когда нужно быстрее выпускать фичи, реализовать задачи из бэклога, или предотвратить выгорание команды. А иногда могут происходить все эти ситуации сразу.
Помочь разобраться могут инструменты Scrum для разработчиков, а Практикум — разобраться с тем, как их внедрить.
За 7 дней обучения вы:
◾освоите самый популярный Agile-фреймворк;
◾разберётесь, как работает фреймворк Scrum;
◾удете много практиковаться и участвовать в вебинарах.
Вы не только изучите методологию Scrum, но и сможете внедрить её под присмотром опытного наставника — две недели после курса он будет с вами на связи и поможет применить новые инструменты в вашем проекте.
Узнать о курсе больше и начать учиться бесплатно →
Помочь разобраться могут инструменты Scrum для разработчиков, а Практикум — разобраться с тем, как их внедрить.
За 7 дней обучения вы:
◾освоите самый популярный Agile-фреймворк;
◾разберётесь, как работает фреймворк Scrum;
◾удете много практиковаться и участвовать в вебинарах.
Вы не только изучите методологию Scrum, но и сможете внедрить её под присмотром опытного наставника — две недели после курса он будет с вами на связи и поможет применить новые инструменты в вашем проекте.
Узнать о курсе больше и начать учиться бесплатно →
Яндекс Практикум
Онлайн-курс «Инструменты начинающего руководителя»
Двухнедельный курс «Инструменты начинающего руководителя» от сервиса Яндекс Практикум. За время онлайн-обучения вы изучите основные инструменты управления командой.
Зачем тимлиду прокачивать продуктовую ветку
Одна из возможных веток развития тимлида – продуктовая. Разные люди качают ее по разным причинам:
🤝В продуктовых компаниях тимлид и продакт-менеджер часто работают максимально тесно, и тимлид в экстренном случае должен быть способен подменить продакта. Например, во время моей работы в Авито это случалось не раз, как и обратная ситуация.
🤔Работа тимлида – находить оптимальные способы решения задач бизнеса. Ты не принимаешь решения, что делать, твоя задача – заниматься деталями реализации. Если тимлид хочет напрямую влиять на то, как конкретно принимаются решения, то он рассматривает для себя продакт-менеджмент как потенциальное продолжение карьеры.
🌩Не все продакты – одинаково скилловые. Вместо того, чтобы принимать все идеи продакта на веру, полезно уметь челленджить его доводы.
📝Несколько лет назад было популярно движение «Что угодно – это продукт». Продуктовый подход действительно можно применить к чему угодно – к инфраструктуре, процессам, своей команде.
Так вот, мы с командой проводим новую конференцию Подлодки про продуктовую аналитику. Она, конечно, расчитана на мидлов-продактов, но на мой взгляд будет полезна и тимлидам. Несколько сессий, на которые я точно рекомендую сходить, чтобы прокачать ту самую продуктовую ветку:
🪄Воркшоп «Прогнозируем влияние фичей до начала разработки». Такой навык может помочь не бросать команду на заранее бесполезные задачи.
📊Воркшоп «Лезем в данные самостоятельно». Поможет посчитать метрики самостоятельно, чтобы отстоять свои собственные идеи перед продактом, или проверить его выводы.
💰Воркшоп «Финансовые метрики и юнит-экономика». То, как продукт зарабатывает деньги, часто остается черным ящиком для тимлида, хотя в итоге именно от этого зависит выживание его и его команды.
Конференция стартует уже в понедельник. Я забыл выложить анонс заранее, поэтому держите промокод –
Подключайтесь, тимлиды с продуктовым мышлением – на вес золота!
Одна из возможных веток развития тимлида – продуктовая. Разные люди качают ее по разным причинам:
🤝В продуктовых компаниях тимлид и продакт-менеджер часто работают максимально тесно, и тимлид в экстренном случае должен быть способен подменить продакта. Например, во время моей работы в Авито это случалось не раз, как и обратная ситуация.
🤔Работа тимлида – находить оптимальные способы решения задач бизнеса. Ты не принимаешь решения, что делать, твоя задача – заниматься деталями реализации. Если тимлид хочет напрямую влиять на то, как конкретно принимаются решения, то он рассматривает для себя продакт-менеджмент как потенциальное продолжение карьеры.
🌩Не все продакты – одинаково скилловые. Вместо того, чтобы принимать все идеи продакта на веру, полезно уметь челленджить его доводы.
📝Несколько лет назад было популярно движение «Что угодно – это продукт». Продуктовый подход действительно можно применить к чему угодно – к инфраструктуре, процессам, своей команде.
Так вот, мы с командой проводим новую конференцию Подлодки про продуктовую аналитику. Она, конечно, расчитана на мидлов-продактов, но на мой взгляд будет полезна и тимлидам. Несколько сессий, на которые я точно рекомендую сходить, чтобы прокачать ту самую продуктовую ветку:
🪄Воркшоп «Прогнозируем влияние фичей до начала разработки». Такой навык может помочь не бросать команду на заранее бесполезные задачи.
📊Воркшоп «Лезем в данные самостоятельно». Поможет посчитать метрики самостоятельно, чтобы отстоять свои собственные идеи перед продактом, или проверить его выводы.
💰Воркшоп «Финансовые метрики и юнит-экономика». То, как продукт зарабатывает деньги, часто остается черным ящиком для тимлида, хотя в итоге именно от этого зависит выживание его и его команды.
Конференция стартует уже в понедельник. Я забыл выложить анонс заранее, поэтому держите промокод –
product_crew_2_SINaBE
.Подключайтесь, тимлиды с продуктовым мышлением – на вес золота!
podlodka.io
Онлайн-конференция Podlodka Product Crew #6
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам продуктовой работы, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
This media is not supported in your browser
VIEW IN TELEGRAM
Как в Shopify переделали систему расчета компенсации
- Каждый сотрудник сам решает, какую часть компенсации он получит в виде кеша, какую – в виде опционов, а какую – другими бонусами, вроде денег для оплаты товаров на платформе
- Это круто, так как разным людям важно разное – кто-то расчитывает на зарплату и хочет побыстрее выплатить ипотеку, а кто-то готов рискнуть и поставить на долгосрочный успех компании
- Компания поощряет выбор опционов дополнительными 5% сверху
- Весь расчет компенсации, независимо от ее вида, ведется в одном инструменте, что сильно повышает прозрачность
- Каждый сотрудник сам решает, какую часть компенсации он получит в виде кеша, какую – в виде опционов, а какую – другими бонусами, вроде денег для оплаты товаров на платформе
- Это круто, так как разным людям важно разное – кто-то расчитывает на зарплату и хочет побыстрее выплатить ипотеку, а кто-то готов рискнуть и поставить на долгосрочный успех компании
- Компания поощряет выбор опционов дополнительными 5% сверху
- Весь расчет компенсации, независимо от ее вида, ведется в одном инструменте, что сильно повышает прозрачность
Инструменты для управления ИТ-инфраструктурой
Тимлиду чаще всего нужно думать не только про благополучие и результативность своей команды, но и про обслуживаемую командой систему. Многие из вопросов упираются в то, в каких конкретно облаках работает проект, и какие возможности и условия они дают. Регулярно смотреть на рынок и примерять новые решения – полезная практика.
При запуске виртуальной инфраструктуры в облаке, #CloudMTS предоставляет 300 000 бонусных рублей, которые вы можете потратить на размещение и управление ресурсами. Примеры того, что можно там развернуть:
🛒Интернет-магазин, чтобы справляться с нагрузкой в самый пик
🐞Софт для тестирования
📊бизнес-приложения или хранить большие массивы данных
Все условия и подробности акции – по ссылке
Тимлиду чаще всего нужно думать не только про благополучие и результативность своей команды, но и про обслуживаемую командой систему. Многие из вопросов упираются в то, в каких конкретно облаках работает проект, и какие возможности и условия они дают. Регулярно смотреть на рынок и примерять новые решения – полезная практика.
При запуске виртуальной инфраструктуры в облаке, #CloudMTS предоставляет 300 000 бонусных рублей, которые вы можете потратить на размещение и управление ресурсами. Примеры того, что можно там развернуть:
🛒Интернет-магазин, чтобы справляться с нагрузкой в самый пик
🐞Софт для тестирования
📊бизнес-приложения или хранить большие массивы данных
Все условия и подробности акции – по ссылке
Дисфункции организаций
Несколько лет назад мы записали выпуск подкаста «Дисфункции организаций» с Олегом Сорокой. На протяжении нескольких часов Олег объясняет, как получается так, что в индустрии, собравшей в себе умнейших людей, так много вещей делается неэффективно. Этот выпуск – один из моих любимых по плотности шикарных идей на минуту времени.
А по ссылке – англоязычный пост с разбором основных идей подкаста с комментариями автора. Если вы не готовы сразу тратить три часа на прослушивание, то это – отличный старт!
Несколько лет назад мы записали выпуск подкаста «Дисфункции организаций» с Олегом Сорокой. На протяжении нескольких часов Олег объясняет, как получается так, что в индустрии, собравшей в себе умнейших людей, так много вещей делается неэффективно. Этот выпуск – один из моих любимых по плотности шикарных идей на минуту времени.
А по ссылке – англоязычный пост с разбором основных идей подкаста с комментариями автора. Если вы не готовы сразу тратить три часа на прослушивание, то это – отличный старт!
★ Vicki Boykis ★
On the team as a system
How humans work together to build software
Что такое data engineering
- Дата-инженеры отвечают за разработку и поддержку инфраструктуры обработки данных, которые затем используются аналитиками, дата-саентистами и обычными пользователями
- Помимо инфраструктуры, дата-инженеры определяют основную модель данных, при необходимости денормализуя ее для конкретных команд
- Основная часть работы – построение пайплайнов перекладывания данных из разных источников, контроль целостности и качества данных, процессинг данных на потоке, поддержка хранилищ данных
- Дата-инженеры отвечают за разработку и поддержку инфраструктуры обработки данных, которые затем используются аналитиками, дата-саентистами и обычными пользователями
- Помимо инфраструктуры, дата-инженеры определяют основную модель данных, при необходимости денормализуя ее для конкретных команд
- Основная часть работы – построение пайплайнов перекладывания данных из разных источников, контроль целостности и качества данных, процессинг данных на потоке, поддержка хранилищ данных
Курс «Английский для аналитиков» от Яндекс Практикума
Для специалистов, которые хотят изменить свою профессиональную жизнь и работать в международной команде. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
• Самопрезентация. Рассказ о своей роли, задачах, сфере ответственности на поведенческом интервью и в неформальной беседе.
• Работа в команде. Стендапы, планирование спринтов, демонстрация навыков командной работы на собеседовании.
• Общение с заказчиками и исполнителями. Сбор требований у стейкхолдеров и постановка задач для разработчиков.
• Презентация результатов работы. Выступление на митапах, неформальное общение с коллегами из отрасли.
• Обсуждение решений по проекту. Генерация и аргументация идей, участие в мозговых штурмах.
• Рефлексия и самоанализ. Ретроспектива, ревью, ответы на сложные вопросы.
Запишитесь на бесплатную консультацию. Определят ваш уровень языка, расскажут про обучение и ответят на все вопросы
Для специалистов, которые хотят изменить свою профессиональную жизнь и работать в международной команде. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
• Самопрезентация. Рассказ о своей роли, задачах, сфере ответственности на поведенческом интервью и в неформальной беседе.
• Работа в команде. Стендапы, планирование спринтов, демонстрация навыков командной работы на собеседовании.
• Общение с заказчиками и исполнителями. Сбор требований у стейкхолдеров и постановка задач для разработчиков.
• Презентация результатов работы. Выступление на митапах, неформальное общение с коллегами из отрасли.
• Обсуждение решений по проекту. Генерация и аргументация идей, участие в мозговых штурмах.
• Рефлексия и самоанализ. Ретроспектива, ревью, ответы на сложные вопросы.
Запишитесь на бесплатную консультацию. Определят ваш уровень языка, расскажут про обучение и ответят на все вопросы
Как исправить худший проект, на который только возможно попасть
Представьте, что вас нанимают навести порядок в проекте, который:
- Разрабатывался 12 лет без системы контроля версий
- Никогда не рефакторился, и никакая функциональность не удалялась
- Писался без каких-либо фреймворков, архитектуры и паттернов
- Представляет собой полный хаос с точки зрения кода, модели данных и инфраструктуры
- Зарабатывает 20 миллионов долларов в год
Автор статьи дает много хороших советов про то, как в такой ситуации можно поступить:
- В первую очередь, не соглашайтесь на такую работу, и ищите нормальный проект. Компания, работавшая в таком режиме много лет, будет не готова меняться, и вы просто потратите несколько лет карьеры зря
- Даже не думайте затевать переписывание всего с нуля, двигайтесь очень маленькими постепенными шагами
- Начинайте с наименее рисковых инициатив: документация, контроль версий, автоматические сборки. Потом продвигайтесь к более сложным – автотесты и управление зависимостями. И только после того, как с точки зрения инфраструктуры и тестов все готово, начинайте постепенный рефакторинг архитектуры
- Постепенно ротируйте команду, избавляясь от тех, кто сопротивляется изменениям. Готовьтесь платить много денег, иначе хороших инженеров на такой проект не нанять
Еще больше обсуждений этой ситуации есть на HackerNews. И расскажите в комментариях про свои похожие истории и то, как вы из них выкарабкивались!
Представьте, что вас нанимают навести порядок в проекте, который:
- Разрабатывался 12 лет без системы контроля версий
- Никогда не рефакторился, и никакая функциональность не удалялась
- Писался без каких-либо фреймворков, архитектуры и паттернов
- Представляет собой полный хаос с точки зрения кода, модели данных и инфраструктуры
- Зарабатывает 20 миллионов долларов в год
Автор статьи дает много хороших советов про то, как в такой ситуации можно поступить:
- В первую очередь, не соглашайтесь на такую работу, и ищите нормальный проект. Компания, работавшая в таком режиме много лет, будет не готова меняться, и вы просто потратите несколько лет карьеры зря
- Даже не думайте затевать переписывание всего с нуля, двигайтесь очень маленькими постепенными шагами
- Начинайте с наименее рисковых инициатив: документация, контроль версий, автоматические сборки. Потом продвигайтесь к более сложным – автотесты и управление зависимостями. И только после того, как с точки зрения инфраструктуры и тестов все готово, начинайте постепенный рефакторинг архитектуры
- Постепенно ротируйте команду, избавляясь от тех, кто сопротивляется изменениям. Готовьтесь платить много денег, иначе хороших инженеров на такой проект не нанять
Еще больше обсуждений этой ситуации есть на HackerNews. И расскажите в комментариях про свои похожие истории и то, как вы из них выкарабкивались!
Medium
HN: Inherited the worst code and tech team I have ever seen. How to fix it?
I read an article on News Ycombintor and copied the title from there. The short story is that somebody inherited a product + team which…
Примеры карьерных линеек разных компаний
К нам в Роадмап Тимлида прилетел отличный pull request с примерами карьерных линеек в разных компаниях. Если у вас появится похожая задача, сможете использовать как источник для вдохновения.
Кстати, начался Хактоберфест, так что с радостью примем больше ваших PR! 🎉
К нам в Роадмап Тимлида прилетел отличный pull request с примерами карьерных линеек в разных компаниях. Если у вас появится похожая задача, сможете использовать как источник для вдохновения.
Кстати, начался Хактоберфест, так что с радостью примем больше ваших PR! 🎉
Deep dive в современные фронтенд фреймворки и решаемые ими проблемы
Существуют десятки фреймворков для разработки фронтенда. На взгляд непосвященного, разница между ними не очень велика, и механизм выбора технологии для конкретного случая не очень понятен.
Держите отличную статью с глубоким разбором проблем современного фронтенда и классификацией всех фреймворков по тому, как они подходят к их решению.
Существуют десятки фреймворков для разработки фронтенда. На взгляд непосвященного, разница между ними не очень велика, и механизм выбора технологии для конкретного случая не очень понятен.
Держите отличную статью с глубоким разбором проблем современного фронтенда и классификацией всех фреймворков по тому, как они подходят к их решению.
Frontendmastery
The new wave of Javascript web frameworks
Make sense of the proliferation of new Javascript web frameworks. A deep dive into the problems at scale and the recent evolution of innovation.
Исследование проблем начинающих тимлидов
Я провожу исследование, которое поможет нам в составлении модели курса для Симулятора Тимлида. Вспомните свой первый год работы менеджером, и поделитесь самыми большими вопросами и сложностями, знание решения которых могло бы значительно ускорить вашу адаптацию к новой роли.
Опрос будет состоять из двух частей – сначала я соберу качественные данные, потом обработаю их и кластеризую, и ~через неделю проведу второй опрос, где попрошу вас поранжировать их по приоритету. Результаты потом опубликую в чате для всех!
И главное – двум случайным участникам опроса выдам бесплатные билеты на Podlodka Teamlead Crew, которая пройдет уже довольно скоро.
Я провожу исследование, которое поможет нам в составлении модели курса для Симулятора Тимлида. Вспомните свой первый год работы менеджером, и поделитесь самыми большими вопросами и сложностями, знание решения которых могло бы значительно ускорить вашу адаптацию к новой роли.
Опрос будет состоять из двух частей – сначала я соберу качественные данные, потом обработаю их и кластеризую, и ~через неделю проведу второй опрос, где попрошу вас поранжировать их по приоритету. Результаты потом опубликую в чате для всех!
И главное – двум случайным участникам опроса выдам бесплатные билеты на Podlodka Teamlead Crew, которая пройдет уже довольно скоро.
Google Docs
Проблемы начинающих тимлидов
Расскажите нам, с какими проблемами и вопросами вы сталкивались в первый год своего тимлидства. Например: "Человек хотел уволиться, не знал, как уговорить его остаться", "В проекте была куча техдолга, сложно было придумать, как его решать". Это поможет нам…