Много лет назад, работая консультантом, выжимая строки кода, я пришел к этой простой, но действенной реализации. Это изменило мой взгляд на программное обеспечение и весь мой карьерный путь.
Я был по заданию в The Big Company, работая над их серверной частью Big Enterprise. Мы занимались множеством проблем с обслуживанием, передачей проекта и интеграцией с другими крупными системами. Большую часть обслуживания выполняли консультанты из Индии, а иногда и находящиеся в ней. Они были оторваны от того, что мы пытались создать, и плохо понимали проблемы, которые мы пытались решить. Несмотря на то, что мы использовали самые современные технологии, много работали с TDD для обеспечения качества и работали в соответствии с принципами Agile, проблемы сохранялись. Пользователи жаловались на отсутствие функций или на то, что простые задачи слишком сложны для выполнения в системе. Тогда меня осенило: наше программное обеспечение создано людьми и должно использоваться людьми.
Сделано людьми
Программное обеспечение разработано и написано людьми. Настоящим людям придется читать, понимать и расширять ваш код. Люди много думали о функциях, которые вы внедряете, архитекторы принимали решения о том, какую технологию использовать, и вы принимаете осознанные решения в отношении каждого создаваемого вами технического решения. Реальным людям придется поддерживать ваше программное обеспечение, запускать его в производство, исправлять ошибки и следить за тем, чтобы оно работало должным образом. При создании программного обеспечения для решения конкретной проблемы потребовалось большое количество осознанных решений, знаний и технологий. На все эти решения повлияло понимание проблемы, способы общения, личные чувства и убеждения.
Используется людьми
Также вашим программным обеспечением будут пользоваться реальные люди. Вероятно, не тот, кто составил спецификацию, и, возможно, даже не тот, кто покупает ваше программное обеспечение. Будут люди, пользователи, которые используют ваше программное обеспечение для решения конкретной проблемы. Они будут счастливы, когда это облегчит им жизнь, и разочарованы, когда они не смогут понять, как пользоваться системой. Ваше программное обеспечение может вызвать улыбку на лице пользователя или вызвать бессонные ночи. Если все сделано правильно, ваше программное обеспечение решает проблемы реального мира. Если вы сделаете плохо, ваше программное обеспечение не имеет значения и никогда не будет использовано, а все ваши усилия будут напрасными.
Это о людях
Я понял, что насколько я люблю технологии, работа с человеческим аспектом программного обеспечения привлекает меня больше (и, честно говоря, я считаю, что у меня это получается лучше, чем когда-либо как разработчик). Устранение разрыва между людьми, которые создают программное обеспечение, и людьми, которые его используют, стало одной из моих миссий. Технологии - это инструмент, который помогает нам приносить пользу другим людям. Пока мы помним об этих коллегах, членах сообщества и пользователях, наши усилия имеют больше смысла.
Человеческий фактор также объясняет, почему разработка программного обеспечения настолько сложна. Сама по себе технология обычно сложна (результат работы системы трудно предсказать, но один и тот же ввод всегда дает один и тот же результат). Создание программного обеспечения для пользователей является сложной задачей (вывод невозможно предсказать, и результаты будут разными для одного и того же ввода, здесь - более полное объяснение). Разработка программного обеспечения или любая другая работа, в которой задействованы люди, всегда содержат некоторую неопределенность. Такие методологии, как agile, бережливое производство и дизайн-мышление, - это способы справиться с этой неопределенностью.
При работе с серверной частью Big Enterprise мы закончили экскурсию, опросили конечных пользователей продукта и спросили их, что они хотели бы видеть в ремейке системы. Они были приятно удивлены, что мы хотели их внести. Мы получили бесценные отзывы, которые помогли нам создать лучшую систему, которая более эффективно решала проблемы реального мира. Мы также пригласили некоторых инженеров по обслуживанию сесть с нашей командой. Проводя время вместе, мы стали лучше понимать работу друг друга, и общение стало намного проще.
Снова и снова я добивался отличных результатов в проектах по разработке программного обеспечения, когда указывал, что «другие» (команда, от которой мы зависим, пользователи, менеджеры) - это люди со своим собственным набором ценностей и убеждений. Поговорив с ними и выяснив, что происходит, мы смогли разрешить множество конфликтов и технических проблем, которые поначалу казались непонятными. Один из моих наиболее часто применяемых инструментов задает вопрос: «РАЗГОВАРИВАЛИ ли вы с ними?» (Я не считаю, что написание туда и обратно в тикете Jira является разговором).
В следующий раз, когда вы столкнетесь с проблемой, которую, по вашему мнению, создали другие (включая клиентов), попробуйте посетить этого человека или команду и послушать их, чтобы узнать, что происходит на самом деле. Что заставило их так разработать API? Что послужило причиной их решения? Усердно работайте, чтобы понять их, а затем вместе выработайте решение.
