На мой взгляд, лучший способ координации независимых команд — это не координировать их вовсе. Более того, я считаю координационные встречи между командами признаком проблемы в архитектуре. То, что возникает необходимость обсуждать вопросы с другими командами, свидетельствует о слишком тесной взаимосвязанности команд. В статье попробуем поразмышлять на эту тему.
Всем привет! Меня зовут Светлана Уварова, я работаю в МТС Диджитал архитектором. Сегодня я расскажу о Зле, которое может сокрушить целые ИТ-команды. Стоит только одному человеку поддаться ему, как оно перекидывается на его коллег. Поставленные цели не достигаются, новая функциональность не поступает на прод, а проект потихоньку умирает. Имя этому злу — Демотивация. Если не заметить ее начало, поддаться соблазну и опустить руки, то она постепенно ломает командную работу и приводит к выгоранию. В этой статье я расскажу, как отследить наступающую Демотивацию и чем ей противостоять.
Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработчиков. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.
Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!
Бывает, есть проблема: люди перегружены работой, но сроки проектов едут; услуги оказываются, а клиенты не платят; команда делает кучу всего, а в цели квартала не попадает. И причины толком не понятны — усилий тратится много, а результат никакой. Только напряжение и недовольство.
В таком случае, может пригодиться концепция границ группы, которая широко применяется в психологии, социологии и организационной теории.
В мире, где технологии несутся вперед со скоростью света, а стартаперы едва успели окончить школу, найти работу в IT после 60 кажется чем-то из области фантастики. Однако опыт Сергея Вяткина, senior software engineer в американской компании Moody's Corporation, доказывает: в программировании возраст — это просто число в переменной.
Всем привет! Когда команды давно работают вместе по своим устоявшимся привычным процессам, любое вмешательство вызывает настороженность, а иногда и сопротивление. А уж интеграция крупного продукта в экосистему со сложившимися стандартами — всегда рискованное мероприятие. Эта задача усложняется еще больше, когда ей ставят сжатые сроки. Но нет ничего невозможного.
Меня зовут Ирина Васильева, и я старший Agile-коуч в МТС Live. В этой статье я расскажу, как мы провели Agile-трансформацию билетного оператора Ticketland. В процессе реорганизации мы навели порядок в задачах, сохранили команду и обеспечили сервису дальнейшее развитие в экосистеме МТС. На нашем примере я покажу, что любые изменения возможны, если декомпозировать основную задачу, наладить общение между командами и придерживаться выбранного роадмэпа. «Глаза боятся, а руки делают» — об этом я и расскажу под катом.
В эпоху стремительной цифровизации, когда виртуальный мир становится неотъемлемой частью нашей жизни, роль IT-специалистов возрастает многократно. Особенно это касается компаний, которые активно внедряют цифровые решения, делая жизнь своих клиентов комфортнее и доступнее. Но кто же стоит во главе этого процесса? Кто отвечает за бесперебойную работу платформы, внедрение новых технологий и развитие цифрового сервиса? В этой статье я расскажу о роли IT Area Lead в Домклик, о том, какими навыками должен обладать этот человек и с какими вызовами он сталкивается каждый день.
Кирилл Трибунский выполняет в компании несколько ролей — главы гильдии фронтенд‑разработки и ведущего фронтенд‑разработчика команды Дизайн‑архитектура МоегоСклада.
Вот о чем рассказал Кирилл в этом интервью:
- как он переключился с бэкенда на фронтенд и попал в МойСклад;
- что проще: фронтенд или бэкенд?
- как устроена гильдия фронтенд‑разработки в МоемСкладе;
- с чего начать изучать фронтенд‑разработку;
- куда можно расти фронтенд‑разработчику;
- чем занимается фронтенд‑разработчик в МоемСкладе
- стек технологий;
- как проходит адаптация новичков в гильдии;
- и о других моментах.
2-3 августа в Перми мы провели уже третью конференцию для разработчиков и управленцев — Ural Digital Weekend 2024. В статье мы подводим итоги события, делимся полезными материалами и фотоотчетом.
В современном разработке программного обеспечения обзор кода играет критическую роль в обеспечении качества и надежности продукта. Однако ручной обзор кода может быть трудоемким и часто требует значительного внимания со стороны опытных разработчиков. Автоматизация этого процесса предлагает несколько преимуществ. Но возможна ли? Помогут ли LLM и Агенты решить эту задачу?
Осознание, что ты микроменеджер, приходит не сразу, и чаще всего только после фидбэка от подчинённых. А фидбэк этот бьёт обухом по голове, когда у сотрудников заканчивается терпение. Стоит один раз с утра спросить, как дела, из лучших побуждений предложить свою помощь, повторить это ценное предложение часа через три, подстраховать уверенного мидла или сеньора, чтобы он вдруг ощутил, что с ним обращаются как со школьником, — и вот обратная связь от коллег помогает узнать о себе что-то новое.
Даже если вы искренне хотите помочь и облегчить жизнь окружающим, микроменеджмент не перестаёт быть микроменеджментом и всё так же раздражает сотрудников.
Сегодняшняя статья не входит в цикл по организации команд разработки, а является неким изложением мыслей тимлида. А запустил поток этих самых мыслей один из комментариев к предыдущей статье, который в общих чертах обрисовывал, что созвоны это трата времени, и не более. Обсудим?
Ошибки бывают не всегда очевидны. Вот один из случаев, который у нас произошёл при попытке отловить ошибку. На неё долго жаловался один из кассиров — выскакивает непонятная блокирующая ошибка, когда кассир пытается провести типичную валютно-обменную операцию. Повторяется стабильно, мешает.
Проверяем мы у себя, внутри ИТ — не воспроизводится, нормально всё работает. Попробовали повторить несколько человек. Не повторяется. Уже и права настроили как у пользователя — не помогло. И всё по шагам прошли 100500 раз, но никак не можем выйти на ошибку, всё работает. А у кассира не работает.
В итоге позвали кассира к себе, встали впятером у неё за спиной и стали смотреть за последовательностью её действий. И на наших глазах у неё ошибка воспроизводится! Сразу.
С первой попытки.
Не поняли. Повторили. И ещё.
А суть была в следующем: оказалось, что каждый раз она входила в лукап валюты, чтобы выбрать из списка рубли. В этом и была засада. Мы же этого не делали, зачем каждый раз проваливаться и что-то выбирать, когда мы знаем, что рубли это 810. Мы просто сразу привычно набирали 810, Tab и шли дальше.
В общем, иногда лучший тестировщик — пользователь.
Качество программного обеспечения (ПО) напрямую зависит от многих факторов: от требований и спецификаций, проектирования и архитектуры, процессов разработки и тестирования ПО. Естественно, в процессе тестирования часто возникают проблемы и «узкие горлышки», которые могут существенно затруднить успешное завершение проекта.
Специалист по тестированию “Лаборатории качества” Александр Черняков написал об основных проблемах, с которыми сталкиваются команды специалистов по тестированию, и рассмотрел возможные пути их решения. Все актуально.
Code review решает такие проблемы частично, всегда присутствует человеческий фактор, и раз за разом подобные проблемы проходят через проверки. Но решение есть — это концепция Code Ownership, которую мы применили в нашем проекте.
Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.
В этой статье я поделюсь алгоритмом, который я использовала в собственной практике, как тимлиду выбраться из рутины и сделать команду автономной.
Про сбор требований написано очень много, но в этой статье я хочу сосредоточиться на нескольких важных аспектах проведения встречи по сбору требований. Есть несколько моментов, которые не являются первостепенными, но которые существенно повышают успех встречи.
Чем больше в компании продуктов, команд и процессов, тем острее становится потребность в развитой культуре лидерства. Речь не только о тонкостях управления, но и об организации слаженного взаимодействия: на уровне разработчиков, между командами, с бизнесом.
Когда каждая команда отвечает за конкретный продукт, её участникам важно видеть технологическую картину в целом; четко осознавать в ней свою роль, понимать принципы межкомандных коммуникаций и другие процессы в масштабах компании. Именно здесь роль тех- и тимлидов становится ключевой.
В Сравни мы уже три года проводим встречи лидов. Мероприятия помогают руководителям ИТ-команд фиксировать общий контекст, совместно формировать удобный для всех план действий. И параллельно решать более локальные проблемы — например, связанные с внедрением новых инструментов в командах.
За это время мы подобрали оптимальный для нас формат встреч, а недавний июльский ивент, восьмой по счету, помог закрепить удачные аспекты прошлых LeadHub.
Под катом на примере LeadHub #8 рассказываем, как устроены встречи тимлидов, и какой эффект дают на разных дистанциях. С примерами прорабатываемых на встречах проблем и практическими советами по организации подобных ивентов.
Всем доброе утро!
На связи вновь Крылов Александр и сегодня я решил поделиться мыслями по тому, как можно применить опыт DevOps Governance в Enterprice, который я ранее описывал в в этой статье. Прошло время и опыт был переиспользован для разработки продукта на примере компании Bimeister. А началось это аж в августе 2023 года.
Что тут важно сказать - нет, это не будет детальной расшифровкой с уточнениями доклада с DevOops 2023, с которым так же можно будет ознакомиться по ссылке выше. В данной статье я расскажу ряд аспектов отличия Governance в Enterprice и то, как он может выглядеть в компании разработчике своего продукта. Помимо этого, я так же расскажу, какие работы удалось провести за год в компании, а какие нет.
Привет, Хабр!
Как Frontend-разработчик, я в одной из своих прошлых работ столкнулся с проблемой неэффективной постановки задач в моей команде. Это привело к потере времени, недопониманию и снижению качества работы. Например, однажды мы потратили целую неделю на разработку функциональности, которая в итоге оказалась не той, что ожидал заказчик из-за неполного описания требований. В другой раз из-за отсутствия четких критериев приемки мы трижды возвращались к доработке уже "готовой" задачи.
В этой статье я поделюсь результатами своего исследования и практическими рекомендациями по улучшению процесса постановки и ведения задач, которые мы теперь применяем в работе.
Шаблоны и примеры задач будут в конце статьи.
