Комментарии 14
— А зачем?
— За шкафом.
Программирование - вторая грамотность.
сможете делать немножко волшебства с файлами и табличками уже через пару месяцев.
Примерно через 36 часов чистого времени. Пара месяцев это или неделя - смотря у кого сколько времени, чтобы учиться.
По времени обучения - я имел ввиду что-то вроде бесплатных курсов со степика "Поколение Python для начинающих" и "Основы Pandas для начинающих". Их общая продолжительность 105 часов (оценка самих авторов), поэтому пара месяцев.
Но если "галопом по Европам" - то все необходимое можно и часов в 35-40 вместить пожалуй.
Проглядывается подмена понятий "Надо ли менеджеру уметь писать код" и "Надо ли менеджеру писать код". Как бывший разработчик скажу своё мнение: уметь надо, делать не надо.
Уметь надо что бы иметь общие понятия - не столько о написании кода, сколько процессов ему сопутствующих (бранчинг, авто тестирование, оценка работы и тд).
Писать самому не надо. Во первых учитывая обязанности менеджера (люди, процессы, стейкхолдеры, продукт, архитектура) на кодинг времени хватит только если воспринимать позицию инженерного лидера как скрам мастера который пишет код. Восприятие это кстати весьма распространенное, и на мой взгляд весьма ошибочное. Во вторых главная роль руководителя это целеполагание и делегирование, а не написание кода. Вторичная роль - растить талант в своей команде, а это сложно если руководитель сам принимает все технические решения - с ним не поспоришь. Получается конфликт интересов.
Поэтому кстати в западной практике тим лиды являются чисто техническими лидерами, и подчиненных не имеют.
в карму плюс за смелость, минус за статью, потому что не согласен с изложенным.
Если вы менеджер, у которого есть время на изучение программирования - вы недозагруженный менеджер. Лиду аналитиков еще можно играться в скрипты, питоны и сиквели, а вот менеджер должен учиться делегировать.
тотже трекер (нормальный) имеет открытое апи, изучить которое можно поручить разработчику (4 часа), потом понять , какие данные нужны вашему PMO (8 часов с учетом кофе и обеда и , к примеру, нескольких дашбордов), поставить задачку на создание дашбордов на основании данных (пара дней, но зависит от требований к отчетам и фронту).
И это я говорю, как руководитель ПМО, который такие задачи и ставил. Но я не шарю в питоне и в sql ничего кроме select * from all не знаю :) и мне оно и не надо. Фокус на другом у менеджера должен быть.
Минус за комментарий, потому что не согласен с возражением.
Как известно, восьмичасовый труд прекрасен, а значит у каждого есть время на любое хобби. Например на изучение программирования.
Мы с вами точно не совпадаем во взгляде на норму.
Вы утверждаете что "нормальный" менеджер должен быть загружен и не иметь времени ни на что кроме менеджмента.
А я считаю, что это утверждение в корне неверно. Если у менеджера нет времени ни на что кроме рутины проекта - то у вас проблемы с автоматизациями/делегированием/рабочим процессом/формированием ожиданий заказчика/планирования сроков и нагрузок/{подставьте сами}.
Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Заметьте, я нигде не сказал что надо собой замещать разработчика. Я только обрисовал пользу от знания программирования для управленца.
Также я нигде не сказал, что учиться надо в рабочее время. Я лично учусь по вечерам, понемногу, по 1-2 часа в день.
Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Мне мои менеджеры в полном составе говорят "спасибо" за развитие. Я даже менторингом занялся из-за этого.
Я наверное сходу резковато сказал, так иногда словами выглядит. Реально я категорически ЗА развитие любого человека в рамках организации. Сам писал про это: взаимное развитие возможно только при совпадении целей организации и сотрудника (тут можно сделать ремарку, что далеко не все сотрудники осознаны, чтобы понимать свои цели на 1-3-5 лет, но фиг с ним).
Но есть нюанс. У меня правда много опыта, я очень много где работал и сам в роли РП и я знаю, какие навыки РП нужны, а какие нет. И для меня, как представителя компании, и для моих РП, которые хотят и готовы расти профессионально, важно развивать то, что нужно чаще. А это софтскиллы: умение работать с заказчиками и капризным бизнесом, умение работать в потоке задач, делегирование и прочие веселости.
И вот этому я учу своих на практике. А заодно учу ценить себя, выпихиваю в отпуск, чтобы не выгорели (потому что нафиг оно мне надо - искать хорошего РП с рынка долго и дорого) и так далее.
В этом списке есть навык РП быть аналитиком и разбираться в технике ровно настолько, чтобы иногда взять на себя отвествтенность за какое-то решение, предложенное командой (или хотябы просто понять изменения и уметь пояснить заказчикам при необходимости).
Но нет навыка разработки, так как все кейсы, когда это было надо (и приведенный выше вами) решался на уровне описания требований и постановки тикета разработчику.
Так-то, разумеется, веселится каждый так, как хочет. Я вот знаю CDTO очень большой компании, который на досуге балуется Питончиком, чтобы чувствовать себя "в строю" :)
Но к его работе отношения это, конечно, не имеет. Когда ему необходимы серьезные дашборды (а у него 10 тыс человек в организации), он зовет свое аналитическое управление, а то управление зовет подрядчиков, чтобы те подогнали данные для отчетности. То есть в реале оно вот так.
С написанным согласен. В целом мое самоощущение также близко к "балуется чтобы быть "в строю"
И я также писал про то что это не тот скилл, который менеджеру нужен "кровь из носа". Сам знаю много менеджеров на крупных проектах, у кого нет навыка писать код, но не знаю ни одного, кто не умел бы вникнуть в бизнес-процесс и со всеми договориться, пройти между Сциллой и Харибдой требований и ресурсов.
Есть, правда, в наличии навыка разработки еще один интересный и неожиданный момент, который меня сейчас занимает: если есть интерес к продуктовой разработке и живая идея, но нет ресурсов команды на эксперименты, то собственный скилл позволяет накидать прототип решения, а прототип "продать акционерам" в теории намного проще чем презентацию.
Пока это гипотеза, и запустить продукт я не пробовал, но интерес в организации к моим автоматизациям на уровне желания их пощупать и внедрить я вижу.
Для чего ИТ менеджеру уметь программировать. И главное — зачем