Эта часть больше ориентирована на тех, кто начинает свою карьеру в разработке программного обеспечения. И начну с заключения.

S L O W . . . D O W N !

Хорошо. Теперь я могу немного разглагольствовать о важности замедления, чтобы финишировать быстрее.

Прежде всего, давайте определим, что означает «конец». Готово значит сделано. Это значит, что вы сдали домашнее задание своему учителю, и пути назад нет. Когда спринтер заканчивает гонку, гонка окончена. Готово. Нет пути назад к финишу, чтобы пробежать еще метр или около того. Нет, это сделано. Вот и все. Там только вперед. Нет пути назад. Нет никакого «90% финиша». Finish имеет логическое значение: оно либо закончено, либо нет. Короче говоря, когда вы заканчиваете задачу, это означает, что вы в конечном итоге готовы взяться за другую задачу… прямо сейчас.

Вау.

Теперь, что я имею в виду под «закончить быстрее», так это то, что поток работы и выполнения задачи должен быть ацикличным. Там тоже нет пути назад. По сути, вы ставите задачу один раз, а общий результат принимается клиентом. Это означает, что нет «возможности» исправить ошибку, потому что в первую очередь не должно быть ошибки. Если есть необходимость вернуться и переработать задачу, то только потому, что клиент меняет свое мнение о первоначальном запросе ПОСЛЕ, увидев, что вы успешно выполнили задание, которое на 100 % соответствует первоначальному запросу. требования.

Теперь, когда у нас есть основа для «финиша» и понимание «финишировать быстрее», давайте посмотрим, как этого достичь.

Понимать все переменные в игре

Разработка программного обеспечения очень похожа на работу над головоломкой. Каждая часть головоломки — это компонент, взаимодействующий с другими компонентами для получения одного большого результата: изображения реки, текущей по долине. Или что-то достаточно близкое. Чтобы достичь цели, первое, что нужно сделать при работе над головоломкой, — это убедиться, что каждая часть обращена правильной стороной вверх, чтобы вы могли видеть, с чем работаете. В разработке программного обеспечения часть головоломки сродни требованию. Вы должны убедиться, что можете «видеть» требование, что это такое, и как оно вписывается в общую головоломку, которую обычно составляет система.

Другими словами, часть головоломки сродни переменной в требовании.

При работе над пазлом мы пробуем кусочки в разных местах и ​​под разными углами. «Подойдет сюда?», «Подойдет ли туда?», «Подойдет ли он к этой части?», «Разве нет ничего лучше, чем посмотреть на Netflix, чем пытаться работать над этой головоломкой?». Столько попыток. Столько неудач. Тем не менее, мы продолжаем и не сдаемся. То же самое и с требованиями. Вам нужно задавать вопросы, чтобы понять их. Некоторые вопросы прозвучат глупо (на самом деле иногда это самые лучшие вопросы). Некоторые вопросы покажутся излишними (эти вопросы утверждают, что вы на самом деле получаете один и тот же ответ с разных точек зрения). Некоторые вопросы будут звучать так, как будто их не нужно задавать… но вы все равно их задаете по следующей причине: вы не хотите ничего предполагать. Не предполагай. Перестаньте предполагать. Перестаньте гадать, что представляют собой переменные, и работайте над выяснением их значений, задавая все вопросы мира относительно требований нужным людям. Правильно… люди. Множественное число. Попытайтесь понять требование с разных точек зрения: конечного пользователя, архитектора пользовательского интерфейса, бизнес-аналитика, ваших коллег-разработчиков.

Однажды я был на встрече с дюжиной людей во время подготовки к будущему спринту. Пока люди за столом обсуждали оценку для той или иной задачи, я начал задавать вопросы, которые раньше не задавали, потому что в моей голове требование было понято на 85%. И я говорю себе, что если я не полностью понял требование, скорее всего, другие за столом тоже не поняли. Требование должно быть понято на 100%. Если это не так, скорее всего, требование не является четким, кратким или полным. Нет смысла начинать гонку, если мы не знаем, когда и где она должна закончиться. Бег без цели — пустая трата времени и энергии… ну, если только вы не занимаетесь кроссфитом. Во всяком случае, некоторые вопросы, которые я задавал, были настолько простыми, что их мог бы задать и пятилетний ребенок. Самое смешное… или грустное в этом то, что я не мог получить ответ на свой простой вопрос, потому что ответа просто не было ни у кого. Как мы можем оценивать то, что А) не до конца понятно и Б) неясно, кратко и полно?

Короче говоря, не начинайте работу до тех пор, пока все переменные не будут известны… насколько это возможно. Посмотрите на это с другой стороны: как бы вы себя чувствовали, работая над конструктором Lego или головоломкой из 1000 деталей, и когда вы уже почти закончили, вы понимаете, что одной детали не хватает. Или, может быть, два. Или три. Можно ли сказать, что Lego или головоломка завершены? Я бы не стал. Я бы расстроился. Это означает, что я потратил впустую время и энергию, которые мог бы направить куда-то еще. Конечно, вы можете сказать: «Ну, 98% сделано». Но я не хочу, чтобы LEGO «Тысячелетний сокол» был готов на 98%. Я хочу все это. Почему? Потому что он должен быть цельным. Это так просто.

Понять, кто эти персонажи

Требование начинается где-то. Большую часть времени это начинается в голове кого-то, когда он или она моет посуду после ужина. Затем эта идея в уме проходит через общение и сотрудничество с рядом людей. Если вы хотите правильно понять требование, вам нужно надеть шляпу детектива и найти людей в этой строке. Иди и познакомься с каждым из них. Вежливо попросите у них время. Помните, что для того, чтобы вы могли помочь им, они также должны помочь вам с пониманием части требования. Начните с того, что задайте им самый важный вопрос во вселенной: почему?

«Зачем это?» «Почему это важно для вас?» «Зачем делать это сейчас?» Попробуйте найти причину, первопричину требования. Возвращаясь к моему предыдущему примеру со спринтером, представьте, что он или она заканчивает гонку и бьет мировой рекорд… на квалификационной тренировке перед чемпионатом. Медалей на мероприятии не вручают. Нет съемочной группы NBC, которая снимала это. Так что спринтер только что побил мировой рекорд, и это не произвело впечатления. Это должно было повлиять на новости, но этого не произошло, потому что контекст не позволил этому влиянию проявиться в полной мере. При этом в жизни нет ничего более отстойного, чем работа над чем-то, что оказывается бесполезным.

После вопроса «почему» пришло время спросить «кто». Для кого именно вы это делаете? В городе Монреаль (где я сейчас работаю) обычно работают граждане. Так что это хорошо… теперь, когда я знаю, для кого я это делаю, это дает мне уверенность, цель делать эту работу хорошо.

ВОЗ?" усиливает вопрос «почему?» придав ему цель. Где «почему?» дает причину, «кто?» дает цель.

Понимание требований для требования

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

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

Помните об этом: потребовалось почти 14 лет, чтобы завершить работу башен-близнецов в Нью-Йорке (Всемирный торговый центр). Однако потребовалось всего несколько минут, чтобы превратить их в пепел. Вот как работает доверие. Не торопитесь, иначе вы рискуете подорвать доверие к себе. Это одно из самых важных приобретений в вашей карьере. И относиться к нему нужно соответственно.

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

Подведение итогов

Если вы хотите закончить быстро и не возвращаться к исправлению ошибок, вам нужно замедлиться. Если вам не хватает времени, чтобы закончить что-то, поднимите вопрос с менеджером проекта. Мы не всегда принимаем лучшие решения, но у каждого из нас есть право сказать об этом, поговорить об этом, когда возникает проблема. Хотя ваши пальцы важны для написания кода, ваш голос — лучший инструмент в вашем арсенале. Помните: самое худшее вложение в разработку программного обеспечения — это ваше тело. Ваше физическое тело. Твоя шея. Ваша спина. Ваши запястья. Ваши ноги. Твои глаза. Ваше тело будет страдать от этой работы. Это не физически исчерпывающе, но иногда физически болезненно. И все, что причиняет боль телу через долгое время, также может вызвать проблемы с разумом, духом, так что выгорание не за горами. Не доводите себя до выгорания или ослабления желания работать в этой творческой сфере. Замедлять. Знайте, что вы делаете, прежде чем начнете вводить первую строку кода. Убедитесь, что вы понимаете, что нужно построить. Если никто не уверен на 100% в том, что нужно построить, то примите тот факт, что это, возможно, придется создавать постепенно. Это не идеал, но иногда это реально. Поэтому, когда это произойдет, убедитесь, что понимаете основу того, что строится постепенно, применяя то, что я рекомендую на каждом этапе.

Если вы хотите закончить быстрее, притормозите.

Замедлять.

Медленный.

Вниз.