Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулся с настоящими вызовами, некоторые процессы пришлось выстраивать.
Мы активно используем нейросети для решения рабочих задач. Бизнес агитирует за глубокое проникновение «искусственного интеллекта» в рабочие процессы. В то же время процесс найма в компаниях старательно игнорирует эволюцию инструментов. Интервьюеры выставляют себя идиотами и встают на пути интересов бизнеса.
Эта статья для тимлидов, которые столкнулись с тем, что в их команде появились более опытные разработчики, чем они сами. Поговорим, почему это хорошо и как этим управлять
Привет! Сегодня я хочу поделиться опытом создания и внедрения системы грейдинга для системных аналитиков в моей компании. Эта история о том, как стремиться сделать оценку сотрудников объективной, прозрачной и мотивирующей, какие результаты получили в итоге, какие выявили недостатки. В рамках компании, система грейдинга коснулась нескольких направлений разработки, я же буду акцентировать внимание именно на системных аналитиках.
Последнее время вышло много статей на тему тимлидства. Где-то спорили о написании кода тимлидами, где-то говорили о найме, где-то обсуждали пипл-менеджмент. Но давайте подумаем, есть ли вообще смысл становиться тимлидом.
Ревью - важный этап разработки и одна из самых частых точек взаимодействия разработчиков с кодом и между собой, особенно в распределенных командах. Обычно он заключается в изучении разработчиком (ревьюер) изменений кода, предлагаемых другим разработчиком.
При этом разработчик (надеемся):
В курсе бизнес процесса
Понимает, как его код встроен в общую архитектуру решения
Уверен, что предлагаемое решение - работает
Ревьюер (в худшем случае):
Не знает бизнес процесса
Не в курсе архитектуры решения
Не в курсе, работает ли решение и работает ли так, как должно
Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработки. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon ProfitЧитать полностью »
Моя предыдущая статья вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я.
Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика.
Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.
У меня получилось четыре категории:
Эта статья подходит для тимлидов и их подопечных, а также для всех, кто оценивает проекты и задачи. Я расскажу, как и почему мы делаем ошибки из-за когнитивных искажений. Попадаем в них мы почти все, просто потому что мы живые люди. И на примере одного дня из жизни тимлида я хочу показать, в какие искажения чаще всего влетают в IT, и — самое полезное — как из них можно выходить.
Замечу, что искать когнитивные искажения стоит, в первую очередь, у себя, а не у коллег. Читать полностью »
