Управление разработкой *

Если вы часто ходите на собеседования, то вы достаточно часто можете столкнуться с ребятами, которых HR представляет тимлидами, но при этом они показывают 10 красных флагов из 10 еще на этапе приветствия. И возникает вопрос, а зачем этих ребят поставили тимлидами, если это явно не их.

Возможно дело состоит в том, что в IT принято ставить тимлидом какого-то крутого инженера, давать ему книги типа: "Как пасти котов" или "Мама, я тимлид". И дальше надеяться, что человек как-то познает дзен и сможет выполнять работу тимлида.

Однако, что если вам нужно найти правильного человека, а не обучать того, кого обучать не стоит?

Как странно иногда пересекаются личности сказочных героев, современные технологии и древняя философия... В лучших традициях современного приключенческого романа герои сойдутся на страницах этой статьи, чтобы переплести линии своих судеб, заставить читателя изрядно поволноваться и, наконец, привести его к захватывающему и неожиданному финалу...

Представьте: вы придумали классное решение внутри своего продукта, которое в разы упростит жизнь клиентам. Анонсировали в СМИ коллаборацию с известной компанией, пилите интеграцию и готовитесь успешно выкатить релиз. Но внезапно выясняется, что при разработке потерялось важное бизнес-требование. Теперь проект висит на волоске, вы рискуете потерять репутацию, доверие общественности и партнеров, а еще затянуть проект минимум на полгода. Ситуация патовая.  

С такой историей столкнулась наша команда, но нам удалось вовремя перестроиться и не слить впустую много месяцев интенсивной разработки. В статье рассказываю, как мы продумали и запустили интеграцию, а еще спасли репутацию двух больших компаний благодаря четким и прозрачным внутренним процессам.

Discovery процесс — это этап в разработке продукта, направленный на исследование и оценку идей до начала их реализации. В рамках Discovery команды анализируют, насколько идеи жизнеспособны, экономически обоснованы и технически реализуемы. Управление Discovery процессом помогает минимизировать риски и избегать ненужных трат на разработку идей, которые не принесут ценности бизнесу или пользователям.

Одним из ключевых инструментов для управления Discovery процессом является его визуализация. Визуальные доски позволяют командам видеть этапы работы, управлять приоритетами и отслеживать прогресс, делая процесс более прозрачным и управляемым.

Меня зовут Валерий Студенников, я программист, и вершиной моей IT-карьеры стала компания REG.RU, где я был сооснователем, техническим директором и руководителем разработки.

За 10 лет REG.RU стала №1 в России по количеству зарегистрированных доменных имен, а затем вошла в тройку лидеров по web-хостингу и VPS. В 2021 году мы с партнером продали компанию, я ушел «на пенсию» и с тех пор занимаюсь преподаванием в Самарском университете, обучая студентов различным IT-предметам.

Именно в REG.RU я стал активно применять гибкие методологии и впервые столкнулся с Kaiten, и так получилось, что и то и другое забрал с собой и сейчас использую в преподавательской деятельности. Собственно, об этом и хочу рассказать.

Привет! Меня зовут Борис Рябов, я руководитель отдела разработки интерфейсов в ЮMoney и по совместительству — Product Owner платформенной команды. Поделюсь, чем такая команда может быть полезна бизнесу, почему этот подход нам подошёл и к каким трудностям надо подготовиться.

Многие компании, успешно работающие по Agile в одной команде, сталкиваются с проблемой масштабирования. Когда число команд растет, а Agile-принципы не адаптируются на более высокий уровень, начинается хаос. Команды теряют синхронность, задачи не выполняются в срок, и возникают проблемы с прозрачностью процессов. 

Чтобы справиться с этими вызовами, были созданы фреймворки масштабирования, такие как LeSS, SAFe и Nexus. В этой статье мы рассмотрим их основные принципы и рекомендации по применению.

В статье хотел бы поделиться наблюдениями о вызовах, с которыми сегодня сталкиваются команды разработки, а также представить наработки, основанные на личном опыте руководства проектами и продуктами в нефтегазовой сфере.

Почему это актуально? В мире ИТ мы находимся в условиях постоянно меняющихся потребностей и активной конкуренции. Успех наших решений и эффективность взаимодействия между собой напрямую влияют на наше будущее. Существует мнение, что в будущем будут две профессии: те, кто следит за компьютерами, и те, за кем следят компьютеры. Давайте обсудим, как адаптироваться к этим изменениям и оставаться на шаг впереди.

Обычно я работаю над статьями для других — пишу что-то для компаний, помогаю коллегам с редактурой их материалов. Но сегодня хочется сделать что-то для себя, что, возможно, сделает мою жизнь и работу немного лучше. Ведь если это поможет мне, то, вероятно, поможет и вам (но это не точно).

В этой статье я подниму тему о том, как мы используем мессенджеры для работы и почему смешение личного и профессионального общения в одном приложении — это путь к выгоранию и, как следствие, к потере продуктивности и мотивации. Подробнее, как водится, — под катом. Залетайте.

На всякий случай отмечу, что идея этой статьи родилась за пару недель до ареста Павла Дурова и никак не связана с этим ужасным случаем.

Какой будет команда КХД, решает бизнес. Определяющими факторами могут быть объем хранилища и количество средств, которые готовы вкладывать в его развитие. Взвешиваем за и против и составляем оптимальную команду и схему постановки задач.

Цифровизация предприятия ведется за счет внедрения интегрированных программных систем для управления бизнес-процессами и базами данных. Комплексное программное обеспечение задает класс систем вида ERP, который часто в русскоязычной литературе называют корпоративными информационными системами. Сложность имплементации ERP-систем состоит в том, что одновременно должны решаться задачи по оптимизации бизнес-процессов, разработке программ, переносу данных, управлению изменениями, настройке технической инфраструктуры и «дирижированию» проектом. Миграция информации из исторической системы в целевую систему является одной из важнейших проектных задач, так как низкое качество начальных данных может заблокировать выполнение бизнес операций и их отражение в программной системе. Качественный процесс переноса данных обеспечивается правильно подобранной и реализованной стратегией миграции. Какие стратегии существуют, каковы их особенности и способы выполнения? Мы постараемся найти ответы на эти вопросы в данной статье.

Несмотря на важность вопроса мигрирования данных корпоративных информационных систем, литературных источников, дающих исчерпывающее представление о переносе информации не так много. Но даже в них есть изъяны: или слишком поверхностное описание, или излишняя детализация, исключающая стратегию как таковую. Примером первой категории работ служит статья [1], повествующая о миграции данных в SAP ERP, однако тонкости и детали переноса основных и переменных данных в ней не раскрыты. Прочие работы [2-3] дают максимум информации по автоматизированным средствам переноса данных в той же системе SAP, хотя взаимосвязь между техническими средствами и концепцией, стратегией, видением не прослеживается. Все это подчеркивает необходимость детального анализа миграции данных ERP-систем, что особенно актуально для транзакционных информационных систем.

В этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.

Эта статья будет о наболевшем. О правилах в разработке и что бывает, когда их нет.

Она не совсем про Руководство проектами, она пошире: про руководство командами разработки. Но если вы Руководитель и у вас на проекте разработки ПО есть хотя бы пара разработчиков, вам ее будет полезно прочитать.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

Правила – это скучно.

Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?

В своей карьере я работала в таких компаниях, как Авито, Rutube, МТС, сейчас работаю в Банке [NDA] — и везде у меня была команда разработки самостоятельна. 

Где каждый член команды мог не только выполнить свою часть работы, но и рассказать про цели: от годовых по нашему стриму до каждой отдельно взятой задаче, также мог выступить на ревью, где с удовольствием расскажет бизнес-часть, покажет графики и, конечно же, работающий продукт.

Это кажется идеалом, но на самом деле, это вполне реализуемая задачка для менеджера. В этой статье я поделюсь своим подходом и опытом, как продакт-менеджеру освободить больше времени для Discovery и уменьшить свою вовлеченность в Delivery, делегируя ответственность команде и создавая условия для их самостоятельности.

Несмотря на то, что наши сегодняшние процессы выглядят достаточно устойчиво, хотелось бы, во-первых, иметь возможность вовремя увидеть возможные негативные тенденции и причины их возникновения, а во-вторых, оставаться открытыми к полезным инициативам.

Всё это сподвигло нас к анализу накопленного опыта и имеющихся материалов в области процессов разработки с акцентом на взаимоотношения в коллективах. Мы — это Евгений Филимонов и Андрей Клюйков, инженеры по тестированию КОМПАС-3D.

В ходе проработки содержания статьи мы решили сгруппировать попарно антипаттерны, являющиеся крайними проявлениями одной сущности, и придать им гротескную форму. Мы посчитали, что через призму таких антипаттернов будет проще обратить внимание на те области наших процессов, которые имеют потенциал к улучшениям и оптимизации. Особенно это актуально, когда масштабы задач непрерывно растут и наблюдаются достаточно высокие темпы роста штата сотрудников.

И наконец, чтобы приблизиться к пониманию актуальности темы антипаттернов, решили провести небольшой опрос среди коллег, результаты которого приведены в конце статьи.

Это история разработки B2B решения для планшетов, чтобы увеличить их востребованность в сфере образования. Вначале мы совершили все возможные ошибки: считали себя самыми умными, путались в «болях» целевой аудитории вместе с фокус-группой. Всё нравилось менеджерам, разработчикам и, главное, начальству. Затем пилот решения дошёл до пользователей и пришло время отваги для осознания наших заблуждений.

Чем более сложными становятся ИТ-проекты, тем больше им требуется функциональных лидеров — тимлидов и техлидов. Эти роли в команде объединяют административные и технические обязанности и открывают новые карьерные перспективы для сотрудников.

Как специалисты становятся тимлидами и техлидами? В чем разница между ними? Какие навыки для них нужны? Поговорили с экспертами ПСБ, чтобы найти ответы.

Как  разработчики большой мультибрендовой торговой площадки (Faire) внедрили автоматизированные c LLM  Code Review (статья - мой перевод для нашего ТГ канала посвященного разработке софта при помощи LLM). 

В Faire мы верим в ценность код-ревью и всегда придерживаемся этой практики. Хотя многие аспекты код-ревью требуют глубокого понимания проекта, существуют также множество общих требований, которые можно учесть без дополнительного контекста. Например, наличие ясного заголовка и описания, достаточное покрытие тестами, соблюдение стиля кода, выявление изменений несовместимых между сервисами.

Похоже, что LLM хорошо подходят для выполнения таких общих задач код-ревью. Имея достаточно информации о pull request: метаданные, diff, логи сборки и  отчеты о покрытии тестами, можно эффективно настроить LLM для добавления полезной информации, выявления багов или потенциально опасных изменений и даже автоматического исправления простых ошибок.

«Что там с базами, не пора ли добавлять ресурсов?» — казалось бы, звучит как дежурная реплика менеджера, и классический ответ на неё: «всё ок, до конца недели должно хватить!». 

На деле этот безобидный на первый взгляд вопрос может быть сигналом о целом ворохе проблем. Важно разобраться, почему его задают (можно ведь посмотреть алерты и мониторинг), о чём именно речь (у нас точно всё ок с архитектурой?), как часто вопрос возникает (сколько денег мы тратим на содержание баз?).

Однажды на вопрос «что там с базами?» мы в команде решили ответить несколько иначе. Вместо «до конца недели должно хватить» — сказали: «давайте мигрируем базы в единый кластер, а тяжёлые файлы перенесём в S3».

О том, что из этого вышло, читайте под катом.