Мой план из четырех пунктов для демонстрации моей работы
Итак, вы написали код. Что теперь?
Вы неизбежно будете улучшать чужую работу. Как вы можете отмечать свои улучшения, не оскорбляя при этом авторов оригинала? Как вы поддерживаете культуру, в которой другие чувствуют себя приглашенными улучшить вашу работу в будущем?
Ниже приводится мой план из четырех пунктов для демонстрации моей работы. Конечно, любая презентация будет немного отличаться, но это хорошая отправная точка для размышлений:
- Каково было прежнее положение вещей?
- Почему этого было недостаточно?
- Что мы изменили?
- Что мы ожидаем лучшего?
Разберем каждый шаг.
1. Каково было прежнее положение вещей?
Сформулируйте проблемную область. Особенно в крупной организации не все будут знать об области продукта, которую вы изменили. Это работает лучше, поскольку вы лучше знаете свою аудиторию. Если вы делаете презентацию в первую очередь для сотрудников с большим стажем работы, вы можете обойтись чем-то простым, например: «Мы внесли некоторые изменения на страницу оформления заказа». Когда вы представляете продукт в первую очередь новым сотрудникам или людям, плохо знакомым с продуктом, не бойтесь вдаваться в подробности.
Для людей, хорошо знакомых с проблемной областью, это может быть одно предложение: «Сегодня утром я покажу вам изменение, которое мы внесли на страницу оформления заказа». Для другой аудитории вам, возможно, потребуется немного больше объяснить предысторию. Используйте свое лучшее суждение.
2. Почему этого было недостаточно?
Частью разработки программного обеспечения является роль «археологии программного обеспечения» — копаться в слоях, чтобы понять, как возник проект, каким был мыслительный процесс в то время и как эта история развивалась (и была забыта) с течением времени.
Объясните, что было упущено, сломано, слишком сложно или иным образом проблематично. Намеренно сформулируйте недостаток как текущую главу постоянно улучшающейся сюжетной линии, а не как чью-то допущенную ошибку.
Помните, что продукт, существующий в настоящее время, всегда является результатом знаний, ограничений и компромиссов, существовавших во время его создания. Как только продукт попадает в руки пользователей, мы неизбежно начинаем проверять все предположения, которые у нас были в начале, а также формулировать новые гипотезы, которые требуют выпуска нового кода.
Ваше изменение является этим новым кодом.
Если вы не знаете, как представить этот сегмент, подумайте над тем, чтобы ответить на несколько из следующих вопросов:
- Как мы узнали о недостаточности?
- Какие данные мы получили?
- Как мы интерпретировали эти данные?
- Каковы были компромиссы и ограничения в то время?
- Почему эти компромиссы больше не приемлемы?
- Как мы преодолели эти ограничения?
3. Что мы изменили?
Теперь займитесь сутью изменений. Всегда представляйте изменение с точки зрения пользователя продукта. Это требует, чтобы вы понимали пользователя. Представляйте глубоко технические детали только в том случае, если пользователь (а не аудитория) обладает глубокими техническими знаниями.
Например, если вы внесли изменение в пользовательское приложение, постарайтесь придерживаться того, что пользователь заметит как отличное и (надеюсь) лучшее. У клиента обычно нет особых предпочтений, если он использует веб-сайт, который использует компоненты React, основанные на функциях или классах. Однако им небезразлично, работает ли ранее медленная страница быстрее или они могут выполнить работу с меньшими усилиями. Это не значит, что вы должны игнорировать абсолютно все технические детали, просто не делайте их основным акцентом презентации.
С другой стороны, иногда изменения носят преимущественно технический характер. В чистом виде рефакторинг характеризуется изменением «факторов уравнения программного обеспечения без изменения результирующего решения». Если ваше изменение в первую очередь принесет пользу другим инженерам, а влияние на конечного пользователя будет лишь второстепенным, то приложите столько усилий, сколько вам нужно, чтобы описать, что в коде отличается (и опять же, надеюсь, лучше).
Подумайте о том, чтобы показать до и после, если позволяет время; в противном случае просто сосредоточьтесь на после. Используйте первые два сегмента, чтобы установить, почему изменение является значительным.
4. Что мы предполагаем улучшить?
Используйте это время, чтобы вернуться к началу, с которого вы начали. Сформулируйте свое улучшение как гипотезу эксперимента: «Мы ожидаем, что {изменение} улучшит {недостаточность}, потому что {ваша новая гипотеза}».
Это полезный способ обеспечить здоровое отношение к коду в контексте неверных гипотез: изменения имеют смысл, даже если гипотеза оказывается ошибочной, потому что они были успешными в определении достоверности гипотезы. В худшем случае мы получим больше данных и уточним нашу гипотезу. В лучшем случае наша гипотеза оказалась верной, и мы улучшили пользовательский опыт.
Обрамление изменений в контексте данных и обучения — хороший способ защититься от непреднамеренного представления идей других людей как «правильных» или «неправильных». Сосредоточение внимания на обучении неявно предполагает, что мы не знали всего. Он предполагает, что мы узнаем, является ли наше изменение хорошим, благодаря собранным данным, а не утверждению, что я уже знаю, что мое изменение является хорошим, потому что я сделал его сам.
Это основной план с примечаниями. Каждая демонстрация неизменно отличается, но я стараюсь, по крайней мере, каким-то образом, в какой-то форме или форме включить эти ключевые моменты. Не стесняйтесь заимствовать и улучшать по мере необходимости.
