Как влиять на сотрудников и правильно ставить задачи им ?

Ты пытаешься мне ответить, не вникнув в то что я написал. Более того - ты не прочитал тему с начала и не используешь вводные данные от ТС. До того как придется применить  кнут или пряник - хватает других методов. Кто сказал, что менторство это только обязанность? У нас за него и плюшек достаточно. 

А у тебя  в голове по-прежнему совковые методы. Именно поэтому у них делают Макьуки и мерседесы, а у вас - лады-калины и китайские ноутбуки с перелкленными этикетками

У меня был. Порядка 3 лет управления корпоративной веб студией и руководство командой в составе 7 человек.

Я в общем не ратую за какую-то глубокую дискуссию, я в общем и в целом за приёмы эффективного менеджмента, но также абсолютно точно уверен, никакая эффективная система распределения внимания, времени и специализации не заменит ключевую возможность решить задачу. 

Да, поделитесь, мне интересно. У меня хоть в настоящем и нет амбиций для занятия должностей по корпоративному управления, но для доп. развития не помешает.

Хочу уточнить - командой вы называете кого? Программистов одного профиля? Для меня команда - весь IT отдел, но устраивать общие брифинги и выносить на них специализированные задачи для общего обсуждения неэффективно.

Да, безусловно.

Да, расскажите, интересно, только пожалуйста по возможности без избыточного погружения в терминологию scrum и аджайл, а на общепринятых словах.

Здесь не соглашусь. 

В команду приходят люди разного уровня. Иногда они там появляются и настойчиво лоббируются собственниками компании. Задача эффективного управленца - не пороть и выгонять неугодных, а искать, предлагать и внедрять решения корпоративного менеджмента. 

Так вот вернёмся к началу абзаца. Как правильно и резонно отметил Слай - менторство одна из форм образования и поддержания рабочего уровня команды. 

Совершенно нормально и зачастую необходимо, когда программисты более высокого уровня курируют работу молодых специалистов. 

Любая компания так или иначе "выращивает" специалиста. У кого-то, в зависимости от подготовки и квалификации этот рост происходит на 3-5% (благодаря освоению практической специфики), кто-то растёт на голову и выше, начиная с обучающей практики и дальше вырастая до уверенного специалиста.

Состав команды нередко разнородный и тем, кто может и хочется учится (но пока не хватает знаний и опыт) обязательно нужно помогать, а вот кто паразитирует на процессе, отсиживается, не желает принимать необходимость рабочей действительности и тормозит процесс - вот от таких членов команды нужно избавляться.

Но однозначно определить того или иного кандидата не всегда получается просто. Бывает талантливый и знающий специалист, но настолько токсичный и отравляющий всё вокруг, что от него все воют и невозможно организовать совместную работу. А бывает такое, что ну не хватает человеку интеллекта и кругозора действовать творчески и инициативно, но в остальном - ответственный, исполнительный и во всех других отношениях хороший специалист - вот для этого человека необходимо искать специализированные задачи (если конечно это возможно).

Я за то, чтобы искать подход к людям (но с учётом возможной перспективы их профессиональной реализации).

У меня есть опыт управления разными коллективами, от нескольких человек в частной фирме до цеха на предприятии. Я знаю одно, если человек дурак его никакое менторство умным не сделает. Таких либо переводить на должность где он сможет работать в зависимости от своих знаний и умений, либо увольнять иначе это якорь для коллектива, из-за которого рано или поздно всё будет ухудшаться и может всё рухнуть. Если у самого человека нет стремления чему-то научится, то никакой ментор, гений и кто либо ещё не научит таково. Сегодня ему объяснили, помогли, через день, неделю он опять будет тупить, это не излечимо. А ещё хуже когда его начальник этого не понимает и говорит, ну в следующий раз будет умнее.., а потом в другой раз и тд. Вот почему учитель для всех(допустим 30 человек) объясняет одинаково, но только один, два могут усвоить материал, а то и никто. Потому что у всех свои планы на будущее, на текущие несколько часов после занятия, на завтра, на месяц, год, на жизнь. Одни из-за своей тупости верят всему что им говорят, другие придают всё сомнению(я такой), третьим на всё плевать и тд. У каждого своя война.

Поэтому либо устанавливаешь одинаковые правила для всех, затем убираешь тех кто не справляется и находишь подходящих. Либо тратишь время, силы, средства на всяких бестолычей и смиряешся с текущей ситуацией, так как ничего изменить по сути не можешь.

Самое забавное то, что ты даже не можешь понять ситуацию, в которой находится ТС - и рассуждаешь с "умным" видом о вещах, в которых ничего не понимаешь. Иди уже, готовься налаживать логистику для своих панов. Там тебе твой аджайл очень поможет, "знаток" планёрок (в отличие от тебя, я их не по фильмам знаю).

Да, все верно. Поэтому так или в любой контрольной точке мы работаем именно с человеком и определяем его потенциал. 

Если потенциал решительно не удовлетворяет рабочим условиях, то "Спасибо, но больше в ваших услугам мы не нуждаемся".

Хорошая оговорка, действительно у каждого своя мотивация и нередко сотрудник можно просто использовать текущий рабочий ресурс. 

Самое сложное, когда ты как руководитель отвечаешь за эффективность рабочего процесса, но есть явный якорь и тормоз, которой нет возможности уволить и более того - заменить, потому как он протекция одного из собственников, а другие собственники не хотят портить с ним отношения, а требуют "как-нибудь найти рабочее решение".   

Как и предполагалось, кроме ТС реальным опытом управления обладает только Антоний и его словам я склонен верить, что это правда. 

Моя первая айтишная работа была - техник-программист в ГОСКОМСТАТе СССР. Все же смотрели служебный роман - ну вот это с нас было списано. С той организацией я вообще не понимаю, как мы умудрялись еще что-то делать) А мы писали первую автоматизацию для сбербанка тогда. Еще на Foxbase/DbaseIII.  В отделе на 15 человек я знал точно что работают трое, чем занимались остальные - понятия не имел. Так что уж есть с чем сравнивать))

Все что я читаю тут про кнуты - это наследие совка, с его кумовством раздутыми штатами и бездельниками в нем. Все это переехало успешно и в коммерческие структуры. Мне на днях звонил одноклассник, просил взять его сына на работу. Похоже обиделся, когда я чказал, что могу подтянуть его и пригласить на собес, но никакой протекции не будет. Максимум могу порекомендовать его, если в разговоре со мной сочту его знания достаточными. 

У нас считает, если черовек прошел сито собесов( у нас их минимум 3) То значит он чего-то стоит. Значит надо потратить на него какие-то усилия, если возникли проблемы с его работой. Поэтому если я как менеджер нажимаю на кнопочку "Уволить" - ко мне будет куча вопросов. Поэтому есть серьезный флоу в случае проблем такого рода.

Для меня эта фраза алогична. Эффективная система это и есть путь решения ключевой задачи.

4 года работая по скраму, мне уже сложно понять что там не общепринятого))) Типа какая разница между грумингом и рефайментом)) 

Ну и вот как ответить на вопрос общепринятыми словами, если я веду разговор про скрам команду? Ликбез по скраму устраивать неохота, кому интересно - почитает сам, там всего то несколько страниц.

Разговор про команду разработчиков - собственно девелоперы, тимлид, бизнес-аналитик/продукт оунер, тестировшик, скрам-мастер. Это у нас. естественно бухгалтер там не нужен. Все остальные должны понимать что команда делает.

Эти слова несложно проверить, так как смена руководителей ООО фиксируется в истории карточки юр. лица и данная информация находится в публичном доступе.

Но всё же уточню, что я не был тим лидом команды программистов, эту должность выполнял старший программист, которого назначал я и их программистов  (включая старшего)  было всего 3.

Очень интересно! Вот правда очень интересно (без иронии).

Достойно и категорически правильно. Нет большей тягомотины, чем жалость или чувство стенающего дискомфорта о того, что в команде абсолютно ненужный человек, его невозможно убрать, но конкретно ты - человек, который обязан бесконечно пинать дохлую лошадь.

Согласен. Здесь нет противоречий.

А вот здесь мы к сожалению расходимся. Эффективная система - это способ организации внутренних ресурсов (временных, финансовых, интеллектуальных), однако если, условно, яблоки c гнильцой, то как их не перемешивай, как не взвешивай, не подогревай и не подкидывай, не выбирай места хранения и не регулируй влажность, и температуру, гнильца не уйдет. 

А вот когда гнильцы нет - да, можно создать условия в которых яблоки будут храниться существенно больше, нежели этого не делать. Более того, есть сорта зимних яблок, которые именно после нескольких месяцев сохранности (в нужным условиях) обретают исключительно новый насыщенный вкус.

Делайте, пожалуйста, скидку. Это не форум программистов.  И уж тем более не форум по управлению. 

Вы же можете объяснить качественную разницу в разборе конкретного проблемного случая используя обычный лексикон. Думаю, что можете, вот лично я - прошу.

Читать ещё дополнительно что-то и вникать, чтобы понять собеседника - это доп. усилия и время. Если бы я решал рабочую задачу - я бы так и поступил, но у нас просто разговор, в котором желательно оперировать понятиями, соответствующие уровню восприятия слушающего. 

Читать о преимуществах SCUM подхода возможно полезно, но конкретно у меня в этом нет необходимости, мне искренне интересно, как это помогало вам в конкретных рабочих ситуациях.

Все верно. И эффективная система должна содержать механизм удаления таких яблок. Как крайнюю меру. Никто не должен тянуть баланс. Разговор  же о том, как максимально избежать этого. С меня как с менеджера спросят, какие меры из флоу "retantion " я применил, прежде чем уволить человека. Существует целый список мероприятий.

Не знаю что это такое, если говорим про СКРАМ, то часто задача скрам-мастера, не дать разработчикам увлечься в и уйти не туда. Любой код можно переписывать вечно и всегда найдется что улучшить, это как ремонт - нельзя закончить, можно только остановить. 

Не дать закопаться в проблему, вовремя привлечь кого-то более компетентного. Опять же перед начальством вовремя обозначить проблему. Много что позволяет срам. Цель одна - в обьявленные эстимации выпустить готовый продукт.

Мнение дилетанта..

Код необходимо улучшать только в трёх случиях:

1. Когда код устаревает, т. е.  когда в языке программирования произошли модификации, ввелись новые команды, функции, изменился синтаксис. То есть когда код перестаёт работать.
2. Когда в этом есть необходимость, когда нужны дополнительные возможности или наоборот когда удаляется не нужное замедляющее работу и тд.
3. Когда человек написал код с минимальными знаниями, опытом и очень коряво. Когда видишь и понимаешь что это говнокод, и лучше написать по другому, что улучшит его работу, уменьшит нагрузку, ускорит выполнение и тд.