Довольно интересно почитать о вашем опыте. Могу сказать что ситуации бывают и правда разными, я считаю стоит все же отталкиваться от того что имеешь. В целом возможно и правильно делать все не торопясь, но все же все определяется вашим бизнес планом еще в зародыше стартапа. Обозначили короткие сроки - жми на газ, расчитали в долгую - расслабься. Конечно отталкиваясь от плана и будет приниматься решения о вливании, поэтому всегда выбирать второй вариант по дефолту будет уместно не всем.
Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Потому что я не хочу, чтобы у других людей, которые пришли сюда ее прочитать, было ощущение, что то, что вы говорите про управляющую роль - верно.
Вам то откуда знать верно это или нет, вы сами сказали что для архитектора не нужны навыки руководителя, вы архитектор => у вас этих навыков быть не должно
Может вы тогда и на эту полную мою цитату ссылку оставите. Вы еще после такого говорите о том что я только удобный контекст цитирую?)
Тогда нам действительно нечего обсуждать.
Ваш первый комментарии был по поводу роли архитектора в этой статье, а потом вы сказали что вам в принципе не нужны знания руководителя. Нам с вами было нечего обсуждать с самого начала, я в целом не понимаю, почему вы с вашими убеждениями вторые сутки комментируете эту статью.
Нет, зачем мне вообще руководить командой, если я все могу сделать сам лучше?
Это уже называется абсолютное нежелание понять, о чем вам говорят
Нет, я скопировал вашу оригинальную цитату полностью.
Я оставил мою оригинальную цитату в предыдущем комменте
Каждому участнику команды?
В целом да, в этом и смысл руководить
Ну вы уж определитесь: либо он прав, и тогда ваше предположение ошибочно, либо он не прав, и тогда мы про него забываем и начинаем думать самостоятельно.
Все что я хотел сказать о цитировании Джобса, я сказал в предыдущем комменте
Поможет. Почему нет?
Потому что вы понятия не имеете как строится NodeJS приложение в реальной работе. Если у вас простое понимание как строятся NodeJS приложения, то скорее всего все что вы знаете это: что такое сервисы, контроллеры, бд и что все на JS.
"Владеют навыками" не означает "хорошо делают". Поэтому нет, не может. По крайней мере, может далеко не всякий продукт.
Ох, давайте еще углубимся в детали. Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Ответ-то очевиден: надо научиться управлять и начать это делать, к этому вопросов нет
Ого, я тут целую статью пишу, а вы все в одном предложении описали, потрясающе
Если техлид занимается организацией спринта, он уже не только техлид. Разделение обязанностей не просто так.
Все он тех лид, все эти разделения обязанностей абстрактные понятия
Тогда зачем команда? Надо все самому делать
Чтобы команде которой вы руководите было комфортно работать
Вы же написали выше: "Хороший руководитель тот, кто лучше других умеет делать свою работу."
Вы не скопировали мою цитату полностью:
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь
А что конкретно обязательно делает руководитель команды, кроме руководства?
Рассказывает как и что делать
Забавно, как вы удобное вам оставляете, а остальное выкидываете.
Вы меня ни на чем не подловили, я не претендую на роль лучшего руководителя, которого описывает Джобс, как вы сказали, возможно это не истинна, а возможно он и прав.
Чтобы иметь понимание, достаточно понимания. Это совсем не то же самое, как, например, умение что-то сделать самому.
Простое понимания как строить NodeJS приложения не поможет вам управлять отделом разработки NodeJS.
А откуда вы, извините, берете определение "полноценной команды"?
Из личного опыта
Прекрасно. Может такая команда это сделать без аналитиков и тестировщиков? ("очевидно, что" нет)
Ну конечно может, многие программисты владеют навыками тестирования и аналитики в том числе. (Я конечно не обесцениваю эти профессии, но как факт ответ: да)
Им не надо ничего делегировать, но им всем надо работать вместе, чтобы получился результат. В моем понимании это и есть команда.
Если сейчас не впадать в обсуждения определении, то и в моем, наверное это команда. Еще раз, статья о том как помочь тем у кого описанных в статье процессов нет.
Это не обязательная задача тех лида я бы сказал, опять же, хочешь сделать хорошо, сделай это сам.
Тогда зачем же руководителю команды быть лучшим разработчиком?
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь и желание руководить.
Чтобы иметь понимание как и что делать
Как это нет? Там есть и борда, и ветки, и ревью PR, и многое другое. Это полноценная команда с настроенным процессом разработки.
Это не полноценная команда, это организация из нескольких сотрудников.
Полноценная команда это когда приходит бизнес и говорит: "ребята, вооот такое приложение хочу". А лид команды потом эту идею превращает в явь и делигирует куски реализации своей команде.
В вашем примере одному андроид разработчику ненадо никому ничего делигировать, он работает один над своим приложением, как и остальные работают одни над своими процессами.
Я не говорил что вам надо следить за статусом задач, я говорил что вам надо правильно организовать комфортное для разработчиков пространство на борде и четко следовать определенным инструкциям.
Я так же не говорил что именно вы должны ревьюить PR.
Какую работу должен уметь лучше всех делать ее руководитель?
Это не тот случай где описывается история того как вырасти в руководителя. Очевидным будет ответ, что у них будет PM, который будет давать каждому из них бизнес задачи, а они сами будут выдумывать как их решить.
По сути каким бы лидом ты ни был: тимлид, техлид. Везде нужны навыки описанные мной в этой статье, не получится сидеть в углу писать и писать свой код. Для того чтобы придуманную вами систему не испортили, а пользовались ей должным образом, вам надо наложить на нее ограничения, эти ограничения можно называть по разному, но я называю их руководящими процессами.
Да, так и получается, бизнес передает задачи тех команде, а разработчик лид их правильно делегирует на команду, это и называется грамотное руководство.
вы подразумеваете, что мой жизненный опыт имеет меньший вес, чем опыт Джобса
И по поводу этого, я ничего не подразумеваю, вы были первый кто сказал что ваш пример из жизни для вас рабочий, значит его, вероятно нет
У него в подчинении были такие же управленцы которых он описывал и речь шла о них.
Раз речь зашла об управлении компании то там своих забот полно, помимо разработки продукта и на все это есть свои методики и опять же, чтобы хорошо руководить компании недостаточно просто «уметь руководить».
В "уметь руководить" входит понимание предметной области управления.
Понимание на каком уровне? Поверхностном? - это плохой руководитель.
Углубленном? - это специалист, о котором я рассказываю
Какие тут личности, я указал вам на то, что вы ставите под сомнения слова человека, который точно знал как руководить компании, противопостовляя это своему личному опыту. Ну поменялась индустрия, а менеджеры не поменялись и подходы все те же самые, появились только новые методики. Однако то что говорите вы
Работа руководителя - руководить
Это в корне неправильная позиция, такой логикой можно предположить что менеджер чупа-чупса может придти и начать управлять программистами.
Довольно интересно почитать о вашем опыте. Могу сказать что ситуации бывают и правда разными, я считаю стоит все же отталкиваться от того что имеешь. В целом возможно и правильно делать все не торопясь, но все же все определяется вашим бизнес планом еще в зародыше стартапа. Обозначили короткие сроки - жми на газ, расчитали в долгую - расслабься. Конечно отталкиваясь от плана и будет приниматься решения о вливании, поэтому всегда выбирать второй вариант по дефолту будет уместно не всем.
Спасибо??
Так никто про лотерею и не говорил, основной посыл такой:
Если ты хочешь стать в руководящей должности программистом, то вот тебе советы как развить в себе эти черты.
Вы выросли в архитекторы из тимлида и при этом доказывали мне что это невозможно? Загадочный вы человек и очень непостоянный.
Я вам помогу процитировать её
Вам то откуда знать верно это или нет, вы сами сказали что для архитектора не нужны навыки руководителя, вы архитектор => у вас этих навыков быть не должно
Может вы тогда и на эту полную мою цитату ссылку оставите. Вы еще после такого говорите о том что я только удобный контекст цитирую?)
Ваш первый комментарии был по поводу роли архитектора в этой статье, а потом вы сказали что вам в принципе не нужны знания руководителя. Нам с вами было нечего обсуждать с самого начала, я в целом не понимаю, почему вы с вашими убеждениями вторые сутки комментируете эту статью.
согласен
Это уже называется абсолютное нежелание понять, о чем вам говорят
Я оставил мою оригинальную цитату в предыдущем комменте
В целом да, в этом и смысл руководить
Все что я хотел сказать о цитировании Джобса, я сказал в предыдущем комменте
Потому что вы понятия не имеете как строится NodeJS приложение в реальной работе. Если у вас простое понимание как строятся NodeJS приложения, то скорее всего все что вы знаете это: что такое сервисы, контроллеры, бд и что все на JS.
Ох, давайте еще углубимся в детали. Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Ого, я тут целую статью пишу, а вы все в одном предложении описали, потрясающе
Все он тех лид, все эти разделения обязанностей абстрактные понятия
Чтобы команде которой вы руководите было комфортно работать
Вы не скопировали мою цитату полностью:
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь
Рассказывает как и что делать
Вы меня ни на чем не подловили, я не претендую на роль лучшего руководителя, которого описывает Джобс, как вы сказали, возможно это не истинна, а возможно он и прав.
Простое понимания как строить NodeJS приложения не поможет вам управлять отделом разработки NodeJS.
Из личного опыта
Ну конечно может, многие программисты владеют навыками тестирования и аналитики в том числе. (Я конечно не обесцениваю эти профессии, но как факт ответ: да)
Если сейчас не впадать в обсуждения определении, то и в моем, наверное это команда. Еще раз, статья о том как помочь тем у кого описанных в статье процессов нет.
Это не обязательная задача тех лида я бы сказал, опять же, хочешь сделать хорошо, сделай это сам.
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь и желание руководить.
Чтобы иметь понимание как и что делать
Это не полноценная команда, это организация из нескольких сотрудников.
Полноценная команда это когда приходит бизнес и говорит: "ребята, вооот такое приложение хочу". А лид команды потом эту идею превращает в явь и делигирует куски реализации своей команде.
В вашем примере одному андроид разработчику ненадо никому ничего делигировать, он работает один над своим приложением, как и остальные работают одни над своими процессами.
Я не говорил что вам надо следить за статусом задач, я говорил что вам надо правильно организовать комфортное для разработчиков пространство на борде и четко следовать определенным инструкциям.
Я так же не говорил что именно вы должны ревьюить PR.
Это не тот случай где описывается история того как вырасти в руководителя. Очевидным будет ответ, что у них будет PM, который будет давать каждому из них бизнес задачи, а они сами будут выдумывать как их решить.
Здесь нет тех процессов, которые я описываю
По сути каким бы лидом ты ни был: тимлид, техлид. Везде нужны навыки описанные мной в этой статье, не получится сидеть в углу писать и писать свой код. Для того чтобы придуманную вами систему не испортили, а пользовались ей должным образом, вам надо наложить на нее ограничения, эти ограничения можно называть по разному, но я называю их руководящими процессами.
Да, так и получается, бизнес передает задачи тех команде, а разработчик лид их правильно делегирует на команду, это и называется грамотное руководство.
И по поводу этого, я ничего не подразумеваю, вы были первый кто сказал что ваш пример из жизни для вас рабочий, значит его, вероятно нет
Нет, не противоречит.
У него в подчинении были такие же управленцы которых он описывал и речь шла о них.
Раз речь зашла об управлении компании то там своих забот полно, помимо разработки продукта и на все это есть свои методики и опять же, чтобы хорошо руководить компании недостаточно просто «уметь руководить».
Понимание на каком уровне? Поверхностном? - это плохой руководитель.
Углубленном? - это специалист, о котором я рассказываю
Так он и не занимался тех частью никогда
Какие тут личности, я указал вам на то, что вы ставите под сомнения слова человека, который точно знал как руководить компании, противопостовляя это своему личному опыту.
Ну поменялась индустрия, а менеджеры не поменялись и подходы все те же самые, появились только новые методики.
Однако то что говорите вы
Это в корне неправильная позиция, такой логикой можно предположить что менеджер чупа-чупса может придти и начать управлять программистами.
Куда ему до жизненного опыта архитектора из Монреаля
Это один из немногих непредвзятых комментариев здесь, браво
https://youtu.be/QplyFXgIx7Q?si=3qWzPdq5xUZWKhNO
Это две разные профессии, но с тем что они не имеют ничего общего я не согласен. Хороший руководитель тот, кто лучше других умеет делать свою работу.