Я долго пытался справиться с большим проектом, например создать приложение с нуля. Я брался за создание разных приложений, но так и не закончил ни одного из них, так как не умел разбивать задачи на части. Сначала я всегда с энтузиазмом принимался за новый проект, но довольно скоро увязал в деталях. Я постоянно думал о том, сколько работы осталось до конца, но так никогда и не добирался до финиша. Чем масштабнее был проект, тем выше был шанс, что он будет заброшен.
Я обнаружил, что я такой не один. Когда я раздавал задания другим разработчикам, то замечал, что главным показателем успеха проекта был размер задачи, которую я отдавал подчиненным. Чем больше задач я просил выполнить, тем выше была вероятность того, что они так и останутся невыполненными.
Мы уже говорили об одной из причин, почему это происходит: психологическая нагрузка от большой задачи. Столкнувшись с такой задачей, мы много времени тратим на размышления о ней и совсем мало на собственно работу. Люди склонны идти по пути наименьшего сопротивления. Столкнувшись с большой задачей, мы выбираем легкий путь, например идем проверять электронную почту или выпиваем еще одну чашечку кофе. Вот так мы начинаем прокрастинировать.
Однако прокрастинация – это не единственная причина, по которой мы не справляемся с большими задачами. Чем больше задача, тем она менее определенна, менее понятна. Если я попрошу тебя сходить в магазин и купить яиц, молока и хлеба, то ты точно знаешь, что делать. Задача понятна. Задачу выполнить легко, и не думаю, что она вызовет у тебя какие-то трудности.
Но если я попрошу тебя создать для меня сайт, то это будет сложная и менее определенная задача. Возможно, ты не будешь понимать, с чего начинать. У тебя возникнет много вопросов. Не думаю, что ты понимаешь, что нужно сделать, чтобы успешно выполнить это задание. Я мог бы написать тебе, что именно значит для меня создание сайта и чего я ожидаю, но на создание настолько подробного описания уйдет много времени, появляется вероятность того, что ты уже успеешь допустить где-то ошибку.
Большим задачам очень трудно дать адекватную оценку. Если я спрошу тебя, сколько времени понадобится для создания алгоритма для поиска самого большого элемента в списке, то ты дашь мне довольно точный ответ. Но если я спрошу тебя, сколько времени понадобится для внедрения функции корзины для покупок на сайте, то твоя оценка будет больше похожа на догадку.
Большие задачи очень сложны, и работа над ними с большей вероятностью приведет к прокрастинации. Как правило, такие задачи непонятны, при их выполнении можно совершить много ошибок, их очень сложно оценить.
Не теряй надежды. У меня есть решение. Оказывается, большинство больших задач можно разбить на несколько маленьких. По правде говоря, почти все большие задачи можно поделить на бесконечное количество маленьких задач.
Дробление задач на составляющие – это прием, который я постоянно использую в своей работе. Так я могу точно оценить время, которое потребуется для выполнения задачи.
По правде говоря, структура этой книги неслучайна. Возможно, тебе было интересно, почему в ней так много маленьких глав. Приступая к написанию этой книги, я намеренно решил написать много маленьких частей вместо нескольких больших. На это было две причины.
Во-первых, тебе как читателю будет легче воспринимать материал. Я знаю, что если я начну читать книгу с длинными главами, то я не захочу возвращаться к ней снова. К тому же если у меня не будет достаточно времени, то я тоже не смогу почитать эту книгу, так как не успею дойти до конца главы за отведенный на чтение срок. Надеюсь, ты уже заметил, что главу, состоящую из тысячи или двух тысяч слов, читать намного легче, чем длинные главы.
Во-вторых, мне намного легче писать маленькие главы. Я знаю, что написание книги – занятие не из легких. Это вызов. Многие начинают книгу, но никогда ее не заканчивают. Я сам множество раз начинал писать, но бросал это занятие на полпути. Небольшие главы, размер которых можно сравнить с большим постом в блоге, упрощают задачу: вместо одной большой задачи «написать книгу» у меня есть около 80 небольших задач «написать главы».
Когда ты разбиваешь задачу на множество мелких, тебе становится легче справляться с работой, и ты можешь точно оценивать время, которое на нее понадобится. Даже если ты выполнишь задачу неправильно, у тебя будет много возможностей исправить ошибку, прежде чем ты зайдешь слишком далеко. Очень часто полезно дробить большую задачу на составляющие.
Оказывается, разбивать задачи не так уж и сложно. Цитата про то, как съесть слона, правдива. Единственный способ, которым ты можешь съесть слона, – это откусывать по кусочку за раз. То же самое касается больших задач. Даже если сознательно ты не разбиваешь ее на части, ты все равно постепенно выполняешь ее.
Если ты хочешь взяться за выполнение большой задачи и сделать ее не такой пугающей, то тебе нужно определиться с шагами для ее выполнения. Если на работе мне поручают большую задачу, то первое, что я делаю, – это проверяю, могу ли я разбить задачу на составляющие.
Недавно я работал над одним проектом для моего клиента. Задача заключалась в том, чтобы в его коде работала система непрерывной интеграции. Вот это была задачка. Сначала это показалось мне сложным, пугающим, но я взял себя в руки и разбил задачу на несколько небольших.
Сначала я попытался заставить код клиента запускаться и компилировать из командной строки, так как это необходимо для создания автоматизированной сборки. Далее мне надо было сделать так, чтобы сервер сборки мог проверить код. Затем следовала задача, объединяющая обе предыдущие: мне надо было заставить сервер сборки проверить код, а также использовать сценарий командной строки для компиляции кода.
Таким образом, я разбил весь проект на маленькие задачи, и внезапно все стало казаться таким простым и нестрашным… Каждая маленькая задача оказалась простой, хотя изначально проект казался очень сложным.
Когда ты пытаешься разбить большую задачу на множество небольших, ты можешь обнаружить, что у тебя для этого недостаточно информации. Ты просто не знаешь, как это делать. Помнишь, я сказал, что большие задачи кажутся непонятными? Важный шаг в дроблении больших задач на маленькие – определение того, какой информации тебе не хватает. Как только ты заполнишь эти пробелы, ты сможешь разбить задачу на более мелкие.
Но это к лучшему. Намного лучше узнать об этом на раннем этапе проекта, пока ты не углубился в работу и не зашел слишком далеко. Когда ты разбиваешь крупную задачу на составляющие, убедись, что у каждой из небольших задач есть четкая цель. Когда ты определяешь цели, ты можешь обнаружить ценную информацию, которую мог бы упустить.
Когда я работаю с командами, использующими методологию Agile, я всегда стараюсь использовать этот метод – так я получаю от клиента всю нужную информацию. Очень часто клиенты не могут сформулировать, чего они хотят, так что они просто просят тебя выполнить большую задачу, например добавить корзину для покупок на их сайт. Но если ты сможешь разбить большую задачу на составляющие, то им будет проще объяснить, что им нужно.
Такой подход можно применить непосредственно к работе с кодом и решению проблем. Многие начинающие разработчики предпринимают множество безуспешных попыток разобраться со сложным участком кода или решить нетривиальную проблему, не понимая, почему у них ничего не получается. Все из-за того, что они не знают, как разбить большую задачу на несколько мелких. Должен признать, даже я время от времени грешу этим.
Конечно, мы разбиваем некоторые задачи на части, когда пытаемся справиться со сложностью кода. Именно поэтому у нас нет одного большого метода, в котором будет весь код. Мы разбиваем наш код на методы, функции, переменные и другие составляющие, упрощая его. Какой бы сложной ни была программа программирования, ее всегда можно разбить на составляющие. Если ты пытаешься написать сложный алгоритм, то разбей задачу на мелкие части, которые можно решать независимо друг от друга.
Неважно, насколько сложным и большим будет приложение, ты всегда можешь разбить его на строки кода. Строку кода может понять или написать любой программист; если ты разделишь задачу на составляющие, то сможешь написать любое приложение.
• Каких крупных задач ты избегаешь, потому что тебя пугает их размер? Может, ты откладываешь уборку гаража, написание поста в блоге или решение сложного алгоритма?
• Выбери крупную задачу, с которой ты столкнулся, и посмотри, можешь ли ты разбить ее на несколько мелких.
47Цена усердной работы и почему ты всегда избегаешь ее
Эта глава близка моему сердцу. Я чувствую, что в моей жизни и карьере случился огромный поворотный момент, когда я принял идею, что усердную работу не стоит избегать, ведь она так необходима для успеха.
Все всегда пытаются найти кратчайший способ к успеху – способ избежать усердной работы, необходимой для достижения успеха. Не буду лгать, я тоже был таким. Все мы хотим наслаждаться плодами усердной работы, не совершая ее на самом деле. Хотел бы я закончить эту книгу, не прилагая особых усилий для ее написания, но…
Реальность такова, что успеха можно добиться только путем усердной работы. В жизни, и особенно в карьере разработчика ПО, ты должен научиться сидеть и делать работу, которая не всегда будет тебе нравиться. Должен научиться делать эту работу постоянно, если ты действительно хочешь увидеть результаты.
В этой главе мы развеем некоторые мифы о шарлатанах, обещающих награду за то, что ты будешь работать умнее, а не усерднее. А еще мы рассмотрим некоторые проблемы мотивации, связанные с усердной работой.