Привет, Хабр!
Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.
Я делюсь своим опытом работы тимлидом и пришел к выводу, что наибольшая эффективность команды достигается через служение ей, а не командование - это называется servant leadership. Моя главная задача заключается в автоматизации рутинных процессов, защите интересов команды перед руководством.
Наверняка тебе знакома ситуация: начинается утренний синк, и ты задаёшься вопросом: «А что вообще сейчас происходит с задачами?». Кто‑то что‑то делал, кто‑то ждал ревью, у кого‑то что‑то зависло, а кто‑то вообще сидит без работы. На расспросы команды уходит много времени, а картина всё равно остаётся неполной. И самое важное не про все вспомнишь в момент синка.
Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.
Мне 38, программирую с института — заканчивала по специальности. За 15 лет в IT успела побывать всем, кем только можно: техлид, архитектор, DevOps, backend, frontend. Когда в отрасли так долго, трудно найти что-то, чего не делала.
Разрабатывая девайсы, мы проходим полный цикл создания устройства: ES, EVT, DVT, PVT-этапы. Это международный инженерный фреймворк, его использует множество компаний. Но акцент во фреймворке на валидации и доработке хардверной части. О том, что в рамках каждого этапа требуется от софта, говорят мало и редко. Поэтому расскажу, как мы вписываем разработку программного обеспечения в основные этапы разработки «железа» и что требуют от software-команды на каждом этапе создания умных устройств Sber. Если вы хотите разрабатывать софт в хардверной компании или уже занимаетесь этим, но пока не работали в рамках фреймворка полного цикла — точно будет интересно.
Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...».
Кому будет полезна эта статья:
— Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками.
— Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор».
— Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек.
— Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами.
Вы узнаете, что:
— Не существует «правильных» технологий (и postgres не лучше mysql).
— Архитектор не должен писать код (и почему).
— Что покупка коробочных решений не избавляет от проблем.
И как же из паразита сделать симбиота? Agile — слово, которое стартапы любят произносить на каждом питче.
Сразу расставлю все точки над «и»: LLM полезны. Вопрос не в том, могут ли LLM писать код, они на это способны. Вопрос в том, почему вайб-кодинг может оказаться вашей худшей карьерной инвестицией.
Я начал замечать перемены, когда темы бесед разработчиков полностью поменялись. Теперь они обсуждают лишь то, как заставить Claude написать код за них. Или конечную цель: как заставить ИИ делать всё без вмешательства человека.
До недавнего времени я по большей мере игнорировал этот ажиотаж. Я читал заголовки, время от времени просил Claude или ChatGPT помочь мне в отладке, но ничего больше. Пришла пора учиться вайб-кодингу!
Всем привет! Меня зовут Павел, я руководитель разработки в компании Банки.ру. Сегодня предлагаю погрузиться в достаточно классическую тему когнитивных искажений и их влияния на работу тимлида и принимаемые решения.
Уверен, что практически каждый хоть раз чувствовал некоторое разочарование и непонимание в поведении коллег, результатах проекта или принимаемых решениях. В эти моменты в голове часто крутятся вопросы:
– Почему часть важных изменений в команде не приживается и откатывается к началу, хотя, кажется, мы все вместе нашли консенсус?
– Да каким образом мы снова не попали в сроки проекта, хотя у нас прекрасная опытная команда.
– Какова причина нежелания команды переходить на актуальный стек? Или наоборот, почему члены команды упорно тащат в ключевой проект сырые фреймворки и необкатанные подходы?
– Снова по итогам проекта у нас переусложненная и запутанная архитектура. Что мы делаем не так?
Давайте разбираться!
За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.
Пара моих эмоционально-заряженых эссе на тему взаимоотношений компаний и сотрудников.
Первое — про ответственность и вовлечённость сотрудников через призму личного опыта. И почему по настоящему ответственных людей так мало.
Второе — про то, что усилия и вклад сотрудников далеко не всегда оцениваются работодателем справедливо и часто не коррелируют между собой. Про «перетягивание одеяла» интересов сотрудников и компаний. А также критика современных течений «Как хакнуть работодателя».
Есть одна фраза, которую я слышал в десятках проектов.
Она звучит почти невинно, даже логично:
"Сейчас сделаем как получится, а потом перепишем"...
Есть одна фраза, которую я слышал в десятках проектов.
Она звучит почти невинно, даже логично:
"Сейчас сделаем как получится, а потом перепишем"...
Эта статья для тимлидов, которые столкнулись с тем, что в их команде появились более опытные разработчики, чем они сами. Поговорим, почему это хорошо и как этим управлять.
В этой статье я делюсь опытом менторства проекта на Yandex Camp по машинному обучению — рассказываю о том, что получилось, что нет, и какие выводы сделал. Надеюсь, эти наблюдения помогут будущим менторам и организаторам кемпов улучшить рабочий процесс, а также всем, кому интересно управление проектами.
Встретился с крутыми мотивированными ребятами — мне сначала показалось, что они выполнят весь проект за день. Но опыт показал, что у многих команд были проблемы в самоорганизации командной работы и технической подготовке к работе.
Когда задачи есть, а движения — нет
Команда работает.
Задачи в трекере стоят.
Стендапы идут, код пишется, обсуждения кипят.
А результата всё нет.
Нет чувства прогресса, нет ощущения, что продукт становится ближе к релизу.
Итерации проходят одна за другой — а продукт будто топчется на месте.
Эта статья — попытка ответить на извечный вопрос «когда?», а так же размышления на тему нужно ли его задавать, и нужно ли на него отвечать. Пригодится тем, кто выполняет проектную работу (на случай важных переговоров) и их заказчикам.
Есть сроки виртуальные, а есть сроки реальные. Виртуальные — это те сроки, которые вам пытаются продать. Которые обещают. Даже если их прописывают в договоре, всё равно это некий прогноз, гипотеза о будущем. Которую всегда можно переиграть, объяснив, почему не получилось.
Виртуальные сроки обычно называют не те, кто будет делать непосредственную работу, а менеджеры и продажники. И цель их в первую очередь — продать. Сделать так, чтобы вам понравилось их предложение и вы захотели купить, заключить договор, внести предоплату. А что будет дальше — это проблемы будущих нас. К тому же чем дальше, тем сильнее вы будете связаны с исполнителем, больше от него зависеть и больше ошибок ему будете готовы прощать. Потому как сами уже затратили своё время, деньги и силы на коммуникацию и притирку, плюс становится всё более лень искать новых, и не факт ведь что те будут лучше.
Поэтому задача продажников и менеджеров на первом этапе, это озвучить те сроки, которые вы захотите услышать. Объявить коммерческое предложение, которое будет выглядеть лучше, чем предложения других исполнителей. Ещё не началась работа и сопутствующие проблемы, а сроки уже начали расходиться с реальностью.
Для менеджера главное — не «пообещать и сделать», а «управлять ожиданиями». А ведь и заказчикам нужно то же самое. Главное сейчас — чтобы им что‑то пообещали. А могут это выполнить или нет, обоснованы ли сроки, и вообще есть ли полная информация, чтобы их посчитать — это уходит на второй план. Зато в моменте вы успокоитесь потому что всё под «контролем». А потом уже будет «возникли новые обстоятельства», «задача оказалась чуть сложнее, чем мы предполагали», «мы не учли некоторые моменты, извините», это всё потом. А сейчас win‑win. То, что вы хотите слышать, совпадает с тем, что говорят вам менеджеры.
Приложения для планирования и управления проектами призваны помочь нам успешно разрабатывать и поддерживать проекты в рамках нашего бизнеса. Сегодня, в эпоху цифровых технологий, когда все больше отраслей уходит в онлайн и все больше людей работают дистанционно, на рынке программного обеспечения для управления проектами царит настоящие изобилие. Но как понять, какие продукты действительно хороши, а от каких лучше держаться подальше?
Одним из гостей подкаста Doubletapp «Что-то на программистском» стал бывший топ-менеджер Яндекса и нынешний IT-предприниматель Григорий Бакунов (aka Bobuk). В разговоре с ведущим, CEO Doubletapp Сергеем Анчутиным( (ТГ-канал: t.me/serega_ceo), он рассказал, почему против работы фултайм и аутсорса, чем IT-компании вредят российскому образованию, куда по карьерной лестнице могут продвинуться разработчики и почему чаще всего им это не интересно.
Вы все еще разрабатываете и тестируете в общем окружении, пересылаете в мессенджерах файлы конфигов для запуска приложения на рабочей машине, провели половину спринта в ожидании ресурсов для новой: бд, очереди, etc.? Знайте - вы не одиноки. Но бывает по-другому.
Если вы еще здесь, полагаю, что все же хочется “по-другому”. На самом деле это вовсе не значит, что сейчас плохо. Просто жизнь такая.
Так о чем это мы тут? О рабочем и тестовом окружении, интеграционном (здесь будем называть интеграцией любое внешнее по отношению к процессу приложения взаимодействие – потому что так хочется) тестировании и немного о процессе разработки по.
