попробуйте посмотреть на это предложение в контексте статьи: хороший разработчик и хороший тимлид "растет" в других условиях, условиях определённости и налаженных процессов. Что почти всегда неверно в случае директора.
Вам повезло расти в хороших компаниях. Если мы говорим про современные процессы, разработчики по умолчанию находятся в тех же условиях неопределенности: бизнесовые сценарии использования новой фичи не определены, предполагаемые нагрузки не обозначены, риски по интеграции непредсказуемы.
Ощущение бесконечной неопределённость у директора, как вы пишете, возникает возможно потому, что нет понимания, собственно, с чем он работает? Я на это и намекал, когда говорил про необходимые знания и навыки, кроме готовности принимать всё что прилетит.
Что это означает на практике? Вот назначили вас завтра на такую должность. У вас ворох нерешенных проблем. И вы займётесь теорией? Звучит нереалистично
Получается назначили вас на должность директора, убеждаться в наличии необходимых навыков не стали. А почему тогда назначили? Может потому что человек "свой", проверенный временем? Об этом и разговор.
Это не претензия лично вам. Открытый вопрос.
Наверно на практике не должно быть таких назначений? Было бы лучше кандидатам сначала освоить предмет своей деятельности, потренироваться под менторством действующих опытных руководителей, а потом принимать должность.
Технический директор отвечает за сотрудников, организацию их условий труда, реализуемость перспектив компании. К этому стоит готовится тем, кто собирается сделать карьерный шаг. А не о снеках и забитом календаре беспокоится.
Лекции Георгия Щедровицкого. Можно начать с популярной книги "Оргуправленческое мышление". Местами душновато, но в целом даёт теоретическую базу по теме.
Эрик Бёрн "Лидер и группа". Формальное описание устройства групп людей. Особенно интересно в контексте обязанности руководителя поддерживать жизнедеятельность команд.
Фредерик Брукс "Мифический человеко-месяц". Раскрывает тему управления сложностью и сроками разработки программных решений.
На первых порах такой поток разнородных задач/проблем/поручений вызывает стресс, особенно с учётом того, что вопросы могут возникать на выходных или в нерабочее время. Ах да, для директора нет понятия «нерабочее время».
Извините, но если директор не в состоянии организовать свой собственный рабочий процесс, почему его допустили до организации работы отдела?
Эта статья только подкрепляет распространенное представление, что для работы руководителем не нужно никаких фундаментальных знаний и навыков. Главное быть лояльным, в режиме 24/7 принимать на себя любую задачу, какую спустят сверху.
В реальности то и получаем. Сначала технический директор тратит свое время на закупку снеков или настройку принтеров для бухгалтеров. А потом компания удивляется почему её ключевые разработчики разбегаются, а текущее техническое решение не соответствует требованиям и целям.
К вопросу ведь можно подойти системно. Сначала в теории разобраться с тем, что организация, руководство и управление - это разные виды деятельности. Изучить устройство человеческих групп и динамику их развития. Осознать роль директора в прикладном смысле. Наконец, тренировать на практике приемы и методики для эффективного исполнения этой деятельности, в зависимости от конкретных обстоятельств.
В статье об этом ни слова. Можно освоить "Джедайские техники" и вперед рулить десятками людей и влиять на бизнес, главное не боятся, всё обязательно получится. Это ответственный подход к делу, вы считаете?
Вот разработчик Вася, которому предложили стать тимлидом, он согласился. Первые пару недель радовался, но вот уже три месяца живёт в каком-то аду.
Как правило, Васю назначают тимлидом, чтобы закопать адскую яму в управленческом процессе, а не потому что заботятся о его счастье.
Так вот, Сет Годин считает, что смелость в том, чтобы закопаться в свою яму, в итоге прорваться на другую сторону и получить всю славу и деньги, какие хотите. То есть Васе стоило, скажем, проговорить свои тревоги с друзьями или специалистом, записать их в дневник, выпустить наружу, прожить, — и нырнуть в яму с новыми силами и спокойствием.
Это не смелость, а эксплуатация своего психологического здоровья ради работы. Невозможно все грустное, тревожащее и неприятное замести под ковер и концентрироваться только на увеличении собственного материального успеха. Если не построить дорогу, Вася выгорит, не в этой яме, так в следующей побольше.
Расскажите лучше что делает Dodo чтобы такие Васи продолжали комфортно работать и строить свою жизнь дальше. Или рекомендация книг про успешный успех это всё?
Даже в процессе увольнения вы требуете от сотрудников проактивности: подумай о команде, подумай о начальнике, расскажи конструктивно о проблемах, не уводи хороших специалистов...
Но почему вы не предъявляете таких же требований к себе?
Но я, к сожалению, работаю начальником. И постоянно общаюсь с множеством других начальников. И правда, увы, такова: после любого «скандального» увольнения начальник садится и думает. Смотрит на свою работу, условия труда, зарплату, треки развития – на всё. На оставшихся сотрудников – причём, совершенно свежим взглядом. Кто сколько получает, кто как прирастает, кому сколько лет, у кого дети, ипотека, нет машины, далеко ли ездить, в каком он обычно настроении, пытается вспомнить, что, когда и кому говорил, не обидел ли.
Почему не можете заранее проговорить желания и перспективы развития сотрудника, запланировать под это изменения в бюджете?
Наверно потому что проще бежать от ответственности в надежде, что все как-нибудь само решится. Проще жаловаться на обстоятельства и ждать конкретных запросов, на которые можно будет реактивно отреагировать с минимальными усилиями.
Хотите чтобы сотрудники не уходили молча? Будьте проактивным, решайте задачи по обеспечению условий труда, это ваша прямая обязанность как руководителя, а не "довольно жуткий геморрой".
Идейно я с вами согласен. Но в данном случае приходится учитывать несовершенство реального мира. Эта Rust обёртка небезопасна настолько, насколько это заложено в оригинальном FMOD API, в контексте наших примеров:
Комбинировать FMOD_Studio_System_Create и FMOD_Studio_System_Initialize нельзя потому что между ними могут быть другие вызовы
FMOD работает как "отдельный процесс", загруженные банки могут использоваться в процессе независимо от количества ссылок на них в Rust приложении
Чтобы это исправить и сделать "как должно быть" нужно отдельное решение, которое бы опиралось на принципы и механизмы Rust, а не фактический FMOD C API. А это уже сложнее чем генератор обёртки, дороже, и вопрос целесообразности.
Спасибо, дельное замечание. Сначала тоже думал переложить на Rust высвобождение ресурсов, реализовать в Drop вызов FMOD_Studio_System_Release и прочее. Но FMOD в любом случае подразумевает ответственность со стороны разработчика за порядок работы с API. Например:
Если пойти в обратную сторону, любой работе с FMOD объектами должен предшествовать FMOD_Studio_System_Initialize, а это подразумевает строгость типов вроде отдельных System и InitializedSystem
Банки выгружать через Drop нельзя, потому что есть сценарии, где это должно происходить только вручную
В итоге хорошо бы сделать более безопасный и строгий интерфейс, но это уже скорее следующий уровень абстракции, который предполагает изменение FMOD API в Rust стиле. Это, на мой взгляд, выходит за рамки обёртки, которая просто скрывает работу с указателями и небезопасным FFI.
Кажется это популярное решение для работы с флагами, не стал его использовать только потому что соблазнила мысль сделать итоговую библиотеку без зависимостей. Но может быть пересмотрю этот момент в будущем.
FMOD не только звуковой движок, но и рабочая среда FMOD Studio, в которой имеют опыт работы многие звукорежиссеры потому что это один из стандартов в отрасли.
Вам повезло расти в хороших компаниях. Если мы говорим про современные процессы, разработчики по умолчанию находятся в тех же условиях неопределенности: бизнесовые сценарии использования новой фичи не определены, предполагаемые нагрузки не обозначены, риски по интеграции непредсказуемы.
Ощущение бесконечной неопределённость у директора, как вы пишете, возникает возможно потому, что нет понимания, собственно, с чем он работает? Я на это и намекал, когда говорил про необходимые знания и навыки, кроме готовности принимать всё что прилетит.
Получается назначили вас на должность директора, убеждаться в наличии необходимых навыков не стали. А почему тогда назначили? Может потому что человек "свой", проверенный временем? Об этом и разговор.
Это не претензия лично вам. Открытый вопрос.
Наверно на практике не должно быть таких назначений? Было бы лучше кандидатам сначала освоить предмет своей деятельности, потренироваться под менторством действующих опытных руководителей, а потом принимать должность.
Технический директор отвечает за сотрудников, организацию их условий труда, реализуемость перспектив компании. К этому стоит готовится тем, кто собирается сделать карьерный шаг. А не о снеках и забитом календаре беспокоится.
Как отправные точки, могу рекомендовать:
Лекции Георгия Щедровицкого. Можно начать с популярной книги "Оргуправленческое мышление". Местами душновато, но в целом даёт теоретическую базу по теме.
Эрик Бёрн "Лидер и группа". Формальное описание устройства групп людей. Особенно интересно в контексте обязанности руководителя поддерживать жизнедеятельность команд.
Фредерик Брукс "Мифический человеко-месяц". Раскрывает тему управления сложностью и сроками разработки программных решений.
Извините, но если директор не в состоянии организовать свой собственный рабочий процесс, почему его допустили до организации работы отдела?
Эта статья только подкрепляет распространенное представление, что для работы руководителем не нужно никаких фундаментальных знаний и навыков. Главное быть лояльным, в режиме 24/7 принимать на себя любую задачу, какую спустят сверху.
В реальности то и получаем. Сначала технический директор тратит свое время на закупку снеков или настройку принтеров для бухгалтеров. А потом компания удивляется почему её ключевые разработчики разбегаются, а текущее техническое решение не соответствует требованиям и целям.
К вопросу ведь можно подойти системно. Сначала в теории разобраться с тем, что организация, руководство и управление - это разные виды деятельности. Изучить устройство человеческих групп и динамику их развития. Осознать роль директора в прикладном смысле. Наконец, тренировать на практике приемы и методики для эффективного исполнения этой деятельности, в зависимости от конкретных обстоятельств.
В статье об этом ни слова. Можно освоить "Джедайские техники" и вперед рулить десятками людей и влиять на бизнес, главное не боятся, всё обязательно получится. Это ответственный подход к делу, вы считаете?
Как правило, Васю назначают тимлидом, чтобы закопать адскую яму в управленческом процессе, а не потому что заботятся о его счастье.
Это не смелость, а эксплуатация своего психологического здоровья ради работы. Невозможно все грустное, тревожащее и неприятное замести под ковер и концентрироваться только на увеличении собственного материального успеха. Если не построить дорогу, Вася выгорит, не в этой яме, так в следующей побольше.
Расскажите лучше что делает Dodo чтобы такие Васи продолжали комфортно работать и строить свою жизнь дальше. Или рекомендация книг про успешный успех это всё?
Даже в процессе увольнения вы требуете от сотрудников проактивности: подумай о команде, подумай о начальнике, расскажи конструктивно о проблемах, не уводи хороших специалистов...
Но почему вы не предъявляете таких же требований к себе?
Почему не можете заранее проговорить желания и перспективы развития сотрудника, запланировать под это изменения в бюджете?
Наверно потому что проще бежать от ответственности в надежде, что все как-нибудь само решится. Проще жаловаться на обстоятельства и ждать конкретных запросов, на которые можно будет реактивно отреагировать с минимальными усилиями.
Хотите чтобы сотрудники не уходили молча? Будьте проактивным, решайте задачи по обеспечению условий труда, это ваша прямая обязанность как руководителя, а не "довольно жуткий геморрой".
Идейно я с вами согласен. Но в данном случае приходится учитывать несовершенство реального мира. Эта Rust обёртка небезопасна настолько, насколько это заложено в оригинальном FMOD API, в контексте наших примеров:
Комбинировать
FMOD_Studio_System_CreateиFMOD_Studio_System_Initializeнельзя потому что между ними могут быть другие вызовыFMOD работает как "отдельный процесс", загруженные банки могут использоваться в процессе независимо от количества ссылок на них в Rust приложении
Чтобы это исправить и сделать "как должно быть" нужно отдельное решение, которое бы опиралось на принципы и механизмы Rust, а не фактический FMOD C API. А это уже сложнее чем генератор обёртки, дороже, и вопрос целесообразности.
Приходится идти на компромисс, я об этом.
Спасибо, дельное замечание. Сначала тоже думал переложить на Rust высвобождение ресурсов, реализовать в Drop вызов
FMOD_Studio_System_Releaseи прочее. Но FMOD в любом случае подразумевает ответственность со стороны разработчика за порядок работы с API. Например:Если пойти в обратную сторону, любой работе с FMOD объектами должен предшествовать
FMOD_Studio_System_Initialize, а это подразумевает строгость типов вроде отдельныхSystemиInitializedSystemБанки выгружать через Drop нельзя, потому что есть сценарии, где это должно происходить только вручную
В итоге хорошо бы сделать более безопасный и строгий интерфейс, но это уже скорее следующий уровень абстракции, который предполагает изменение FMOD API в Rust стиле. Это, на мой взгляд, выходит за рамки обёртки, которая просто скрывает работу с указателями и небезопасным FFI.
Не знаю как мог упустить такой очевидный момент. Спасибо! Переделаю, это сильно упрощает обработку перечислений
Кажется это популярное решение для работы с флагами, не стал его использовать только потому что соблазнила мысль сделать итоговую библиотеку без зависимостей. Но может быть пересмотрю этот момент в будущем.
FMOD не только звуковой движок, но и рабочая среда FMOD Studio, в которой имеют опыт работы многие звукорежиссеры потому что это один из стандартов в отрасли.