"Не вредные советы для РП". Как подготовиться к встрече с Волан-де-Мортом и защититься от Дементоров в проекте. Часть 1.
Это анти-статья для тех, кто сталкивался с "граблями" и двойными стандартами в управлении проектов и для тех, кто хочет об этом узнать. Получить подсказки как застраховаться от "скрытых граблей" и ловушках в темном лесу Волан-де-Морта до того, как войти в него, а также подготовиться к схватке с проектными Дементорами и суметь себя защитить.
Сегодняшняя статья не входит в цикл по организации команд разработки, а является неким изложением мыслей тимлида. А запустил поток этих самых мыслей один из комментариев к предыдущей статье, который в общих чертах обрисовывал, что созвоны это трата времени, и не более. Обсудим?
Ошибки бывают не всегда очевидны. Вот один из случаев, который у нас произошёл при попытке отловить ошибку. На неё долго жаловался один из кассиров — выскакивает непонятная блокирующая ошибка, когда кассир пытается провести типичную валютно-обменную операцию. Повторяется стабильно, мешает.
Проверяем мы у себя, внутри ИТ — не воспроизводится, нормально всё работает. Попробовали повторить несколько человек. Не повторяется. Уже и права настроили как у пользователя — не помогло. И всё по шагам прошли 100500 раз, но никак не можем выйти на ошибку, всё работает. А у кассира не работает.
В итоге позвали кассира к себе, встали впятером у неё за спиной и стали смотреть за последовательностью её действий. И на наших глазах у неё ошибка воспроизводится! Сразу.
С первой попытки.
Не поняли. Повторили. И ещё.
А суть была в следующем: оказалось, что каждый раз она входила в лукап валюты, чтобы выбрать из списка рубли. В этом и была засада. Мы же этого не делали, зачем каждый раз проваливаться и что-то выбирать, когда мы знаем, что рубли это 810. Мы просто сразу привычно набирали 810, Tab и шли дальше.
В общем, иногда лучший тестировщик — пользователь.
Качество программного обеспечения (ПО) напрямую зависит от многих факторов: от требований и спецификаций, проектирования и архитектуры, процессов разработки и тестирования ПО. Естественно, в процессе тестирования часто возникают проблемы и «узкие горлышки», которые могут существенно затруднить успешное завершение проекта.
Специалист по тестированию “Лаборатории качества” Александр Черняков написал об основных проблемах, с которыми сталкиваются команды специалистов по тестированию, и рассмотрел возможные пути их решения. Все актуально.
Code review решает такие проблемы частично, всегда присутствует человеческий фактор, и раз за разом подобные проблемы проходят через проверки. Но решение есть — это концепция Code Ownership, которую мы применили в нашем проекте.
Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.
В этой статье я поделюсь алгоритмом, который я использовала в собственной практике, как тимлиду выбраться из рутины и сделать команду автономной.
Про сбор требований написано очень много, но в этой статье я хочу сосредоточиться на нескольких важных аспектах проведения встречи по сбору требований. Есть несколько моментов, которые не являются первостепенными, но которые существенно повышают успех встречи.
Чем больше в компании продуктов, команд и процессов, тем острее становится потребность в развитой культуре лидерства. Речь не только о тонкостях управления, но и об организации слаженного взаимодействия: на уровне разработчиков, между командами, с бизнесом.
Когда каждая команда отвечает за конкретный продукт, её участникам важно видеть технологическую картину в целом; четко осознавать в ней свою роль, понимать принципы межкомандных коммуникаций и другие процессы в масштабах компании. Именно здесь роль тех- и тимлидов становится ключевой.
В Сравни мы уже три года проводим встречи лидов. Мероприятия помогают руководителям ИТ-команд фиксировать общий контекст, совместно формировать удобный для всех план действий. И параллельно решать более локальные проблемы — например, связанные с внедрением новых инструментов в командах.
За это время мы подобрали оптимальный для нас формат встреч, а недавний июльский ивент, восьмой по счету, помог закрепить удачные аспекты прошлых LeadHub.
Под катом на примере LeadHub #8 рассказываем, как устроены встречи тимлидов, и какой эффект дают на разных дистанциях. С примерами прорабатываемых на встречах проблем и практическими советами по организации подобных ивентов.
Всем доброе утро!
На связи вновь Крылов Александр и сегодня я решил поделиться мыслями по тому, как можно применить опыт DevOps Governance в Enterprice, который я ранее описывал в в этой статье. Прошло время и опыт был переиспользован для разработки продукта на примере компании Bimeister. А началось это аж в августе 2023 года.
Что тут важно сказать - нет, это не будет детальной расшифровкой с уточнениями доклада с DevOops 2023, с которым так же можно будет ознакомиться по ссылке выше. В данной статье я расскажу ряд аспектов отличия Governance в Enterprice и то, как он может выглядеть в компании разработчике своего продукта. Помимо этого, я так же расскажу, какие работы удалось провести за год в компании, а какие нет.
Привет, Хабр!
Как Frontend-разработчик, я в одной из своих прошлых работ столкнулся с проблемой неэффективной постановки задач в моей команде. Это привело к потере времени, недопониманию и снижению качества работы. Например, однажды мы потратили целую неделю на разработку функциональности, которая в итоге оказалась не той, что ожидал заказчик из-за неполного описания требований. В другой раз из-за отсутствия четких критериев приемки мы трижды возвращались к доработке уже "готовой" задачи.
В этой статье я поделюсь результатами своего исследования и практическими рекомендациями по улучшению процесса постановки и ведения задач, которые мы теперь применяем в работе.
Шаблоны и примеры задач будут в конце статьи.
Начнем с того, что тема команды в целом, довольно сложный и многогранный вопрос, Который требует развития разных граней человека каждого члена команды, и в особенности, её лидера. От Эмоционального интеллекта и эмпатичности, до самокритики и самообладания.
Но современная культура корпоративного обучения и управления начала использовать это явление (команды), исключительно для манипуляций людьми.
«Мы же команда» заявляет ктоугодновышестоящий с целью вовлечь вас в решение задач компании, без уточнения, а нужно ли вам это, вообще. Особенно если задачи и начинания, о которых говорят, выходят за рамки должностных обязанностей.
Так вот ответственно заявляю, – нифига мы не команда, пока мы её не построили. Кто этим должен заниматься, и как? Этим должен заниматься руководитель, он же, по совместительству, лидер команды. Как конкретно этим заниматься, это тема для отдельной статьи, сегодня расскажем некоторые инструменты которые можно использовать и внедрять в рабочие процессы и правила команды, чтобы начать повышать эффективность коммуникации, и очерчивать границы командной работы.
Много раз сталкивался с жалобами команд разработки на огромное количество онлайн-встреч, совещаний и созвонов в течении рабочего дня. Иногда аналитик, показывая календарь, полностью забитый разного рода подобными активностями, страдающим голосом вопрошал – а работать-то когда? Сегодня попробуем определиться, откуда берутся все эти созвоны, сколько времени на них планировать, и как уменьшить их количество. Поехали.
Чтобы нанять хорошего инженера, недостаточно проверить только его харды. В статье я расскажу о трех софт-скиллах, которые я обязательно проверяю у каждого кандидата. Если вы начнете проверять эти три навыка, вы начнете нанимать лучших специалистов. А еще я расскажу обратную, темную сторону каждого из качеств.
Меня зовут Олег Федоткин, я программист и менеджер в ИТ. Я провел более сотни собеседований (мне HR даже толстовку «Hiring Hero» по такому случаю подарили) и нанял десятки человек: программистов, тим лидов, юнит лидов, архитекторов — да всех. После всех интервью я выделил три качества, которые неизменно определяют классного специалиста.
Привет! Меня зовут Сергей Реусин и последние пять лет я занимаюсь эксплуатацией production-систем с непрерывной практикой инцидент-менеджмента. Каждый день, сталкиваясь с аномалиями и проблемами, невольно спрашиваешь себя: «Почему это происходит? А главное — как с этим дальше жить?». Три нелегких года работы в Купере ( ex СберМаркет), где мне доверили строить культуру инцидент-менеджмента, помогли мне утвердиться во мнении и подходах, которые действительно помогают справляться с подобными вызовами. О них и поговорим!
Чтобы сложить цельную картину о создании устойчивых систем и организации, мы пройдем по шагам:
1. Определим, ради чего вся эта «доступность» и «стабильность» нужна
2. Попробуем устаканить терминологию, чтобы говорить на одном языке
3. Посмотрим на понятие системы с позиции устойчивости
4. Обратимся к историческому опыту
5. Изучим возможные паттерны отказов систем и способы их митигации
6. Визуализируем модель восприятия аномалий
7. Познакомимся с ключевыми личностями в подходах Resilience Engineering
Привет! В последнее время на Хабре выходит много статей про найм глазами потенциального сотрудника. В них содержится много критики в адрес этого процесса, а также в адрес исполнителей в лице HR. Такая критика часто вполне заслуженна. Также иногда выходят статьи о найме глазами HR: в таких текстах углы сглаживаются, а рекомендации даются в самом общем виде. Но есть ещё и третья сторона процесса найма: нанимающие менеджеры, которым нужно обеспечить свои команды сотрудниками.
Последние два года я работаю тимлидом в быстро развивающемся проекте, и через мою команду прошло уже достаточно много народу (не соврать, более 2 десятков). Часть из них мы брали у наших коллег из аутстафф-компаний, а часть нанимали сами. В этой небольшой статье я попробую объяснить, чем руководствуюсь при просмотре резюме и на собеседовании. Соискателям программистам, тестировщикам, девопсам, админам может быть интересно почитать, если они хотят работать в относительно небольшой российской компании. Наш процесс найма бесконечно далёк от FAANG- и Яндекс-мытарств, нам лишь нужно завлечь себе человека с определёнными качествами за минимально короткое время.
О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.Когда я начинал программировать в детстве, я не знал, что людям платят за программирование. Даже когда я закончил среднюю школу, я полагал, что мир «профессиональной разработки» выглядит совсем иначе, чем код, который я писал в свободное время. Когда мне посчастливилось устроиться на свою первую работу в сфере программного обеспечения, я быстро понял, насколько я ошибался и насколько был прав. Моя первая работа была испытанием огнем, и по сей день та кодовая база остается худшей и лучшей кодовой базой, в которой мне довелось работать. Хотя кодовая база навсегда останется запертой в проприетарных стенах той конкретной компании, я надеюсь, что смогу поделиться с вами некоторыми самыми забавными и страшными историями из нее.
Приветствую всех! Цель данной статьи - рассказать реальные проблемы с которыми сталкивается команда при создании нового продукта и её лидер в большом финтехе и да, не просто с чьих то слов, а прочувствовав всё на собственной шкуре. В прошлом году я взял достаточно большой и серьезный проект, который вывел до прода.
Привет, Хабр! На связи C#-разработчик компании SimbirSoft Георгий. В этой статье поговорим о том, как с помощью комментариев кода можно ускорить погружение новых разработчиков в проект, упростить написание документации и найти общий язык с коллегами-разработчиками.
Материал будет интересен как начинающим IT-специалистам, кто только учится писать чистый и красивый код, так и тем, кто отвечает за формирование кодстайла проектов. Подкреплять свои рассуждения буду примерами из личного опыта и опыта коллег. Сначала быстро пройдемся по основам, а потом откроем этот ящик Пандоры и уйдем в рассуждения.
Как вы отнесетесь, если я скажу, что в идеальной команде могут быть провокаторы, манипуляторы, токсичные, нервные, нерешительные, жесткие, нервозные и неконкретные люди?
Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.
Определение 1. Корпоративная информационная система (КИС) – это расширяемая информационная система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний, а также корпораций, требующих единого управления [2].
К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.
