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

Как он мимо анализа пройти не смог...

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

В компании «Арбис» используется стек, который давно оброс стереотипами и предрассудками — это 1С:Платформа. Более того, у большинства 1С прочно связана с бухгалтерией. И, хотя в Арбис программный продукт вообще с ней не связан — это облачное решение, сервис на 1000 пользователей — опытных спецов по 1С для него просто нет. 

И в довершение, компания базируется в Архангельске, где есть утечка кадров в большие города и нет рынок вакансий в принципе небольшой. Даже хуже. Процветает хантинг сотрудников, потому что Абрис — единственная компания, которая воспитывает и учит специалистов по 1С.

Где искать людей? Компания сделала ставку на джунов. Об этом на конференции TeamLead Conf 2021 рассказала Маргарита Маковеева, которая каждого сотрудника в своем отделе выращивала с нуля. И сегодня мы опишем подробности ее решения. Видео ее выступления можно посмотреть здесь.

В данном посте мне хотелось бы поделиться списком книг, которые (по крайне субъективному мнению) являются полезными и весьма практичными для Engineering Manager’а. При этом акцент хочу сделать именно на современных книгах (выпущенных в последние 5-6 лет). Под Engineering Manager’ом, в моем вольном определении, будем понимать бывшего инженера, ставшего руководителем, решающего как технические (например, внедряем RabbitMQ или Kafka), так и административные вопросы (например, план обучения новичков, сколько еще нанять разработчиков и каких и т.п.). Под такое понятие могут подпадать Tech Lead, Team Lead, Project Manager.

• цель грума,
• необходимый минимум,
• уточнение требований и контекста,
• типичные этапы,
• особенности при доработке механик.

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

Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками - системы трекинга времени, средства трансляции рабочего стола?

А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться. 

Под катом рассказываем, как это у нас работает уже более 5 лет.

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

Привет, Хабр! Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент (environment) — это основная рабочая площадка тестировщика. Если у программиста — это любимая IDE, то у тестировщика — милый и родной энвайронмент.

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

Мы продолжаем делиться внутренними документами Авито. Сегодня это будет модель зрелости. Она может пригодиться как трекер внедрения инженерных практик всем компаниям, где есть своя разработка. Чётко прописанная модель зрелости помогает быстро синхронизироваться и находить зоны роста команд.

Привет!

Меня зовут Тимофей, и я продуктовый разработчик. О продуктовой разработке подробнее можно почитать тут. 

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

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

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

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

Всем привет! Несколько дней назад мы поговорили с Олегом Мельником о том, кто такой техлид. Прочитать интервью можно тут.

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

Мы продолжаем цикл публикаций о недостатках Аgile методологии. Сегодня перевод статьи о том, почему инженеры презирают Agile (много новых удивительных наблюдений!)

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

Эта статья подходит для тимлидов и их подопечных, а также для всех, кто оценивает проекты и задачи. Я расскажу, как и почему мы делаем ошибки из-за когнитивных искажений. Попадаем в них мы почти все, просто потому что мы живые люди. И на примере одного дня из жизни тимлида я хочу показать, в какие искажения чаще всего влетают в IT, и  — самое полезное  —  как из них можно выходить.

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

Если вам приходилось задумываться о построении эффективной экосистемы проекта и определении ролей тимлида и разработчика — статья Артема Прозорова из ZeBrains для вас.

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

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

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

Команда №2: Один сильный разработчик. Ему помогают множество не знакомых между собой людей из разных часовых поясов. У каждого — свой набор компетенций и уровень опыта. Работой над проектом участники занимаются в свободном режиме, по несколько часов в неделю.

* * *

Ответ на этот вопрос получим к концу статьи.

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

Привет, меня зовут Оля, я Head of Processes&Practices, занимаюсь продуктовой трансформацией в inDriver. Сейчас у нас активная продуктовая и инженерная культура, система OKR, масштабное продуктовое планирование и смелые планы на будущее. Но так было не всегда. И в этой статье я расскажу о тех вызовах, с которыми мы столкнулись в процессе трансформации и о том, чего уже удалось достичь.

Всем привет. Меня зовут Даша Викторова, я Project Lead направления Outbound, которое отвечает за автоматизацию доставки в Lamoda. Сегодня поговорим про проектный менеджмент… Но не совсем :) 

Как правило, проект-менеджер (или просто PM) отвечает за реализацию проектов — как ни странно! Однако любой проект состоит не только из задач, которые ведут к достижению конечной цели, но и из процессов, от которых зависит качество и скорость их достижения.

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

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

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