Рабочие конфликты - это факт жизни. Я даже не имею в виду разногласия, здоровое напряжение или компромисс - я говорю о реальных конфликтах, когда вы уходите, чувствуя разочарование, гнев или неуверенность в том, как двигаться дальше.
К счастью, на моем рабочем месте такие конфликты встречаются довольно редко; чаще всего проблемы решаются быстро, без всяких неприятностей. Но эти конфликты иногда случаются, и готовность справиться с ними - решающий навык, чтобы справиться с делом.
Как руководитель (он же менеджер) я время от времени слышу о подобных проблемах от моей команды. Если они расстроены и не знают, что делать дальше, я обычно начинаю с одного вопроса: «Вы говорили об этом с другим человеком?»
Недавно я сам испытал это с другой командой, когда я пытался проработать некоторые изменения и чувствовал себя замедленным и разочарованным из-за неясного процесса. Мне казалось, что я ударился о стену, и чем дольше я чувствовал себя заблокированным, тем больше я разочаровывался.
Я изначально ничего не делал, чтобы решить эту проблему. Что ж, это не совсем так: я жаловался / скулил коллеге, потому что она доверенный коллега, и я хотел немного выговориться. Она задала мне очень важный вопрос: «Вы говорили с ними об этом?»
Я не знал.
Программное обеспечение для отладки
Как и проблемы в человеческих отношениях, проблемы с программным обеспечением - это реальность.
Одна из самых распространенных проблем для младших разработчиков (особенно тех, кто не работал с большими кодовыми базами) - это отладка.
Когда разработчики только начинают свою карьеру, они часто сосредотачиваются на том, чтобы заставить что-то работать, а не на исправлении неисправных. Даже когда они сталкиваются с проблемами, часто выполняемая ими отладка является тривиальной, потому что они работают над кодом, который они написали. Они знают, как все работает, или, по крайней мере, как это должно работать. У них есть весь контекст.
По мере того, как разработчики начинают работать над более сложными проблемами, в более крупных базах кода, с кодом, который они не писали, у них не будет всего контекста, когда они столкнутся с препятствием. Отладка становится все сложнее, и младшие разработчики могут быть не готовы к тому, как с ней справиться.
Паттерн, который я видел много раз:
- у разработчика проблема (например, ошибка, которую он не понимает)
- разработчик расстраивается: «черт возьми, это программа, она глупая, почему она не работает так, как я хочу ?!»
- разработчик просит помощи у доверенного партнера или лидера
Когда они просят о помощи, они часто получают тот же ответ: «Вы пробовали погуглить?»
Научиться эффективно отлаживать - это такой же навык, как и любой другой, и он начинается с признания вашего беспокойства по поводу того, что вам незнакомо, но все равно погружается, чтобы изучить его. Нет ничего плохого в том, чтобы попросить о помощи (это отличный способ научиться), но вместо того, чтобы спрашивать в качестве первого шага, разработчики учатся добавлять другие инструменты в свой набор инструментов для отладки: поиск сообщений об ошибках в Google, чтение стека трассировки, добавление точек останова в код, изоляция тестовых случаев и т. д. Все эти действия дают разработчику больше знаний, больше контекста, с помощью которого можно понять и в конечном итоге решить проблему.
По мере роста набора инструментов отладки разработчики могут не чувствовать меньше разочарования или беспокойства, когда сталкиваются с неприятной проблемой, но они лучше оснащены для ее решения здоровым способом.
Путем отладки разработчики могут узнать, что ошибка связана с программным обеспечением (например, какая-то законная ошибка); или они могут обнаружить, что ошибка была в них (например, что они использовали что-то неправильно). Часто истина находится где-то посередине: ни разработчик, ни программное обеспечение не неправы, они просто оба делают разные предположения о том, как все должно работать.
Устранение человеческих проблем
В моем конфликте с другой командой (и со многими другими людьми, с которыми я беседовал) мы можем наблюдать тот же паттерн разочарованного младшего разработчика:
- У Дэйва проблема (например, все работает не так, как я ожидал, и я не понимаю, почему)
- Дэйв расстраивается: «Почему эта команда не работает так, как я хочу ?!»
- Дэйв просит помощи у доверенного партнера
Из-за своей эмоциональной реакции я был слеп к собственному поведению и дальнейшему развитию. Мой коллега, задавший мне этот простой вопрос («Вы говорили с ними?»), Заставил меня признать, что для решения этой проблемы мне нужно было погрузиться в проблему. Это напомнило мне, что мне нужно обратиться к другим инструментам в моем наборе инструментов для отладки.
Как только я поговорил с другой командой, я узнал:
- У меня был какой-то недостающий контекст
- Я делал некоторые неправильные предположения
- Они согласились, что некоторые части процесса работают не так, как ожидалось, и у них есть планы по их улучшению.
Я также вспомнил, что мне нужно исходить из позитивных намерений: эта команда состоит из разумных людей, и они хотят лучшего для компании и людей, которые здесь работают.
Разговор не был эмоционально заряженным, не обвиняющим, не о вине. Это было рациональное исследование проблемы, с которой мы столкнулись, и оно принесло ощутимые результаты: теперь мы оба лучше понимаем разочарование, которое испытывал каждый из нас, и теперь можем вместе работать над улучшением ситуации. Мое разочарование растаяло.
Как и при отладке, такие разговоры могут дать нам больший контекст и ясность в отношении того, в чем проблема, почему это происходит и как двигаться дальше. Высказав это, мы можем узнать, что виноват другой человек (например, какое-то законное проблемное поведение); или мы можем обнаружить, что вина была на нас (например, что мы делали что-то не так). Часто правда где-то посередине: ни мы, ни другой человек не неправы, просто мы оба делаем разные предположения о том, как все должно работать.
В следующий раз, когда вы столкнетесь с кем-то на работе, когда вы расстроены и просто не можете понять, почему они что-то делают (или не делают), наденьте пояс с инструментами отладки и спросите себя: Я еще с ними разговаривал? »
Подробнее откуда это взялось
Эта история публикуется в журнале Noteworthy, куда каждый день приходят тысячи людей, чтобы узнать о людях и идеях, формирующих наши любимые продукты.
Следите за нашей публикацией, чтобы увидеть больше историй о продуктах и дизайне, представленных командой Журнала.
