Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.
В комментариях к статье я бы хотел, чтобы читатели дали свою оценку этим урокам и высказали свое мнение по вопросу, который будет задан в конце статьи.
Да, и еще один, последний момент. Местами формулировки у автора были достаточно заковыристые, поэтому все замечания и предложения по переводу приветствуются в формате личных сообщений.
Итак, поехали.
Добро пожаловать на урок управления технарями. Процесс прикольный, выматывающий, благодарный, но, что более важно, он совершенно новый. Подходы, которые раньше работали, больше не работают. Вам потребуется прокачать новые навыки и в процессе избавиться от некоторых вредных привычек. Вот вам небольшая инструкция, с чего начать.
#Делайте
1. Вовлекайте, воспитывайте, будьте наставником и хранителем талантов. Разговаривайте с вашими инженерами, чтобы понять, что их беспокоит. Если что-то такое есть, пробуйте решить эту проблему сразу же, если можете.
2. Обсуждайте с каждым инженером следующую большую задачу, над которой ему предстоит работать. Это второй важный момент, влияющий на эффективность работы технаря.
3. Будьте арбитром, если команда не может договориться.
4. Будьте источником информации. Будьте в курсе, над чем работает каждый из ваших инженеров и помогайте налаживать связи там, где без вас они никогда не появятся сами.
5. Обеспечьте административную поддержку. Если нужно, раскидывайте задачи в багтрекере, координируйте выпуски версий продукта и постоянно держите руку на пульсе бюрократической машины – она должна работать.
6. Вводите стандарты качества работы и философию поведения. Увольняйте неадекватных и неквалифицированных сотрудников.
#Не делайте
7. Не пытайтесь чинить код и пилить фичи самостоятельно. Вы можете писать код только в одном случае, если надо разрулить конфликт между разработчиками. Всё.
8. Не контролируйте качество и объем работы, которую делают сотрудники. Процесс разработки – не конвейер. (Прим. переводчика – Я бы с этим поспорил. Зависит от проекта. Для каждого отдельного разработчика – это не конвейер, а в масштабах информационной системы, которую создает команда, вполне себе даже.) Если вы влезаете в процесс со своим контролем слишком часто, это означает, что вы не подключили правильных людей или не дали им стимула развиваться.
#Мотивация и культура
9. Вы тот, кто нанимает и увольняет. Все, что происходит в вашей команде – ваша личная ответственность.
10. ИТ – это рынок: люди работают на вас, потому что они в вас верят. Доступ к таланту людей – это привилегия.
11. Авторитет не дается просто так – он зарабатывается принятием правильных решений каждый день.
12. Не принимайте решений, кроме случаев, когда вы вынуждены это сделать. Всегда, если это возможно, позволяйте команде генерить идеи и принимать решения самостоятельно.
13. Обязательно принимайте решения в исключительных ситуациях. Мало вещей на свете так демотивирует команду, как чувство, что проект зашел в тупик.
14. Не убивайте идеи на корню, если в этом нет необходимости. Создавайте среду, в которой каждый сотрудник будет чувствовать себя спокойно и уверенно, предлагая и обсуждая идеи. У ребят «в полях» (прим. переводчика – здесь я сознательно сделал обобщение, так как это касается не только команды разработки) гораздо больше информации, чем у вас. Полагайтесь на вашу команду, и ваши решения будут более осознанными и правильными.
15. Развитие интуиции в принятии правильных решений и создании тесной связи с вашей командой – это 95% успеха на пути к достижению поставленных целей. Множество высокоуровневых фреймворков для организации рабочего процесса ИТ-команды не очень сильно влияют на результат. Фреймворки делают хороших менеджеров лучше, а плохим они только вредят.
#Эмоции и люди
16. Быть руководителем считается престижным в современной культуре, но это такой же навык, как и все остальные. Аура престижности отвлекает – она непостоянна и случайна. Боритесь с чувством, что вы чем-то лучше любого вокруг вас. Чем раньше вы преодолеете чувство превосходства, тем быстрее вы сможете сконцентрироваться на том, чтобы делать свою работу хорошо.
17. Руководителей часто окружает презрение. Не обращайте на это внимание. Люди, которые считают менеджеров бесполезными, не понимают тонкостей процесса создания команды победителей.
18. Если вы чувствуете, что что-то не так, скорее всего, вы правы. Не позволяйте никому довести вас до состояния, когда вы перестанете доверять своему чутью.
19. Если вы ловите себя в процессе отчитывания вашего сотрудника за косяк на работе, скорее всего, вы не правы. Никто не просыпается по утрам, чтобы прийти на работу и специально накосячить. В 95% случаев вы можете решить проблему, просто поговорив с людьми.
20. Большинству людей нелегко делиться своими настоящими эмоциями. Попробуйте поговорить неформально, уловите настроение человека и, если выясните, что что-то не так – исправьте эту проблему, если можете.
21. Ваша команда ждет от вас поведения лидера. Имейте мужество сказать вслух все, как есть, особенно, если все это понимают, но не говорят об этом.
22. Вам платят за выявление и исправление культурных проблем, о существовании которых ваша команда может даже не догадываться. Наберитесь смелости и расскажите о том, что все должны знать, но до сих пор не в курсе.
23. Нанимайте ценных людей и полностью им доверяйте. Введите систему ежемесячных или квартальных отчётов, чтобы оценивать прогресс, по результатам выявляйте тех, с кем надо попрощаться. Не требуйте ежедневных отчётов, такой подход сведет с ума всех, включая вас.
24. Самые разумные аргументы уходят корнями в сильные внутренние эмоции. Ваша эффективность значительно вырастет, если вы научитесь распознавать эти эмоции.
#Конфликты и их разруливание
25. Не бросайтесь судить слишком быстро: на самом деле, вы бываете правы реже, чем думаете. Даже если каждый раз вы уверены в своей правоте, подождите, пока все выскажутся.
26. Как только все выскажутся, подытожьте услышанное настолько четко и понятно, чтобы каждый из участников мог сказать: «Спасибо! С такой стороны я на эту историю даже и не подумал бы посмотреть». Перечислите все, с чем вы согласны, и укажите, что узнали от каждого собеседника. Потом принимайте решение.
27. Приняв решение, претворяйте его в жизнь. Не позволяйте команде топтаться на месте, чтобы не провоцировать недовольство.
28. Возвращайтесь к истории в случае появления новой важной информации.
29. Когда в разногласиях переходят на личности, возникает конфликт.
30. Большинство конфликтов зарождается из-за того, что людям кажется, что их не услышали. Проговорите с каждым ситуацию лично, уточните, что человек об этом думает. Спросите снова. И снова. После этого перескажите, как вы поняли сказанное. В большинстве случаев уже одно это поможет решить проблему.
Источник
31. Если конфликт продолжает разрастаться после того, как вы исчерпали все разумные возможности выслушать каждого и решить проблемы, настаёт время трудных разговоров.
#Трудные разговоры
32. Не откладывайте трудный разговор! Это только усложнит ситуацию.
33. Ничего не предполагайте и не делайте выводов заранее. Не думайте о людях, как о монстрах. Не обвиняйте, не кричите, не очерняйте никого.
34. Прибегайте к «ненасильственному общению» (ННО): это лучший известный мне способ критиковать людей, не оскорбляя их. Да, это звучит как очередная менеджерская уловка, но зато правда работает (обещаю).
35. Не бойтесь говорить о том, что чувствуете и что вам необходимо. Людей привлекает уязвимость других, но собственная — раздражает. Уязвимость – это не слабость.
36. Ожидайте от людей такого же отношения. Если из-за кого-то вы чувствуете себя неловко, высказывая свои мысли и чувства, причина — в них, а не в вас.
#Шероховатости
37. Люди постоянно будут вас провоцировать, чтобы определить ваш предел. Знать, когда надо стоять до конца, а когда отступить – половина выигранной битвы.
38. Однажды кто-нибудь зайдет слишком далеко. Когда это произойдет, четко и твердо сообщите об этом, иначе рискуете потерять авторитет в глазах команды.
39. Обычно фразы «Так делать не надо», произнесенной с серьезным видом, бывает достаточно.
40. Не смейтесь над вещами, которые вам совершенно не кажутся смешными. Не бойтесь проявить именно те эмоции, которые испытываете.
41. Если вы слишком часто повторяете «Так делать не надо» одному и тому же человеку, ваша работа – расстаться с ним.
42. Увольнение – сложный процесс, и вы будете придумывать отговорки, чтобы не доводить до этого (если, конечно, вы не социопат). Если вы поймали себя на том, что постоянно размышляете над чьей-то полезностью для команды, наберитесь смелости и сделайте то, что будет правильно.
43. Не позволяйте другим заставлять вас принимать решения, с которыми вы не согласны. Потом вас назовут ответственным за это, и, между прочим, будут правы. Принимать решения – ваша обязанность.
44. Верьте в себя. Вы не сможете повести в бой отряд кавалеристов, если будете думать, что смешно выглядите на лошади.
ОК. Все уроки закончились, теперь – обещанные вопросы.
С одной стороны – компания RethinkDB закрылась.
С другой стороны – команда RethinkDB создала продукт, который даже после закрытия компании продолжает жить и развиваться в рамках Open Source сообщества. Уверен, что это произошло в том числе благодаря той культуре и той атмосфере, которую удалось создать в команде технарей не без помощи «44 уроков».
Теперь давайте подумаем, если компании открываются и закрываются, продукты создаются, какие-то даже не умирают, а технари все чаще работают не «в компаниях», а «кочуют» между интересными для них проектами, стоит ли вообще компаниям вкладываться в стратегическое развитие технарей, набирать студентов без опыта, прокачивать их, чтобы они потом ушли работать на другой проект? Не правильнее ли собрать команду под проект, сделать дело и разойтись, получив свои кровные и не заморачиваться?
Для себя я определился с ответом на этот вопрос, но, на мой взгляд, тема неоднозначная и сильно зависит, что называется, от контекста.
Хотел бы услышать мнение читателей Хабра на этот счет и заодно попробовать совместно сформулировать критерии того самого «контекста», когда надо применять «44 урока» или что-то подобное, а когда достаточно обойтись старым добрым уроком «кнута и пряника».
Комментарии (83)
SirEdvin
10.10.2017 12:57В дополнении к вопросу предыдущему коментатору — а какие есть "технари", которые не "инженеры"?
91koff Автор
10.10.2017 13:26+1Автор под «инженерами» имел в виду в большей степени «инженеров-разработчиков», так как руководил командой, которая создавала базу данных.
third112
10.10.2017 14:01а какие есть «технари», которые не «инженеры»?
Научные работники, нпр., в сферах математики, физики, CS и т.д. Или здесь речь только о разработках, где таких не требуется?SirEdvin
10.10.2017 14:02+1Или здесь речь только о разработках, где таких не требуется?
ИТ – это рынок: люди работают на вас, потому что они в вас верят. Доступ к таланту людей – это привилегия.Как я понимаю, похоже на то.
91koff Автор
10.10.2017 14:39+1Если научные работники, физики (на самом деле, здесь можно перечислять профессии и дальше) и т.д. непосредственно заняты в работе по созданию некоторой информационной системы или программного продукта (пишут алгоритмы, код, создают железо, на котором все это будет работать), то они тоже входят в это понятие в том его значении, которое имелось в виду в «уроках». Хотя, в общем виде, на мой взгляд, они больше относятся к другой важной группе людей, которые принимают участие в создании систем и ПО: консультантов, бизнес аналитиков, бизнес архитекторов и др. – людей, которые задают функциональные характеристики продукта.
third112
10.10.2017 14:44Тогда возникает вопрос: верно ли делить одну команду на 2 группы?
91koff Автор
10.10.2017 17:29+1Команда общая. Уроки выше только для технарей. Так решил автор «уроков».
Как мне кажется, эти уроки применимы, отчасти и для команды бизнес-аналитиков, бизнес-архитекторов и пр., но чтобы об этом заявлять, надо на каждый пункт посмотреть под призмой «бизнес» команды.
sshmakov
10.10.2017 13:45+68. Не контролируйте качество и объем работы, которую делают сотрудники. Процесс разработки – не конвейер. (Прим. переводчика – Я бы с этим поспорил. Зависит от проекта. Для каждого отдельного разработчика – это не конвейер, а в масштабах информационной системы, которую создает команда, вполне себе даже.) Если вы влезаете в процесс со своим контролем слишком часто, это означает, что вы не подключили правильных людей или не дали им стимула развиваться.
А я бы не спорил. Если у вас повышенные требования к качеству кода, то введите code review. Если у вас есть вопросы к совершаемому объему работы (и только если эти вопросы действительно есть и критичны), то поручите более опытному товарищу помочь, потом у него узнайте, какие знания и умения нужно подтянуть вашему разработчику. Но не надо контролировать постоянно — так вы разрушаете доверие.
17. Руководителей часто окружает презрение. Не обращайте на это внимание. Люди, которые считают менеджеров бесполезными, не понимают тонкостей процесса создания команды победителей.
А вот тут я бы поспорил. Презрение окружает руководителей, занимающихся ерундой, неквалифицированных, грубых, напыщенных (нужное подчеркнуть). Руководители, занимающиеся своей командой, решающие, а не создающие проблемы, обеспечивающие фронт работ и достойную компенсацию — они пользуются заслуженным уважением.91koff Автор
10.10.2017 14:331) Я спорил не с фразой про контроль, а с тем, что «Процесс разработки – не конвейер». С вашими предложениями абсолютно согласен. Code review и наличие в команде более опытных товарищей, которые помогают молодым специалистам – это важные критерии зрелости проекта и уровня команды соответственно.
2) Думаю, что автор уроков имел в виду скорее то, что не все сотрудники осознают важность роли руководителя в команде, особенно тех руководителей, которые стоят по вертикали на уровне выше, чем +1 от сотрудника. Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют. При этом, согласен с вами, зачастую этому способствуют и те сценарии поведения руководителей, о которых вы написали.sshmakov
10.10.2017 14:47+1Отсюда возникает ощущение, что все делают они, а там «наверху» непонятно, чем занимаются, но приходят и что-то требуют.
Если руководитель +1 приходит и что-то требует от сотрудника — то это несколько странный руководитель. Стоит соблюдать принцип «вассал моего вассала не мой вассал».third112
10.10.2017 15:01Сложный вопрос. Исторически вассалитет устарел. Странно будет, если в рамках одной современной фирмы или учреждения директор не будет иметь прав говорить с рядовыми сотрудниками. Как еще он сможет выявить негодных руководителей среднего звена?
lair
10.10.2017 15:05+3Говорить — можно. Ставить задачи (без явного разрешения промежуточного руководителя) — нельзя.
(это верно только для иерархических структур, конечно)
third112
10.10.2017 16:10-1Зав.отделом устраивает обсуждение текущего хода проекта. Все собрались, и рядовой программист докладывает: «для решения данной подзадачи литературный сетевой поиск выявил подходы А, Б, В. Мы использовали А». Зав.отделом: «почему не Б? Выглядит гораздо привлекательнее.» Рядовой, кивает на непосредственного начальника: «Иван Иваныч так сказал...» Иван Иваныч: «ну, в прошлом и позапрошлом проекте этот подход себя зарекомендовал...» Зав.отделом, рядовому: «У меня личная просьба, попробуйте Б и завтра лично мне доложите».
Зав.отделом не прав?lair
10.10.2017 16:15+1Не прав. Рядовой с этого момента не считается со мнением непосредственного начальника, а тот начинает считать его любимчиком завотделом (это утрируя, конечно). Правильно — это заву обсудить с непосредственным начальником выбор подходов, и убедить того попробовать, чтобы тот поставил эту задачу нижестоящим.
third112
10.10.2017 16:25Однако в наше время в большинстве стран мира укоренилась армейская дисциплина, когда нижестоящий начальник просит разрешения присутствующего вышестоящего обратиться к третьему лицу, а не наоборот — вышестоящему не требуется просить разрешения. Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
lair
10.10.2017 16:28Однако в наше время в большинстве стран мира укоренилась армейская дисциплина, когда нижестоящий начальник просит разрешения присутствующего вышестоящего обратиться к третьему лицу, а не наоборот — вышестоящему не требуется просить разрешения.
Укоренилась где? В армии? Возможно, ничего про это не знаю.
А вот в корпоративной среде это некорректно, потому что нарушает иерархию.
Бесспорно тут только то, что если большой начальник будет со всеми промежуточными обсуждать и объяснять, что должен сделать один рядовой — никакого времени не хватит.
Именно поэтому большому начальнику не надо объяснять, что должен делать конкретный рядовой. Делегируйте.
third112
10.10.2017 16:38-1Укоренилась где? В армии?
В НИИ, в гос.учреждениях и в частных компаниях. Член совета директоров говорит секретарше отделения «принесите кофе, pls» или «принесите отчет за январь прошлого года», и найдется ли зав. отделением, который не будет кивать, а возразит, что это его секретарша?.. Я такого не видел. А Вы?
А вот в корпоративной среде это некорректно, потому что нарушает иерархию.
Тут речь не про корпоративную среду? А про какую?lair
10.10.2017 16:57+2Член совета директоров говорит секретарше отделения «принесите кофе, pls» или «принесите отчет за январь прошлого года», и найдется ли зав. отделением, который не будет кивать, а возразит, что это его секретарша?.. Я такого не видел. А Вы?
А я видел людей, которые формулируют аналогичную просьбу как "можно кофе" — и уже принимающая сторона решает эту проблему своим способом.
А главное, есть некоторая разница между секретаршами и линейными сотрудниками.
Тут речь не про корпоративную среду? А про какую?
Тут речь как раз про корпоративную среду.
third112
10.10.2017 21:01-2Именно поэтому большому начальнику не надо объяснять, что должен делать конкретный рядовой. Делегируйте.
Совершенно нереально, когда решение большого начальника касается каждого рядового. Выбор технологии, инструмента, языка.lair
10.10.2017 21:16+2Как раз совершенно реально. Выбрали технологию — довели до начальников следующего уровня, те распространят дальше. Нет никакой необходимости бегать за каждым исполнителем.
third112
10.10.2017 22:33-2Нет! Большой начальник приказал — переходим на новый язык Х и не за кем не бегает. При этом начальник ниже не сможет сказать: как писали на Васике — так и продолжим. При вассалитете было не так: герцог приказал перейти на мушкеты, а мелкий барон говорит: как стреляли из луков — так и будем стрелять, и герцог был не в праве вмешаться.
lair
10.10.2017 22:38+1А просто не надо воспринимать аналогию буквально, вот и все.
third112
10.10.2017 22:41-3Тогда не надо бросаться словами:
«вассал моего вассала не мой вассал»
И одобрять столь небуквальное…lair
10.10.2017 22:47+2А я и не бросался такими словами. Я просто объяснил вам, как этот принцип надо понимать применительно к нынешней иерархии управления.
(и спорили вы, что характерно, именно с моим объяснением)
third112
10.10.2017 22:52-2Не объяснили. Объяснения нет:
не надо воспринимать аналогию буквально
— не объяснение. На этом закончу.lair
10.10.2017 22:54+1Не объяснили. Объяснения нет:
Эм, вот же: "Ставить задачи (без явного разрешения промежуточного руководителя) — нельзя."
third112
10.10.2017 22:59-2Этого не бывает. Если и найдете такого «главного» — то «тряпка» — самая мягкая характеристика от его подчиненных.
lair
10.10.2017 23:06+1У кого не бывает, а кто по такому принципу не первый раз команды строит.
Как бы если вам комфортно, что вам может дать указание любой из цепочки управления над вами, и, что еще веселее, он может дать указание любому в цепочке управления под вами, тем самым нарушая все ваши планы — ну ок, работайте так, кто вам запрещает.
third112
10.10.2017 23:11-1Предъявите примеры успешных команд, построенных по такому принципу.
Я не видел спора о выборе языка/технологии, который не инфинитен.lair
10.10.2017 23:13Предъявите примеры успешных команд, построенных по такому принципу.
Мой отдел разработки на предыдущем месте работы.
Я не видел спора о выборе языка/технологии, который не инфинитен.
И какое это имеет отношение к делу?
vedenin1980
10.10.2017 23:11-1Этого не бывает. Если и найдете такого «главного» — то «тряпка» — самая мягкая характеристика его подчиненных.
Именно так и бывает. Задачи в нормальных ИТ компаниях идут по иерархии. Если пришла задача «сделать фичу X к сроку Y» тимлиду, то это его дело (или дело команды) кто и когда будет ее делать.
Не представляю себе ситуации когда ген.директор придет и будет ставить задачи отдельным сотрудникам через головы всех их руководителей.
Ставить задачу своим подчиненным начальник может и требовать их исполнения (например, если команда забила на фичу X по инициативе тимлида, он может его уволить или заменить на другого), но если он попытается рулить подчиненными своего подчиненного — его вряд ли поймут. Ну или это значит что по факту подчиненный уже отстранен от управления.third112
10.10.2017 23:18-1Ok. Задача разделилась на 4 подзадачи — одну сделали на Яве, другую на VBA, третью на Паскале, четвертую на Си. Они плохо стыкуются. Виноват главный, который должен был сказать, что все делают на Си (пусть выбор будет сделан подбрасыванием монетки). Бывают и более сложные случаи — я о простейшем.
В статье сказано:
3. Будьте арбитром, если команда не может договориться.
Но быть арбитром — это командовать всем, не взирая на средневековую иерархию!lair
10.10.2017 23:27+2Но быть арбитром — это командовать всем, не взирая на средневековую иерархию!
А вот и нет. Быть арбитром — это либо среди своих подчиненных, либо если тебя явно попросили рассудить проблему.
(либо если иерархия в компании настолько сломалась, что надо всех убить и сделать заново)
vedenin1980
10.10.2017 23:29-1Ok. Задача разделилась на 4 подзадачи — одну сделали на Яве, другую на VBA, третью на Паскале, четвертую на Си. Они плохо стыкуются. Виноват главный, который должен был сказать, что все делают на Си (пусть выбор будет сделан подбрасыванием монетки). Бывают и более сложные случаи — я о простейшем.
Вы кажется не понимаете о чем вам говорят. Еще раз главный может вызвать своих подчиненных (скажем, проджект менеджеров) и сказать «завтра ваши проекты переходят на Си», те вызывают своих тимлидом и говорят им «ваши команды пишут на Си», те соотвественно говорят тоже девелоперам.
Если один из тимлидов говорит «нет, моя команда будет писать на Дельфи и точка», у его начальников есть возможность либо выслушать его и придти к компромиссу, либо уволить нафиг и поставить другого, кто будет писать на Си. Не должно быть такого, что командой постоянно управляют через голову тимлида и без его согласия.
командовать всем
Это антипатерн управления, командовать надо своей областью. Не должен генерал в бою вмешиваться в управления отдельного взвода, приказы должны приходит на иерархию его уровня.third112
10.10.2017 23:34-2Не понимаю. Общих обсуждений быть не должно? Жалоб подчиненных на самодурство непосредственного начальника? Контроля сверху? — М.б. нижний начальник друзей и родственников на работу принял и покрывает их незнание за счет остальных?
third112
10.10.2017 23:44-2Не должен генерал в бою вмешиваться в управления отдельного взвода
Хороший пример. Генерал приказал не штурмовать окопы противника, т.к. собирается нанести по ним арт.удар. И видит, что какой-то взвод пошел на штурм. Приказывает адъютанту — вернуть взвод, а взводного под трибунал.vedenin1980
10.10.2017 23:55+1Приказывает адъютанту — вернуть взвод, а взводного под трибунал.
Это пункт про увольнение/отстранение начальника. И приказ идет к адъютанту от адъютанта к командиру полка, а от командира полка к командиру роты и т.д.
Общих обсуждений быть не должно? Жалоб подчиненных на самодурство непосредственного начальника? Контроля сверху? — М.б. нижний начальник друзей и родственников на работу принял и покрывает их незнание за счет остальных?
Должно быть, если какой-то из нижестоящих начальников провинился, значит его непосредственный руководитель должен разобраться и уволить, если он того заслужил (либо сам будет уволен). Ну не должен гендиректор разбираться что тимлид нанял родственников или нет, для этого у тимлида есть проджект манеджер, скажем.third112
11.10.2017 00:11-2И приказ идет к адъютанту от адъютанта к командиру полка, а от командира полка к командиру роты и т.д.
Нет, конечно! Тем более, что кто-то в этой цепочке «полк-рота» м.б. уже ранен/убит во время боя. Современный адъютант по рации передает приказ радисту взвода, адъютант прошлых веков вскакивал на лошадь, преграждал взводу дорогу и орал «поворачивай (далее не печатно)».
Ну не должен гендиректор разбираться что тимлид нанял родственников или нет, для этого у тимлида есть проджект манеджер, скажем.
В каких правилах сказано, что гендиректор должен?
См., нпр.:директор (он же главный разработчик) лично по три часа собеседует каждого соискателя
lair
11.10.2017 00:24В каких правилах сказано, что гендиректор должен?
А в каких правилах сказано, что гендиректор должен сам все контролировать?
third112
11.10.2017 00:29-2Над директором частной фирмы хозяин или акционеры, они ему скажут и накажут, если не так. Над директором гос. учреждения — государство в лице, нпр., министерства. И там скажут и накажут. Исходя из этого каждый директор прежде всего решает сам, что нужно контролировать.
lair
11.10.2017 00:31+1… ну вот все эти милые люди могут и запретить ему куда-то вмешиваться. Во избежание, так сказать, распыления внимания.
И, конечно, каждый директор сам решает, что ему контролировать, а каждый наемный работник сам решает, хочет ли он у такого директора работать.
third112
11.10.2017 00:43-1Обычно «милые люди» не запрещают, а считают, что директор должен и в силах контролировать всё. Каждую копейку. А за неизвестно как потерянный рубль — голову с директора готовы снять. Но могут быть исключения — нпр., попросят проявить деликатность к сыну кого-то. У директоров не много свободы и т.о. они довольно одинаковы, поэтому у наемных работников не большой выбор типов директоров.
lair
11.10.2017 00:46На фоне этого утверждения на редкость удивительно то, что ни в одной компании, где я работал, не было описываемого вами типа управления.
third112
11.10.2017 01:07-2Думаю, что Вы его не заметили.
lair
11.10.2017 01:13А как бишь можно не заметить того, что тебе кто-то дает указания мимо твоего начальника, или что твоим подчиненным кто-то пытается дать указания мимо тебя?
third112
11.10.2017 01:19-2М.б. не было такой необходимости.
lair
11.10.2017 01:22+1Не было необходимости — значит, не было и управления. А вы говорите, выбора нет.
Другое дело, что я точно знаю, что как минимум в одной компании это правило явно озвучивалось, так что дело не только в "не было необходимости".
vedenin1980
11.10.2017 00:39+1Нет, конечно!
Значит это плохой генерал, если ему нужно в ручном режиме управлять каждым отдельным солдатом. Тем более вы описываете нестандартную ситуацию (взвод не случается приказов, управление со стороны роты/полка потеряно), в нормальном управлении боем таких ситуаций надо избегать.
кто-то в этой цепочке «полк-рота» м.б. уже ранен/убит во время боя
Я так понимаю, вы не служили? В случае смерти любого командира в армии всегда есть явный алгоритм кто принимает его обязанности. Только полное уничтожение всего полка (включая тот взвод), может убрать эту цепочку.
В каких правилах сказано, что гендиректор должен?
В здравом смысле, если есть иерархическая структура управление через голову промежуточных начальников показывает ее несостоятельность. Если гендиректор вмешивается до уровня отдельного работника, значит никакой иерархии в компании нет, просто есть один начальник-директор и все остальные его подчиненые и все.
Вы сейчас приводите примеры ненормальных и нестандартных ситуаций, да может быть что бухгалтер украл миллион долларов и его дело рассматривает совет директоров и гендиректор, но такие ситуации ненормальные и в обычных деятельности компании они должны быть по возможности минимизированы.
P.S. Вы то говорите как обычно в компаниях бывает, то переводите на директора-самодура, который всем управляет. В нормальной компании в нормальной ситуации и при правильном поставленной иерархии управления такое управление через голову начальников не требуется.third112
11.10.2017 01:04-2Значит это плохой генерал, если ему нужно в ручном режиме управлять каждым отдельным солдатом.
Не солдатом, а взводом. В разных армиях и в разных родах войск кол-во солдат во взводе м.б. разное. И мы не оговаривали численность: армия генерала могла понести серьезные потери, и каждый солдат на счету. Но это был пример для директоров. В небольшой фирме у директора м.б. 100 человек, а средний взвод-отдел — 9 человек. Если 9 человек будут поступать неправильно — это серьезная проблема для такого директора.
Только полное уничтожение всего полка (включая тот взвод), может убрать эту цепочку.
Исключая тот взвод. В бою это очень вероятно. Кроме того — фактор времени. Адъютант должен максимально быстро обеспечить исполнение приказа.
значит никакой иерархии в компании нет
Значит только, что нет устаревшей средневековой иерархии сеньор- вассал.
В нормальной компании в нормальной ситуации и при правильном поставленной иерархии управления такое управление через голову начальников не требуется.
Оно практически в любой компании. Просто оно не заметно. Замаскировано.vedenin1980
11.10.2017 01:17-1Не солдатом, а взводом. В разных армиях и в разных родах войск кол-во солдат во взводе м.б. разное. И мы не оговаривали численность: армия генерала могла понести серьезные потери, и каждый солдат на счету
Генерал не знает почему взвод идет в ту сторону, возможно ротный отправил его в разведку, возможно в той стороне враг разворачивает скрытные позиции артиллерии. Если генерал начнет отдавать приказы напрямую взводу — он нарушит тот план, который придумал ротный. В нормальной армии приказ отдадут по иерархии и уже ротный сам решит куда идти взводу (случай, когда все командиры убиты/вышли из боя — означает что командир взвода — подчиненный генерала и тогда прямые приказы не нарушают иерархию). А если ротный будет отдавать приказы по своему плану, а генерал их напрямую отменять — вся армия развалиться.
Аналогия: вы едите с водителем и вам кажется что водитель поворачивает не туда, вы схватите руль и начнете его выкручивать сами или все-таки спросите/отдадите приказ водителю?
Помнится, президент Польши погиб скорее всего потому что он или один из высоких начальников решил управлять самолетом «напрямую».third112
11.10.2017 01:27-2Теперь Вы берете крайние случаи — думаю, что истина посредине. Мы обменялись мнениями, но к единому не пришли. Даже в споре с минимальным числом участников не всегда удается договориться. И это лишний раз доказывает, что даже в теории управлять людьми очень не просто. Не так просто, как в статье, и как прозвучало в обсуждении.
Желаю успехов.
rkosolapov
13.10.2017 11:18Как раз в армии приказы вниз через голову тоже не спускают, и это закреплено в уставе (принцип единоначалия). Исключение только для солдат — им любой офицер начальник, но и для этого исключения есть правило — выдавший приказ солдату офицер ОБЯЗАН уведомить непосредственного начальника солдата (ну и тот может приказ отменить).
third112
13.10.2017 14:07Приказы отдаются в порядке подчиненности. При крайней необходимости старший начальник может отдать приказ подчиненному, минуя его непосредственного начальника. В таком случае он сообщает об этом непосредственному начальнику подчиненного или подчиненный сам докладывает о получении приказа своему непосредственному начальнику.
Указ Президента Российской Федерации от 10.11.2007 г. № 1495
Об утверждении общевоинских уставов Вооруженных Сил Российской Федерации
Katemare
10.10.2017 20:44В других текстах я встречала утверждение «Процесс разработки – не конвейер» в том смысле, что интеллектуальный труд принципиально отличается от заводского конвейера или производства бургеров тем, что полезный выход не пропорционален затраченному времени. Нельзя потратить в 2 раза больше времени и закономерно получить в 2 раза больше продукции.
91koff Автор
10.10.2017 20:48+1Под конвейером в разработке я понимаю не монотонный типовой труд отдельного специалиста, а некоторый процесс, который для каждого отдельного сотрудника является интеллектуальной творческой активностью (постарался суть вашей мысли передать), но на более высоком уровне абстракции представляет собой механизм по выдаче результата (я сейчас не говорю про эффективность) для зарабатывания денег.
HiMiC
10.10.2017 18:10>>> Bet365 (ссылку давать не буду, их сайт на территории РФ не открывается)
antizapret.info/site.php?id=225219
Советы понравились. Их бы не забыть.91koff Автор
10.10.2017 20:59Первый вариант ответа на первый вопрос в конце статьи поможет вам решить эту задачу.
vedenin1980
10.10.2017 20:18+27. Не пытайтесь чинить код и пилить фичи самостоятельно. Вы можете писать код только в одном случае, если надо разрулить конфликт между разработчиками. Всё.
8. Не контролируйте качество и объем работы, которую делают сотрудники.
Не понятно о каком размере команды идет речь, если о тимлиде команды из 5-6 разработчиков, то я бы поспорил, не делать хотя бы код-ревью плохо, вы начинаете с командой переходить в отношения начальник-подчиненные, а не лидер-команда (так перестаете понимать сложности программирования и не следите за качеством кода). В идеале, хорошо на такой роле находить время и на код, ИМХО.
К тому же, если команда знает что ты очень хороший программист, управлять командой будет проще, чем некий чувак, не открывающие IDE.
Если речь идет о ролях ПМа и выше — тогда код писать вообще не стоит, только разве что дома в качестве хобби.91koff Автор
10.10.2017 20:55+1Вот! Именно этого комментария я ждал. Это тот самый «контекст», от которого сильно зависит применимость или неприменимость тех или иных правил из списка уроков. Я абсолютно с вами согласен, что одним из критериев применимости этих правил является размер команды. К сожалению, я не нашел в открытых источниках информацию о размерах технической команды RethinkDB, но думаю, что это была команда больше 5-6 разработчиков.
greblin
11.10.2017 12:43+1Полностью согласен с Вами. Для тимлида команды на 5-7 человек я бы 7 пункт переформулировал так:
Помните, что теперь у вас появилось много не менее важных задач, и писать код (тестировать, проводить аналитику, etc) теперь вы будете меньше. Не пытайтесь всё сделать в одиночку, делегируйте задачи. И ни в коем случае не забирайте себе все самые интересные задачи
africaunite
12.10.2017 03:57-1Мне кажется, что тут речь идет больше о "моральной" стороне вопроса, а уже потом о вечных проблемах вечной нехватки времени на разработку. И, тем более, тут не имелся в виду отказ лидером от участия в код-ревью (вспоминается это: https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/).
Кроме того, что я не очень понимаю, что такое современный "тимлид", всегда казалось, что у любого спеца, который имеет право произнести фразу "моя команда", помимо кучи отнимающих время "деловых" задач — главная, все-таки, — это поднимать уровень этой самой команды.
Поднимать команду (во всех смыслах) — нужно всегда, но в моей практике очень часто получается так, что ты буквально начинаешь проект (стартап) с ребятами, которые заведомо слабее тебя (не случайно же ты лидер), но справедливо считают себя крутыми и уже не яйцами (не случайно же они в твоей команде). И для роста, в таком случае, нет ничего хуже демотивации типа — я звезда, а Вы дурак. Даже если код исправляется (или важный и интересный кусок программы, как внизу указали, пишется) из дома.
И потом, кодить и писать программу — это не одно и тоже. Я, обычно, не пишу ни строчки. Но часто способен быстро сказать где, как, чего и в чем причина. Именно благодаря тому, что держку в голове все более крупными кусками, немного реже остальных сталкиваясь с опасностью заблудиться на самых нижних уровнях башни, я и могу помочь писать программу, а не просто кодить.
И, да, для отвечающего за команду специалиста-программиста, это плохо. Приходится раз в три-пять лет делать перерыв и пытаться писать (что-нибудь очень маленькое, но реальное), чтобы снова прочувствовать ритм современных языков и инструментов (каждый раз матерясь на этапе "настройте окружение").
ultraElephant
11.10.2017 03:14+1Вводите стандарты качества работы и философию поведения
Вот это очень опасная штука. Только однажды видел как корпоративная культура прививалась профессионально (и то сыграло нормально, только потому что коллектив был не большой и начальник имел возможность индивидуально и не навязчиво объяснить идеи каждому), во всех остальных (массовых) случаях это выглядело примерно так: рассылка на «Все» с содержанием "С сегодняшнего дня мы внедряем [блаблабла] индивидуальны подход к каждому [блаблабла] здоровайтесь со всеми в коридорах, даже если уже здоровались, улыбайтесь даже в телефонную трубку. Спасибо за внимание".
Не профессиональный подход прививания подобных вещей скорее вызовет раздражение и роптание в коллективе.
Так что я бы трижды подумал перед тем, как пробовать это.africaunite
12.10.2017 04:18-1Хитрость, мне кажется, в том, что эта самая "культура" есть всегда. Замечаем мы ее за собой или нет.
Понятно, что растить и поддерживать ее (не дергая) — натуральная необходимость.
А вот "прививать" — можно только если живет себе такая организация деревом (с корой и возможностью отрезать половину будущего ствола за раз). Если что-то более живое — то тут только при жизненной необходимости немного оттянуть конец путем замены совсем некротического. За дорого, хорошим спецом и обязательно подсев на кучу лекарств после операции.
naething
11.10.2017 08:15+17. Не пытайтесь чинить код и пилить фичи самостоятельно. Вы можете писать код только в одном случае, если надо разрулить конфликт между разработчиками. Всё.
Это прям из разряда «вредных советов». Такими темпами можно за два-три года растерять все технические навыки и превратиться в того самого pointy-haired boss.sshmakov
11.10.2017 09:03+1Для PM/РП это правильный совет. Поддерживать свои технические навыки нужно не принося в жертву проект.
Исключения, разумеется, возможны.91koff Автор
13.10.2017 19:13Каждый из вас (@naething, sshmakov) прав в рамках своего контекста. Пример, приведенный naething, на мой взгляд, подходит для контекста, когда речь идет про тимлида небольшой команды в 5-6 человек. Когда можно успевать и код писать, и задачи раздавать и на митингах уровня +1 участвовать пару раз в неделю. Если же мы увеличиваем размер команды до 10 человек и далее, то одному тимлиду становится сложно держать в фокусе, все, что я описал выше. И, если тимлид хочет сохранять техническую компетенцию, то возможны, как мне кажется, такие варианты: А) тимлид начинает работать 24 часа в сутки и быстро перегорает Б) тимлид повышает уровень абстракции по задачам, над которыми работает и переходит на уровень тимлида +1, команде при этом придется повысить эффективность и распределить между собой задачи тимлида В) в иерархию вводится еще один тимлид уровня -1 и часть задач с нашего тимлида уходят туда Г) увеличиваются сроки выполнения по каждой задаче.
Gryphon88
11.10.2017 15:41+1Полезно, но… неужели один я читал почти все перечисленное у Фейнмана (рассказ про Проект Манхеттен) и Брукса?
91koff Автор
13.10.2017 19:25Допускаю, что вы могли читать с автором оригинальной статьи одни и те же книги…
Или, второй вариант, который нельзя не исключить, что идеи уроков пришли в голову автору просто на основе его опыта и его наблюдений. Если допустить, что выводы, которые сделал автор исходя из своего опыта, логичные и разумные, то другой человек, обладающий разумом и логикой, находясь в тех же условиях, сделает аналогичные выводы. Примером может служить история, когда в разных концах мира ученые делали схожие открытия практически одновременно.
lair
А поясните, пожалуйста, кого же именно вы понимаете под "технарем"?
91koff Автор
Под «технарями» я понимаю людей, которые участвуют в работе с программным обеспечением и/или информационными системами на всех этапах от создания до эксплуатации, и всего, что с этим связано. Например, к «технарям» я отношу инженеров, разработчиков, архитекторов, системных аналитиков, системных администраторов, специалистов по информационной безопасности, тестировщиков и т.д.
lair
То есть это профессия, а не образование?
91koff Автор
Я бы сказал, что это роль в рамках некоторого процесса.
Botchal
Что Вы имеете в виду под образованием? Документ об окончании или полученные знания?
lair
Имеющиеся знания и навыки.