Да, в большой компании процессы сложнее. Но дело не только в этом, но и в предметной области. Когда мы имеем дело с деньгами людей, это сопровождается большой ответственностью. Если будет простой сайта интернет-магазина - это одна история, а если вы в магазине прикладываете карту к терминалу, и не можете оплатить - это совсем другое. Другие требования к безопасности, скорости обработки транзакций, надежности, сервис должен держать очень большую нагрузку. Поэтому менеджер у нас - не просто связующее звено между командой и другими отделами, но и глубоко погруженный в продукт и процессы эксперт, который и команду направляет и мотивирует. Ведь только атмосфера, когда все в команде настроены на высокое качество продукта, верят в свой продукт, приносит такие плоды.
Задача менеджера - выстраивание команды и процесса, чтобы фичи ставились, а баги правились. У нас в компании такие менеджеры и такие процессы (разработки, управления), что мы можем совмещать в себе несколько ролей, это реально. И то, что это работает (сервис работает, выпускаются быстро новые фичи), говорит, что практики не так уж и плохи. :)
Графики и логи доступны всем в команде, и если возникает проблема, нет одного человека, от которого зависит её решение. Обычно менеджер и есть точка входа для мониторинга и саппорта: если загорелся триггер по процессу, за который ответственна команда, первым, к кому придут - будет именно менеджер (либо тот, кому менеджер это делегировал)). Менеджер - такой же член команды, отвечающий за работоспособность продукта, поэтому если возник инцидент, не всегда проще\эффективнее отдать разбираться разработчику, в части случаев - можно за 5 минут по логам понять, в чем проблема, и если это баг, отдать разработке. А далеко не всегда причина инцидента - баги 🙂 У нас достаточно процессов и продуктов, но за качеством мы следим хорошо - критичное все покрыто автотестами, регрессы прогоняем при каждом релизе. Поэтому баги случаются не так часто. Я в своей команде трачу на разбор инцидентов гораздо меньше времени, чем на стендапы в среднем. И заодно берегу ресурс разработки.
В умелых руках очень хороший инструмент, который позволяет широко взглянуть и на свои компетенции, и на компетенции своих сотрудников, увидеть точки роста. Лично я нахожу очень полезным. :)
Изучение нового - в ИТ процесс постоянный, и не только для менеджера. Но менеджер у нас не один на один с проблемами, у нас командная работа, и ребята в командах тоже нам, менеджерам, помогают. Мы за то, что менеджер - это полноценный член команды, обладает экспертизой в своих продуктах и процессах, но это не значит, что он всегда все делает один, напротив. :)
Да, в большой компании процессы сложнее. Но дело не только в этом, но и в предметной области. Когда мы имеем дело с деньгами людей, это сопровождается большой ответственностью. Если будет простой сайта интернет-магазина - это одна история, а если вы в магазине прикладываете карту к терминалу, и не можете оплатить - это совсем другое. Другие требования к безопасности, скорости обработки транзакций, надежности, сервис должен держать очень большую нагрузку. Поэтому менеджер у нас - не просто связующее звено между командой и другими отделами, но и глубоко погруженный в продукт и процессы эксперт, который и команду направляет и мотивирует. Ведь только атмосфера, когда все в команде настроены на высокое качество продукта, верят в свой продукт, приносит такие плоды.
Задача менеджера - выстраивание команды и процесса, чтобы фичи ставились, а баги правились. У нас в компании такие менеджеры и такие процессы (разработки, управления), что мы можем совмещать в себе несколько ролей, это реально. И то, что это работает (сервис работает, выпускаются быстро новые фичи), говорит, что практики не так уж и плохи. :)
Графики и логи доступны всем в команде, и если возникает проблема, нет одного человека, от которого зависит её решение.
Обычно менеджер и есть точка входа для мониторинга и саппорта: если загорелся триггер по процессу, за который ответственна команда, первым, к кому придут - будет именно менеджер (либо тот, кому менеджер это делегировал)).
Менеджер - такой же член команды, отвечающий за работоспособность продукта, поэтому если возник инцидент, не всегда проще\эффективнее отдать разбираться разработчику, в части случаев - можно за 5 минут по логам понять, в чем проблема, и если это баг, отдать разработке. А далеко не всегда причина инцидента - баги 🙂
У нас достаточно процессов и продуктов, но за качеством мы следим хорошо - критичное все покрыто автотестами, регрессы прогоняем при каждом релизе. Поэтому баги случаются не так часто. Я в своей команде трачу на разбор инцидентов гораздо меньше времени, чем на стендапы в среднем. И заодно берегу ресурс разработки.
В умелых руках очень хороший инструмент, который позволяет широко взглянуть и на свои компетенции, и на компетенции своих сотрудников, увидеть точки роста. Лично я нахожу очень полезным. :)
Изучение нового - в ИТ процесс постоянный, и не только для менеджера. Но менеджер у нас не один на один с проблемами, у нас командная работа, и ребята в командах тоже нам, менеджерам, помогают. Мы за то, что менеджер - это полноценный член команды, обладает экспертизой в своих продуктах и процессах, но это не значит, что он всегда все делает один, напротив. :)