Тут нет секрета: вырабатываешь правила и придерживаешься их. Правила примерно описаны в разделе «Ваша команда — не команда». А команда подхватывает, если, конечно, совсем неподходящего человека не нанял, скажем, индивидуалиста, который не способен слышать мнения окружающих.
Тезисы примерно верны, но один вы упустили:
Вот вам правила, взяв которые за основу, вы можете построить Команду.
Мне это напоминает поведение новичков в покере — сделали ставку и продолжают повышать, не желая терять первоначальную ставку и надеясь на то, что карта придёт. В итоге проигрывают много больше, чем могли себе позволить.
Спасибо за разъяснение. Но все равно, звучит как теория. То ли вы не проходили на практике, то о чем пишете, то ли наоборот этот успешный опыт у вас уже давно в бессознательном. Вы строили команды? Вот, прямо лично вы, строили? Не наблюдали, не помогали, а строили? Если так — напишите об этом статью, пожалуйста. На примере легче понять и поверить.
Рассматривайте работу Вашего коллектива как совокупность юзкейсов или процессов, а людей — как объекты, которые их реализуют.
Данное представление как будто упрощает людей. Человеческий фактор не зря считается серьезным источником сложностей. Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением. Аналогию с объектами вряд ли можно считать практичной.
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Тут согласен.
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Я не видел в работе программиста такой работы с процессами, которая помогла бы ему в дальнейшем управлять людьми. Поэтому формально с утверждением я согласен, а вот с вероятным выводом из этого утверждения — нет.
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
Соглашусь.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Согласен. Только тех. навыки тут совсем не помогают.
Давайте вернемся к исходному вопросу — какие именно, максимально конкретно, тех. навыки программиста, коли мы находимся в контексте разработки ПО, помогают ему руководить людьми? Я увидел много слов, но к сожалению не увидел ответа. Могу своё видение описать, но хочу все таки сначала увидеть ваше, чтобы исключить влияние.
Чтобы наш разговор был более предметным я предлагаю вам описать ваше понимание Senior, а читатели пояснят где ваше мнение отличается от их. И т.к. стандарта нет, то вы ведь позволите им иметь собственное мнение?
Да, в вакансиях пишут эти названия уровней, но это очень расплывчатые понятия, которые понимаются по-разному в разных местах. В том числе поэтому я и утверждаю, что общепринятой классификации нет.
Как раз вчера общался с руководителем, учредителем двух компаний, руководитель направления в одной немецкой компании. Он в итоге пришел к выводу, что руководитель должен разбираться в людях и управлении, но ни в коем случае не должен пытаться сделать дело своими руками — это отвлекает от основной обязанности — управления. Хорошо я он вышел из разработки.
Может ли руководитель оказаться самодуром? Ещё как может! И разработческое прошлое от этого не спасает.
Спасибо за рекомендацию. Судя по описанию книги, основная её мысль заключается в потере IT специалистами фокуса с денег. Эту мысль достойно доносит книжка impact mapping и мимоходом касается в книгах specification by example и bdd in action. В принципе тема мной усвоена.
Нет общепринятой классификации уровней разработчиков, Так что не знаю о каком общепринятом мнении речь. И я убеждён, что умение руководить не зависит от компетенции в разработке.
Тезисы примерно верны, но один вы упустили:
Вот! Это главное слово для строительства любой рабочей системы.
Но мысли, точно, годные. Еще раз спасибо.
Ладно, чего я умничаю. Вот моё видение.
Принципы SOLID.
Об ограничении рабочих функций:
О взаимозаменяемости кадров, о важности ролей:
Данное представление как будто упрощает людей. Человеческий фактор не зря считается серьезным источником сложностей. Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением. Аналогию с объектами вряд ли можно считать практичной.
Тут согласен.
Я не видел в работе программиста такой работы с процессами, которая помогла бы ему в дальнейшем управлять людьми. Поэтому формально с утверждением я согласен, а вот с вероятным выводом из этого утверждения — нет.
Соглашусь.
Согласен. Только тех. навыки тут совсем не помогают.
Давайте вернемся к исходному вопросу — какие именно, максимально конкретно, тех. навыки программиста, коли мы находимся в контексте разработки ПО, помогают ему руководить людьми? Я увидел много слов, но к сожалению не увидел ответа. Могу своё видение описать, но хочу все таки сначала увидеть ваше, чтобы исключить влияние.
А ведь я с вами согласен. А можете еще раскрыть ваше видение — какие именно «тех.навыки применимы и в управлении людьми»?
Чтобы наш разговор был более предметным я предлагаю вам описать ваше понимание Senior, а читатели пояснят где ваше мнение отличается от их. И т.к. стандарта нет, то вы ведь позволите им иметь собственное мнение?
«Хотя он вышел из разработки»
«руководитель направления в одной немелкой компании»
Как раз вчера общался с руководителем, учредителем двух компаний, руководитель направления в одной немецкой компании. Он в итоге пришел к выводу, что руководитель должен разбираться в людях и управлении, но ни в коем случае не должен пытаться сделать дело своими руками — это отвлекает от основной обязанности — управления. Хорошо я он вышел из разработки.
Может ли руководитель оказаться самодуром? Ещё как может! И разработческое прошлое от этого не спасает.
Руководство = управление.
notdotteam.github.io/trust