Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.
Немного об оригинальном тексте. Статья была написана в 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 урока» или что-то подобное, а когда достаточно обойтись старым добрым уроком «кнута и пряника».
Автор: 91koff
