Прохладные отношения с асинхронностью. Команда и взаимодействие внутри её
Многие программисты любят работать одни. Некоторые начальники не любят, когда их работники особенно активно взаимодействуют. По ровной ли мы идём дорожке или по кочкам, по кочкам?🤔
Когда разработчики говорят, что они не любят встречи и предпочли бы всё время проводить с компьютером, то в душе я улыбаюсь. Если наступит тот момент, когда разработчик сможет всё выполнить, ни с кем не общаясь, то тогда ИИ предложит подвинуться, дружески хлопнув рукой по плечу.
Почему это я так радикально завернул? Давайте немного всмотримся, чем мы занимаемся. Мы пишем обширные инструкции, позволяющие компьютеру делать полезную работу и справляться с трудностями на её пути. А откуда мы знаем, какую именно полезную работу должен делать компьютер?
Это хороший вопрос. При разработке для любой неизвестной нам предметной области мы не знаем ответа на него. Но знают другие люди. Ситуация может быть ещё закрученнее, когда другие люди не знают точно, а только предполагают, и им необходимо произвести исследование.
Вопрос ещё осложняется тем, что не все мыслят в подобных терминах. Кто-то может и не знать, что нужно провести исследование жизнеспособности решения и просто предложит: «сделай то-то». Если вам не повезло сильно, то «то-то» — непроверенное решение, первым пришедшее в голову.
То есть мы пришли к тому, что часто разработчик не является решателем проблем в широком смысле. Его задача состоит в том, чтобы воспроизвести описанное на естественном языке решение в терминах искусственного языка. Мы в каком-то смысле переводчики. Но переводим ли мы дословно?
Не совсем, наши переводы содержат дополнительную информацию, которую я уже упомянул — решения для проблем, которые могут появиться в пути. Какие это проблемы? Можно увидеть по крайней мере два вида: проблемы технического характера и проблемы логики решения.
Проблемы технического характера вроде необходимости подстраиваться под не самый удачный API библиотеки мы можем решить и сами. Хотя некоторые технические проблемы всплывают и до уровня пользователя, и не в наших силах это изменить. Например, ожидание ответа на запрос.
Это то, что явно будет заметно, и значит то, что нужно будет как-то обработать аналитику, предлагающему решение. Более того, ему уже нужно будет подумать об обработке исключений в самом процессе решения пользовательской проблемы. Продумать обработку неверных данных, подсказки.
Не каждый человек, предлагающий решение проблемы, занимается её проработкой вширь, не каждый умеет. Умеет ли делать такое разработчик? В какой-то мере да, но умеет ли кто-то делать это лучше него? Да, QA-инженер, это его работа.
Путём этих размышлений мы пришли к тому, что без совместной работы троих людей над одной задачей её решение будет вопиюще неполным. А может ли решение быть полным? Нет, таковым оно быть не может. А может ли быть полным в достаточной степени? Да, такое возможно.
Почему решение не может быть полным? По той причине, что обработка неожиданных ситуаций в его логике не имеет явного конца. Неожиданные ситуации — это проблемы, материализовавшиеся риски. Сколько рисков мы можем придумать для моего завтрашнего утреннего прослушивания аудиокниги?
Да сколько угодно: я просплю, мне захочется посмотреть мультик с дочкой, я решу дописать небольшой тред про работу с книгами, лупоглазый гуманоид мне предложит дружбу века, вознесёт на крыльях ветра в даль, что светит ярко нам.
Там на праздничном конгрессе я поставлю свою подпись, скрепив дружбу меж народов на грядущие века. Представлять я буду Землю, как вы поняли, наверно, а мой друг представит свой удалённый внешний мир.
В какой-то момент обработка неожиданных ситуаций перестаёт иметь видимый смысл, тогда-то решение становится в достаточной степени полным. Новый опыт может нас научить видеть новые риски. Тогда до достаточно полного состояния потребуется сделать новый шаг.
Если же по каким-то причинам взаимодействие в группе, разрабатывающей решение, не произойдёт, то мы окажемся на дороге последовательных работ, и сначала свою работу выполнит аналитик, потом разработчик, а затем QAE. Асинхронность в уродливом виде покажется во всей красе.
Через пару недель QAE вернётся с парой багов, потом разработка пойдёт в бой. Ещё спустя некоторое время счастливые клиенты через удобнейшие механизмы фиксации обратной связи пришлют вам информацию о непокрытых рисках и немножечко денег, чтобы вы всё починили.
Так что же после всего сказанного стоит воспринимать как выполнение разработчиком поставленной задачи? Написанный код на имеющуюся спецификацию или же завершение её проработки в составе группы с последующим доведением до ожиданий заинтересованных лиц?
Ответ на него многослойный, часть его мы рассмотрим завтра, если я не забуду. В своей команде я всё же пытаюсь продвигать именно второй вариант. Но должен ли разработчик заниматься такой деятельностью? Сама постановка вопроса «А почему я должен?..» мешает обзору перспектив.
Если окружающая среда не подсказывает вам ответ, перспективнее задать вопрос: «Будет ли мне полезно делать это?» Если будет, то действуйте, собирайте людей, качайте навыки взаимодействия, организации. Ведь если что-то выглядит и крякает как тимлид, то это, наверное, он и есть.
А если вокруг летят головы, да и вообще не очень-то вам и нравится взаимодействовать с людьми, то полезнее не будет. По возможности, избегайте этого.
Мы лихо проехались по самому базовому взаимодействию, а что ещё бывает?
Бывают стендапы, бывают ретроспективы, демонстрации и прочее. Нужно ли это всё? В своей практике я стараюсь использовать стендапы для того, чтобы фокусировать команду на определённых действиях, а также помогать людям увидеть альтернативные способы решения их задачи.
Ретроспективы — это настолько отдельная песня, что даже погружаться в них не хочется, тред и так затянулся. Единственное, хочу сказать, что очень удивился, когда прочитал в Твиттере, что участники уходят с них в слезах. Это ярчайшее свидетельство их ошибочного проведения.
Про демонстрации ничего не скажу. У меня нет опыта проведения качественных демонстраций.
Я опять ушёл от вопроса, нужно ли это всё. Мне кажется, что да, но с нюансами. Без внутреннего взаимодействия команда перестаёт быть командой и становится группой, суммой частей.
То есть, уходя от общения, мы уходим от взаимного обучения, синхронизации взглядов, выработки более качественных решений и в полном согласии с законом Конвея создаём системы, организованные по принципу «кто в лес, кто по дрова».
Если это всё так важно, то почему слово «встреча» — почти ругательное? Дело в том, что, как и в остальных вопросах, здесь нужно действовать лучше, чем как-нибудь. Мне нравится модель, предложенная книгой Where the Action Is авторства Elise Keith.
В книге предлагается руководствоваться несколькими вещами: воспринимаемым качеством встреч, то есть внутенним ощущением участников и чистым позитивным влиянием, то есть пользой от этих встреч для целей организации.
Также в книге предлагается базовая структура любой встречи, пять этапов зрелости культуры встреч в организации. Кстати, если задуматься, то концерт — это тоже встреча, но лица там обычно не такие кислые.
Герман Тебиев