Вы меня немного не поняли: я критикую не пункт "лично ездить на объект", это наоборот похвально. А пункт "Рукпроекта - служба единого окна для Заказчика, а запросов у него, как у 2-летнего ребенка". Вы занимаетесь микроменеджментом, замыкая на себе все вопросы. Неудивительно, что Ваши подчинённые не имеют своего мнения, уже привыкли, что вы сами все решаете за них
Так Вы сами подходите к правильному ответу на свой вопрос:) В идеале руководитель НИЧЕГО не делает! Но без него ничего не работает, потому что только у него есть ключики к каждому сотруднику/процессу. У меня лично есть опыт руководства небольшим отделом, на управление которым я тратил 1,5 дня в неделю, все остальное время занимаясь личными делами.
плохая статья, смешали в одну кучу все обязанности: и техлида, и тимлида, и наставника. То, о чем Вы пишите в самом начале (разные подходы к написанию кода) обычно решается написанием регламента разработок, которого заставляют всех придерживаться.
Пару раз встречал на проектах техлидов, но их обязанности в основном заключались, чтобы выбрать корректный стек, на котором все работают.
Вникать в каждую проблему, одновременно всех убеждать и при этом как-то, чтобы 80 % времени оставалось на обучение - с трудом укладывается в 40-часовую рабочую неделю) Ну и это скорее относится к обязанностям тимлида
я указал те моменты, к которым необходимо стремиться в идеале :)
Например, закончили Вы текущий проект, понимаете, что бригадир монтажников отличный специалист, переговорили с ним, что через пару месяцев у вас будет новый проект и было бы отлично снова с ним поработать. С начальством одновременно выбиваете для него допоплату или другие "плюшки".
Если каждый проект начинать с новыми людьми, которых первый раз видишь, то понятно, что будете наступать на одни и те же грабли.
Критические моменты - это то, от чего зависит Ваша оплата и Ваш крепкий сон) У всех людей это по-разному. Например, в IT-компании всем все равно если люди опаздывают на час и больше, а на заводе каждая минуту опоздания это катастрофа. У Вас должен быть свой список таких моментов. У меня, например, бзик на документации, потому что я понимаю, если нет документации, то в случае каких-то новых доработок новому сотруднику придется потратить огромное кол-во времени, чтобы вникнуть в суть. Соответственно, подрядчикам не подписываются акты, пока они не приведут все в порядок/
Извините, если сумбурно написал, но основная мысль, что за всеми лично не уследишь и не проконтролируешь. Ну или работать по 80 часов в неделю и оборудование топить через раз)
Хорошая статья, но финал скомкан оказался. По Вашему мнению секрет - в микроменеджменте, то есть то, от чего руководителю необходимо отказываться в первую очередь. Может быть в стройке такой подход и оказался полезен (все таки результат работы на виду и сразу все видно), но есть куча отраслей, где этот подход не работает (не только IT).
Вы в статье привели всего один пример, где Ваше непосредственное присутствие спасло оборудование на проекте, но я не вижу тут системного подхода. Вы по сути как в казино, подкинули монетку поставив все на красное (что оборудование затонет), и угадали, хотя все Ваши подчиненные в один голос сказали, что все в порядке. То есть вопрос в недостаточной квалификации/вовлеченности сотрудников либо непрописанности алгоритмов в критических ситуациях. И судя по всему Вы все оставили все как есть, то есть в следующей критической ситуации опять будете гадать, не получив помощи от подчиненных.
Ключ к успешной работе: 1) подбор квалифицированного и проактивного персонала; 2) определение критических моментов, по которым вы будете контролировать их работу; 3) наделение сотрудников всеми необходимыми полномочиями.
Статья хорошая, но пока Вы находитесь на неверном пути)
а у меня наоборот, какое-то чувство отвращения к автору и всем тем, чем он занимался. Работал на самой интересной позиции (RND) в одной из самых топовых компаний мира, а все рассказы про пьянки и корпоративные интриги. Читая эти статьи, понимаешь, почему Интел теряет свои позиции по миру
у меня часто бывает, что если отложил какую-то задачу по работе, сроки по ней все пропустил, то потом очень сложно к ней приступить. При этом по другим задачам в это же время могу спокойно и продуктивно работать. А "задача-лягушка" в итоге может решаться за полчаса
Интересная статья, спасибо, но со многими пунктами не соглашусь. Ниже ряд из них приведу, но их гораздо больше, и напишу почему с ними не согласен:
1) Отсутствие понимания технологий, нежелание разбираться в особенностях того или иного инструмента (пример с Post и Oracle):
На хабре пару лет назад наткнулся на статью, как другой автор проводит собеседования, и там была очень крутая мысль, что помимо оценки его профессиональных качеств, необходимо еще учитывать его роль и обязанности, для которых вы собственно нанимаете сотрудника. То есть в чем польза человека, который знает в совершенстве язык программирования, если он будет заниматься пресэйлом или РП, не переплатите ли Вы за те скиллы, которые не требуются Вам в данный момент. То есть, конечно, это все неплохо, но не критично.
И наоборот, у меня есть огромное количество коллег, которые могут закрыть 90% задач по проекту, но при этом без понятия что такое база данных и чем они отличаются друг от друга. Я сам без понятия)
Здесь надо еще учитывать, что нанимая такого рода увлеченных людей, Вы вряд ли уговорите их годами заниматься однообразными задачами, все время придется подкидывать им интересные проекты и при отсутствии таких они без сожаления покинут вашу компанию (сам такой :))
2) Неумение формулировать определения:
бесполезный навык, который скорее говорит о Вас, как о не совсем адекватном работодателе. Р. Фейнман говорил, что вы тогда разбираетесь в своем деле, когда можете объяснить это ребенку, а ребенок вряд ли поймет сухой и казенный язык. В чем проблема растянуть определение на небольшой рассказ, не пытаясь уместить свою мысль в небольшое предложение?)
3) Неумение смотреть на ситуацию «сверху»:
людей с таким навыком очень мало, и они явно не ходят по собеседованиям на миддл-аналитика.
Общее впечатление от автора статьи, что довольно редкостный зануда, который будет тебя поправлять в разговоре, по 10 раз требовать переформулировать вопрос/ответ и все в таком духе) Сталкивался с такими людьми не раз: багаж знаний неплохой, но желания работать в команде с такими людьми не было
ничего странного, если накатывать голый функционал + у заказчика отлажены процессы. В личной практике рекорд - внедрение за 2 месяца (SAP) командой из 5 человек
Вы меня немного не поняли: я критикую не пункт "лично ездить на объект", это наоборот похвально. А пункт "Рукпроекта - служба единого окна для Заказчика, а запросов у него, как у 2-летнего ребенка". Вы занимаетесь микроменеджментом, замыкая на себе все вопросы. Неудивительно, что Ваши подчинённые не имеют своего мнения, уже привыкли, что вы сами все решаете за них
Так Вы сами подходите к правильному ответу на свой вопрос:) В идеале руководитель НИЧЕГО не делает! Но без него ничего не работает, потому что только у него есть ключики к каждому сотруднику/процессу. У меня лично есть опыт руководства небольшим отделом, на управление которым я тратил 1,5 дня в неделю, все остальное время занимаясь личными делами.
плохая статья, смешали в одну кучу все обязанности: и техлида, и тимлида, и наставника. То, о чем Вы пишите в самом начале (разные подходы к написанию кода) обычно решается написанием регламента разработок, которого заставляют всех придерживаться.
Пару раз встречал на проектах техлидов, но их обязанности в основном заключались, чтобы выбрать корректный стек, на котором все работают.
Вникать в каждую проблему, одновременно всех убеждать и при этом как-то, чтобы 80 % времени оставалось на обучение - с трудом укладывается в 40-часовую рабочую неделю) Ну и это скорее относится к обязанностям тимлида
я указал те моменты, к которым необходимо стремиться в идеале :)
Например, закончили Вы текущий проект, понимаете, что бригадир монтажников отличный специалист, переговорили с ним, что через пару месяцев у вас будет новый проект и было бы отлично снова с ним поработать. С начальством одновременно выбиваете для него допоплату или другие "плюшки".
Если каждый проект начинать с новыми людьми, которых первый раз видишь, то понятно, что будете наступать на одни и те же грабли.
Критические моменты - это то, от чего зависит Ваша оплата и Ваш крепкий сон) У всех людей это по-разному. Например, в IT-компании всем все равно если люди опаздывают на час и больше, а на заводе каждая минуту опоздания это катастрофа. У Вас должен быть свой список таких моментов. У меня, например, бзик на документации, потому что я понимаю, если нет документации, то в случае каких-то новых доработок новому сотруднику придется потратить огромное кол-во времени, чтобы вникнуть в суть. Соответственно, подрядчикам не подписываются акты, пока они не приведут все в порядок/
Извините, если сумбурно написал, но основная мысль, что за всеми лично не уследишь и не проконтролируешь. Ну или работать по 80 часов в неделю и оборудование топить через раз)
Хорошая статья, но финал скомкан оказался. По Вашему мнению секрет - в микроменеджменте, то есть то, от чего руководителю необходимо отказываться в первую очередь. Может быть в стройке такой подход и оказался полезен (все таки результат работы на виду и сразу все видно), но есть куча отраслей, где этот подход не работает (не только IT).
Вы в статье привели всего один пример, где Ваше непосредственное присутствие спасло оборудование на проекте, но я не вижу тут системного подхода. Вы по сути как в казино, подкинули монетку поставив все на красное (что оборудование затонет), и угадали, хотя все Ваши подчиненные в один голос сказали, что все в порядке. То есть вопрос в недостаточной квалификации/вовлеченности сотрудников либо непрописанности алгоритмов в критических ситуациях. И судя по всему Вы все оставили все как есть, то есть в следующей критической ситуации опять будете гадать, не получив помощи от подчиненных.
Ключ к успешной работе: 1) подбор квалифицированного и проактивного персонала; 2) определение критических моментов, по которым вы будете контролировать их работу; 3) наделение сотрудников всеми необходимыми полномочиями.
Статья хорошая, но пока Вы находитесь на неверном пути)
а у меня наоборот, какое-то чувство отвращения к автору и всем тем, чем он занимался. Работал на самой интересной позиции (RND) в одной из самых топовых компаний мира, а все рассказы про пьянки и корпоративные интриги. Читая эти статьи, понимаешь, почему Интел теряет свои позиции по миру
норм статья, плохо представляю как именно применить формулу, но сама идея достойная
у меня часто бывает, что если отложил какую-то задачу по работе, сроки по ней все пропустил, то потом очень сложно к ней приступить. При этом по другим задачам в это же время могу спокойно и продуктивно работать. А "задача-лягушка" в итоге может решаться за полчаса
спасибо)
Добрый день!
Интересная статья, спасибо, но со многими пунктами не соглашусь. Ниже ряд из них приведу, но их гораздо больше, и напишу почему с ними не согласен:
1) Отсутствие понимания технологий, нежелание разбираться в особенностях того или иного инструмента (пример с Post и Oracle):
На хабре пару лет назад наткнулся на статью, как другой автор проводит собеседования, и там была очень крутая мысль, что помимо оценки его профессиональных качеств, необходимо еще учитывать его роль и обязанности, для которых вы собственно нанимаете сотрудника. То есть в чем польза человека, который знает в совершенстве язык программирования, если он будет заниматься пресэйлом или РП, не переплатите ли Вы за те скиллы, которые не требуются Вам в данный момент. То есть, конечно, это все неплохо, но не критично.
И наоборот, у меня есть огромное количество коллег, которые могут закрыть 90% задач по проекту, но при этом без понятия что такое база данных и чем они отличаются друг от друга. Я сам без понятия)
Здесь надо еще учитывать, что нанимая такого рода увлеченных людей, Вы вряд ли уговорите их годами заниматься однообразными задачами, все время придется подкидывать им интересные проекты и при отсутствии таких они без сожаления покинут вашу компанию (сам такой :))
2) Неумение формулировать определения:
бесполезный навык, который скорее говорит о Вас, как о не совсем адекватном работодателе. Р. Фейнман говорил, что вы тогда разбираетесь в своем деле, когда можете объяснить это ребенку, а ребенок вряд ли поймет сухой и казенный язык. В чем проблема растянуть определение на небольшой рассказ, не пытаясь уместить свою мысль в небольшое предложение?)
3) Неумение смотреть на ситуацию «сверху»:
людей с таким навыком очень мало, и они явно не ходят по собеседованиям на миддл-аналитика.
Общее впечатление от автора статьи, что довольно редкостный зануда, который будет тебя поправлять в разговоре, по 10 раз требовать переформулировать вопрос/ответ и все в таком духе) Сталкивался с такими людьми не раз: багаж знаний неплохой, но желания работать в команде с такими людьми не было
ничего странного, если накатывать голый функционал + у заказчика отлажены процессы. В личной практике рекорд - внедрение за 2 месяца (SAP) командой из 5 человек
охранник хороший)