[Перевод] Выученная беспомощность в разработке ПО
Лучше зажечь одну свечку, чем проклинать темноту.
За последние 24 часа, две мои статьи «Почему ваш программист просто хочет кодировать» и «Менеджерам пора проснуться» прочитаны более 96 000 раз на Medium и получили более 900 комментариев на Reddit.
Похоже, проблема серьёзнее, чем я думал.
Да, в технологических компаниях есть плохие менеджеры. И да, я жёстко обошёлся, возложив на них вину за апатию разработчиков.
Но я хочу помочь разработчикам, которые чувствуют себя разочарованными, бесправными или лишёнными права голоса. Ведь именно вы разместили подавляющее большинство комментариев, описывающих ужасные условия и ужасное управление. Вы подняли руку, чтобы сказать: «Мне это надоело».
Начиная с сегодняшнего дня изменим это.
Мы как программисты выбрали такое поведение.
Терпя это, мы показываем менеджерам, как можно к нам относиться.
Будем реалистами. Мы не можем изменить всё в одиночку, но у нас больше силы, чем мы думаем.
Вот несколько действенных способов, как вы можете радикально изменить своё рабочее окружение.
Признать, что менеджер пытается хорошо работать.
Скорее всего, босс раньше инженером, как и вы. Технические компании исповедуют принцип Питера и повышают людей в должности до тех пор, пока те не терпят неудачу.
Плохо и то, что ваш менеджер, вероятно, прошёл меньшее обучение для своей работы, чем ваш бариста (76% менеджеров обучались менее 8 часов обучения для работы на своей должности!)
Никто не рождается со знанием, как управлять или руководить. Фраза «прирождённый лидер» — это туфта.
Многие технические менеджеры сомневаются, что они «созданы» для этой работы. Честно говоря, большинство из них хотели бы по-прежнему программировать!
Переход от программиста к менеджеру труден, поэтому давайте для начала оставим их в покое. Да, они должны измениться. Но кто не должен? Никто не идеален.
Попробуем найти способы изменить обстановку, чтобы все мы могли продвинуться вперёд.
Ваш менеджер работает в плохой обстановке (и вы тоже!)
И вы, и ваш начальник — часть общей среды с её проблемами. Скорее всего, не они создали такие условия. На самом деле они тоже чувствуют себя заложниками сложившегося положения.
Технологические лидеры почти никогда не контролируют…
- Над какими фичами/багами работают программисты.
- Сколько платят разработчикам.
- Продолжительность их отпуска.
- Какие стимулы можно предложить программистам.
- Где сидят разработчики, какие у них рабочие компьютеры.
- Когда программисты могут работать удалённо.
- Какие используются языки и фреймворки.
Компания, культура и окружающая среда здесь решают. И это адски расстраивает вашего начальника.
Признайте, что НИКТО не останавливает вас, но ОКРУЖАЮЩАЯ СРЕДА способна на это.
Вы и ваш менеджер — жертвы постороннего явления: плохой обстановки. Её можно определить по определённым признакам, как и плохой код.
Некоторые признаки плохой среды, которые можно заметить:
- Люди говорят о том, что бы они улучшили, если бы контролировали ситуацию.
- Отсутствие интереса к ценности проекта и результатам работы.
- Ощущение бессилия в улучшении ситуации.
- Ощущение, что «кто угодно может облажаться, но ответственность несём мы».
- Продолжение работы «как обычно» из-за страха ошибиться (и быть наказанным).
- Много разговоров об изменениях; очень мало реальных изменений.
- И многое другое…
Я работал в репрессивных условиях, и это очень угнетает. Словно ты не можешь дышать, чувствуешь досаду и злость.
Лидерство не даётся, оно приобретается.
Подумай о людях, которые рядом. Есть ли среди них тот, кого можно назвать неназначенным, неформальным лидером? (Компании назначают менеджеров, но сами лидеры как будто появляются повсюду).
Внимательно следите за ними. Что они делают иначе? Почему по-вашему они это делают? Как другие реагируют на них?
На своей первой работе я заметил, что один сотрудник, Милинд, действовал немного иначе, чем другие. Он был неформальным лидером в команде, хотя я не сразу это понял.
Например, Милинд…
- Задавал ключевые вопросы о том, ПОЧЕМУ выбран конкретный подход.
- Признавался в своём непонимании во время группового обсуждения и просил начальника более чётко разъяснить идеи.
- Никогда не колебался, чтобы вызвать клиента для уточнения или даже обсуждения требования.
- Был чрезвычайно сосредоточен на выпуске реального программного обеспечения, а не на обсуждения инструментария.
- Настаивал на том, что мы понимаем истинную причину проблем.
Милинд изменил наше окружение своими действиями, и он определённо изменил моё мнение о «разработке программного обеспечения». Он даже изменил то, как вёл себя наш начальник!
Он продемонстрировал мне, что у меня гораздо больше силы, чем я думал. Если только я перестану постоянно ждать, что менять будут кормить с ложечки.
Его действия показали, что настоящее лидерство не даётся, а приобретается.
Со временем я изменил свое поведение, и другие тоже. И ты тоже можешь.
Говорите об окружающей среде, а не только о процессе.
Большинство команд обсуждают свой agile-процесс. Что сработало, что не сработало, как можно всё улучшить. Вот для чего нужна гибкая ретроспектива. Лучшие команды регулярно говорят об этом, и даже производят изменения для улучшения ситуации.
Отличные команды ещё говорят о своей среде.
Они проводят время, обсуждая «экологические» вопросы, например:
- Как люди работают вместе.
- Насколько они доверяют друг другу.
- Насколько эмоционально безопасна окружающая среда.
- Как можно улучшить коммуникации.
- Как больше помогать друг другу и легче получать помощь.
- Как лучше решать проблемы.
- Как эго и самооценка влияют на работу.
Начните обсуждать среду — и вы увидите, что всё меняется.
Для этого не нужно получать чьё-то одобрение. Не ожидайте, что ваш босс проведёт совещание под названием «Как улучшить среду разработки программного обеспечения». Не нужно заявлять такую тему на следующее совещание.
Просто начни об этом говорить.
Начни ставить под сомнение принятые допущения, поднимая темы об окружении в ретроспективе. Чем больше ты будешь об этом говорить, тем больше начнут и другие.
Назначьте разговор один на один с начальником.
Если у вас нет обычных переговоров один на один с начальником, попросите о нём. Не нужно ждать, пока они сами предложат его. Большинство людей чувствуют себя неловко при этом, но каждый раз, когда я просил о таком разговоре, мой менеджер был в восторге, что я это сделал.
Видите ли, большинство менеджеров ценят разговоры один на один, но они думают, что вы их не желаете. Одна просьба полностью меняет ситуацию.
Присылайте заранее краткую повестку и приходите подготовленным. (Не уверены, о чём говорить? Используйте такой шаблон для начала).
Пример повестки:
- Обсудить предстоящие проекты.
- Услышать мнение менеджера.
- Отчитаться по текущим проектам.
- Высказать своё мнение.
В вашем разговоре рассмотрите возможность рассказать боссу, что вы работаете над изменением себя и окружающей среды. Вы хотите быть более эффективным инженером и создать более эффективную командную среду. И что вы знаете: технические навыки — лишь часть того, что нужно хорошему инженеру, и вы хотите улучшить свои лидерские навыки.
Он не будет чувствовать угрозу. Вы не пытаетесь отнять у него хлеб, а хотите лучше делать собственную работу.
Каждый менеджер хочет видеть самостоятельных программистов и самоуправляемые команды. Это обещание agile-разработки, верно? Вашими стараниями их жизнь станет проще.
Попробуйте и расскажите, что получилось.
