Предположу, что причиной является тот факт, что мало кто из технарей, проводящих собеседования, имеет образование в сфере управления персоналом (естественно), либо хотя бы что-то читали об этом. А рекрутеры, в свою очередь, слабо смыслят в анализе данных. В итоге, пара этих компетенций редко соединяется в одном человеке и нанимающие просто повторяют внешние признаки понравившихся им самим собеседований, не понимая, какой цели они служили исходно и какую информацию были задуманы извлечь. В итоге, с каждой такой копипастой, качество принятия решений падает.
При разработке каких-либо продуктов у команды зачастую возникает желание перестать бороться с текущим состоянием проекта и переписать всё снова, на этот раз "правильно" и "по науке". Обычно такие порывы не одобряются, но в этот раз я бы хотел предложить к прочтению перевод поста Hugo Baraúna, посвященного тому, какие вопросы нужно задать себе, если всё же решили переписывать.
Также, как и большой рефакторинг, переписывание продукта — непростая штука. За много лет мы приобрели достаточно опыта, чтобы указать, что вам следует обдумать, планируя и осуществляя процесс переписывания.
Будут ли обе платформы существовать одновременно, или нет?
Теория ограничений — это метод управления, разработанный Элияху Голдратом в 1980-х годах. Для популяризации своих идей он написал несколько книг в формате бизнес-романов, где на реальных кейсах показал инструменты, которые помогают разложить любую проблему по полочкам и найти возможные пути решения.
Когда мы в Точке узнали про теорию ограничений, она показалась нам серебряной пулей, которая может решить все проблемы. В том числе и проблему сбоев, так как всего за пять месяцев года мы получили абсолютно негуманный размер манибэка. Мы заручились поддержкой практикующего тренера Саши Брызгаловой и начали разбираться, как повысить качество сервиса. Подробности — под катом.
Нанимать или развивать? Как определить границу между миддлом и сеньором? А что делать дальше, когда ты уже сеньор? На тимлидстве все заканчивается? Как видите, вопросов много. В статье — как мы их решили в Профи.ру.
Статьи — самый эффективный источник не только для изучения нового, но и для восполнения пробелов в имеющихся знаниях. Часто в них можно найти ценные идеи и инсайты, которых нет в других источниках.
Тем не менее, многие находят научные статьи сложными. Отсутствие исследовательского бэкграунда может стать препятствием, когда вы только начинаете читать сложные статьи. Я потратил годы на чтение и понимание научных работ, и в этой статье я поделюсь подходом, который работает для меня.
Сегодня я хочу рассказать о метриках. Но не о тех, которые обычно обсуждают, к примеру, на конференциях, где каждый рассказывает о своём продукте. Я буду говорить о командных метриках и о нашей команде Sber Data Exchange.
Но сначала пару слов всё‑таки о продукте, чтобы задать контекст. Наш продукт специфический: это инструмент для обмена данными со Сбером и компаниями экосистемы. Представьте себе трубы, по которым данные движутся туда‑сюда. Вот этим мы и занимаемся.
Наша команда начинала разработку с нуля и преодолела долгий путь. Мы прошли через опытную эксплуатацию, пережили несколько миграций, наладили процессы и, наконец, вышли в зону стабильности. Продукт развивался, обрастал функциональностью, и всё шло хорошо. Но тут появились неожиданные вызовы, которые заставили нас пересмотреть подходы к работе и увеличить эффективность в разы.
Оу, таблица merchants2? Ну, у нас кончились столбцы в merchants, так что мы сделали merchants2.
Когда я начал заниматься программированием в детстве, я не знал, что людям за это платят. Даже когда я закончил высшую школу, я предполагал, что мир "профессиональной разработки" был устроен совершенно иначе, чем мой код, написанный в свободное время. Когда мне посчастливилось попасть на первую работу разработчиком, я быстро понял насколько я был прав и неправ. Моя первая работа была "испытанием огнём", и по сей день эта кодовая база является и худшей, и лучшей из тех, с которыми я работал. И пусть она навеки останется закрытой в стенах той конкретной компании, я всё же могу поделиться парой самый забавных и страшных историй.
Как часто анализировать проект? Сколько анализаторов использовать? Как размечать полученные предупреждения? Отвечаем на эти и другие вопросы, разбираясь в подробностях свежего ГОСТ Р 71207–2024, посвящённого статическому анализу.
Джесси Уотсон — руководитель группы разработки, ИИ-консультант и сторонник человеко-ориентированного стиля управления персоналом — размышляет о том, насколько слова и поступки руководства могут быть пагубными для подчинённых. Неосторожное слово может не только испортить атмосферу доверия в коллективе, но и напрочь разрушить устоявшиеся отношения между тимлидом и ведущим разрабом.
Делитесь в комментариях своими идеями: что, с вашей точки зрения, лучше — сильная рука тимлида или доверительные отношения в команде?
Всем привет! На связи «Инферит Клаудмастер». Я Милена, технический писатель, и пару месяцев назад уже делилась в статье, как в две руки актуализирую портал документации, чтобы вся информация в нём была актуальная и полезная.
На этот раз хочу рассказать:
- о том, почему ченджлог и роадмап — пользовательская документация,
- о ключевых преимуществах ведения обоих видов документации,
- об удачных и оригинальных примерах их ведения с точки зрения визуального представления.
