Комментарии 90
В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.
А поясните, пожалуйста, кого же именно вы понимаете под "технарем"?
Под «технарями» я понимаю людей, которые участвуют в работе с программным обеспечением и/или информационными системами на всех этапах от создания до эксплуатации, и всего, что с этим связано. Например, к «технарям» я отношу инженеров, разработчиков, архитекторов, системных аналитиков, системных администраторов, специалистов по информационной безопасности, тестировщиков и т.д.
В дополнении к вопросу предыдущему коментатору — а какие есть "технари", которые не "инженеры"?
Автор под «инженерами» имел в виду в большей степени «инженеров-разработчиков», так как руководил командой, которая создавала базу данных.
а какие есть «технари», которые не «инженеры»?
Научные работники, нпр., в сферах математики, физики, CS и т.д. Или здесь речь только о разработках, где таких не требуется?
Или здесь речь только о разработках, где таких не требуется?
ИТ – это рынок: люди работают на вас, потому что они в вас верят. Доступ к таланту людей – это привилегия.
Как я понимаю, похоже на то.
Если научные работники, физики (на самом деле, здесь можно перечислять профессии и дальше) и т.д. непосредственно заняты в работе по созданию некоторой информационной системы или программного продукта (пишут алгоритмы, код, создают железо, на котором все это будет работать), то они тоже входят в это понятие в том его значении, которое имелось в виду в «уроках». Хотя, в общем виде, на мой взгляд, они больше относятся к другой важной группе людей, которые принимают участие в создании систем и ПО: консультантов, бизнес аналитиков, бизнес архитекторов и др. – людей, которые задают функциональные характеристики продукта.
8. Не контролируйте качество и объем работы, которую делают сотрудники. Процесс разработки – не конвейер. (Прим. переводчика – Я бы с этим поспорил. Зависит от проекта. Для каждого отдельного разработчика – это не конвейер, а в масштабах информационной системы, которую создает команда, вполне себе даже.) Если вы влезаете в процесс со своим контролем слишком часто, это означает, что вы не подключили правильных людей или не дали им стимула развиваться.
А я бы не спорил. Если у вас повышенные требования к качеству кода, то введите code review. Если у вас есть вопросы к совершаемому объему работы (и только если эти вопросы действительно есть и критичны), то поручите более опытному товарищу помочь, потом у него узнайте, какие знания и умения нужно подтянуть вашему разработчику. Но не надо контролировать постоянно — так вы разрушаете доверие.
17. Руководителей часто окружает презрение. Не обращайте на это внимание. Люди, которые считают менеджеров бесполезными, не понимают тонкостей процесса создания команды победителей.
А вот тут я бы поспорил. Презрение окружает руководителей, занимающихся ерундой, неквалифицированных, грубых, напыщенных (нужное подчеркнуть). Руководители, занимающиеся своей командой, решающие, а не создающие проблемы, обеспечивающие фронт работ и достойную компенсацию — они пользуются заслуженным уважением.
1) Я спорил не с фразой про контроль, а с тем, что «Процесс разработки – не конвейер». С вашими предложениями абсолютно согласен. Code review и наличие в команде более опытных товарищей, которые помогают молодым специалистам – это важные критерии зрелости проекта и уровня команды соответственно.
2) Думаю, что автор уроков имел в виду скорее то, что не все сотрудники осознают важность роли руководителя в команде, особенно тех руководителей, которые стоят по вертикали на уровне выше, чем +1 от сотрудника. Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют. При этом, согласен с вами, зачастую этому способствуют и те сценарии поведения руководителей, о которых вы написали.
2) Думаю, что автор уроков имел в виду скорее то, что не все сотрудники осознают важность роли руководителя в команде, особенно тех руководителей, которые стоят по вертикали на уровне выше, чем +1 от сотрудника. Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют. При этом, согласен с вами, зачастую этому способствуют и те сценарии поведения руководителей, о которых вы написали.
Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют.
Если руководитель +1 приходит и что-то требует от сотрудника — то это несколько странный руководитель. Стоит соблюдать принцип «вассал моего вассала не мой вассал».
Сложный вопрос. Исторически вассалитет устарел. Странно будет, если в рамках одной современной фирмы или учреждения директор не будет иметь прав говорить с рядовыми сотрудниками. Как еще он сможет выявить негодных руководителей среднего звена?
Говорить — можно. Ставить задачи (без явного разрешения промежуточного руководителя) — нельзя.
(это верно только для иерархических структур, конечно)
Зав.отделом устраивает обсуждение текущего хода проекта. Все собрались, и рядовой программист докладывает: «для решения данной подзадачи литературный сетевой поиск выявил подходы А, Б, В. Мы использовали А». Зав.отделом: «почему не Б? Выглядит гораздо привлекательнее.» Рядовой, кивает на непосредственного начальника: «Иван Иваныч так сказал...» Иван Иваныч: «ну, в прошлом и позапрошлом проекте этот подход себя зарекомендовал...» Зав.отделом, рядовому: «У меня личная просьба, попробуйте Б и завтра лично мне доложите».
Зав.отделом не прав?
Зав.отделом не прав?
Не прав. Рядовой с этого момента не считается со мнением непосредственного начальника, а тот начинает считать его любимчиком завотделом (это утрируя, конечно). Правильно — это заву обсудить с непосредственным начальником выбор подходов, и убедить того попробовать, чтобы тот поставил эту задачу нижестоящим.
Или, что вероятнее, понять, почему этого делать не надо
Однако в наше время в большинстве стран мира укоренилась армейская дисциплина, когда нижестоящий начальник просит разрешения присутствующего вышестоящего обратиться к третьему лицу, а не наоборот — вышестоящему не требуется просить разрешения. Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
Однако в наше время в большинстве стран мира укоренилась армейская дисциплина, когда нижестоящий начальник просит разрешения присутствующего вышестоящего обратиться к третьему лицу, а не наоборот — вышестоящему не требуется просить разрешения.
Укоренилась где? В армии? Возможно, ничего про это не знаю.
А вот в корпоративной среде это некорректно, потому что нарушает иерархию.
Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
Именно поэтому большому начальнику не надо объяснять, что должен делать конкретный рядовой. Делегируйте.
Укоренилась где? В армии?В НИИ, в гос.учреждениях и в частных компаниях. Член совета директоров говорит секретарше отделения «принесите кофе, pls» или «принесите отчет за январь прошлого года», и найдется ли зав. отделением, который не будет кивать, а возразит, что это его секретарша?.. Я такого не видел. А Вы?
А вот в корпоративной среде это некорректно, потому что нарушает иерархию.Тут речь не про корпоративную среду? А про какую?
Член совета директоров говорит секретарше отделения «принесите кофе, pls» или «принесите отчет за январь прошлого года», и найдется ли зав. отделением, который не будет кивать, а возразит, что это его секретарша?.. Я такого не видел. А Вы?
А я видел людей, которые формулируют аналогичную просьбу как "можно кофе" — и уже принимающая сторона решает эту проблему своим способом.
А главное, есть некоторая разница между секретаршами и линейными сотрудниками.
Тут речь не про корпоративную среду? А про какую?
Тут речь как раз про корпоративную среду.
Именно поэтому большому начальнику не надо объяснять, что должен делать конкретный рядовой. Делегируйте.Совершенно нереально, когда решение большого начальника касается каждого рядового. Выбор технологии, инструмента, языка.
Как раз совершенно реально. Выбрали технологию — довели до начальников следующего уровня, те распространят дальше. Нет никакой необходимости бегать за каждым исполнителем.
Нет! Большой начальник приказал — переходим на новый язык Х и не за кем не бегает. При этом начальник ниже не сможет сказать: как писали на Васике — так и продолжим. При вассалитете было не так: герцог приказал перейти на мушкеты, а мелкий барон говорит: как стреляли из луков — так и будем стрелять, и герцог был не в праве вмешаться.
А просто не надо воспринимать аналогию буквально, вот и все.
Тогда не надо бросаться словами:
«вассал моего вассала не мой вассал»И одобрять столь небуквальное…
А я и не бросался такими словами. Я просто объяснил вам, как этот принцип надо понимать применительно к нынешней иерархии управления.
(и спорили вы, что характерно, именно с моим объяснением)
Не объяснили. Объяснения нет:
не надо воспринимать аналогию буквально— не объяснение. На этом закончу.
Не объяснили. Объяснения нет:
Эм, вот же: "Ставить задачи (без явного разрешения промежуточного руководителя) — нельзя."
Этого не бывает. Если и найдете такого «главного» — то «тряпка» — самая мягкая характеристика от его подчиненных.
У кого не бывает, а кто по такому принципу не первый раз команды строит.
Как бы если вам комфортно, что вам может дать указание любой из цепочки управления над вами, и, что еще веселее, он может дать указание любому в цепочке управления под вами, тем самым нарушая все ваши планы — ну ок, работайте так, кто вам запрещает.
Этого не бывает. Если и найдете такого «главного» — то «тряпка» — самая мягкая характеристика его подчиненных.
Именно так и бывает. Задачи в нормальных ИТ компаниях идут по иерархии. Если пришла задача «сделать фичу X к сроку Y» тимлиду, то это его дело (или дело команды) кто и когда будет ее делать.
Не представляю себе ситуации когда ген.директор придет и будет ставить задачи отдельным сотрудникам через головы всех их руководителей.
Ставить задачу своим подчиненным начальник может и требовать их исполнения (например, если команда забила на фичу X по инициативе тимлида, он может его уволить или заменить на другого), но если он попытается рулить подчиненными своего подчиненного — его вряд ли поймут. Ну или это значит что по факту подчиненный уже отстранен от управления.
Ok. Задача разделилась на 4 подзадачи — одну сделали на Яве, другую на VBA, третью на Паскале, четвертую на Си. Они плохо стыкуются. Виноват главный, который должен был сказать, что все делают на Си (пусть выбор будет сделан подбрасыванием монетки). Бывают и более сложные случаи — я о простейшем.
В статье сказано:
В статье сказано:
3. Будьте арбитром, если команда не может договориться.Но быть арбитром — это командовать всем, не взирая на средневековую иерархию!
Но быть арбитром — это командовать всем, не взирая на средневековую иерархию!
А вот и нет. Быть арбитром — это либо среди своих подчиненных, либо если тебя явно попросили рассудить проблему.
(либо если иерархия в компании настолько сломалась, что надо всех убить и сделать заново)
Ok. Задача разделилась на 4 подзадачи — одну сделали на Яве, другую на VBA, третью на Паскале, четвертую на Си. Они плохо стыкуются. Виноват главный, который должен был сказать, что все делают на Си (пусть выбор будет сделан подбрасыванием монетки). Бывают и более сложные случаи — я о простейшем.
Вы кажется не понимаете о чем вам говорят. Еще раз главный может вызвать своих подчиненных (скажем, проджект менеджеров) и сказать «завтра ваши проекты переходят на Си», те вызывают своих тимлидом и говорят им «ваши команды пишут на Си», те соотвественно говорят тоже девелоперам.
Если один из тимлидов говорит «нет, моя команда будет писать на Дельфи и точка», у его начальников есть возможность либо выслушать его и придти к компромиссу, либо уволить нафиг и поставить другого, кто будет писать на Си. Не должно быть такого, что командой постоянно управляют через голову тимлида и без его согласия.
командовать всем
Это антипатерн управления, командовать надо своей областью. Не должен генерал в бою вмешиваться в управления отдельного взвода, приказы должны приходит на иерархию его уровня.
Не понимаю. Общих обсуждений быть не должно? Жалоб подчиненных на самодурство непосредственного начальника? Контроля сверху? — М.б. нижний начальник друзей и родственников на работу принял и покрывает их незнание за счет остальных?
Не должен генерал в бою вмешиваться в управления отдельного взводаХороший пример. Генерал приказал не штурмовать окопы противника, т.к. собирается нанести по ним арт.удар. И видит, что какой-то взвод пошел на штурм. Приказывает адъютанту — вернуть взвод, а взводного под трибунал.
Приказывает адъютанту — вернуть взвод, а взводного под трибунал.
Это пункт про увольнение/отстранение начальника. И приказ идет к адъютанту от адъютанта к командиру полка, а от командира полка к командиру роты и т.д.
Общих обсуждений быть не должно? Жалоб подчиненных на самодурство непосредственного начальника? Контроля сверху? — М.б. нижний начальник друзей и родственников на работу принял и покрывает их незнание за счет остальных?
Должно быть, если какой-то из нижестоящих начальников провинился, значит его непосредственный руководитель должен разобраться и уволить, если он того заслужил (либо сам будет уволен). Ну не должен гендиректор разбираться что тимлид нанял родственников или нет, для этого у тимлида есть проджект манеджер, скажем.
И приказ идет к адъютанту от адъютанта к командиру полка, а от командира полка к командиру роты и т.д.Нет, конечно! Тем более, что кто-то в этой цепочке «полк-рота» м.б. уже ранен/убит во время боя. Современный адъютант по рации передает приказ радисту взвода, адъютант прошлых веков вскакивал на лошадь, преграждал взводу дорогу и орал «поворачивай (далее не печатно)».
Ну не должен гендиректор разбираться что тимлид нанял родственников или нет, для этого у тимлида есть проджект манеджер, скажем.В каких правилах сказано, что гендиректор должен?
См., нпр.:
директор (он же главный разработчик) лично по три часа собеседует каждого соискателя
В каких правилах сказано, что гендиректор должен?
А в каких правилах сказано, что гендиректор должен сам все контролировать?
Над директором частной фирмы хозяин или акционеры, они ему скажут и накажут, если не так. Над директором гос. учреждения — государство в лице, нпр., министерства. И там скажут и накажут. Исходя из этого каждый директор прежде всего решает сам, что нужно контролировать.
… ну вот все эти милые люди могут и запретить ему куда-то вмешиваться. Во избежание, так сказать, распыления внимания.
И, конечно, каждый директор сам решает, что ему контролировать, а каждый наемный работник сам решает, хочет ли он у такого директора работать.
Обычно «милые люди» не запрещают, а считают, что директор должен и в силах контролировать всё. Каждую копейку. А за неизвестно как потерянный рубль — голову с директора готовы снять. Но могут быть исключения — нпр., попросят проявить деликатность к сыну кого-то. У директоров не много свободы и т.о. они довольно одинаковы, поэтому у наемных работников не большой выбор типов директоров.
На фоне этого утверждения на редкость удивительно то, что ни в одной компании, где я работал, не было описываемого вами типа управления.
Думаю, что Вы его не заметили.
А как бишь можно не заметить того, что тебе кто-то дает указания мимо твоего начальника, или что твоим подчиненным кто-то пытается дать указания мимо тебя?
Нет, конечно!
Значит это плохой генерал, если ему нужно в ручном режиме управлять каждым отдельным солдатом. Тем более вы описываете нестандартную ситуацию (взвод не случается приказов, управление со стороны роты/полка потеряно), в нормальном управлении боем таких ситуаций надо избегать.
кто-то в этой цепочке «полк-рота» м.б. уже ранен/убит во время боя
Я так понимаю, вы не служили? В случае смерти любого командира в армии всегда есть явный алгоритм кто принимает его обязанности. Только полное уничтожение всего полка (включая тот взвод), может убрать эту цепочку.
В каких правилах сказано, что гендиректор должен?
В здравом смысле, если есть иерархическая структура управление через голову промежуточных начальников показывает ее несостоятельность. Если гендиректор вмешивается до уровня отдельного работника, значит никакой иерархии в компании нет, просто есть один начальник-директор и все остальные его подчиненые и все.
Вы сейчас приводите примеры ненормальных и нестандартных ситуаций, да может быть что бухгалтер украл миллион долларов и его дело рассматривает совет директоров и гендиректор, но такие ситуации ненормальные и в обычных деятельности компании они должны быть по возможности минимизированы.
P.S. Вы то говорите как обычно в компаниях бывает, то переводите на директора-самодура, который всем управляет. В нормальной компании в нормальной ситуации и при правильном поставленной иерархии управления такое управление через голову начальников не требуется.
Значит это плохой генерал, если ему нужно в ручном режиме управлять каждым отдельным солдатом.Не солдатом, а взводом. В разных армиях и в разных родах войск кол-во солдат во взводе м.б. разное. И мы не оговаривали численность: армия генерала могла понести серьезные потери, и каждый солдат на счету. Но это был пример для директоров. В небольшой фирме у директора м.б. 100 человек, а средний взвод-отдел — 9 человек. Если 9 человек будут поступать неправильно — это серьезная проблема для такого директора.
Только полное уничтожение всего полка (включая тот взвод), может убрать эту цепочку.Исключая тот взвод. В бою это очень вероятно. Кроме того — фактор времени. Адъютант должен максимально быстро обеспечить исполнение приказа.
значит никакой иерархии в компании нетЗначит только, что нет устаревшей средневековой иерархии сеньор- вассал.
В нормальной компании в нормальной ситуации и при правильном поставленной иерархии управления такое управление через голову начальников не требуется.Оно практически в любой компании. Просто оно не заметно. Замаскировано.
Не солдатом, а взводом. В разных армиях и в разных родах войск кол-во солдат во взводе м.б. разное. И мы не оговаривали численность: армия генерала могла понести серьезные потери, и каждый солдат на счету
Генерал не знает почему взвод идет в ту сторону, возможно ротный отправил его в разведку, возможно в той стороне враг разворачивает скрытные позиции артиллерии. Если генерал начнет отдавать приказы напрямую взводу — он нарушит тот план, который придумал ротный. В нормальной армии приказ отдадут по иерархии и уже ротный сам решит куда идти взводу (случай, когда все командиры убиты/вышли из боя — означает что командир взвода — подчиненный генерала и тогда прямые приказы не нарушают иерархию). А если ротный будет отдавать приказы по своему плану, а генерал их напрямую отменять — вся армия развалиться.
Аналогия: вы едите с водителем и вам кажется что водитель поворачивает не туда, вы схватите руль и начнете его выкручивать сами или все-таки спросите/отдадите приказ водителю?
Помнится, президент Польши погиб скорее всего потому что он или один из высоких начальников решил управлять самолетом «напрямую».
Теперь Вы берете крайние случаи — думаю, что истина посредине. Мы обменялись мнениями, но к единому не пришли. Даже в споре с минимальным числом участников не всегда удается договориться. И это лишний раз доказывает, что даже в теории управлять людьми очень не просто. Не так просто, как в статье, и как прозвучало в обсуждении.
Желаю успехов.
Желаю успехов.
Как собственный подчиненный попал в категорию "третье лицо"?
Как раз в армии приказы вниз через голову тоже не спускают, и это закреплено в уставе (принцип единоначалия). Исключение только для солдат — им любой офицер начальник, но и для этого исключения есть правило — выдавший приказ солдату офицер ОБЯЗАН уведомить непосредственного начальника солдата (ну и тот может приказ отменить).
Приказы отдаются в порядке подчиненности. При крайней необходимости старший начальник может отдать приказ подчиненному, минуя его непосредственного начальника. В таком случае он сообщает об этом непосредственному начальнику подчиненного или подчиненный сам докладывает о получении приказа своему непосредственному начальнику.
Указ Президента Российской Федерации от 10.11.2007 г. № 1495
Об утверждении общевоинских уставов Вооруженных Сил Российской Федерации
Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
Зачем обсуждать со всеми промежуточными? Прямое распоряжение подчиненному, который доведет его до рядового. Надо доверять своим подчиненным, даже если они тоже начальники, а не заниматься ерундой
В других текстах я встречала утверждение «Процесс разработки – не конвейер» в том смысле, что интеллектуальный труд принципиально отличается от заводского конвейера или производства бургеров тем, что полезный выход не пропорционален затраченному времени. Нельзя потратить в 2 раза больше времени и закономерно получить в 2 раза больше продукции.
Под конвейером в разработке я понимаю не монотонный типовой труд отдельного специалиста, а некоторый процесс, который для каждого отдельного сотрудника является интеллектуальной творческой активностью (постарался суть вашей мысли передать), но на более высоком уровне абстракции представляет собой механизм по выдаче результата (я сейчас не говорю про эффективность) для зарабатывания денег.
Извините: не та ветка
>>> Bet365 (ссылку давать не буду, их сайт на территории РФ не открывается)
antizapret.info/site.php?id=225219
Советы понравились. Их бы не забыть.
antizapret.info/site.php?id=225219
Советы понравились. Их бы не забыть.
А ГК ЛАНИТ контрибьютит в open source?
7. Не пытайтесь чинить код и пилить фичи самостоятельно. Вы можете писать код только в одном случае, если надо разрулить конфликт между разработчиками. Всё.
8. Не контролируйте качество и объем работы, которую делают сотрудники.
Не понятно о каком размере команды идет речь, если о тимлиде команды из 5-6 разработчиков, то я бы поспорил, не делать хотя бы код-ревью плохо, вы начинаете с командой переходить в отношения начальник-подчиненные, а не лидер-команда (так перестаете понимать сложности программирования и не следите за качеством кода). В идеале, хорошо на такой роле находить время и на код, ИМХО.
К тому же, если команда знает что ты очень хороший программист, управлять командой будет проще, чем некий чувак, не открывающие IDE.
Если речь идет о ролях ПМа и выше — тогда код писать вообще не стоит, только разве что дома в качестве хобби.
Вот! Именно этого комментария я ждал. Это тот самый «контекст», от которого сильно зависит применимость или неприменимость тех или иных правил из списка уроков. Я абсолютно с вами согласен, что одним из критериев применимости этих правил является размер команды. К сожалению, я не нашел в открытых источниках информацию о размерах технической команды RethinkDB, но думаю, что это была команда больше 5-6 разработчиков.
Полностью согласен с Вами. Для тимлида команды на 5-7 человек я бы 7 пункт переформулировал так:
Помните, что теперь у вас появилось много не менее важных задач, и писать код (тестировать, проводить аналитику, etc) теперь вы будете меньше. Не пытайтесь всё сделать в одиночку, делегируйте задачи. И ни в коем случае не забирайте себе все самые интересные задачи
Мне кажется, что тут речь идет больше о "моральной" стороне вопроса, а уже потом о вечных проблемах вечной нехватки времени на разработку. И, тем более, тут не имелся в виду отказ лидером от участия в код-ревью (вспоминается это: https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/).
Кроме того, что я не очень понимаю, что такое современный "тимлид", всегда казалось, что у любого спеца, который имеет право произнести фразу "моя команда", помимо кучи отнимающих время "деловых" задач — главная, все-таки, — это поднимать уровень этой самой команды.
Поднимать команду (во всех смыслах) — нужно всегда, но в моей практике очень часто получается так, что ты буквально начинаешь проект (стартап) с ребятами, которые заведомо слабее тебя (не случайно же ты лидер), но справедливо считают себя крутыми и уже не яйцами (не случайно же они в твоей команде). И для роста, в таком случае, нет ничего хуже демотивации типа — я звезда, а Вы дурак. Даже если код исправляется (или важный и интересный кусок программы, как внизу указали, пишется) из дома.
И потом, кодить и писать программу — это не одно и тоже. Я, обычно, не пишу ни строчки. Но часто способен быстро сказать где, как, чего и в чем причина. Именно благодаря тому, что держку в голове все более крупными кусками, немного реже остальных сталкиваясь с опасностью заблудиться на самых нижних уровнях башни, я и могу помочь писать программу, а не просто кодить.
И, да, для отвечающего за команду специалиста-программиста, это плохо. Приходится раз в три-пять лет делать перерыв и пытаться писать (что-нибудь очень маленькое, но реальное), чтобы снова прочувствовать ритм современных языков и инструментов (каждый раз матерясь на этапе "настройте окружение").
Вводите стандарты качества работы и философию поведения
Вот это очень опасная штука. Только однажды видел как корпоративная культура прививалась профессионально (и то сыграло нормально, только потому что коллектив был не большой и начальник имел возможность индивидуально и не навязчиво объяснить идеи каждому), во всех остальных (массовых) случаях это выглядело примерно так: рассылка на «Все» с содержанием "С сегодняшнего дня мы внедряем [блаблабла] индивидуальны подход к каждому [блаблабла] здоровайтесь со всеми в коридорах, даже если уже здоровались, улыбайтесь даже в телефонную трубку. Спасибо за внимание".
Не профессиональный подход прививания подобных вещей скорее вызовет раздражение и роптание в коллективе.
Так что я бы трижды подумал перед тем, как пробовать это.
Хитрость, мне кажется, в том, что эта самая "культура" есть всегда. Замечаем мы ее за собой или нет.
Понятно, что растить и поддерживать ее (не дергая) — натуральная необходимость.
А вот "прививать" — можно только если живет себе такая организация деревом (с корой и возможностью отрезать половину будущего ствола за раз). Если что-то более живое — то тут только при жизненной необходимости немного оттянуть конец путем замены совсем некротического. За дорого, хорошим спецом и обязательно подсев на кучу лекарств после операции.
7. Не пытайтесь чинить код и пилить фичи самостоятельно. Вы можете писать код только в одном случае, если надо разрулить конфликт между разработчиками. Всё.Это прям из разряда «вредных советов». Такими темпами можно за два-три года растерять все технические навыки и превратиться в того самого pointy-haired boss.
Для PM/РП это правильный совет. Поддерживать свои технические навыки нужно не принося в жертву проект.
Исключения, разумеется, возможны.
Исключения, разумеется, возможны.
Каждый из вас (@naething, sshmakov) прав в рамках своего контекста. Пример, приведенный naething, на мой взгляд, подходит для контекста, когда речь идет про тимлида небольшой команды в 5-6 человек. Когда можно успевать и код писать, и задачи раздавать и на митингах уровня +1 участвовать пару раз в неделю. Если же мы увеличиваем размер команды до 10 человек и далее, то одному тимлиду становится сложно держать в фокусе, все, что я описал выше. И, если тимлид хочет сохранять техническую компетенцию, то возможны, как мне кажется, такие варианты: А) тимлид начинает работать 24 часа в сутки и быстро перегорает Б) тимлид повышает уровень абстракции по задачам, над которыми работает и переходит на уровень тимлида +1, команде при этом придется повысить эффективность и распределить между собой задачи тимлида В) в иерархию вводится еще один тимлид уровня -1 и часть задач с нашего тимлида уходят туда Г) увеличиваются сроки выполнения по каждой задаче.
Полезно, но… неужели один я читал почти все перечисленное у Фейнмана (рассказ про Проект Манхеттен) и Брукса?
Допускаю, что вы могли читать с автором оригинальной статьи одни и те же книги…
Или, второй вариант, который нельзя не исключить, что идеи уроков пришли в голову автору просто на основе его опыта и его наблюдений. Если допустить, что выводы, которые сделал автор исходя из своего опыта, логичные и разумные, то другой человек, обладающий разумом и логикой, находясь в тех же условиях, сделает аналогичные выводы. Примером может служить история, когда в разных концах мира ученые делали схожие открытия практически одновременно.
Или, второй вариант, который нельзя не исключить, что идеи уроков пришли в голову автору просто на основе его опыта и его наблюдений. Если допустить, что выводы, которые сделал автор исходя из своего опыта, логичные и разумные, то другой человек, обладающий разумом и логикой, находясь в тех же условиях, сделает аналогичные выводы. Примером может служить история, когда в разных концах мира ученые делали схожие открытия практически одновременно.
6. Вводите стандарты качества работы и философию поведения. Увольняйте неадекватных и неквалифицированных сотрудников.
Не принимайте на работу неадекватных и неквалифицированных сотрудников.
11. Авторитет не дается просто так – он зарабатывается принятием правильных решений каждый день.
Тривиально. Известное правило — Уважение нельзя требовать, его можно только заработать.
«Кто в технологической команде должен отвечать за создание и поддержание ценностей, философии поведения, общих правил и стандартов качества работы?»
Спускаться сверху вниз и распространяться на каждом уровне уже как от себя.
Не принимайте на работу неадекватных и неквалифицированных сотрудников.
11. Авторитет не дается просто так – он зарабатывается принятием правильных решений каждый день.
Тривиально. Известное правило — Уважение нельзя требовать, его можно только заработать.
«Кто в технологической команде должен отвечать за создание и поддержание ценностей, философии поведения, общих правил и стандартов качества работы?»
Спускаться сверху вниз и распространяться на каждом уровне уже как от себя.
6. Если продолжить вашу аналогию, то нужно писать код без ошибок, нужно на тестировании не пропускать ошибки, нужно писать только идеальные постановки на разработку и т.д. Работает только в идеальном вакууме. Если серьезно, что за 2-3 часа собеседований не всегда можно определить в достаточной мере уровень адекватности и квалификации человека, хотя, обычно бывает достаточно. Для всего остального существует испытательный срок.
11. Никто не обещал откровений. Автор собрал «лучшие практики» с его точки зрения. То, что в них вошли тривиальные вещи вполне нормально. Больше скажу. Если для вас это тривиально – вы молодец!
11. Никто не обещал откровений. Автор собрал «лучшие практики» с его точки зрения. То, что в них вошли тривиальные вещи вполне нормально. Больше скажу. Если для вас это тривиально – вы молодец!
6. Мое мнение больше складывается из реалий нашей страны. Иногда сложно уволить человека, если он не хочет. Его начальнику придется испытать очень сложный психологический период времени.
Второе мнение не мое. В Яндексе в интервью спросили, много ли они увольняют. «Нет, мы очень строго подходим к приему на работу». Тоже практика, если им верить.
Второе мнение не мое. В Яндексе в интервью спросили, много ли они увольняют. «Нет, мы очень строго подходим к приему на работу». Тоже практика, если им верить.
Какой-то или какие-то пункты из этого перечня стали торпедой для RethinkDB.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
44 урока управления технарями