Как стать автором
Обновить
242.98

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

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

METEOR. Что может? Чем полезен?

Уровень сложности Простой
Время на прочтение 8 мин
Количество просмотров 253

Привет! На связи команда METEOR Cloud. Ранее опубликовали статью-знакомство, где рассказали о себе и новом таск-трекере для любой компании, который сделала наша команда. Получили много вопросов, которые касались возможностей METEOR. Поэтому расскажем больше о функционале, рассмотрим детально интерфейс и способы работы.

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

Читать далее
Всего голосов 2: ↑2 и ↓0 +2
Комментарии 0

Новости

Как мы автоматизировали и упростили процесс ведения релизов

Время на прочтение 5 мин
Количество просмотров 468
image

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

После трансформации весь описанный выше функционал перешёл в одну группу — «Управление релизами». Коммуникации, работу с командой тестирования, отчётность и встречи — всё стала вести наша команда.

Большая часть коммуникаций проходила в почте. Сбор, фиксацию состава релиза и отчётность — всё приходилось делать вручную. Процесс подготовки к релизу занимал до пяти рабочих дней. Релиз-менеджер каждый день из confluence сохранял pdf-файл со списком задач и сравнивал состав релиза на предмет добавленных и исключённых задач. После включения задачи в релиз тест-менеджеры самостоятельно вносили её на страницу «Актуализация регрессов» на confluence согласно цветовой легенде и определяли, какие задачи требуют изменения в тестовой модели, а какие ещё не брали в работу. Было много ручных активностей релиз-менеджеров и тест-менеджеров, и это заставило нас подумать над частичной автоматизацией процесса ведения релизов.

Дальше я расскажу в деталях, как всё было «до» и как стало «после».
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 0

Продуктивность в тишине: Отказ от совещаний как идеал

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 1.2K

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

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

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

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

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

Читать далее 🔥
Всего голосов 6: ↑4 и ↓2 +2
Комментарии 2

Как быстро выучить язык моделирования Archimate?

Время на прочтение 4 мин
Количество просмотров 2.4K

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

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

Читать далее
Всего голосов 10: ↑3 и ↓7 -4
Комментарии 5

Истории

Как сделать джуна полноценной частью команды

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 1.6K

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

Читать далее
Всего голосов 19: ↑16 и ↓3 +13
Комментарии 1

От А до Я: Руководство по воспитанию молодых специалистов (на необычном примере )

Уровень сложности Простой
Время на прочтение 3 мин
Количество просмотров 2K

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

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

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

Читать далее
Всего голосов 17: ↑14 и ↓3 +11
Комментарии 6

Как использовать макросы для систематизации документов «как в Confluence»?

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 971

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

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

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

Читать далее
Всего голосов 9: ↑7 и ↓2 +5
Комментарии 0

Спринт с багами, или как (не) создать себе проблем

Уровень сложности Простой
Время на прочтение 3 мин
Количество просмотров 4.2K

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

Читать далее
Всего голосов 15: ↑10 и ↓5 +5
Комментарии 24

Передача контекста и знаний в IT команде

Уровень сложности Простой
Время на прочтение 19 мин
Количество просмотров 1.2K

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

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

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

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

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

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

Читать далее
Всего голосов 10: ↑8 и ↓2 +6
Комментарии 0

О причинах технического долга, том, как с ним бороться и убедить бизнес, что это проблема

Время на прочтение 3 мин
Количество просмотров 1.1K

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

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

Читать далее
Всего голосов 12: ↑8 и ↓4 +4
Комментарии 6

Выученные уроки молодого продакта

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 1.9K

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

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

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

Читать далее
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 2

5 стадий принятия необходимости изучения «плана запроса» или почему может долго выполняться запрос

Уровень сложности Простой
Время на прочтение 14 мин
Количество просмотров 3.8K

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

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

Читать далее
Всего голосов 7: ↑7 и ↓0 +7
Комментарии 0

Опыт организации планирования в машиностроении применительно к ИТ. Часть 3

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 780

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

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

Читать далее
Всего голосов 4: ↑3 и ↓1 +2
Комментарии 0

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн

Высказывания трех известных людей о проблемах современной разработки ПО

Уровень сложности Простой
Время на прочтение 8 мин
Количество просмотров 3.4K

Думаю, что после прочтения статьи Никиты Прокопова «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-х, когда стали появляться первые смартфоны. Разработка ПО стала постепенно усложняться, дорожать и носить более конвеерный характер. Начался массовый найм разработчиков, повсеместное внедрение гибких методологий разработки и стала расти доля работы, отдаваемой на аутсорс. В веб-разработке наступила эпоха фреймворков и инструментов сборки для фронтенда. Со временем подходы, которые были призваны снизить порог входа в профессию, временные и финансовые издержки, стали давать обратный эффект.

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

Читать далее
Всего голосов 17: ↑14 и ↓3 +11
Комментарии 20

Добрый доктор для ML-команды: как тимлиду работать с людьми

Время на прочтение 9 мин
Количество просмотров 911

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

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

Читать далее
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 0

Внутри нельзя снаружи: как мы решаем, где запускать новые сервисы

Уровень сложности Средний
Время на прочтение 5 мин
Количество просмотров 532

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

Читать далее
Всего голосов 8: ↑6 и ↓2 +4
Комментарии 0

Прозрачность процессов как инструмент эффективного взаимодействия

Время на прочтение 11 мин
Количество просмотров 743

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

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

Читать далее
Всего голосов 14: ↑12 и ↓2 +10
Комментарии 0

Шаг за шагом: как добиться синхронности в дизайн-команде за 9 месяцев

Уровень сложности Средний
Время на прочтение 16 мин
Количество просмотров 1.2K

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

Читать далее
Всего голосов 20: ↑19 и ↓1 +18
Комментарии 6

JIRA + AI = LOVE или Как Product manager-у найти друзей и перестать страдать

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 1.8K

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

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

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

Читать далее
Всего голосов 14: ↑13 и ↓1 +12
Комментарии 4

Книга «Жемчужины разработки. Чему мы научились за 50 лет создания ПО»

Время на прочтение 16 мин
Количество просмотров 3.3K
imageПривет, Хаброжители!

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

Опыт — главный учитель, но медленный и нередко болезненный. Но зачем же нам повторять ошибки? Книга «Жемчужины разработки» поможет совершенствоваться быстрее и избежать многих проблем, обучаясь на опыте других людей, которые уже поднялись по кривой обучения. Карл Вигерс сформулировал 60 кратких практических уроков, которые подойдут для любых проектов, независимо от роли, отрасли, технологии или методологии.

Идеи и конкретные рекомендации охватывают шесть важнейших элементов успеха: требования, дизайн, управление проектами, культуру и командную работу, качество и совершенствование процессов. Для каждого из направлений Вигерс предлагает «первые шаги», позволяющие осмыслить собственный опыт, уроки с основными идеями, реальными примерами и действенными решениями и «следующие шаги» для внедрения опыта в вашем проекте, команде или организации. Эти знания нельзя получить в университете!
Читать дальше →
Всего голосов 15: ↑13 и ↓2 +11
Комментарии 7

Вклад авторов

Работа