Очень меткое замечание про чувство утраты ценности. Я в свое время жёстко дизмораль поймал именно оттого, что привык быть центром экспертизы и держать в руках все ключевые точки бизнес-логик и технических реализаций.
Пока это было в рамках одной команды проблем не было. Но, когда попал в работу над давно развивавшимся продуктом, с количеством участников 40 человек, и мне надо было заниматься выстраиванием процессов, я перестал успевать уделять достаточно внимания разработке, стал страдать от собственной "некомпетентности и бесполезности". Пришлось пересматривать привычный взгляд на свое "место в мире".
В целом такая позиция в России имеет довольно серьезные основания и, в кое-что веки, могу сказать, что у нас менеджеры оказались дальновиднее западных коллег.
Сам, будучи менеджером, постоянно вайбкожу разные автоматизации для рабочих процессов, это сильно быстрее чем когда я писал те же вещи руками. Но, в то же время, постоянно наблюдаю, как хваленого Клод Кода уносит не туда, как он теряет контекст, делает иногда странные предположения и т.п. Поэтому у нас вайбкодинг прочно обосновался в прототипировании, код ревью процессах, генерации документов, лёгких автоматизациях, но везде, где цена ошибки высока, контроль над происходящим должен быть в железной хватке разработчика. Точка. Это не значит не пользоваться кодгеном. Это значит пользоваться, но не доверять железному болвану.
Давно автор, вас читаю, есть реально интересные публикации. Но в данном случае вы демонстрирует полное непонимание самой сути управления чем-то крупным и статью можно свести к мысли "оставьте умных людей в покое, и все будет работать хорошо". На проектах с большим бюджетом, зрелой спаянной командой, лояльными заказчиками это действительно может так получиться. Но как только появляется какой-то дефицит - и идея самокалибрующейся системы начинает троить. Тут ведь знаете, есть такая работа, которую не видно, пока все идёт хорошо. Никто не видит дворника пока улицы чистые и никто не думает про электрика пока в доме есть свет. И никто не понимает, зачем кормить менеджмент, пока есть заказы и нет задержек зарплат и сокращений.
Так вот, говорю вам как человек, много времени проведший с обеих сторон, и как пишущий скрипты и постановки аналитик, и как выстраивающий процессы управленец:
Оценки нужны не чтобы отдать их наверх. Они нужны что спланировать роадмап продукта и график релизов, убедиться что при текущем ресурсе команды реально выдержать сроки, с учётом SLA по поддержке, обязательств по контрактам и поставке фичей, запланировать ресурсы команды и инфры. И идея "просто оставьте умных людей в покое" не решит этой задачи. Эти же самые умные люди потом будут крепки задним умом и будут говорить что менеджер должен был подумать заранее про приоритеты фич, про найм человека на фронт и на инфру, должен был сформировать реалистичные ожидания у заказчиков и многое многое другое. И можно будет справедливо сказать "мы работали хорошо, а менеджер не справился". Так как ему справиться если у него нет инструмента для хотя бы примерного прогнозирования-то?)
А если продукт/проект большой? Десятки, сотни человек? В таким масштабах физически нереально не то что каждого учесть, даже в лицо-то не каждого знаешь, в этих условиях какой команде сколько нагрузки запланировать? Когда они это отдадут? Как сформировать ожидания смежных команд, чья работа зависит от поставки этой? Вот эти все простои , потом авралы, разве это не есть прямое следствие неумения менеджера в дата драйвен?
Есть, конечно, те, кто используют отчёты как средство самопродвижения и самопиара, только процессы-то тут причем? Это не процессы ненужные, это люди ими корыстно злоупотребляют просто. Так любой порядок можно довести до абсурда, а любой закон - превратить в насмешку. Так что ж теперь, отменять все законы, скатываться в каменный век?) Так в джунглях тоже есть законы) Так что правильный путь - бороться не с процессами, а с теми, кто их извращает и лишает содержательности.
Простите, но как можно свести 10 лет жизни к сумме денег, заработанной за это время?
То есть на одной чаше 10 лет труда, вызовов, взлетов и падений, общения с семьёй, друзьями и коллегами, занятий хобби и спортом, путешествий и прочее прочее, что собственно и есть содержание жизни: все эти события и эмоции, которые они дарят.
А на другой чаше - сумма, которую за это время человек заработал.
Хорошо, конечно, поискать светлое в любой ситуации.
Хорошо не сдаваться при первых сложностях.
Хорошо иметь страсть и волю к победам.
И все же, на мой взгляд, в статье есть попытка натянуть сову на глобус.
Работать и терпеть при любом стрессе - это не здоровая альтернатива тому, чтобы бежать от любых трудностей. Это - другая форма крайности.
Путь героя - это про личностный рост, а не про то чтобы умирать на работе.
Я лично "за" когда речь идёт об ответственности за взятые на себя обязательства. Но вместе с тем я не понимаю эту риторику про терпеть трудности ради "высшей цели". Открывайте устав своей компании, там в первых строках написано черным по белому, что смысл создания организации - получение прибыли. И люди идут работать потому что им платят. Компания зарабатывает, люди зарабатывают. Это взаимосвязано, но причем здесь высшие цели? Цели, на мой взгляд, довольно- таки материально приземленные.
Очень вас понимаю. Причем, кажется, дело не только в работе. Просто чем сложнее ты становишься, чем более сложные вопросы поднимаешь, тем меньше тех, с кем можно обсуждать свои мысли и проблемы.
А если и решишь с кем-то поговорить, то нешаблонные ответы и советы услышишь редко, а шаблонных я и сам могу сколько угодно генерить.
С написанным согласен. В целом мое самоощущение также близко к "балуется чтобы быть "в строю"
И я также писал про то что это не тот скилл, который менеджеру нужен "кровь из носа". Сам знаю много менеджеров на крупных проектах, у кого нет навыка писать код, но не знаю ни одного, кто не умел бы вникнуть в бизнес-процесс и со всеми договориться, пройти между Сциллой и Харибдой требований и ресурсов.
Есть, правда, в наличии навыка разработки еще один интересный и неожиданный момент, который меня сейчас занимает: если есть интерес к продуктовой разработке и живая идея, но нет ресурсов команды на эксперименты, то собственный скилл позволяет накидать прототип решения, а прототип "продать акционерам" в теории намного проще чем презентацию. Пока это гипотеза, и запустить продукт я не пробовал, но интерес в организации к моим автоматизациям на уровне желания их пощупать и внедрить я вижу.
Я, кстати, с вами полностью согласен в формуле "уметь надо, делать не надо ". Возможно, от статьи создалось впечатление что я призываю разрабатывать самому, но я старался просто донести пользу от знания разработки и поделиться некоторыми кейсами.
Мы с вами точно не совпадаем во взгляде на норму. Вы утверждаете что "нормальный" менеджер должен быть загружен и не иметь времени ни на что кроме менеджмента. А я считаю, что это утверждение в корне неверно. Если у менеджера нет времени ни на что кроме рутины проекта - то у вас проблемы с автоматизациями/делегированием/рабочим процессом/формированием ожиданий заказчика/планирования сроков и нагрузок/{подставьте сами}. Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Заметьте, я нигде не сказал что надо собой замещать разработчика. Я только обрисовал пользу от знания программирования для управленца. Также я нигде не сказал, что учиться надо в рабочее время. Я лично учусь по вечерам, понемногу, по 1-2 часа в день.
По времени обучения - я имел ввиду что-то вроде бесплатных курсов со степика "Поколение Python для начинающих" и "Основы Pandas для начинающих". Их общая продолжительность 105 часов (оценка самих авторов), поэтому пара месяцев.
Но если "галопом по Европам" - то все необходимое можно и часов в 35-40 вместить пожалуй.
Автор, хотя то что ты описал (буду обращаться на "ты" как это принято в отрасли, не воспринимай как неуважение пожалуйста) выглядит как довольно неприятный опыт, мне так видится, что тебе повезло это опыт получить достаточно рано, в тот момент, когда ты был к нему готов, у том объеме, который мог выдержать.
Дело в том, что карьерный путь длинный, и токсичные руководители и заказчики, так же как воровство идей, фаворитизм, манипуляции и обесценивание - это тот самый shit, который just happens. Этого нельзя избежать, оно конечно плохо, но "плохо" - часть жизни, и главный вопрос - это суметь выжить, отрефлексировать, научиться с этим сосуществовать когда нужно, на ранней стадии распознавать, стоять за свой интерес и продолжать расти. Судя по всему, статья и есть та самая рефлексия человека, видевшего некоторое shit, так что поздравляю, молодец, и так держать!
Очень меткое замечание про чувство утраты ценности. Я в свое время жёстко дизмораль поймал именно оттого, что привык быть центром экспертизы и держать в руках все ключевые точки бизнес-логик и технических реализаций.
Пока это было в рамках одной команды проблем не было. Но, когда попал в работу над давно развивавшимся продуктом, с количеством участников 40 человек, и мне надо было заниматься выстраиванием процессов, я перестал успевать уделять достаточно внимания разработке, стал страдать от собственной "некомпетентности и бесполезности". Пришлось пересматривать привычный взгляд на свое "место в мире".
Жаль, не наткнулся на статью раньше.
В целом такая позиция в России имеет довольно серьезные основания и, в кое-что веки, могу сказать, что у нас менеджеры оказались дальновиднее западных коллег.
Сам, будучи менеджером, постоянно вайбкожу разные автоматизации для рабочих процессов, это сильно быстрее чем когда я писал те же вещи руками. Но, в то же время, постоянно наблюдаю, как хваленого Клод Кода уносит не туда, как он теряет контекст, делает иногда странные предположения и т.п. Поэтому у нас вайбкодинг прочно обосновался в прототипировании, код ревью процессах, генерации документов, лёгких автоматизациях, но везде, где цена ошибки высока, контроль над происходящим должен быть в железной хватке разработчика. Точка. Это не значит не пользоваться кодгеном. Это значит пользоваться, но не доверять железному болвану.
Давно автор, вас читаю, есть реально интересные публикации. Но в данном случае вы демонстрирует полное непонимание самой сути управления чем-то крупным и статью можно свести к мысли "оставьте умных людей в покое, и все будет работать хорошо". На проектах с большим бюджетом, зрелой спаянной командой, лояльными заказчиками это действительно может так получиться. Но как только появляется какой-то дефицит - и идея самокалибрующейся системы начинает троить. Тут ведь знаете, есть такая работа, которую не видно, пока все идёт хорошо. Никто не видит дворника пока улицы чистые и никто не думает про электрика пока в доме есть свет. И никто не понимает, зачем кормить менеджмент, пока есть заказы и нет задержек зарплат и сокращений.
Так вот, говорю вам как человек, много времени проведший с обеих сторон, и как пишущий скрипты и постановки аналитик, и как выстраивающий процессы управленец:
Оценки нужны не чтобы отдать их наверх. Они нужны что спланировать роадмап продукта и график релизов, убедиться что при текущем ресурсе команды реально выдержать сроки, с учётом SLA по поддержке, обязательств по контрактам и поставке фичей, запланировать ресурсы команды и инфры. И идея "просто оставьте умных людей в покое" не решит этой задачи. Эти же самые умные люди потом будут крепки задним умом и будут говорить что менеджер должен был подумать заранее про приоритеты фич, про найм человека на фронт и на инфру, должен был сформировать реалистичные ожидания у заказчиков и многое многое другое. И можно будет справедливо сказать "мы работали хорошо, а менеджер не справился". Так как ему справиться если у него нет инструмента для хотя бы примерного прогнозирования-то?)
А если продукт/проект большой? Десятки, сотни человек? В таким масштабах физически нереально не то что каждого учесть, даже в лицо-то не каждого знаешь, в этих условиях какой команде сколько нагрузки запланировать? Когда они это отдадут? Как сформировать ожидания смежных команд, чья работа зависит от поставки этой? Вот эти все простои , потом авралы, разве это не есть прямое следствие неумения менеджера в дата драйвен?
Есть, конечно, те, кто используют отчёты как средство самопродвижения и самопиара, только процессы-то тут причем? Это не процессы ненужные, это люди ими корыстно злоупотребляют просто. Так любой порядок можно довести до абсурда, а любой закон - превратить в насмешку. Так что ж теперь, отменять все законы, скатываться в каменный век?) Так в джунглях тоже есть законы) Так что правильный путь - бороться не с процессами, а с теми, кто их извращает и лишает содержательности.
Почему у статьи нет тега #юмор ?
Простите, но как можно свести 10 лет жизни к сумме денег, заработанной за это время?
То есть на одной чаше 10 лет труда, вызовов, взлетов и падений, общения с семьёй, друзьями и коллегами, занятий хобби и спортом, путешествий и прочее прочее, что собственно и есть содержание жизни: все эти события и эмоции, которые они дарят.
А на другой чаше - сумма, которую за это время человек заработал.
И вы ставите знак равенства?
Хорошо, конечно, поискать светлое в любой ситуации.
Хорошо не сдаваться при первых сложностях.
Хорошо иметь страсть и волю к победам.
И все же, на мой взгляд, в статье есть попытка натянуть сову на глобус.
Работать и терпеть при любом стрессе - это не здоровая альтернатива тому, чтобы бежать от любых трудностей. Это - другая форма крайности.
Путь героя - это про личностный рост, а не про то чтобы умирать на работе.
Я лично "за" когда речь идёт об ответственности за взятые на себя обязательства. Но вместе с тем я не понимаю эту риторику про терпеть трудности ради "высшей цели". Открывайте устав своей компании, там в первых строках написано черным по белому, что смысл создания организации - получение прибыли. И люди идут работать потому что им платят. Компания зарабатывает, люди зарабатывают. Это взаимосвязано, но причем здесь высшие цели? Цели, на мой взгляд, довольно- таки материально приземленные.
Спасибо за обзор
Очень вас понимаю. Причем, кажется, дело не только в работе. Просто чем сложнее ты становишься, чем более сложные вопросы поднимаешь, тем меньше тех, с кем можно обсуждать свои мысли и проблемы.
А если и решишь с кем-то поговорить, то нешаблонные ответы и советы услышишь редко, а шаблонных я и сам могу сколько угодно генерить.
Когда меня попросят привести наглядный пример эффекта Даннинга-Крюгера, я знаю, что отправлять
С написанным согласен. В целом мое самоощущение также близко к "балуется чтобы быть "в строю"
И я также писал про то что это не тот скилл, который менеджеру нужен "кровь из носа". Сам знаю много менеджеров на крупных проектах, у кого нет навыка писать код, но не знаю ни одного, кто не умел бы вникнуть в бизнес-процесс и со всеми договориться, пройти между Сциллой и Харибдой требований и ресурсов.
Есть, правда, в наличии навыка разработки еще один интересный и неожиданный момент, который меня сейчас занимает: если есть интерес к продуктовой разработке и живая идея, но нет ресурсов команды на эксперименты, то собственный скилл позволяет накидать прототип решения, а прототип "продать акционерам" в теории намного проще чем презентацию.
Пока это гипотеза, и запустить продукт я не пробовал, но интерес в организации к моим автоматизациям на уровне желания их пощупать и внедрить я вижу.
Я, кстати, с вами полностью согласен в формуле "уметь надо, делать не надо ".
Возможно, от статьи создалось впечатление что я призываю разрабатывать самому, но я старался просто донести пользу от знания разработки и поделиться некоторыми кейсами.
Мы с вами точно не совпадаем во взгляде на норму.
Вы утверждаете что "нормальный" менеджер должен быть загружен и не иметь времени ни на что кроме менеджмента.
А я считаю, что это утверждение в корне неверно. Если у менеджера нет времени ни на что кроме рутины проекта - то у вас проблемы с автоматизациями/делегированием/рабочим процессом/формированием ожиданий заказчика/планирования сроков и нагрузок/{подставьте сами}.
Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Заметьте, я нигде не сказал что надо собой замещать разработчика. Я только обрисовал пользу от знания программирования для управленца.
Также я нигде не сказал, что учиться надо в рабочее время. Я лично учусь по вечерам, понемногу, по 1-2 часа в день.
По времени обучения - я имел ввиду что-то вроде бесплатных курсов со степика "Поколение Python для начинающих" и "Основы Pandas для начинающих". Их общая продолжительность 105 часов (оценка самих авторов), поэтому пара месяцев.
Но если "галопом по Европам" - то все необходимое можно и часов в 35-40 вместить пожалуй.
Автор, хотя то что ты описал (буду обращаться на "ты" как это принято в отрасли, не воспринимай как неуважение пожалуйста) выглядит как довольно неприятный опыт, мне так видится, что тебе повезло это опыт получить достаточно рано, в тот момент, когда ты был к нему готов, у том объеме, который мог выдержать.
Дело в том, что карьерный путь длинный, и токсичные руководители и заказчики, так же как воровство идей, фаворитизм, манипуляции и обесценивание - это тот самый shit, который just happens. Этого нельзя избежать, оно конечно плохо, но "плохо" - часть жизни, и главный вопрос - это суметь выжить, отрефлексировать, научиться с этим сосуществовать когда нужно, на ранней стадии распознавать, стоять за свой интерес и продолжать расти. Судя по всему, статья и есть та самая рефлексия человека, видевшего некоторое shit, так что поздравляю, молодец, и так держать!