В последнее время всё чаще можно услышать об ужесточении чего-либо, в любой из сфер жизни. Так определяет "милосердие" Глеб Жеглов в фильме Говорухина "Место встречи изменить нельзя"</p><p></p>" data-abbr="Поповское слово">Поповское словоЧитать полностью »
Рубрика «команда» - 2
Жёсткое руководство
2024-06-05 в 20:17, admin, рубрики: коллектив, команда, компания, найм, персонал, руководство, стиль, управление людьмиRUNIT 2023: присоединяйтесь к масштабному забегу для IT-специалистов
2023-05-11 в 7:51, admin, рубрики: runit, Блог компании AGIMA, Карьера в IT-индустрии, команда, командообразование, марафон, нетворкинг, спорт, Управление сообществомВ этом году спортивный фестиваль для IT-специалистов RUNIT пройдет 18 июня в Измайловском парке. Мы приглашаем тех, кто развивает IT и Digital, присоединиться к нам. Участие в забеге примут сотрудники крупнейших IT-компаний России: разработчики, тестировщики, DevOps-специалисты, продакт- и проджект-менеджеры, маркетологи.
FeatureWeek: как мы повысили вовлеченность команды и заполнили бэклог
2022-12-05 в 7:56, admin, рубрики: online, Блог компании Lamoda, брейншторминг, бэклог, вовлеченность, генерация идей, команда, команда разработки, мозговой штурм, продуктовая разработка, удаленная работа, Управление продуктом, Хакатоны
Привет! Я Саша Пургина, руководитель отдела развития data-продуктов в Lamoda. В этой статье хочу рассказать, как мы использовали экспертизу разных команд для генерации 200+ новых гипотез и сплотили весь отдел вокруг решения пользовательских проблем.
Что будет, если от разработчиков не отстать: умирающая команда
2022-11-17 в 11:01, admin, рубрики: банк, Блог компании Газпромбанк, задача, команда, проект, процесс, разработка, управление проектами, управление разработкойМне досталась команда, которая болела. Все понимали, что происходит, никому не нравилось, что творится в команде, и традиционно менеджеры такие команды сильно режут. Но здесь были шансы вылечить и без ампутаций.
15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.
Вроде бы когда-то это был настроенный конвейер, но теперь его куски — как будто в разных зданиях. Особо не заботятся о том, что было «до» и что будет «после». А если всё падает, то люди поднимают руки: «Я не виноват. Я не знаю, как поднять».
Проект — внутренний банка, он нужен для улучшения работы внутри компании. Традиционных решений в кровавом энерпрайзе — два: нанять новую команду (но вгружать мидла на проект такой сложности — три-четыре месяца) или же оставить проект на поддержке, через два года найти ему замену, а команду тихо похоронить в подвале. Точнее, не так: те, кто плывет по течению и не заботится о карьере, остаются тихо сидеть «на пенсии», то есть в бесконечной поддержке проекта. А самые проактивные тут же перейдут в другие команды или другие компании.
Почему процессы разваливались? На первый взгляд, потому, что была куча ненужных совещаний и встреч с теми, кого разработчики вообще не должны были видеть. Плюс местами странноватые KPI. Как это ни странно, но если психологически давить на разработчика пару лет, то ничем хорошим это не закончится. Руководство подразделения дало мне карт-бланш на исправления, и я начал разбираться, что же случилось.
Читать полностью »
Как вообще можно управлять отдельными людьми в команде разработки?
2022-07-05 в 7:03, admin, рубрики: Блог компании Skyeng, Карьера в IT-индустрии, команда, метрики, ошибки, перфоманс-менеджмент, результативность, управление, управление персоналом
Перформанс — это результативность команды. Начиная с этого места понятийный аппарат разваливается. Чтобы измерять результативность, нужно знать какую-то метрику. Метрика «строчки кода» определённо не подходит, а метрика «готовые фичи» измеряет продуктолога или команду, а не индивидуального разработчика. И вот этим «чем-то» ещё нужно управлять. Логика в том, чтобы разработчик разрабатывал нужное и с понятной скоростью, чтобы на него можно было полагаться в задачах.
Управлять можно, например:
- Балансом между костылями и оверинжинирингом.
- Балансом между тестированием кода и быстрой выкаткой на прод.
- Балансом между техническим долгом и TTM.
- Балансом между «пиши код» и «развивай своего джуна» и так далее.
Например, хорошие метрики, следующие из этого — это доступность сервиса, максимальное время ответа сервиса, размер техдолга (хотя его тоже сложно измерить), процент покрытия автотестами и так далее.
Но вы не управляете даже этим! Этим всем управляет сам разработчик. Вы же управляете тем, как он понимает текущую ситуацию с компанией, продуктом, командой и своим развитием.
Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать полностью »
Где именно лежит граница между зарплатными грейдами: как это устроено у нас
2022-05-26 в 7:01, admin, рубрики: skyeng, Блог компании Skyeng, грейды, Карьера в IT-индустрии, команда, компетенция, опрос, разработчик, софт скилс, тимлид, управление персоналом, управление проектами, хард скилс
Сколько в компании разработчиков, столько примерно и мнений. Например, где именно проходит граница между мидлом и синьором? Нам нужен был справедливый инструмент оценки, который помогает понять, не получает ли наш специалист зарплату меньше, чем должен был бы. И, самое главное, что нужно делать для того, чтобы развиваться.
В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.
Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Читать полностью »
Как пользователи спасают психику техподдержке
2022-03-22 в 12:03, admin, рубрики: service desk, Блог компании Группа Т1, задачи, команда, общение, пользователь, техподдержка, тикеты
«Набить хай-ло» — программирование светодиодных индикаторов на корпусе для показа Hi или Lo в зависимости от нажатия кнопки «турбо», если кто-то такую ещё помнит. Один из моих первых тикетов в роли поддержки как раз закончился тем, что я сообщил пользователю, что осталось только «набить ему хай-ло».
По прошлому посту «Как пользователи расшатывают психику техподдержке» могло сложиться впечатление, что жизнь у нас совсем не сахар, а скорее даже рудники. Теперь хочу рассказать о тех приятных вещах, которые есть в работе поддержки.
Да, до выхода я так ещё не дошёл и всё ещё хожу по офису в куртке. И да, у нас есть сервис деск, есть тикеты, но всё равно мы отвечаем на устные заявки тоже. Не потому что мы не в состоянии отказать и пригласить пользователя писать тикет, а потому что задача поддержки — чтобы у людей всё работало, а не чтобы они воспринимали нас как геморрой.
Именно эта общительность пользователей даёт первый важный плюс: когда в компании 200–300 человек, а вы социально активны, не боитесь смотреть в глаза людям и нормально общаетесь, — через пару месяцев будете знать вообще всех. И при этом к вам будут хорошо относиться, потому что вы помогаете. Нет, конечно, будут время от времени встречаться люди, которые, наверное, в ресторанах орут на официантов, но с поддержкой фокус «Быстро подойди сюда, я тут босс» не работает. Потому что, кроме SLA, тогда будет применяться USLA, например, при SLA — один час на ответ, при USLA будет 58 минут на ожидание. Но такие случаи очень редки. Чаще всего мы всех любим и нас все любят.
Уже в первые дни любовь выражается в том, что вас стараются подкормить. Почти у всех есть вкусняшки в кабинетах, а приход инженера для многих из разряда «Оно шевелится, милое, давайте его покормим!» Ну, если вы мило шевелитесь, конечно.
Дальше становится интереснее.
Читать полностью »
Я рефакторю компании
2022-01-20 в 11:01, admin, рубрики: Анализ и проектирование систем, бизнес-процессы, Блог компании Группа Т1, команда, Проектирование и рефакторинг, работа, сотрудники, управление, управление проектами, эффективность
Этот архитектор переделывал систему шесть раз, и сейчас к нему пришёл джун сообщить, что пора заходить на седьмую итерацию.
Я работаю человеком, который знает, как лучше поменять что-то в компании, чтобы не сломать что-то другое. Грубо говоря, правильно это называется «бизнес-архитектор», а джун моей специальности называется «бизнес-аналитик».
Мы превращаем людей в скрипты, а потом заменяем их, если получается.
В среднем бизнесе работа бизнес-аналитика или бизнес-архитектора очень похожа на то, что делает ИТ-архитектор. Обычно есть какой-то работающий бизнес, в котором море организационных костылей. Нужно прийти, пересобрать процессы и сделать так, чтобы всё работало лучше.
Как правило, пересбор — это такое разбиение процесса на шаги, которые делает либо микросервис (человек или команда) с известным API, либо, если вам ближе функциональный подход, — функция с понятным входом, выходом, проверками и кодом внутри. По сути, такой человек выстраивает API отделов и команд, потом связывает их между собой по-новому. Иногда бывает нужно перестроить компанию серьёзнее либо создать вообще новое направление.
Почти как программирование, только к ИТ-системам добавляются ещё и живые люди, их потребности и эмоции. В итоге всё настолько декомпозировано на понятные шаги и проверки, что снижаются требования к контексту и компетенциям.
Итак, давайте покажу процесс верхнеуровнево: как разобрать и собрать процессы заново, выстраивая это всё в систему.
«Доктор, меня игнорируют», или Как писать письма так, чтобы их читали
2022-01-10 в 19:56, admin, рубрики: email, взаимодействие, команда, коммуникация, коммуникация в команде, Лайфхаки для гиков, нескучная работа, общение, Подготовка технической документации, понимание, удаленная работа, управление персоналом, управление проектами, читабельность«Мои письма никто не читает.»
«Я уже всё всем написал, а коллеги продолжают спрашивать одно и то же. Бесит.»
И особенно популярное: «Мы ещё неделю назад написали, что удалим эту таблицу из базы, и сказали адаптировать код! Так что мы не виноваты, что сайт (пайплайн, приложение, <подставь своё>) упали.»
Начну с весьма непопулярного заявления: ответственность за доставку и восприятие сообщения процентов на семьдесят лежит на отправителе (то есть на тебе). Конечно, если твой коллега — заядлый социопат и в принципе не читает никакиеЧитать полностью »