Планирование, отслеживание и контроль
Управление направлением разработки в IT-компании на 2500 чел — Юлия Бажанова / Ural Digital Weekend 2024
Почему важно делать не только проектную разработку и аутстафф, а также вкладываться в продуктовую разработку? Как посчитать от этого экономический эффект? Правила ведения IT-бизнеса, которые с годами не стареют.
Ссылка на запись доклада в ВКонтакте.
Ссылка на презентацию: https://goo.su/CsVGBAU
Какие бывают заказчики в диджитал-разработке? — Михаил Белошапка / Ural Digital Weekend 2024
1. Какой он — идеальный заказчик сильного агентства?
2. Классификация заказчиков: как устроены, кто принимает решения «на той стороне» и как выходить на нужных вам людей.
3. С какими агентствами работают крупные клиенты?
Ссылка на запись доклада в ВКонтакте.
Ссылка на презентацию: https://goo.su/kGanyP3
Как меняется менеджмент в компании с ростом от 20 до 200 человек — Николай Фетюхин / Ural Digital Weekend 2024
Менеджмент — система управления людьми в компании, где строится какая-то культура, на нее нанизываются всякие регламенты, отчеты. Круто, когда планы совпадают с фактами.
1. История становления менеджмента в моих компанияx.
2. Чем большие компании отличаются от маленьких?
3. Почему в IT-компаниях все плохо с менеджментом?
4. Как это исправить?
5. Менеджмент — главная точка роста IT-компании.
Ссылка на запись доклада в ВКонтакте.
Ссылка на презентацию: https://goo.su/S6OcR
Сквозное управление рисками на аутсорс-контракте — Артем Михайлов / Ural Digital Weekend 2024
1. Управление рисками с точки зрения PMBook-а (теория): реестр рисков, стратегии реагирования на риски.
2. Три основных роли на проекте.
3. Управление рисками на этапе оценки.
4. Управление рисками на этапе контрактации.
5. Управление рисками на этапе исполнения проекта.
6. Управление рисками на этапе исполнении контракта.
Ссылка на запись доклада в ВКонтакте.
Ссылка на презентацию: https://goo.su/9tErOH
Как горизонтальные решения ускоряют разработку продуктов?
Программа платформизации — это такой централизованный подход, с помощью которого можно ускорять разработку продуктов. В теории звучит классно, но как это работает на практике?
Это вы узнаете из доклада Евгения Толмачёва, руководителя разработки в юните FullBase кластера SellerExperience. На примере одной из платформ Авито Женя рассказывает:
как понять, что ваш продукт — это платформа;
как подойти к оценке ее возможностей;
и главное — как ее развивать.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Что в ЮMoney думают о лайфкодинге
Рассказывает Никита, ведущий инженер отдела разработки серверных решений.
Мы предлагаем кандидату решить небольшую задачу с использованием Java Core. Для этого не нужно знать специфичные технологии и хардкорные алгоритмы.
Считаем лайфкодинг эффективным форматом. Писать код — одна из основных задач программиста, и этот формат позволяет увидеть, как кандидат справляется. Мы пробовали и другие форматы, но они оказались менее эффективными или более долгими.
Оценивая кандидата, мы делаем скидку на то, что собеседование — это стресс, но важно уметь с ним справляться. Например, мы ежедневно выкладываем новые релизы, это может делать как опытный специалист, так и новичок. И, если что-то пойдёт не так, надо не растеряться и быстро отреагировать.
Чтобы кандидат меньше нервничал во время лайфкодинга:
● Мы ставим его в условия, похожие на рабочие, и предлагаем решить задачу на личном компьютере, в любимой IDE. Можно также подглядеть в документацию или поисковик.
● Максимально доброжелательно отвечаем на вопросы, не давим и ни в коем случае не превращаем интервью в стресс-тест. Если кандидат застопорился, стараемся выяснить, что именно вызывает трудности.
● Если кандидат допустил ошибку или его решение неоптимальное, указываем на это и обсуждаем способы улучшения.
Возможно, в будущем собеседование изменится — например, если с развитием инструментов ИИ мы совсем перестанем писать код. В таком случае постараемся адаптировать наши процессы под новые реалии.
Управление ожиданиями: внешние и внутренние заказчики, особенности работы с разными моделями оплаты — Сергей Костин и Татьяна Пименова / Ural Digital Weekend 2024
Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.
1. Управление ожиданиями заказчика. Эффективная работа с клиентом: независимо от модели оплаты. 2. Работа с внешними клиентами: Кейс компании АТОЛ. 3. Работа с внутренними клиентами: Кейс Head of Sales BSL.
Ссылка на запись доклада в ВКонтакте.
Ссылка на презентацию: https://goo.su/zD4B
Почему джуны — это хорошая инвестиция
Большинство компаний неохотно нанимают начинающих разработчиков. Согласно статистике Хабр Карьеры, только 5% опубликованных вакансий ориентированы на джуниор-специалистов. Для сравнения: 50% — на мидлов, 31% — на сеньоров, 8% — на лидов, 6% — на стажеров. На рынке к джунам принято относиться с опаской. Есть стереотип, что они приносят мало пользы, зато требуют много вложений.
У нас другой подход, мы с бóльшим энтузиазмом относимся к джунам. В наши дни они, как правило, неплохо знают теорию, но не умеют применять знания на практике. Их можно сравнить с водителями, которые выучили правила движения, но еще не выезжали на дорогу. Всё, что им нужно — опыт на реальных проектах.
Если держать эту мысль в голове, взять в команду джуна уже не кажется безумной затеей. Тем более, что в голову новичка можно вложить любую информацию. Джуны схватывают на лету все корпоративные стандарты и правила — в отличие от опытных разработчиков, прошедших через десяток компаний.
Есть и другие преимущества:
Джуны берут на себя рутинные задачи, а значит, мидлы и сеньоры меньше выгорают. К тому же это выгоднее экономически: если кнопки на сайте красит джун, а не сеньор с огромной зарплатой — вы экономите.
Джуны лояльнее к компании. Если всё сделать правильно, то джуниор останется в компании надолго. Так вы экономите на найме и закрываете на будущее вопрос с высококвалифицированными кадрами.
Больше об экономике найма джунов и о работе с ними — в большой статье.
Багскрам
Вчера поднимали вопрос классификации багов. Но иногда бывает, что накапливается много неразобранных багов, или резко появляется несколько критических багов, или в багах сложно разобраться, или непонятны приоритеты багов.
Для таких случаев существует багскрам – встреча с целью однозначно определить суть бага, актуальность, приоритет, назначить исполнителя и сроки исправления. На ней же можно классифицировать баги по причине возникновения.
Кто участвует: тестировщики, команда разработки и руководитель проекта. Если система сложная, то ещё аналитики. Встреча получается дорогой, поэтому проводить её нужно, понимая цель, чётко и быстро.
Подготовка: выбрать скоуп багов, которые хотите разобрать.
Сама встреча:
Ведущий встречи открывает каждый из багов.
Тестировщик, который завёл баг, тезисно описывает проблему.
Команда обсуждает баг, появляется и фиксируется дополнительная информация. Далее определяется приоритет, назначается ответственный. Во время обсуждения ведущему нужно следить за тем, чтобы встреча не уходила не в то русло и шла чётко по плану.
После обработки бага оставляется комментарий, что баг рассмотрен на багскраме, чтобы повторно не обсуждать.
Периодический багскрам в целом не даёт багам накапливаться и превращаться в неуправляемую массу.
А на тех проектах, где у нас проводится багскрам, конечно, зафиксирован процесс: участники, периодичность, правила, примеры фильтрации багов в системе контроля задач. Чтобы любой человек мог ознакомиться с процессом.
Анализ источника багов как начало улучшения процессов работы в команде
У нас есть один достаточно сложный и душный проект. На нём трудятся специалисты самых разных направлений, в том числе бизнес-аналитики, системные аналитики, разработчики, тестировщики. Сложный проект и такая команда требуют качественной координации и слаженной работы – что-то сломаться может где угодно.
Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.
Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?
В результате этого процесса получилось классифицировать баги:
– кейс не проработан бизнес-анализом;
– кейс не проработан системным анализом;
– в требованиях нечёткие формулировки: аналитик написал как-то расплывчато, разработчик не пошёл уточнять;
– ошибка разработчика;
– ёпрст, никто об этом не думал, бизнес сам не представлял, что такое бывает.
Такая классификация позволила нырнуть глубже и посмотреть, в каких местах стоит что-то чинить.
Меня, конечно, в первую очередь интересует системный анализ и разработка, на этом и сосредоточились. Решили:
✅ По части разработки выявили проблему тестирования миграций, команда бекенда пошла думать, как улучшить тесты в эту сторону, а также продумать алертинг.
✅ По части системного анализа изучили существующие требования и места рассинхрона. Особое внимание обращали не на техническое решение, а на структуру документа, уровни детализации, проработали конкретные формулировки, договорились об исправлениях.
Из рабочего чата, залипательное — хороша почти каждая строчка, даже мелкий текст по периметру :)
Привет! Это подкаст «Айтидо» от команды мобильной разработки Альфа-Банка 🎙 В втором выпуске подкаста мы поговорили с Николаем Крыловым, техлидом мобильной разработки.
Обсуждаем разное — от карьеры проводника в РЖД до погружения в фотографию. Коля рассказал, как пофигизм помогает ему быть лидом, как выстроены производственные процессы и почему сотрудники порой их нарушают. А также поделился советом, как спастись от выгорания и переработок ⏰
Ссылки на подкаст:
🔗 RuTube
🔗 YouTube
🔗 ВКонтакте
🔗 Яндекс Музыка
Подписывайтесь на Tелеграм-канал Alfa Digital, там много интересного о нашей корпоративной культуре и технологиях.
Запускаем конвейер: отечественные решения для всех этапов разработки
📅 22 октября в 11:00 (МСК) на онлайн-митапе поговорим об отечественных решениях для всех этапов жизненного цикла разработки ПО: проведем демо конвейера разработки, в реальном времени рассмотрим основные принципы работы с инструментами и ответим на все вопросы.
Ключевые темы:
🔹 планирование и управление требованиями: Teamstorm для эффективной
организации процесса разработки
🔹 разработка: GitFlic для автоматической сборки и доставки приложений, управления версиями кода, хранения артефактов для сборки
🔹 тестирование: Test IT для организации проведения ручных и автотестов
🔹 безопасность: Nova для управления жизненным циклом контейнеров
Спикеры:
🔹 Михаил Рябов, Директор продукта TeamStorm
🔹 Денис Рамазанов, Директор по развитию GitFlic
🔹 Руслан Остропольский, Директор продукта Test IT
🔹 Максим Морарь, Директор продукта Nova
🔹 Дарья Березинец, Инженер-тестировщик К2Тех
🔹 Алексей Патрин, Системный архитектор К2Тех
🔹 Лидия Башлыкова (модератор), Партнер-менеджер К2Тех
🔗 Подробности и регистрация по ссылке
За что платят деньги фронтендерам?
Гость нового выпуска подкаста «Мы обречены» — Павел Федотов, техлид команды Dev в Авито. Вместе с Глебом Михеевым и Заром Захаровым он обсуждает:
почему фронтенд — это сложно?
почему все фронтендерские фреймворки и библиотеки необходимы?
и, конечно же, почему фронтендерам столько платят?
Много вопросов и ещё больше ответов — в новым выпуске подкаста «Мы обречены».
А о том, как фронтендеру стать тимлидом кросс-функциональной команды, в своей статье рассказал Илья Оболенский.
Подписывайтесь на канал AvitoTech в Telegram: там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Так получилось, что я испытываю нежные чувства к настольно-ролевым играм в целом и Dungeons & Dragons в частности. Всегда казалось логичным, что их пытаются применять в работе.
Вот один из победителей прошлого Технотекста @iktash пишет о том, как D&D помогает тимлидить.
У партии в D&D и рабочего проекта действительно много общего:
и там, и там люди выполняют определённые роли
часто перед игроками и сотрудниками стоит понятная задача (иногда задачи нет, но тогда они придумывают её сами)
без командной работы решить задачу очень трудно
Когда в очередной раз думал об этом, стало интересно: что будет, если как есть перетащить некоторые практики ролевых игр в рабочие процессы?
Обсуждать алаймент на ревью — это, конечно, шиза. Но в D&D есть такая штука, как степень успеха — игрок выполнил задачу, но вместе с результатом получил негативный эффект, потому что не проявил достаточного мастерства. Или наоборот — выложился сверх необходимого и результат получился лучше, чем ожидалось.
На следующем ретро попрошу ребят оценить так проект. Кажется, что будет проще выискивать подводные камни:
Эпик закрыт без особых проблем, но в процессе мы затронули старый кусок функциональности, который может стать проблемой в будущем — надо переписать.
Каким образом выстроены процессы поддержки командного духа у вас в компании?
Важное уточнение: Вопрос относиться больше к тем, кто работает в компаниях с «полной удаленкой»
Когда я работал в офисе, у меня был коллега который закончил СПбГЭТУ «ЛЭТИ», ну, в прочем это не суть важно, просто человек он был очень интересный, и такой же жадный до знаний в сфере как и я. И собственно из этого складывалось активное общение, обсуждение разного рода тем программирования, проектирования и прочего. В том числе, подобным образом мы внедряли разного рода фичи в нашу команду и трек разработки. Так же за счет наших разговоров удавалось подключать других коллег которым было так же интересно послушать нас.
Но вот я уже 2 года работаю на удаленке и процессы связанные с неформальным общением, обсуждением разного рода тем связанных с разработкой повсюду (в разных компаниях) — неоднозначны.
Хотелось бы узнать мнение других людей на этот счет, каким образом решение подобной проблемы выстроено в вашей компании?
Вышел новый Sravni Podcast: про устройство мобильной разработки и управление её процессам
С Денисом Сизым, тимлидом Сравни, обсудили специфику приложений для iOS и Android, сложности с проверками в сторах, преимущества Backend Driven UI и развитие в ИТ — от написания первого калькулятора на Pascal до управления командой.
Также в подкасте:
Как и для чего сеньор становится тимлидом?
В чем польза архитектурного мышления?
Почему все «сидят в телефонах», но важным чаще пользуются в вебе?
Бывают ли в идеальном мире дейлики?
Посмотреть или послушать подкаст можно здесь:
Больше полезных видео, статей и других ИТ-материалов — в ТГ инженерного сообщества Sravni Tech.
Как «устаканить» цены на российское ПО
Цены на российское ПО поднялись в сентябре на 15—20%. Почему? Формально это затрагивает только госструктуры и компании с госучастием, а коммерческие компании вольны выбирать ПО сами. Только с каждым очередным разработчиком, который отключает свои сервисы в РФ, всё меньше желания искать пути подключения зарубежного ПО, и в итоге повышение затрагивает всех.
Разработчиков можно понять: затраты на создание ПО в лучшем случае сравнимы, рынок сбыта меньше. Если разработчика не устроит зарплата, он может перейти в западную компанию, а вот сбыт ПО и сервисов возможен в России и странах, не подключившихся к санкциям.
Прежде чем софт продать, его надо создать. Из-за текущей высокой банковской ставки кредиты получаются дорогими и дают вклад в себестоимость продукта. Да, она принята, исходя из экономических факторов, но всё-таки государство может помочь IT. Недавно введённый налог в 5% меньше, чем у большинства компаний, но в сочетании с высокой ставкой кредитования превращается в увеличение стоимости продуктов и сервисов разработчиков из РФ. Повышение цен в таких условиях неизбежно, и можно лишь стимулировать компании, минимально повышающие цены. Точно ли государство выиграло от его введения?
Применение опенсорса несёт как плюсы, так и минусы, но для многих компаний это способ снизить стоимость разработки. И учитывая, как перекрываются доступы российским разработчикам к некоторым опенсорсным продуктам, стоит думать о собственных решениях.
TeamLead T-Sync: загляните в самое сердце культуры тимлидов Т-Банка
Быть тимлидом интересно, но непросто. Поэтому так важно иметь возможность обменяться опытом, поговорить о наболевшем и послушать, как справляются со сложностями другие. Чтобы вы смогли все это сделать, мы кое-что придумали.
Приглашаем на TeamLead T-Sync. С нас — доклады, открытая дискуссия, спид-дейтинг и нетворкинг. А еще — билет на Fast Track в команду Т-Банка.
Встречаемся 19 сентября в нашей штаб-квартире T-Space в Москве. Ждем тимлидов с опытом от года и бэкграундом в разработке.
Что будет:
— Доклады. Лучшие практики и кейсы от ИТ-менеджмента Т-Банка. Выступления о том, кто такой тимлид у нас и как мы работаем с метриками.
— Открытая дискуссия. Делитесь кейсами, которые можем разобрать вместе.
— Спид-дейтинг c мидл-менеджментом Т-Банка. Задавайте вопросы о команде, процессах, возможностях внедрять изменения, карьерных амбициях и обо всем, что вам интересно.
— Нетворкинг. Для вас — комьюнити сильных тимлидов, обмен идеями и экспертностью, вдохновением и мотивацией и все, что пригодится для разговора о самых важных вещах в профессии.
— Fast Track в Т-Банк для тех, кому это интересно. Если после ивента захотите стать частью нашей команды, быстро проведем все интервью. А если нужно время подумать, приходите к нам в течение месяца — все это время будет действовать Fast Track.
Будем вас ждать. Подавайте заявку до 17 сентября на сайте.
