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

Простая идея для канбан-доски, которая делает работу прозрачней

Пересказываем большую статью в маленьком посте.

Недавно мы заметили, что некоторые задачи на наших канбан-досках застревают на приемке у заказчиков. Например, задачу с нуля мы делаем 10 дней, а потом в колонке Client Acceptance она может лежать еще 20–30. Ситуация повторялась на разных проектах и явно была общей.

Мы быстро поняли, в чем дело. На стадии Client Acceptance команда получала замечания от заказчики. И пока они вносились, задача оставалась в этом же столбце. По правилам Канбан, двигать ее назад нельзя. Хотя, по сути, всё это время она проходила тот же путь, что и до этого — через To do, In progress и Validation.

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

Чтобы вывести задачи из слепой зоны, мы визуализировали процесс работы над замечаниями. Для этого добавили дополнительные свимлайны. Каждый из них повторял основной воркфлоу. Теперь задача возвращалась в To do, но в другом свимлайне.

Благодаря этому решению мы:

• упростили и оптимизировали работу;

• начали лучше контролировать работу отделов;

• сделали работу прозрачной для заказчика.

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

Интересная статья на английском языке:
"First decide how to decide: “one weird trick” for easier decisions"
https://jacobian.org/2023/dec/5/how-to-decide/

Статья про формальный процесс принятия решений, основанная на опыте работы в Heroku на проекте Dogwood (Heroku Enterprise).

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

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

Источник новости: полезняшки от Разбора Полетов

Выгорание - это всего лишь отсутствие цели в работе.

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

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

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

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

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

В этот момент вместо Труса, Балбеса и Бывалого у вас появится инициативная команда.

1. Платите им

2. Корректируйте их

3. Покажите им как они влияют на ваш бизнес в котором они учавствуют

PI-планирование, или Почему нам стало легче дышать

Один из наших заказчиков — известный бренд, который развивают Ecom-направление. Мы работаем с ними уже пять лет, но начиналось всё так себе. Первое время мы не могли найти общий язык, спорили из-за мелочей. Всё как в басне «Лебедь, рак и щука».

Но затем нашли лекарство — PI-планирование. Рассказываем, как его проводим мы.

PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров. Она помогает держать фокус на общей цели и синхронизировать действия нескольких команд сразу.

PI-планирование идет от бэклога. То есть на встрече мы не пополняем доску задачами, а все вместе распределяем их по двухнедельным таймбоксам. У нас встречи проходят онлайн.

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

В итоге мы стали понимать KPI стейкхолдеров и глобальные задачи бизнеса. Вот главные плюсы PI:

1. Мы обеспечиваем команде равномерную нагрузку.

2. Мы делим ответственность за проект с заказчиком.

3. Мы лучше распределяем ресурсы.

PI-планирование точно стоит внедрить тем,

✔️ кто строит команду на аутсорсе;

✔️ у кого над продуктом работает несколько команд.

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

Что мы делаем, когда задача приходит на разработку без планирования

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

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

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

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

Если коротко, то выбираем решение с еmail-рассылкой, потому что многие пользуются VPN и по IP мы ничего выяснить не можем. Бэк генерирует уникальную ссылку и промокод, получить его можно кликнув по своему городу в письме.

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

Рассылаем акцию в понедельник, а в во вторник собираем статистику. Вот как это выглядит на схеме:

Теперь вы расскажите, как вы проводите срочные задачи. Больше про управление проектами — в нашем телеграм-канале.

После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.43.

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

По сравнению с прошлым выпуском в версию Git 2.43 внесено и принято 464 изменения, подготовленные при участии 80 разработчиков, из которых 17 программистов впервые приняли участие в разработке, включая:

• в команду "git repack" добавлены опции "--filter" и "--filter-to", позволяющие выполнить переупаковку репозитория c учётом заданного фильтра объектов и при необходимости перенести в отдельное место объекты, не удовлетворяющие заданному фильтру;

• добавлена возможность работы с несколькими pack-файлами с информацией о недостижимых объектах ("cruft packs"), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги);

• добавлено распознавание попыток выполнения двойной отмены коммита через "git revert" и учёт этого факта при формировании сообщения об отмене;

• Разрешено совместное использование опций "--rfc" и "--subject-prefix".

Источник: OpenNET.

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_8

?Вопрос_8: Какие алгориммы поиска аномалий в данных существуют и чем они отличаются ?

✔️Ответ:

• DBSCAN (Density-Based Spatial Clustering of Applications with Noise) - алгоритм кластеризации данных, который основывается на плотностной информации о расположении объектов. Он определяет кластеры как плотные области в пространстве признаков, разделенные областями разреженности;

• LOF (Local Outlier Factor): LOF также использует информацию о плотности для обнаружения аномалий. Он вычисляет локальный коэффициент выброса для каждого объекта, основываясь на плотности окрестности данного объекта по сравнению с плотностью окрестности его соседей. Значения LOF выше единицы указывают на аномальные объекты;

• Isolation Forest использует случайные деревья для изоляции аномалий. Он строит ансамбль изолирующих деревьев, разделяя объекты по случайным разделениям до тех пор, пока каждый объект не будет изолирован в отдельном листе. Аномалии обычно требуют меньшего числа разделений для изоляции, и поэтому имеют более короткий путь в дереве;

• One-Class SVM (Support Vector Machines): One-Class SVM - алгоритм, который строит модель только для "нормальных" данных. Он пытается найти гиперплоскость, которая наилучшим образом разделяет нормальные данные от выбросов в пространстве признаков. Объекты, находящиеся далеко от этой гиперплоскости, считаются аномалиями.

  https://t.me/DenoiseLAB

Как работать со старожилами компании, которые стали неэффективными. Инструкция для тимлидов

Если компания на рынке хотя бы 10–15 лет, в ней точно есть сотрудники-старожилы. Когда-то они решали нерешаемые задачи и были незаменимы. Но технологии и процессы шагнули вперед, а они нет. Ниже советы, как вернуть их в строй.

1. Разговаривать.

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

2. Учить новому.

Когда человек годами на одном проекте, он забывает, как работать над другими. Оцените его остаточные знания. Может, просто отправить его на курсы?

3. Строить план развития.

Можно внести в KPI, какие технологии ему освоить. Причем новые знания нужно применять на практике. Поэтому подкидывайте ему интересные задачи, тренинги.

4. Мотивировать.

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

5. Следить и поддерживать.

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

6. Принимать решения.

Если все усилия не помогли, придется задуматься о расставании. Не все готовы меняться, это нормально. Помнить об этом варианте нужно с самого начала.

Если хотите узнать больше о работе тимлида — подписывайтесь на телеграм-канал.

Организация GNOME Foundation, курирующая разработку пользовательского окружения GNOME, объявила о назначении Холли Миллион (Holly Million) на пост исполнительного директора, который оставался с вакантным с августа прошлого года после ухода Нила МакГоверна (Neil McGovern). Исполнительный директор отвечает за управление и развитие GNOME Foundation как организацией, а также за взаимодействие с советом директоров, консультативным советом (Advisory Board) и членами организации.

Холли Миллион имеет обширный опыт управления некоммерческими организациями и является разносторонней и увлечённой личностью, проявившей себя в роли продюсера документальных фильмов, писателя, художника и педагога. Миллион прошла путь от консультанта в некоммерческой организации до директора по разработке, члена совета директоров различных организаций, исполнительного директора организации BioBricks Foundation, развивающие открытые проекты в области биотехнологий, и основателя организации Artists United, объединяющий художников и ценителей искусства, и продвигающей идею, что через обучение понимания искусства можно решить многие социальные проблемы.

Источник: OpenNET.

Вышел новый стабильный выпуск системы управления проектами Trac 1.6 с поддержкой Python 3, предоставляющей web-интерфейс для работы с репозиториями Subversion и ​Git, встроенный Wiki, систему отслеживания ошибок и раздел планирования функциональности для новых версий. Код написан на языке Python и распространяется под лицензией BSD. Для хранения данных могут применяться СУБД SQLite, ​PostgreSQL и ​MySQL/MariaDB.

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

В форме плагинов доступны модули для ведения новостных лент, создания дискуссионной площадки, проведения опросов, взаимодействия с различными системами непрерывной интеграции, генерации документации в Doxygen, управления загрузками, отправки уведомлений через ​Slack, поддержки Subversion и Mercurial.

Источник: OpenNET.

⚽️ Обыденная история: некогда бедный парнишка выросший в бразильских фавелах играет за неплохой клуб из топовой европейской лиги. Неплохой, но не сильнейший: вроде всегда на виду, сильно не позорится, иногда даёт отпор чемпионам, но при этом не берёт никаких титулов, да и вообще не особо на что-то претендует. 

? Болельщики команды боготворят юношу, страна живёт футболом, соперники сильные, играть интересно. Зарплата правда не самая высокая — клуб не из богатых, сильно тратиться не может.

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

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

⚡️ И вдруг — о, озарение! — наш герой понимает, что не только большая зарплата мотивирует его творить чудеса на поле. Есть что-то ещё. В его случае — признание ультрас, журналистов; титулы, награды и трофеи; критика, стремление доказывать и голод до побед. Кажется, летом придётся паковать вещи и ехать обратно в Европу, но будет ли теперь достойное предложение? Хороший вопрос. 

А как это у вас?

? ВНУТРЕННИЙ МИР. КОРМИТЬ ПО РАСПИСАНИЮ!

? Если Вы всё же считаете, что сотрудников мотивируют не только деньги, то поздравляю: тут мы сходимся во мнении.

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

? Хотите ещё пример? Это можно. Теперь реалистичный и не вычурный, обещаю. Но в следующем посте. Сюда не влезает)

? ЛЮДЕЙ МОТИВИРУЮТ ТОЛЬКО ДЕНЬГИ

? Или нет? Давайте разбираться.

? Вот Вам пример в качестве пищи для размышлений. ? Сразу извиняюсь: немного вычурный, уровень реализма — 2 из 10. Зато очень наглядно.

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

? Но у босса условие: деньги — только наличкой, и курьер кидает их на дно мусорного бака перед Вашим домом. 

⁉️ Как поступите в такой ситуации? Устроитесь куда-то в более адекватную фирму на оклад поскромнее или «чёрт с ним — деньги не пахнут»? 

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

Сегодня я хочу поговорить о мифах, которые существуют вокруг роли TeamLead'а. Эти мифы могут создать ложные ожидания и привести к разочарованию. Давайте разберем несколько из них:

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

Миф 2: TeamLead должен решать все проблемы команды.
TeamLead - не сверхчеловек. Они не могут решить все проблемы команды. Однако, они должны уметь координировать работу команды и находить решения вместе с членами команды.

Миф 3: TeamLead должен работать более долгие часы, чем остальные члены команды.
TeamLead должен быть примером для своей команды. Но это не означает, что они должны работать больше других. Если команда работает 8 часов в день, то и TeamLead должен работать столько же. Если TeamLead работает больше, это может привести к выгоранию и недовольству.

Миф 4: TeamLead должен быть экспертом во всех областях.
TeamLead не обязан знать все технологии и языки программирования. Однако, они должны понимать основы и уметь общаться с каждым членом команды. Хороший TeamLead будет обучаться и узнавать новые вещи вместе с командой.

Надеюсь, что эти объяснения помогут снять некоторые мифы вокруг роли TeamLead'а. Если у вас есть что добавить, оставляйте комментарии ниже!