Вопрос "повернут ли бизнес под вас" на самом деле вопрос _вашего личного статуса там_. Будет статус повыше — повернут.
B>и вот теперь дайте мне правильный ответ на вопрос, который задают все участники процесса до уровня зам-директора включительно: B>"ну вот есть у вас этот один. вот такой он замечательный. все классно. что будет, если завтра его трамвай переедет?". B>другой вариант того же вопроса: B>"считайте, что его нет. начиная с текущего момента и ближайшие 2 месяца. что вы будете делать?".
Этап первый. Исследование причин возникновения такой ситуации.
Возможные варианты:
а) остальные сотрудники просто слабоваты для такого проекта и "не тянут".
б) человек подмял под себя важнейшие вещи из соображений своей job security.
Возможно сочетание этих вариантов, но лично мне кажется, что в этом случае (сочетания) лечение Б невозможно без лечения А — некому дела передавать.
Потому, если есть А — то это главная проблема. Надо решать ее, а уже потом бороться с Б, если Б имеет место.
Лично я ни разу не видел, чтобы такое возникало при отсутствии как А, так и Б — т.е. в команде адекватных спецов, которые не "заныкивают".
Этап второй. Действия по улучшению ситуации.
В случае А это может быть институт тьюторства, или же — увы и ах — смена кадровой политики в сторону набора более толковых людей. Ну да, ФОТ вырастет, но считайте, что это плата за снижение риска переезда трамваем центрового человека.
В случае Б — внедрение процессов, направленных на большую открытость всего кода всей команде. Перевод данного спеца с одного кода на другой раз в какое-то время. Если он сильный спец — то каждый раз на самый сложный. Если же слабый — то ну и пусть его, будет рядовым, которого кидают с одного фронта на другой, ничего страшного.
Если в процессе таких переводов выявится его совсем неприемлемая слабость (т.е. Б в чистом виде) — то резекция.
Оставление за собой кода в таком виде, что он не понятен без поллитры для других — это большой минус, большой вклад в слабость сотрудника и склонение той чаши весов, на которой написано "резекция".
N_C>По-моему, он просто предлагает просчитать риски и начать процесс их минимизации. Если одним из способов минимизировать риск будет увольнение сотрудника... что-ж — это только один из способов.
В случае А (см. мой корневой пост в теме) — это с хорошими шансами полный провал проекта. Придется приглашать "варяга", который, может, проект и вытянет, но все вернется на круги своя — а если травмай переедет "варяга"?
N_C>Это нормальный процесс минимизации риска. Только надо понимать, что риском здесь является не увольнение сотрудника, а развал проекта в случае его увольнения. Соответственно одним из способов минимизировать этот риск является полное выведение этого человека из проекта. И ничего страшного в этом нет.
Ага, всего-навсего проект развалится. Попробовать можно. Если после этого все сотрудники начнут неформально бегать к Ване в вопросами "Вань, а как вот тут надо" — то надо отыгрывать назад.
N_C>разработчика мне ни о чем не говорит — он может быть прекрасным кодером, но ему будет трудно изучать новые технологии,
В рамках одного проекта это дело десятое.
N_C>он может быть очень умным и буквально схватывать все новое, но посредственным разработчиком, когда дело дойдет до рутины.
Тогда он не умный, а посредственный разработчик, просто с нахватанностью пенсионерки.
N_C>Звезды нужны в стартапах, или там, где нужен прорыв, а в обычной работе они бывают зачастую даже вредны именно из-за своей звездности.
Это зависит от еще одного фактора, уровня сложности задач на проекте. Если все задачи просты, но их много — тогда не нужен.
Наличие в команде человека, чей уровень действительно выше уровня задач — зло. Overqualified.
C>>У нас наверно разное понимание терминов разработка и простой кодинг. N_C>Скорее разное понимание звездности.
Звезда — понятие относительное. Относительно уровня сложности задач на проекте.
N_C>Хм. Не согласен. Если собрать звезд в такой проект тоже лучше не станет. Нужен баланс. В тех частях проекта, где нужен быстрый результат — пожалуйста звезду (но опять-же надо смотреть какую...)
Да нет. Толкового человека в архитекторы надо, а не туда, где он "быстро делает".
N_C>У бизнеса цель одна — заработать денег. И чем меньше рисков при большей отдаче, тем лучше.
Вы не понимаете, что это две разные, а иногда противоречащие друг другу вещи? вы не понимаете, что часто снижение рисков стоит денег? что часто идет выбор между "больше прибыль" и "меньше риски"?
B>Начиналось все прекрасно и примадонна показала себя очень и очень хорошо. B>Потом, осознав свою "незаменимость" она выбила для себя: B>1) 4-х дневную рабочую неделю B>2) запрет на собрания с ним в послеобеденное время B>3) практически полную свободу при выборе кусков, которые он может делать полностью сам. B>4) кучу других вещей по мелочам, включая личный чайник, B>который ему нужен для особых сортов чая, без которых он не может программировать.
А вы как-то пытались с этим бороться? а как?
Человек вам сел на шею. Что было сделано для того, чтобы пресечь это на ранних этапах?
Почему за счет компании ему куплен личный чайник? почему он не мог сам его свой принести из дома?
Подскажу, как обломать такое: дать ему чужой кусок, ему неприятный, и попросить высказать просветленное мнение. Мнение должно быть а) аргументированным б) позитивным, т.е. направленным не на констатацию плохости кода, а на выработку предложений по улучшению.
Если не хочет — значит, не справился с работой. Через какое-то время он либо начнет справляться, либо же покажет себя как олух и его можно будет выгнать без проблем.
B>>1) 4-х дневную рабочую неделю B>>2) запрет на собрания с ним в послеобеденное время B>>3) практически полную свободу при выборе кусков, которые он может делать полностью сам. B>>4) кучу других вещей по мелочам, включая личный чайник,
0rc>А вам не кажется, что это вполне нормальные требования которые бы подошли большинству работников предприятия? И виноват он в том, что выбил это только себе, а не всем?
IB>6. Проблема со "звездами" в том, что они расслабляют весь остальной коллектив. Причем это происходит на иррациональном уровне — башкой человек понимает, что этот шлемазл, сидящий на против — заслужил чайник и возможность приходить позже на два часа, а он сам пока нет. А хочется, черт возьми, все равно таких же благ. Эта ситуация жутко озлобляет и демотивирует.
А если шлемазл по должности старше? никто же не будет возмущаться, что директор имеет личный чайник и приходит, когда захочет?
IB>Более того, существуют примеры "звезд", которые с удовольствием работают в кампаниях второго типа (ориентированных на процесс), потому что прекрасно знают, что если их не строить, то и делать они ничего не будут.
Немного не так. Процесс гарантирует от гнилых базаров с обвинениями в случае, если все сделано по процессу. Это плюс на самом деле для всех, а не только для середнячков.
Звезде нужно не отсутствие процесса. Звезде нужно подтверждение звездности и исключительности. Отсутствие процесса лично для него любимого — это частный случай. Можно иначе, например, тупо больше зарплату, пропуск с надписью "архитектор", неподчинение конкретным персоналиям, которым звезда считает для себя унизительным подчиняться (будет подчиняться другим персоналиям), и так далее.
B>Конкретно сейчас есть объективные причины, почему примадоннам позволено много чего B>и почему они вообще существуют среди разработчиков. B>Рынок перегрет и работников реально не хватает. B>Это сказывается и еще как.
На мой взгляд, ориентация на примадонн была главным образом в самом начале ИТ бизнеса в России, годы в 90-93.
В развитых продвинутых структурах ее почти не осталось к 96 году. Менее развитые структуры проходили свой путь с опозданием, и у них это могло и до года 2000 задержаться.
Я с трудом верю в ярко выраженную примадонну (с личным чайником с особым сортом чая) в наше время. Вот году в 92 — сколько угодно.
Пообтесали просто людей. Они уже давно приучены, что прямо в лоб нарциссить вряд ли получится.
B>но проблем он делает до 50-70% на проекте. включая (как вы верно заметили) сваливание команды в полном составе (хотя свалить она может и из за идиота манагера тоже, что даже чаще).
Бывает, бывает. Играя на дружелюбии, подбивают имеющихся сотрудников компании, откуда уволили, к смене места работы со ссылкой якобы на кретинизм директора и с игрой на мелких обидках, нанесенных директором сотрудникам.
N_C>Ну уж позвольте и мне не согласится. Тем более с такой жесткой формой ответа. Где они так называют менеджеров, которые считают риски и которые достаточно мудры, чтобы рассмотреть (именно рассмотреть, а не обязательно применить) не только варианты удержания сотрудников, но и их увольнения? (приведите цитату плз.)
Не буду цитировать. Читай PeopleWare от начала до конца. Тебе точно полезно будет.
MSS>1 — ненормально. Прямая недоработка часов.
Какая разница, если результат выше, чем у всех?
Если он будет работать 8 часов с тем же результатом, кому будет лучше?
MSS>3 — ненормально. Обнуляет управляемость проекта.
Не факт. Вполне возможно, ему делегировали эту роль именно для улучшения управляемости проекта.
N_C>>У бизнеса цель одна — заработать денег. И чем меньше рисков при большей отдаче, тем лучше. MSS>Вы не понимаете, что это две разные, а иногда противоречащие друг другу вещи? вы не понимаете, что часто снижение рисков стоит денег? что часто идет выбор между "больше прибыль" и "меньше риски"?
Понимаю. Но от этого идея заработать больше денег при меньших рисках для бизнеса не становиться призпрачнее. При любых раскладах бизнесом деньги всегда будут вкладываться туда, где есть большая отдача при меньших рисках. Для того, чтобы нивелировать эти тенденции и существует государство, которое вкладывает деньги несколько по иным принципам.
N_C>>И второй — почему Вы решили, что звезда — это архитектор? MSS>А там что, лучший девелопер — не архитектор? т.е. архитектор — кто похуже?
Вопрос не в этом. С какого перепугу лучший девелопер должен быть архитектором? Архитектором может быть и человек не менее опытный и знающий, чем лучший девелопер. Да и области знаний архитектора и девелопера несколько разнятся.
N_C>Понимаю. Но от этого идея заработать больше денег при меньших рисках для бизнеса не становиться призпрачнее. При любых раскладах бизнесом деньги всегда будут вкладываться туда, где есть большая отдача при меньших рисках.
Еще раз повторяю: зачастую "больше денег" и "меньше рисков" — противоречат. Хотя бы в игре на бирже.
N_C>Вопрос не в этом. С какого перепугу лучший девелопер должен быть архитектором? Архитектором может быть и человек не менее опытный и знающий, чем лучший девелопер. Да и области знаний архитектора и девелопера несколько разнятся.
