Рубрика «управление разработкой» - 48

Я уже пытался лечить «механический» scrum (часть 1, часть 2, часть 3), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот, вот, вот или вот.

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.
Прозрачность — панацея от баттхёртов - 1
Читать полностью »

Некоторое время назад между мной и моим хорошим другом состоялся разговор, в котором прозвучали такие фразы:

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

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

Всем привет! Меня зовут Егор, я руковожу кластером App Platform в Авито. Мои команды в основном занимаются разработкой внутренних продуктов, инструментов и процессов — тем, что принято называть платформенной разработкой.

Год назад я рассказывал в этом блоге, как мы внедрили и используем performance review. Тогда я упоминал, что мы смотрим на него как на индикатор пользы, которую приносит компании каждый отдельный человек. Понимать это важно и полезно. Это помогает ответить на вопрос «насколько Вася молодец по сравнению с Петей?» и определить, какую премию кому выплатить. Но когда мы переходим на уровень команд, всё становится сильно интереснее. Здесь важно оценить конкретный результат команды и его влияние на успех компании. Высокое среднее значение перфоманса всех членов команды совсем необязательно значит, что команда достигла крутых результатов. Какая-то корреляция точно присутствует, но для оценки фактического вклада команды в успех компании этот инструмент использовать нельзя.

Для решения этой и ряда других проблем мы в Авито используем метод OKR — Objectives and Key Results. Он позволяет установить дерево понятных и легко измеримых целей во всей компании, связать результаты различных команд друг с другом и добиться достижения желаемых результатов.

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

Objectives and Key Results: инструкция по применению - 1

Читать полностью »

Гнев на код: программисты и негатив - 1

Я смотрю на кусок кода. Возможно, это худший код, что мне когда-либо встречался. Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже те, которые обновлять не требуется. Тут есть map-функция, которая просто возвращает переданное ей значение. Есть условные проверки переменных с очевидно одинаковым значением, просто поименованных в разных стилях (firstName and first_name). Для каждого UPDATE’а код отправляет сообщение в другую очередь, которая обрабатывается другой serverless-функцией, но которая выполняет всю работу для другой коллекции в той же базе данных. Я не упомянул, что эта serverless-функция из облачной «сервис-ориентированной архитектуры», содержащей более 100 функций в окружении?

Как вообще можно было такое сделать? Я закрываю лицо и явственно всхлипываю сквозь смех. Мои коллеги спрашивают, что случилось, и я в красках пересказываю Worst Hits Of BulkDataImporter.js 2018. Все сочувственно кивают мне и соглашаются: как они могли так с нами поступить?
Читать полностью »

Примечание: Если вы считаете, что на построении архитектуры съели хотя бы полпёсика, то эта статья не для вас.

Модель — абстрактное представление реальности в какой-либо форме.

Предполагаем, что архитектор уже закончил со сбором требований к будущей системе и их анализом.

Разработку архитектуры нужно начинать только с понятия и принятия фундаментальной концепции работы с информацией (данными): передача, хранение и обработка. Притом формы ввода/выводы информации, схемы обработки, абстрактные структуры массивов и элементов данных сами по себе тоже являются информацией (как и всё приложение) и подчиняются той же фундаментальной концепции.Читать полностью »

Добрый день. Делимся с вами второй частью статьи о рекрутинге разработчиков ПО, которая приурочена к запуску курса «IT-Recruiter». Первую часть можно прочитать тут.

Опыт кандидата при рекрутинге разработчиков программного обеспечения. Часть 2 - 1

Уведомление привлекательно

Итак, вы сходили на свое первое свидание, а потом… ничего. Вы звоните на следующий день, чтобы сказать, что вам было весело? Вы ждете три дня? Стоит ли вам беспокоиться, если с вами не хотят связываться? Все задают эти вопросы, когда они встречаются, и никто не любит их. Намного лучше узнать точно, хочет ли другой человек увидеться снова.Читать полностью »

В современном мире продукты выпускаются все быстрее, а люди задерживаются в компании в среднем всего на пару лет. О том, как эти факторы влияют на участие сотрудников в процессе обмена знаниями, мы поговорили с одним из ключевых спикеров KnowledgeConf Алексеем Сидориным, руководителем направления «Управление знаниями и корпоративными коммуникациями» в КРОК.

Сидорин: KnowledgeConf — это про то, как сохранить знания при средней продолжительности работы на одном месте в 2-3 года - 1
Читать полностью »

Привет!

Меня зовут Даша Русланова, я директор Департамента цифровых решений в Альфа-Банке. Сегодня я расскажу вам, как мы живем во время довольно значимых изменений, каких результатов в процессе этого переформатирования смогли достигнуть за год в плане скорости, и зачем нам solution-архитекторы.

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

Чтобы нарастить скорость, нам потребовалось не только перестроить процессы, связанные с наймом сотрудников и работой с вендорами, но и привнести существенные инновации в уже имеющиеся процессы: поточную технологию релизов, так называемый release train – еженедельный максимально автоматизированный процесс поставки ценностей в мобильное приложение. На данный момент над ним трудится более 20 команд. В начале каждой недели автоматически собирается релиз-кандидат и запускается релизный pipeline.

К чему мы стремились прийти: автоматизировать сборку приложений и составление описания изменений — соединить «тикеты» изменений, сделанных разработчиком в Git, и описание user story с командной доски в jira, а также к полной прозрачности для клиентов и стейкхолдеров. В дальнейших планах сделать все стадии, кроме ручного приемочного тестирования, автоматическими, чтобы релизный цикл стал меньше недели.
Читать полностью »

Недавно я рассказала о докладах, которые сформировали программу конференции про управление знаниями в IT компаниях KnowledgeConf. Но не докладами едиными, все таки самое важное на конференции — это общение экспертов, дискуссии, столкновение мнений, на стыке которых возникает что-то новое, интересное и прорывное. Поэтому параллельно в программе у нас будет четыре двухчасовых интерактивных формата — два круглых стола и два мастер-класса.

Строим модели, «продаем» управление знаниями руководству и исправляем ошибку выжившего - 1

Читать полностью »

Всем привет!

Как и обещал, продолжаю публикации о менеджменте в IT. В предыдущей статье я рассказал, что значит быть Team Leader. Но какой же тим лид без команды? Сегодня же о том, как можно набирать классных людей, не имея больших ресурсов, и когда о вас никто не знает.

image
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js