Зачем смотреть, как другие люди работают

Говорят, можно бесконечно смотреть на три вещи: на 🔥 огонь, 💧 воду и как другие люди 🛠 работают. Сегодня рассуждаем о том, зачем смотреть, как другие люди работают, и стоит ли показывать, что делаете вы.

Работа может быть прозрачной и непрозрачной. Прозрачная работа - это когда видно, как идет прогресс. А непрозрачная - это как черный ящик: что-то на входе, потом что-то на выходе, а что там происходит внутри - не видно. Поговорим об аргументах за и против прозрачности, и потом я предложу несколько советов, как найти оптимальный баланс.

Облегчает планирование. Если примерно представлять, как идет работа, можно строить планы, отталкиваясь от этого. Здесь могут быть и обещания, выдаваемые клиентам, и координация работы других людей, и выбор, чем заниматься дальше.

Снижает риск ошибок. Программирование это такая полу-исследовательская деятельность. Нельзя вообще все запланировать заранее, многие детали выясняются по ходу работы. Вот моя любимая картинка от Basecamp: существенная часть работы над задачей - это, по сути, выяснение, что надо делать. Регулярное обсуждение с коллегами помогает нам выявить ошибки на ранней стадии, когда их проще всего исправить.

Помогает не застревать. Опытные люди знают, что все занимает больше времени, чем изначально кажется. Порой сложности возникают там, где вообще не ждали, и их обсуждение может помочь продвинуться вперед. Иногда коллеги могут подсказать какую-то идею, а иногда можно упростить условия задачи, если оказалось, что первоначальный план слишком сложен. Рассказ о том, что происходит, стимулирует такие обсуждения и помогает двигаться быстрее.

Обучение в команде сильно выигрывает, если люди показывают, как они работают, делятся опытом. Это один из самых эффективных способов передачи знаний во все времена. Веками подмастерья учились, наблюдая за работой мастера, и это по-прежнему отлично работает.

Снижение тревожности - психологический момент. У людей, а особенно некоторых менеджеров 🙂, есть фундаментальная особенность - неопределенность их тревожит. Если они долго ждут выполнения какой-то задачи, то им хочется знать, что там происходит. В идеале, они бы, конечно, хотели услышать, что все уже готово, но если еще нет - то, как идут дела. Так что, если мы можем доложить, что по задаче есть хороший прогресс - их это успокаивает. Если, конечно, прогресс хороший. Если не очень хороший - это другая история, поговорим чуть ниже.

Отвлечения на “ненужную бюрократию”. Во многих профессиях работа требует сфокусированности (яркий пример - программисты), а всякие рассказы о том, что происходит - это отвлечения, и далеко не всегда они продуктивны. Также люди могут опасаться, что если они начнут подробно рассказывать, что и как они делают, то к ним начнут лезть с непрошенными советами или как-то еще мешать работать. Люди не хотят отвлекаться, и это естественно.

Иногда нечем похвастаться. Перед этим мы говорили что демонстрация хорошего прогресса успокаивает, но ведь далеко не всегда прогресс хороший, а демонстрировать плохой не очень то и хочется. Иногда кажется, что надо немного подождать, скоро будет, что показать, и вот тогда лучше демонстрировать. Особенно дизайнеры не любят показывать незавершенную работу.

Ощущение слежки. Иногда попытки обеспечить прозрачность работы заходят слишком далеко и начинают восприниматься, как вторжение в приватность и демонстрация недоверия. Пример - следящий софт от UpWork, который делает скриншоты экрана во время работы. Я встречал много людей, которые крайне негативно отзывались о таком, и я полностью их понимаю.

Скатывание в микроменеджмент. Если исполнитель постоянно демонстрирует, что получилось и советуется по каждому поводу, это размывает его ответственность, он теряет способность работать над задачей самостоятельно. Ничего хорошего из такого не происходит: и работа замедляется, и качество в итоге падает.

В идеале, мы бы хотели найти такой баланс прозрачности работы, при котором удалось бы получить все вышеперечисленные преимущества, и в то же самое время избежать недостатков. Как говорится, за все хорошее, и против всего плохого. Вот несколько практических советов, как найти этот баланс:

Фокусируйтесь на результатах, а не на процессе. Не нужно пытаться наблюдать, чем человек занят, важно - что он в итоге сделал. Если он кучу времени проводит в твиттере и на ютубе, но потом может быстро собраться и сделать все, что нужно - отлично, нет вообще никаких проблем с этим. Как именно он проводит время - его дело, смотрите на результат - чего в итоге добился. Это помогает избежать сразу двух ловушек. Во-первых, вы не вторгаетесь в приватность, а люди этого очень не любят. Во-вторых, вы не ведетесь на демонстрацию кипучей деятельности, когда человек изображает, как сильно он занят, а в итоге на выходе пшик.

Спрашивайте, какие затруднения. Если результаты скромные - не спешите делать из этого трагедию, и не спешите со своими выводами, как же так вышло, что результаты печальные. Все в программировании занимает больше времени, чем нам хотелось бы, это скорее правило, чем исключение. Лучше спросите у самого человека, что ему помешало. Так будет гораздо полезнее и продуктивнее. Свои выводы и, при необходимости, корректировку курса вы сможете сделать позже, имея на руках полную картину. Ну а, может, человек уже сам нашел выход и ему просто нужно еще немного времени.

Найдите оптимальную периодичность, как часто спрашивать о результатах. Если это происходит слишком часто, то у людей недостаточно времени, чтобы добиться чего-то значимого, а разговоры или отчеты создают слишком много отвлечения и раздражают. Если слишком редко, то страдают основные цели, зачем мы это делаем - планирование, коррекция ошибок, минимизация застреваний. Оптимальная периодичность - разная для разных проектов и команд. У кого-то планерки раз в неделю, у кого-то каждый день. Если вы не уверены, что будет хорошо работать для вас - экспериментируйте. Начните с чего-то, что кажется разумным, потом попробуйте почаще или пореже, смотрите, что хорошо работает для вас.

Открытые коммуникации. Если большая часть рабочих обсуждений происходит публично, а не тет-а-тет, это способствует не только прозрачности работы, но и помогает принимать более качественные решения, а также стимулирует обучение в команде. Не во всех компаниях принят такой подход, но он очень действенный, и я даже записал короткое видео на эту тему.

Подавайте личный пример. Если вы находитесь в роли менеджера или тимлида, то вам будет гораздо проще внедрить в команде какие-то правила, если вы сами им следуете. Это, к сожалению, не всегда так, бывает что менеджер, например, просит других писать отчеты, а сам их не пишет, ну и это вызывает совершенно естественную неприязнь. Как преодолеть - очень просто, следуйте сами тем правилам, которые вы заводите.

Не злоупотребляйте ограничениями доступа. Последнее в списке, но не последнее по важности. Есть компании, в которых для получения доступа к чему-нибудь нужно долго и мучительно доказывать, что оно вам действительно нужно. Это ужасная атмосфера для работы: и демотивирующая, и убивающая продуктивность. Я видел случаи, когда один слишком усердный безопасник с синдромом вахтера мог практически парализовать работу целой немаленькой компании. Постарайтесь, чтобы у вас так не было.

Да, бывает информация, к которой стоит ограничить доступ, но причины для таких ограничений должны быть четко названы, и желательно, чтобы это были исключения, а не правило. Доступ к исходному коду, таск-треккеру, проектной документации, рабочим чатам и другим инструментам совместной работы должен быть у всех, кто причастен к проекту. Нет ничего страшного, что разработчик будет заглядывать в фигму к дизайнеру, а дизайнер - подглядывать в код к разработчику.

Нет никаких проблем, если ребята из соседнего отдела будут видеть исходные коды API, которым они пользуются. Открытая информация способствует совместной работе, закрытая - препятствует. Даже Apple, компания многие годы известная своей атмосферой секретности, сейчас начинает менять подходы, потому что секретность очень мешает работе.

И напоследок поговорим о статус-митингах. Они очень широко распространены, и в некоторых командах даже проходят ежедневно в формате стендапов. Стендапы как раз призваны помочь с прозрачностью работы и оперативным планированием. На них люди часто отвечают на три стандартных вопроса - что я сделал вчера, что собираюсь делать сегодня и какие есть затруднения. Я лично такой формат недолюбливаю, и я знаком со многими разработчиками, которые тоже от него не в восторге. Цели как бы понятные и к ним вопросов нет. Но, мне кажется, что частенько можно добиваться тех же самых результатов меньшими усилиями.

Вот, например, смотрите, почти каждая команда использует какой-то таск-треккер, типа Jira, Trello, YouTrack или подобный. Казалось бы, зачем спрашивать, над чем я работаю, если в таск-треккере на меня уже назначена задача, и у нее стоит статус “в работе”? Или, например, зачем спрашивать на митинге, что я сделал вчера, если вот они - мои коммиты на гитхабе, и вот я отписался в задаче, что по ней сделано? Зачем спрашивать “какие есть затруднения”, если мой пулл-реквест висит уже третий день без ревью? Ну вот он как бы и есть мое затруднение.

На это можно возразить, что, во-первых, информация бывает разбросана и собирать ее неудобно, во-вторых, не все проблемы попадают в описанные категории, и далеко не всегда в таск-треккере полный порядок. Люди забывают передвинуть статус у задачи или отписаться по ней, или, может, вообще кто-то делает работу мимо таск-треккера. Я согласен, так бывает, и разумеется, не призываю полностью исключить живое общение. Оно полезно, просто не хочется тратить время на тривиальные вещи, которые легко узнать и без митинга.

Мы в ivelum даже разработали специального помощника для команд разработки - Teamplify, который помогает экономить время на обсуждении таких вопросов. Он автоматически собирает информацию из всех систем, которые использует команда, и помогает понять, кто чем был занят, где могли возникнуть затруднения, помогает поддерживать порядок в таск-треккере, напоминает о дедлайнах и других важных датах - отпусках, праздниках и прочем. Можете бесплатно попробовать для своей команды.

Как и во всем, здесь важен баланс. Чрезмерное увлечение попытками сделать всю работу прозрачной - ни к чему хорошему не ведет. Однако и работать в полностью закрытом режиме тоже не стоит. Старайтесь фокусироваться на результатах. Спрашивайте, какие есть затруднения. Не надоедайте людям слишком частыми или тупыми вопросами. Старайтесь не скатываться в тотальный контроль и микроменеджмент. Цените открытые коммуникации. Подавайте личный пример - как отчитываться о своей работе. И не злоупотребляйте ограничениями доступа. Надеюсь, это поможет сделать обстановку на вашем проекте более продуктивной.

Если у вас есть что добавить по этой теме - давайте обсудим в комментариях!