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

В индустрии разработки программного обеспечения очень много времени и ресурсов тратится на совещания. У многих менеджеров календарь большую часть времени забит встречами.

По данным исследования компании Atlassian, средний работник тратит до 31 часа в месяц на непродуктивные совещания. Это примерно 8 часов в неделю, что равносильно полной рабочей неделе одного сотрудника из команды из пяти человек каждый месяц. Если мы переведем это в рабочие дни, то получается, что в среднем четыре человека работают, а один постоянно находится на совещаниях. Это не учитывает дополнительное время, потраченное на неформальные обсуждения и ad-hoc встречи, которые еще больше сокращают время, доступное для непосредственной работы над созданием продукта. Таким образом, разработчики фактически проводят менее половины своего рабочего дня на прямую разработку, что является тревожным сигналом для любой организаци.

Лично я не люблю митинги. Я всегда стараюсь минимизировать общение, если вопрос можно решить без личной встречи. Это правило я применяю как в работе, так и в жизни. Например, я предпочитаю заправлять автомобиль, используя приложение, а заказ еды и другие услуги я стараюсь осуществлять без необходимости подтверждения от оператора, и я делал это даже тогда, когда такой подход был не так распространен. Если мне нужно найти место, я открою карту в приложении, вместо того чтобы спрашивать направление у прохожих.

Мое нежелание тратить время впустую или неэффективно, вылилось в то, что в департаменте разработки программного обеспечения мы тщательно следим за временем, которое наши разработчики тратят на совещания. В среднем, на разработчика приходится всего 2 часа 15 минут обязательных совещаний в неделю, включая четыре стендапа по 15 минут, встречу 1 на 1 с руководителем на 30 минут каждые две недели и 60 минут на различные совещания, такие как планирование и демонстрации. Остальное время, примерно 5 часов 45 минут, уходит на прочие активности в MS Teams, включая чаты и единичные созвоны. Хотя мы считаем, что и это время следует оптимизировать, основное внимание мы уделяем именно ключевым совещаниям, чтобы убедиться, что каждая минута проведенного времени имеет ценность.

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

Я использую Архимейт в своей работе уже более 7 лет. Когда я познакомился с этим языком, то он привлек меня тем, что позволял изображать систему в динамике, то есть отображать не только структуру программы, но и бизнес-процессы, которые она автоматизирует, и средства, на которых она развернута. К тому же Архимейт казался очень простым — подумаешь, каких-то 10 стрелок и 20 компонентов. На тот момент я был уже очень опытным программистом и архитектором, у меня был огромный опыт проектирования систем и баз данных, также я на приличном уровне освоил несколько языков программирования. И казалось, что выучить такой простой язык — это дело нескольких часов.

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

Каждая команда разработчиков сталкивается с тем, что в ней появляется кто-то молодой и неопытный. Это естественно. Компания рассчитывает, что новый сотрудник как можно быстрее начнет оправдывать вложения, но по факту это прежде всего зависит от действий остальной команды. Далее в посте мы дадим ряд советов, чтобы этот этап завершился как можно быстрее и эффективнее.

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

В качестве примера я взял свой недавний опыт "найма" джуна. 😀

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

Привет! Приятно ведь читать хорошо оформленные статьи на уютном хабре? В которых часть текста спрятана под катом, есть подписи к картинкам, красивые и понятные таблицы и все остальные плюшки? Я думаю очень приятно. Поэтому предлагаю рассмотреть немного полезных советов, о том какие макросы в Confluence помогали делать это раньше, а теперь точно также помогают в EvaWiki.

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

Статья может быть полезной для тех, кто активно работал в Confluence и хочет точно также делать это в нашем ПО.

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

Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.

Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.

Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.

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

С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.

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

Привет, Хабр! Технический долг есть в любом крупном проекте. Он возникает, когда копятся компромиссные решения, проблемы в коде или архитектуре. Важно, что эти решения и проблемы усложняют и удорожают поддержку и обновление кода в будущем. Это своеобразные «проценты». Чем больше долг, тем больше «процентов» приходится платить.

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

Всем привет! Меня зовут Юстина Цига, и я владелец продукта IIoT в Цифровом СИБУРе.

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

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

Всем привет! Меня зовут Виктор, я работаю в Компании БФТ-Холдинг руководителем группы разработки. В этой статье разберем подходы и рекомендации по выявлению и устранению проблем с производительностью в системе базы данных Greenplum. Материал будет особенно полезен начинающим разработчикам Greenplum, которые пока не имеют достаточного опыта «чтения» плана запроса.

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

Сопоставление организации планирования в машиностроении с подходами при планировании разработки программного обеспечения.

Продолжаем рассмотрение опыта автоматизации планирования и учета в машиностроении и сопоставляем с подходами в ИТ. С предыдущими частями статьи можете ознакомиться по ссылкам: Часть 1 и Часть 2.

Думаю, что после прочтения статьи Никиты Прокопова «JavaScript Bloat in 2024» (рус. «Насколько потолстел JavaScript к 2024 году?») не я один стал с пессимизмом смотреть на будущее веб-разработки. Хотя тема раздутия JavaScript не нова (одним из первых на эту проблему обратил внимание Эдди Османи в своей статье-отчете «The Cost Of JavaScript» (рус. «Сколько стоит JavaScript?») в 2017 году), но здесь поражает масштаб проблемы, обозначенный автором статьи.

Нечто подобное было с HTML (и в какой-то степени с графикой) на ранних этапах развития Всемирной паутины (далее веб). Проблему раздутия HTML удалось практически полностью решить к середине 00-х за счет внедрения веб-стандартов и совершенствования WYSIWYG-редакторов HTML. Появление технологии AJAX и одностраничных приложений (SPA) сместило акцент на JavaScript, но это не привело к мгновенному утяжелению веб-приложений (например, первые версии Gmail прекрасно работали даже на самых медленных dial-up-соединениях).

Ситуация начала меняться в худшую сторону где-то на рубеже 00-х и 10-х, когда стали появляться первые смартфоны. Разработка ПО стала постепенно усложняться, дорожать и носить более конвеерный характер. Начался массовый найм разработчиков, повсеместное внедрение гибких методологий разработки и стала расти доля работы, отдаваемой на аутсорс. В веб-разработке наступила эпоха фреймворков и инструментов сборки для фронтенда. Со временем подходы, которые были призваны снизить порог входа в профессию, временные и финансовые издержки, стали давать обратный эффект.

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

Кадры или, если брать шире, люди по-прежнему решают все, и сфера Machine Learning — не исключение. Но подбор специалистов, поддержание работоспособности команды, отношения с заказчиками — все в этой области имеет определенную специфику.

Как проводить собеседования, что общего между сеньорами и ворами в законе, зачем тимлиду быть еще и психологом, наконец, какие magic tools облегчают жизнь команде? Обо всем этом нам рассказал senior-разработчик и DL-инженер Роман Тезиков, который собаку съел в работе с людьми на ML-проектах. Передаем ему слово.

На разработку и успешность сервиса влияет то, как его будут запускать — внутри существующего продукта или отдельным приложением. В этом посте Михаил Мельников, продакт-лид Отелло, рассказывает, как мы в 2ГИС решаем, где запускать: внутри или снаружи.

Привет, Хабр! Меня зовут Анастасия, я из Газпромбанк.Тех. На текущий момент являюсь одним из HOP QA, но довольно долго была просто тестлидом. Поэтому много мыслей в этой статье использованы ещё с того периода времени.

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

Привет, меня зовут Артём Говердовский, и я дизайн-директор в Сбер Домклик. В моëм подчинении 49 дизайнеров, среди которых 6 лидов. Хочу рассказать, как у нас получилось переформатировать дизайн-отдел, распределить зоны ответственности, настроить процессы, справиться с легаси и полностью синхронизироваться по всем проектам за 9 месяцев работы.

Развитие AI-инструментов на базе современных LLM запустило в последние годы тренд на автоматизацию всего, что прибито меньше, чем на 2 гвоздя, и первыми адоптерами здесь традиционно выступает IT сообщество. Как Луи Пастер некогда ставил себе и друзьям намешанные на голой коленке вакцины, так сейчас разработчики активно ставят Code Copilot-ы, дизайнеры экспериментируют с Midjourney, скромно к этой очереди пристраиваемся и мы, Product Manager-ы.

Меня зовут Алексей, и я более 15 лет занимаюсь управлением b2b-b2c продуктами и руководством командами в энтерпрайзе и стартапах.

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

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

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

Данный регламент я написал на основании опыта работы лидом в IT компании с веб-приложением. Пункты из него прошли проверку практикой. Изначальные версии были основаны на best practice из интернета, agile и опыта предыдущих и текущих руководителей.

Здесь нет привязки на какую-то определенную систему трекинга задач. Использование возможно как для JIRA, Kaiten, GitLab, Trello, так и для excel-таблицы.