Как избегать накопления техдолга
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
У причин появления в проекте большого количества техдолга всегда есть два наивных объяснения: неосознанные разработчики или глупый и жадный менеджмент. Но в подавляющем большинстве случаев настоящие причины не настолько полярны.
Типичная история – менеджер просит команду побыстрее сделать фичу, на что тимлид соглашается, не озвучивая при этом риски, либо считая их очевидными, либо просто не желая быть негативным. В этой ситуации, конечно, виноваты оба участника: и менеджер не проговорил, какая вообще ценность от задачи, и в чем причины спешки, и тимлид не задал вопросов.
Чтобы избежать такого паттерна накопления техдолга, попробуйте следующие шаги:
👉Вместо прямых указаний или просьб сделать фичу задавать вопросы вида "Можем ли мы сделать Х за время У?". Это дает команде возможность сделать выбор вместо того, чтоьы пойти по простому пути и следовать указанию.
👉Еще лучше использовать открытый вопрос. Например, "Что нам придется убрать из скоупа, чтобы сделать Х?" или "Как вы оцениваете риски фичи Х по 10-балльной шкале?"
👉Еще лучше – делать команду достаточно автономной и передавать ей ответственность за результат, чтобы продакту достаточно было рассказать о фактах и дать команде самой решить, что самое ценное для пользователя они могут сделать.
👉Поощряйте привычки команды, которые заставляют ее регулярно задумываться о стоимости и смысле изменений, или уделять внимание инженерной культуре. Например, учитывать в приоритизации cost of delay.
👉Поощряйте не только релизы фичей, но и невидимую работу по решению техдолга и улучшению процессов.
Benji's Blog
Supporting Sustainability - Benji's Blog
what about from the management side? I often hear from engineering and product managers that they're unaware, or learn too late, that folks were accumulating debt. It becomes visible when teams are no longer able to achieve goals.
Как построить найм студентов
Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек.
Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:
👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.
Один из способов расширить воронку найма – посмотреть в сторону найма студентов, которые пока нигде поработать не успели. С одной стороны, нужно построить непростой процесс обучения и отфильтровывания тех из студентов, кто не готов вкладываться, а с другой вы можете получить отлично обучаемых людей, которые готовы будут быстро вникнуть именно в ваш технический стек.
Ребята из МойОфис рассказывают, как запускали два потока студенческих стажировок и с какими сложностями столкнулись. По цифрам результат такой:
👉50 собеседований на входе воронки, 5 наймов спустя 3 месяца.
👉4 из 5 нанятых остались в компании после испытательного срока.
Хабр
Как начать нанимать в штат студентов: опыт создания инженерной школы в МойОфис
Развитие любого крупного ИТ-проекта рано или поздно приводит к потребности в новых сотрудниках. Не всегда её просто покрыть: даже при наличии в компании зрелых HR-процессов и нужных бюджетов, поиск...
Пост для всех, кто любит новогодние подарки с пользой
Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.
Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.
На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.
Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.
Переходите в бот адвент-календаря, чтобы не пропустить подарки!
ООО Яндекс. ИНН 7736207543
Грейд клуб от Яндекс Практикума запустил адвент-календарь для руководителей цифровых команд.
Грейд Клуб — сообщество для нетворкинга цифровых лидеров и площадка для поиска решений о том, как драйвить рост IT-команд.
На протяжении трех недель пользователи будут получать классные подарки от клуба и его партнеров. А их собралось внушительное количество: Эйч, МИФ, Ясно, Кинжал и топовые эксперты индустрии.
Внутри вас ждут:
🎁Полезные фичи для мессенджеров
🎁Билеты на отраслевые конференции
🎁Гайды по эффективному лидерству и другие полезные подарки.
Переходите в бот адвент-календаря, чтобы не пропустить подарки!
ООО Яндекс. ИНН 7736207543
Бреслав и Ложечкин про обратную связь
Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.
Вышел новый эпизод дочернего проекта Подлодки – подкаста для менеджеров "Бреслав и Ложечкин". В этот раз разговор идет про обратную связь: когда и кому она нужна, сколько времени на нее тратить и с какими подводными камнями можно столкнуться.
Как запрашивать фидбэк на свою работу
Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:
👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"
Типичная история – вы работаете над какой-то идеей, запрашиваете у коллег фидбэк, и вместо чего-то полезного получаете поток обратной связи про несущественные аспекты и косметику. Чтобы этого избежать, надо заранее проговаривать, фидбэк какого типа вы ожидаете. Вот одна из моделей:
👉Работа завершена на 5%: "Согласны ли вы с проблемой, которую я решаю?"
👉Работа завершена на 30%: "На правильном ли пути я нахожусь с моим решением проблемы?"
👉Работа завершена на 60%: "Является ли решение разумным, достигнем ли мы с ним наших целей?"
👉Работа завершена на 90%: "Пропустил ли я что-нибудь?"
👉Работа завершена на 100%: "Что в следующий раз надо сделать по-другому?"
hellojames.co.uk
Getting better feedback on your work | hellojames
I'm a designer who helps growing organisations build great in-house teams.
Производительность определяется не личностью разработчика, а случайными факторами
Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные:
👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз.
👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая.
👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Интересное исследование за 1995 год. 500 разработчиков выполняли на протяжении времени набор одинаковых задач, оценивая свои трудозатраты на разные этапы работы над ними. На выходе получились интересные данные:
👉В рамках отдельных заданий есть огромная разница между некоторыми программистами – лучший может быть производительнее худшего аж в 55 раз.
👉Если отбросить эти выбросы, то разница между 25 и 75 перцентилем очень небольшая.
👉Все интереснее, когда анализируется производительность каждого разработчика в рамках всех задач. У 90% разработчиков очень большой разброс времени выполнения разных заданий. Фактически 482 из 494 программистов закончили хотя бы одно задание быстрее среднего, а 415 — медленнее.
Короче, еще одно подтверждение того, что бессмысленно сравнивать перфоманс разработчиков друг с другом, когда они работают над разными задачами, и что вместо фиксации на скорости разработки лучше уменьшать ее неопределенность.
Обязательные знания для тимлида
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Сегодня вечером пишем выпуск Подлодки, в котором будем вместе с Виталием Шароватовым разбираться, что должен знать настоящий тимлид. Чтобы выпуск получился более живым, мы хотим собрать побольше мнений сообщества.
Расскажите в комментариях, что, по вашему, входит в комплект обязательных знаний для тимлида!
Skyeng — EdTech-компания с целой экосистемой сервисов для изучения иностранных языков. В 2022 году они решили усилить аналитическое направление, построив новое корпоративное хранилище данных и сменив инструменты для аналитики.
Новое хранилище построено на сервисах платформы данных Yandex Cloud, покрывающей полный цикл работы с данными в облаке. Ядром DWH стал Yandex Managed Service for Greenplum® , для оперативного доступа к данным используется Yandex Managed Service for ClickHouse®, а для визуализации — Yandex DataLens.
Переход на сервисы Yandex Cloud позволил Skyeng сократить расходы на аналитику данных на 10% и ускорить тестирование маркетинговых гипотез. Это помогло компании за год увеличить продажи на 26%, а число клиентов — на 12%.
Как сервисы Yandex Cloud помогают Skyeng развиваться, читайте по ссылке.
Please open Telegram to view this post
VIEW IN TELEGRAM
Как убедить всех замедлить разработку
Представьте(а, может, вам и представлять не надо) , что с каждым месяцем вы все медленнее и медленнее деливерите фичи из-за накопившегося технического долга и других проблем, а бизнес при этом пушит, чтобы вы ускорялись. Любое ускорение в такой ситуации приводит только к тому, что вы создаете еще больше технического долга, башня которого в ближайшем будущем обрушится на вашу голову.
Единственное разумное решение в такой ситуации – замедлить разработку еще сильнее, исправить накопившиеся проблемы, и потом вступить в игру с новой силой. Проблема в том, что такой подход так просто не продать, особенно в период утраты доверия к команде. Держите советы из статьи, как все-таки достичь желаемого:
👉Оцените все, что от вас требуют сделать, в финансовых метриках, хотя бы очень приблизительно.
👉Выберите самые импактящие вещи, которые заблокированы существующими проблемами. Используйте их для обоснования.
👉Продумайте стратегию отдачи техдолга, которая уменьшает возможные риски и позволяет заинтересованным прозрачно видеть прогресс.
👉Быстро проверьте свои основные предположения до того, как продавать план. Например, точно ли вы сможете переписать какой-то компонент системы в обозначенное время.
👉Заранее продумайте, какие трейдоффы возможны, и используйте их как аргумент в переговорах.
👉Включите свою работу в продуктовый роадмап, сделайте ее видимой, чтобы всем было очевидно, что она связана с болями пользователя.
👉Выбирайте стратегию, которая сможет показать хоть какие-то ранние результаты.
Представьте
Единственное разумное решение в такой ситуации – замедлить разработку еще сильнее, исправить накопившиеся проблемы, и потом вступить в игру с новой силой. Проблема в том, что такой подход так просто не продать, особенно в период утраты доверия к команде. Держите советы из статьи, как все-таки достичь желаемого:
👉Оцените все, что от вас требуют сделать, в финансовых метриках, хотя бы очень приблизительно.
👉Выберите самые импактящие вещи, которые заблокированы существующими проблемами. Используйте их для обоснования.
👉Продумайте стратегию отдачи техдолга, которая уменьшает возможные риски и позволяет заинтересованным прозрачно видеть прогресс.
👉Быстро проверьте свои основные предположения до того, как продавать план. Например, точно ли вы сможете переписать какой-то компонент системы в обозначенное время.
👉Заранее продумайте, какие трейдоффы возможны, и используйте их как аргумент в переговорах.
👉Включите свою работу в продуктовый роадмап, сделайте ее видимой, чтобы всем было очевидно, что она связана с болями пользователя.
👉Выбирайте стратегию, которая сможет показать хоть какие-то ранние результаты.
The Beautiful Mess
TBM 257: How to Make the Case for Slowing Down to Speed Up
How can we make the case for slowing down to speed up when we are already going slow, and when shutting things down and starting over is not an option?
Универсальное правило для продуктивной работы
Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?
🍅Помодоро или регулярных медитаций не хватает, это лишь кратковременная фокусировка на чём-то. Надо создать систему, в которой абсолютно все твои мысли и задачи будут учтены. Так ты избавишь голову от каждодневного хлама и начнёшь кратно увеличишь скорость роста как себя, так и всей компании.
О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте
Держи голову свободной! Тебе никогда не придёт в голову гениальная идея, если она всегда забита операционными мелкими задачами. Помнишь, как ты придумывал что-то перед сном или в отпуске? А сколько из этих идей моментально забывались?
🍅Помодоро или регулярных медитаций не хватает, это лишь кратковременная фокусировка на чём-то. Надо создать систему, в которой абсолютно все твои мысли и задачи будут учтены. Так ты избавишь голову от каждодневного хлама и начнёшь кратно увеличишь скорость роста как себя, так и всей компании.
О том, как система тайм-менеджмента может помочь достичь такого состояния расскажут на вебинаре 16 декабря в 20:30 по мск. Участие бесплатное, надо лишь зарегистрироваться в боте