Дедлайн…
Один из самых больших кошмаров для разработчика.
Признайтесь, вас пугает это слово. Даже сейчас, читая эти строки, ваши волосы встают дыбом.
Вам интересно, откуда я это знаю?
Я был на вашем месте. Но страх перед дедлайном остался в прошлом. Я перестал переживать и примирился со своими страхами.
И предлагаю вам сделать то же самое. Просто возьмите и примите их. Это единственный способ справиться с ними.
Остался последний вопрос: как это сделать?
Есть некоторые факторы, которые мы часто игнорируем при установлении срока сдачи работы. Моя цель — показать эти факторы, чтобы вы поняли, насколько легко можно побороть свой страх перед дедлайном и начать наслаждаться жизнью и работой над проектом, не беспокоясь о датах.
Работайте в спокойной обстановке
Не спешите. Не принуждайте себя и свою команду к чему-либо.
В первую очередь вы должны понять, что не сможете успокоиться, если обозначите нереальные сроки для сдачи проекта, заставляя свою команду работать в спешке. В некоторых компаниях любят бросаться громкими словами, чтобы мотивировать свою команду двигаться вперед. Но как вы можете быть уверенными в том, что они поверят вашим словам, если те далеки от реальности?
Без четко установленного и, что самое главное, адекватного дедлайна, вы не сможете работать спокойно. Спокойствие — ключ к успеху. Когда вы думаете, что не справитесь к назначенной дате, или когда вам добавляют задач в проект, не давая при этом больше времени на выполнение, вы начинаете маниакально работать день и ночь. Больше это нельзя называть работой. Теперь это ад.
Постоянно находясь в состоянии стресса и под давлением, вы априори не можете хорошо выполнять свою работу. Спокойствие помогает вам осознанно подходить к принятию решений.
Наши предварительные расчеты времени ужасны
Пользователи Windows помнят это диалоговое окно. Приблизительное время копирования файлов (почти вечность) в точности соответствует нашим оценкам времени, не так ли?
Давайте признаем это. Наши расчеты никуда не годятся. Нам кажется, что мы можем угадать, сколько времени займет определенное задание. И мы действительно верим, что справимся вовремя.
Однако, как правило, мы игнорирует некоторые важные факторы, которые могут повлиять на наши предположения. Почему? Потому что мы слишком оптимистичны.
Сначала необходимо признать тот факт, что мы не умеем объективно оценивать свои силы. В дальнейшем, вспоминая об этом, вы не будете преуменьшать сложность проекта.
Разбейте большую задачу на маленькие. Чем меньше, тем легче оценить. Это увеличит ваши шансы на получение более точных предварительных расчетов.
Делайте свою работу хорошо, а не идеально
“Лучшее — враг хорошего” — Вольтер
Лучше всего нам удается найти сложное решение для простой задачи. Но:
Любая задача имеет простое решение, которое вы, вероятно, игнорируете.
Не гонитесь за идеальным решением. Первая версия проекта не должна быть лучшей и единственной. Сделайте половину работы. Главное, чтобы ваш продукт работал. Если вы будете слишком долго ждать, вы потеряете свои ресурсы и драгоценное время или пропустите дедлайн, или, что еще хуже, ничего не сделаете, потому что пытались достичь совершенства.
Найдите решение, которое принесет вам наибольшую пользу и не потребует больших усилий. И не забывайте, что “хорошее” со временем можно превратить в “лучшее”.
Не будьте заядлым оптимистом. Будьте реалистом.
Я знаю руководителей, которые слишком оптимистично относятся к работе, и это приводит к тому, что они устанавливают слишком оптимистичный дедлайн для мотивации команды. Это неправильно. Я не говорю вам становится пессимистами. Напротив, я лишь говорю о том, что вы должны научиться видеть все возможности, которые создает “узкое место”. Так, приняв их во внимание, вы получите более точное время выполнения работы.
В компании работают разные команды. Инженеры, команда по деловому развитию, маркетологи и т.д. Когда команда по деловому развитию просит вас назначить им дедлайн на самое ближайшее будущее, вы ни в коем случае не должны соглашаться.
Различайте такие понятия как “должны сделать”, “можете сделать” и “хотите сделать”
Здесь самое главное понимание. Каковы основные требования для выпуска вашего продукта? Как правило, команде разработчиков сложно отличить одно требование от другого.
Во время совещания один из членов команды говорит: “Мы можем реализовать эту функцию и это принесет нам такую-то пользу”, а другой скажет: “Мы должны реализовать эту функцию”. Каждый смотрит на один и тот же вопрос с разных точек зрения. Хорошо, мы можем реализовать ту или иную функцию и это может принести нам пользу, но есть важный вопрос: “Нужно ли это сейчас?В первой версии продукта?”.
В большинстве случаев ответ — НЕТ.
То, что вы должны сделать, — это то, на чем вы должны сосредоточиться в первую очередь. Исключите из списка “то, что вы могли бы сделать” и “то, что хотите сделать”.
Говорите “нет” по умолчанию
В тот самый момент, когда мы говорим “Да”, мы говорим “Нет” тем делам, которые нужно завершить уже сейчас.
Когда вы говорите “Да” чему-то новому, вы не задумываетесь о том, какое влияние это окажет на вашу жизнь.
“Давайте добавим больше задач в проект после того, как уже установлен дедлайн (со временем ваш проект должен стать меньше, а не больше)” — ответ НЕТ
“Мы сосредоточились на главном. Но что насчет деталей? Давайте посмотрим, что может создать проблемы в будущем” — ответ НЕТ. В первой версии продукта забудьте о каких-либо деталях. Не пытайтесь предсказать будущее.
Проблема не в недостатке свободного времени, а в количестве дел, которые необходимо сделать. Нужно различать “необходимо сделать” и “было бы неплохо сделать”.
Единственный способ добиться большего — это сделать меньше.
Никогда не меняйте дедлайн
Я встречал команды разработчиков с очень дурной привычкой, которая может повлиять на всю разработку проекта: изменение графика дедлайна.
Не укладываясь в один дедлайн, они устанавливают новый. Если они снова не успевают, дедлайн снова переносится. Когда что-то происходит неоднократно, это становится привычкой. Затем эта дурная привычка превращается в культуру. Другие команды в компании теряют доверие и ставят под сомнение работу разработчиков. Хуже того, в команде разработчиков коллеги могут потерять доверие друг к другу.
Изменение дедлайна, по сути, является признанием неудачи. Вы будто заявляете: “Мы не смогли составить план действий, мы не сосредоточились на том, что важно. Мы заставили наши команды выполнять не ту работу не в то время”.
Запомните, всегда будут какие-то проблемы
Если вы будете слишком оптимистичны, вы упустите тот факт, что при разработке могут возникнуть некоторые проблемы. Просто имейте это в виду. Возможно что-то пойдет не так и исправление ошибок займет время. Так что лучше будьте готовы к плохому развитию событий. При этом не нужно быть пессимистом и пытаться предсказать будущее, подготавливая себя и свою команду к неизвестному. Просто найдите баланс между оптимизмом и пессимизмом. Будьте реалистами.
Основываясь на своем опыте, могу сказать, что при разработке программного обеспечения всегда что-то идет не так. Поэтому мой вам совет:
Прежде чем установить дедлайн, прибавьте время, необходимое в том случае, если что-то пойдет не так и вам потребуется это исправлять.
Не привлекайте много людей к работе над проектом
Многие думают, что работа над проектом пойдет быстрее, если они привлекут больше людей. Однако они упускают один очень важный момент. Давайте обратимся к закону Брукса:
“Привлечение новых разработчиков в опаздывающий проект еще больше затягивает его окончание” — Фредерик Брукс
По словам Брукса, в проекте появляется такой инкрементный человек, который только увеличивает время разработки. Почему так получается?
- Требуется определенное количество времени, чтобы люди, недавно пришедшие в проект, начали продуктивно работать. Сначала вы должны обучить их. У вас уже есть ограниченное количество человеческих ресурсов и вам придется выделить эти ресурсы для обучения нового члена команды. Кроме того, новички будут “привносить” в проект баги, которые будут постоянно откладывать завершение проекта на неопределенный срок.
- С увеличением количества людей возрастает объем коммуникаций внутри команды.
- Увеличение количества людей в задаче с высокой степенью разделения, такой как уборка номеров в отеле, сокращает общую продолжительность задачи. Однако другие задачи, в том числе в разработке программного обеспечения, нельзя так делить. Еще один замечательный пример в книге Брукса: одной женщине требуется девять месяцев, чтобы родить одного ребенка, но “девять женщин не могут родить ребенка за один месяц”.
Возьмем еще одно доказательство Ричарда Далтона, позволяющее понять, почему привлечение большего количества людей является неправильным:
“Команда — это неизменяемый объект. Каждый раз, когда кто-то уходит или присоединяется, возникает новая команда, а не измененная.”
Не откладывайте на завтра
Что я имею в виду: на прошлой неделе у меня было совещание, на котором мы определялись с дедлайном для новой функции в проекте. Мы говорили о том, какие задачи являются приоритетными и как их следует реализовать.
Было одно задание, на которое мы потратили очень много времени. Мы все никак не могли выбрать способ выполнить его. Все из-за того, что разработчики пытались предсказать будущее. Каждое предложение начиналось с “что если”.
Вы не можете предсказать, что принесет вам будущее. Не нужно чрезмерно готовиться к неизвестному.
Я не говорю о каких-то серьезных технических решениях. Конечно, если вам нужно определиться с какой-то технологией для разработки, вы должны тщательно обдумать это. Но не тратьте время на мелочи. Неопределенные вещи увеличивают количество совещаний и блокируют прогресс.
Не откладывайте на завтра, принимайте решение и двигайтесь вперед.
Измените свой образ мышления с “давайте подумаем над этим” на “давайте решим это сейчас”. Окончательные решения ускорят процесс. Каждый в команде будет точно знать, что делать.
Общайтесь: видите, где “узкое место”?
Вы все спланировали. Вы определились, на чем целиком сосредоточить внимание и что делать. Вы точно знаете, сколько времени это займет (но, возможно, вы ошибетесь). Этого достаточно?
НЕТ.
Как я упоминал выше, всегда есть вероятность того, что что-то может пойти не так. Пока члены вашей команды работают над своими задачами, что-то может их затормозить. Что-то может помешать им выполнить свои задачи вовремя. Вы должны понять, где находится “узкое место” и что оно из себя представляет.
В этом случае вам поможет общение. Вы должны синхронизировать команду. Иногда члены команды прячутся “в панцирь” и не видят, что происходит за его пределами. Тут-то вы и выходите на сцену. Как только вы нашли “узкое место”, избавьтесь от него, чтобы члены вашей команды могли продолжить работать.
Желаю вам уложиться во все сроки 🙂
Читайте также:
Перевод статьи Hüseyin Polat Yürük: How to make peace with deadlines in software development
