В моей голове несколько недель вертелась мысль, крошечная теория о том, как люди воспринимают разработку ПО.
Согласно моей теории, есть два типа разработчиков ПО:
Когда тип 1 узнаёт о задаче, он думает: «Это легко, люди просто могут делать X».
Когда о той же задаче узнаёт тип 2, он думает: «Это очень сложно, ведь для этого нужно, чтобы люди делали X».
Тип 1 предполагает, что задача проста, если она не техническая, потому что «можно просто попросить людей делать X». Тип 2 считает, что она сложна, потому что она не техническая.
Пример. Тип 1: «Это легко, мы можем просто попросить людей не выполнять развёртывание в это время».
Тип 2: «Постойте-ка, но что нам делать, когда люди будут выполнять развёртывание в это время?»
Другой пример. Тип 1: «Это легко, мы просто задокументируем этот процесс и попросим людей следовать документации».
Тип 2: «Как мы можем гарантировать, что люди вообще это прочитают?»
И ещё один пример. Тип 1: «Это легко, просто создадим систему, которую будут использовать эти четыре стороны, и которая гарантирует, что никто не будет жульничать друг с другом».
Тип 2: «Это очень сложно, потому что нам нужно сделать так, чтобы четыре стороны использовали одну систему».
Я пока не совсем уверен, как чётко прочертить границу между типами 1 и 2, или как дать им точное определение. Как я и говорил, это крошечная теория.
Однако если объяснять вкратце, то я бы сказал, что тип 1 не учитывает людей, а тип 2 знает, что в основе всей работы по разработке (и её задач) находятся люди.
Тип 1 верит в Разработку в большой буквы Р, в которой есть только холодные и непреложные истины; в ней есть математика и физика; это прикладная наука. Это то, что мы видим в фильме «Марсианин».
Тип 2 задаст вопрос: «Хорошо, но что, если главному герою „Марсианина“ пришлось бы строить всё это не для себя, а для других?»
Как вы могли заметить, я прозрачно намекаю на тот факт, что инженер второго типа знает чуть больше. В то же время, возможно, вы почуяли привкус цинизма, как будто мы признаём поражение: невозможно создавать красивые вещи, потому что как только дело касается людей, всё превращается в хаос.
Однако на самом деле всё наоборот! Это не цинизм, разработка второго типа принимает тот факт, что мы создаём системы с людьми и для людей, и берётся за ещё более серьёзную задачу: выполнять работу, несмотря на создаваемый этим хаос.
Потому что когда всё становится хаотичным, начинается реальность; здесь начинается настоящая работа, когда ты переходишь от маркерной доски к выпуску чего-то действительно ценного, оказывающего влияние на кого-то.
Такие разработчики принимают тот факт, что люди не машины, и сколько бы они не говорили, что они рационально мыслят, ты всё равно знаешь, что даже самые упорные защитники принципа «выбирай для работы лучший инструмент» иногда выбирают его из-за красивой GIF в README. Тип 2 знает, что никто не будет читать документацию, если она не увлекает и её сложно читать. Он использует тот факт, что люди установят обновления безопасности, чтобы получить новые эмодзи. Он учитывает, что не все будут следовать рекомендациям, потому что у каждого бывает такой полдень четверга, который ощущается как вечер пятницы.
И добавлю ещё кое-что: мне кажется, что именно из-за того, насколько хаотичны наши продукты, они становятся такими прекрасными.
Комментарии (24)
On_Luck
10.04.2023 11:04+1Как минимум не хватает третьего типа разработчика, который сочетает в себе черты первого и второго типов.
Ибо из первого примера Тип 1 - прав, т.к. большинство людей поймет, если их просто попросить. Но если не понимают, или просто игнорируют, то плавно переходим к рассуждениями Типа 2.
А из второго примера - если не получилось сделать интутивно понятный алгоритм выполнения какой-то операции, то ее необходимо задокументировать и каким-то образом гарантировать ознакомление пользователей.
prosto_a
10.04.2023 11:04+1Как минимум не хватает третьего типа разработчика который ...
Возьмет все самое лучшее что было до этого и придумает новый, самый классный, универсальный, везде подходящий, единственно применимый, новый .... тип.
Corsonamor
10.04.2023 11:04+1А ещё можно попробовать решать техническую проблему техническим методом, а не организационным, который подразумевает знания и адекватность всех участников, и заведомо ненадёжный
Kostik_s_v
10.04.2023 11:04+1В этом есть логика. И я из разработчиков второго типа. Нужно исходить из того, что никто не собирается читать руководство. Все привыкли к волшебству Google, когда вы вводите что-то и получаете целую кучу помощи в за секунду.
vlom88
10.04.2023 11:04+1Эх... если бы было это так, что бы люди могли искать самостоятельно информацию. Я тоже отношусь ко второму типу, и стараюсь проверить всевозможные ситуации
johnfound
10.04.2023 11:04+1Вообще-то, решать технические задачи административными средствами является антипатерном из худших!
AzIdeaL
10.04.2023 11:04+1"... Согласно моей теории, есть два типа разработчиков ПО:"
//Далее, Походу, накосячили вы с переводом
"Когда тип 1 узнаёт о задаче, он думает: «Это легко, люди просто могут делать X»".
-- В оригинале мысль должна была: когда тип 1 узнаёт о задаче, он решает это легко -- просто делает Х.
"Когда о той же задаче узнаёт тип 2, он думает: «Это очень сложно, ведь для этого нужно, чтобы люди делали X»".
-- В оригинале мысль должна была: когда ту же задачу решает тип 2, то решает очень сложно: ведь для простого решения есть решатели типа 1.
И т.д, и т.п.
ogost
10.04.2023 11:04+2Видишь, Туко, есть два типа людей: те, у кого револьвер, и те, кто копают. Ты копаешь.
(c) Блондинчик
Второй "тип", описанный автором - умудрённый опытом разработчик/инженер, который знает, что если дать возможность пользователю сделать что-то неправильно, то рано или поздно это случится. Я не говорю, что все пользователи идиоты, просто люди несовершенны, они склонны ошибаться, отвлечься, быть невнимательным, забывать порядок действий и так далее. В конце концов пользователи - это не обученные пилоты авиалайнеров, знающих поведение своего самолёта досконально (ну хорошо, почти досконально), а обычные люди. Это не хорошо и не плохо, это просто надо учитывать при разработке.
Первый тип с опытом, наступив на пару грабель, со временем станет вторым.
Gradiens
10.04.2023 11:04А потом происходит прекрасное: эти типы сталкиваются с бизнесом.
У которого есть словарик:
Легко = недорого, или вообще бесплатно.
Сложно = дорого
«Это легко, мы можем просто попросить людей не выполнять развёртывание в это время».
Бизнес слышит: "попросить людей - это бесплатно". Отличная идея!
Ну ладно, написать регламент "не развертывать в это время" не совсем бесплатно, но стоит совсем недорого.
Ну, а если люди не прочитали, и все уронили - так это их ответственность
Ivan22
10.04.2023 11:04+1Ну бизнес все понимает правильно, и сколько стоит 95%-ную автоматизацию превратить в 100%-ную. И сколько стоит разгрести последствия действий юзеров.
Kelf
10.04.2023 11:04+1Изначально всегда относился ко 2 типу людей, но из-за этого на меня все ополчались - ведь я им усложнял жизнь. После чего я попробовал думать и делать как 1 тип, но столкнулся с реальностью. Сейчас же стараюсь держаться золотой середины: не усложнять жизнь вечными "а что если?", но и не делать всё спустя рукава
Maklovin
10.04.2023 11:04+1Как сотрудник клиентской поддержки понимаю, что продукт от разработчика 1 типа будет генерить кучу обращений от юзеров. При чем поток обращений будет очень некачественный, который можно закрыть одним макросом. То есть макросы от поддержки станут частью процесса. Это не очень.
Всегда нравилась мысль, что юзера должен вести интерфейс, а не документация. Но понимаю, что это дольше и дороже. Просто решил поделиться
Ivan22
10.04.2023 11:04+1а продукт от разработчика номер 2 просто.... не существует, так как автоматизировать вообще ВСЁ невозможно
Xneg
10.04.2023 11:04+1
К сожалению, сталкивался в своей практике с разработчиками типа 2, которые как раз считали себя очень опытными, а остальных беспечными/несистемными и т.д.
В результате разработка продукта занимала вместо 1 месяца пол-года, на выходе получалось не то, что нужно пользователям, а потом разработчика 1-го типа всё равно всё приходилось переделывать...
В общем, мне ситуация напоминает цитату Дональда Кнута про преждевременную оптимизацию.
Но вообще всё хорошо в меру, и у каждого подхода есть свои достоинства и недостатки. Самое страшное, когда в своём подходе видишь только плюсы, а во всех остальных минусы.
gruzoveek
Я как-то сделал отличный сервис, но как только туда пришли юзеры со своими шаловливыми ручонками - тут то все и загнулось!