Создание программного обеспечения — это обучение

Знаете, что редкость?

Человек А: «Нам нужна эта фича».
Человек Б: «Да, я сделаю ее».
...
Человек Б: «Готово».
Человек А: «Фантастика, именно то, что я хотел».

Такого практически НИКОГДА не происходит. По крайней мере, не при создании чего-то нового. Это может случиться, когда вы исправляете ошибку или переносите уже существующее приложение на новый язык или фреймворк… Или когда вы разрабатываете приложение, следуя спецификации.

Но когда спецификации нет, и вы создаёте что-то новое?

Вот как это работает:

Человек А: «Нам нужна эта фича».
Человек Б: «Да, я сделаю ее».
[...]
Человек Б: «Готово».
Человек А: «Хм, на самом деле, я не это имел в виду. Я имел в виду следующее: [...]»

Или так:

Человек А: «Нам нужна эта фича».
Человек Б: «Да, я сделаю её».
[...]
Человек Б: «Знаете что... На самом деле есть 3 способа это сделать, и я не уверен, какой из них лучший»
Человек А: «А, понятно. Думаю, учитывая, что мы хотим выпустить это завтра, давайте выберем первый способ».

Или так:

Человек А: «Нам нужна эта функция»
Человек Б: «Да, я сделаю ее»
[...]
Человек Б: «Готово».
Человек А: «Мне это не нравится»

Почему это происходит снова и снова?

Потому что создание нового программного обеспечения — это обучение! Если вы создаёте что-то новое и ещё не до конца понимаете, как именно это должно работать, вы узнаете, что именно вы создаёте, по ходу дела. Повторюсь: создание нового программного обеспечения — это обучение.

Пока всё хорошо, верно? Но вот очень важный момент, тот, который я хочу, чтобы вы запомнили на этой неделе: нет ни малейшего шанса, абсолютно никакой возможности создать что-то новое и избежать ситуаций типа «я не это имел в виду», или «теперь, когда я над этим работаю, я уже не уверен», или «хм, теперь, когда я это использую, мне это не нравится». Потому что единственный способ избежать этого — полностью определить, что вы хотите, заранее. Ведь что такое программирование? Это полное определение того, что вы хотите. Вы не можете этого избежать, потому что вы ещё не можете это определить, потому что создание программного обеспечения — это обучение!

Это были плохие новости. А вот хорошие. Вы можете сократить время, которое требуется для реализации идеи из приведенных выше примеров — время между уверенным «да, давайте я это сделаю» и смиренным «а, понятно».

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

Если кто-то говорит: «Нам нужна эта фича», не отвечайте «да, давайте я это сделаю» и не тратьте 4 недели на разработку, чтобы в итоге получить от другого человека ответ: «Я не это имел в виду». Нет. Вместо этого, примите тот факт, что нам нужно учиться, что нам нужно как можно быстрее поэкспериментировать с этой идеей, так, чтобы это позволило нам учиться. Принять эту идею означает попытаться как можно быстрее понять, «что они имеют в виду», с минимальными усилиями, чтобы вы могли УЗНАТЬ, что именно вы создаете.

Вместо того чтобы удаляться на 4 недели и что-то там дорабатывать, можно поступить примерно так:

• … за час создать прототип и показать его, а они скажут: «Нет, я не это имел в виду, вам нужно изменить вот эту часть»
• … за 30 минут написать описание того, как вы бы подошли к решению задачи, показать его, а они скажут: «Нет, я не это имел в виду»
• … разбить задачу на несколько частей и выпускать по одной части каждый день, чтобы каждый день то, что вы создали, воплощалось в жизнь, и вы учились, потому что на второй день кто-то скажет: «Знаешь что, нам нужно это изменить…»
• … сократить объем работ, выяснить, в чем мы уже уверены, и пропустить эти моменты, сосредоточившись на тех частях, которые нам еще неизвестны — именно там нам и нужно учиться: не добавляйте пять способов входа в систему, если нам сейчас для обучения нужен только один
• … создайте фейковое демонстрационное видео, покажите его, получите отзывы
• … напишите пост, объясняющий идею — зачем тратить неделю на разработку чего-то, если идею можно изложить в 3 абзацах?
• … напишите пример кода, который будет в файле README, покажите его, выглядит ли это как хороший API? Людям не нужен готовый SDK, если им не нравится API в README
• …

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

Что именно вы делаете, не так важно, как постоянно спрашивать: как я могу получить обратную связь о том, что я пытаюсь создать, как можно скорее? И «обратная связь» здесь используется в самом широком смысле. Обратная связь бывает самых разных форм и размеров: обратная связь от системы CI в основной ветке, обратная связь от коллег, обратная связь от пользователей, обратная связь от вас самих после того, как вы начнете использовать продукт.

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

• Вы не получите хорошей обратной связи, если выпустите MVP идеи, которая настолько очевидно содержит ошибки, что в течение 3 дней будете получать только отчеты об ошибках, а не реальную обратную связь о ее полезности.
• Вы не получите хорошей обратной связи, если людям, которые должны были дать вам обратную связь, придется преодолеть 8 препятствий, чтобы протестировать ее.
• Вы не получите хорошей обратной связи, если будете хранить свои изменения в ветке 3 недели, потому что к тому времени, как вы объедините свои 27 коммитов и система CI выйдет из строя, у вас будет 27 возможных причин, против 1, если бы вы объединяли их по одному.
• Хотите получить обратную связь по дизайну вашего скейтборда — покажите им доску, колеса не нужны. Хотите получить обратную связь о том, как работает ваш скейтборд? Вы не можете отправить его тестировщикам без колёс.
• …

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

Потому что мы создаём что-то новое, в то время, когда программное обеспечение меняется (бэк-вокал: всё меняется), и никто понятия не имеет, что, чёрт возьми, происходит. Поэтому самое важное — принять это и как можно скорее, как можно чаще выпускать продукты, по которым мы можем получать обратную связь, таким образом, чтобы это давало нам ценную обратную связь — от CI, от продакшена, от наших коллег по команде, от отдельных пользователей, от отдельных клиентов, от всех наших пользователей.

Потому что разработка программного обеспечения — это обучение, и мы хотим учиться как можно больше.

Источник