Рубрика «команда» - 2

В любом малом бизнесе есть процесс перешагивания из малого в средний или крупный. Ну или уютная самозанятость для предпенсионера. Например, для малого бизнеса достаточно 1–2–3–4, может, в край, 5 разработчиков. Эти люди могут взять отдельные направления и работать крайне эффективно. Как только их становится больше, начинают появляться внутренние коммуникативные издержки. То есть вклад следующего будет уже не 1/N, а размытым.

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

Я сейчас очень упрощаю, конечно, но почувствовать бюрократию вы можете довольно легко и на других объёмах.

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

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

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

"Мир не такой, каким он кажется.."

"Мир не такой, каким он кажется.."

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

Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработки. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.

Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon ProfitЧитать полностью »

В последнее время всё чаще можно услышать об ужесточении чего-либо, в любой из сфер жизни. Так определяет "милосердие" Глеб Жеглов в фильме Говорухина "Место встречи изменить нельзя"</p><p></p>" data-abbr="Поповское слово">Поповское словоЧитать полностью »

В этом году спортивный фестиваль для IT-специалистов RUNIT пройдет 18 июня в Измайловском парке. Мы приглашаем тех, кто развивает IT и Digital, присоединиться к нам. Участие в забеге примут сотрудники крупнейших IT-компаний России: разработчики, тестировщики, DevOps-специалисты, продакт- и проджект-менеджеры, маркетологи.

Читать полностью »
FeatureWeek: как мы повысили вовлеченность команды и заполнили бэклог - 1

Привет! Я Саша Пургина, руководитель отдела развития data-продуктов в Lamoda. В этой статье хочу рассказать, как мы использовали экспертизу разных команд для генерации 200+ новых гипотез и сплотили весь отдел вокруг решения пользовательских проблем.

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

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

Что будет, если от разработчиков не отстать: умирающая команда - 1
Источник

15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.

Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».

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

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

Как вообще можно управлять отдельными людьми в команде разработки? - 1

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

Управлять можно, например:

  • Балансом между костылями и оверинжинирингом.
  • Балансом между тестированием кода и быстрой выкаткой на прод.
  • Балансом между техническим долгом и TTM.
  • Балансом между «пиши код» и «развивай своего джуна» и так далее.

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

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

Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать полностью »

Где именно лежит граница между зарплатными грейдами: как это устроено у нас - 1

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

В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.

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


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